1. OMG Mailing List
  2. UML 2.6 Revision Task Force

All Issues

  • All Issues
  • Name: uml2-rtf
  • Issues Count: 2,116

Issues Summary

Key Issue Reported Fixed Disposition Status
UMLR-820 Multiplicity of Comment's "owningElement" (composition/aggregation end next to Element) in UML diagram for Root should be 1 and not 0..1 UML 2.5.1 open
UMLR-819 missing async Operation call UML 2.5.1 open
UMLR-818 wrong definition of partial order UML 2.5.1 open
UMLR-817 Misleading sentence about the default history transition UML 2.5.1 open
UMLR-816 History Pseudostates should be allowed for top-level regions UML 2.5.1 open
UMLR-815 Derived union property values cannot change after initialization UML 2.5.1 open
UMLR-814 need to add DataType UML 2.5.1 open
UMLR-811 No formal mapping between VisibilityKind and Visibility Symbols UML 2.5.1 open
UMLR-813 Inconsistent document structure descriptions in section 6.4 UML 2.5.1 open
UMLR-812 Missing dot notation in Abstract Syntax diagrams in Clause 16 Actions UML 2.5.1 open
UMLR-808 Wrong cross-reference for RedefinableElement specialisation UML 2.5.1 open
UMLR-685 UML 2.5: StateMachine Vertex needs to be made a kind of RedefinableElement instead of State UML 2.5 open
UMLR-810 Mis-spelling of redefined property modelElement becomes modeElement UML 2.5.1 open
UMLR-809 Many diagram hyperlinks in the Diagrams sections of Classifier Descriptions sections are wrong UML 2.5.1 open
UMLR-807 BehavioredClassifier is not shown as a specialisation of Classifier anywhere in the Abstract Syntax UML 2.5.1 open
UMLR-804 Link incorrect UML 2.5.1 open
UMLR-802 Owner has to do with Namespaces UML 2.5.1 open
UMLR-806 Specification inconsistent UML 2.5 open
UMLR-805 Possible missing ActivityEdge guard notation example on Figure 15.5; Duplicate ActivityEdge weight on Figure 15.5 and Figure 15.7 UML 2.5.1 open
UMLR-803 StateMachine initial transition inconsistency UML 2.5.1 open
UMLR-704 Figure 14.44 ProtocolStateMachine example error UML 2.5 open
UMLR-705 Meaning of Event on Initial Transition unclear UML 2.5 open
UMLR-801 Figure 9.1: duplicate graphical element "NamedElement" UML 2.5.1 open
UMLR-800 Typo in caption for figure 14.14 UML 2.5.1 open
UMLR-799 Behavioral Classification UML 2.5.1 open
UML22-21 UML 2 Issue: isUnique UML 1.5 UML 2.2 Resolved closed
UMLR-757 Make AssociationClasses unique again UML 2.5 open
UMLR-798 Unclear how StateInvariants on a Lifeline identify the next OccurranceSpecification UML 2.5.1 open
UMLR-797 unclear whether imported elements are merged by package merge UML 2.5.1 open
UMLR-796 MultiplicityElement.isOrdered: Abstract Syntax Metamodel does not match the specification document UML 2.5.1 open
UMLR-795 Inheritance of extension not explicitly stated UML 2.5.1 open
UMLR-794 Association wrong here UML 2.5.1 open
UMLR-793 The last link on the page about Diagram Definition is dead UML 2.5.1 open
UMLR-792 Dead URL link for XMI UML 2.5.1 open
UMLR-791 https/www.omg.org/spec/UML/ URL is not valid (typo) UML 2.5.1 open
UMLR-790 UML::Property.defaultValue has upper multiplicity of 1 even though Property is a MultiplicityElement UML 2.5.1 open
UMLR-789 Receptions should be redefinable elements as operations are. UML 2.5.1 open
UMLR-788 Inconsistent use of unspecified and unlimited for the multiplicity notation UML 2.5.1 open
UMLR-787 There is not a way to do this... UML 2.5.1 open
UMLR-786 removeAt_and_value wrong UML 2.5.1 open
UMLR-785 Misleading Link UML 2.5.1 open
UMLR-784 Include ordering UML 2.5.1 open
UMLR-783 need to include setup UML 2.5.1 open
UMLR-782 switch LoopNode for ConditionalNode UML 2.5.1 open
UMLR-781 " in state name UML 2.5.1 open
UMLR-780 Local Transitions conflict UML 2.5.1 open
UMLR-779 OCL and Text Mismatch UML 2.5.1 open
UMLR-777 Lambda's,Traits and Generics UML 2.5.1 open
UMLR-778 Textual "Markdown" visualization UML 2.5.1 open
UMLR-776 OCL for excludeCollisions in Namespace element seems incorrect UML 2.5.1 open
UMLR-775 An Activity Edge cannot connect to Activities UML 2.5.1 open
UMLR-774 Needs to be a constraint between AggregationKind and subsetting UML 2.5.1 open
UMLR-773 Please make it clear what is being modeled behind the scenes for figures UML 2.5.1 open
UMLR-759 UML Specification "Normative References" uses non-secure links UML 2.5 open
UMLR-772 Please provide more detail on redefinition UML 2.5.1 open
UMLR-771 UML.xmi is not well-formed UML 2.5.1 open
UMLR-770 PackageImport Missing for Type Generalization UML 2.5.1 open
UMLR-769 Nested Port not supported on Sequence Diagram UML 2.5.1 open
UMLR-768 InteractionUse can not reference a CollaborationUse (as shown in Figure 17.24) UML 2.5.1 open
UMLR-767 Error in Loop fragment deffinition UML 2.5.1 open
UMLR-766 Duplicate section titles UML 2.5.1 open
UMLR-761 Property.Association is not a union UML 2.5.1 open
UMLR-765 Comments not annotating anything should annotate their owner UML 2.5 open
UMLR-89 No way of specifying element documentation UML 2.5 open
UMLR-764 Specializations of an Association Class UML 2.5.1 open
UMLR-219 UML has no way of distinguishing Notes from Comments UML 2.5 open
UMLR-185 Association class notation with just class or association UML 2.1.2 open
UMLR-763 Clarify that AcceptEventActions in InterruptibleActivityRegions are disabled when token leaves UML 2.5 open
UML22-457 New proposal for conjugate types for ports UML 2.1.2 UML 2.2 Resolved closed
UML22-459 Semantics of Ports in Components and CompositeStructures are incompatible UML 2.1.2 UML 2.2 Resolved closed
UMLR-750 Description of Generalization of Enumerations is contradictory UML 2.5 open
UMLR-758 Duplicated xmi:id values in UML.xmi UML 2.5.1 open
UMLR-756 Behavior::behavioredClassifier bodycondition is serialized as a precondition UML 2.5.1 open
UMLR-755 Unclear whether current State during Transition is the target State UML 2.5.1 open
UMLR-754 Figure 9.11 misses attribute name UML 2.5.1 open
UMLR-753 I believe ptc/08-05-12 and ptc/08-05-06 got mixed up on the UML 2.2 specification page UML 2.2 open
UMLR-751 The definition of relative Time Events is ambigious UML 2.5.1 open
UMLR-292 About behavior ports UML 2.5 open
UMLR-54 Operation calls on behavior ports UML 2.0 open
UMLR-107 Behavioral port UML 2.5 open
UMLR-749 Are null NamedElement::name values names? UML 2.5 open
UMLR-748 Thing UML 2.5 $issue.fixedSpecification.name Deferred closed
UMLR-747 Typo UML 2.5.1 open
UMLR-746 Figure 7.17 has some trucated labels UML 2.5 open
UMLR-745 Typo in last syntax example UML 2.5 open
UMLR-744 Attachment point of connectors not specified UML 2.5 open
UMLR-743 Implied Multiplicity of the association-like notation should be displayable UML 2.5 open
UMLR-742 Lifeline "same_classifier" constraint has an inconsistent specification UML 2.5 open
UMLR-738 Incorrect use of multiplicity element. UML 2.5 open
UMLR-620 Complete and Covering are Synonyms and used confusinginly UML 2.5 open
UMLR-730 Does the abort of an Do/Activity by an incoming event count as a Completion Event UML 2.5 open
UMLR-234 UML Interactions: Misleading suggestion of relationship between Interactions and Activities modeling UML 2.5 open
UMLR-740 DecisionNode is missing a constraint on incoming edges UML 2.5 open
UMLR-306 How to access a token value in a guard? UML 2.5 open
UMLR-711 Conflicting constraints UML 2.5 open
UMLR-243 Restrictions on decision nodes UML 2.5 open
UMLR-668 Unspecified and inconsistent notation for Observations UML 2.5 open
UML22-319 Explanation of Observation notation UML 2.1 UML 2.2 Resolved closed
UMLR-737 ReturnValueRecipient missing in Metamodel Diagram of InteractionUse UML 2.5 open
UMLR-736 Figure 17.20 "InteractionUse with value return" shows incorrect notation UML 2.5 open
UMLR-735 Undefined notation for ownedBehaviors in Figures 17.23 and 17.24 UML 2.5 open
UMLR-734 Instances are linked to other instances, not associated UML 2.5 open
UMLR-732 Odd restriction on state machine redefinition context UML 2.5 open
UMLR-729 Clarify diagram notation for collection parameters in operation UML 2.5 open
UMLR-728 Transistion selection algorithm is incomplete UML 2.5 open
UMLR-727 UML: Missing property subset for StateMachine::extendedStateMachine UML 2.5 open
UMLR-725 Nested activities in activity diagrams UML 2.5 open
UMLR-726 Template binding relationship incorrect notation UML 2.5 open
UMLR-724 bad example for weight in Figure 15.21 UML 2.5 open
UMLR-404 ActivityEdge weight examples UML 2.5 open
UMLR-723 Implication of weight of ActivityEdge is unclear UML 2.5 open
UMLR-722 Conjugated port properties shown on association ends and in compartments UML 2.5 open
UMLR-721 Actor Relationships UML 2.5 open
UMLR-720 Incorrect arrow heads for object flows UML 2.5 open
UMLR-718 Ambiguous meaning of word "composed" UML 2.5 open
UMLR-119 Section: Annex A: Diagrams UML 2.1.1 open
UMLR-681 ClassB::height missing from diagram UML 2.5 open
UMLR-680 Missing interface name in Figure 10.10 ISensor is a required Interface of TheftAlarm UML 2.5 open
UMLR-691 Section 14.2.4.4 is not a real section UML 2.5 open
UMLR-677 Why is Association.memberEnd ordered? UML 2.5b1 open
UMLR-684 Figure 11.23 (and 11.22) should use one brand of tire but show two instead UML 2.5 open
UMLR-690 Transition guards should be its own section. UML 2.5 open
UMLR-697 UML 2.5: StateMachine Vertex needs to be made a kind of UML 2.5 open
UMLR-702 Clarify that deep history uses the same default transition strategy as shallow history UML 2.5 open
UMLR-354 State machine semantics for transition between regions of an orthogonal state UML 2.4.1 open
UMLR-717 Invalid XMI elements containing both xmi:type and href UML 2.5 open
UMLR-710 Missing visibility definition UML 2.5 open
UMLR-716 What is a "compound state"? UML 2.5 open
UMLR-715 All actions should be able to own control pins UML 2.5 open
UMLR-714 Missing Constraint: Associations cannot type StructuralFeatures UML 2.5 open
UMLR-348 Actor association constraint makes UseCase subclass of Class UML 2.5 open
UMLR-713 On page 290 of UML 2.5 formal/2015-03-01, UML 2.5 open
UMLR-712 New Issue on UML 2.5 formal/2015-03-01 re signalbroadcastaction vs. broadcastsignalaction UML 2.5 open
UMLR-696 The behavior of an OpaqueExpression should be allowed to have input parameters UML 2.5 open
UMLR-92 UML/OCL spec mismatch-Constraint.context vs Constraint.constrainedElement UML 2.5 open
UMLR-706 What is "a separate InteractionConstraint"? UML 2.5 open
UMLR-703 XOR Constraint modeling UML 2.5 open
UMLR-701 Inconsistent constraints about several kinds of UML Diagrams UML 2.5 open
UMLR-699 Notation of a reception: Keyword <> is superfluous UML 2.5 $issue.fixedSpecification.name Deferred closed
UMLR-698 OpaqueExpression should own Behavior UML 2.5 open
UMLR-627 Semantics of Lifeline.selector not clear UML 2.5 open
UMLR-640 Notation is depreciated for inherited interface UML 2.5 open
UMLR-692 Comment is misleading UML 2.5 open
UMLR-689 Mixed plural/singular UML 2.5 open
UMLR-688 Plural vs Singulr? UML 2.5 open
UMLR-687 Unclear sentence UML 2.5 open
UMLR-686 Missing words in sentence UML 2.5 open
UMLR-68 reply messages in interactions UML 2.5 open
UMLR-101 Subclasses of InstanceSpecification UML 2.5 open
UMLR-112 ValueSpecification that refers to some Element shall be defined UML 2.5 open
UMLR-113 Ability to define "context specific" default values for Part UML 2.5 open
UMLR-683 Order of example information should be diagram first, then explanation. UML 2.5 open
UMLR-682 Link to "see" sections missing UML 2.5 open
UMLR-679 AssociationEnd/Attribute redefintion consistency UML 2.5 open
UMLR-678 Why is a qualified association qualifier composed by a Property? UML 2.5 open
UMLR-355 UML should support proxies for linking models UML 2.5 open
UMLR-676 No UML approach to create an infix operator UML 2.5 open
UMLR-674 Parameter types required for operation parameters UML 2.5 open
UMLR-329 TypeElement / TypedElement typo UML 2.5 open
UMLR-673 Spec refers to TypeElement twice. Should be TypedElement UML 2.5 open
UMLR-672 Constraint TemplateSignature::own_elements too constraining UML 2.5 open
UMLR-671 Need example of derived qualifier. UML 2.5 open
UMLR-670 The Kind field from frame names should be bold UML 2.5 open
UMLR-659 Need BNF for Protocol State Machines Transitions UML 2.5 open
UMLR-669 DI refers to putting the Diagram Kind in bold... UML 2.5 open
UMLR-667 Package names in wrong location. UML 2.5 open
UMLR-35 Disjointness should be independent of generalization UML 2.0 open
UMLR-41 section 7.3.17 /EnumerationLiteral should not be an InstanceSpecification UML 2.5 open
UMLR-665 Impossiblity to specify links for connected roles. UML 2.5 open
UMLR-664 Delegation Connector should not be typed UML 2.5 open
UMLR-663 Decide whether the document divisions are "sub clauses" or "subclauses" UML 2.5 open
UMLR-660 Unexpected trigger reception has contradictory results in Protocol State Machines UML 2.5 open
UMLR-661 What does calling an "operation for a state" mean in PSM. UML 2.5 open
UMLR-658 No notation for associations defined for abstract classes UML 2.5 open
UMLR-202 UML:Notational option to display inherited features in a subclass UML 2.5 open
UMLR-657 Deploying a «deployment spec» has no explicit interpretation UML 2.5 open
UMLR-656 Shoppin->Shopping UML 2.5 open
UMLR-655 UML 2.5 refers to EBNF, but the spec uses a variant BNF, not EBNF UML 2.5 open
UMLR-384 Classifiers can contain Packages, but they can't have appropriate visibility UML 2.5 open
UMLR-654 Pin rectangles in examples should not overlap the action border UML 2.5 open
UMLR-653 Activity Generalization is underspecified UML 2.5 open
UMLR-315 Rename Specialization/Generalization between abstract classes UML 2.5 open
UMLR-652 In Sequence diagrams, the duration constraint shown as a vertical two-headed is ambiguous UML 2.5 open
UMLR-651 In the time-related syntax for Sequence diagrams, there are used two terms (now, duration). Are there more? Are these defined? UML 2.5 open
UMLR-650 It doesn't seem possible to use a time-based trigger in the alternate format transition-focused state machine. UML 2.5 open
UMLR-649 Use of decomposition indicator UML 2.5 open
UMLR-648 InstanceSpecification for a qualified Property UML 2.5 open
UMLR-646 Recursive use of Interaction Use UML 2.5 open
UMLR-647 Limitation on isDimension Partition to be uncontained appears unwarranted UML 2.5 open
UMLR-645 Classifier.allSlottableFeatures shall incorporate redefinition UML 2.5 open
UMLR-643 Location of owning fully qualifed name not specified. UML 2.5 open
UMLR-642 Clarify the difference between «create» and «instantiate» UML 2.5 open
UMLR-641 Missing parameter properties of stream and exception in BNF UML 2.5 open
UMLR-637 What is the order for EnumerationLiterals? UML 2.5 open
UMLR-639 Wrong expression for dipicting package merge process? UML 2.5 open
UMLR-638 Inconsistency in constraints and rules for property merge UML 2.5 open
UMLR-636 How to deal with guard in Transition redefinition? UML 2.5 open
UMLR-635 Typing error in figure 9.11 UML 2.5 open
UMLR-634 Wrong figure referrence in text UML 2.5 open
UMLR-633 Computation error for the example of ReduceAction UML 2.5 open
UMLR-631 UML 2: Lifeline should be made a TemplateableElement UML 2.5 open
UMLR-630 Semantics of UnlimitedNatural in notation section. UML 2.5 open
UMLR-629 Matching between '+-#~' in Property's and "public-private-protected-package" is not described UML 2.5 open
UMLR-628 Constraint wording implies aggregation is only for associations UML 2.5 open
UMLR-626 Need to constrain where triggers can be put in state machines UML 2.5 open
UMLR-625 Missing: how +-#~ symbols map to VisibilityKind UML 2.5 open
UMLR-624 Example for association-like notation for attribute contradicts description. UML 2.5 open
UMLR-623 In OCL, the use of ::_'in' appears unwarranted UML 2.5 open
UMLR-622 Define well-formed/ill-formed UML 2.5 open
UMLR-621 Clarify Property Qualifiers with a full Example UML 2.5 open
UML22-307 Repr. of applied stereotypes and their properties insufficiently described UML 2.1 UML 2.2 Resolved closed
UMLR-619 Class.isAbstract attribute is not necessary UML 2.5 open
UMLR-420 Multiplicity of opposite end of a number of associations from various action metaclasses UML 2.5 open
UMLR-618 isDirectlyInstantiated is defined in reverse UML 2.5 open
UML25-684 Typo in Interaction Example UML 2.5b1 UML 2.5 Duplicate or Merged closed
UMLR-328 NamedElement::allNamespaces is invalid at model root UML 2.5 open
UMLR-351 Section 15.5.3: a missed word UML 2.5 open
UML22-1380 Section: 7.3.10/Associations UML 2.1.2 UML 2.2 Duplicate or Merged closed
UML22-1376 section on connectors in the component chapter UML 2.0 UML 2.1 Resolved closed
UML241-47 No unambiguous way in UML 2.4 to serialize StructuredActivityNode UML 2.4 UML 2.4.1 Resolved closed
UML24-152 navigation only possible to generalization but not to specializations of elements UML 2.3 UML 2.4 Closed; No Change closed
UML23-155 Japan Superstructure PAS Ballot Comments - comment 9 UML 2.2 UML 2.3 Resolved closed
UML23-154 New proposal for conjugate types for ports UML 2.1.2 UML 2.3 Resolved closed
UML23-153 proper content for Figure 13.8 UML 2.1 UML 2.3 Closed; No Change closed
UML23-152 Section: 15.3.8 UML 2.1.1 UML 2.3 Resolved closed
UML23-151 Section: 14.3.20 UML 2.0 UML 2.3 Resolved closed
UML22-1375 7.3.41 Parameter (from Kernel, AssociationClasses)" UML 2.1 UML 2.1.2 Resolved closed
UML23-150 UML 2 Super / Activities / missing subsets UML 2.1 UML 2.3 Resolved closed
UML22-1374 Profiles::ObjectNode has wrong default multiplicity UML 2.1 UML 2.1.1 Resolved closed
UML23-148 UML 2 Super / Components / realizingClassifier UML 2.0 UML 2.3 Resolved closed
UML22-1373 Section: 12.3.52 UML 2.0 UML 2.1 Resolved closed
UML23-149 Section: 8.3.4 UML 2.0 UML 2.3 Resolved closed
UML23-147 LiteralReal has no default value. It would make sense if it had a value of 0 as for LiteralInteger. UML 2.2 UML 2.3 Resolved closed
UML23-146 UML 2 chapter 17: template model cannot represent templates parameterized by value types UML 2.2 UML 2.3 Resolved closed
UML22-1372 Instance modeling does not take into account stereotypes properties UML 2.1.2 UML 2.2 Resolved closed
UML22-1371 Comments owned by Packages (02) UML 2.1.2 UML 2.2 Resolved closed
UML22-1370 Comments owned by Packages UML 2.1.2 UML 2.2 Resolved closed
UML22-1369 section 15.3.14 Transition :: Constraints UML 2.1.2 UML 2.2 Resolved closed
UML22-1368 Regarding the quote on p128 UML 2.1.2 UML 2.2 Resolved closed
UML22-1367 Section: Composite Structures/Abstract syntax UML 2.1.1 UML 2.1.2 Resolved closed
UML22-1366 ptc/06-01-02:14.3.14, Notation UML 2.1 UML 2.1.1 Resolved closed
UML22-1142 Output tokens UML 2.1 UML 2.1.1 Duplicate or Merged closed
UML25-672 Problems with OCL definition of Package::makesVisible UML 2.5b1 UML 2.5 Resolved closed
UML25-671 an instance spec should be a legitimate value of a property typed by a classifier UML 2.4.1 UML 2.5 Resolved closed
UML25-668 A comment is a specialization of Element UML 2.4.1 UML 2.5 Resolved closed
UML25-667 Surplus classifier field serialized in Superstructure.xmi UML 2.4.1 UML 2.5 Resolved closed
UML25-670 Attribute is represented by Property UML 2.4.1 UML 2.5 Resolved closed
UML25-669 Operation "isConsistentWith" is not overridden for any RedefinableElement UML 2.4.1 UML 2.5 Resolved closed
UML25-664 Question About Arrows In Communication Diagramms UML 2.4.1 UML 2.5 Resolved closed
UML25-663 Constraint [1] uses undefined attribute "ownedAttribute UML 2.4.1 UML 2.5 Resolved closed
UML25-662 Inconsistency: CentralBufferNode (ch .12.3.16) and fig. 12.15 UML 2.4.1 UML 2.5 Resolved closed
UML25-665 missing words in section 14.1 UML 2.4.1 UML 2.5 Resolved closed
UML25-673 Incomplete sentence UML 2.5b1 UML 2.5 Resolved closed
UML25-666 DurationObservation#event should be ordered UML 2.4.1 UML 2.5 Resolved closed
UML25-661 LifeLine instead of Lifeline UML 2.4.1 UML 2.5 Resolved closed
UML25-630 UML 2.3: Transitions outgoing junction vertexes should be allowed to have triggers 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-660 Behavior should be derived from Classifier, not Class UML 2.4.1 UML 2.5 Resolved closed
UML25-659 Package merge on Class metatype causes semantic issues - particularly with state machine context UML 2.4.1 UML 2.5 Resolved closed
UML25-648 Error in UML diagrams? UML 2.4.1 UML 2.5 Resolved closed
UML25-647 Suggestions for editorial changes UML 2.4.1 UML 2.5 Resolved closed
UML25-654 how to instantiate associations between stereotypes UML 2.4.1 UML 2.5 Resolved closed
UML25-653 Core package caption wrong UML 2.4.1 UML 2.5 Resolved closed
UML25-658 Add an example for the lifeline head shape UML 2.4.1 UML 2.5 Resolved closed
UML25-657 color of the notation is specified UML 2.4.1 UML 2.5 Resolved closed
UML25-656 The property “packagedElement: PackageableElement [*]” is not a derived property and should not be prefixed with "/" UML 2.4.1 UML 2.5 Resolved closed
UML25-655 Opposite ends of derived unions should be derived unions UML 2.4.1 UML 2.5 Resolved closed
UML25-651 Use of term "locus of control" UML 2.4.1 UML 2.5 Resolved closed
UML25-650 V2.4.1 from 11-08-05 on page 14 in Figure 7.3 UML 2.4.1 UML 2.5 Resolved closed
UML25-646 default is wrong UML 2.4.1 UML 2.5 Resolved closed
UML25-645 V2.4.1 from 11-08-05 on page 14 in Figure 7.3 UML 2.4.1 UML 2.5 Resolved closed
UML25-649 Reference in index to item that does not exist in contents UML 2.4.1 UML 2.5 Resolved closed
UML25-652 incorrect upper value of coveredBy of Lifeline UML 2.4.1 UML 2.5 Resolved closed
UML25-632 ChangeEvent association mismatch UML 2.4.1 UML 2.5 Resolved closed
UML25-631 EnumerationLiterals in the XMI UML 2.4.1 UML 2.5 Resolved closed
UML25-635 "A_realization_abstraction_component" is useless UML 2.4.1 UML 2.5 Resolved closed
UML25-634 Subpart I and II are missing in Bookmarks UML 2.4.1 UML 2.5 Resolved closed
UML25-644 default value of ClassifierTemplateParameter#allowSubstitutable is "..." UML 2.4.1 UML 2.5 Resolved closed
UML25-643 Figure 15.2 does not include TransitionKind UML 2.4.1 UML 2.5 Resolved closed
UML25-640 role "interval" appears "interva" UML 2.4.1 UML 2.5 Resolved closed
UML25-639 OpaqueBehavior#body attributes "nonunique" truncated as "nonuni..." UML 2.4.1 UML 2.5 Resolved closed
UML25-642 misspelling: io-oargument UML 2.4.1 UML 2.5 Resolved closed
UML25-641 OpaqueBehavior#body attributes "nonunique" truncated as "nonuni..." UML 2.4.1 UML 2.5 Resolved closed
UML25-636 RedefinableElement (from Kernel) is preferable UML 2.4.1 UML 2.5 Resolved closed
UML25-633 UML Superstructure Specification UML 2.4.1 UML 2.5 Resolved closed
UML25-637 poor figure resolution and a misspelling: fal...( false ) UML 2.4.1 UML 2.5 Resolved closed
UML25-638 {ordered} is rather far from +bodyOutput UML 2.4.1 UML 2.5 Resolved closed
UML24-111 Problem with ExtensionEnd::lower UML 2.3 UML 2.4 Resolved closed
UML24-108 UML state machines: inconsistent subset of StateMachine::extendedStatemachine UML 2.3 UML 2.4 Resolved closed
UML24-107 isDerived with DefaultValue UML 2.3 UML 2.4 Resolved closed
UML24-104 Change all properties typed by data types to aggregation=none UML 2.3 UML 2.4 Resolved closed
UML24-103 Give all constraints unique names within their context. UML 2.3 UML 2.4 Resolved closed
UML24-110 UML 2.4 - ConditionalNode - Semantics UML 2.3 UML 2.4 Resolved closed
UML24-109 DecisionNode at all guards evaluated to false UML 2.3 UML 2.4 Resolved closed
UML24-101 EnumerationHasOperations : UML::VisibilityKind::bestVisibility UML 2.3 UML 2.4 Resolved closed
UML24-100 Parameter have Effects UML 2.3 UML 2.4 Resolved closed
UML24-106 Property::isID should not be optional UML 2.3 UML 2.4 Resolved closed
UML24-112 stereotype <> for defining parameterized classes is nowhere defined UML 2.3 UML 2.4 Resolved closed
UML24-105 UML 2.4 - Interaction UML 2.3 UML 2.4 Resolved closed
UML24-102 The metamodel contains instances of Model UML 2.3 UML 2.4 Resolved closed
UML24-80 xmi files in the 2.4 RTF deliverables have cmof tags contained in a non-XMI root element UML 2.3 UML 2.4 Resolved closed
UML24-82 Operation::isConsistentWith UML 2.3 UML 2.4 Resolved closed
UML24-81 UML2.4: StandardProfileL2 & L3 are incomplete as delivered UML 2.3 UML 2.4 Resolved closed
UML24-84 bodyCondition and isQuery UML 2.3 UML 2.4 Resolved closed
UML24-83 isConsistentWith UML 2.3 UML 2.4 Resolved closed
UML24-74 "unique" annotation UML 2.3 UML 2.4 Resolved closed
UML24-77 The stereotype «Create» and keyword «create» are both defined in the UML 4 document UML 2.3 UML 2.4 Resolved closed
UML24-76 Figure 9.2 (Abstractions subpackage dependencies) has wrong dependency UML 2.3 UML 2.4 Resolved closed
UML24-79 "isStatic" property of Feature no longer appears in any diagram UML 2.3 UML 2.4 Resolved closed
UML24-78 coveredBy : InteractionFragment [0..1] should be [*] UML 2.3 UML 2.4 Resolved closed
UML24-85 redefinitionContext of Property UML 2.3 UML 2.4 Resolved closed
UML24-73 Ambiguous constraints for transitions UML 2.3 UML 2.4 Resolved closed
UML24-72 Typo: isStric => isStrict UML 2.3 UML 2.4 Resolved closed
UML24-75 Qualified name is incorrectly claimed to be unambiguous UML 2.3 UML 2.4 Resolved closed
UML24-68 UML 2.4: Add package:URI UML 2.3 UML 2.4 Resolved closed
UML24-67 UML 2.4: Add Property::isId UML 2.3 UML 2.4 Resolved closed
UML24-71 UML 2.4: Inconsistent rendering of OCL in UML metamodel UML 2.3 UML 2.4 Resolved closed
UML24-70 Over-general sentence about MOF and Profiles UML 2.3 UML 2.4 Resolved closed
UML24-69 UML 2.3 Superstructure: Non-sensible text for modelLibrary stereotype UML 2.3 UML 2.4 Resolved closed
UML24-58 UML 2.3, Figure 18.1 UML 2.3 UML 2.4 Resolved closed
UML24-57 Term "method activation" deprecated? UML 2.3 UML 2.4 Resolved closed
UML24-66 UML 2.3 Issue: Constraint InformationFlow.sources_and_target_kinds UML 2.3 UML 2.4 Resolved closed
UML24-65 NamedElement::clientDependency constrained to subset DirectedRelationship::source UML 2.3 UML 2.4 Resolved closed
UML24-64 Figure 7.10 shows Feature::isStatic as abstract UML 2.3 UML 2.4 Resolved closed
UML24-59 split the addition of generalization relationships among association in 14977 in two parts UML 2.3 UML 2.4 Resolved closed
UML24-62 It seems odd to say that Service “computes a value”. UML 2.3 UML 2.4 Resolved closed
UML24-61 Create UML 2.3 UML 2.4 Resolved closed
UML24-63 issues relating to Figure 7.14 - The Packages diagram of the Kernel package UML 2.3 UML 2.4 Resolved closed
UML24-60 Auxiliary UML 2.3 UML 2.4 Resolved closed
UML24-130 MultiplicityElement constraint 1 inconsistent with possible [0..0] multiplicity UML 2.3 UML 2.4 Resolved closed
UML24-128 Figure 7.31 propose an “association-like” notation for attributes UML 2.3 UML 2.4 Resolved closed
UML24-127 Statement mistake UML 2.3 UML 2.4 Resolved closed
UML24-129 Section numbering UML 2.3 UML 2.4 Resolved closed
UML24-124 UML 2.4: “Figure 7.31 shows the dot at the wrong end.” UML 2.3 UML 2.4 Resolved closed
UML24-123 UML 2: Multiplicity of Lifeline's coveredBy is incorrectly specified UML 2.3 UML 2.4 Resolved closed
UML24-116 Fix minor inconsistencies between infrastructure specification document & metamodel UML 2.3 UML 2.4 Resolved closed
UML24-115 Missing relation between "Namespaces" package and "Ownerships" package in fig. 9.2 (p. 30)? UML 2.3 UML 2.4 Resolved closed
UML24-120 Deep history for orthogonal states UML 2.3 UML 2.4 Resolved closed
UML24-119 Parameter semantics related to Behavior and BehavioralFeature UML 2.3 UML 2.4 Resolved closed
UML24-118 Property.isReadOnly is redundant with StructuralFeature.isReadOnly UML 2.3 UML 2.4 Resolved closed
UML24-122 Part document structures in Infrastructure need to conform to ISO Standard Document Template Conventions UML 2.3 UML 2.4 Resolved closed
UML24-121 Big UML 2.4 problem: missing defaults in XMI UML 2.3 UML 2.4 Resolved closed
UML24-114 Operation with multiple return parameter UML 2.3 UML 2.4 Resolved closed
UML24-113 Wrong constraint on Operation::bodyCondition UML 2.3 UML 2.4 Resolved closed
UML24-117 Be explicit that type does not need to be set for LiteralBoolean etc. UML 2.3 UML 2.4 Resolved closed
UML24-126 Constraint is Wrong UML 2.3 UML 2.4 Resolved closed
UML24-125 Wrong Classifier Name UML 2.3 UML 2.4 Resolved closed
UML24-49 UML2 - Invalid constraint for Actor UML 2.3 UML 2.4 Resolved closed
UML24-48 Detailed modeling of the Standard Profiles UML 2.3 UML 2.4 Resolved closed
UML24-52 UML 2 issue - misleadingly named associations UML 2.3 UML 2.4 Resolved closed
UML24-51 Meaning of BodyCondition and its alignment with OCL UML 2.3 UML 2.4 Resolved closed
UML24-53 Resolution to issue 14063 UML 2.3 UML 2.4 Resolved closed
UML24-55 Issue 14287 and 13330 resolutions are inconsistent and incorrectly applied. UML 2.3 UML 2.4 Resolved closed
UML24-54 UML 2 Subclasses of Classifier should subset redefinedClassifier when they redefine UML 2.3 UML 2.4 Resolved closed
UML24-47 MessageEvents UML 2.3 UML 2.4 Resolved closed
UML24-46 Association owned derived union UML 2.3 UML 2.4 Resolved closed
UML24-50 composite tags UML 2.3 UML 2.4 Resolved closed
UML24-56 UML2 Issue: OCL in resolution 11114 is incorrect UML 2.3 UML 2.4 Resolved closed
UML24-45 UML2.3 definition of Classifier::hasVisibilityOf is circular UML 2.3 UML 2.4 Resolved closed
UML24-44 UML2.3: Missing subsetting from A_redefinedClassifier_classifier in XMI UML 2.3 UML 2.4 Resolved closed
UML24-29 loopVariable ownership UML 2.3 UML 2.4 Resolved closed
UML24-95 Association conflicts with MemberEnds IsDerived flags UML 2.3 UML 2.4 Resolved closed
UML24-94 Fix association end multiplicities UML 2.3 UML 2.4 Resolved closed
UML24-98 Multiplicity Element Is MultiValued With Default Value UML 2.3 UML 2.4 Resolved closed
UML24-97 Derived properties that are not marked read-only UML 2.3 UML 2.4 Resolved closed
UML24-89 Message's signature is still derived property (in text only): UML 2.3 UML 2.4 Resolved closed
UML24-88 UML 2 issue: UML 2.4 normative deliverables should be published in MOF2.4 / XMI 2.4 format UML 2.3 UML 2.4 Resolved closed
UML24-96 Redefinition of association-owned ends requires association generalization UML 2.3 UML 2.4 Resolved closed
UML24-93 Fix 14977 vs. 14638 UML 2.3 UML 2.4 Resolved closed
UML24-92 Association-owned association end name changes UML 2.3 UML 2.4 Resolved closed
UML24-87 The resolution to issue 13993 that moved PrimitiveTypes to an independent package contained a mistake UML 2.3 UML 2.4 Resolved closed
UML24-86 Missing subsetting of redefinitionContext by Property::owningAssociation UML 2.3 UML 2.4 Resolved closed
UML24-99 InstanceValue has no type UML 2.3 UML 2.4 Resolved closed
UML24-90 DestructionOccurenceSpecification is inherited from OccurenceSpecification instead of MessageOccurenceSpecification UML 2.3 UML 2.4 Resolved closed
UML24-91 DestructionOccurenceSpecification text in Semantics still refers to events UML 2.3 UML 2.4 Resolved closed
UML24-38 serialization of a profile should always include the nsURI and nsPrefix tags UML 2.3 UML 2.4 Resolved closed
UML24-37 Incomplete resolution to 10826 UML 2.3 UML 2.4 Resolved closed
UML24-31 Definition of Behavior::context is not correct UML 2.3 UML 2.4 Resolved closed
UML24-30 Context of a behavior owned as a nested classifier UML 2.3 UML 2.4 Resolved closed
UML24-32 Matching subsettting across association ends UML 2.3 UML 2.4 Resolved closed
UML24-43 Activity vs Action completion UML 2.3 UML 2.4 Resolved closed
UML24-42 Enumeration Literal UML 2.3 UML 2.4 Resolved closed
UML24-40 Lack of graphical example of multi-element Dependency Notation UML 2.3 UML 2.4 Resolved closed
UML24-39 Poor example of Dependency notation UML 2.3 UML 2.4 Resolved closed
UML24-41 Figure 7.15 UML 2.3 UML 2.4 Resolved closed
UML24-35 The containment between Activity and StructuredActivityNode has one end redefining and the other subsetting UML 2.3 UML 2.4 Resolved closed
UML24-34 UML 2: property redefinitions should be symmetric across associations UML 2.3 UML 2.4 Resolved closed
UML24-33 Expansion nodes using all the tokens in them as a single collection FUML 1.0b2 UML 2.4 Resolved closed
UML24-36 Subsetting clauses should show the subsetted property fully qualified. UML 2.3 UML 2.4 Resolved closed
UML23-145 Semantics of the AddVariableValueAction UML 2.2 UML 2.3b1 Resolved closed
UML24-15 Errros with some "subsets" and redefines" where the contexts of subsetting/redefintion do not conform UML 2.3 UML 2.4 Resolved closed
UML24-14 Attributes without a type UML 2.3 UML 2.4 Resolved closed
UML24-10 UML 2 Events referred to by OccurrenceSpecifications should be optional UML 2.3 UML 2.4 Resolved closed
UML24-13 Associations with same name that live in different packages violate unique name constraint UML 2.3 UML 2.4 Resolved closed
UML24-12 All enumertion literals in the model have their "classifier" collections empty UML 2.3 UML 2.4 Resolved closed
UML24-4 Constraint [3] on TestIdentityAction is incorrect UML 2.3 UML 2.4 Resolved closed
UML24-3 Constraint [1] for WriteStructuralFeatureAction is incorrect UML 2.3 UML 2.4 Resolved closed
UML24-7 UML2 - derivation for DeploymentTarget.deployedElement is invalid UML 2.3 UML 2.4 Resolved closed
UML24-6 UML2 - non-unique association names in L3.merged.cmof UML 2.3 UML 2.4 Resolved closed
UML24-11 Some owned operations with OCL expression bodies but without their "isQuery" set to "true" UML 2.3 UML 2.4 Resolved closed
UML24-8 UML2 - definition of Property.opposite is wrong UML 2.3 UML 2.4 Resolved closed
UML24-5 Parameter type of MultiplicityElement::includesMultiplicity() UML 2.3 UML 2.4 Resolved closed
UML24-9 UML2: Incomplete definition for Activity.structuredNode UML 2.3 UML 2.4 Resolved closed
UML23-143 What is "top-tier packages of the UML metamodel"? UML 2.2 UML 2.3 Resolved closed
UML23-125 Names of ownedEnds that were there in UML 2.1.1 are missing in UML 2.2 UML 2.2 UML 2.3 Resolved closed
UML23-127 notation of objet flow <> and <> UML 2.2 UML 2.3 Resolved closed
UML23-126 UML 2.3 draft, 11.3.1 - AcceptCallAction UML 2.2 UML 2.3 Resolved closed
UML23-124 Duplicate association in normative UML 2.3 superstructure file UML 2.2 UML 2.3 Resolved closed
UML23-123 Japan Infrastructure PAS Ballot Comments - comment 9 UML 2.2 UML 2.3 Resolved closed
UML23-122 Japan Infrastructure PAS Ballot Comments - comment 8 UML 2.2 UML 2.3 Resolved closed
UML23-118 Japan Infrastructure PAS Ballot Comments - comment 4 UML 2.2 UML 2.3 Resolved closed
UML23-117 Japan Infrastructure PAS Ballot Comments - comment 3 UML 2.2 UML 2.3 Resolved closed
UML23-114 Japan Superstructure PAS Ballot Comments - comment 20 UML 2.2 UML 2.3 Resolved closed
UML23-113 Japan Superstructure PAS Ballot Comments - comment 19 UML 2.2 UML 2.3 Resolved closed
UML23-121 Japan Infrastructure PAS Ballot Comments - comment 7 UML 2.2 UML 2.3 Resolved closed
UML23-120 Japan Infrastructure PAS Ballot Comments - comment 6 UML 2.2 UML 2.3 Resolved closed
UML23-116 Japan Infrastructure PAS Ballot Comments - comment 2 UML 2.2 UML 2.3 Resolved closed
UML23-119 Japan Infrastructure PAS Ballot Comments - comment 5 UML 2.2 UML 2.3 Resolved closed
UML23-115 Japan Infrastructure PAS Ballot Comments - comment 1 UML 2.2 UML 2.3 Resolved closed
UML241-12 UML type Real specification UML 2.4 UML 2.4.1 Resolved closed
UML241-11 Interface element - associations multiplicity not defined UML 2.4 UML 2.4.1 Resolved closed
UML241-9 Property::isID UML 2.4 UML 2.4.1 Resolved closed
UML241-6 Wrong package name on several Figures UML 2.4 UML 2.4.1 Resolved closed
UML241-10 Missing Namespace in Dependencies package definition? UML 2.4 UML 2.4.1 Resolved closed
UML241-3 typo on page 46 UML 2.4 UML 2.4.1 Resolved closed
UML24-1 typo in new attribute name UML 2.3 UML 2.4 Resolved closed
UML23-144 Section: Classes RAS 2.2 UML 2.3 Resolved closed
UML24-2 CMOF missing several redefined property relationships UML 2.3 UML 2.4 Resolved closed
UML23-95 Setting Classes-Interfaces-Interface-ownedAttribute would fail to populate Classes-Kernel-Property-owner UML 2.2 UML 2.3 Resolved closed
UML23-94 Incorrect OCL in Infrastructure.xmi for 'Core-Constructs-Operation-isConsistentWith' UML 2.2 UML 2.3 Resolved closed
UML23-99 Japan Superstructure PAS Ballot Comments - comment 4 UML 2.2 UML 2.3 Resolved closed
UML23-98 Japan Superstructure PAS Ballot Comments - comment 3 UML 2.2 UML 2.3 Resolved closed
UML23-93 Language unit of Usage UML 2.2 UML 2.3 Resolved closed
UML23-92 Documentation of merge increments in the superstructure UML 2.2 UML 2.3 Resolved closed
UML23-97 Japan Superstructure PAS Ballot Comments - comment 2 UML 2.2 UML 2.3 Resolved closed
UML23-96 Japan Superstructure PAS Ballot Comments - comment 1 UML 2.2 UML 2.3 Resolved closed
UML24-23 is composite, but does not subset ownedElement UML 2.3 UML 2.4 Resolved closed
UML24-22 wrong Actor's constraint [1]" UML 2.3 UML 2.4 Resolved closed
UML24-20 AcceptEventAction notation UML 2.3 UML 2.4 Resolved closed
UML24-19 Some associations in the normative XMI has one memberEnd UML 2.3 UML 2.4 Resolved closed
UML24-18 Namespace collission due to package import UML 2.3 UML 2.4 Resolved closed
UML24-17 Cycles in package imports UML 2.3 UML 2.4 Resolved closed
UML24-16 Errors with types of association ends not conforming to their subsetted ends UML 2.3 UML 2.4 Resolved closed
UML24-28 Unclear constraint on stereotype associations UML 2.3 UML 2.4 Resolved closed
UML24-26 remove BehavioredClassifier::ownedTrigger UML 2.3 UML 2.4 Resolved closed
UML24-25 lowered multiplicity UML 2.3 UML 2.4 Resolved closed
UML24-21 Issue on generalization UML 2.3 UML 2.4 Resolved closed
UML24-24 is composite and subsets not derived composite property: UML 2.3 UML 2.4 Resolved closed
UML24-27 UML is vague about which Element should own Comments UML 2.3 UML 2.4 Resolved closed
UML23-129 UML 2.3: Errors in example serialization for Profiles in Chapter 18 UML 2.2 UML 2.3 Resolved closed
UML23-128 errors in OCL statements of Additional Operations? UML 2.2 UML 2.3 Resolved closed
UML23-132 Value of a Property UML 2.2 UML 2.3 Resolved closed
UML23-131 Interface-redefinedInterface should subset Classifier-redefinedClassifier UML 2.2 UML 2.3 Resolved closed
UML23-142 'false' is not a member of VisibilityKind UML 2.2 UML 2.3 Resolved closed
UML23-141 Guard of activity edge should be optional UML 2.2 UML 2.3 Resolved closed
UML23-140 Bug in Core::Abstractions::Super::Classifier::hasVisibilityOf UML 2.2 UML 2.3 Resolved closed
UML23-130 Ordered derived unions UML 2.2 UML 2.3 Resolved closed
UML23-135 Package Extension UML 2.2 UML 2.3 Resolved closed
UML23-134 Wrong Spelling for "development" UML 2.2 UML 2.3 Resolved closed
UML23-133 Cyclick dependency UML 2.2 UML 2.3 Resolved closed
UML23-138 Invalid type for NamedElement.namespace UML 2.2 UML 2.3 Resolved closed
UML23-137 Invalid type for Slot.value UML 2.2 UML 2.3 Resolved closed
UML23-139 Minor bug in Namespace::importMembers() query UML 2.2 UML 2.3 Resolved closed
UML23-136 Contents of Dependencies package UML 2.2 UML 2.3 Resolved closed
UML23-101 Japan Superstructure PAS Ballot Comments - comment 6 UML 2.2 UML 2.3 Resolved closed
UML23-100 Japan Superstructure PAS Ballot Comments - comment 5 UML 2.2 UML 2.3 Resolved closed
UML23-109 Japan Superstructure PAS Ballot Comments - comment 15 UML 2.2 UML 2.3 Resolved closed
UML23-105 Japan Superstructure PAS Ballot Comments - comment 11 UML 2.2 UML 2.3 Resolved closed
UML23-104 Japan Superstructure PAS Ballot Comments - comment 10 UML 2.2 UML 2.3 Resolved closed
UML23-111 Japan Superstructure PAS Ballot Comments - comment 17 UML 2.2 UML 2.3 Resolved closed
UML23-110 Japan Superstructure PAS Ballot Comments - comment 16 UML 2.2 UML 2.3 Resolved closed
UML23-102 Japan Superstructure PAS Ballot Comments - comment 7 UML 2.2 UML 2.3 Resolved closed
UML23-107 Japan Superstructure PAS Ballot Comments - comment 13 UML 2.2 UML 2.3 Resolved closed
UML23-106 Japan Superstructure PAS Ballot Comments - comment 12 UML 2.2 UML 2.3 Resolved closed
UML23-103 Japan Superstructure PAS Ballot Comments - comment 8 UML 2.2 UML 2.3 Resolved closed
UML23-108 Japan Superstructure PAS Ballot Comments - comment 14 UML 2.2 UML 2.3 Resolved closed
UML23-112 Japan Superstructure PAS Ballot Comments - comment 18 UML 2.2 UML 2.3 Resolved closed
UML241-22 Irritating occurrence of subsystem stereotype in use case example diagrams UML 2.4 UML 2.4.1 Resolved closed
UML241-21 UML 2.4: NamedElement.ownedRule could be ordered UML 2.4 UML 2.4.1 Resolved closed
UML241-19 property.opposite UML 2.4 UML 2.4.1 Resolved closed
UML241-18 ProfileApplication::appliedProfile as "importedProfile" instead of "appliedProfile" UML 2.4 UML 2.4.1 Resolved closed
UML241-25 ChangeEvent::changeExpression should be of type ValueSpecification UML 2.4 UML 2.4.1 Resolved closed
UML241-24 Validity duration of implicitly assigned parameters in SignalEvent/CallEvent UML 2.4 UML 2.4.1 Resolved closed
UML241-17 XMI in small caps UML 2.4 UML 2.4.1 Resolved closed
UML241-16 Core Package versus Construct Package UML 2.4 UML 2.4.1 Resolved closed
UML241-20 UML Appendix A : Figure A.3 Two Diagrams of Packages” UML 2.4 UML 2.4.1 Resolved closed
UML241-15 XML Metadata Interchange (XMI) - p9 UML 2.4 UML 2.4.1 Resolved closed
UML241-14 XML Metadata Interchange (XMI) UML 2.4 UML 2.4.1 Resolved closed
UML241-23 Implicit parameter assignment may cause name clashes UML 2.4 UML 2.4.1 Resolved closed
UML241-13 Number of Compliance Levels UML 2.4 UML 2.4.1 Resolved closed
UML241-2 Presentation options of statemachine transitions: Figure 15.45 is ambiguous or wrong UML 2.4 UML 2.4.1 Resolved closed
UML241-1 Can a Generalization really be in multiple GeneralizationSets? UML 2.4 UML 2.4.1 Resolved closed
UML241-5 No Rules for Element Names UML 2.4 UML 2.4.1 Resolved closed
UML241-4 Figure 15.32 UML 2.4 UML 2.4.1 Resolved closed
UML241-8 Figure 15.32 UML 2.4 UML 2.4.1 Resolved closed
UML241-7 Typo: "joint" should say "join" UML 2.4 UML 2.4.1 Resolved closed
UML22-1141 Section: Activities: Modifications to the approved resolution of 10815 SysML 1.0 UML 2.1.2 Resolved closed
UML22-1122 Diagram metaclass shall be introduced and shall be subclass of Element UML 2.1 UML 2.1.2 Resolved closed
UML22-1121 Setting structural features of a data type UML 2.1 UML 2.1.2 Resolved closed
UML22-1124 Figure 7.14: "Type" does not show its inheritance from "PackageableElement" UML 2.1 UML 2.1.2 Resolved closed
UML22-1123 ConnectorEnd shall have references to provided or required interfaces UML 2.1 UML 2.1.2 Resolved closed
UML22-1134 constraining Classifiers UML 2.1.1 UML 2.1.2 Resolved closed
UML22-1133 defaultClassifier of ClassifierTemplateParameter SysML 1.0 UML 2.1.2 Resolved closed
UML22-1129 Section: 9.3.11 p 182 UML 2.1.1 UML 2.1.2 Resolved closed
UML22-1128 Wrong notation description SysML 1.0 UML 2.1.2 Resolved closed
UML22-1127 Section: 9.3.8 UML 2.1.1 UML 2.1.2 Resolved closed
UML22-1126 page 449 chapter 13.3.24 (Signal (from Communications) SysML 1.0 UML 2.1.2 Resolved closed
UML22-1125 UML 2 superstructure -- figure 9.4 is duplicate of figure 9.3 SysML 1.0 UML 2.1.2 Resolved closed
UML22-1136 Change multiplicity of ClassifierTemplateParameter role UML 2.1.1 UML 2.1.2 Resolved closed
UML22-1135 Any ownedBehavior should be able to have AcceptEventAction UML 2.1.1 UML 2.1.2 Resolved closed
UML22-1132 composite values SysML 1.0 UML 2.1.2 Resolved closed
UML22-1131 Section: 9 composite structures SysML 1.0 UML 2.1.2 Resolved closed
UML22-1130 "representation" SysML 1.0 UML 2.1.2 Resolved closed
UML22-1138 TimeEvent UML 2.1.1 UML 2.1.2 Resolved closed
UML22-1137 Figure 14.5 - Messages. UML 2.1.1 UML 2.1.2 Resolved closed
UML22-1140 Section: 7.3.7 UML 2.1.1 UML 2.1.2 Resolved closed
UML22-1139 Figures 9.4 identical to figure 9.3 UML 2.1.1 UML 2.1.2 Resolved closed
UML22-1120 Flowing data into decision input behaviors UML 2.1 UML 2.1.2 Resolved closed
UML22-1119 Section: Composite Structures UML 2.1.1 UML 2.1.2 Resolved closed
UML22-1107 issue regarding required and provided interfaces UML 2.1 UML 2.1.2 Resolved closed
UML22-1106 UML 2: Semantics of isOrdered need to be clarified UML 2.1 UML 2.1.2 Resolved closed
UML22-1118 Ptc/06-04-02/Pg 188 UML 2.1 UML 2.1.2 Resolved closed
UML22-1117 Section: 7.3.32 UML 2.1.1 UML 2.1.2 Resolved closed
UML22-1116 A notation for Trigger UML 2.1 UML 2.1.2 Resolved closed
UML22-1102 Section: Activities - Action semantic clarification UML 2.1.1 UML 2.1.2 Resolved closed
UML22-1101 Section: Activities -StartClassifeirBehaviorAction and classifier behaviors UML 2.1.1 UML 2.1.2 Resolved closed
UML22-1100 Section: Activities - isSingleExecution default UML 2.1.1 UML 2.1.2 Resolved closed
UML22-1105 Profile Structure Diagrams are missing from Annex A SysML 1.0b1 UML 2.1.2 Resolved closed
UML22-1104 Missing inheritance in 9.3.12 SysML 1.0b1 UML 2.1.2 Resolved closed
UML22-1103 No default value specified for Generalization::isSubstitutable SysML 1.0b1 UML 2.1.2 Resolved closed
UML22-1115 consistent descriptions of semantics of event consumption needed UML 2.1 UML 2.1.2 Resolved closed
UML22-1114 section 13.3.2 – doc ptc/2006-04-02, v.2.1 UML 2.1 UML 2.1.2 Resolved closed
UML22-1113 Uses notation "Subsets Element::ownedElement" and similar UML 2.1.1 UML 2.1.2 Resolved closed
UML22-1112 UML2: Behavior without a specification should not be a classifier behavior UML 2.1 UML 2.1.2 Resolved closed
UML22-1109 Figure 13.8 shows the wrong diagram UML 2.1 UML 2.1.2 Resolved closed
UML22-1108 Section: 13.3.25 UML 2.1 UML 2.1.2 Resolved closed
UML22-1111 Section: 13 SimpleTime UML 2.1.1 UML 2.1.2 Resolved closed
UML22-1110 Section: 13.2 UML 2.1 UML 2.1.2 Resolved closed
UML22-1084 UML2: No notation for BehavioredClassifier::ownedTrigger UML 2.0 UML 2.1.2 Resolved closed
UML22-1083 UML 2/Templates -- single argument? UML 2.0 UML 2.1.2 Resolved closed
UML22-1082 Use the new 'dot' notation in examples UML 2.0 UML 2.1.2 Resolved closed
UML22-1099 Section: Activities - Join node edge constraint UML 2.1.1 UML 2.1.2 Resolved closed
UML22-1098 Section: Activities - Offer ordering on joins UML 2.1.1 UML 2.1.2 Resolved closed
UML22-1097 Section: Activities - Multiple activity parameters nodes for a single inout UML 2.1.1 UML 2.1.2 Resolved closed
UML22-1088 A notation for Trigger SysML 1.0b1 UML 2.1.2 Resolved closed
UML22-1087 Section: 9.3.13 - connectors UML 2.1 UML 2.1.2 Resolved closed
UML22-1096 Section: Activities - Semantics of fork node wording UML 2.1.1 UML 2.1.2 Resolved closed
UML22-1095 ReadLinkAction UML 2.1.1 UML 2.1.2 Resolved closed
UML22-1094 Section: Activities - Weight notation UML 2.1.1 UML 2.1.2 Resolved closed
UML22-1093 Section: Activities - Weight description UML 2.1.1 UML 2.1.2 Resolved closed
UML22-1092 Section: Activities UML 2.1.1 UML 2.1.2 Resolved closed
UML22-1091 Section: 9.3.11 UML 2.1.1 UML 2.1.2 Resolved closed
UML22-1090 Section: 9.3.11 UML 2.1.1 UML 2.1.2 Resolved closed
UML22-1089 Section: 9.2 UML 2.1.1 UML 2.1.2 Resolved closed
UML22-1086 Section: 13.3.24 Signal (from Communications) UML 2.1.1 UML 2.1.2 Resolved closed
UML22-1085 page 467, Section 13.3.24 UML 2.0 UML 2.1.2 Resolved closed
UML23-53 Figure 18.15 does not reflect the example before UML 2.2 UML 2.3 Resolved closed
UML23-52 The XMI document contains elements which should be UML 2.2 UML 2.3 Resolved closed
UML23-47 chapter 2.2, p.3 Last paragaph, second sentence UML 2.2 UML 2.3 Resolved closed
UML23-46 "Associations" part of the "9.10.3 Slot" chapter/section UML 2.2 UML 2.3 Resolved closed
UML23-44 In paragraph 4, the text should read "Class has a derived association ...". Currently, the sentence is missing "a". UML 2.2 UML 2.3 Resolved closed
UML23-43 In paragraph 2, the package reference to InfrastructureLibrary::Constructs::Class omits intermediate package "Core" UML 2.2 UML 2.3 Resolved closed
UML23-50 18.3.6 Typo in Profile section UML 2.2 UML 2.3 Resolved closed
UML23-49 Section: Fig. 7.15: subsets at wrong side UML 2.2 UML 2.3 Resolved closed
UML23-41 Figure 13.2 shows class InfrastructureLibrary::Profiles::Element. Section 13 doesn't define a class named Element. UML 2.2 UML 2.3 Resolved closed
UML23-42 Figure 13.2 shows an association between ProfileApplication and Profile that has role "appliedProfile UML 2.2 UML 2.3 Resolved closed
UML23-48 Section: Chapter 2.2 Compliance levels UML 2.2 UML 2.3 Resolved closed
UML23-45 In the Attributes section, "integer" should be capitalized UML 2.2 UML 2.3 Resolved closed
UML23-51 Section: 18.3.2 UML 2.2 UML 2.3 Resolved closed
UML23-23 UML 2.2 Profiles Issue: Stereotypes extending multiple metaclasses are ill-formed as metamodel equivalents UML 2.2 UML 2.3 Resolved closed
UML23-17 UML 2: conflicting specifications for how to calculate context for a Behavior UML 2.2 UML 2.3 Resolved closed
UML23-16 use of "internal" transition is used incorrectly in many places where "local" should be used. UML 2.2 UML 2.3 Resolved closed
UML23-18 default multiplicty of association ends are defined more than one UML 2.2 UML 2.3 Resolved closed
UML23-25 Section: 7.4 Diagrams text on page 144 UML 2.2 UML 2.3 Resolved closed
UML23-24 UML 2.2 Beta1 Figure 12.18 is misleading about Parameter::effect : ParameterEffectKind [0..1] UML 2.2 UML 2.3 Resolved closed
UML23-28 Figure 12.95 - "Fork node example" UML 2.2 UML 2.3 Resolved closed
UML23-27 UML2 : Lifeline identity for InteractionUse UML 2.2 UML 2.3 Resolved closed
UML23-22 In the XMI, Ownerships::Element erroneously includes an association for ownedComment. UML 2.2 UML 2.3 Resolved closed
UML23-21 In the XMI, Ownerships::Element fails to include a superClass attribute for Elements::Element UML 2.2 UML 2.3 Resolved closed
UML23-20 Section: 9.8.3 XMI fails to include a "lower" attribute UML 2.2 UML 2.3 Resolved closed
UML23-19 The UML XMI fails to include an ownedRule for the Constraint specified for an OpaqueExpression UML 2.2 UML 2.3 Resolved closed
UML23-26 "Table 7.3 - Graphic paths included in structure diagrams" on pp.143-144 UML 2.2 UML 2.3 Resolved closed
UML23-15 Statemachine diagram in section 15.3.12 diagram 15.42 (and the text above) UML 2.2 UML 2.3 Resolved closed
UML23-88 Propagate RTF 2.3 changes to Infrastructure UML 2.2 UML 2.3 Resolved closed
UML23-87 Need to copy down merged content to make constraints parse in receiving package UML 2.2 UML 2.3 Resolved closed
UML23-86 Remove InputPint from StructuredActivities UML 2.2 UML 2.3 Resolved closed
UML23-85 BNF of Constructs::Property UML 2.2 UML 2.3 Resolved closed
UML23-84 Ambiguity in the names of the stereotypes in the standard profiles UML 2.2 UML 2.3 Resolved closed
UML23-91 The primitive types in the UML 2.3 infrastructure.xmi are private; they should be public UML 2.2 UML 2.3 Resolved closed
UML23-90 Difference between OCL and text in constraint [2] of 15.3.15 UML 2.2 UML 2.3 Resolved closed
UML23-89 Remove redundantant constraint [2] in 7.3.4 UML 2.2 UML 2.3 Resolved closed
UML23-73 UML 2.2 Issue - availability of PrimitiveTypes for UML models UML 2.2 UML 2.3 Resolved closed
UML23-72 lowerBound/upperBound constraints and derivations wrong UML 2.2 UML 2.3 Resolved closed
UML23-81 UML2: Missing semantics in definition of RedefinableTemplateSignature with multiple parents UML 2.2 UML 2.3 Resolved closed
UML23-80 remove StructuredActivities::ActivityGroup UML 2.2 UML 2.3 Resolved closed
UML23-83 Profile::allOwningPackages UML 2.2 UML 2.3 Resolved closed
UML23-82 Properties need not be owned UML 2.2 UML 2.3 Resolved closed
UML23-71 Operation-interface should subset Feature-featuringClassifier and NamedElement-namespace UML 2.2 UML 2.3 Resolved closed
UML23-70 UML2.2 chapter 16 : Actor constraint [1] has invalid OCL UML 2.2 UML 2.3 Resolved closed
UML23-76 UML2: error in definition of Class::nestedClassifier UML 2.2 UML 2.3 Resolved closed
UML23-75 confusion re diagram on p. 83 UML 2.2 UML 2.3 Resolved closed
UML23-79 Currently is it possible for a Classifier to specialize the same classifier directly more than once UML 2.2 UML 2.3 Resolved closed
UML23-77 nestedClassifier UML 2.2 UML 2.3 Resolved closed
UML23-74 Section 9.9 should classifier be added to the diagram on p 50? UML 2.2 UML 2.3 Resolved closed
UML23-78 type mismatch UML 2.2 UML 2.3 Resolved closed
UML23-32 Section 12.3.48 on page 412 UML 2.2 UML 2.3 Resolved closed
UML23-34 Figure 7.1 shows no dependency UML 2.2 UML 2.3 Resolved closed
UML23-33 Section 2.3 para 1 needs to be re-written UML 2.2 UML 2.3 Resolved closed
UML23-40 Section 13 "Core::Profiles" inconsistency UML 2.2 UML 2.3 Resolved closed
UML23-39 Should the definition of Element state that it reuses the definition of Element from Abstractions::Elements? UML 2.2 UML 2.3 Resolved closed
UML23-37 The "Generalizations" heading is missing before the "ValueSpecification" bullet. UML 2.2 UML 2.3 Resolved closed
UML23-36 Paragraph 5: The text states that class Comment has no generalizations UML 2.2 UML 2.3 Resolved closed
UML23-31 UML 2 7.3.3 : incorrect text about aggregationKind in associations UML 2.2 UML 2.3 Resolved closed
UML23-29 Table 12.1 - "Graphic nodes included in activity diagrams", UML 2.2 UML 2.3 Resolved closed
UML23-30 Generalizations" for StructuredActivityNode on p. 417 UML 2.2 UML 2.3 Resolved closed
UML23-38 Two issues regarding Figure 10.2: 1 UML 2.2 UML 2.3 Resolved closed
UML23-35 Parameter is part of the BehavioralFeatures package. UML 2.2 UML 2.3 Resolved closed
UML23-65 Validator issues with TestCase 2 UML 2.2 UML 2.3 Resolved closed
UML23-64 current definition of a 'local' transition does not allow the case to have a local transition UML 2.2 UML 2.3 Resolved closed
UML23-59 Figures 9.17 and 9.19 and related text UML 2.2 UML 2.3 Resolved closed
UML23-58 what's the difference > between weight=1 and weight=*? UML 2.2 UML 2.3 Resolved closed
UML23-63 Clarify that input pins do not accept more tokens than their actions can immediately consume UML 2.2 UML 2.3 Resolved closed
UML23-62 The OCL for /required interfaces of Component is using ports.provided instead of ports.required UML 2.2 UML 2.3 Resolved closed
UML23-67 Clarification need on circle plus notation for containment UML 2.2 UML 2.3 Resolved closed
UML23-66 Color errors on figures in UML 2.2 UML 2.2 UML 2.3 Resolved closed
UML23-69 Figure 7.38 needs to be revised UML 2.2 UML 2.3 Resolved closed
UML23-68 Activity groups should be named UML 2.2 UML 2.3 Resolved closed
UML23-57 Table 2.2 Example feature support statement references Note (4) and Note (5) UML 2.2 UML 2.3 Resolved closed
UML23-56 Description of Level 1 diagram does not make sense with respect to figure 2.2 UML 2.2 UML 2.3 Resolved closed
UML23-61 Clarify how the provided and required interfaces of a Port are calculated UML 2.2 UML 2.3 Resolved closed
UML23-60 Missing keyword? UML 2.2 UML 2.3 Resolved closed
UML23-54 Replace "extensionClock" with "extension_Clock" and "baseClass" with "base_Class" UML 2.2 UML 2.3 Resolved closed
UML23-55 URIs do not refer to existing resources (404 errors) Annex H UML 2.2 UML 2.3 Resolved closed
UML23-14 Section: 14.3.13 Interaction (from BasicInteraction, Fragments) UML 2.2 UML 2.3 Resolved closed
UML23-13 Notation for ExecutionSpecification UML 2.2 UML 2.3 Resolved closed
UML23-6 Section: 7.3.39 PackageImport (from Kernel) UML 2.2 UML 2.3 Resolved closed
UML23-5 Section: 7.3.12 Dependency (from Dependencies) UML 2.2 UML 2.3 Resolved closed
UML23-11 Val(MyCar.Interaction [SVWB UML 2.2 UML 2.3 Resolved closed
UML23-10 Section: 12.3.14 Figure 12.29 on page 320 UML 2.2 UML 2.3 Resolved closed
UML23-8 Section: 14.3.24 MessageSort (from BasicInteractions) UML 2.2 UML 2.3 Resolved closed
UML23-7 Section: 14.3.3 CombinedFragment (from Fragments) UML 2.2 UML 2.3 Resolved closed
UML23-9 "description" section of the Behavior metaclass UML 2.2 UML 2.3 Resolved closed
UML23-2 Parameter isn't package (Heading 2 level) UML 2.2 UML 2.3 Resolved closed
UML23-1 Super package should import NamedElement from the Visibilities package, not Namespaces UML 2.2 UML 2.3 Resolved closed
UML23-12 description of Interaction provided by the Semantic section inconsistent UML 2.2 UML 2.3 Resolved closed
UML23-4 Section: 14.3.20 Actors in Interactions UML 2.2 UML 2.3 Resolved closed
UML23-3 Figure 9.20 UML 2.2 UML 2.3 Resolved closed
UML22-1081 UML 2 Superstructure / CommonBehaviors / Incorrect types in text UML 2.0 UML 2.1.2 Resolved closed
UML22-1080 7.3.41 Parameter (from Kernel, AssociationClasses)" UML 2.0 UML 2.1.2 Resolved closed
UML22-1063 UML 2.0 issue: ownedMember xsi:type="uml:Stereotype" should be used UML 2.0 UML 2.1 Resolved closed
UML22-1062 UML 2.0: CMOF/UML mixup for profiles UML 2.0 UML 2.1 Resolved closed
UML22-1069 Required attributes UML 2.0 UML 2.1 Resolved closed
UML22-1068 Parameter::effect UML 2.0 UML 2.1 Resolved closed
UML22-1065 UML 2.1 XMI Issue UML 2.0 UML 2.1 Resolved closed
UML22-1064 UML 2.0: Inconsistencies in profile example XMI UML 2.0 UML 2.1 Resolved closed
UML22-1073 parameter of operation isRedefinitionContextValid() is inconistently named UML 2.0 UML 2.1 Resolved closed
UML22-1072 Compliance package L2 does not merge StructuredActions in the metamodel UML 2.0 UML 2.1 Resolved closed
UML22-1071 The following properties should not subset DirectedRelationship::target UML 2.0 UML 2.1 Resolved closed
UML22-1070 The following properties should not subset DirectedRelationship::source UML 2.0 UML 2.1 Resolved closed
UML22-1067 Artifact::fileName UML 2.0 UML 2.1 Resolved closed
UML22-1066 uml::Extension::ownedEnd should not subset uml::Association::ownedEnd UML 2.0 UML 2.1 Resolved closed
UML22-1079 Figure 12.18: Small typo: "subsets ownedMember" not "ownedmember" UML 2.0 UML 2.1.2 Resolved closed
UML22-1078 Page: 161 UML 2.0 UML 2.1.2 Resolved closed
UML22-1075 Issue regarding "Action::effect : String" UML 1.3 UML 2.1 Resolved closed
UML22-1074 Transition guards cannot currently be evaluated because they have no contex UML 2.0 UML 2.1 Resolved closed
UML22-1077 StateMachine::extendedStateMachine should have a multiplicity of 0..*. UML 2.0 UML 2.1 Resolved closed
UML22-1076 Behavior::context UML 2.0 UML 2.1 Resolved closed
UML22-1058 UML 2.0 issue: Package Primitive Types not merged UML 2.0 UML 2.1 Resolved closed
UML22-1057 Section: Appendix A: Diagrams UML 2.0 UML 2.1.2 Resolved closed
UML22-1056 Section 7.2.1 of ptc/04-10-14 UML 2.0 UML 2.1.2 Resolved closed
UML22-1055 Section: 7.3.36 Operation UML 2.0 UML 2.1.2 Resolved closed
UML22-1054 Section 8 Issue - Component Realization-Classifier multiplicity UML 2.0 UML 2.1.2 Resolved closed
UML22-1053 Section: Actions, Figure 156 UML 2.0 UML 2.1 Resolved closed
UML22-1052 UML 2.1 Regressions UML 2.0 UML 2.1 Resolved closed
UML22-1051 Realization classifier UML 2.0 UML 2.1 Resolved closed
UML22-1050 UML 2 issue: redefining isComposite on association ends UML 2.0 UML 2.1 Resolved closed
UML22-1049 Classifier::parameter, Operation::parameter, and ConnectableElement::parame UML 2.0 UML 2.1 Resolved closed
UML22-1048 Component::realization should NOT be derived UML 2.0 UML 2.1 Resolved closed
UML22-1047 Rename ActivityGroup::activity to containingActivity UML 2.0 UML 2.1 Resolved closed
UML22-1046 Rename OpaqueAction::output to outputPin. UML 2.0 UML 2.1 Resolved closed
UML22-1045 Make ActivityGroup::containedNode a derived union UML 2.0 UML 2.1 Resolved closed
UML22-1044 Make ActivityGroup::containedEdge a derived union UML 2.0 UML 2.1 Resolved closed
UML22-1039 compliance levels L2 and L3 UML 2.0 UML 2.1 Resolved closed
UML22-1038 Change type of WriteStructuralFeatureAction::value to ValueSpecification UML 2.0 UML 2.1 Resolved closed
UML22-1037 Change type of WriteStructuralFeatureAction::value UML 2.0 UML 2.1 Resolved closed
UML22-1061 UML 2.0: separate profile application from profile importing UML 2.0 UML 2.1 Resolved closed
UML22-1060 UML 2.0: invalid package merge diagrams for compliance points UML 2.0 UML 2.1 Resolved closed
UML22-1059 UML 2.0 issue: Profile::ownedStereotype should be derived UML 2.0 UML 2.1 Resolved closed
UML22-1043 Rename LinkAction::input to inputPin UML 2.0 UML 2.1 Resolved closed
UML22-1042 Rename OpaqueAction::input to inputPin UML 2.0 UML 2.1 Resolved closed
UML22-1041 Rename InformationFlow::source UML 2.0 UML 2.1 Resolved closed
UML22-1040 Rename InformationFlow::target UML 2.0 UML 2.1 Resolved closed
UML22-1036 Rename ActivityPartition::subgroup to subpartition UML 2.0 UML 2.1 Resolved closed
UML22-1035 Replace {redefines redefinedElement} UML 2.0 UML 2.1 Resolved closed
UML22-1034 Replace {redefines redefinedElement} UML 2.0 UML 2.1 Resolved closed
UML22-1033 Replace {redefines redefinedElement} UML 2.0 UML 2.1 Resolved closed
UML22-1026 body expression for Property::isConsistentWith(RedefinableElement) UML 2.0 UML 2.1 Resolved closed
UML22-1025 following imports from merged packages to unmerged packages should be remov UML 2.0 UML 2.1 Resolved closed
UML22-1024 UML2 Superstructure Fig 2.2 Incomplete UML 2.0 UML 2.1 Resolved closed
UML22-1023 Section: 14.4 UML 2.0 UML 2.1 Resolved closed
UML22-1020 Section: Common Behaviors UML 2.0 UML 2.1.2 Resolved closed
UML22-1019 Section: Actions UML 2.0 UML 2.1.2 Resolved closed
UML22-1022 7.3.22 InstanceSpecification UML 2.0 UML 2.1 Resolved closed
UML22-1021 Section: Activities UML 2.0 UML 2.1 Resolved closed
UML22-1018 Section: Classes UML 2.0 UML 2.1.2 Resolved closed
UML22-1017 Section: Activities UML 2.0 UML 2.1 Resolved closed
UML22-1016 Invalid stereotype in StandardProfile UML 2.0 UML 2.1 Resolved closed
UML22-1015 UML 2 Super / miscellaneous figure-text discrepancies UML 2.0 UML 2.1 Resolved closed
UML22-1028 Rename Package::ownedMember UML 2.0 UML 2.1 Resolved closed
UML22-1027 Rename Constraint::namespace UML 2.0 UML 2.1 Resolved closed
UML22-1030 Rename ActivityEdge::redefinedElement UML 2.0 UML 2.1 Resolved closed
UML22-1029 Rename Component::ownedMember UML 2.0 UML 2.1 Resolved closed
UML22-1032 Replace {redefines redefinedElement} UML 2.0 UML 2.1 Resolved closed
UML22-1031 Rename ActivityNode::redefinedElement UML 2.0 UML 2.1 Resolved closed
UML22-1012 Section: 6.5 UML 2.0 UML 2.1.2 Resolved closed
UML22-1011 UML2 should specify default property ownership for association ends UML 2.0 UML 2.1 Resolved closed
UML22-1002 Figure 430 references invalid metaclass UML 2.0 UML 2.1 Resolved closed
UML22-1001 Section: 9.3.5 UML 2.0 UML 2.1.2 Resolved closed
UML22-1006 UML2 Navigability Impact on Tools UML 2.0 UML 2.1 Resolved closed
UML22-1005 UML 2 XMI DTD requirement UML 2.0 UML 2.1 Resolved closed
UML22-998 UML2 issue: {unrestricted} described in text but not BNF UML 2.0 UML 2.1 Resolved closed
UML22-997 UML Superstructure / Actions / Missing package heading UML 2.0 UML 2.1 Resolved closed
UML22-1010 UML 2 Super / Undocumented properties UML 2.0 UML 2.1 Resolved closed
UML22-1009 Page: 591,592 UML 2.0 UML 2.1 Resolved closed
UML22-1008 Core::Constructs::Operation UML 2.0 UML 2.1.2 Resolved closed
UML22-1007 Interaction::lifeline should be ordered UML 2.0 UML 2.1.2 Resolved closed
UML22-1004 UML 2 Classes Notation for association end ownership UML 2.0 UML 2.1 Resolved closed
UML22-1003 connection point reference UML 2.0 UML 2.1 Resolved closed
UML22-1014 UML 2 Super / Collaboration use issues (02) UML 2.0 UML 2.1 Resolved closed
UML22-1013 UML 2 Super / Collaboration use issues (01) UML 2.0 UML 2.1 Resolved closed
UML22-1000 Section: 12.3.18 and 12.3.35 UML 2.0 UML 2.1 Resolved closed
UML22-999 Section: 15.3.14 UML 2.0 UML 2.1 Resolved closed
UML22-987 p. 732: Show examples of new stereotype notation RAS 2.2 UML 2.1 Resolved closed
UML22-986 p. 732: Change example to be consistent with new definition of Clock RAS 2.2 UML 2.1 Resolved closed
UML22-994 Section: 12.3.5 UML 2.0 UML 2.1 Resolved closed
UML22-993 Page: 163 UML 2.0 UML 2.1 Resolved closed
UML22-983 Make instance model consistent with new definition of Clock RAS 2.2 UML 2.1 Resolved closed
UML22-982 p. 729: Extend the Clock example to show metaclass property RAS 2.2 UML 2.1 Resolved closed
UML22-985 p. 731: Make example consistent with new definition of Clock. RAS 2.2 UML 2.1 Resolved closed
UML22-984 p. 731: Make this example consistent with the new definition of Clock RAS 2.2 UML 2.1 Resolved closed
UML22-989 Section: 12.3.37 ObjectFlow UML 2.0 UML 2.1 Resolved closed
UML22-996 UML Superstructure / Actions / incorrect form for subsetting UML 2.0 UML 2.1 Resolved closed
UML22-995 Section: 12.3.9 UML 2.0 UML 2.1 Resolved closed
UML22-988 pp. 733-734: Add association as valid graphic path RAS 2.2 UML 2.1 Resolved closed
UML22-991 TimeExpression RAS 2.2 UML 2.1 Resolved closed
UML22-990 OpaqueAction UML 2.0 UML 2.1 Resolved closed
UML22-992 abstract Action in Activity diagram RAS 2.2 UML 2.1 Resolved closed
UML22-981 p. 728: New presentation options. Replace the following paragraph RAS 2.2 UML 2.1 Resolved closed
UML22-980 p. 721: Allow stereotypes to have properties that are typed by metaclasses RAS 2.2 UML 2.1 Resolved closed
UML22-968 Can't specify mutator semantics for derived properties RAS 2.2 UML 2.1 Resolved closed
UML22-967 Section: 12.3.37 RAS 2.2 UML 2.1 Resolved closed
UML22-976 MessageEnd RAS 2.2 UML 2.1 Resolved closed
UML22-975 ExecutableNode should be abstract in Figure 195. It is in Figure 197. UML 2.0 UML 2.1 Resolved closed
UML22-979 Section: 12 and 13 UML 2.0 UML 2.1 Resolved closed
UML22-978 Incorrect Communication Domain Model RAS 2.2 UML 2.1 Resolved closed
UML22-977 Obsolete term EventOccurrence still used in multiple places RAS 2.2 UML 2.1 Resolved closed
UML22-972 Notation of Attributes and Associations subsections RAS 2.2 UML 2.1.2 Resolved closed
UML22-971 Page: 330 UML 2.0 UML 2.1.2 Resolved closed
UML22-970 Section: 11.3.48 UML 2.0 UML 2.1 Resolved closed
UML22-969 Section: Actions UML 2.0 UML 2.1 Resolved closed
UML22-974 Actions should be able to overlap partitions, to support multiple participa UML 2.0 UML 2.1 Resolved closed
UML22-973 Section: 8.3.1 Page: 156 ff UML 2.0 UML 2.1.2 Resolved closed
UML22-966 OpaqueAction RAS 2.2 UML 2.1 Resolved closed
UML22-965 Page: 591 UML 2.0 UML 2.1 Resolved closed
UML22-961 Clarify caption of Figure 56 UML 2.0 UML 2.1 Resolved closed
UML22-960 Section: Interactions UML 2.0 UML 2.1 Resolved closed
UML22-953 Clarify first constraint on InputPin and OutputPin, move "only" to before " UML 2.0 UML 2.1 Resolved closed
UML22-952 LoopNode should move rather than copy values to/from loop variables UML 2.0 UML 2.1 Resolved closed
UML22-951 In Figure 210, put merge before Use Part to merge the incoming flows UML 2.0 UML 2.1 Resolved closed
UML22-950 Exceptions thrown across synchronous invocations UML 2.0 UML 2.1 Resolved closed
UML22-949 Multiple exception handlers UML 2.0 UML 2.1 Resolved closed
UML22-955 Actions, CallBehaviorAction, third sentence, UML 2.0 UML 2.1 Resolved closed
UML22-954 The Syle Guidelines for Stereotype UML 2.0 UML 2.1 Resolved closed
UML22-959 CollaborationUse: Constraint 1, UML 2.0 UML 2.1.2 Resolved closed
UML22-958 ConditionalNode and LoopNode test and bodies should be ExecutableNodes UML 2.0 UML 2.1 Resolved closed
UML22-957 ExpansionRegion UML 2.0 UML 2.1 Resolved closed
UML22-956 ControlFlow UML 2.0 UML 2.1 Resolved closed
UML22-964 Last element in transition BNF UML 2.0 UML 2.1 Resolved closed
UML22-962 Notation for connector end multiplicities. UML 2.0 UML 2.1.2 Resolved closed
UML22-963 ParameterSet, first line: "inputs *or* outputs". UML 2.0 UML 2.1 Resolved closed
UML22-942 In Activities, Figure 176, Action should be abstract UML 2.0 UML 2.1 Resolved closed
UML22-941 Profile Semantics, pag 723 RAS 2.2 UML 2.1 Resolved closed
UML22-935 Section: 12 UML 1.4.2 UML 2.1 Resolved closed
UML22-934 token UML 1.4.2 UML 2.1 Resolved closed
UML22-944 String is primitive but has structure. UML 2.0 UML 2.1 Resolved closed
UML22-937 ``conditional node or conditional node'' delete one. UML 1.4.2 UML 2.1 Resolved closed
UML22-936 add the rule of ``natural termination'' UML 1.4.2 UML 2.1 Resolved closed
UML22-948 Solid triange notation for Association UML 2.0 UML 2.1 Resolved closed
UML22-947 The create stereotype on Usage dependency UML 2.0 UML 2.1.2 Resolved closed
UML22-939 Section: 12.2 UML 2.0 UML 2.1 Resolved closed
UML22-938 Delete sentence UML 1.4.2 UML 2.1 Resolved closed
UML22-946 Element to Constraint navigation UML 2.0 UML 2.1.2 Resolved closed
UML22-945 Disjointness should be independent of generalization UML 2.0 UML 2.1.2 Resolved closed
UML22-943 Semantics for instances applies to InstanceSpecification? UML 2.0 UML 2.1 Resolved closed
UML22-940 policy to describe the Associations sub section of a meta class description RAS 2.2 UML 2.1 Resolved closed
UML22-933 UML 2 -- Need explanations of XMI structure and usage UML 1.4.2 UML 2.1 Resolved closed
UML22-932 token movement UML 1.4.2 UML 2.1 Resolved closed
UML22-931 output tokens (02) UML 1.4.2 UML 2.1 Resolved closed
UML22-927 Section: 12 UML 1.4.2 UML 2.1 Resolved closed
UML22-926 Section: Appendix F UML 2.0 UML 2.1 Resolved closed
UML22-925 Section: E.1 UML 2.0 UML 2.1 Resolved closed
UML22-930 text p.297 UML 1.4.2 UML 2.1 Resolved closed
UML22-929 Section 12 (03) UML 1.4.2 UML 2.1 Resolved closed
UML22-928 Section 12 (02) UML 1.4.2 UML 2.1.2 Resolved closed
UML22-920 Section: Appendix C Table 27 UML 2.0 UML 2.1 Resolved closed
UML22-919 Section: Appendix C Table 26 UML 2.0 UML 2.1 Resolved closed
UML22-922 Section: D.1 UML 2.0 UML 2.1 Resolved closed
UML22-921 Section: 15.3.8 UML 2.0 UML 2.1 Resolved closed
UML22-924 Section: D.3 UML 2.0 UML 2.1 Resolved closed
UML22-923 Section: D.2 UML 2.0 UML 2.1 Resolved closed
UML22-915 Section: 18 UML 2.0 UML 2.1 Resolved closed
UML22-914 Section: 18.4 UML 2.0 UML 2.1 Resolved closed
UML22-913 Section: 18.3.8 UML 2.0 UML 2.1 Resolved closed
UML22-918 Section: Appendix C Table 25 UML 2.0 UML 2.1 Resolved closed
UML22-917 Section: Appendix B (02) UML 2.0 UML 2.1 Resolved closed
UML22-916 Section: Appendix B UML 2.0 UML 2.1 Resolved closed
UML22-912 Section: 18.3.7 UML 2.0 UML 2.1 Resolved closed
UML22-911 Section: 18.3.3 UML 2.0 UML 2.1 Resolved closed
UML22-910 Section: 18.3.2 UML 2.0 UML 2.1 Resolved closed
UML22-909 Section: 18.2 UML 2.0 UML 2.1 Resolved closed
UML22-908 Section: 18.3.2 UML 2.0 UML 2.1 Resolved closed
UML22-893 Section: 17.5.6 UML 2.0 UML 2.1 Resolved closed
UML22-892 Section: 17.5.5 UML 2.0 UML 2.1 Resolved closed
UML22-891 Section: 17.5.4 UML 2.0 UML 2.1 Resolved closed
UML22-895 Section: 17.5.7 UML 2.0 UML 2.1 Resolved closed
UML22-894 Section: 17.1 UML 2.0 UML 2.1 Resolved closed
UML22-901 Section: 17.5.15 UML 2.0 UML 2.1 Resolved closed
UML22-900 Section: 17.5.14 UML 2.0 UML 2.1 Resolved closed
UML22-897 Section: 17.5.12 UML 2.0 UML 2.1 Resolved closed
UML22-896 Section: 17.5.8 UML 2.0 UML 2.1 Resolved closed
UML22-907 Section: 18.1.2 UML 2.0 UML 2.1 Resolved closed
UML22-906 Section: 17.5.20 UML 2.0 UML 2.1 Resolved closed
UML22-899 Section: 12 Activities UML 2.0 UML 2.1 Resolved closed
UML22-898 Section: 17.5.13 UML 2.0 UML 2.1 Resolved closed
UML22-903 Section: 17.5.17 UML 2.0 UML 2.1 Resolved closed
UML22-902 Section: 17.5.16 UML 2.0 UML 2.1 Resolved closed
UML22-905 Section: 17.5.19 UML 2.0 UML 2.1 Resolved closed
UML22-904 Section: 17.5.18 UML 2.0 UML 2.1 Resolved closed
UML22-883 Section: 17.2.2 UML 2.0 UML 2.1 Resolved closed
UML22-882 Section: 17.2.1 UML 2.0 UML 2.1 Resolved closed
UML22-872 Expansion region description UML 2.0 UML 2.1 Resolved closed
UML22-871 ExpansionRegioin example, Figure 261: concurrent => parallel UML 2.0 UML 2.1 Resolved closed
UML22-870 Section: Activities, ExpansionRegion (05) UML 2.0 UML 2.1 Resolved closed
UML22-879 mustIsolate: UML 2.0 UML 2.1 Resolved closed
UML22-878 No notation UML 2.0 UML 2.1 Resolved closed
UML22-875 Semantics of isAssured/isDeterminant in conditional node UML 2.0 UML 2.1 Resolved closed
UML22-874 Add constraint in LoopNode UML 2.0 UML 2.1 Resolved closed
UML22-873 Section: Activities UML 2.0 UML 2.1 Resolved closed
UML22-890 Section: 17.5.3 UML 2.0 UML 2.1 Resolved closed
UML22-889 Section: 17.5.3 UML 2.0 UML 2.1 Resolved closed
UML22-888 Section: 17.5.1 UML 2.0 UML 2.1 Resolved closed
UML22-885 Section: 17.4 UML 2.0 UML 2.1 Resolved closed
UML22-884 Section: 17.3.1 UML 2.0 UML 2.1 Resolved closed
UML22-887 Section: 17.5.2 UML 2.0 UML 2.1 Resolved closed
UML22-886 Section: 17.5.1 UML 2.0 UML 2.1 Resolved closed
UML22-881 Clarify the semantics of minimum multiplicity > 0 for streaming parameters UML 2.0 UML 2.1 Resolved closed
UML22-880 Figure 209 of Activites UML 2.0 UML 2.1 Resolved closed
UML22-877 Add constraints on conditional and loop nodes (02) UML 2.0 UML 2.1 Resolved closed
UML22-876 Add constraints on conditional and loop nodes UML 2.0 UML 2.1 Resolved closed
UML22-853 UML 2 Super / Conformance / inconsistencies UML 1.4.2 UML 2.1 Resolved closed
UML22-852 UML 2 Super / General / missing merges UML 1.4.2 UML 2.1 Resolved closed
UML22-851 UML 2 Super / General / improper subsetting UML 1.4.2 UML 2.1 Resolved closed
UML22-855 UML 2 Super / General / invalid subset rule too strict UML 1.4.2 UML 2.1 Resolved closed
UML22-854 UML 2 Super / Kernel / excessive restriction on redefinition UML 1.4.2 UML 2.1 Resolved closed
UML22-861 Section: 14.3.3 UML 2.0 UML 2.1 Resolved closed
UML22-860 Section: 16.3.6 UML 2.0 UML 2.1 Resolved closed
UML22-869 Section: Activities, ExpansionRegion (04) UML 2.0 UML 2.1 Resolved closed
UML22-868 Section: Activities, ExpansionRegion (03) UML 2.0 UML 2.1 Resolved closed
UML22-867 Section: Activities, ExpansionRegion (02) UML 2.0 UML 2.1 Resolved closed
UML22-859 Section: 16.3.5 UML 2.0 UML 2.1 Resolved closed
UML22-858 Section: 16.3.4 UML 2.0 UML 2.1 Resolved closed
UML22-857 Section: 16.3.3 UML 2.0 UML 2.1 Resolved closed
UML22-856 UML 2 Super / Common Behaviors / missing multiplicites UML 1.4.2 UML 2.1 Resolved closed
UML22-866 Section: Activities, ExpansionRegion UML 2.0 UML 2.1 Resolved closed
UML22-865 Section: Activities UML 2.0 UML 2.1 Resolved closed
UML22-864 ValueSpecificationAction, Attribute section, is missing the return pin UML 2.0 UML 2.1 Resolved closed
UML22-863 Section: Actions UML 2.0 UML 2.1 Resolved closed
UML22-862 Section: Common Behavior UML 2.0 UML 2.1 Resolved closed
UML22-841 Section: 15.3.14 UML 2.0 UML 2.1 Resolved closed
UML22-840 Section: Appendix A UML 2.0 UML 2.1 Resolved closed
UML22-837 Section: 15.3.11 UML 2.0 UML 2.1 Resolved closed
UML22-836 Section: 15.3.11 UML 2.0 UML 2.1 Resolved closed
UML22-835 Action Semantics Section: 9.5 UML 1.4.2 UML 2.1 Resolved closed
UML22-839 Appendix C.1 UML 2.0 UML 2.1 Resolved closed
UML22-838 Section: 15.3.12 UML 2.0 UML 2.1 Resolved closed
UML22-834 Specification: Action Semantics Section: 9.5 UML 1.4.2 UML 2.1 Resolved closed
UML22-833 Section: 15.3.10 UML 2.0 UML 2.1 Resolved closed
UML22-832 Section: 15.3.9 UML 2.0 UML 2.1 Resolved closed
UML22-843 Section: 15.3.16 UML 2.0 UML 2.1 Resolved closed
UML22-842 Section: 15.3.15 UML 2.0 UML 2.1 Resolved closed
UML22-850 UML 2 Super / Collaborations / improper subset UML 1.4.2 UML 2.1 Resolved closed
UML22-849 Profiles::ObjectNode has wrong default multiplicity UML 1.4.2 UML 2.1 Resolved closed
UML22-848 Profiles::ExtensionEnd has wrong default multiplicity UML 1.4.2 UML 2.1 Resolved closed
UML22-845 Should Profiles::Image be an Element? UML 1.4.2 UML 2.1 Resolved closed
UML22-844 Section: 15.3.7 UML 2.0 UML 2.1 Resolved closed
UML22-847 Remove redundant superclass for Element UML 1.4.2 UML 2.1 Resolved closed
UML22-846 OCL for Property::opposite() is incorrect: UML 1.4.2 UML 2.1 Resolved closed
UML22-831 Section: 15.3.8 UML 2.0 UML 2.1 Resolved closed
UML22-830 Section: 15.3.7 UML 2.0 UML 2.1 Resolved closed
UML22-817 Section: 14.3.26 UML 2.0 UML 2.1 Resolved closed
UML22-816 Section: 14.3.25 UML 2.0 UML 2.1 Resolved closed
UML22-823 Section: 15.3.1 UML 2.0 UML 2.1 Resolved closed
UML22-822 Section: 8.3.1 UML 2.0 UML 2.1.2 Resolved closed
UML22-829 Section: 15.3.6 UML 2.0 UML 2.1 Resolved closed
UML22-828 Section: 11.3.42 UML 2.0 UML 2.1 Resolved closed
UML22-812 Section: 14.3.20 UML 2.0 UML 2.1 Resolved closed
UML22-811 Section: 14.3.19 UML 2.0 UML 2.1 Resolved closed
UML22-815 Section: 14.3.24 UML 1.4.2 UML 2.1 Resolved closed
UML22-814 Section: 14.3.21 UML 2.0 UML 2.1 Resolved closed
UML22-813 Section: 14.3.21 UML 2.0 UML 2.1 Resolved closed
UML22-827 Section: 15.3.5 UML 2.0 UML 2.1 Resolved closed
UML22-826 Section: 15.3.5 UML 2.0 UML 2.1 Resolved closed
UML22-819 Section: 14.4 UML 2.0 UML 2.1 Resolved closed
UML22-818 Section: 14.3.29 UML 2.0 UML 2.1 Resolved closed
UML22-821 Section: 12.3.4 UML 2.0 UML 2.1 Resolved closed
UML22-820 Section: 11.3.5 UML 2.0 UML 2.1 Resolved closed
UML22-825 Section: 15.3.3 UML 2.0 UML 2.1 Resolved closed
UML22-824 Section: 15.3.2 UML 2.0 UML 2.1 Resolved closed
UML22-810 Section: 14.3.17 UML 2.0 UML 2.1 Resolved closed
UML22-809 Section: 14.3.16 UML 2.0 UML 2.1 Resolved closed
UML22-808 Section: 14.3.15 UML 2.0 UML 2.1 Resolved closed
UML22-797 Section: 14.3.2 UML 2.0 UML 2.1 Resolved closed
UML22-796 Section: 13 UML 2.0 UML 2.1 Resolved closed
UML22-795 Section: 13.3.30 UML 2.0 UML 2.1 Resolved closed
UML22-807 Section: 14.3.13 UML 2.0 UML 2.1 Resolved closed
UML22-806 Section: 14.3.14 UML 2.0 UML 2.1 Resolved closed
UML22-799 Section: 14.3.4 UML 2.0 UML 2.1 Resolved closed
UML22-798 Section: 14.3.3 UML 2.0 UML 2.1 Resolved closed
UML22-803 Section: 14.3.10 UML 2.0 UML 2.1 Resolved closed
UML22-802 Section: 14.3.8 UML 2.0 UML 2.1 Resolved closed
UML22-801 Section: 14.3.6 UML 2.0 UML 2.1 Resolved closed
UML22-800 Section: 14.3.5 UML 2.0 UML 2.1 Resolved closed
UML22-794 Section: 13.3.29 UML 2.0 UML 2.1 Resolved closed
UML22-793 Section: 13.3.28 UML 2.0 UML 2.1 Resolved closed
UML22-792 Section: 13.3.27 UML 2.0 UML 2.1 Resolved closed
UML22-805 Section: 14.3.12 UML 2.0 UML 2.1 Resolved closed
UML22-804 Section: 14.3.3 & 14.3.11 UML 2.0 UML 2.1 Resolved closed
UML22-791 Section: 13.3.26 UML 2.0 UML 2.1 Resolved closed
UML22-790 Section: 13.3.24 UML 2.0 UML 2.1 Resolved closed
UML22-776 Section: 13.3.3 UML 2.0 UML 2.1 Resolved closed
UML22-775 Section: 13.3.2 UML 2.0 UML 2.1.2 Resolved closed
UML22-784 Section: 13.3.14 UML 2.0 UML 2.1 Resolved closed
UML22-783 Section: 13.3.12 UML 2.0 UML 2.1 Resolved closed
UML22-778 Section: 13.3.4 UML 2.0 UML 2.1 Resolved closed
UML22-780 Section: 13.3.8 UML 2.0 UML 2.1 Resolved closed
UML22-779 Section: 13.3.7 UML 2.0 UML 2.1 Resolved closed
UML22-789 Section: 13.3.23 UML 2.0 UML 2.1 Resolved closed
UML22-788 Section: 13.3.22 UML 2.0 UML 2.1 Resolved closed
UML22-782 Section: 13.3.9 UML 2.0 UML 2.1 Resolved closed
UML22-781 Section: 13.3.10 UML 2.0 UML 2.1 Resolved closed
UML22-786 Section: 13.3.19 UML 2.0 UML 2.1 Resolved closed
UML22-785 Section: 13.3.15 UML 2.0 UML 2.1 Resolved closed
UML22-787 Section: 13.3.20 UML 2.0 UML 2.1 Resolved closed
UML22-777 Section: 7.3.36 UML 2.0 UML 2.1 Resolved closed
UML22-755 Section: 12.3.35 UML 2.0 UML 2.1 Resolved closed
UML22-754 Section: 12.3 UML 2.0 UML 2.1 Resolved closed
UML22-753 Section: 12.3.35 UML 2.0 UML 2.1 Resolved closed
UML22-767 Section: 11.3.48 UML 2.0 UML 2.1 Resolved closed
UML22-766 Section: 12.3.48 UML 2.0 UML 2.1 Resolved closed
UML22-771 Section: 12 UML 2.0 UML 2.1 Resolved closed
UML22-770 Section: 12.4 UML 2.0 UML 2.1 Resolved closed
UML22-758 Section: 12.3.38 UML 2.0 UML 2.1 Resolved closed
UML22-757 Section: 12.3.37 UML 2.0 UML 2.1 Resolved closed
UML22-756 Profiles:Extension End UML 1.4.2 UML 2.1 Resolved closed
UML22-765 Section: 12.2 UML 2.0 UML 2.1 Resolved closed
UML22-764 Section: 12.3.47 UML 2.0 UML 2.1 Resolved closed
UML22-763 UML 2 super/templates/ UML 1.4.2 UML 2.1 Resolved closed
UML22-760 Section: 12.3.43 UML 2.0 UML 2.1 Resolved closed
UML22-759 Section: 12.3.41 UML 2.0 UML 2.1 Resolved closed
UML22-774 Section: 12.3.49 UML 2.0 UML 2.1 Resolved closed
UML22-773 Section: 12.3.46 UML 2.0 UML 2.1 Resolved closed
UML22-772 Section: 13.1 UML 2.0 UML 2.1 Resolved closed
UML22-762 UML 2 Super/templates/inexplicable constraint on defaults UML 1.4.2 UML 2.1 Resolved closed
UML22-761 Section: 12.3.44 UML 2.0 UML 2.1 Resolved closed
UML22-769 Section: 12.3.51 UML 2.0 UML 2.1 Resolved closed
UML22-768 Section: 12.3.50 UML 2.0 UML 2.1 Resolved closed
UML22-752 Section: 12.3.34 UML 2.0 UML 2.1 Resolved closed
UML22-751 Section: 12.3.33 UML 2.0 UML 2.1 Resolved closed
UML22-738 Section: 12.3.17 UML 2.0 UML 2.1 Resolved closed
UML22-737 Section: 12.3.16 UML 2.0 UML 2.1 Resolved closed
UML22-736 Section: 12.3.15 UML 2.0 UML 2.1 Resolved closed
UML22-735 Section: 12.3.14 UML 2.0 UML 2.1.2 Resolved closed
UML22-731 MultiplicityElement BNF too restrictive UML 1.4.2 UML 2.1 Resolved closed
UML22-730 Section: 12.3.13 UML 2.0 UML 2.1 Resolved closed
UML22-741 Section: 12.3.6 & 12.3.19 UML 2.0 UML 2.1 Resolved closed
UML22-740 Section: 12.3.19 UML 2.0 UML 2.1 Resolved closed
UML22-739 Section: 12.3.18 UML 2.0 UML 2.1 Resolved closed
UML22-746 Section: 12.3.28 UML 2.0 UML 2.1 Resolved closed
UML22-745 Section: 12.3.27 UML 2.0 UML 2.1 Resolved closed
UML22-744 Section: 12.3.23 UML 2.0 UML 2.1 Resolved closed
UML22-734 Used of "Redefines ...from Abstractions" in descriptions is misleading UML 1.4.2 UML 2.1 Resolved closed
UML22-733 BNF Notation for Operation is too restrictive UML 1.4.2 UML 2.1 Resolved closed
UML22-732 Incomplete BNF for Property UML 1.4.2 UML 2.1 Resolved closed
UML22-743 Section: 12.3.24 UML 2.0 UML 2.1 Resolved closed
UML22-742 Section: 12.3.22 UML 2.0 UML 2.1 Resolved closed
UML22-748 Section: 12.3.38 UML 2.0 UML 2.1 Resolved closed
UML22-747 Section: 12.3.30 UML 2.0 UML 2.1 Resolved closed
UML22-750 Section: 12.3.32 UML 2.0 UML 2.1 Resolved closed
UML22-749 Section: 12.3.31 UML 2.0 UML 2.1 Resolved closed
UML22-729 Section: 12.1 UML 2.0 UML 2.1 Resolved closed
UML22-728 Section: 12.3.12 UML 2.0 UML 2.1 Resolved closed
UML22-727 Section: 12.3.10 UML 2.0 UML 2.1 Resolved closed
UML22-726 Section: 12 UML 2.0 UML 2.1 Resolved closed
UML22-725 Section: 12.3.9 UML 2.0 UML 2.1 Resolved closed
UML22-716 Section: 12.3.4 UML 2.0 UML 2.1 Resolved closed
UML22-715 Section: 12.3.2 UML 2.0 UML 2.1 Resolved closed
UML22-714 Section: 12.2 UML 2.0 UML 2.1 Resolved closed
UML22-721 Section: 12.3.8 UML 2.0 UML 2.1 Resolved closed
UML22-720 Section: 12.3.7 UML 2.0 UML 2.1 Resolved closed
UML22-719 Section: 12.3.6 UML 2.0 UML 2.1 Resolved closed
UML22-683 Section: 11.3.25 UML 2.0 UML 2.1 Resolved closed
UML22-682 Section: 11.3.24 UML 2.0 UML 2.1 Resolved closed
UML22-629 Section: 7.3.35 UML 2.0 UML 2.1 Resolved closed
UML22-631 Section: 8.3.1 - typo UML 2.0 UML 2.1 Resolved closed
UML22-630 Section: 8.3.1 UML 2.0 UML 2.1 Resolved closed
UML22-628 Section: 7.3.34 UML 2.0 UML 2.1 Resolved closed
UML22-627 Section: 7.3.33 UML 2.0 UML 2.1 Resolved closed
UML22-637 Section: 9.3.5 UML 2.0 UML 2.1 Resolved closed
UML22-636 Section: 9.3.3 UML 1.4.2 UML 2.1 Resolved closed
UML22-635 Section: 9.3.2 UML 2.0 UML 2.1 Resolved closed
UML22-632 Section: 8.3.1 UML 2.0 UML 2.1 Resolved closed
UML22-633 Section: 9.20.2 UML 2.0 UML 2.1 Resolved closed
UML22-634 Section: 9.3.1 UML 2.0 UML 2.1 Resolved closed
UML22-638 Section: 9.3.9 UML 2.0 UML 2.1 Resolved closed
UML22-561 InfrastructureLibrary defines, but should not use package merge UML 1.4.2 UML 2.1 Resolved closed
UML22-557 section 2.10.4.1 detailed semantics of collaborations UML 1.4.2 UML 2.1 Resolved closed
UML22-554 Section: 7.3.43 UML 2.0 UML 2.1 Resolved closed
UML22-559 Interactions UML 1.4.2 UML 2.1 Resolved closed
UML22-558 Section: 7.3.44 - OCL incorrect UML 1.4.2 UML 2.1 Resolved closed
UML22-555 Section: 7.2.8 UML 1.4.2 UML 2.1 Resolved closed
UML22-560 UML 2 Super Basic Interactions UML 1.4.2 UML 2.1.2 Resolved closed
UML22-562 An observed time value must be written into a structural feature UML 2.0 UML 2.1.2 Resolved closed
UML22-556 Classes UML 1.4.2 UML 2.1 Resolved closed
UML22-691 Section: 11.3.34 UML 2.0 UML 2.1 Resolved closed
UML22-690 Section: 11.3.33 UML 2.0 UML 2.1 Resolved closed
UML22-689 Section: 11.3.31 UML 2.0 UML 2.1 Resolved closed
UML22-684 Section: 11.3.26 UML 2.0 UML 2.1 Resolved closed
UML22-694 Section: 11.3.27 UML 2.0 UML 2.1 Resolved closed
UML22-693 Section: 11.3.36 UML 2.0 UML 2.1 Resolved closed
UML22-686 Section: 11.3.28 UML 2.0 UML 2.1 Resolved closed
UML22-687 Section: 11.3.29 UML 2.0 UML 2.1 Resolved closed
UML22-692 Section: 11.3.35 UML 2.0 UML 2.1 Resolved closed
UML22-688 Section: 11.3.30 UML 2.0 UML 2.1 Resolved closed
UML22-685 Section: 11.3.27 UML 2.0 UML 2.1 Resolved closed
UML22-588 Optional inputs UML 2.0 UML 2.1 Resolved closed
UML22-587 Preserve order in result of read actions UML 2.0 UML 2.1 Resolved closed
UML22-582 Interactions chapter refers to ActivityInvocations UML 2.0 UML 2.1 Resolved closed
UML22-583 Destruction semantics in StructuredClassifier UML 2.0 UML 2.1 Resolved closed
UML22-585 Figure 119 missing multiplicity UML 2.0 UML 2.1 Resolved closed
UML22-584 Link maintenance in StructuredClassifier UML 2.0 UML 2.1 Resolved closed
UML22-591 ObjectNode, constraint 1 In ObjectNode UML 2.0 UML 2.1 Resolved closed
UML22-590 DestroyObjectAction semantics UML 2.0 UML 2.1 Resolved closed
UML22-589 IsReadOnly constriant UML 2.0 UML 2.1 Resolved closed
UML22-586 Notation for method UML 2.0 UML 2.1 Resolved closed
UML22-659 Section: 11.3.1 UML 2.0 UML 2.1 Resolved closed
UML22-658 Section: 11.1 UML 2.0 UML 2.1 Resolved closed
UML22-621 Section: 7.3.15 UML 2.0 UML 2.1 Resolved closed
UML22-620 Section: 7.3.12 UML 2.0 UML 2.1 Resolved closed
UML22-626 Section: 7.3.32 Page: 96-99 UML 2.0 UML 2.1 Resolved closed
UML22-625 Section: 7.3.32 UML 2.0 UML 2.1 Resolved closed
UML22-624 Section: 7.3.22 UML 2.0 UML 2.1 Resolved closed
UML22-616 Section: 6.5.1: Error in example UML 2.0 UML 2.1 Resolved closed
UML22-619 Section: 7.3.10 UML 2.0 UML 2.1 Resolved closed
UML22-622 Section: 7.3.20 UML 2.0 UML 2.1 Resolved closed
UML22-618 Section: 7.3.8 UML 2.0 UML 2.1 Resolved closed
UML22-623 Stereotypes applying in UML 2.0 UML 1.4.2 UML 2.1 Resolved closed
UML22-617 Section: 7.3.3 UML 2.0 UML 2.1 Resolved closed
UML22-678 Section: 11.3.20 UML 2.0 UML 2.1 Resolved closed
UML22-677 Section: 11.3.19 UML 2.0 UML 2.1 Resolved closed
UML22-680 Section: 11.3.22 -- significant revision? UML 2.0 UML 2.1 Resolved closed
UML22-679 Section: 11.3.21 UML 2.0 UML 2.1 Resolved closed
UML22-696 Section: 11.3.40 UML 2.0 UML 2.1 Resolved closed
UML22-695 Section: 11.3.38 UML 2.0 UML 2.1 Resolved closed
UML22-681 Section: 11.3.23 -- significant revision? UML 2.0 UML 2.1 Resolved closed
UML22-672 Section: 11.3.14 UML 2.0 UML 2.1 Resolved closed
UML22-676 Section: 11.3.18 UML 2.0 UML 2.1 Resolved closed
UML22-674 Section: 11.3.16 UML 2.0 UML 2.1 Resolved closed
UML22-675 Section: 11.3.17 UML 2.0 UML 2.1 Resolved closed
UML22-673 Section: 11.3.15 UML 2.0 UML 2.1 Resolved closed
UML22-709 Section: 11.3.53 UML 2.0 UML 2.1 Resolved closed
UML22-708 Section: 11.3.42 UML 2.0 UML 2.1 Resolved closed
UML22-698 Section: 11.3.43 UML 2.0 UML 2.1 Resolved closed
UML22-697 Section: 11.3.41 UML 2.0 UML 2.1 Resolved closed
UML22-660 Section: 11.3.2 UML 2.0 UML 2.1 Resolved closed
UML22-667 Section: 11.3.9 UML 2.0 UML 2.1 Resolved closed
UML22-666 Section: 11.3.8 UML 2.0 UML 2.1 Resolved closed
UML22-670 Section: 11.3.12 UML 2.0 UML 2.1 Resolved closed
UML22-669 Section: 11.3.11 UML 2.0 UML 2.1.2 Resolved closed
UML22-668 Section: 11.3.10 UML 2.0 UML 2.1 Resolved closed
UML22-664 Section: 11.3.6 UML 2.0 UML 2.1 Resolved closed
UML22-665 Section: 11.3.7 UML 2.0 UML 2.1 Resolved closed
UML22-663 Section: 11.3.5 UML 2.0 UML 2.1 Resolved closed
UML22-671 Section: 11.3.13 UML 2.0 UML 2.1 Resolved closed
UML22-579 Connector multiplicity notation UML 2.0 UML 2.1 Resolved closed
UML22-578 Associations between interfaces UML 2.0 UML 2.1 Resolved closed
UML22-580 create dependency Figures 103 and 121 UML 2.0 UML 2.1 Resolved closed
UML22-573 Transitivity in composition UML 2.0 UML 2.1 Resolved closed
UML22-581 underlined association name UML 2.0 UML 2.1.2 Resolved closed
UML22-577 Section: Classes UML 2.0 UML 2.1 Resolved closed
UML22-572 Add concept "StateInvariant" UML 2.0 UML 2.1 Resolved closed
UML22-574 Pin/parameter matching constraints UML 2.0 UML 2.1 Resolved closed
UML22-576 Section: Classes UML 2.0 UML 2.1 Resolved closed
UML22-575 Section: CB/ACT UML 2.0 UML 2.1 Resolved closed
UML22-723 Section: 12.3.9 UML 2.0 UML 2.1 Resolved closed
UML22-722 Section: 12.1 UML 2.0 UML 2.1 Resolved closed
UML22-641 Section: 8.3.4 UML 2.0 UML 2.1 Resolved closed
UML22-640 Section: 9.3.10 UML 2.0 UML 2.1 Resolved closed
UML22-647 Section: 10.3.1 UML 2.0 UML 2.1 Resolved closed
UML22-648 Section: 10.3.1 UML 2.0 UML 2.1 Resolved closed
UML22-644 Section: 12.3.13 UML 2.0 UML 2.1 Resolved closed
UML22-645 Section: 12.3.13 UML 2.0 UML 2.1 Resolved closed
UML22-643 Section: 9.3.13 UML 2.0 UML 2.1 Resolved closed
UML22-639 Section: 9.3.9 UML 2.0 UML 2.1 Resolved closed
UML22-646 Section: 9.2 UML 2.0 UML 2.1 Resolved closed
UML22-642 Section: 9.3.12 UML 2.0 UML 2.1 Resolved closed
UML22-615 Section: 7.4.1 UML 2.0 UML 2.1 Resolved closed
UML22-614 Section: 7.3.6 UML 2.0 UML 2.1 Resolved closed
UML22-610 Section: 11.8.3 UML 2.0 UML 2.1 Resolved closed
UML22-609 Section: 11.6.1 UML 2.0 UML 2.1 Resolved closed
UML22-613 Section: 7.3.3 UML 2.0 UML 2.1 Resolved closed
UML22-612 Section: 13.1.5 UML 2.0 UML 2.1 Resolved closed
UML22-607 Section: 11.5 UML 2.0 UML 2.1 Resolved closed
UML22-606 search for referenced item -- Section: 11.3.4 UML 2.0 UML 2.1 Resolved closed
UML22-603 Figure 68 UML 2.0 UML 2.1 Resolved closed
UML22-602 methods not defined under attributes UML 2.0 UML 2.1 Resolved closed
UML22-611 Section: 13.1.2 UML 2.0 UML 2.1 Resolved closed
UML22-605 Section: 11.3.3 UML 2.0 UML 2.1 Resolved closed
UML22-604 Section: 11.3.1 UML 2.0 UML 2.1 Resolved closed
UML22-608 Actor is a specialized Classifier and not BehavioredClassifier UML 2.0 UML 2.1 Resolved closed
UML22-711 Section: 12.1 UML 2.0 UML 2.1 Resolved closed
UML22-710 Section: 11.3.54 UML 2.0 UML 2.1 Resolved closed
UML22-713 {redefined } should be named {redefines } UML 2.0 UML 2.1 Resolved closed
UML22-712 Property string {bag} is redundant UML 2.0 UML 2.1.2 Resolved closed
UML22-718 Section: 12.3.5 UML 2.0 UML 2.1 Resolved closed
UML22-717 Section: 12.3.4 UML 2.0 UML 2.1 Resolved closed
UML22-703 Section: 11.3.48 UML 2.0 UML 2.1 Resolved closed
UML22-701 Section: 11.3.46 UML 2.0 UML 2.1 Resolved closed
UML22-700 Section: 11.3.45 UML 2.0 UML 2.1 Resolved closed
UML22-707 Section: 11.3.52 UML 2.0 UML 2.1 Resolved closed
UML22-706 Section: 11.3.51 UML 2.0 UML 2.1 Resolved closed
UML22-705 Section: 11.3.50 UML 2.0 UML 2.1 Resolved closed
UML22-699 Section: 11.3.44 UML 2.0 UML 2.1 Resolved closed
UML22-704 Section: 11.3.49 UML 2.0 UML 2.1 Resolved closed
UML22-702 Section: 11.3.47 UML 2.0 UML 2.1 Resolved closed
UML22-596 unclear statement UML 2.0 UML 2.1 Resolved closed
UML22-595 Text references Figure 8 and the correct figure number is 6 UML 2.0 UML 2.1 Resolved closed
UML22-599 Section is badly worded and does not make a lot of sense UML 2.0 UML 2.1 Resolved closed
UML22-598 clarify what a directed association is UML 2.0 UML 2.1 Resolved closed
UML22-593 Terminology Issue UML 1.4.2 UML 2.1.2 Resolved closed
UML22-600 typing error in the statement :unrestricted ? UML 2.0 UML 2.1 Resolved closed
UML22-597 extra word in the last sentence of the paragraph under Attributes UML 2.0 UML 2.1 Resolved closed
UML22-594 section 9.20.2 VisibilityKind lists two types of visibility UML 2.0 UML 2.1 Resolved closed
UML22-592 StructuredActivityNode specialized multiplicity UML 2.0 UML 2.1 Resolved closed
UML22-601 What happened to real numbers UML 2.0 UML 2.1 Resolved closed
UML22-724 Section: 12 UML 2.0 UML 2.1 Resolved closed
UML22-662 Section: 11.3.4 UML 2.0 UML 2.1 Resolved closed
UML22-661 Section: 11.3.3 UML 2.0 UML 2.1 Resolved closed
UML22-655 Section: 10.3.10 UML 2.0 UML 2.1 Resolved closed
UML22-654 Section: 10.3.9 UML 2.0 UML 2.1 Resolved closed
UML22-657 Section: 10.4 UML 1.4.2 UML 2.1 Resolved closed
UML22-652 Section: 10.3.6 UML 2.0 UML 2.1 Resolved closed
UML22-656 Section: 10.3.11 UML 2.0 UML 2.1 Resolved closed
UML22-650 Section: 10.3.4 UML 2.0 UML 2.1 Resolved closed
UML22-653 Section: 10.3.8 UML 2.0 UML 2.1 Resolved closed
UML22-649 Section: 10.3.3 UML 2.0 UML 2.1 Resolved closed
UML22-651 Section: 10.3.5 UML 2.0 UML 2.1 Resolved closed
UML22-565 ReduceAction UML 1.4.2 UML 2.1 Resolved closed
UML22-564 UML 2 Super / Incorrect statement on port visibility UML 1.4.2 UML 2.1 Resolved closed
UML22-566 Section: 14.3.7 UML 2.0 UML 2.1 Resolved closed
UML22-563 Minor error in BNF of an message argument UML 2.0 UML 2.1 Resolved closed
UML22-568 Section: 14.3.14 UML 2.0 UML 2.1 Resolved closed
UML22-569 Section: 14.3.16 UML 2.0 UML 2.1 Resolved closed
UML22-571 StateInvariants/Continuations UML 2.0 UML 2.1 Resolved closed
UML22-570 Section: Table 14 UML 2.0 UML 2.1 Resolved closed
UML22-567 Section: 14.3.13 UML 2.0 UML 2.1 Resolved closed
UML22-553 DataType attributes UML 2 Super (ptc/04-10-02) UML 1.4.2 UML 2.1 Resolved closed
UML22-458 UML 2.2 superstructure section 9.3.11 page 184: Port.isService UML 2.1.2 UML 2.2 Resolved closed
UML22-456 Could you please clarify what does the UML2 specifications intend for "provided port" and "required port"? UML 2.1.2 UML 2.2 Resolved closed
UML22-455 Inconsistency in Superstructure 2.2 p. 550 UML 2.1.2 UML 2.2 Resolved closed
UML22-454 InstanceSpecifications UML 2.1.2 UML 2.2 Resolved closed
UML22-453 specificMachine association should be changed to be type StateMachine UML 2.1.2 UML 2.2 Resolved closed
UML22-452 p269-p270 Constraint UML 2.1.2 UML 2.2 Resolved closed
UML22-451 operation allConnections UML 2.1.2 UML 2.2 Resolved closed
UML22-450 TYPO p.54 Additional Operations UML 2.1.2 UML 2.2 Resolved closed
UML22-446 Classifier has association end "attribute" UML 2.1.2 UML 2.2 Resolved closed
UML22-445 Typo 9.3.13 p190 UML 2.1.2 UML 2.2 Resolved closed
UML22-449 Metaclass Property is denoted in Interfaces Package on p.36 UML 2.1.2 UML 2.2 Resolved closed
UML22-448 7.3.33 p100 UML 2.1.2 UML 2.2 Resolved closed
UML22-447 Property 7.3.44 p125 UML 2.1.2 UML 2.2 Resolved closed
UML22-444 7.3.44 additional operation P128 UML 2.1.2 UML 2.2 Resolved closed
UML22-399 first paragraph of section 7.8 UML kernel UML 2.1.2 UML 2.2 Resolved closed
UML22-398 Section: 7.3.7 and 8.3.1 UML 2.1.2 UML 2.2 Resolved closed
UML22-401 Port UML 2.1.2 UML 2.2 Resolved closed
UML22-400 Section 14 Interaction UML 2.1.2 UML 2.2 Resolved closed
UML22-389 Section: 15.3.11/Notation UML 2.1.2 UML 2.2 Resolved closed
UML22-388 Section 11.3.25 gives the definition of MultiplicityExpression::isConsisten UML 2.1.2 UML 2.2 Resolved closed
UML22-396 interpreting InstanceSpecification UML 2.1.2 UML 2.2 Resolved closed
UML22-395 Figure showing an AssociationClass as a ternary association UML 2.1.2 UML 2.2 Resolved closed
UML22-391 Section: 7.3.10/Associations UML 2.1.2 UML 2.2 Resolved closed
UML22-390 Section: 13.3.3/ Changes from previous UML UML 2.1.2 UML 2.2 Resolved closed
UML22-394 Car dependency example UML 2.1.2 UML 2.2 Resolved closed
UML22-393 Section: 12.3.8/Generalizations UML 2.1.2 UML 2.2 Resolved closed
UML22-387 qualifiers UML 2.1.2 UML 2.2 Resolved closed
UML22-397 Section: 15 StateMachines: doActivity and internal transitions UML 2.1.2 UML 2.2 Resolved closed
UML22-392 Section: 7.3.10/Associations - insert reference UML 2.1.2 UML 2.2 Resolved closed
UML22-432 Unspecified constraint [1] on ActivityNode UML 2.1.2 UML 2.2 Resolved closed
UML22-431 constraint [4] on AcceptEventAction and unordered result:OutputPin property UML 2.1.2 UML 2.2 Resolved closed
UML22-434 figure 13.12 UML 2.1.2 UML 2.2 Resolved closed
UML22-433 Unspecified constraint [1] on ActivityNode (StructuredActivities) UML 2.1.2 UML 2.2 Resolved closed
UML22-436 Clarification on use of Profiles. UML 2.1.2 UML 2.2 Resolved closed
UML22-435 Property – Additional Operations, page 127. UML 2.1.2 UML 2.2 Resolved closed
UML22-443 7.3.44 Property P128 UML 2.1.2 UML 2.2 Resolved closed
UML22-442 18.3.8 Stereotype UML 2.1.2 UML 2.2 Resolved closed
UML22-430 Unspecified constraint [3] on Activity UML 2.1.2 UML 2.2 Resolved closed
UML22-440 Typo P205 10.3.4 UML 2.1.2 UML 2.2 Resolved closed
UML22-439 On the table 2.3, page 8 UML 2.1.2 UML 2.2 Resolved closed
UML22-438 On the communication diagram in Fig 6.2 (second issue) UML 2.1.2 UML 2.2 Resolved closed
UML22-437 On the communication diagram in Fig 6.2 (P12) UML 2.1.2 UML 2.2 Resolved closed
UML22-441 7.3.11 DataType, P61 UML 2.1.2 UML 2.2 Resolved closed
UML22-383 UML 2.1.2:18.3.5 Package (from Profiles) UML 2.1.2 UML 2.2 Resolved closed
UML22-382 UML Super 2.1.2:Feature UML 2.1.2 UML 2.2 Resolved closed
UML22-384 A final node that returns to the caller but leaves alive any parallel flow UML 2.1.2 UML 2.2 Resolved closed
UML22-380 section '10.3.12 Property (from Nodes)' UML 2.1.2 UML 2.2 Resolved closed
UML22-379 PackageableElement (from Kernel), subsection: "Attribute" UML 2.1.2 UML 2.2 Resolved closed
UML22-386 CMOF file for UML2 does not have derived Associations marked as such UML 2.1.2 UML 2.2 Resolved closed
UML22-385 Section: 8.3.3 UML 2.1.2 UML 2.2 Resolved closed
UML22-378 description of MessageOccurenceSpecification UML 2.1.2 UML 2.2 Resolved closed
UML22-377 The list of literal described for the ennumeration MessageSort is not compl UML 2.1.2 UML 2.2 Resolved closed
UML22-381 undefined term 'Element::redefinedElement' occurs three times in standard UML 2.1.2 UML 2.2 Resolved closed
UML22-419 Section: 7.4 figure 7.1 missing dependency UML 2.1.2 UML 2.2 Resolved closed
UML22-418 UML2: Need a better mechanism for integrating UML2 Profiles UML 2.1.2 UML 2.2 Resolved closed
UML22-421 Regression in XMI from UML 2.1.2 to UML 2.2 UML 2.1.2 UML 2.2 Resolved closed
UML22-420 Section: 2.2-2.4 compliance level clarifiction needed UML 2.1.2 UML 2.2 Resolved closed
UML22-424 Unspecified constraint [1] on AcceptEventAction UML 2.1.2 UML 2.2 Resolved closed
UML22-423 Incorrect OCL expression for constraint [1] on BehavioredClassifier UML 2.1.2 UML 2.2 Resolved closed
UML22-415 OCL 2.0 8.2 Real UML 2.1.2 UML 2.2 Resolved closed
UML22-414 UML2 issue regarding RedefinableTemplateSignature UML 2.1.2 UML 2.2 Resolved closed
UML22-427 Unspecified constraint [1] on ActivityEdge (CompleteStructuredActivities) UML 2.1.2 UML 2.2 Resolved closed
UML22-426 Unspecified constraint [2] on ActivityEdge UML 2.1.2 UML 2.2 Resolved closed
UML22-429 Unspecified constraint [2] on Activity UML 2.1.2 UML 2.2 Resolved closed
UML22-428 Unspecified constraint [1 on Activity UML 2.1.2 UML 2.2 Resolved closed
UML22-417 Section 7.3.50 "substitution" UML 2.1.2 UML 2.2 Resolved closed
UML22-416 Keyword ambiguity for DataType Section UML 2.1.2 UML 2.2 Resolved closed
UML22-425 Unspecified constraint [1] on ActivityEdge UML 2.1.2 UML 2.2 Resolved closed
UML22-422 Section: 9.3.8 UML 2.1.2 UML 2.2 Resolved closed
UML22-406 Section 10.3.10 UML 2.1.1 UML 2.2 Resolved closed
UML22-405 definition of RedefinableElement::isLeaf UML 2.1.2 UML 2.2 Resolved closed
UML22-404 Behavior's parameter list UML 2.1.2 UML 2.2 Resolved closed
UML22-403 PackageMerge relationships UML 2.1.2 UML 2.2 Resolved closed
UML22-413 Section: 7.3.36 UML 2.1.2 UML 2.2 Resolved closed
UML22-412 Section: 11.3.30,12.3.23 UML 2.1.2 UML 2.2 Resolved closed
UML22-410 Section: 13.3.3 UML 2.1.2 UML 2.2 Resolved closed
UML22-411 Section: 12.2 UML 2.1.2 UML 2.2 Resolved closed
UML22-408 The behavior of an OpaqueExpression should itself be opaque UML 2.1.2 UML 2.2 Resolved closed
UML22-409 Section: 13.3.23 UML 2.1.2 UML 2.2 Resolved closed
UML22-402 Classifiers UML 2.1.2 UML 2.2 Resolved closed
UML22-407 Section: 7.3.35 UML 2.1.2 UML 2.2 Resolved closed
UML22-468 Packaging Issues with Stereotype Extension UML 2.1.2 UML 2.2 Resolved closed
UML22-467 inconsistency with how constraints are specified in UML and OCL UML 2.1.2 UML 2.2 Resolved closed
UML22-470 Allowing multiple Associations in a Package with the same name UML 2.1.2 UML 2.2 Resolved closed
UML22-469 P479L.14 Section "Notation" in 14.3.10 ExecutionOccurences - Typo UML 2.1.2 UML 2.2 Resolved closed
UML22-472 Figure 18.2 (which describes the contents of the Profiles package) is currently misleading UML 2.1.2 UML 2.2 Resolved closed
UML22-466 ParameterableElement as a formal template parameter UML 2.1.2 UML 2.2 Resolved closed
UML22-465 UML. Clarify relationship of Substitution and InterfaceRealization UML 2.1.2 UML 2.2 Resolved closed
UML22-462 UML2 section 8.3.1 OCL derivations on Component.provided and Component.required are still invalid UML 2.1.2 UML 2.2 Resolved closed
UML22-464 transitionkind Constraints UML 2.1.2 UML 2.2 Resolved closed
UML22-463 UML 2.2 figure 8.10 has arrows the wrong way around UML 2.1.2 UML 2.2 Resolved closed
UML22-461 UML2.2 Section 9.3.1 Presentation Options section UML 2.1.2 UML 2.2 Resolved closed
UML22-460 UML 2.2 Section 9.3.1 nested classes paragrpah in wrong chapter UML 2.1.2 UML 2.2 Resolved closed
UML22-471 Figure 2.2 contains more than four packages, description referes to four packages UML 2.1.2 UML 2.2 Resolved closed
UML22-534 In normative XMI file for the metamodel, no Associations have a name. XMI 2.0 UML 2.1 Resolved closed
UML22-533 UML 2 Super/Interactions/Constraints for create messages XMI 2.0 UML 2.1 Resolved closed
UML22-536 UML2 Infra/11.5.1/Invalid reference to Attribute class XMI 2.0 UML 2.1 Resolved closed
UML22-535 Figure 78 UML 2.0 UML 2.1.2 Resolved closed
UML22-532 Class InfrastructureLibrary::Core::Basic::Property UML 2.0 UML 2.1 Resolved closed
UML22-531 In 2.13.3, the first sub-section about ActivityGraph is not numbered UML 1.5 UML 2.1 Resolved closed
UML22-529 missing closing parenthesis UML 1.5 UML 2.1 Resolved closed
UML22-528 The Composition section does not follow the usual conventions UML 1.5 UML 2.1 Resolved closed
UML22-526 In "2.9.3.5 Instance", numbering of different well-formedness rules wrong UML 1.5 UML 2.1 Resolved closed
UML22-525 The numbering of the sub-sections in 2.7.2 is wrong UML 1.5 UML 2.1 Resolved closed
UML22-523 Associations section of element JumpHandler UML 1.5 UML 2.1 Resolved closed
UML22-522 Remove one of the dots between protectedAction and availableOutput UML 1.5 UML 2.1 Resolved closed
UML22-524 UML 2.0 infra and super Constraints Diagram of the Kernel UML 1.5 UML 2.1 Resolved closed
UML22-527 The section about Procedure does not contain any well-formedness rules UML 1.5 UML 2.1 Resolved closed
UML22-530 At the bottom of the page, the characters "antics." should be removed UML 1.5 UML 2.1 Resolved closed
UML22-549 Inconsistent use of 'Element' between MOF and UML UML 1.4.2 UML 2.1 Resolved closed
UML22-548 Missing XMI tags in spec and XMI rendition of metamodel UML 1.4.2 UML 2.1 Resolved closed
UML22-504 ptc-03-09-15/Constructs::Class superClass property UML 1.5 UML 2.1 Resolved closed
UML22-503 ptc-03-09-15/Non-navigable ends with no role names nor multiplicities UML 1.5 UML 2.1 Resolved closed
UML22-502 UML 2 Issue: Message notation UML 1.5 UML 2.1 Resolved closed
UML22-508 Why not using the UML1 activity symbol for UML2 actions? UML 1.5 UML 2.1 Resolved closed
UML22-507 Multiplicity seems to be broken - UML2 Infra & Super UML 1.5 UML 2.1 Resolved closed
UML22-499 UML 2 Super / Dependency / ownership of dependencies UML 1.5 UML 2.1 Resolved closed
UML22-498 Clarification of Information Flow semantics UML 1.5 UML 2.1 Resolved closed
UML22-497 Activity diagram problems UML 1.5 UML 2.1 Resolved closed
UML22-490 UML 2 Infra/Metamodel::Constructs/invalid OCL constraint for "opposite" UML 1.5 UML 2.1 Resolved closed
UML22-489 UML 2 Super/Metamodel::Kernel/missing merges UML 1.5 UML 2.1 Resolved closed
UML22-488 UML 2 Super/Package merge/redefinitions issue - lost association ends UML 1.5 UML 2.1 Resolved closed
UML22-487 UML 2 Super/Metamodel::Super/missing merge UML 1.5 UML 2.1 Resolved closed
UML22-493 raisedException UML 1.5 UML 2.1 Resolved closed
UML22-492 UML 2 Super / Templates / TemplateParameter not named UML 1.5 UML 2.1 Resolved closed
UML22-491 UML 2 Super/pg.75/kinds of changeability UML 1.5 UML 2.1 Resolved closed
UML22-496 Section 9.3.4 page 161, Presentation Option UML 1.5 UML 2.1 Resolved closed
UML22-495 UML 2 Super / Kernel features / cannot exclude superclass properties UML 1.5 UML 2.1 Resolved closed
UML22-494 Syntax of names UML 1.5 UML 2.1 Resolved closed
UML22-501 UML 2 Issue: definition of navigability UML 1.5 UML 2.1.2 Resolved closed
UML22-500 Use 'represent' for the relationship of a model UML 1.5 UML 2.1 Resolved closed
UML22-506 Rose Model of UML 2.0 spec UML 1.5 UML 2.1 Resolved closed
UML22-505 ptc-03-09-15/Relationships among Core packages UML 1.5 UML 2.1 Resolved closed
UML22-547 Move Comment into Basic and add Kind UML 1.4.2 UML 2.1 Resolved closed
UML22-546 Unconsistent Profile extension description (02) UML 1.4.2 UML 2.1 Resolved closed
UML22-545 Unconsistent association extension description UML 1.4.2 UML 2.1 Resolved closed
UML22-538 Section 11.7 UML 2.0 UML 2.1 Resolved closed
UML22-537 simple time model" in CommonBehavior UML 2.0 UML 2.1.2 Resolved closed
UML22-551 Problem with diagram references in Profiles section UML 1.4.2 UML 2.1 Resolved closed
UML22-550 Design principles UML 1.4.2 UML 2.1 Resolved closed
UML22-544 The specification is fond of using 'typically.' UML 2.0 UML 2.1 Resolved closed
UML22-543 TimeObservationAction and DurationObservationAction UML 2.0 UML 2.1.2 Resolved closed
UML22-541 add an interaction fragment UML 2.0 UML 2.1 Resolved closed
UML22-540 Interactions model sequences of events UML 2.0 UML 2.1.2 Resolved closed
UML22-539 Clarify example in figure 133 UML 2.0 UML 2.1 Resolved closed
UML22-542 XMI schema RAS 2.0b1 UML 2.1 Resolved closed
UML22-552 DataType attributes UML 2 Super (ptc/04-10-02) UML 1.4.2 UML 2.1 Resolved closed
UML22-486 UML 2 Super/Metamodel::Constructs/owningComment UML 1.5 UML 2.1 Resolved closed
UML22-485 Classes diagram of the Core::Constructs package UML 2.0 UML 2.1 Resolved closed
UML22-484 cross-reference missing UML 2.0 UML 2.1 Resolved closed
UML22-483 Relationship and DirectedRelationship in Core::Constructs UML 2.0 UML 2.1 Resolved closed
UML22-482 document appears to be inconsistent in how it handles concepts UML 2.0 UML 2.1 Resolved closed
UML22-477 Designates a Generalization UML 1.4 UML 2.1 Resolved closed
UML22-476 Namespace issue (UML 1.4 formal/2002-09-67, 2.5.3.26 Namespace ) UML 1.4 UML 2.1.2 Resolved closed
UML22-475 Sending a signal after a delay XMI 1.3 UML 2.1.2 Resolved closed
UML22-474 Does visibility apply to creating an destroying links? XMI 1.2 UML 2.1 Resolved closed
UML22-481 relationship should just be a cross-reference UML 1.5 UML 2.1 Resolved closed
UML22-480 formal/03-03-01 : Omission of definition of Class "Action" UML 1.5 UML 2.1 Resolved closed
UML22-473 Specify XMI parameters for the UML / XMI interchange format UML 1.3 UML 2.1 Resolved closed
UML22-479 logic upperbound is the same as the lower bound. UML 1.5 UML 2.1 Resolved closed
UML22-478 2.5.2.27 ModelElement UML 1.4 UML 2.1 Resolved closed
UML22-511 UML 2 Super / Classes / dependencies should be unidirectional UML 1.5 UML 2.1 Resolved closed
UML22-510 two classes "NamedElement UML 1.5 UML 2.1 Resolved closed
UML22-515 well-formedness rules are not numbered correctly UML 1.5 UML 2.1 Resolved closed
UML22-514 number of the figure is wrong UML 1.5 UML 2.1 Resolved closed
UML22-520 UML 1.5 table of contents XMI 2.0 UML 2.1 Resolved closed
UML22-519 In the last paragraph, the period after the word "collections" on the secon UML 1.5 UML 2.1 Resolved closed
UML22-518 In paragraph 5, the addition of 2, 5, 7 and -3 does not yield 9 but 11 UML 1.5 UML 2.1 Resolved closed
UML22-517 The multiplicity of association named subaction of type Action ill formed UML 1.5 UML 2.1 Resolved closed
UML22-521 Operations and derived attributes UML 1.5 UML 2.1 Resolved closed
UML22-509 class "InfrastructureLibrary.core.constructs.Association", UML 1.5 UML 2.1 Resolved closed
UML22-513 remove paragraph UML 1.5 UML 2.1 Resolved closed
UML22-512 UML 2 Infra/Metamodel/missing derivation indicators UML 1.5 UML 2.1.2 Resolved closed
UML22-516 multiplicity of the association named "type" of type DataType UML 1.5 UML 2.1 Resolved closed
UML22-327 Behaviors Owned by State Machines UML 2.1 UML 2.2 Resolved closed
UML22-326 Section: 12.3.41 Streaming parameters for actions UML 2.1.1 UML 2.2 Resolved closed
UML22-316 Section: 13.3.24 UML 2.1.1 UML 2.2 Resolved closed
UML22-315 Section: 15.3.14 UML 2.1.1 UML 2.2 Resolved closed
UML22-321 Wrong subsets UML 2.1 UML 2.2 Resolved closed
UML22-320 Section: 15.3.11 UML 2.1.1 UML 2.2 Resolved closed
UML22-328 information flow source and target UML 2.1 UML 2.2 Resolved closed
UML22-318 description of 14.3.24 MessageSort (from BasicInteractions) - typo UML 2.1 UML 2.2 Resolved closed
UML22-317 drawing a frame to represent Combined Fragment or an Interaction Occurrence UML 2.1 UML 2.2 Resolved closed
UML22-325 Section: 14 Interactions: Lifeline representing an actor UML 2.1.1 UML 2.2 Resolved closed
UML22-324 Section: 9 Composite Structures / Port notation UML 2.1.1 UML 2.2 Resolved closed
UML22-323 Section: 16.3.2 Classifier (from UseCases) UML 2.1.1 UML 2.2 Resolved closed
UML22-322 Section 18.3.1 UML 2.1 UML 2.2 Resolved closed
UML22-247 Section: Common Behavior - isReentrant should default to true UML 2.1.1 UML 2.2 Resolved closed
UML22-246 Actions on non-unique properties with location specified UML 2.1.1 UML 2.2 Resolved closed
UML22-243 Section: Actions - Output of read actions for no values UML 2.1.1 UML 2.2 Resolved closed
UML22-242 Section: Actions - InputPin semantics wording UML 2.1.1 UML 2.2 Resolved closed
UML22-245 Section: Activities - Output pin semantics clarification UML 2.1.1 UML 2.2 Resolved closed
UML22-244 Section: Activities - ForkNode semantics wording UML 2.1.1 UML 2.2 Resolved closed
UML22-241 Section: Activities - Preserving order of multiple tokens offered. UML 2.1.1 UML 2.2 Resolved closed
UML22-250 Bad cross reference for InterfaceRealization Notation UML 2.0 UML 2.2 Resolved closed
UML22-249 PrimitiveTypes access by UML (M1) models UML 2.0 UML 2.2 Resolved closed
UML22-253 Unclear which Property has aggregation UML 2.0 UML 2.2 Resolved closed
UML22-252 Move Property::isId from MOF to UML UML 2.0 UML 2.2 Resolved closed
UML22-248 Notation for stereotypes on Comments and other elements UML 2.0 UML 2.2 Resolved closed
UML22-251 text-diagram out of synch in Infrastructure 11.4.1 UML 2.0 UML 2.2 Resolved closed
UML22-254 Clarify isRequired UML 2.0 UML 2.2 Resolved closed
UML22-375 definition of 'isCompatibleWith' for ValueSpecification UML 2.1.2 UML 2.2 Resolved closed
UML22-374 formal definitions of 'isCompatibleWith' (pages 622, 647, 649) UML 2.1.2 UML 2.2 Resolved closed
UML22-373 association 'ownedTemplateSignature' of a Classifier UML 2.1.2 UML 2.2 Resolved closed
UML22-376 term 'templatedElement' not defined UML 2.1.2 UML 2.2 Resolved closed
UML22-309 Usage of "Element::ownedMember" UML 2.1 UML 2.2 Resolved closed
UML22-308 Consistency in description of ends owned by associations UML 2.1 UML 2.2 Resolved closed
UML22-306 Section: 12.3.30 UML 2.1.1 UML 2.2 Resolved closed
UML22-312 Section: 15.3.12 UML 2.1 UML 2.2 Resolved closed
UML22-311 "PackageableElement::visibility" uses "false" as default value UML 2.1 UML 2.2 Resolved closed
UML22-302 Mismatch between Superstructure ptc/06-04-02 and XML Schema ptc/06-04-05 UML 2.1 UML 2.2 Resolved closed
UML22-301 Page: 155, 162 UML 2.1 UML 2.2 Resolved closed
UML22-305 Section: 17/17.5.7 UML 2.1.1 UML 2.2 Resolved closed
UML22-304 Port.provided:Interface UML 2.1 UML 2.2 Resolved closed
UML22-300 Section: 14.3.28 ReceiveSignalEvent (from BasicInteractions) UML 2.1 UML 2.2 Resolved closed
UML22-299 Section: 12.3.38 UML 2.1.1 UML 2.2 Resolved closed
UML22-303 UML2: Actor cannot have ownedAttributes UML 2.1 UML 2.2 Resolved closed
UML22-314 State Machines UML 2.1.1 UML 2.2 Resolved closed
UML22-313 Section: 18.3.8 UML 2.1.1 UML 2.2 Resolved closed
UML22-310 "Constraint::context" is marked as derived in the metaclass description UML 2.1 UML 2.2 Resolved closed
UML22-222 discrepancies between package dependencies and XMI file for Superstructure UML 2.1 UML 2.2 Resolved closed
UML22-224 Section: Figure 14.5 UML 2.1 UML 2.2 Resolved closed
UML22-223 Section: Appendix F UML 2.1 UML 2.2 Resolved closed
UML22-218 Section: 8.3.1 UML 2.1.1 UML 2.2 Resolved closed
UML22-217 General ordering cycles UML 2.0 UML 2.2 Resolved closed
UML22-215 What exactly is a state list? UML 2.0 UML 2.2 Resolved closed
UML22-214 Section: 9.14.2 UML 2.0 UML 2.2 Resolved closed
UML22-213 Section: 11.1.3 UML 2.0 UML 2.2 Resolved closed
UML22-212 Action inputs/outputs UML 2.0 UML 2.2 Resolved closed
UML22-225 Section: 7.3.44 UML 2.1.1 UML 2.2 Resolved closed
UML22-221 Section: 7.2 UML 2.1 UML 2.2 Resolved closed
UML22-220 Page: 64 & 112 UML 2.1.1 UML 2.2 Resolved closed
UML22-219 Completion event modeling UML 2.0 UML 2.2 Resolved closed
UML22-216 Editorial bug in 2.1 Superstructure Convenience document UML 2.0 UML 2.2 Resolved closed
UML22-183 7.3.4 Association Class UML 2.0 UML 2.2 Resolved closed
UML22-334 UML 2.2 scope statement UML 2.1 UML 2.2 Resolved closed
UML22-333 Property::isAttribute() query needs no argument UML 2.1 UML 2.2 Resolved closed
UML22-330 Section: 11.4 UML 2.1 UML 2.2 Resolved closed
UML22-329 Section: 11.4 Classifiers Diagram UML 2.1 UML 2.2 Resolved closed
UML22-340 Actor concept was indeed changed UML 2.1 UML 2.2 Resolved closed
UML22-339 Section: 13.3.3 UML 2.1 UML 2.2 Resolved closed
UML22-343 composite subsets UML 2.1 UML 2.2 Resolved closed
UML22-342 UML 2.1.2: Path names for CMOF files UML 2.1 UML 2.2 Resolved closed
UML22-332 Section: 7.3.21 figure 7.47 UML 2.1.1 UML 2.2 Resolved closed
UML22-331 Section: 7.3.21 UML 2.1.1 UML 2.2 Resolved closed
UML22-337 Section: Abstractions (02) UML 2.1 UML 2.2 Resolved closed
UML22-336 Section: Constructs UML 2.1 UML 2.2 Resolved closed
UML22-338 Namespace URI for Standard Profile(s) UML 2.1 UML 2.2 Resolved closed
UML22-335 Section: Abstractions UML 2.1 UML 2.2 Resolved closed
UML22-341 Section: 14.3.3 UML 2.1.1 UML 2.2 Resolved closed
UML22-264 Invalid mandatory compositions and associations UML 2.0 UML 2.2 Resolved closed
UML22-263 11.3.47 on StructuralFeatureAction (and related sections on subclasses) UML 2.0 UML 2.2 Resolved closed
UML22-262 Section: 9.16.1 UML 2.0 UML 2.2 Resolved closed
UML22-261 Section: 9.19.1 UML 2.0 UML 2.2 Resolved closed
UML22-258 Section: 9.12.1 UML 2.0 UML 2.2 Resolved closed
UML22-257 Merged Metam.:Property::class with redefinition of non-inherited property UML 2.0 UML 2.2 Resolved closed
UML22-265 Invalid redefinitions introduced into metamodel UML 2.1 UML 2.2 Resolved closed
UML22-267 Section: 13.2 UML 2.1.1 UML 2.2 Resolved closed
UML22-266 Section: 11.3.5 UML 2.1 UML 2.2 Resolved closed
UML22-256 navigating from link to link ends UML 2.0 UML 2.2 Resolved closed
UML22-255 ExtensionEnd description refers to old use of navigability UML 2.0 UML 2.2 Resolved closed
UML22-260 Section: 9.10.3 UML 2.0 UML 2.2 Resolved closed
UML22-259 Section: 9.13 UML 2.0 UML 2.2 Resolved closed
UML22-270 Section: 7.3.3 UML 2.1.1 UML 2.2 Resolved closed
UML22-269 Figure 7.31 UML 2.1 UML 2.2 Resolved closed
UML22-268 Section: Annex C.1 UML 2.1.1 UML 2.2 Resolved closed
UML22-355 StructuredActivityNode [UML 2.1.1] UML 2.1.2 UML 2.2 Resolved closed
UML22-357 UML2 Issue - 'abstract' not listed in keyword Annex UML 2.1.2 UML 2.2 Resolved closed
UML22-356 UML2 issue: ProfileApplication treated as Import UML 2.1.2 UML 2.2 Resolved closed
UML22-348 context of Constraint UML 2.1.1 UML 2.2 Resolved closed
UML22-347 Section: 18.3.6 Profile (from Profiles) UML 2.1.1 UML 2.2 Resolved closed
UML22-354 Section: 7.3.33 UML 2.1.1 UML 2.2 Resolved closed
UML22-353 In section 7.3.12 Figure 7.38 UML 2.1.1 UML 2.2 Resolved closed
UML22-351 Incorrect word renders sentence meaningless: Chap. 12.3.41 UML 2.1.1 UML 2.2 Resolved closed
UML22-350 The section titled "Changes from previous UML" is not complete UML 2.1.1 UML 2.2 Resolved closed
UML22-346 first constraint for CombinedFragment UML 2.1.1 UML 2.2 Resolved closed
UML22-345 Section: 12.3.1 AcceptEventAction UML 2.1.1 UML 2.2 Resolved closed
UML22-344 RedefinableTemplateSignature UML 2.1.1 UML 2.2 Resolved closed
UML22-352 ElementImport UML 2.1.1 UML 2.2 Resolved closed
UML22-349 UML 2.1.1 - fig 7.14 UML 2.1.1 UML 2.2 Resolved closed
UML22-287 Section: 7 UML 2.1.1 UML 2.2 Resolved closed
UML22-286 Section: 15 UML 2.1 UML 2.2 Resolved closed
UML22-285 Section: 15 UML 2.0 UML 2.2 Resolved closed
UML22-295 UML 2.1 Spec, Interactions: 14.3.18 UML 2.1 UML 2.2 Resolved closed
UML22-294 UML 2.1 Spec, Interactions: 14.3.18 - InteractionUse UML 2.1 UML 2.2 Resolved closed
UML22-293 A_outgoing_source and A_incoming_target should not be bidirectional UML 2.1 UML 2.2 Resolved closed
UML22-289 UML 2 Superstructure/Components/overly stringent constraints UML 2.1 UML 2.2 Resolved closed
UML22-288 AcceptCallAction has not operation UML 2.1 UML 2.2 Resolved closed
UML22-291 Section: 14.3.10 UML 2.0 UML 2.2 Resolved closed
UML22-290 Section: 14.3.14 UML 2.0 UML 2.2 Resolved closed
UML22-297 UML2: notation issue UML 2.1 UML 2.2 Resolved closed
UML22-296 Section: e. g. 12.2. page 287 UML 2.0 UML 2.2 Resolved closed
UML22-292 A_end_role should not be bidirectional UML 2.1 UML 2.2 Resolved closed
UML22-298 ReplyAction::replyValue type is incorrct UML 2.1 UML 2.2 Resolved closed
UML22-201 assembly connectors UML 2.0 UML 2.2 Resolved closed
UML22-200 New Issue on multiple guillemot pairs for same element UML 2.0 UML 2.2 Resolved closed
UML22-210 11.3.26 OpaqueAction UML 2.0 UML 2.2 Resolved closed
UML22-209 Definition of stereotype placement requires a name UML 2.0 UML 2.2 Resolved closed
UML22-206 the default for a Property should not be inconsistent with its type UML 2.0 UML 2.2 Resolved closed
UML22-205 Section: 7.3.10 UML 2.1.1 UML 2.2 Resolved closed
UML22-204 packagedElement UML 2.0 UML 2.2 Resolved closed
UML22-203 ptc/06-01-02:14.3.14, Notation UML 2.0 UML 2.2 Resolved closed
UML22-207 UML's support for null values and semantics is unclear UML 2.0 UML 2.2 Resolved closed
UML22-211 UML 2/ Super / SendSignalEvent erratum UML 2.0 UML 2.2 Resolved closed
UML22-199 Question on InfrastrucutreLibrary::BehavioralFeatures::Parameter UML 2.0 UML 2.2 Resolved closed
UML22-208 "Property::lowerValue" is not a good name UML 2.0 UML 2.2 Resolved closed
UML22-202 Fig 7.14 UML 2.0 UML 2.2 Resolved closed
UML22-370 Table 8.2 must be named "Graphic paths..." instead of "Graphic nodes..." UML 2.1.1 UML 2.2 Resolved closed
UML22-369 Datatypes in UML profiles UML 2.1.2 UML 2.2 Resolved closed
UML22-364 TemplateSignature / TemplateParameter / StructuredClassifier UML 2.1.2 UML 2.2 Resolved closed
UML22-363 inability to specify ordering of messages connected to gates is problematic UML 2.1.2 UML 2.2 Resolved closed
UML22-372 The semantics of an assembly connector remains unspecified UML 2.1.2 UML 2.2 Resolved closed
UML22-371 Table 8.2 UML 2.1.1 UML 2.2 Resolved closed
UML22-362 UML2: Missing ActionOutputPin UML 2.1.2 UML 2.2 Resolved closed
UML22-361 The spec needs to clarify the isConsistentWith() method for transitions UML 2.1.2 UML 2.2 Resolved closed
UML22-367 paragraph on "deferred events" on page 552 UML 2.1.2 UML 2.2 Resolved closed
UML22-366 Section 14.3.19 UML 2.1.2 UML 2.2 Resolved closed
UML22-360 Figure 7.6 UML 2.1.2 UML 2.2 Resolved closed
UML22-359 Section: 12 UML 2.1.1 UML 2.2 Resolved closed
UML22-368 15.3.14: This paragraph refers to signal and change events UML 2.1.2 UML 2.2 Resolved closed
UML22-358 Section: 8.3.2 Connector UML 2.1.1 UML 2.2 Resolved closed
UML22-365 UML 2.1.1 Issue: Invalid association end in Figure 7.20 UML 2.1.2 UML 2.2 Resolved closed
UML22-275 Section: 17.5 UML 2.0 UML 2.2 Resolved closed
UML22-274 UML 2 state machines / entry point outgoing transitions UML 2.1 UML 2.2 Resolved closed
UML22-278 Page 60 of the pdf UML 2.1 UML 2.2 Resolved closed
UML22-277 UML2: Parameter::isException overlaps with Operation::raisedException UML 2.1 UML 2.2 Resolved closed
UML22-279 uml.xsd schema file in ptc/2006-04-05 is not correctly generated UML 2.1 UML 2.2 Resolved closed
UML22-284 UML2: ReadSelfAction with a context cannot access behavior owned attributes UML 2.1 UML 2.2 Resolved closed
UML22-283 Activity shape UML 2.0 UML 2.2 Resolved closed
UML22-273 12.3.27 ExpansionRegion UML 2.1.1 UML 2.2 Resolved closed
UML22-272 12.3.26 ExpansionNode UML 2.1.1 UML 2.2 Resolved closed
UML22-281 Meaning of Constraint visibility UML 2.1 UML 2.2 Resolved closed
UML22-280 Section: 7.3.38 UML 2.1.1 UML 2.2 Resolved closed
UML22-276 Section: 12.3.2 Action UML 2.1.1 UML 2.2 Resolved closed
UML22-271 redefined properties UML 2.1 UML 2.2 Resolved closed
UML22-282 Change references in Infra- and Superstructure to UML 2.1.1- URGENT ISSUE- UML 2.1 UML 2.2 Resolved closed
UML22-240 Section: Activities - Pin ordering semantics UML 2.1.1 UML 2.2 Resolved closed
UML22-239 Section Activities: Default weight UML 2.1.1 UML 2.2 Resolved closed
UML22-235 text of specs and corresponding XMI specs should be clarified UML 2.0 UML 2.2 Resolved closed
UML22-234 UML 2: "isLeaf" UML 2.0 UML 2.2 Resolved closed
UML22-227 Section: 15.3.14 Transition UML 2.0 UML 2.2 Resolved closed
UML22-226 Section: 7 UML 2.1.1 UML 2.2 Resolved closed
UML22-238 Figure 7.4 invalid redefines UML 2.0 UML 2.2 Resolved closed
UML22-237 EnumerationLiteral should constrain InstanceSpecification UML 2.0 UML 2.2 Resolved closed
UML22-233 Stereotype attributes inherited from Class UML 2.0 UML 2.2 Resolved closed
UML22-232 Section: 12.3.8 UML 2.1.1 UML 2.2 Resolved closed
UML22-231 Section 11.4.1 "Classifier" (in Constructs) UML 2.0 UML 2.2 Resolved closed
UML22-228 Notation (p 154, formal/05-07-04 ) UML 2.0 UML 2.2 Resolved closed
UML22-230 Section 11.4.1 "Classifier" (in Constructs) UML 2.0 UML 2.2 Resolved closed
UML22-229 Section 10.2.1 "Class" (in Basic) UML 2.0 UML 2.2 Resolved closed
UML22-236 Section: 15.3.12 UML 2.1.1 UML 2.2 Resolved closed
UML22-192 Section: 7.3.7 UML 2.0 UML 2.2 Resolved closed
UML22-191 AssociationClass is severely underspecified UML 2.0 UML 2.2 Resolved closed
UML22-190 Show an example of correct notation for the metamodel UML 2.0 UML 2.2 Resolved closed
UML22-185 Page: 338, 339 UML 2.1 UML 2.2 Resolved closed
UML22-184 Optional name attribute in NamedElement is misleading and insufficient UML 2.0 UML 2.2 Resolved closed
UML22-197 UML 2 Super / Components / connectors to interfaces UML 2.0 UML 2.2 Resolved closed
UML22-187 reference to Figure 12.87 missing UML 2.0 UML 2.2 Resolved closed
UML22-186 Section: 14.4 UML 2.0 UML 2.2 Resolved closed
UML22-194 No ObjectEvent corresponding to SendObjectAction UML 2.0 UML 2.2 Resolved closed
UML22-193 Fig 12.10 UML 2.0 UML 2.2 Resolved closed
UML22-189 Page: 625 UML 2.1 UML 2.2 Resolved closed
UML22-188 UML 2.1/Superstructure/ call triggers vs signal triggers UML 2.0 UML 2.2 Resolved closed
UML22-196 Section: 12.3.48 UML 2.1 UML 2.2 Resolved closed
UML22-198 UML 2.2 RTF issue - line styles for profiles UML 2.0 UML 2.2 Resolved closed
UML22-195 UML 2 Super / Composite Structure / ambiguous constraint UML 2.0 UML 2.2 Resolved closed
UML22-132 Section: 15.3.12 UML 2.0 UML 2.2 Resolved closed
UML22-131 Section: 11.5.1 DataType (as specialized) UML 2.0 UML 2.2 Resolved closed
UML22-141 event parameters UML 2.0 UML 2.2 Resolved closed
UML22-140 Meaning of navigability UML 1.4.2 UML 2.2 Resolved closed
UML22-130 Section: 11.3.13 TypedElement (as specialized) UML 2.0 UML 2.2 Resolved closed
UML22-129 Section: 11.3.6 Classifiers diagram UML 2.0 UML 2.2 Resolved closed
UML22-139 Page: 62 UML 2.0 UML 2.2 Resolved closed
UML22-138 page 134, Chapter 11.4.1 UML 1.4.2 UML 2.2 Resolved closed
UML22-137 page 97, Chapter 10.2.2. MultiplicityElement UML 1.4.2 UML 2.2 Resolved closed
UML22-125 Page: 129 UML 2.0 UML 2.2 Resolved closed
UML22-124 Page: 369/370 UML 2.0 UML 2.2 Resolved closed
UML22-136 Page: 157,162,163 UML 2.0 UML 2.2 Resolved closed
UML22-135 ObjectNode UML 1.4.2 UML 2.2 Resolved closed
UML22-127 9.1 BehavioralFeature package UML 2.0 UML 2.2 Resolved closed
UML22-126 Page: 532 UML 2.0 UML 2.2 Resolved closed
UML22-134 UseCase and Actors UML 1.4.2 UML 2.2 Resolved closed
UML22-133 Page: 423 UML 2.0 UML 2.2 Resolved closed
UML22-128 Section: 10.1 Types Diagram UML 1.4.2 UML 2.2 Resolved closed
UML22-93 Figure 179 (Control nodes) UML 1.4.2 UML 2.2 Resolved closed
UML22-92 Section: D.4 UML 2.0 UML 2.2 Resolved closed
UML22-91 Section: 15.3.8 (second issue) UML 2.0 UML 2.2 Resolved closed
UML22-90 Section: 18.3.6 UML 2.0 UML 2.2 Resolved closed
UML22-89 Section: 17 UML 2.0 UML 2.2 Resolved closed
UML22-102 Section: 8.3.1 UML 2.0 UML 2.2 Resolved closed
UML22-101 Section: Actions UML 1.4.2 UML 2.2 Resolved closed
UML22-100 CombinedFragment Loop notation UML 1.4.2 UML 2.2 Resolved closed
UML22-99 Section: 7.3.36 UML 2.0 UML 2.2 Resolved closed
UML22-98 editorial in section 12 UML 1.4.2 UML 2.2 Resolved closed
UML22-97 UML 2 Different constraints for Property in Super and Infra UML 1.4.2 UML 2.2 Resolved closed
UML22-107 Activities UML 2.0 UML 2.2 Resolved closed
UML22-106 Clarify multiple inputs to expansion regions UML 2.0 UML 2.2 Resolved closed
UML22-105 DataStoreNode has uniqueness, reverse constraint inherited from ObjectNode UML 2.0 UML 2.2 Resolved closed
UML22-87 Add constraints on conditional, loop, sequence to rule out node contents UML 2.0 UML 2.2 Resolved closed
UML22-86 Section: Activities, LoopNode UML 2.0 UML 2.2 Resolved closed
UML22-96 rewording isuse? UML 1.4.2 UML 2.2 Resolved closed
UML22-95 reword sentence UML 1.4.2 UML 2.2 Resolved closed
UML22-94 A test cannot be empty UML 1.4.2 UML 2.2 Resolved closed
UML22-104 Misleading statement about multiplicity in AssociationClass UML 2.0 UML 2.2 Resolved closed
UML22-103 Client/supplier on dependencies UML 2.0 UML 2.2 Resolved closed
UML22-88 Constrain conditional node to have body pins if there is a result pin. UML 2.0 UML 2.2 Resolved closed
UML22-2 Starting state machine UML 1.4 UML 2.2 Resolved closed
UML22-3 Starting a state machine UML 1.4 UML 2.2 Resolved closed
UML22-5 saying {nonunique} on one end of a binary association is meaningless UML 1.5 UML 2.2 Resolved closed
UML22-4 behaviour of the shallow history state and deep history state UML 1.5 UML 2.2 Resolved closed
UML22-173 On page 26, Figure 7.9 UML 2.0 UML 2.2 Resolved closed
UML22-172 choice of terminolgy for TransitionKind is non-intuitive UML 2.0 UML 2.2 Resolved closed
UML22-171 Section: 15.3.15 UML 2.0 UML 2.2 Resolved closed
UML22-170 Section 8.3.2 sub-section "Notation" starting on page 149 UML 2.0 UML 2.2 Resolved closed
UML22-169 inconsistency wrt UML2 classifier behavior UML 2.0 UML 2.2 Resolved closed
UML22-168 keyword, "buildcomponent", and a stereotype, "buildComponent" UML 2.0 UML 2.2 Resolved closed
UML22-182 Element and Comment in Basic UML 2.0 UML 2.2 Resolved closed
UML22-181 Description of Element UML 2.0 UML 2.2 Resolved closed
UML22-180 Unclear relationship between the Basic and Abstractions packages UML 2.0 UML 2.2 Resolved closed
UML22-179 XMI file: Core::Constructs::Operation::bodyCondition should have upper boun UML 2.0 UML 2.2 Resolved closed
UML22-178 /qualifiedName attribute missing on Core::Constructs::NamedElement UML 2.0 UML 2.2 Resolved closed
UML22-177 Operation::ownedParameter should be ordered in XMI? UML 2.0 UML 2.2 Resolved closed
UML22-176 Section: Classes UML 2.0 UML 2.2 Resolved closed
UML22-175 constraints owned by these properties have no context UML 2.0 UML 2.2 Resolved closed
UML22-174 Operation should be a specialization of TypedElement and MultiplicityElemen UML 2.0 UML 2.2 Resolved closed
UML22-167 section, 12.3.27 ExpansionRegion(from ExtarStructureActivities UML 2.0 UML 2.2 Resolved closed
UML22-166 (merged) compliance levels L2 and L3 UML 2.0 UML 2.2 Resolved closed
UML22-165 (merged) compliance level L1 UML 2.0 UML 2.2 Resolved closed
UML22-164 Section: 14.3.20 Message (from BasicInteractions) UML 2.0 UML 2.2 Resolved closed
UML22-163 Section: Activities UML 2.0 UML 2.2 Resolved closed
UML22-22 UML 2 Issue: Qualified pathnames UML 1.5 UML 2.2 Resolved closed
UML22-35 show object flow or interactions UML 1.5 UML 2.2 Resolved closed
UML22-34 UML 2 Super/Interactions/Need constraints that cover multiple Lifelines UML 1.5 UML 2.2 Resolved closed
UML22-24 ptc-03-09-15/Separate classification and generalization in Core::Basic UML 1.5 UML 2.2 Resolved closed
UML22-23 Ports in Protocol State Machines UML 1.5 UML 2.2 Resolved closed
UML22-33 StateMachine - Constraints UML 2.0 UML 2.2 Resolved closed
UML22-32 transtion UML 2.0 UML 2.2 Resolved closed
UML22-27 UML2 Super/Kernel Classes UML 1.5 UML 2.2 Resolved closed
UML22-26 UML Superstructure FTF : isRoot property disappeared UML 1.5 UML 2.2 Resolved closed
UML22-30 Inheritance of 'Enumerations' is not detailed UML 2.0 UML 2.2 Resolved closed
UML22-29 Part subtype UML 1.5 UML 2.2 Resolved closed
UML22-31 manage simultaneity of events UML 2.0 UML 2.2 Resolved closed
UML22-25 Federated models - UML2 issue UML 1.5 UML 2.2 Resolved closed
UML22-28 UML 2.0 Kernel Operations Diagram and Features Diagram and mdl UML 1.5 UML 2.2 Resolved closed
UML22-112 External exceptions. UML 2.0 UML 2.2 Resolved closed
UML22-111 Clarify which classifier or operation this is referring to UML 2.0 UML 2.2 Resolved closed
UML22-110 represents and occurrence keywords are switched UML 2.0 UML 2.2 Resolved closed
UML22-114 Events in Sequence diagram UML 1.4.2 UML 2.2 Resolved closed
UML22-113 1. Deployment UML 1.4.2 UML 2.2 Resolved closed
UML22-116 Section: Action/Activity UML 2.0 UML 2.2 Resolved closed
UML22-115 Nested Nodes UML 1.4.2 UML 2.2 Resolved closed
UML22-119 Input tokens to LoopNodes should be destroyed when the loop is done UML 2.0 UML 2.2 Resolved closed
UML22-118 Section: 8.3.1 UML 2.0 UML 2.2 Resolved closed
UML22-123 Section: Classes UML 2.0 UML 2.2 Resolved closed
UML22-122 Section: 12.3.2 Action UML 2.0 UML 2.2 Resolved closed
UML22-109 In Figure 12, ownedAttribute is bidirectional, in Figure 95, it is unidirec UML 2.0 UML 2.2 Resolved closed
UML22-108 StructuredActivityNode, Semantics, third paragraph, first sentence, UML 2.0 UML 2.2 Resolved closed
UML22-117 Section: 9.3.7 UML 2.0 UML 2.2 Resolved closed
UML22-120 Return message UML 1.4.2 UML 2.2 Resolved closed
UML22-121 multiplicity should not be used/shown in an communicates association UML 1.4.2 UML 2.2 Resolved closed
UML22-76 Section: 14 UML 2.0 UML 2.2 Resolved closed
UML22-75 Section: 14.3.18 UML 2.0 UML 2.2 Resolved closed
UML22-74 RemoveStructuralFeatureValueAction specification UML 2.0 UML 2.2 Resolved closed
UML22-73 inconsistent description UML 1.4.2 UML 2.2 Resolved closed
UML22-82 Decision node UML 2.0 UML 2.2 Resolved closed
UML22-81 Section: Actions UML 2.0 UML 2.2 Resolved closed
UML22-80 UML 2 Super / Kernel / invalid restriction in isConsistentWith() UML 1.4.2 UML 2.2 Resolved closed
UML22-67 namespace UML 1.4.2 UML 2.2 Resolved closed
UML22-66 Figure 89 on page 158 is incorrect UML 1.4.2 UML 2.2 Resolved closed
UML22-72 Section: 13.3.17 UML 2.0 UML 2.2 Resolved closed
UML22-71 Section: 13.3.11 UML 2.0 UML 2.2 Resolved closed
UML22-70 UML2/Infra section 11.6.2/ Enumerations should not have attributes UML 1.4.2 UML 2.2 Resolved closed
UML22-79 Default values for ValueSpecification are not specified properly UML 1.4.2 UML 2.2 Resolved closed
UML22-78 Section 15 UML 2.0 UML 2.2 Resolved closed
UML22-77 Section: 14 UML 2.0 UML 2.2 Resolved closed
UML22-69 Section: 12.3.40 UML 2.0 UML 2.2 Resolved closed
UML22-68 Section: 12.3.33 UML 2.0 UML 2.2 Resolved closed
UML22-84 Section: Classes UML 2.0 UML 2.2 Resolved closed
UML22-83 Section: Activities UML 2.0 UML 2.2 Resolved closed
UML22-65 Section: 10.3.11 UML 2.0 UML 2.2 Resolved closed
UML22-85 Section: Interactions UML 2.0 UML 2.2 Resolved closed
UML22-155 Section: Common Behavior UML 2.0 UML 2.2 Resolved closed
UML22-154 Section: Classes (02) UML 2.0 UML 2.2 Resolved closed
UML22-153 Section: Common Behavior (02) UML 2.0 UML 2.2 Resolved closed
UML22-152 Section: Common Behavior UML 2.0 UML 2.2 Resolved closed
UML22-151 Property ownership must be consistent across association redefinitions UML 2.0 UML 2.2 Resolved closed
UML22-150 Missing notation for association classes UML 2.0 UML 2.2 Resolved closed
UML22-149 Page: 346-347 UML 2.0 UML 2.2 Resolved closed
UML22-148 Page: 255 UML 2.0 UML 2.2 Resolved closed
UML22-147 Behavior UML 2.0 UML 2.2 Resolved closed
UML22-144 UML 2 - Invalid subsetting of composition ends UML 2.0 UML 2.2 Resolved closed
UML22-143 UML 2 Super / Actions / Compliance Levels of Actions UML 2.0 UML 2.2 Resolved closed
UML22-162 Page: 53-55 UML 2.0 UML 2.2 Resolved closed
UML22-161 "ownedType" is not a valid element UML 2.0 UML 2.2 Resolved closed
UML22-158 Section: Classes UML 2.0 UML 2.2 Resolved closed
UML22-157 Section: Classes UML 2.0 UML 2.2 Resolved closed
UML22-156 Section: Activities UML 2.0 UML 2.2 Resolved closed
UML22-146 UML SuperStructure - Inconsistency re State Machine terms UML 2.0 UML 2.2 Resolved closed
UML22-145 Section: 14.3.20 UML 2.0 UML 2.2 Resolved closed
UML22-160 Section: 16.3.3 UML 2.0 UML 2.2 Resolved closed
UML22-159 Section: Activities UML 2.0 UML 2.2 Resolved closed
UML22-142 Page: 420 UML 2.0 UML 2.2 Resolved closed
UML22-36 Connector - "provided Port" and "required Port" not defined Constraint 1 UML 2.0 UML 2.2 Resolved closed
UML22-46 isComposite inconsistency in UML 2.0 and MOF 2.0 UML 1.4.2 UML 2.2 Resolved closed
UML22-48 Section: 9.14.1 UML 2.0 UML 2.2 Resolved closed
UML22-47 should retain Comment and its associations to Element UML 1.4.2 UML 2.2 Resolved closed
UML22-42 Notation sections for TimeObservation and DurationObservation UML 2.0 UML 2.2 Resolved closed
UML22-41 completion transitions UML 1.5 UML 2.2 Resolved closed
UML22-38 Connector - inconsistencies in Constraint[3] UML 2.0 UML 2.2 Resolved closed
UML22-37 Connector - inconsistencies in Constraint [2] UML 2.0 UML 2.2 Resolved closed
UML22-40 Connector - inconsistencies in Constraint[5] UML 2.0 UML 2.2 Resolved closed
UML22-39 Connector - inconsistencies in Constraint[4] UML 2.0 UML 2.2 Resolved closed
UML22-50 Presentation Options UML 2.0 UML 2.2 Resolved closed
UML22-49 Use case extension inconsistencies UML 1.4.2 UML 2.2 Resolved closed
UML22-45 AssociationClass UML 1.5 UML 2.2 Resolved closed
UML22-44 useless example on p.330, Figure 247 UML 2.0 UML 2.2 Resolved closed
UML22-43 Property defines an association "datatype" which is redundant UML 2.0 UML 2.2 Resolved closed
UML22-57 Multiple typos in ptc/04-10-02 UML 2.0 UML 2.2 Resolved closed
UML22-56 Clarify the differences between redefining element and redefined element. UML 2.0 UML 2.2 Resolved closed
UML22-55 All sections UML 2.0 UML 2.2 Resolved closed
UML22-54 ClassifierInState not supported in UML2.0 ? UML 1.4.2 UML 2.2 Resolved closed
UML22-64 Section: 9.3.11 UML 2.0 UML 2.2 Resolved closed
UML22-63 Section: 8.3.2 UML 2.0 UML 2.2 Resolved closed
UML22-51 constrainedElement direction UML 2.0 UML 2.2 Resolved closed
UML22-53 Association specialization semantics UML 1.4.2 UML 2.2 Resolved closed
UML22-52 Derived union notation UML 2.0 UML 2.2 Resolved closed
UML22-61 Section: 9.3.7 UML 2.0 UML 2.2 Resolved closed
UML22-60 Section: 9.3.6 UML 2.0 UML 2.2 Resolved closed
UML22-62 Section: 8.3.2 UML 2.0 UML 2.2 Resolved closed
UML22-58 Section: 8.3.2 UML 2.0 UML 2.2 Resolved closed
UML22-59 Section: 9.3.4 UML 2.0 UML 2.2 Resolved closed
UML22-7 Reentrancy 1 UML 1.5 UML 2.2 Resolved closed
UML22-6 Suspension Region UML 1.5 UML 2.2 Resolved closed
UML22-18 UML 2 Super / Missing OCL constraints UML 1.5 UML 2.2 Resolved closed
UML22-17 03-04-01 Chap 2 p. 112/Components: Different ways to wire components UML 1.5 UML 2.2 Resolved closed
UML22-20 UML 2 Issue: AssociationEnd UML 1.5 UML 2.2 Resolved closed
UML22-19 instantiations of Classifiers UML 1.5 UML 2.2 Resolved closed
UML22-15 Section 9.3.3 UML 1.5 UML 2.2 Resolved closed
UML22-14 UML 2 Super/Interactions/missing OCL constraints UML 1.5 UML 2.2 Resolved closed
UML22-10 UML 2 Super/Metamodel/redefinition and substitutability UML 1.5 UML 2.2 Resolved closed
UML22-9 Target pin notation UML 1.5 UML 2.2 Resolved closed
UML22-12 Notes versus curly braces UML 1.5 UML 2.2 Resolved closed
UML22-11 Activity OCL UML 1.5 UML 2.2 Resolved closed
UML22-16 UML2 super/ad-03-04-01/Derived attributes and associations UML 1.5 UML 2.2 Resolved closed
UML22-13 UML 2 super / Dependencies / improper subsetting? UML 1.5 UML 2.2 Resolved closed
UML22-8 State extension UML 1.5 UML 2.2 Resolved closed
UML22-1 Semantics of firing compound transitions still appears to be circular UML 1.3 UML 2.2 Resolved closed
UMLR-616 UML 2.5: UML redefinition mechanism insufficiently granular UML 2.5 open
UMLR-347 UML 2.5 Beta 2 XMI invalid UML 2.5 open
UMLR-421 Missing Example of TemplateBinding with model element "Class" UML 2.5b1 open
UMLR-415 Object Flow arrow heads are inconsistent: V-shaped vs triangular UML 2.5 open
UMLR-410 More on SateMachines UML 2.5 open
UMLR-409 Figure 14.5 State with Compartments does not show all the compartments that it should UML 2.5 open
UMLR-408 BNF notation as given and used is unclear about italics UML 2.5 open
UMLR-407 Figure 14.14 includes a "Submachine Sate" UML 2.5 open
UMLR-418 InformatonFlows are constrained to be Classes or Classifiers -- which one? UML 2.5 open
UMLR-417 Are DeploymentSpecification execution-time input to components -- meaning they are somehow read by the component while they are running/executng? UML 2.5 open
UMLR-416 Can be performed their instances --> missing "by" UML 2.5 open
UMLR-413 A State can only have one Do/ behavior, but example shows more than one. UML 2.5 open
UMLR-412 Some hyperlinks are underlined and some are not. This is inconsistent UML 2.5 open
UMLR-424 UML 2.5: Property::isConsistentWith() error UML 2.5 open
UMLR-423 UML 2.5 beta issue - Operation notation is wrong UML 2.5b1 open
UMLR-422 UML2::Constraint UML 2.2 open
UMLR-411 These are typographical errors UML 2.5 open
UMLR-403 Shouldn't it be possible to make the state of an object be private to support encapsulation/information hiding?. UML 2.5 open
UMLR-402 States of Reachable objects may be used in guard constraints, but reachable is not defined UML 2.5 open
UMLR-414 Any Activity parameter is steaming. It must be too hot to handle UML 2.5 open
UMLR-405 adding error UML 2.5 open
UMLR-401 orthogonal State missing on bullet point list UML 2.5 open
UMLR-391 Use of Qualifier and Qualified in same section of UML 2.5 spec should be more clearly disambiguated UML 2.5 open
UMLR-386 UML needs standardized default package (or Model) UML 2.5 open
UMLR-387 shoes-->shows UML 2.5 open
UMLR-380 In Sequence diagrams it is unclear if the name of the Gate can be different from the name of the message UML 2.5 open
UMLR-361 Inconsistent use of Oxford comma in "Behavior, Event, and Trigger" UML 2.5 open
UMLR-358 AcceptEventActions where the triggers are all for ChangeEvents or CallEvents should allow output ControlPins UML 2.5 open
UMLR-360 Minor error in ptc-13-09-05 UML 2.5 open
UMLR-352 Pin multiplicity and token upper bound UML 2.5 open
UMLR-346 Classifier::ownedTemplateSignature needs to subset Element::ownedElement UML 2.5 open
UMLR-345 Issue against UML: implementation of OCL constraint containingProfile UML 2.5 open
UMLR-344 No specification of which visibility marking corresponds to which VisibilityKind value UML 2.5 open
UMLR-340 ExpansionNodes owned by ExpansionRegions? UML 2.5 open
UMLR-339 Incorrect sentence UML 2.5b1 open
UMLR-342 BehavioralParameter should be BehavioralFeature UML 2.5 open
UMLR-341 UML wording in Superstructure 2.4.1 UML 2.5 open
UMLR-337 Message should extend Namespace UML 2.5 open
UMLR-343 Semantics of static features UML 2.5 open
UMLR-338 Incomplete sentence UML 2.5b1 open
UMLR-305 Rg. Reception.ownedParameter UML 2.5 open
UMLR-308 Generalization should be limited to relate similar UML-elements UML 2.5 open
UMLR-307 Type conformance for classifiers UML 2.5 open
UMLR-300 Notation for PrimitiveTypes UML 2.5 open
UMLR-299 Problems with normative UML 2.5 Beta 2 Standard profile UML 2.5 open
UMLR-304 Descriptions missing for PseudostateKind literals UML 2.5 open
UMLR-303 Clause 21 Primitive Types is misnamed UML 2.5 open
UMLR-298 Problem with NamedElement::clientDependency subsets in UML 2.5 Beta 2 UML 2.5 open
UMLR-301 Can PrimitiveTypes be user-defined and where? UML 2.5 open
UMLR-302 A PrimitiveType can/cannot have owned attributes. UML 2.5 open
UMLR-310 InstanceSpecification validity is not modelable UML 2.5 open
UMLR-309 Missing OpaqueXXX body constraint UML 2.5 open
UMLR-259 UML Appendix A: After Figure A.4 UML 2.5 open
UMLR-258 UML: unification of OCL declarations UML 2.5 open
UMLR-260 Clarification about serializing the application of SysML 1.3 to a UML2.4.1 model UML 2.5 open
UMLR-264 OccurrenceSpecification should have at least an optional notation UML 2.4 open
UMLR-262 Message arguments for a Signal signature too restrictive UML 2.4 open
UMLR-261 Relation of message arguments to signature parameters ambiguous UML 2.4 open
UMLR-265 The included use case is always required for the including use case to execute correctly UML 2.4.1 open
UMLR-268 Concerning Transition and its owned elements UML 2.5 open
UMLR-266 Abstraction::mapping should be of type ValueSpecification or OpaqueExpression UML 2.4 open
UMLR-263 Message arguments should not be contained in a message UML 2.4 open
UMLR-267 UML 2.4/2.5 Aliases UML 2.5 open
UMLR-236 Under-specified associations in UML2.4 & the need for clarifying the semantic directionality for all UML associations UML 2.5 open
UMLR-235 Issue on UML 2.4 - notation for Component::provided UML 2.5 open
UMLR-233 Nasty UML 2.x Issue - /qualifiedName is not unambiguous UML 2.5 open
UMLR-242 Creation of an expansion node under an activity is allowed by UML and SysML specifications UML 2.3 open
UMLR-241 Part document structures in Superstructure need to conform to ISO standard Document Template Conventions UML 2.5 open
UMLR-230 How to specify actual parameters to pass to parameterized submachine StateMachine UML 2.5 open
UMLR-229 Ports UML 2.5 open
UMLR-228 Initialization of complex fields UML 2.5 open
UMLR-238 UML 2 issue: connectors typed by Association Class UML 2.5 open
UMLR-237 Clarifying the support for and semantics of subsetting/redefinition for a pair of properties defined in different contex UML 2.5 open
UMLR-240 UML 2.3 Infra 12 Incomplete conformance for infinity UML 2.5 open
UMLR-239 No Constraint for multiple associations UML 2.3b1 open
UMLR-232 Aggregation missing from Property string syntax UML 2.5 open
UMLR-231 Issue on UML 2.3 - Use of isAbstract for Interfaces UML 2.5 open
UMLR-244 Retationships and composite structures UML 2.5 open
UMLR-394 How is an attribute that is not a part, a role? UML 2.5 open
UMLR-393 Lack of clarify of attribute vs attribute value. UML 2.5 open
UMLR-392 Generalizations should allow enumeration types as PowerTypes. UML 2.5 open
UMLR-396 Caption for Table 9.1 on wrong page UML 2.5 open
UMLR-395 Making the default for Generalization isDisjoint=False is contrary to modelers' expectations. UML 2.5 open
UMLR-390 Continuation examples are missing InteractionConstraints for the Alternative CombinedFragment UML 2.5 open
UMLR-389 Extraneous " (double quote) in 17.6.3 Semantics UML 2.5 open
UMLR-388 As no UML operators are defined, it is not possible to write a UML Expression UML 2.5 open
UMLR-364 As Events are Packageable Elements, how is their Package known? UML 2.5 open
UMLR-365 Use Cases both can and cannot have BehavioralFeatures UML 2.5 open
UMLR-363 Semantics of Executable Nodes does not cover Control Flows on Control Pins UML 2.5 open
UMLR-362 A type defines a set member (not a set) UML 2.5 open
UMLR-353 2 Conformance: Missing Oxford comma in Item #2. UML 2.5 open
UMLR-333 UML 2.5 Mandatory but suppressible compartments UML 2.5 open
UMLR-332 UML 2.6 Issue --- SignalEvent Triggers UML 2.5 open
UMLR-327 Incorrectly drawn ParameterableElement.owningTemplateParameterSubstitution multiplicity UML 2.5 open
UMLR-326 Incorrect drawing of non-navigable redefined opposites UML 2.5 open
UMLR-330 Incorrect OrderedSet returns UML 2.5 open
UMLR-335 Figures 15.45 and 15.46 in the spec are bad examples as they are of malformed activity diagrams UML 2.5 open
UMLR-336 meaning is not clear UML 2.5b1 open
UMLR-334 Incorrect Result in ReduceAction Example UML 2.5 open
UMLR-331 Specification should not contain any methodology UML 2.5 open
UMLR-290 Improving the association direction notation UML 2.5 open
UMLR-291 Sequence Diagram: Message limitation UML 2.5 open
UMLR-287 Use cases and use of arrows UML 2.5 open
UMLR-286 Even if Use Cases need not have an actor, there is some ambiguity when there is an «include»d or «extension» use case UML 2.5 open
UMLR-295 Information flow instantiation UML 2.5 open
UMLR-294 Cannot set an activity as the source or target of an information flow UML 2.4.1 open
UMLR-289 Description of the OCL on Actor does not match OCL and both are obsolete. UML 2.5 open
UMLR-293 About prescribed port implementation UML 2.5 open
UMLR-297 Problem with MultiplicityELement::lower redefinition in UML 2.5 Beta 2 UML 2.5 open
UMLR-296 BehavioredClassifier should redefine Classifier::conformsTo to include interfaceRealization UML 2.5 open
UMLR-288 No rules on Extension Pts governing differences between Use Case definitions & «extend» relationships usage UML 2.5 open
UMLR-285 Abstract Syntax diagram for Use Cases UML 2.5 open
UMLR-257 Navigability orthogonal to end ownership or not? UML 2.3 open
UMLR-256 Ambiguous stereotype notation UML 2.5 open
UMLR-248 Notation of Lifelines UML 2.5 open
UMLR-247 Tags typed by classes/blocks UML 2.5 open
UMLR-246 XMI representation of stereotype application UML 2.5 open
UMLR-245 New notation for attribute UML 2.5 open
UMLR-254 Use cases specifying the same subject cannot be associated: exception UML 2.4 open
UMLR-252 Metaclass stereotype notion (02) UML 2.4 open
UMLR-251 Metaclass stereotype notion UML 2.4 open
UMLR-250 Profile URI Attribute - Mingled URI Definition and Use in XMI UML 2.4 open
UMLR-253 State::stateInvariant multiplicity too restrictive UML 2.5 open
UMLR-249 Package URI Attribute Uses Obsolete RFC 2396 UML 2.4 open
UMLR-255 A deferrable trigger may have a guard UML 2.4 open
UMLR-227 Owning of interaction fragments is ambiguous when InteractionOperands are present UML 2.5 open
UMLR-226 Chapter 14 is ambiguous and contradictory about how to link up messages and execution specifications UML 2.5 open
UMLR-225 issue10087 and association-like notation UML 2.5 open
UMLR-224 not sure it is possible to define a constraint without a context UML 2.5 open
UMLR-223 Timing Diagram and interchange UML 2.5 open
UMLR-400 Missing constraints preventing contradictory GeneralizationSets. UML 2.5 open
UMLR-399 What is the default setting for disjoint/overlapping and complete/incomplete for generalizations that are not part of a GeneralizationSet UML 2.5 open
UMLR-398 How can a GeneralizationSet not have any Generalizations? UML 2.5 open
UMLR-397 Ambiguity in description of TransitionKind UML 2.5 open
UMLR-385 Two classes can share attributes by use of element import UML 2.5 open
UMLR-383 History pseudo states in protocol state machines UML 2.5 open
UMLR-381 Message lines can cross without the first being asynchronous UML 2.5 open
UMLR-382 Justification for messages on differnent sides of a gate being identical is not clear. UML 2.5 open
UMLR-369 Tables 17.1, 17.3, 17.5, 17.6 Header Formats UML 2.5 open
UMLR-379 Need clarification between exceptionType and the type of the exceptionInput UML 2.5 open
UMLR-378 Does not seem possible to have an exception cause an interrupt (leave the region) UML 2.5 open
UMLR-377 What exception type is "any" exceptionType UML 2.5 open
UMLR-373 Vertical lines do not always describe the time-line for an interaction diagram UML 2.5 open
UMLR-367 Spelling error in ActivityGoups UML 2.5 open
UMLR-370 Message wildcards appear to ignore operation default values UML 2.5 open
UMLR-372 use of ! instead of + or ∪ UML 2.5 open
UMLR-371 Extraneous " (double quote) in 17.5.4 BehaviorExecutionSpecification UML 2.5 open
UMLR-376 Coloring and shading on Figure 17.10 should be removed UML 2.5 open
UMLR-375 Caption for Table 17.5 on wrong page UML 2.5 open
UMLR-368 Mismatch of singular/plural Activity Goups are a grouping constructs UML 2.5 open
UMLR-357 SignalBroadcastAction used where BroadcastSignalAction should be. UML 2.5 open
UMLR-356 Spelling error: i-->is UML 2.5 open
UMLR-350 UML 2.5 Section 15.2.3 p392 description for the ActivityEdge weight UML 2.5 open
UMLR-349 Another UML 2.5 Beta 2 XMI invalidity UML 2.5 open
UMLR-323 Unclear statement regarding Lifeline shape UML 2.5 open
UMLR-322 UML 2.5 Overly strict restriction on message slope in seq diagrams UML 2.5 open
UMLR-325 Unnamed elements in a namespace UML 2.5 open
UMLR-324 Including use case depends on included use case but Include is no subclass of Dependency UML 2.5 open
UMLR-318 UML 2.5 Visibility of a packagedElement UML 2.5 open
UMLR-317 UML 2.5 Issue on DI for reply arrows UML 2.5 open
UMLR-316 Ambiguous Profile::profileApplication UML 2.5 open
UMLR-319 UML transition-centric state machine arrows (01) alternative exit pt vs entry pt notation UML 2.5 open
UMLR-321 UML 2.5 issue on examples in 17.4.5 UML 2.5 open
UMLR-320 UML transition-centric state machine arrows (02) solid vs v-shaped arrow heads UML 2.5 open
UMLR-312 UML 2.5 Figure 10.10 Error UML 2.5 open
UMLR-311 Name of Package in Figure 7.3 should be "Core" rather than "Constructs" UML 2.4.1 open
UMLR-313 Multiple Generalization Sets UML 2.5 open
UMLR-314 UML 2.5 Figure 14.25 Choice Pseudostates UML 2.5 open
UMLR-277 isReplaceAll=true and lowerBound > 1 UML 2.5 open
UMLR-276 test UML 2.5 open
UMLR-275 applying and associating stereotypes and explanation of all aspects of their serialization UML 2.5 open
UMLR-279 Relax Association::/endType from [1..*] to [0..*] UML 2.5 open
UMLR-278 Problems with OCL definition of Package::makesVisible UML 2.5 open
UMLR-274 Specifying the multiplicity of a part with an attribute UML 2.5 open
UMLR-273 Link notation for stereotype property value UML 2.5 open
UMLR-272 Generalization should be allowed to be cyclic and should no be restricted to be owned by the specialized classifier UML 2.5 open
UMLR-270 Interaction.action should subset ownedMember in lieu of ownedElement UML 2.4.1 open
UMLR-269 Message Signature in Interactions and Reception.ownedParameter UML 2.5 open
UMLR-271 Migrate UML::Component's ability to own UML::PackageableElements to UML::Class UML 2.5 open
UMLR-282 Semantic error in UMLAssociationOrConnectorOrLinkShape::edge_instancespec invariant UML 2.5 open
UMLR-281 Semantic error in Lifeline::interaction_uses_share_lifeline UML 2.5 open
UMLR-283 XMI.xmi is not merged UML 2.5 open
UMLR-284 In the Use Case section, it is unclear whether a use case requires an actor UML 2.5 open
UMLR-280 ExtensionEnd upper/lower inconsistent with MultiplicityElement UML 2.5 open
UMLR-159 Lack of clarity about meaning of package shapes containing elements with fully qualified names UML 2.5 open
UMLR-158 Section 9.3.4 Collaboration Use, 2nd constraint creates unneces UML 2.5 open
UMLR-153 UML: Standard Techniques to disambiguate crossing lines needed UML 2.5 open
UMLR-152 There is no way to specify the behavior of operations which are members of data types UML 2.5 open
UMLR-161 UML 2 - appearance of Association Ends as members of the related classes UML 2.5 open
UMLR-160 UML2.2. Contradications in 14.3.10 UML 2.5 open
UMLR-157 we can create an invalid active state configuration UML 2.2 open
UMLR-164 Concrete specialization of the Relationship meta-class are missing UML 2.2 open
UMLR-163 UML 2.2 InteractionOperand abstract syntax UML 2.5 open
UMLR-155 UML2: Unclear how to indicate what events a classifier might send UML 2.5 open
UMLR-154 UML2.2 RTF: EnumerationLiteral is a DeploymentTarget UML 2.5 open
UMLR-162 Section: 9.3.11 Port UML 2.5 open
UMLR-156 Section: 7.3.9 Comment should be NamedElement UML 2.2 open
UMLR-151 MARTE/section 7.2.1/ "several labels for the same classifiers in the Metamodel" bug UML 2.5 open
UMLR-122 Section: 16.3.5 UML 2.1.1 open
UMLR-121 Section: 7.3.3 UML 2.5 open
UMLR-126 Figure 7.48 and the accompanying discussion under 7.3.21 UML 2.1.1 open
UMLR-125 simpleTime package problems UML 2.5 open
UMLR-124 Section: 7.3.37 Package (from Kernel) UML 2.1.1 open
UMLR-123 UML2 Property collaborationRole should be removed UML 2.5 open
UMLR-128 UML2 Issue: notation for Literals does not allow for name UML 2.5 open
UMLR-127 Section: 14.4 UML 2.5 open
UMLR-130 should be able to show gates on communication diagrams UML 2.5 open
UMLR-129 pull semantics are only supported on Action inputs, not outputs UML 2.5 open
UMLR-135 new constraint ? UML 2.5 open
UMLR-134 Section 7.3.44 UML 2.1.2 open
UMLR-132 UML 2 has lost cability to represent operations by collaborations UML 2.1.2 open
UMLR-131 UML 2: Need an explicit listing of all semantic variation points UML 2.5 open
UMLR-133 Section: 7.3.41 UML 2.1.2 open
UMLR-76 No notation for associating Exceptions with Operations UML 2.5 open
UMLR-75 Page: 107 UML 2.0 open
UMLR-79 Section: 7.3.9 UML 2.1 open
UMLR-78 consistent ordering of Association::memberEnd and ownedEnd UML 2.5 open
UMLR-77 No ReadParameterAction or WriteParameterAction UML 2.5 open
UMLR-74 Need more flexible notation for activity partitions UML 2.5 open
UMLR-69 UML2 Super / 14.3.13 Interaction UML 2.5 open
UMLR-70 Section: Classes UML 2.0 open
UMLR-67 Syntax of Transition UML 2.5 open
UMLR-66 OutputPin UML 2.5 open
UMLR-73 Page: 492-493 UML 2.5 open
UMLR-72 Section: Classes UML 2.0 open
UMLR-71 Section: Activities UML 2.0 open
UMLR-40 Properties on Association for end objects UML 2.0 open
UMLR-39 Notation for classifierBehavior UML 2.0 open
UMLR-38 Contextualized attribute values Figures 121 UML 2.0 open
UMLR-42 ReadStructuralFeatureAction UML 2.0 open
UMLR-34 Section: Classes, Behavior UML 2.0 open
UMLR-37 End objects of a link In the semantics of AssociationClass UML 2.0 open
UMLR-36 Action for retrieving activity instance UML 2.0 open
UMLR-44 Activities section UML 2.0 open
UMLR-43 Section: 16.3.1 UML 2.0 open
UMLR-48 Add constraints on ConditionalNode UML 2.0 open
UMLR-47 ExpansionRegion (behavior in the shorthand notation) UML 2.0 open
UMLR-46 Section: Activities : Why is exception type needed? UML 2.0 open
UMLR-45 Section: Activities - clarification UML 2.0 open
UMLR-212 UML: Cross model dependencies UML 2.5 open
UMLR-211 UML: Large Scale Model Support:Federated/Distibuted Models UML 2.5 open
UMLR-214 UML: Add abilities to specifiy intent of Assert, Negate, Consider, Ignore fragments UML 2.5 open
UMLR-213 UML: Improve Sequence Diagram Semantics (3-issues) UML 2.5 open
UMLR-216 UML: Better Profile Capabilitiy UML 2.5 open
UMLR-215 UML:Access to standardized ontologies within models UML 2.5 open
UMLR-220 NamedElements whose owners do not subset Namespace UML 2.5 open
UMLR-222 Sequence diagram and Communication diagrams should support instances as lifelines UML 2.5 open
UMLR-221 Parameter UML 2.5 open
UMLR-218 UML: Higher-level reusable frameworks UML 2.5 open
UMLR-217 UML: Timing semantics for activity diagram UML 2.5 open
UMLR-178 Package merge is missing a rule UML 2.2 open
UMLR-177 UML 2: notation and concepts for unbound and un-owned template parameters are not clear UML 2.5 open
UMLR-176 semantics of associating a use case with another use case, or indeed anything other than an actor, are unclear UML 2.2 open
UMLR-180 authorize a reference to an operation in a realized interface. UML 2.2 open
UMLR-179 Subsets vs. Redefines UML 2.5 open
UMLR-174 Visibility and Import relationships UML 2.5 open
UMLR-173 UML2: Need clarification on circle plus notation for containment UML 2.5 open
UMLR-169 Section: 18.3.8 UML 2.2 open
UMLR-168 The example in Figure 18.11 is badly designed in multiple ways and is strongly misleading UML 2.2 open
UMLR-171 Template Binding Question UML 2.5 open
UMLR-170 there are numerous places where associations between UML elements have only one, navigable role UML 2.1.2 open
UMLR-172 Subsets vs. Redefines UML 2.5 open
UMLR-167 Figure 18.9 shows a presentation option for an Interface which has not been introduced before (circle within box) UML 2.2 open
UMLR-166 Section: 18.3.6 UML 2.2 open
UMLR-165 issue within UPDM with profile diagrams UML 2.5 open
UMLR-175 Should there be a constraint for extends equivalent to 16.3.6 [4] UML 2.2 open
UMLR-110 clarification on Behavior::specification / meaning of InterfaceRealization UML 2.5 open
UMLR-109 Presentation option for return parameter for operation type are incomplete UML 2.5 open
UMLR-108 UML 2 Superstructure: Abstractions should be acyclic UML 2.5 open
UMLR-105 Constraint.context vs Constraint.constrainedElement UML 2.5 open
UMLR-104 Section: Chapter: 7.3.2.4 View SysML 1.0 open
UMLR-103 Section: 7 UML 2.0 open
UMLR-106 Connector contract is inflexible UML 2.5 open
UMLR-100 Section: 13 & 14 UML 2.1.1 open
UMLR-99 Optional values and evaluation of defaults UML 2.5 open
UMLR-98 OCL Syntax in expressions UML 2.5 open
UMLR-102 Association::isDerived should be derived UML 2.5 open
UMLR-111 Section: 10.3.4 of formal/2007-02-03 UML 2.1.1 open
UMLR-116 UML 2.1.1 - notation for parameter sets UML 2.5 open
UMLR-115 Units and types are still problematic UML 2.5 open
UMLR-114 names and namespaces UML 2.5 open
UMLR-118 Section: 14.4 Timing Diagram: Continuous time axis UML 2.1.1 open
UMLR-117 9.3.9 Invocation Action UML 2.5 open
UMLR-120 Section: Annex A: Diagrams UML 2.1.1 open
UMLR-53 Meaning of relationship between iteration clause and Lifeline.selector clau UML 2.5 open
UMLR-59 Section: 14.3.3 Page: 508+ UML 2.0 open
UMLR-58 Section: 14.3.3 UML 2.0 open
UMLR-65 UML 2.0 Super/Use Cases/Subject of a Use Case UML 2.5 open
UMLR-64 Issue 7368 - make Classifier::useCase navigable UML 2.5 open
UMLR-52 UML2-rtf issue: communication diagram UML 2.5 open
UMLR-51 Section: 10.3.1 UML 2.0 open
UMLR-61 Arguments of Message UML 2.5 open
UMLR-60 ConditionalNode inputs used by more than one test UML 2.0 open
UMLR-56 Association in UseCase diagram UML 2.5 open
UMLR-55 Possibility to define a Collection as default Value needed UML 2.0 open
UMLR-63 Variables UML 2.5 open
UMLR-62 Numbering UML 2.5 open
UMLR-50 Add a Constraint UML 2.5 open
UMLR-49 SequenceNode should have way to set output pins in CompleteStructured UML 2.0 open
UMLR-57 Arguments of Message UML 2.5 open
UMLR-201 UML: Include text description field with model element --- additional information added UML 2.5 open
UMLR-200 UML: Provide unique URL/URI Reference to/from Model Elements UML 2.5 open
UMLR-207 UML: A strong ability to support generating Documents UML 2.5 open
UMLR-206 UML Support for multiple library levels UML 2.5 open
UMLR-203 Provide notational mechanism to represent any group of model elements based on some criteria w/o stealing ownership UML 2.5 open
UMLR-210 UML: Better Definition of Compliance UML 2.5 open
UMLR-209 UML: Provide mathematical formalism for UML semantics to provide precise meaning to language constructs UML 2.5 open
UMLR-205 UML: Support for maintaining what-if models in repository without massive duplication UML 2.5 open
UMLR-204 UML: A strong ability to support reviewing packages UML 2.5 open
UMLR-208 UML: Diagrams as Model Elements UML 2.5 open
UMLR-199 UML Associate an image/icon with each model element UML 2.5 open
UMLR-184 Reconcile the algebra of collections across OCL & UML’s intentional & extensional semantics UML 2.5 open
UMLR-183 UML: Issue with stereotype icons in a profile UML 2.5 open
UMLR-182 The spec may require some clarification regarding figure 14.16 UML 2.5 open
UMLR-181 Need notation option to show type stereotype on typed element UML 2.5 open
UMLR-188 Stereotyped Constraints in UML UML 2.5 open
UMLR-187 Stereotyped Constraints in UML UML 2.5 open
UMLR-191 Property subsets other regular property, non-derived union UML 2.5 open
UMLR-190 are Create messages aynch or synch, or doesn't it matter? UML 2.5 open
UMLR-189 UML 2 TemplateParameterSubstitution inconsistency about multiplicity of Actual and OwnedActual UML 2.5 open
UMLR-186 PrimitiveType has missing constraints UML 2.2 open
UMLR-193 UML Issue: Refactor UML to separate SW-Specific Aspects from Foundation Language UML 2.5 open
UMLR-192 One association end is derived, another is not UML 2.5 open
UMLR-195 Simplify by Making UML More Consistent: Allow States to be model as classes supporting inheritance and composition UML 2.5 open
UMLR-194 Simplify by Making UML More Consistent: Apply class and composite structure diagram rules to behavior modeling UML 2.5 open
UMLR-198 UML: Include text description field with model element UML 2.5 open
UMLR-197 UML: Incorporate SysML Requirements Model into UML UML 2.5 open
UMLR-196 UML: Need more robust value model that would enable capture of values vs time UML 2.5 open
UMLR-148 InterfaceRealization UML 2.5 open
UMLR-147 issue to address how problem 11240 was actually addressed in UML 2.2 spec UML 2.5 open
UMLR-146 Figure 7.65 and its explanation, P115 UML 2.5 open
UMLR-138 Section: 15.3.7 Constraint [2] UML 2.1.2 open
UMLR-137 UML Super 2.1.2: section 18.3.2 UML 2.5 open
UMLR-145 UML2 issue regarding Redefinition UML 2.5 open
UMLR-144 Section: 14.3.24, 14.3.20 UML 2.1.2 open
UMLR-140 Section: Activities SysML 1.0 open
UMLR-139 UML 2.1.2 Super: Execution Specification UML 2.5 open
UMLR-136 Section: 18.3.3 UML 2.1.2 open
UMLR-142 role bindings of a CollaborationUse UML 2.1.1 open
UMLR-141 Callout notation for many clients/suppliers SysML 1.0 open
UMLR-149 Actors cannot own Operations - a contradiction UML 2.5 open
UMLR-150 18.3.8 Generalization of stereotyped model elements UML 2.2 open
UMLR-143 3 3.2 Behavior (CommonBehaviors/BasicBehaviors) UML 2.1.2 open
UMLR-82 Notation for ordering action input and output pins UML 2.5 open
UMLR-81 All associations ends in the UML2 metamodel itself should be navigable UML 2.5 open
UMLR-80 Section: Sequence diagrams UML 2.0 open
UMLR-88 Unnecessary restriction on aggregations being binary UML 2.5 open
UMLR-87 New issue on notation for multiple stereotypes UML 2.5 open
UMLR-86 Link notation for instance diagrams does not cope with multiple classifiers UML 2.5 open
UMLR-97 Guidance for Representing Enumeration Values UML 2.5 open
UMLR-96 Section: 15.3.12, p 588, 589 UML 2.1.1 open
UMLR-95 Relationships UML 2.5 open
UMLR-83 ControlNodes in ActivityPartitions UML 2.5 open
UMLR-85 UML2: No notation for indicating Operation::raisedException UML 2.5 open
UMLR-84 Reception has no notation for its signal UML 2.5 open
UMLR-90 Unclear usage of LiteralExpression::type UML 2.5 open
UMLR-94 Default value types UML 2.5 open
UMLR-93 Section: 7.3.33 UML 2.1.1 open
UMLR-91 ValueSpecification::isComputable() UML 2.5 open
UMLR-32 Alternative entry and exit point notation is ambiguous UML 2.0 open
UMLR-31 Coupling between StateMachines and Activities UML 2.5 open
UMLR-33 Too much navigability from Generalizations UML 2.5 open
UMLR-14 ptc-03-09-15/Need for examples to include instance models UML 2.5 open
UMLR-13 Conditions for parameter sets UML 2.5 open
UMLR-11 Clarification of use case semantics UML 2.5 open
UMLR-10 Integration between behavioral "sublanguages": Interactions and Activities UML 2.5 open
UMLR-15 ptc-03-09-15/Explain the new association modeling constructs UML 2.5 open
UMLR-3 More explanation needed on Figure 339 UML 2.0 open
UMLR-2 More examples UML 2.0 open
UMLR-5 Promote local conditions to ExecutableNode UML 2.5 open
UMLR-4 Parameterization of lifelines UML 2.0 open
UMLR-9 UML 2 Super / State machines / Transition triggers cannot be redefined UML 2.5 open
UMLR-8 Join nodes that destroy tokens UML 2.5 open
UMLR-7 Deployment a dependency? UML 2.5 open
UMLR-6 Notation for method UML 2.5 open
UMLR-1 Conditional Node and Loop Node notation missing UML 2.5 open
UMLR-12 Section 7.11.2 Association UML 2.5 open
UMLR-23 UML2 Super/Deployment/inheritance UML 2.5 open
UMLR-22 Questions about DataTypes and generalization UML 2.5 open
UMLR-21 missing illustrations of graphical paths for create and destroy messages UML 2.5 open
UMLR-20 UML 2 Super / Interactions / Ambiguous diagram tags UML 2.5 open
UMLR-19 Redefinitions of OCL constraints must be aligned with MOF2.0/UML2.0 class R UML 2.0 open
UMLR-18 UML 2 Infrastructure / rule for redefinition of Property UML 2.5 open
UMLR-27 inconsistency in the action model UML 2.0 open
UMLR-26 large overlap between structural features and variables UML 2.0 open
UMLR-17 UML 2.0 Superstructure Kernal/Packages UML 2.5 open
UMLR-16 freeing namespace UML 2.5 open
UMLR-28 metaattribute isReadOnly UML 2.0 open
UMLR-25 Priority of the joint transition UML 2.5 open
UMLR-29 surface notation for state machines UML 2.0 open
UMLR-24 UML2 Super/Deployments/Manifestation UML 2.5 open
UMLR-30 Provide exception handling for all behaviors. UML 2.0 open

Issues Descriptions

Multiplicity of Comment's "owningElement" (composition/aggregation end next to Element) in UML diagram for Root should be 1 and not 0..1

  • Key: UMLR-820
  • Status: open  
  • Source: N/A ( Robert Hairgrove)
  • Summary:

    Since only Package elements override the virtual operation of Element "mustBeOwned()" to return false, this means that all other objects derived from Element except packages must have exactly one owner.

    References: Figure 7.1 Root, p. 63; 7.8.6.5 Operations "mustBeOwned()", p. 85

    Under the machine-generated description of Comment on p. 82, there is no mention of the association end for the aggregation, only for "annotatedElements".

    Other questions about Comment:

    1. Does it make sense for a Comment to have an empty body?
    2. Since a Comment is not a NamedElement, how would we want to access a single comment out of a possible set of Comments?
    3. Should the body attribute of Comment at least be unique within the set of Comments owned by a given Element?

  • Reported: UML 2.5.1 — Fri, 5 Apr 2024 08:15 GMT
  • Updated: Fri, 5 Apr 2024 16:55 GMT

missing async Operation call

  • Key: UMLR-819
  • Status: open  
  • Source: Elparazim ( George Roberts)
  • Summary:

    SAYS: "Messages are generated either by synchronous Operation calls or asynchronous Signal sends."

    but this misses asynchronous Operation calls

  • Reported: UML 2.5.1 — Sun, 7 Jan 2024 19:59 GMT
  • Updated: Wed, 10 Jan 2024 15:23 GMT

wrong definition of partial order

  • Key: UMLR-818
  • Status: open  
  • Source: Elparazim ( George Roberts)
  • Summary:

    A binary relation
    which is transitive, antisymmetric and irreflexive is called partial order.

    is wrong... partial orders are reflexive... irreflexive is a total order

  • Reported: UML 2.5.1 — Sat, 6 Jan 2024 16:51 GMT
  • Updated: Wed, 10 Jan 2024 15:23 GMT

Misleading sentence about the default history transition

  • Key: UMLR-817
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Axel Scheithauer)
  • Summary:

    The following sentence is incomplete:

    This [default history] Transition is only taken if execution leads to the history Pseudostate and the State had never been active before

    I think the sentence should continue:

    ... or had been active before, but reached its FinalState.

    This is specified in other places:

    In cases where a Transition terminates on a history Pseudostate when the State has not been entered before (i.e., no prior history) or it had reached its FinalState, there is an option to force a transition to a specific substate.

    the active substate becomes the substate that was most recently active prior to this entry, unless: o the most recently active substate is the FinalState, [...]

  • Reported: UML 2.5.1 — Wed, 3 Jan 2024 12:33 GMT
  • Updated: Wed, 3 Jan 2024 12:33 GMT

History Pseudostates should be allowed for top-level regions

  • Key: UMLR-816
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Axel Scheithauer)
  • Summary:

    The specification says:

    a deep/shallow History Pseudostate can only be defined for composite States

    There is no corresponding constraint.

    And the PSSM-specification allows them:

    If the history Pseudostate is owned by a top-level Region [...]

    And I think it is useful when the statemachine is used as a submachine.

    Therefore, I suggest deleting the sentence.

  • Reported: UML 2.5.1 — Wed, 3 Jan 2024 11:58 GMT
  • Updated: Wed, 3 Jan 2024 11:58 GMT

Derived union property values cannot change after initialization

  • Key: UMLR-815
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    [from Mr. Nerijus Jankevicius] Clause 9.9.21.5 (Attributes of StructuralFeature) describes isReadOnly as

    isReadOnly : Boolean [1..1] = false
    If isReadOnly is true, the StructuralFeature may not be written to after initialization.

    and 9.9.17.8 (Constraints on Property) includes

    derived_union_is_read_only
    A derived union is read only.
    inv: isDerivedUnion implies isReadOnly

    preventing properties from changing values (after initialization) when they subset a derived union.

  • Reported: UML 2.5.1 — Thu, 26 Oct 2023 15:03 GMT
  • Updated: Mon, 30 Oct 2023 19:12 GMT

need to add DataType

  • Key: UMLR-814
  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    sources_and_targets_kind constraint need to add DataType as something a InformationItem can be represented by... analogous to
    the fact that an ItemFlow in SysML can be a ValueType

  • Reported: UML 2.5.1 — Mon, 21 Aug 2023 14:15 GMT
  • Updated: Wed, 23 Aug 2023 20:18 GMT

No formal mapping between VisibilityKind and Visibility Symbols

  • Key: UMLR-811
  • Status: open  
  • Source: Private person ( Per Tengdahl)
  • Summary:

    There is no formal mapping between the Visibility Symbols ('+', '-', '#' and '~') and the VisibilityKind enumeration anywhere in the specification. There are a couple of hints in section 12.2.4. It seems that the mapping should be defined in either sub clause 7.4 or section 9.5.4?

  • Reported: UML 2.5.1 — Sun, 16 Jul 2023 17:48 GMT
  • Updated: Mon, 17 Jul 2023 16:03 GMT

Inconsistent document structure descriptions in section 6.4

  • Key: UMLR-813
  • Status: open  
  • Source: Private person ( Per Tengdahl)
  • Summary:

    There are a number of descriptions in section 6.4 on how to read the specification that are confusing or erroneous. In section 6.4.1 the structure of the generic Classifier Descriptions is said to contain a "Derivation" heading. There are no such headings, but it would be relevant to actually introduce them and move the derivations from the "Operations" part (where they are located now). It would also be clarifying to specify that the "Association Ends" part only lists the association ends owned by the class (and therefore navigable). And, as far as can be seen, all the other association ends in all Abstract Syntax diagrams are non-navigable from the class under discussion. In section 6.4.2 the last three rules could be simplified or removed. All association ends have an explicit multiplicity, so rule 6 can be deleted. There are also no unlabeled association ends, so the same applies to rule 7. There are no associations that are explicitly named, so the last rule should be rewritten (delete "that are not explicitly named,"). In the Abstract Syntax diagrams, the only association ends that are navigable are those owned by a Class. All ends owned by the Association itself are non-navigable. The arrow notation is redundant since it always occur together with a dot. It could also be interesting to remove the public visibility symbols that occur in all diagrams since they don't add any information if a "rule" was added instead. The diagrams would be slightly cleaner without the arrows and plus signs without losing any precision. Note that most of the diagrams in section 16 misses the dot notation (reported as a separate issue).

  • Reported: UML 2.5.1 — Sun, 16 Jul 2023 20:10 GMT
  • Updated: Mon, 17 Jul 2023 14:17 GMT

Missing dot notation in Abstract Syntax diagrams in Clause 16 Actions

  • Key: UMLR-812
  • Status: open  
  • Source: Private person ( Per Tengdahl)
  • Summary:

    Almost all Abstract Syntax diagrams in Clause 16 Actions are missing the dot notation for Classifier ownership. This is not in line with the statement in section 6.4.2. The Classifier and Association Descriptions at the end of the clause seem correct.

  • Reported: UML 2.5.1 — Sun, 16 Jul 2023 18:10 GMT
  • Updated: Mon, 17 Jul 2023 14:17 GMT

Wrong cross-reference for RedefinableElement specialisation

  • Key: UMLR-808
  • Status: open  
  • Source: Private person ( Per Tengdahl)
  • Summary:

    In section 9.9.18.4 it is stated that State is a specialisation of RedefinableElement. According to other parts iof the specification t is actually the abstract class Vertex that is intended, State is a specialisation of Vertex but so is also PseudoState and ConnectionPointReference.

  • Reported: UML 2.5.1 — Mon, 26 Jun 2023 22:25 GMT
  • Updated: Wed, 12 Jul 2023 08:03 GMT

UML 2.5: StateMachine Vertex needs to be made a kind of RedefinableElement instead of State

  • Key: UMLR-685
  • Status: open  
  • Source: Object Management Group ( Mr. Juergen Boldt)
  • Summary:

    In clause 14.3 dealing with state machine redefinition, State is declared as a kind of RedefinableElement (see Figure 14.37). This is necessary not only to allow States to be refined, but also because adding a Transition in an extending state machine necessarily has an impact on the "source" and "target" properties of the States that serve as the source and target (respectively) of that Transition. However, the source and target of a Transition is not necessarily a State; it could, in fact, be any kind of Vertex, such as a Pseudostate.

    Consequently, it is necessary to declare Vertex as a kind of RedefinableElement. Since State is a kind of Vertex, the necessary change to the metamodel is to replace State (see figure 14.37) by Vertex.

  • Reported: UML 2.5 — Mon, 9 May 2016 18:57 GMT
  • Updated: Wed, 12 Jul 2023 08:03 GMT

Mis-spelling of redefined property modelElement becomes modeElement

  • Key: UMLR-810
  • Status: open  
  • Source: Eurostep Group AB ( Phil Spiby)
  • Summary:

    UMLNameLabel is a specialization of UMLLabel and the modelElement attribute of UMLLabel is supposed to be constrained to just point to a NamedElement. However, in the specification and the XMI etc, the redefinition also, accidentally I beleive, renames the attribute.

  • Reported: UML 2.5.1 — Thu, 6 Jul 2023 13:48 GMT
  • Updated: Tue, 11 Jul 2023 20:11 GMT

Many diagram hyperlinks in the Diagrams sections of Classifier Descriptions sections are wrong

  • Key: UMLR-809
  • Status: open  
  • Source: Private person ( Per Tengdahl)
  • Summary:

    It seems that many of the first diagram hyperlinks in the list of diagrams under the Diagrams sections under the Classifier Descriptions have problems. They seem to point to the Classifier section itself. As an example, section 7.8.3.2 lists many diagrams. Clicking Namespaces shows sectiom 7.8.3 and not the diagram in figure 7.5. Clicking Constraints moves correctly to the diagram in figure 7.13. It is interesting to note that the problem seems to only occur for the first diagram reference in the list. Also, note that the problem occurs at MANY places all over the document (in the mentioned "generic" sections). It is especially annoying since the first diagram often is the diagram of main interest (the "definition" diagram).

  • Reported: UML 2.5.1 — Tue, 27 Jun 2023 12:44 GMT
  • Updated: Tue, 11 Jul 2023 19:55 GMT

BehavioredClassifier is not shown as a specialisation of Classifier anywhere in the Abstract Syntax

  • Key: UMLR-807
  • Status: open  
  • Source: Private person ( Per Tengdahl)
  • Summary:

    In section 10.5.1.3 it is said that BehavioredClassifier is a Classifier. This is consistent with sectiom 9.9.4.4 that defines BehavioredClassifier as a specialisation of Classifier. In figure 10.7 (covering Interfaces) BehavioredClassifier is shown with its attribute compartment. According to section 6.4.1, this indicates that BehavioredClassifier is defined in clause 10 which seems correct. Figure 10.7 is the only Abstract Syntax diagram in clause 10. It would therfore be appropriate to show BehavioredClassifier as a specialisation of Classifier in that diagram. No Abstract Syntax diagram containing BehavioredClassifier shows this specialisation. As an alternative, the specialisation could be shown in the Behaviors Abstract Syntax figure 13.1.

  • Reported: UML 2.5.1 — Mon, 26 Jun 2023 18:33 GMT
  • Updated: Tue, 11 Jul 2023 19:55 GMT

Link incorrect

  • Key: UMLR-804
  • Status: open  
  • Source: me.com ( Thomas Kilian)
  • Summary:

    http://www.omg.org/report_issue.htm does not exist and it should actually point to this very page. Alternatively think about noz using a dedicated link and suggest to follow from the main page.

  • Reported: UML 2.5.1 — Mon, 22 May 2023 22:02 GMT
  • Updated: Tue, 27 Jun 2023 14:03 GMT

Owner has to do with Namespaces

  • Key: UMLR-802
  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    NOTE. The concept of parent (a generalization relationship between Classifiers) is unrelated to the concept of owner (a composition relationship between instances).

    a composition relationship between instances).

    is not what is meant by "composition relationship"... this is not ownership

  • Reported: UML 2.5.1 — Sun, 14 May 2023 02:28 GMT
  • Updated: Tue, 27 Jun 2023 11:01 GMT

Specification inconsistent

  • Key: UMLR-806
  • Status: open  
  • Source: Elparazim ( George Roberts)
  • Summary:

    in 11.4.4 ... the usage <<Create>> is described as "The Operation is the client, the created instance the supplier. The
    InstanceSpecification may reference parameters declared by the Operation" but later in the Standard Profile it says

    «Create» for Usage "A usage dependency denoting that the client classifier creates instances
    of the supplier classifier."

    The Standard Profile description is incorrect

  • Reported: UML 2.5 — Mon, 29 May 2023 12:45 GMT
  • Updated: Tue, 27 Jun 2023 09:50 GMT

Possible missing ActivityEdge guard notation example on Figure 15.5; Duplicate ActivityEdge weight on Figure 15.5 and Figure 15.7

  • Key: UMLR-805
  • Status: open  
  • Source: PUCRS ( Marco Aurélio Souza Mangan)
  • Summary:

    Figure 15.5 is after the text:
    "An ActivityEdge (whether a ControlFlow or ObjectFlow) is notated by an open arrowhead line connecting two ActivityNodes. If the edge has a name, it is notated near the arrow. Guards are shown as text in square brackets near tail of the line."
    Possible missing ActivityEdge guard notation example on Figure 15.5, some guard example like [yes] ou [a > b]

    Fix proposal is:

    [yes]
    ------->
    [a > b]
    ------->
    With guard

    ------->
    Regular activity edge

    ------->
    Activity edge with name

    Figure 15.5 ActivityEdge notation for guarded edges, plain edges, and named edges

    Both weight and interruptible regions examples are not indicated on the text at this point.
    Further evidence of some error is that Figure 15.7 will also repeat weight and interruptible regions examples, after properly indicated on the text.

  • Reported: UML 2.5.1 — Sat, 27 May 2023 09:44 GMT
  • Updated: Thu, 15 Jun 2023 12:48 GMT

StateMachine initial transition inconsistency

  • Key: UMLR-803
  • Status: open  
  • Source: Private ( Eshar Gal)
  • Summary:

    The specification state in page 312 that the only transition from an initial Pseudostate should never have an associated trigger or guard:
    “It is the source for at most one Transition, which may have an associated effect Behavior, but not an associated trigger or guard.”

    Page 361 specify a constraint for the trigger (initial_transition):
    “An initial Transition at the topmost level Region of a StateMachine that has no Trigger.”
    inv: (source.oclIsKindOf(Pseudostate) and container.stateMachine->notEmpty()) implies trigger->isEmpty()

    With the above, an inconsistency appears in page 344, Figure 14.44:
    A trigger associated transition originating from the initial pseudostate.

  • Reported: UML 2.5.1 — Mon, 15 May 2023 13:52 GMT
  • Updated: Mon, 15 May 2023 18:17 GMT

Figure 14.44 ProtocolStateMachine example error

  • Key: UMLR-704
  • Status: open  
  • Source: NobleProg ( Filip Stachecki)
  • Summary:

    There is an incorrect description of initial transition on Figure 14.44 ProtocolStateMachine example. The "create" event shouldn't be there.
    Initial transition description from the spec: Initial pseudo state it is the source for at most one Transition, which may have an associated effect Behavior, but not an associated trigger or guard.

  • Reported: UML 2.5 — Fri, 5 Aug 2016 08:13 GMT
  • Updated: Mon, 15 May 2023 18:17 GMT

Meaning of Event on Initial Transition unclear

  • Key: UMLR-705
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Axel Scheithauer)
  • Summary:

    The specification says:

    In a Region of a ClassifierBehavior StateMachine, the Transition from an initial Pseudostate may be labeled with the Event type of the occurrence that creates the object

    First it is unclear, what an Event type is. Events are not TypedElements. I can only guess, that the name of the Event or, in case of MessageEvents, the name of the Signal or Operation is meant.
    The next question is, whose Operation is this? Could it be an Operation of the context Classifier? In the sense of a constructor? Or should it be an Event occurring in the object creating the context Classifier? The constructor interpretation would make sense, but the CreateObjectAction doesn't call any constructors, and that means the Object is already created, before any constructors can get called.

    Suggestion

    In a Region of a ClassifierBehavior StateMachine, the Transition from an initial Pseudostate may be labeled with the Event of invoking the constructor of the Classifier (an operation or reception with the «create» Stereotype), notated in the same way as a Trigger reacting to this Event (see 13.3.4).

  • Reported: UML 2.5 — Mon, 15 Aug 2016 18:49 GMT
  • Updated: Mon, 15 May 2023 18:12 GMT

Figure 9.1: duplicate graphical element "NamedElement"

  • Key: UMLR-801
  • Status: open  
  • Summary:

    the "NamedElement" is twice on the diagram, once in the upper left corner ("NW") and once at the bottom right to the center ("SSO").

    I think the lower right one can go.

  • Reported: UML 2.5.1 — Tue, 14 Feb 2023 19:13 GMT
  • Updated: Fri, 17 Mar 2023 18:14 GMT

Typo in caption for figure 14.14

  • Key: UMLR-800
  • Status: open  
  • Source: n/a ( Jan Mewes)
  • Summary:

    Observed:

    Figure 14.14 Submachine Sate that uses an exit point

    Expected:

    Figure 14.14 Submachine State that uses an exit point

  • Reported: UML 2.5.1 — Sun, 12 Feb 2023 06:01 GMT
  • Updated: Fri, 17 Mar 2023 14:57 GMT

Behavioral Classification

  • Key: UMLR-799
  • Status: open  
  • Source: OptConsult Company ( Himu)
  • Summary:

    As-Is Reads:
    13.2.3.1 A Behavior is a specification of events that may occur dynamically over time (see also sub clause 13.3 on the explicit modeling of Events in UML).
    13.1 UML provides Behavior, Event, and Trigger constructs to model the corresponding fundamental concepts of behavioral modeling.

    Suggestion:
    1) Change Ch13 Title AS-IS (Common Behavior) to (say, Mutability).
    Rational: This will free the word Behavior to specify something as follows.
    It is possible (and desirable) to treat the fundamental constructs of modeling, viz. Behavior, Event, and Trigger, (like other constructs of UML) independent of each other.
    For example, it is possible to conceptualize 'Behavior' as an attribute of relevant class.
    Similarly, Event and Trigger.
    In the paradigm of Object Management, such classification of one or more latent capabilities of objects, can and should simplify some of the problems with modeling (in my humble opinion).
    Thank you for letting me express an opinion...
    PS: Please accept my apologies, if this is already addressed in UML 2.6.

  • Reported: UML 2.5.1 — Mon, 23 Jan 2023 04:27 GMT
  • Updated: Tue, 24 Jan 2023 14:35 GMT

UML 2 Issue: isUnique

  • Key: UML22-21
  • Legacy Issue Number: 6464
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    PROBLEM STATEMENT
    "When one or more ends of the association have isUnique=false, it is
    possible to have several links associating the same set of instances."
    (Superstructure, p. 81)

    As Pierre-Alain Muller demonstrated in an informal conversation with Bran
    Selic during a lunch in San Francisco in the last UML Conference (I also was
    taking part in that conversation), isUnique must have the same value for all
    ends in an association.

    This has implications, for example, for the property strings that can be
    placed near the association ends (

    {ordered}

    ,

    {bag}

    ,

    {seq}

    ). According to the
    table in Superstructure, p. 92, if one end is a Set or an OrderedSet, then
    the opposite end must be a Set or an OrderedSet, too; and if one end is a
    Bag or a Sequence, then the opposite end must be a Bag or a Sequence, too.

    PROPOSED SOLUTION
    Explain this in the Spec.

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

    This topic is discussed in detail in DraganMilicev’s paper at http://afrodita.rcub.bg.ac.rs/ dmilicev/pubs/mdd/
    trumlassoc.zip. In the paper he proposes that the collection that provides the value of a property that is an
    association end is derived from the links that instantiate the association as modified by the isUnique marking.
    So, even if there are two links targeting an instance in the extent of the association, if the property is
    marked as unique then there will only be one instance in the collection. This interpretation allows there to
    be associations with mixed unique/nonunique ends. After discussion the FTF thinks that this interpretation
    is in fact the intended interpretation of the current spec, and should be clarified as such.
    Milicev also points out that AssociationClasses make the identity of links visible in the semantics, and in
    contrast to what the spec currently suggests, it is possible to have multiple instances of an AssociationClass
    that associate the same set of end instances, regardless of the uniqueness marking of the ends. This is
    clarified in the current resolution. Milicev proposes adding an isUnique property to AssociationClass to
    give the power to rule out such multiple instances. Adding such a property is outside the scope of UML 2.5.
    This resolution also clarifies that property subsetting applies to property values coerced to sets. Currently
    nonunique B could be marked as subsetting unique A. If B contains the same value twice and A contains it
    once, then that should be legal, even though the size of the value of B is larger than that of A.
    The resolution also accounts for the use of qualifiers, makes some improvements to the definition and use
    of the term “cardinality”, and corrects the semantics of CreateLinkAction to correspond to the clarified
    definition.
    This also resolves issue 5977.

  • Updated: Mon, 9 Jan 2023 12:17 GMT

Make AssociationClasses unique again

  • Key: UMLR-757
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Axel Scheithauer)
  • Summary:

    Issue UML22-21 asked for some clarifications about uniqueness. In its resolution following sentence was added to the specification:

    NOTE. Even when all ends of the AssociationClass have isUnique=true, it is possible to have several instances associating the same set of instances of the end Classes.

    I'm afraid, this makes AssociationClasses obsolete, because they can now be replaced with normal Classes without loosing expressive power.
    It is correct, that the uniqueness of an AssociationClass is independent of the uniqueness of its member ends, and that adding a 'unique' property is out of the scope of an RTF. However, it would be possible to simply define that an AssociationClass with only unique member ends is itself unique. Should the modeler require another semantics, she can use a normal Class.
    Without this, defining unique links is much more cumbersome.

  • Reported: UML 2.5 — Mon, 4 Mar 2019 14:11 GMT
  • Updated: Mon, 2 Jan 2023 09:44 GMT

Unclear how StateInvariants on a Lifeline identify the next OccurranceSpecification

  • Key: UMLR-798
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Axel Scheithauer)
  • Summary:

    StateInvariants cover a Lifeline and define a Constraint. The specification says:

    17.2.3.5 StateInvariant
    [...] The Constraint is evaluated immediately prior to the execution of the next OccurrenceSpecification.

    Very well, but how is the "next" OccurrenceSpecification identified?

    My first guess was that the Lifeline would have an ordered set of InteractionFragments (both OccurrenceSpecification and StateInvariant are such fragments). But, no, there is none. events:OccurrenceSpecification is ordered, but stateInvariant:StateInvariant is not, and both are subsets of coveredBy:InteractionFragment, which is also not ordered.

    The only way I can think of is to identify the next OccurrenceSpecification by setting it as the constrainedElement of the Constraint. Actually, that really makes sense and should be mandatory.

    Suggestion
    Replace sentence in 17.2.3.5 StateInvariant

    The Constraint is evaluated immediately prior to the execution of the next OccurrenceSpecification.

    with

    The Constraint must constrain an OccurranceSpecification of the covered Lifeline. It will be evaluated immediately before this occurrance.

    Replace sentence in Notation 17.2.4.5 StateInvariant

    The possible associated Constraint is shown as text in curly brackets on the lifeline.

    with

    The possible associated Constraint is shown as text in curly brackets on the lifeline immediately above the constrained OccurrenceSpecification.

    Add a constraint to 17.12.25
    constrains_one_OccurrenceSpecification
    self.invariant.constrainedElement->size()=1
    AND
    self.covered.events->includes(self.invariant.constrainedElement->first())

  • Reported: UML 2.5.1 — Tue, 13 Dec 2022 10:56 GMT
  • Updated: Tue, 13 Dec 2022 10:56 GMT

unclear whether imported elements are merged by package merge

  • Key: UMLR-797
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Axel Scheithauer)
  • Summary:

    When two packages have a merge relationship, the elements with the same name and metatype are merged. Does that include the elements imported into the package? The specification says:

    the contents of the Package to be merged are combined with the contents of the receiving Package.

    merged element – refers to a model element that exists in the merged package.

    I expected that "content" means packagedElement and "exists" means that the merged package is the owningPackage.

    However, according to one member of the taskforce, the imported elements are merged. So, it probably does mean member and memberNamespace.

    From the text of the specification, I cannot derive that. I propose to add a clarification.

    I attached an example diagram that shows the results of the two interpretations: A Class A is imported via PackageImport to Package P2 (the mergedPackage). In this Package no Class of this name is defined. Now P2 is merged into P3 (the receivingPackage), which owns a Class A. There are two interpretations possible:
    a) The resultingPackage P3 owns the result of merging P1::A with P3::A.
    b) The resultingPackage P3 owns P3::A

    In both cases the resultingPackage will also contain a PackageImport that imports P1::A, but since it already contains a Class with this name, it will not be added to the namespace.

  • Reported: UML 2.5.1 — Wed, 26 Oct 2022 15:13 GMT
  • Updated: Wed, 2 Nov 2022 17:40 GMT
  • Attachments:

MultiplicityElement.isOrdered: Abstract Syntax Metamodel does not match the specification document

  • Key: UMLR-796
  • Status: open  
  • Source: Danish Agency for Data Supply and Infrastructure ( Heidi Vanparys)
  • Summary:

    According to the UML 2.5.1, the default value for attribute isOrdered of abstract class MultiplicityElement is false, see clause 7.8.8.5 and see figure 7.10 in clause 7.5.2.

    However, this default value for isOrdered is not present in the Abstract Syntax Metamodel (the XMI file with file id ptc/18-01-01 present at https://www.omg.org/spec/UML/20161101/UML.xmi). In comparison, the default value for isUnique (true) is present in the XMI. See lines 12855-12873.

    <ownedAttribute xmi:type="uml:Property" xmi:id="MultiplicityElement-isOrdered" name="isOrdered">
    <type href="http://www.omg.org/spec/UML/20131001/PrimitiveTypes.xmi#Boolean"/>
    <ownedComment xmi:type="uml:Comment" xmi:id="MultiplicityElement-isOrdered-_ownedComment.0"
    body="For a multivalued multiplicity, this attribute specifies whether the values in an instantiation of this MultiplicityElement are sequentially ordered.">
    <annotatedElement xmi:idref="MultiplicityElement-isOrdered"/>
    </ownedComment>
    <defaultValue xmi:type="uml:LiteralBoolean"
    xmi:id="MultiplicityElement-isOrdered-_defaultValue"/>
    </ownedAttribute>
    <ownedAttribute xmi:type="uml:Property" xmi:id="MultiplicityElement-isUnique" name="isUnique">
    <type href="http://www.omg.org/spec/UML/20131001/PrimitiveTypes.xmi#Boolean"/>
    <ownedComment xmi:type="uml:Comment" xmi:id="MultiplicityElement-isUnique-_ownedComment.0"
    body="For a multivalued multiplicity, this attributes specifies whether the values in an instantiation of this MultiplicityElement are unique.">
    <annotatedElement xmi:idref="MultiplicityElement-isUnique"/>
    </ownedComment>
    <defaultValue xmi:type="uml:LiteralBoolean"
    xmi:id="MultiplicityElement-isUnique-_defaultValue"
    value="true"/>
    </ownedAttribute>

    The result of this is that when I create custom diagrams illustrating specific parts from the UML metamodel, the default value for isOrdered is not shown in my UML tool.

  • Reported: UML 2.5.1 — Wed, 17 Aug 2022 08:33 GMT
  • Updated: Wed, 24 Aug 2022 19:40 GMT

Inheritance of extension not explicitly stated

  • Key: UMLR-795
  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    Fig. 12.21 shows Entity as a specialization of Bean... but Entity does not show any extensions... therefore Entity inherits its extensions from Bean... but nowhere in the standard does it explicitly say that extension relationship are inherited by subclasses... even though one could perhaps derive that from the fact that extensions are associations... it should be explicitly stated in the standard

  • Reported: UML 2.5.1 — Sat, 2 Jul 2022 19:51 GMT
  • Updated: Thu, 14 Jul 2022 15:40 GMT

Association wrong here

  • Key: UMLR-794
  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    the sentence "EncapsulatedClassifiers to differentiate
    between them but without being directly coupled to them. Classes, Components, Associations and Collaborations are
    concrete metaclasses that use these capabilities."

    should have AssociationClass and not Association here... and does not even need AssociationClass because AssociationClass is a specialization of a Class...

    Association does not Specialize EncapsulatedClassifier

  • Reported: UML 2.5.1 — Sun, 8 May 2022 15:35 GMT
  • Updated: Thu, 19 May 2022 16:02 GMT




UML::Property.defaultValue has upper multiplicity of 1 even though Property is a MultiplicityElement

  • Key: UMLR-790
  • Status: open  
  • Source: Department of Navy ( Mr. James Ciarcia)
  • Summary:

    UML makes it hard/impossible to provide defaultValues for properties that have upper multiplicity higher than 1 since the defaultValue is limited to 1 ValueSpecification. While an OpaqueExpression could be used to provide a result of more than 1 element, this still requires execution of extra metaclass associations and the digital trail to Literals or InstanceValue's. Recommend changing the multiplicity to 0 .. *.

  • Reported: UML 2.5.1 — Mon, 31 Jan 2022 21:23 GMT
  • Updated: Mon, 7 Feb 2022 18:09 GMT

Receptions should be redefinable elements as operations are.

  • Key: UMLR-789
  • Status: open  
  • Source: Dassault Systemes ( Mr. Tautvydas Juska)
  • Summary:

    Both Operations and Receptions are Redefinable Elements. However, not we cannot redefine Receptions. This is caused because query isConsistentWith() specifies where we can redefine them or not. By default, this value is "False" and for operations, the value is set to "true", but for Receptions, the value is not specified, which means it is "False".
    We should make Receptions also redefinable elements as Operations are, which requires to specify isConsistentWith() query with "True" value.

  • Reported: UML 2.5.1 — Tue, 18 Jan 2022 08:51 GMT
  • Updated: Tue, 18 Jan 2022 21:27 GMT

Inconsistent use of unspecified and unlimited for the multiplicity notation

  • Key: UMLR-788
  • Status: open  
  • Source: ACM ( Christophe THIERRY)
  • Summary:

    The first paragraph p.35 states: << A multiplicity with zero as the lower bound and an unspecified upper bound may use the alternative notation containing a single star “” instead of “0..” multiplicity. >>
    The use of the term "unspecified upper bound" is not consistent with the sentence found 3 paragraphs above (on p.34): << The star character is used as part of a multiplicity specification to represent an unlimited upper bound. >> nor with the specification of the semantics related to this notation (on top of p.34): << A MultiplicityElement is unlimited if its upperBound has the UnlimitedNatural value of unlimited (“*”) >>.
    Solution: replace "unspecified upper bound" with "unlimited upper bound" in that sentence.

  • Reported: UML 2.5.1 — Mon, 22 Nov 2021 08:59 GMT
  • Updated: Wed, 24 Nov 2021 15:32 GMT

There is not a way to do this...

  • Key: UMLR-787
  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    There is no metaclass for Link so there is no way to do this... in Fig. 9.30 you have two InstanceSpecification being connected by a link... but how do you do this?... you can't do it with a Connector because a Connector is between two ConnectableElements and
    an InstanceSpecification is not a ConnectableElement...

    think that there needs to be a Link metaclass specifically for this purpose..

  • Reported: UML 2.5.1 — Mon, 13 Sep 2021 00:38 GMT
  • Updated: Mon, 20 Sep 2021 10:30 GMT

removeAt_and_value wrong

  • Key: UMLR-786
  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    It says "ReadVariableActions" and it should say "RemoveVariableValueAction"

  • Reported: UML 2.5.1 — Wed, 1 Sep 2021 17:52 GMT
  • Updated: Wed, 8 Sep 2021 14:24 GMT

Misleading Link

  • Key: UMLR-785
  • Status: open  
  • Source: Siemens Mobility ( Philipp Rost)
  • Summary:

    Clicking on "A_bodyPart_loopNode::loopNode" within "bodyPart : ExecutableNode [0..*] (opposite A_bodyPart_loopNode::loopNode)" doesn't guide you to the correct Object "16.15.6 A_bodyPart_loopNode [Association]" on page 542. It redirects onto "bodyPart" itself.

  • Reported: UML 2.5.1 — Wed, 1 Sep 2021 09:06 GMT
  • Updated: Wed, 8 Sep 2021 14:24 GMT

Include ordering

  • Key: UMLR-784
  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    constraints matching_loop_variables and matching_result_pins need to include ordering

  • Reported: UML 2.5.1 — Mon, 9 Aug 2021 06:29 GMT
  • Updated: Mon, 9 Aug 2021 14:02 GMT

need to include setup

  • Key: UMLR-783
  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

     setup_test_and_body
    The test and body parts of a ConditionalNode must be disjoint with each other.

    this should say "setup, test, and body parts"

  • Reported: UML 2.5.1 — Mon, 9 Aug 2021 04:53 GMT
  • Updated: Mon, 9 Aug 2021 14:01 GMT

switch LoopNode for ConditionalNode

  • Key: UMLR-782
  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

     setup_test_and_body
    The test and body parts of a ConditionalNode must be disjoint with each other.

    should be LoopNode instead of ConditionalNode

  • Reported: UML 2.5.1 — Mon, 9 Aug 2021 04:51 GMT
  • Updated: Mon, 9 Aug 2021 14:01 GMT

" in state name

  • Key: UMLR-781
  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    The standard says

    "(Alternatively, a Transition of kind local can be shown as a
    Transition leaving a State symbol containing the text “*.” The Transition is then considered to belong to the
    enclosing composite State.)"

    What does this mean, how is this done, why would one do this?... either there needs to be an example of this in the standard or it needs to be removed

  • Reported: UML 2.5.1 — Sun, 4 Apr 2021 15:48 GMT
  • Updated: Mon, 5 Apr 2021 17:03 GMT

Local Transitions conflict

  • Key: UMLR-780
  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    Standard says

    "Transitions of the kind local can originate from the border of the containing composite State, or one of its entry
    points, or from a Vertex within the composite State."

    yet the OCL Constraint for Transition pg. 361 is

    state_is_local
    A Transition with kind local must have a composite State or an entry point as its source.
    inv: (kind = TransitionKind::local) implies
    ((source.oclIsKindOf (State) and source.oclAsType(State).isComposite) or
    (source.oclIsKindOf (Pseudostate) and source.oclAsType(Pseudostate).kind =
    PseudostateKind::entryPoint))

    which does not include "a Vertex within the composite State"

    the diagram fig 14.34 Local Transition does not include "a Vertex within the composite State" but the fig. 14.35 External Transitions

    something is wrong here... is the S1 to S2 transition in fig 14.35 correct... then the text is wrong... otherwise other things have to change...

  • Reported: UML 2.5.1 — Sun, 4 Apr 2021 15:26 GMT
  • Updated: Mon, 5 Apr 2021 15:32 GMT

OCL and Text Mismatch

  • Key: UMLR-779
  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    same_classifier
    The classifier containing the referenced ConnectableElement must be the same classifier, or an ancestor, of the
    classifier that contains the interaction enclosing this lifeline.
    inv: represents.namespace->closure(namespace)->includes(interaction._'context')

    The text says ancestor which has to do with Generalization issues... yet the OCL deals with namespaces... Ancestors can be in different namespaces... so which is it, does the interaction need to be in the namespace of the ancestor... or does the interaction need to be contained somewhere in the namespace hierarchy... I am thinking it is Generalization over namespace

  • Reported: UML 2.5.1 — Sun, 4 Apr 2021 12:47 GMT
  • Updated: Mon, 5 Apr 2021 15:32 GMT

Lambda's,Traits and Generics

  • Key: UMLR-777
  • Status: open  
  • Source: N/A Transitioning ( Caleb Cushing)
  • Summary:

    So one issue I have noticed with UML over the last few years is the lack of a few types that have become much more prevalent.

    Specifically I'm thinking about Lambda's and Traits.

    I think Lambda, or anonymous functions, and method references can be represented with a class, anonymous or otherwise, using a generic of type <<lambda>>. But I feel as though that doesn't really call it out in the way I would generally like. I'm wondering if they should treated with a different shape when they're used. In some languages that are not java, these are not classes in any way shape or form (that I'm aware). Heh, maybe an arrow box with a name.

    Traits, or flat composition instead of multiple inheritance, similar to java's interfaces with default methods (though traits can have state). I suspect it'd be fine to represent these with the "class" using the generic <<trait>> but I don't know that using the -|> operator to show inheritance is actually appropriate, or even the -<> composition operator, since that seems like it's representing a different object of the same "aggregate root" (using the meaning of the term from domain driven design).

    Generics, UML doesn't really support this at all, By that I mean List<Bar>, I suppose you can but it in the text, but when you have an interface that takes a parameter, or a method, or whatever, it's kind of hard to represent in my opinion that the type is parameterized with other types. If I have a method that returns List<Bar>, there's no class of type List<Bar> that tooling would generally find. Of course you can simply use a one to many relationship, but if you're generating code in either direction, or using this for a more strictly guiding document, E.g. it's a List, not a Set, it's problematic.

    By the way, I don't know what version this happened in, but thanks for clarifying composition vs aggregation. though I think they're backwards from other industry language about aggregates and composition, at least composition seems to match the definition of an aggregate in DDD.

  • Reported: UML 2.5.1 — Fri, 5 Mar 2021 19:11 GMT
  • Updated: Fri, 5 Mar 2021 20:42 GMT

Textual "Markdown" visualization

  • Key: UMLR-778
  • Status: open  
  • Source: N/A Transitioning ( Caleb Cushing)
  • Summary:

    In modern development, git, and markdown have become very popular. While I don't think that markdown (CommonMark) needs to be explicitly supported, I think it would we good to take it into consideration. The idea being that this standard textual representation is readable in plain text format. I think that the mermaid.js browser plugin also does a nice job, by rendering the document when it's in a fenced code block. Having this would allow us to commit markdown (or whatever, that supports it) to our git repositories, or other things and have it rendered wherever we take it.

    An additional thing that may (or may not?) need to be considered, importing from existing "libraries" or "diagrams". One thing I don't like about these tools, especially for class diagrams, if I need to reuse the same class I have to completely recreate it. I think another thing that may want to be considered here, is hiding, if I import a "library" then I want to be able to hide some of its details, I may not want to show all methods in this diagram, for example. It could be argued though, that that is just a hazard of doing that. I don't feel that strongly about that. Speed of creation here is more important.

    references to some varying syntax, and are just examples, I'm certain their are many many more, by having a spec-ed syntax all of these variants could implement that as an option, solving the same problem that UML originally tried to resolve about people using visual communication formats and then standardizing that so that you could walk into an environment and know the "language".

    https://yuml.me/diagram/scruffy/class/samples
    https://mermaid-js.github.io/mermaid/#/
    https://sequencediagram.org/
    https://state-machine-cat.js.org/

  • Reported: UML 2.5.1 — Fri, 5 Mar 2021 19:27 GMT
  • Updated: Fri, 5 Mar 2021 19:36 GMT

OCL for excludeCollisions in Namespace element seems incorrect

  • Key: UMLR-776
  • Status: open  
  • Source: Deniz Eren ( Deniz Eren)
  • Summary:

    Hi,

    UML machine consumable xmi 2.5.1 xmi-id "Namespace-excludeCollisions" has OCL:

    result = (imps->reject(imp1 | imps->exists(imp2 | not imp1.isDistinguishableFrom(imp2, self))))

    However clearly it should have "imp1 <> imp2" like this:

    result = (imps->reject(imp1 | imps->exists(imp2 | imp1 <> imp2 and not imp1.isDistinguishableFrom(imp2, self))))

    Best regards,
    Deniz

  • Reported: UML 2.5.1 — Fri, 29 Jan 2021 12:43 GMT
  • Updated: Fri, 29 Jan 2021 17:58 GMT

An Activity Edge cannot connect to Activities

  • Key: UMLR-775
  • Status: open  
  • Source: private person ( Andreas Warnke)
  • Summary:

    Problem:
    A CommunicationPath is a ActivityEdge. An ActivityEdge has source and target properties of type ActivityNode. But an Activity is not an ActivityNode. So the CommunicationPath link vom Activity to Activity is invalid.
    Such a link should be valid - otherwise the diagram in 15.5.5 Examples is wrong.

    Info: Some tools seem to simply allow this:
    <ownedBehavior xmi:type="uml:Activity" xmi:id="EAID_940293B7_001A_4d5d_BCFE_24CB874155E3" name="Create Title Entry" visibility="public" isReadOnly="false" isSingleExecution="false">
    ...
    <edge xmi:type="uml:ControlFlow" xmi:id="EAID_B750FB8E_8132_4569_99C2_8C0DFD11F144" visibility="public" source="EAID_940293B7_001A_4d5d_BCFE_24CB874155E3" target="EAID_D4190768_7F03_4546_B5E5_38E4DBE56F19"/>
    or
    https://github.com/awarnke/crystal_facet_uml/blob/master/example_diagrams/export_test/export_test_15_activity.xmi

    Proposed fix: Would it make sense to make an Activity derive from ActivityNode instead of Behavior, and ActivityNode derived from Behavior?

    Maybe i simply understood the current specification wrong - then please ignore my Comment.
    Regards
    A. Warnke

  • Reported: UML 2.5.1 — Sat, 12 Dec 2020 11:58 GMT
  • Updated: Mon, 4 Jan 2021 08:44 GMT

Needs to be a constraint between AggregationKind and subsetting

  • Key: UMLR-774
  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    if AggregationKind is ordered

    {none,shared,composite}

    low to high... the there should be a constraint on a subsetting property such that the subsetting property's aggregationkind is at least that of the subsetted property or greater

  • Reported: UML 2.5.1 — Thu, 12 Nov 2020 13:37 GMT
  • Updated: Tue, 17 Nov 2020 14:28 GMT

Please make it clear what is being modeled behind the scenes for figures

  • Key: UMLR-773
  • Status: open  
  • Source: UNICOM Systems ( Mark Gregory)
  • Summary:

    As an example, it is stated here that
    "The values of the ownedAttributes of a Stereotype (or its generalizations) applied to a model element can be shown in one
    of the following three ways:
    1 As part of a comment symbol connected to the graphic node representing the model element."
    Later it says "Within a comment symbol, or, if displayed before or above the model element’s name, the Property values from a specific Stereotype are optionally preceded with the name of the applied Stereotype within a pair of guillemets. This is useful if values of more than one applied stereotype should be shown.".
    I have not found within this specification in either the semantics or notation sections an explanation for what Comment symbols are representing with regards to this. Since there is the InstanceSpecification construct I do not believe this is expected to be manually typed.
    I can understand one scenario where I create an InstanceSpecification to represent an instance of a Stereotype and I could have a Comment symbol represent only that. That could be extended to say that a Comment symbol should present information from more than one stereotype instance.Alternatively it could be meant that you define an InstanceSpecification and InstanceValues referenced by slots could reference the stereotype instances and that these should be decomposed as stated. However, 9.8.4 said, for an InstanceValue, that only the name of the referenced InstanceSpecification should be shown.
    The specification must make it clear what should be modeled for a given figure, each time you present something that has not already been described, to avoid tool vendors coming to conclusions which could be different from those intended.

  • Reported: UML 2.5.1 — Fri, 16 Oct 2020 08:58 GMT
  • Updated: Tue, 27 Oct 2020 19:33 GMT

UML Specification "Normative References" uses non-secure links

  • Key: UMLR-759
  • Status: open  
  • Source: Sierra Nevada ( Mr. Chas Galey)
  • Summary:

    2.5.1 spec uses links in normative references that defaults to http not https protocol.

  • Reported: UML 2.5 — Wed, 20 Mar 2019 02:59 GMT
  • Updated: Wed, 12 Aug 2020 19:51 GMT

Please provide more detail on redefinition

  • Key: UMLR-772
  • Status: open  
  • Source: UNICOM Systems ( Mark Gregory)
  • Summary:

    I am attempting to implement support for UML 2.5.1.
    When handling property redefinition based on the uml Abstract Syntax Metamodel.xmi :
    Given this sort of construct in the xmi..(newproperty, baseproperty xmi:ids added for reference in my question below)
    <ownedAttribute xmi:type="uml:Property" xmi:id="newproperty"..">
    <redefinedProperty xmi:idref="baseproperty"/>
    I need to understand whether it is correct to..
    a) assume that newproperty is being defined from scratch (meaning: clean slate; a brand new property)
    or b) the property being redefined (baseproperty) should be adjusted based on what changes are specified in the xmi

    In our current implementation it is rather difficult for us to accommodate a change in name of the existing property so I propose that newproperty is a subset baseproperty, with the additional restriction on baseproperty that it becomes a derived union.
    This paper..
    "On the Relationships Between Subsetting,Redefinition and Association Specialization"
    https://uni-koblenz.de/~ist/documents/Bildhauer2010OTR.pdf
    .. although based on material dated 2006 (UML2.2), this discussed UML property redefinition in comparison to subsetting and judged that redefinition was subsetting with a constraint.

  • Reported: UML 2.5.1 — Tue, 21 Jul 2020 16:45 GMT
  • Updated: Wed, 29 Jul 2020 08:58 GMT

UML.xmi is not well-formed

  • Key: UMLR-771
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    In comparison to UML 2.5's xmi there is an additional

    <documentation>
    <shortDescription>UML.xmi: XMI representation of the metamodel for UML 2.5.1.</shortDescription>
    </documentation>

    This makes the XMI ill-formed since there is no xmlns declaration for the blank namespace.

    Change to xmi:Documentation

  • Reported: UML 2.5.1 — Tue, 5 May 2020 06:39 GMT
  • Updated: Tue, 5 May 2020 17:47 GMT

PackageImport Missing for Type Generalization

  • Key: UMLR-770
  • Status: open  
  • Source: N/A ( Jon Lindberg)
  • Summary:

    In the XMI representation of the metamodel for UML 2.5.1:

    • The package Classification defines the class InstanceValue.
    • InstanceValue contains a generalization to the class ValueSpecification.
    • ValueSpecification is defined in the package Values.
    • The package Classification does not contain a packageImport element for the Values package or for any other package which itself imports Values. This renders the type of ValueSpecification undefined at the point where it is used by InstanceValue.

    The most immediate solution appears to be to add a packageImport to the definition of the Classification package, e.g., '<packageImport xmi:type="uml:PackageImport" xmi:id="Classification-_packageImport.3" importedPackage="Values"/>'.

  • Reported: UML 2.5.1 — Sun, 25 Aug 2019 03:40 GMT
  • Updated: Thu, 5 Sep 2019 14:50 GMT

Nested Port not supported on Sequence Diagram

  • Key: UMLR-769
  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    currently, there is no way to specify a nested port as a part decomposition in a sequence diagram

  • Reported: UML 2.5.1 — Sat, 3 Aug 2019 00:12 GMT
  • Updated: Mon, 5 Aug 2019 18:52 GMT

InteractionUse can not reference a CollaborationUse (as shown in Figure 17.24)

  • Key: UMLR-768
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Axel Scheithauer)
  • Summary:

    The specification contains following diagram:

    It shows how a CollaborationUse w1 can be used to bind the parts of a concrete Class E to roles in the generic Collaboration W. The InteractionUse in the sequence diagram of E is then shown as if it references w1.Q. This is not possible, since an InteractionUse can only reference another Interaction. In the case shown it might just be inferred, since there is only one CollaborationUse. However, it is possible to use the same Collaboration multiple times with different role bindings, and then it is necessary to define which one is happening.

    Suggestion
    This is a useful feature. I think the Metamodel should be enhanced. One possibility would be to allow InteractionUses to reference CollaborationUses.

  • Reported: UML 2.5.1 — Thu, 25 Jul 2019 12:15 GMT
  • Updated: Thu, 25 Jul 2019 12:17 GMT
  • Attachments:

Error in Loop fragment deffinition

  • Key: UMLR-767
  • Status: open   Implementation work Blocked
  • Source: FHOOE ( Georg Fritze)
  • Summary:

    the textual syntax is wrong:
    ‘loop[‘(‘ <minint> [‘,’ <maxint> ] ‘)’]
    =>
    ‘loop’[‘(’ <minint> [‘,’ <maxint> ] ‘)’]

    If this textual syntax describes the Guard than is also should be able to contain a bool statement (17.6.3.17 Loop).
    If this text describes the format of the name, please explain how to distinguish between an InteractionConstraint and a Guard.

  • Reported: UML 2.5.1 — Fri, 14 Jun 2019 23:03 GMT
  • Updated: Wed, 17 Jul 2019 18:06 GMT

Duplicate section titles

  • Key: UMLR-766
  • Status: open  
  • Source: Fraunhofer FOKUS ( Niels Hoppe)
  • Summary:

    Sections 17.9.1.1 and 17.9.1.2 both bear the title "Graphical Paths". This is correct for section 17.9.1.2, but not for section 17.9.1.1 as it describes graphical nodes (not paths) as written in the section body and the referenced table 17.3 "Graphic Nodes Included in Communication Diagrams".

  • Reported: UML 2.5.1 — Mon, 3 Jun 2019 12:47 GMT
  • Updated: Wed, 17 Jul 2019 18:06 GMT

Property.Association is not a union

  • Key: UMLR-761
  • Status: open   Implementation work Blocked
  • Source: Capricorn Pro s.r.o. ( Slávek Rydval)
  • Summary:

    Property.association is not set as union although Property.owningAssociation is subsetting it.

  • Reported: UML 2.5.1 — Tue, 2 Apr 2019 20:11 GMT
  • Updated: Tue, 18 Jun 2019 06:39 GMT

Comments not annotating anything should annotate their owner

  • Key: UMLR-765
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Axel Scheithauer)
  • Summary:

    Comments have an owner and may annotate Elements. If the list of annotated Elements is empty, I think the only interpretation can be, that the Comment is implicitely annotating its owner. This should get clarified.

    Suggestion
    Current specification:

    Every kind of Element may own Comments. The ownedComments for an Element add no semantics but may represent information useful to the reader of the model.

    add following sentences:

    A comment may annotate any number of elements. If the list of annotated elements is empty, it means that it is annotating its owner.

  • Reported: UML 2.5 — Thu, 6 Jun 2019 17:09 GMT
  • Updated: Wed, 12 Jun 2019 20:19 GMT

No way of specifying element documentation

  • Key: UMLR-89
  • Legacy Issue Number: 9702
  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    There is no equivalent in UML 2.x of the 'documentation' tag at UML 1.x: a standard way of distinguishing the description of an element.
    Comment is generic and has no property to distinguish the 'inherent' description of an element from annotations on specific diagrams, and there is no standard stereotype which could be applied (though use of a stereotype is arguably heavyweight for what is a fairly pervasive requirement).

  • Reported: UML 2.5 — Thu, 4 May 2006 04:00 GMT
  • Updated: Wed, 12 Jun 2019 16:57 GMT

Specializations of an Association Class

  • Key: UMLR-764
  • Status: open  
  • Source: Software Centre of Excellence, Rolls-Royce Div. ( Dave Banham)
  • Summary:

    The very last paragraph of section 11.5.3.2 states "An AssociationClass cannot be a generalization of an Association or a Class." However, there appear to be no constraints specified for AssociationClass (11.8.2) or Generalization (9.9.7), or GeneralizationSet (9.9.8) to formalize the intent of this statement.

    To be clear, does this statement mean that an AssociationClass cannot be a Generalization's general or specific property? If so, why not?

    I think there are two cases to consider:
    1. Redefinition/subsetting of the association class' end properties results in the need to subset the association class;
    2. Classifying the association class into subtypes through specialization;

    Case 1 would naturally lead to the specializations of the AssociationClass being AssociationClasses (because an association is being used to redefine the association that is typed by the more general AssociationClass).

    Case 2. would naturally lead to the specializations of the AssociationClass being Classes (because no new associations are being specified). Although, in reality, instances of these subtype classes are, by inheritance, instances of their general AssocaitionClass.

    Case 2 also makes me think of power types. Can an association class be a power type? If it can then that may well provide a workaround for case 2.

  • Reported: UML 2.5.1 — Wed, 24 Apr 2019 14:33 GMT
  • Updated: Wed, 12 Jun 2019 15:37 GMT

UML has no way of distinguishing Notes from Comments

  • Key: UMLR-219
  • Legacy Issue Number: 14959
  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    Though it is common in tools to provide a way of adding notes to diagrams that are not serialized as part of the model XMI, this is nowhere documented in the UML specification. Nor is there any notational means of distinguishing the 2 (since the dashed line attaching Comments to Elements is optional).

  • Reported: UML 2.5 — Tue, 12 Jan 2010 05:00 GMT
  • Updated: Wed, 12 Jun 2019 14:09 GMT

Association class notation with just class or association

  • Key: UMLR-185
  • Legacy Issue Number: 14426
  • Status: open  
  • Source: RTX ( Mr. Roy M. Bell)
  • Summary:

    Association class notation should include just the class symbol or
    just the association symbol, in addition to the current combination of
    these. Association classes are both associations and classes and
    should be able to be notated as either one separately.

  • Reported: UML 2.1.2 — Sat, 19 Sep 2009 04:00 GMT
  • Updated: Wed, 24 Apr 2019 09:09 GMT

Clarify that AcceptEventActions in InterruptibleActivityRegions are disabled when token leaves

  • Key: UMLR-763
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Axel Scheithauer)
  • Summary:

    The specification says about InterruptibleActivityRegions:

    AcceptEventActions in the region that do not have incoming edges are enabled only when a token enters the region, even if the token is not directed at the AcceptEventAction.

    If taken literally, this would mean, that AcceptEventActions stay enabled after the token leaves the region. This seems to make no sense. If they start with the arrival of a token, they also should stop on the departure of it.
    I believe that the sentence was meant to read "while a token is in the region".

    Suggestion
    Change the sentence to

    AcceptEventActions in the region that do not have incoming edges are enabled only while other contained Actions are either enabled for execution or currently executing. That means, as soon as the first Action in the region becomes enabled, all AcceptEventActions without incoming edges become enabled as well. And as soon as the last Action has finished execution, the AcceptEventActions become disabled.

    This also means, that not the whereabouts of the token are relevant, but the status of the Actions. I'm aware, that this could be regarded as a change, since the token is technically still in the InterruptibleActivityRegion, as long it has not been accepted by the next Action. However the suggested semantics would be in line with the completion semantics of Activities and StructuredActivityNodes.

    The sentence "even if the token is not directed at the AcceptEventAction" seems superfluous and I have left it out. How could a token be directed at an Action without incoming edges?

  • Reported: UML 2.5 — Tue, 9 Apr 2019 16:55 GMT
  • Updated: Tue, 9 Apr 2019 16:55 GMT

New proposal for conjugate types for ports

  • Key: UML22-457
  • Legacy Issue Number: 13080
  • Status: closed  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    The SoaML submission team understands the concerns about making UML extensions at all, let alone introducing changes too high up in the hierarchy that might introduce additional unintended inheritance issues. But we are also reluctant to submit to the UPMS RFP without addressing the need to distinguish services from requests, and without addressing the usability issues that result from the need to create separate types for both ends of a connector.

    Recall that the problem is that ports appear on two ends of a connector. It is very often the case that consumers and providers can agree on the provided and required interfaces, and the interaction characteristics (protocol) and should therefore be able to use the same type to highlight that agreement. This is not possible with UML2. Ports don't have direction to indicate whether the owning component is using the operations or providing them. So users are forced to create "conjugate" types that flip the usage and realization relationships between classes and interfaces. This is especially troubling for the common simple case where the port is typed by a simple Interface.

    There have been a number of suggestions about how to solve this problem, many involving how ports define provided and required interfaces, and whether they need a type at all. We wanted to solve this problem without making a lot of changes to UML that may have other unintended consequences, or not sufficiently address the issues. So our updated proposal is very simple, and hopefully not something that would in any way effect future changes to UML2.

    We suggest the addition of a new Enumeration called PortDirection which has literals incoming and outgoing. Then add a new ownedAttribute to Port called direction: PortDirection = incoming. This would provide a direction on port that would be used to change how the provided and required interfaces are calculated. If direction=incoming, then the provided interfaces are those realized by the port's type and the required interfaces are those used by its type. If the direction is outgoing, the calculations are reversed: the provided interfaces are those used by the port's type, and the required interfaces are those realized by the port's type. Therefore, provided and required interfaces are calculated from the point of view of the owner of the port based on whether they are using the capabilities defined by the port's type, or providing them.

    This does not provide similar capabilities for things like connected collaborationRole Properties in a Collaboration. These properties are of course not Ports, and there is no specific specialization of Property (i.e., Role) that distinguishes the usage of a property in a collaboration that could specify the direction from other usages of property where direction is not relevant. We will miss that capability, but don't want to expand the scope of the UML change to address it at this time. Rather we'll wait and see if the UML2 RTF comes up with a more general solution that is also consistent with port direction.

    Is this acceptable?

  • Reported: UML 2.1.2 — Thu, 6 Nov 2008 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    This issue addresses a widely-recognized fundamental omission from UML. As such it is worthy of making an exception to normal RTF policy of not introducing new features to the language, particularly since the new feature is purely additive.
    But the wording of the proposed change in the UPMS specification is somewhat problematical. Notably the idea of "incoming" and "outgoing" does not sit very comfortably with the notion of a Port being essentially a bidirectional intermediary entity which specifies both provided and required interfaces.
    For this reason we propose a slightly different solution with similar semantic consequences: the introduction of a Boolean property isConjugated (default false) to the metaclass Port. When isConjugated is false, the semantics of Port are what they are today. When isConjugated is true, the calculation of provided and required interfaces from the Port's type is inverted.
    This works nicely when the type of a port is a single interface, because it allows a port that provides one interface and a port that requires one interface both to be simply represented. Today, a simple port that requires one interface has to be typed by a class that requires that interface, which is cumbersome and inconvenient.
    However, the idea of conjugating a port renders problematical the concept of instantiating the port type in the form of "interaction points" as currently specified in chapter 9. Instantiating the same type at both ends of an asymmetrical link is clearly unlikely to work. From a SoaML point of view, the port type represents a protocol, which will be applied differently at each end of the link depending on the sense of isConjugated. Therefore from a UML point of view we propose to delete all text that suggests direct instantiation of port types.
    Finally, it is important for modelers to be able to distinguish conjugated ports in the notation, so we introduce suitable new notation.

  • Updated: Mon, 1 Apr 2019 08:04 GMT

Semantics of Ports in Components and CompositeStructures are incompatible

  • Key: UML22-459
  • Legacy Issue Number: 13140
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    In chapter 9 (CompositeStructures) the semantics of ports are given strictly in terms of instantiating the owning classifier and instantiating the ports as “interaction point objects” typed by the type of the port. Yet in chapter 8 (Components), a Component (through its IsIndirectlyInstantiated attribute) may not be instantiated at run time, in which case the inherited semantics of ports and port types cannot apply. The sentence from 8.3.1 “The required and provided interfaces may optionally be organized through ports, these enable the definition of named sets of provided and required interfaces that are typically (but not always) addressed at run-time” clearly states that ports are a way to organize required and provided interfaces of a component at design time, yet this is contradictory to the notion that the provided and required interfaces of a port are derived from its type which is instantiated as interaction point objects. These contradictions should be resolved

  • Reported: UML 2.1.2 — Thu, 4 Dec 2008 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Much of this issue is resolved by 13080, in which the text about the interaction point objects being instances of the port types has been deleted.
    The remainder of the issue can be handled by some explanatory text as proposed below.

  • Updated: Mon, 1 Apr 2019 08:04 GMT

Description of Generalization of Enumerations is contradictory

  • Key: UMLR-750
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Axel Scheithauer)
  • Summary:

    The specification says:

    An instance of a Classifier is also an (indirect) instance of each of its generalizations.

    This means that the run-time extension of a general Classifier includes the extension of the specific Classifier: All instances of Rectangle are also instances of Polygon.
    Now it says about Enumeration:

    An EnumerationLiteral defines an element of the run-time extension of an Enumeration.

    Taken together this means that all EnumerationLiterals of a specific Enumeration (its run-time extension) must also be contained in the set of Literals of the general Enumeration.
    Finally it says about Enumeration specialization:

    An Enumeration that specializes another may define new EnumerationLiterals that are not defined in the generalizing Enumeration.

    This is a contradiction. The extension of a specific Classifier must always be smaller than that of the general Classifier.
    I agree that this makes the specialization of Enumerations unusable for a lot of purposes. However I don't see how this could get changed.

  • Reported: UML 2.5 — Tue, 8 May 2018 14:07 GMT
  • Updated: Wed, 13 Mar 2019 06:40 GMT
  • Attachments:

Duplicated xmi:id values in UML.xmi

  • Key: UMLR-758
  • Status: open  
  • Source: AGI ( Daniel Yankowsky)
  • Summary:

    The following `xmi:id` attribute values occur multiple times in the document. My understanding is that `xmi:id` attribute values are meant to be unique.

    This looks like a copy/paste error. The given IDs are present within the `UML::StateMachine::State` class and within the `UML::StateMachine::Vertex` class. I suspect that the elements within the `Vertex` class should be prefixed with `Vertex-` instead of `State-`.

    • State-isConsistentWith
    • State-isConsistentWith-_ownedComment.0
    • State-isConsistentWith-pre
    • State-isConsistentWith-pre-_specification
    • State-isConsistentWith-redefiningElement
    • State-isConsistentWith-result
    • State-isConsistentWith-spec
    • State-isConsistentWith-spec-_specification
  • Reported: UML 2.5.1 — Wed, 27 Feb 2019 16:44 GMT
  • Updated: Wed, 6 Mar 2019 14:54 GMT

Behavior::behavioredClassifier bodycondition is serialized as a precondition

  • Key: UMLR-756
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    Behavior::behavioredClassifier like many UML operations has a body defined in OCL.

    This is normally "result="-prefixed to become a pseudo-Boolean bodycondition in XMI.

    However exceptionally Behavior::behavioredClassifier is serialized as a precondition where its non-Boolean value is an error. (Eclipse OCL has finally added the relevant WFR.)

  • Reported: UML 2.5.1 — Sat, 19 Jan 2019 13:18 GMT
  • Updated: Thu, 31 Jan 2019 15:23 GMT

Unclear whether current State during Transition is the target State

  • Key: UMLR-755
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Axel Scheithauer)
  • Summary:

    The specification says:

    Regardless of how a State is entered, the StateMachine is deemed to be “in” that State even before any entry Behavior or effect Behavior (if defined) of that State start executing.

    States don't have effect Behaviors, only Transitions have them. Is that meant here? It would make sense, because otherwise there is no specification, what State the Machine would be "in" during the Transition. And since the effect Behavior could refer to the current State, it must have a defined State.

    Suggested change

    Regardless of how a State is entered, the StateMachine is deemed to be “in” that State even before any entry Behavior of that State or effect Behavior of the Transition leading to it (if defined) start executing.

  • Reported: UML 2.5.1 — Mon, 21 Jan 2019 13:59 GMT
  • Updated: Mon, 21 Jan 2019 13:59 GMT

Figure 9.11 misses attribute name

  • Key: UMLR-754
  • Status: open  
  • Source: Rheinmetall Air Defence ( Yves Strube)
  • Summary:

    In Figure 9.11 "ClassB" has an attribute "Integer = 7" which redefines the default of "ClassA::height". However the name of the attribute seems to be missing in "ClassB". It should probably say "height: Integer = 7".

  • Reported: UML 2.5.1 — Wed, 9 Jan 2019 06:40 GMT
  • Updated: Mon, 14 Jan 2019 20:37 GMT

I believe ptc/08-05-12 and ptc/08-05-06 got mixed up on the UML 2.2 specification page

  • Key: UMLR-753
  • Status: open  
  • Source: N/A ( Logan Campos)
  • Summary:

    I believe there is a typo/bug on https://www.omg.org/spec/UML/2.2.
    In the "Informative Machine Consumable Documents" section, The Filename for ptc/08-05-12 is "Infrastructure" and the Filename for ptc/08-05-06 is "Superstructure" and it should be vice versa.

  • Reported: UML 2.2 — Sat, 1 Dec 2018 07:59 GMT
  • Updated: Wed, 5 Dec 2018 16:24 GMT

The definition of relative Time Events is ambigious

  • Key: UMLR-751
  • Status: open  
  • Source: Scarecrow Consultants ( James Towers)
  • Summary:

    A relative Time Event i.e. after(x) as used as a trigger on a state machine transition is ambiguous as it is not clear when the earliest occurrence of this trigger could be.

    If the originating state is entered at time T1 and the transition is taken at time T2 then providing T2 - T1 > x the event has happened 'after' x (in the common meaning of the word),
    however if T2 - T1 = x it is not clear if the transition has been taken too early or not. This is because it is not defined whether 'after' means T2 - T1 > x or T2 - T1 >= x

  • Reported: UML 2.5.1 — Thu, 18 Oct 2018 16:15 GMT
  • Updated: Mon, 22 Oct 2018 14:35 GMT

About behavior ports

  • Key: UMLR-292
  • Legacy Issue Number: 19070
  • Status: open  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    On the semantics of behavior ports, UML 2.5 §11.3.3 says:

    “A Port has the ability, by setting the property isBehavior to true, to specify that any requests arriving at this Port are handled by the Behavior of the instance of the owning EncapsulatedClassifier, rather than being forwarded to any contained instances, if any”

    It is not clear whether “the Behavior” refers to the classifier behavior only or to any owned behavior. In the former case, an invocation of Op1()at this port can only have a triggered effect, i.e. the classifier behavior should specify a trigger associated to the corresponding CallEvent since the method specified for this operation (if any) will not be executed as a direct consequence of this invocation.

    This has to be clarified.

  • Reported: UML 2.5 — Thu, 7 Nov 2013 05:00 GMT
  • Updated: Fri, 20 Apr 2018 14:30 GMT

Operation calls on behavior ports

  • Key: UMLR-54
  • Legacy Issue Number: 8748
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Operation calls on behavior ports. Per FTF discussion, clarify that an operation call can arrive at a behavior port and be handled by a method on the owning object, without going to the classifier behavior

  • Reported: UML 2.0 — Sun, 1 May 2005 04:00 GMT
  • Updated: Fri, 20 Apr 2018 14:30 GMT

Behavioral port

  • Key: UMLR-107
  • Legacy Issue Number: 10597
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    Title: Non-behavior ports cannot forward requests to behavioral features of the owning classifier
    Specification: Unified Modeling Language Superstructure v2.1 (ptc/06-04-02)
    Section: 9.3.11 Port

    Description:

    Currently, the semantics of ports may be summarized as follows:

    1. If the port not a behavior port, but it has a connector to an internal part of the owning classifier, then a request directed to the port via a provided interface is forwarded along that connector. If it is not connected to an internal part, "any requests that arrive at this port will terminate at this port."

    2. If the port is a behavior port, then a request directed to the port via a provided interface is forwarded to the classifier behavior for the owning classifier. (This is what it means to be a behavior port – requests are forwarded to the classifier behavior.) If the owning classifier does not have a classifier behavior, then "any communication arriving at a behavior port is lost."

    Since the intent of a port is to "provide a means through which requests can be made to invoke behavioral features of a classifier", it would seem natural to have a way for a request through port to be directly forwarded to a behavioral feature of the owning classifier. Currently, however, this can only be done via a behavior port and an explicit classifier behavior that dispatches requests appropriately. A request to a non-behavior port that does not have an internal connection is not handled by the instance of the owning classifier, but rather "terminates" at the port.

    Note also that the text currently states that "the owning classifier must offer the features owned by the provided interfaces" of a port, but there is no formal constraint to this effect.

    Suggested resolution:

    1. Add a constraint that an encapsulated classifier must realize all the provided interfaces of all its ports.

    2. Keep the semantics of a behavior port to be that requests are forwarded to the classifier behavior.

    3. For a non-behavior port with connectors no connectors to any internal parts, any request arriving at the port is forwarded to the method of the corresponding behavioral feature of the owning classifier (if there is such a method).

    4. In other cases, specify that the semantics is not defined, rather than that requests are "terminated" or "lost". Such cases include behavior ports when there is no classifier behavior and non-behavior ports for behavioral features with no corresponding method.

  • Reported: UML 2.5 — Thu, 18 Jan 2007 05:00 GMT
  • Updated: Fri, 20 Apr 2018 14:30 GMT

Are null NamedElement::name values names?

  • Key: UMLR-749
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    I am informed that UML aspires to have null-free collections, even though UML uses OCL which explicitly supports null within collections.

    There is a UML/OCL conflict for Namespace::getNamesOfMember for which a null-named element returns a non-empty set. Consequently multiple unnamed elements such as Constraints violate the NamedElement::isDistinguishableFrom query and so are not valid in UML.

    If an ->excluding(null) is added to the getNamesOfMember result, a more interesting semantics that a null name is not a name results and permits multiple null-named Constraints.

    If this change is pursued, 7.4.3.2 needs to be explicit rather than suggestive that an unnamed element has a null name which is an absence of a name and so when aggregated in a collection of names does not contribute a null value. Perhaps a 6.3.4 section is needed to generically specify that every Collection value in every specified OCL body has an implicit aCollectionValue->excluding(null) to enforce the no-nulls-in-collections semantics of UML.

  • Reported: UML 2.5 — Thu, 15 Feb 2018 16:41 GMT
  • Updated: Fri, 6 Apr 2018 19:23 GMT


Typo

  • Key: UMLR-747
  • Status: open  
  • Source: Yxlon ( Jörn Sierwald)
  • Summary:

    The last paragraph refers to a property called isDirectlyInstantiated. The property is actually called isIndirectlyInstantiated.

  • Reported: UML 2.5.1 — Wed, 17 Jan 2018 08:22 GMT
  • Updated: Wed, 24 Jan 2018 16:01 GMT

Figure 7.17 has some trucated labels

  • Key: UMLR-746
  • Status: open  
  • Source: Middle East Technical University ( Alper Tolga Kocatas)
  • Summary:

    An item in the figure starts with "Abstraci.." but the rest of the label is trucated.

    Not that there are other diagrams in the document which has the same problem. Thus, this comment is a general comment which applies to other diagrams as well (i.e. NamedElement in Figure 7.5)

  • Reported: UML 2.5 — Mon, 25 Dec 2017 09:30 GMT
  • Updated: Thu, 4 Jan 2018 16:43 GMT

Typo in last syntax example

  • Key: UMLR-745
  • Status: open  
  • Source: Fraunhofer FOKUS ( Niels Hoppe)
  • Summary:

    There is a minor typo in the last syntax example for message signatures in interactions:

    v=mymsg(w=myout:16):96 // this is a reply message assigning the return value 69 to ‘v’ and [...]

    The syntax example shows the number 96 (ninety-six), whereas the explanation shows the number 69 (sixty-nine) as the return value.

  • Reported: UML 2.5 — Wed, 6 Dec 2017 10:32 GMT
  • Updated: Thu, 4 Jan 2018 16:37 GMT

Attachment point of connectors not specified

  • Key: UMLR-744
  • Status: open  
  • Source: me.com ( Thomas Kilian)
  • Summary:

    There does not seem to be any kind of specification where exactly a connector should end. I.e. on the border of an element, some way inside the element or a bit way off. Obviously the specification itself attaches all connectors exactly on the border of elements. This should be rectified.

    In a tool like Enterprise Architect that's true for most of the cases. However, for rounded elements EA still uses a rectangular frame where connectors attach so for UseCase bubbles connectors can end a bit offset. Further they have a special feature to link attributes which intrudes the connector with a small open rectangle into the element.

  • Reported: UML 2.5 — Thu, 5 Oct 2017 12:33 GMT
  • Updated: Tue, 17 Oct 2017 14:25 GMT

Implied Multiplicity of the association-like notation should be displayable

  • Key: UMLR-743
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Axel Scheithauer)
  • Summary:

    The specification says:

    In a Classifier, an attribute may also be shown using association notation, where only an aggregation adornment (hollow or filled diamond) may be shown at the tail of the arrow.

    This association-like notation for attributes implies a Multiplicity of * for the opposite end. Since there is no Association and therefore also no opposite end, this Multiplicity can currently not be shown in a diagram. This might be a problem, since most modelers think, that a missing Multiplicity means 1. This is not true, but since this interpretation is so widespread, it should be possible to show the implied Multiplicity, even though there is no model element corresponding to it.
    The UML knows many notations that don't directly correspond to a model element (the dashed line between Comment and annotated Element, the circle plus Notation for ownership), so I don't think adding a notation for a virtual Multiplicity poses any problem. It just completes the association like notation. Other distinguishing features are not necessary, because the interpretations are not conflicting: An attribute can also be an associationEnd.

    Suggestion
    Add following sentence to the paragraph above:

    The implied Multiplicity of the opposite end is not limited. A * may may be shown on this end to make it distinguishable from an unidirectional Associaton without defined Multiplicity (which has an implied Multiplicity of 1).

  • Reported: UML 2.5 — Mon, 28 Aug 2017 18:40 GMT
  • Updated: Wed, 6 Sep 2017 09:25 GMT

Lifeline "same_classifier" constraint has an inconsistent specification

  • Key: UMLR-742
  • Status: open  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    The English description of the "same_classifier" constraint is much more restrictive that the specified OCL expression (see 17.12.17.5):

    The classifier containing the referenced ConnectableElement must be the same classifier, or an ancestor, of the classifier that contains the interaction enclosing this lifeline.

    inv: represents.namespace->closure(namespace)->includes(interaction._'context')

    Please clarify.

  • Reported: UML 2.5 — Mon, 21 Aug 2017 12:50 GMT
  • Updated: Mon, 21 Aug 2017 12:50 GMT

Incorrect use of multiplicity element.

  • Key: UMLR-738
  • Status: open   Implementation work Blocked
  • Source: ARAG ( Rob Grainger)
  • Summary:

    The standard defines lowerBound() and upperBound() as returning 1 when the value is unspecified.

    However, many attributes in the XMI (for example Activity::edge - the very first attribute in the XMI) are specified as if the default lowerBound() is 0. No attributes (AFAICT) set the default value to "1".

    I am trying to generate code from the XMI but this becomes a blocking issue - there is no possible default behaviour.

  • Reported: UML 2.5 — Thu, 25 May 2017 19:45 GMT
  • Updated: Mon, 14 Aug 2017 07:42 GMT

Complete and Covering are Synonyms and used confusinginly

  • Key: UMLR-620
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    7This is a complaint about the fact the complete and covering are synonyms. and are clearly defined as synonyms
    isCovering is used in the metamodel in 9.7.2/9.7.3

    However, in table 9.1 the notational term is Complete/incomplete.

    Having the synonyms only adds confusion and lowers the professionalism of the spec. If a user modeled a generalization as IsCovering=True, would that be wrong?

    This will be confusing to students taking the UML Certification exams.

    An earlier version of this issue was closed with no discussion.

  • Reported: UML 2.5 — Fri, 29 May 2015 04:08 GMT
  • Updated: Wed, 26 Jul 2017 09:48 GMT

Does the abort of an Do/Activity by an incoming event count as a Completion Event

  • Key: UMLR-730
  • Status: open   Implementation work Blocked
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    There are good reasons why end of behavior by an incoming external event should not trigger a completion event., e.g., RTC.

    However it is not explicit, which is confusing especially as it seems the completion event has a higher dispatching priority.

    In 14.2.3.8.3 .."In case of simple States, a completion event is generated when the associated entry
    and doActivity Behaviors have completed executing"

    A statement should be added here (or elsewhere) to clarify that this does not include the aborting of the task, or that this is different from a completion event.

  • Reported: UML 2.5 — Tue, 28 Feb 2017 01:22 GMT
  • Updated: Wed, 28 Jun 2017 17:24 GMT

UML Interactions: Misleading suggestion of relationship between Interactions and Activities modeling

  • Key: UMLR-234
  • Legacy Issue Number: 15421
  • Status: open  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    In section 14.4 that describes Interaction diagrams, there are statements describing interaction overview diagrams that is highly misleading and which, in my consulting experience with numerous UML users, have been the source of much misunderstanding:

    "Interaction Overview Diagrams are specialization of Activity Diagrams that represent Interactions"

    as well as:

    "Interaction Overview Diagrams define Interactions through a variant of Activity Diagrams"

    While there is indeed syntactic similarity between the two forms (e.g, with fork and join nodes), the underlying semantics between the two diagrams are quite different. For instance, activities, by definition, fully complete their execution before passing control/data tokens to their successors (as defined by the token passing rules), whereas this does not hold in general for interaction uses (the blocks in an overview diagram). In fact, while one object/lifeline could still be completing its business in one interaction use block (so to speak), its collaborating peer could already have entered a successor block. That is, in general, there is no implicit synchronization between lifelines when entering and exiting the blocks in an overview diagram. (Far too many users assume this type of synchronization, resulting in erroneous or unimplementable model specifications.)

    There are numerous other semantic differences between Interactions and Activities (e.g., the latter include the notion of pins, control and data flow tokens, etc., while the former do not have any such notions), which further invalidate the claim that one is a special variant of the other. Finally, the metamodels underlying the two diagrams are completely different To summarize: Interaction Overview diagrams are NOT a specialization or variant of Activity Diagrams.

    The solution to this problem is not just to remove the two misleading statements, but to also add an explanation that explicitly points out the differences between the two, so that readers are not misled by the similarity in notations.

  • Reported: UML 2.5 — Thu, 19 Aug 2010 04:00 GMT
  • Updated: Wed, 28 Jun 2017 17:20 GMT

DecisionNode is missing a constraint on incoming edges

  • Key: UMLR-740
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    In the first paragraph of subclause 15.3.3.6 of the UML 2.5 specification, it states: "If it has two incoming edges, then one shall be identified as the decisionInputFlow, the other being called the primary incoming edge." However, while subclause 15.7.12 DecisionNode includes constraints that require a decision node to have at most two incoming edges and require a decisionInputFlow to be an incoming edge, there is no constraint that requires that, if a decision node has two incoming edges, one of them must be the decisionInputFlow. This constraint should be added.

  • Reported: UML 2.5 — Wed, 28 Jun 2017 17:14 GMT
  • Updated: Wed, 28 Jun 2017 17:14 GMT

How to access a token value in a guard?

  • Key: UMLR-306
  • Legacy Issue Number: 19199
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Axel Scheithauer)
  • Summary:

    It is specified that the evaluation of the guard of an ActivityEdge could use the value in the token offered to the edge (see page 392 and 406). However the way, how a guard accesses the value in the token is never specified.

    15.2.3 page 392
    >An offer shall only pass along an ActivityEdge if the guard for
    >the edge evaluates to true for the offered token.

    That sentence could get interpreted, that the guard will evaluate the object in the token (in case it contains one). Maybe I'm over interpreting the sentence. Then how about this one, taken from the chapter on DecisionNodes:

    15.3.3 page 406
    >...the value contained in an incoming object token may be used in
    >the evaluation of the guards on outgoing ObjectFlows

    Since it is explicitly specified for ActivityEdges coming out of DecisionNodes, I think the same should be true with any Edges.

    Now that I have established, that guards should have access to the value in an object token, the question remains, how is this done? The natural way would be to define a parameter of the guard, the same way this is done for selection Behaviors. However guards are ValueSpecifications, and this element cannot have parameters. The Value could be specified by a Behavior, but as far as I understand, this behavior can only have a return parameter (even though there is no constraint).

    How could this get solved? Maybe we need a new subclass of ValueSpecificaton like TokenValueSpecification to be used in Expressions? Or we need to allow Behaviors to be used as guards. Another possibility would be to do it the fUML way: The value in the token is compared with the result of the guard-Expression. Here we don't need a parameter. However it would make it hard to define certain kinds of guards (e.g. token.value between l and u) and I don't think, that the current specification includes the interpretation of fUML.

  • Reported: UML 2.5 — Thu, 30 Jan 2014 05:00 GMT
  • Updated: Wed, 28 Jun 2017 16:27 GMT

Conflicting constraints

  • Key: UMLR-711
  • Status: open   Implementation work Blocked
  • Source: Flanders Make ( Klaas Gadeyne)
  • Summary:

    One of the constraints on objectFlows in 15.7.22.6 is

    compatible_types
    ObjectNodes connected by an ObjectFlow, with optionally intervening ControlNodes, must have compatible types. In particular, the downstream ObjectNode type must be the same or a supertype of the upstream ObjectNode type.

    It is unclear how this has to be interpreted in the case of two objectNodes with a decisionNode in between. More specifically,

    Imagine a decisionNode with 2 incoming objectFlows:

    • 1 objectFlow, whose target is the decisionNode and whose source is an outputPin of type A
    • 1 objectFlow, whose target is the decisionNode, and whose source is an outputPin of type Boolean. This objectFlow is tagged as the decisionInputFlow of the decisionNode

    The decisionNode also has 2 outgoing objectFlows, guarded by [verdict] and [!verdict] and targeting to (two) inputPins of type A

    Whereas the latter model snippet seems to be a valid model according to the documentation on DecisionNode, the 'compatible_types' constraint does not hold for the connection between the outputpin of type Boolean and any inputPin of type A, since A is not a supertype of boolean.

  • Reported: UML 2.5 — Fri, 14 Oct 2016 10:06 GMT
  • Updated: Wed, 28 Jun 2017 16:24 GMT

Restrictions on decision nodes

  • Key: UMLR-243
  • Legacy Issue Number: 15850
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    In activity diagrams, the input and outputs to a decision node much all be control or object flows. However, I’m not sure why I need to have that restriction enforced. I can see that if the input is control, no output can be an object flow (because how would the object flow be generated). However, I can imagine cases where an input object flow is evaluated, and

    1) If the Object flow is good, the object flow is then passed to a downstream activity

    Or

    2) If the object flow fails, a control flow is sent to start an error recovery activity, but this activity has no need for the object flow in error

    I would imagine the correct restriction is that If the input flow to a decision is a control flow, only control flows can come out of the decision.

  • Reported: UML 2.5 — Fri, 5 Nov 2010 04:00 GMT
  • Updated: Wed, 28 Jun 2017 16:22 GMT

Unspecified and inconsistent notation for Observations

  • Key: UMLR-668
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Axel Scheithauer)
  • Summary:

    The specification says about the notation of Observations:

    An Observation may be denoted by a straight line attached to the NamedElement it references. The Observation is given a name that is shown close to the unattached end of the line.

    There are a number of places, where the Observations are shown as "t=now" and "d=duration". "now" and "duration" are never explained and unnecessary. An Observation is just a name at the end of a line connected to the observed Element. It could be ambiguous, which kind of Observation is meant. However this is also the case for many other model Elements. For a modeler this is usually no problem, because she will anyway choose a name that makes it clear, what is meant ("TransmissionDuration", "Receptiontime"). And it is always possible to look up the type in the model.

    The interpretation that these are Time (or Duration) Expressions makes no sense, since they just reference one Observation. In this case the specification says:

    [..] it is simply represented by its single associated Observation.

    Even when we interpret "t=now" as an Expression, it would not be a TimeExpression, since its result is a Boolean.

    Suggestion
    Replace "t=now" with "OkSendTime" and "d=duration" with "TransmissionDuration" (alternatively with "t1" and "d1"):

    • Figure 8.5 (and Figure 17.5, which is the same figure). Since it doesn't show an Expression, "with TimeExpression" should get removed.
    • Table 17.1 row "DurationConstraint Duration Observation"
    • Table 17.1 row "TimeConstraint TimeObservation"
    • Figure 17.30 (additionally it is not clear, which Element is referenced by d. It could get connected to Message "Code")
  • Reported: UML 2.5 — Fri, 4 Mar 2016 13:58 GMT
  • Updated: Sun, 11 Jun 2017 11:36 GMT

Explanation of Observation notation

  • Key: UML22-319
  • Legacy Issue Number: 10974
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    UML2 Superstructure 2.1.1:Interactions

    In Fig 14.26 there are various time annotations shown which relate to the Simple Time package.

    The notation sections for TimeObservation and DurationObservation read thus:

    TimeObservation: “A time observation is often denoted by a straight line attached to a model element. The observation is given a name that is shown close to the unattached end of the line.”

    DurationObservation: “A duration observation is often denoted by a straight line attached to a model element. The observation is given a name that is shown close to the unattached end of the line.”

    However the notations in Figure 14.26 look like this:

    TimeObservation: “t=now”

    DurationObservation: “d=duration”

    I don’t see how the example notation is consistent with the notation descriptions

  • Reported: UML 2.1 — Fri, 27 Apr 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Merged with 17841

  • Updated: Sun, 11 Jun 2017 11:36 GMT

ReturnValueRecipient missing in Metamodel Diagram of InteractionUse

  • Key: UMLR-737
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Axel Scheithauer)
  • Summary:

    Figure 17.18 shows the Metamodel of InteractionUses. According to the list in 17.12.16.5 there is an Association to Property ( A_returnValueRecipient_interactionUse). It is missing in the figure and should get added.

  • Reported: UML 2.5 — Wed, 5 Apr 2017 16:28 GMT
  • Updated: Wed, 5 Apr 2017 16:28 GMT

Figure 17.20 "InteractionUse with value return" shows incorrect notation

  • Key: UMLR-736
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Axel Scheithauer)
  • Summary:

    There are a number of problems with the notation shown in Figure 17.20

    1. In the list of parameters the type should follow the name (x:Integer)
    2. The asynchroneous message s1 cannot be sent to a non active Class (better use a synchroneous message)
    3. The return value assignment of the InteractionUse has an unusual format (:xx.xc). The specification doesn’t define the format, however I would suggest to use notation from common object oriented programming languages. To do this, the property referenced by the left lifeline should have a name (e.g. xx1). Then the notation would be xx1.xc.
    4. The argument for the inout parameter w should be prefixed with out (according to the specification, even though it is probably unambiguous even without it).
    5. Sending asynchroneous messages to an Integer value is not possible (DataTypes cannot be active).
    6. Sending a message to an Integer value to set this value is not possible (put(xc)…). This would mean to ask Integer Value “2” to put Value “9”. The object owning the parameter that has this value is responsible for setting it. If w would be an attribute, it could be done with a AddStructuralFeatureValueAction called by an ActionExecutionSpecification of lifeline :xx (see Figure 17.16). If the value is read from the object, a getter could be used and the return value could get assigned to the parameter or attribute (w=get_xc()). This works with out-parameters as w as well (but not for setting a parameter to a constant as a_op_b). However since both elements w and a_op_b are out-parameters of the Interaction, a more natural way would be to model the reply-message with the respective out values (a_op_b(w:xc):fail). In any case, the lifelines w and a_op_b are no longer needed.

  • Reported: UML 2.5 — Wed, 5 Apr 2017 14:15 GMT
  • Updated: Wed, 5 Apr 2017 14:15 GMT

Undefined notation for ownedBehaviors in Figures 17.23 and 17.24

  • Key: UMLR-735
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Axel Scheithauer)
  • Summary:

    In figures 17.23 and 17.24 Classifiers with a compartment for their ownedBehaviors are shown. The notation for these Behaviors is a diagram frame. This notation is not defined anywhere. In fact Section 9.2.4 describes another notation:

    The default notation for a Classifier is a solid-outline rectangle containing the Classifier’s name, and with compartments separated by horizontal lines below the name. […] If the default notation is used for a Classifier, a keyword corresponding to the metaclass of the Classifier shall be shown in guillemets above the name.

    I suggest to use this notation.
    Additionally the notation for the rolebindings in figure 17.24 should not have arrowheads.

  • Reported: UML 2.5 — Fri, 31 Mar 2017 09:18 GMT
  • Updated: Fri, 31 Mar 2017 12:57 GMT

Instances are linked to other instances, not associated

  • Key: UMLR-734
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Axel Scheithauer)
  • Summary:

    On page 198 it says:

    A qualified Association end has qualifiers that partition the instances associated with an instance at that end,...

    and on page 199:

    ...it is possible to have several instances associating the same set of instances...

    While "associating" and "linking" might be synonyms in normal language, in UML Classes are associated and Instances are linked.

    Suggestion
    Reword the sentences above:
    Page 198:

    A qualified Association end has qualifiers that partition the instances linked to an instance at that end,...

    and on page 199:

    ...it is possible to have several instances of the AssociationClass linking the same set of instances...

  • Reported: UML 2.5 — Tue, 28 Mar 2017 16:58 GMT
  • Updated: Tue, 28 Mar 2017 16:58 GMT

Odd restriction on state machine redefinition context

  • Key: UMLR-732
  • Status: open  
  • Source: DIA Agency, Inc. ( Christian W. Damus)
  • Summary:

    The StateMachine metaclass’s redefinition of the "isRedefinitionContextValid(redefinedElement : RedefinableElement) : Boolean" operation is oddly over-constrained, requiring that the context classifier of a redefining state machine redefine the context classifier of the redefined state machine.  It seems more plausible that this constraint should only require, or should also allow, that the context classifier of the redefining state machine be a specialization of the context classifier of the redefined state machine.  Otherwise, state machine redefinition can only be valid for state machines that are owned behaviours of classifiers that are nested in other classifiers, because these context classifiers are required to have their own valid redefinition contexts.

    That is to say, one might expect an OCL formulation more like this:

    body:
    redefinedElement.oclIsKindOf(StateMachine) and
    let redefinedStateMachine : StateMachine = redefinedElement.oclAsType(StateMachine) in
    self.'context'().allParents()->includes(redefinedStateMachine.'context'())

  • Reported: UML 2.5 — Wed, 8 Mar 2017 23:37 GMT
  • Updated: Thu, 9 Mar 2017 18:30 GMT

Clarify diagram notation for collection parameters in operation

  • Key: UMLR-729
  • Status: open  
  • Source: LSST ( Paul Lotz)
  • Summary:

    Please clarify the notation diagram for indicating that an operation parameter is a collection (e.g., array). Some tools do not indicate this on the diagram, but simply indicate the base type. It is unclear to me, at least, if the specification really requires anything else. It would seem to be appropriate for a future version of the specification to require this and to specify the manner in which this appears.

  • Reported: UML 2.5 — Thu, 23 Feb 2017 17:49 GMT
  • Updated: Mon, 27 Feb 2017 22:02 GMT

Transistion selection algorithm is incomplete

  • Key: UMLR-728
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Axel Scheithauer)
  • Summary:

    The specification says about the state machine transition selection algorithm:

    The set of Transitions that will fire are the Transitions in the Regions of the current state configuration that satisfy the following conditions:

    • All Transitions in the set are enabled. [see 14.2.3.9.2 Enabled Transitions]
    • There are no conflicting Transitions within the set. [see 14.2.3.9.3 Conflicting Transitions]
    • There is no Transition outside the set that has higher priority than a Transition in the set. [see 14.2.3.9.4 Firing priorities]

    Remarks in square brackets are from me to show that each line refers to a definition given further up.
    From the name of this section I would expect, that it describes the complete algorithm. However one part is missing:

    • Only Transitions that occur in mutually orthogonal Regions may be fired simultaneously.

    This sentence is from the section on conflicting Transitions. In my humble opinion part of it belongs to the selection algorithm and not to the definition of conflicting transitions.

    Suggestion
    reprase the sentence in "conflicting Transitions":

    Transitions in mutually orthogonal Regions are not conflicting.

    Add a point to "transition selection algorithm" that explains, that only one transition per region may fire. This may seem obvious to you, but I think it needs to be stated explicitely. I know, there are other sentences which support this interpretation. But the algorithm section is the one place where all should come together.

  • Reported: UML 2.5 — Tue, 14 Feb 2017 11:40 GMT
  • Updated: Tue, 14 Feb 2017 11:40 GMT

UML: Missing property subset for StateMachine::extendedStateMachine

  • Key: UMLR-727
  • Status: open  
  • Source: Eclipse Foundation ( Mr. Kenneth Hussey)
  • Summary:

    The StateMachine::extendedStateMachine property redefines Behavior::redefinedBehavior but it should also subset Classfier::redefinedClassifier so that extended state machines are included in the set of redefined classifiers (and, in turn, redefined elements) for a state machine.

  • Reported: UML 2.5 — Thu, 9 Feb 2017 17:07 GMT
  • Updated: Thu, 9 Feb 2017 18:43 GMT

Nested activities in activity diagrams

  • Key: UMLR-725
  • Status: open  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    It is not clear whether activities defined as nested classifiers in another activity can be shown in the activity diagram of this activity. Is it allowed to have more than one activity frame in one activity diagram?

  • Reported: UML 2.5 — Fri, 27 Jan 2017 07:51 GMT
  • Updated: Wed, 1 Feb 2017 23:02 GMT

Template binding relationship incorrect notation

  • Key: UMLR-726
  • Status: open  
  • Source: gmail.com ( Filip Stachecki)
  • Summary:

    Figure 9.5 Template Class and Bound Class shows incorrect template binding relationship notation. It presents open arrow head drawn with a thick line (not part of UML specification) and not fully dashed line (something between dotted and dashed). This notation is different from one presented in UML 2.5 beta.
    According to section 7.3.4 Notation: A TemplateBinding is shown as a dashed arrow with the tail on the bound element and the arrowhead on the template and the keyword «bind».

  • Reported: UML 2.5 — Tue, 31 Jan 2017 08:23 GMT
  • Updated: Tue, 31 Jan 2017 19:19 GMT

bad example for weight in Figure 15.21

  • Key: UMLR-724
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Axel Scheithauer)
  • Summary:

    In the lower diagram on Figure 15.21 an incoming ObjectFlow on a JoinNode has weight=*. As far as I understand this has no effect, since a join node will offer all tokens offered to it to the outgoing ActivityEdge (15.3.3.4):

    If the joinSpec of a JoinNode evaluates to true, then tokens are offered on the outgoing ActivityEdge of the JoinNode [...]. [Object] Tokens are offered on the outgoing edge in the same order they were offered to the join. [...] The above rules apply to all tokens offered to the JoinNode, including multiple tokens offered from the same incoming edge.

    That means, in the moment, when the joinSpec becomes true, all tokens offered on the incoming Edges, will get offered on the outgoing Edge. The weight doesn't make any difference.

    I'm not sure, whether the same is true for Figure 15.59, where the ObjectFlow out of a DataStore is joined in the same way. Here it would make sense to retrieve the tokens one by one. However I don't see, where the specification would define this. When the DataStore contains 10 tokens, all of them are offered to the outgoing flow, and that means, all of them will be offered to the outgoing flow of a subsequent JoinNode. If we want to retrieve them one by one, the DataStore must offer them to a Pin with Multiplicity 1 directly.
    The examples should get removed, together with the sentence referring to them.

  • Reported: UML 2.5 — Thu, 26 Jan 2017 23:29 GMT
  • Updated: Sat, 28 Jan 2017 15:15 GMT

ActivityEdge weight examples

  • Key: UMLR-404
  • Legacy Issue Number: 19669
  • Status: open  
  • Source: NobleProg ( Filip Stachecki)
  • Summary:

    The last example in Figure 15.21 ActivityEdge weight examples join node has two incoming flows: control flow and object flow but outgoing flow is control flow. According to page 405:
    If any of the incoming edges of a JoinNode are ObjectFlows, the outgoing edge shall be an ObjectFlow. Otherwise the outgoing edge shall be a ControlFlow.

  • Reported: UML 2.5 — Wed, 3 Dec 2014 05:00 GMT
  • Updated: Sat, 28 Jan 2017 15:15 GMT

Implication of weight of ActivityEdge is unclear

  • Key: UMLR-723
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Axel Scheithauer)
  • Summary:

    The specification says in 15.2.3.3:

    The weight property dictates the minimum number of tokens that must traverse the edge [..]. The minimum number of tokens must then be accepted before any tokens shall traverse the edge.

    The number of tokens accepted by an InputPin is determined by its multiplicity (16.2.3.4):

    InputPins cannot accept more tokens than will be consumed immediately by their Actions during a single execution.

    That means, if the weight is greater than the upper value of the Pin multiplicity tokens can never traverse. The problem is, that the text could be mistaken to mean that the weight overrides the multiplicity. Therefore it should get clarified. With weight=* the problem is even bigger, since the number of tokens that must traverse is not known beforehand, so that the deadlock would depend on the accidental number of tokens waiting.

    Suggestion
    After

    The minimum number of tokens must then be accepted before any tokens shall traverse the edge.

    Add

    Note: If the targeted ObjectNode cannot handle this much tokens this rule leads to no tokens traversing. To avoid this, its upper multiplicity should be at least equal to the weight, even though it is not required by the syntax.

  • Reported: UML 2.5 — Thu, 26 Jan 2017 22:13 GMT
  • Updated: Sat, 28 Jan 2017 15:12 GMT

Conjugated port properties shown on association ends and in compartments

  • Key: UMLR-722
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Ports are properties that presumably can appear as association ends and in compartments. Clause 9.5.4 (Notation, Properties) gives BNF for property labels, which is reused in 11.5.4 (Notation, Association), but doesn't cover conjugated ports.

  • Reported: UML 2.5 — Mon, 2 Jan 2017 17:09 GMT
  • Updated: Mon, 2 Jan 2017 17:09 GMT

Actor Relationships

  • Key: UMLR-721
  • Status: open  
  • Source: Personal ( Thomas Owens)
  • Summary:

    It is very confusing to understand that an Actor may be a generalization of another Actor on a Use Case model of a system. An example of this is not provided in Section 18. To understand this, you need to trace up and back down the document and understand Actor, BehavioredClassifier, Classifier, Generalization, DirectedRelationship, Relationship, Association to see that a Generalization is not an Association.

    In section 18.2.1.4, the UML specification states: "An Actor can only have Associations to UseCases, Components, and Classes. Furthermore these Associations
    must be binary."

    In Section 18.2.1.3, the same document states that an Actor is a BehavioredClassifier. A BehavioredClassifier is also a Classifier.

    Section 9.9.4.6 defines the association ends for a Classifier. One of these relationships is Generalization.

    Section 9.9.7 defines the Generalization relationship. The generalization of a Generalization is a DirectedRelationship.

    Section 7.8.5 defines DirectedRelationship. The generalization of a DirectedRelationship is a Relationship.

    Section 7.8.15 defines the Relationship abstract class. The specializations of Relationship are DirectedRelationship and Association.

  • Reported: UML 2.5 — Wed, 28 Dec 2016 16:58 GMT
  • Updated: Thu, 29 Dec 2016 16:32 GMT

Incorrect arrow heads for object flows

  • Key: UMLR-720
  • Status: open  
  • Source: gmail.com ( Filip Stachecki)
  • Summary:

    Presentation option for flows between pins and parameter nodes contains incorrect arrows for object flows inside an activity
    There should be open arrow heads instead of filled.

  • Reported: UML 2.5 — Sun, 18 Dec 2016 20:01 GMT
  • Updated: Thu, 22 Dec 2016 19:24 GMT

Ambiguous meaning of word "composed"

  • Key: UMLR-718
  • Status: open  
  • Source: - ( REGEF)
  • Summary:

    The "composed" word is used as an antonym of the "composite" word, whereas it is more a synonym in common language.

    page 110 :
    "Indicates that the Property is aggregated compositely, i.e., the composite object has responsibility for
    the existence and storage of the composed objects (see the definition of parts in 11.2.3)."
    and:
    "The order and way in which
    composed objects are created is intentionally not defined."

    page 128:
    composite
    Indicates that the Property is aggregated compositely, i.e., the composite object has responsibility for the
    existence and storage of the composed objects (parts).

  • Reported: UML 2.5 — Tue, 6 Dec 2016 17:09 GMT
  • Updated: Wed, 7 Dec 2016 07:31 GMT

Section: Annex A: Diagrams

  • Key: UMLR-119
  • Legacy Issue Number: 11272
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    There are less diagram kinds defined than UML diagrams. In particular I miss a diagram kind for object, deployment and composite structure diagrams

  • Reported: UML 2.1.1 — Fri, 10 Aug 2007 04:00 GMT
  • Updated: Tue, 6 Dec 2016 19:54 GMT

ClassB::height missing from diagram

  • Key: UMLR-681
  • Status: open  
  • Source: N/A ( Barrie Treloar)
  • Summary:

    id

    Unknown macro: {redefines name}

    shape: Square
    ^+size: Integer[0..1]
    Integer = 7
    /width

    Note "Integer = 7" should be "height: Integer = 7"

  • Reported: UML 2.5 — Tue, 3 May 2016 01:08 GMT
  • Updated: Tue, 6 Dec 2016 19:52 GMT

Missing interface name in Figure 10.10 ISensor is a required Interface of TheftAlarm

  • Key: UMLR-680
  • Status: open  
  • Source: N/A ( Barrie Treloar)
  • Summary:

    The socket does not have a name above it.

  • Reported: UML 2.5 — Tue, 3 May 2016 00:56 GMT
  • Updated: Tue, 6 Dec 2016 19:51 GMT

Section 14.2.4.4 is not a real section

  • Key: UMLR-691
  • Status: open  
  • Source: N/A ( Barrie Treloar)
  • Summary:

    It has no title, and only contains "A composite State or StateMachine with just one Region is shown by showing a nested state diagram within the graph Region."

    "shown by showing" might be a clunky way of expressing the intent as well.

  • Reported: UML 2.5 — Tue, 17 May 2016 04:47 GMT
  • Updated: Tue, 6 Dec 2016 19:48 GMT

Why is Association.memberEnd ordered?

  • Key: UMLR-677
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    Association.memberEnd is specified as ordered but no rationale for this is given.

    Possibly there is a requirement that a refined association's memberEnds be positionally consistent with the refining association's memberEnds. But there is no text or Constraint for this.

    A mismatching order can generally be fixed-up, but in the unusual case of an N-ary association where at least two unrefined memberEnds have the same type, positional equivalence is perhaps necessary.

    If the order is significant, is there a graphical policy for defining the order?

  • Reported: UML 2.5b1 — Wed, 13 Apr 2016 17:01 GMT
  • Updated: Tue, 6 Dec 2016 19:47 GMT

Figure 11.23 (and 11.22) should use one brand of tire but show two instead

  • Key: UMLR-684
  • Status: open  
  • Source: N/A ( Barrie Treloar)
  • Summary:

    Figure 11.23 shows a constructor for the Car Class. This constructor takes a parameter brand of type String. It describes
    the internal structure of the Car that it creates and how the four contained instances of Wheel will be initialized. In this
    case, every instance of Wheel will have the predefined size and use the brand of tire passed as parameter.

    Yet the diagram uses two brands "Michelin" and "Firestone".

    This is the same diagram as Figure 11.22, but there was no information about the constructor to infer whether this was intentional or a bug,

  • Reported: UML 2.5 — Fri, 6 May 2016 05:52 GMT
  • Updated: Tue, 6 Dec 2016 19:47 GMT

Transition guards should be its own section.

  • Key: UMLR-690
  • Status: open  
  • Source: N/A ( Barrie Treloar)
  • Summary:

    Transition guards feels like it should be its own section as the information is not specific to Completion Transitions and completion events.

    Also "Transitions that have a guard which evaluates to false are disabled." feels wrong.
    Which should possibly be that as it is a restrictive clause.
    And evaluates should be singular.
    -> "Transitions that have a guard that evaluate to false are disabled."

  • Reported: UML 2.5 — Tue, 17 May 2016 01:58 GMT
  • Updated: Tue, 6 Dec 2016 19:46 GMT

UML 2.5: StateMachine Vertex needs to be made a kind of

  • Key: UMLR-697
  • Legacy Issue Number: 19888
  • Status: open  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    In clause 14.3 dealing with state machine redefinition, State is declared as a kind of RedefinableElement (see Figure 14.37). This is necessary not only to allow States to be refined, but also because adding a Transition in an extending state machine necessarily has an impact on the "source" and "target" properties of the States that serve as the source and target (respectively) of that Transition. However, the source and target of a Transition is not necessarily a State; it could, in fact, be any kind of Vertex, such as a Pseudostate.

    Consequently, it is necessary to declare Vertex as a kind of RedefinableElement. Since State is a kind of Vertex, the necessary change to the metamodel is to replace State (see figure 14.37) by Vertex

  • Reported: UML 2.5 — Fri, 22 Apr 2016 04:00 GMT
  • Updated: Tue, 6 Dec 2016 19:43 GMT

Clarify that deep history uses the same default transition strategy as shallow history

  • Key: UMLR-702
  • Status: open  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Issue: In section 14.2.3.7, it is stated explicitly that, for the shallowHistory pseudostate:

    "A single outgoing Transition from this Pseudostate may be defined terminating on a substate of the composite
    State. This substate is the default shallow history state of the composite State."

    However, there is no corresponding text for the deepHistory pseudostate. There does not seem to be any reason why the latter should not use the same strategy for a default deep history.

    Proposed solution: Insert the following text in the paragraph describing deepHistory pseudostate semantics:

    "A single outgoing Transition from this Pseudostate may be defined terminating on a substate of the composite
    State. This substate is the default deep history state of the composite State."

  • Reported: UML 2.5 — Mon, 18 Jul 2016 13:47 GMT
  • Updated: Tue, 6 Dec 2016 19:36 GMT

State machine semantics for transition between regions of an orthogonal state

  • Key: UMLR-354
  • Legacy Issue Number: 19593
  • Status: open  
  • Source: steelbreeze.net ( David Mesquita-Morris)
  • Summary:

    I am trying to understand the semantics of a transition between vertices in orthogonal regions of the same parent composite state.
    The specification is clear re. exiting the parent composite state, but not between sibling regions.
    This raises issues regarding entering already active regions and states.

  • Reported: UML 2.4.1 — Sun, 31 Aug 2014 04:00 GMT
  • Updated: Tue, 6 Dec 2016 19:32 GMT

Invalid XMI elements containing both xmi:type and href

  • Key: UMLR-717
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    In all three of the named files there are many elements such as these:
    <type xmi:type="uml:Class" href="http://www.omg.org/spec/UML/20131001/UML.xmi#Property"/>
    <type xmi:type="uml:PrimitiveType" href="http://www.omg.org/spec/UML/20131001/PrimitiveTypes.xmi#Boolean"/>

    These are not valid, as the use of xmi:type and href in the same element is not permitted.

    Also, all of the UML 2.5 xmi files cause errors in the NIST validator due to various problems (UML.xmi causes it to crash).

  • Reported: UML 2.5 — Mon, 28 Nov 2016 13:51 GMT
  • Updated: Tue, 29 Nov 2016 16:50 GMT

Missing visibility definition

  • Key: UMLR-710
  • Status: open  
  • Source: me.com ( Thomas Kilian)
  • Summary:

    It is stated that <visibility> ::= ‘+’ | ‘-‘ | ‘#’ | ‘~’ but nowhere in the specs it is stated which symbol means what.

  • Reported: UML 2.5 — Wed, 12 Oct 2016 13:56 GMT
  • Updated: Sat, 26 Nov 2016 05:04 GMT

What is a "compound state"?

  • Key: UMLR-716
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Twice in the UML 2.5 spec it refers to a compound state. Is this an error for composite state?

    Please define.

    See 14.2.3.8.4 p 313

  • Reported: UML 2.5 — Tue, 22 Nov 2016 23:06 GMT
  • Updated: Tue, 22 Nov 2016 23:06 GMT

All actions should be able to own control pins

  • Key: UMLR-715
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Axel Scheithauer)
  • Summary:

    The specification says:

    Control Pins (with isControl=true) are ignored in the constraints that Actions place on Pins.

    In other words, any action could have control pins. And this makes sense, since when an object token is accepted at a control pin, the object is not considered. It has the same effect as a control token (except that the pin only accepts one token at a time, whereas incoming control flows always accept all offered tokens). The number of incoming control flows is not limited and the same is true for object flows targeting control pins.

    Currently this is only possible for some actions (namely InvocationActions), since the "output" and "input" attributes are derived unions. Their subsets are the special pins that each action can define (like the "target" for a SendSignalAction). InvocationActions can have any number of pins, and some of them can be control pins. These are subsequently not considered when matching the Pins to the Parameters of the invoked Behavior. But an Action like SendSignalAction cannot add another InputPin to be used as control pin.

    This should be possible. For example it could be necessary to send a number of signals, then wait for the reception of the same number of signals. With control tokens it would not be possible, since all control tokens will be accepted at once. Adding a control Pin to the AcceptEventAction would solve this problem elegantly (of course I could use a work around).

    Suggestion
    Add a property "control pins" as subset of "output" and "input".
    Add a constraint that all Pins in "control pins" must have isControl=true.

  • Reported: UML 2.5 — Tue, 22 Nov 2016 17:24 GMT
  • Updated: Tue, 22 Nov 2016 17:24 GMT

Missing Constraint: Associations cannot type StructuralFeatures

  • Key: UMLR-714
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Axel Scheithauer)
  • Summary:

    Since Associations are special Types they could also be the type of a StructuralFeature. I think this doesn't make sense, and at least one tool does not allow to model it. However there seems to be no constraint to this effect.

  • Reported: UML 2.5 — Mon, 14 Nov 2016 12:59 GMT
  • Updated: Tue, 15 Nov 2016 13:33 GMT

Actor association constraint makes UseCase subclass of Class

  • Key: UMLR-348
  • Legacy Issue Number: 19523
  • Status: open  
  • Source: gmail.com ( Florian Schneider)
  • Summary:

    The constraint on Actors
    inv: Association.allInstances()>forAll( a | a.memberEnd>collect(type)->includes(self) implies (
    a.memberEnd->size() = 2 and
    let actorEnd : Property = a.memberEnd->any(type = self) in
    actorEnd.opposite.class.oclIsKindOf(UseCase) or
    ( actorEnd.opposite.class.oclIsKindOf(Class) and not
    actorEnd.opposite.class.oclIsKindOf(Behavior)) )
    )

    uses the sub-expression
    actorEnd.opposite.class.oclIsKindOf(UseCase)
    where the actorEnd is a Property, whose opposite is a Property, whose class is a Class. So oclIsKindOf(UseCase) can never be true, as UseCase is a subclass of BehavioredClassifier, and not of Class.

  • Reported: UML 2.5 — Wed, 16 Jul 2014 04:00 GMT
  • Updated: Mon, 14 Nov 2016 12:47 GMT

On page 290 of UML 2.5 formal/2015-03-01,

  • Key: UMLR-713
  • Legacy Issue Number: 19898
  • Status: open  
  • Source: Object Management Group ( Dr. Jon M. Siegel)
  • Summary:

    On page 290 of UML 2.5 formal/2015-03-01, in the paragraph just below the three bullets, the first sentence refers to "signalbroadcastaction". This should actually be "broadcastsignalaction", which occurs in the referenced Section 16.3 and multiple times elsewhere in the spec, while signalbroadcastaction doesn't occur anywhere except in that paragraph on page 290. SO the occurrence on p 290 should be changed to "broadcastsignalaction".

    BTW Andrew suggests that this is not editorial enough to skip the RTF resolution process. Sorry!

    Jon Siegel, OMG
    20161104

  • Reported: UML 2.5 — Mon, 7 Nov 2016 05:00 GMT
  • Updated: Mon, 7 Nov 2016 15:59 GMT

New Issue on UML 2.5 formal/2015-03-01 re signalbroadcastaction vs. broadcastsignalaction

  • Key: UMLR-712
  • Legacy Issue Number: 19897
  • Status: open  
  • Source: Object Management Group ( Dr. Jon M. Siegel)
  • Summary:

    On page 290 of UML 2.5 formal/2015-03-01, in the paragraph just below the three bullets, the first sentence refers to "signalbroadcastaction". This should actually be "broadcastsignalaction", which occurs in the referenced Section 16.3 and multiple times elsewhere in the spec, while signalbroadcastaction doesn't occur anywhere except in that paragraph on page 290. SO the occurrence on p 290 should be changed to "broadcastsignalaction".

    BTW Andrew suggests that this is not editorial enough to skip the RTF resolution process. Sorry!

  • Reported: UML 2.5 — Fri, 4 Nov 2016 04:00 GMT
  • Updated: Fri, 4 Nov 2016 17:23 GMT

The behavior of an OpaqueExpression should be allowed to have input parameters

  • Key: UMLR-696
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    The constraint OpaqueExpression::only_return_result_parameters requires that, if an OpaqueExpression has a behavior, then this behavior may not have any other parameters than a return parameter. In 8.3.3.3 it states, "Note that the behavior of an OpaqueExpression does not have Parameters other than its return and thus cannot be passed data upon invocation. It must therefore access any input data through elements of its behavioral description."

    This constraint is too restrictive. In particular, when an OpaqueExpression is used as a guard on an ActivityEdge or as the specification of a guard Constraint on a Transition, it is often desirable to pass data into the OpaqueExpression, such as variables within an Activity or data obtained from the Event occurrence triggering a Transition. In the body text of an OpaqueExpression, this is often specified by simply using a variable name or parameter name. However, if such a body is to be formalized using, say, an Activity as the behavior for the OpaqueExpression, there is no currently way to specify access to such data as part of the "behavioral description" of the Activity. (Only attribute data of the context object can be accessed within such an Activity. Even accessing variables in an enclosing Activity is not possible.)

    If the behavior of an OpaqueExpression was allowed to have input parameters, then, for example, local names in a body expression could be mapped to parameters of the behavior, such that, however the values of those names are to be resolved at runtime, those values could be passed to the invoked behavior. Of course, the actual resolution of local names and the semantics of what values are passed to behavior parameters would still be specific to the body language and/or the evaluating tool. However, at least there would be an allowance for the possibility of passing such data into the behavior.

    (This issue came up during work on the Precise Semantics of State Machines. If OpaqueExpression behaviors were allowed to have input parameters, then PSSM will define a standard way, using this mechanism, in which Event occurrence data can be passed to the behavior of an OpaqueExpression used as the specification of a Transition guard Constraint, for tools conforming to the PSSM specification.)

  • Reported: UML 2.5 — Fri, 3 Jun 2016 14:45 GMT
  • Updated: Sat, 29 Oct 2016 00:14 GMT

UML/OCL spec mismatch-Constraint.context vs Constraint.constrainedElement

  • Key: UMLR-92
  • Legacy Issue Number: 9751
  • Status: open  
  • Source: Dassault Systemes ( Mr. Tomas Juknevicius)
  • Summary:

    There is an clash/mismatch between the UML2.0 and OCL2.0 specs on constraint semantics.
    The UML superstructure doc 05-07-04, chapter 7.3.10 states,
    that Constraint has context and constrainedElement associations(properties).

    The Semantic section of the paragraph states, that the context property of
    the constraint is used in OCL constraint evaluation as a "self".

    However the OCL2.0 specification doc 05-06-06, chapter 12 specifies different
    rules, how OCL expressions are evaluated in the UML models. In most cases it is mandated that
    the self (a.k.a. contextual classifier) should be derived from the constrainedElement property.

    In particular, for most common case - invariant constraints, 12.6, 12.6.1 paragraphs state, that
    the contextual classifier should be the classifier, specified by the constrainedElement property:

    contextualClassifier = self.constraint.constrainedElement->any(true).oclAsType(Classifier)

    The other conditions are irrelevant for the issue at hand:
    constraint should have <<invariant>> stereotype (self.constraint.stereotype.name = ?invariant?)
    constraint.constrainedElement should have a single element (self.constraint.constrainedElement->size() = 1)
    constraint.constrainedElement should be classifier (self.constraint.constrainedElement.any(true).oclIsKindOf(Classifier))
    expression result should be boolean (self.bodyExpression.type.name = ?Boolean?)

    So we have a conflicting specs here. Which one of these is correct?

    I am inclined to believe, that the OCL spec, being more concrete, is correct -
    UML spec mentions the usage of "self" only casually, in one sentence.
    However if this true, what is the meaning of the context property of the constraint in the UML?
    It seams that this property is then unnecessary and not used (at least for OCL constraints) anywhere...

    Note that the upcoming UML2.1 superstructure spec, 06-04-02, introduces small changes to the context
    property of the constraint. Context is now changed to subset namespace.
    However the issue, described above, is not mitigated and is still present in 2.1.

  • Reported: UML 2.5 — Thu, 18 May 2006 04:00 GMT
  • Updated: Sat, 29 Oct 2016 00:14 GMT

What is "a separate InteractionConstraint"?

  • Key: UMLR-706
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Axel Scheithauer)
  • Summary:

    The specification says:

    If the loop contains a separate InteractionConstraint with a specification, the loop will only continue if that specification evaluates to true during execution regardless of the minimum number of iterations specified in the loop.

    It is not clear what a separate InteractionConstraint is. An InteractionOperand can only have one InteractionConstraint as guard. A CombinedFragment with loop-operator can only have one operand and cannot own any Constraints, since it is not a Namespace. An Operand is a Namespace and could thus contain ownedRules. However this possibility is not mentioned anywhere and I doubt that the authors of this paragraph are referring to this. It seems this paragraph has been added as resolution to UML22-100, but it fails to define abstract and concrete syntax for it.

  • Reported: UML 2.5 — Fri, 19 Aug 2016 10:59 GMT
  • Updated: Fri, 19 Aug 2016 17:50 GMT

XOR Constraint modeling

  • Key: UMLR-703
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    Fgure 7.16 of the UML 2.5 specification shows an

    {xor}

    constraint. How is this encoded in the UML model?

    In UML 1.x it could perhaps have been a Package rule Constraint with an "xor" keyword-stereotype and two Association constrained elements.

    But UML 2.x eliminated keyword-stereotypes so what is the solution?

  • Reported: UML 2.5 — Thu, 4 Aug 2016 16:27 GMT
  • Updated: Wed, 17 Aug 2016 09:51 GMT

Inconsistent constraints about several kinds of UML Diagrams

  • Key: UMLR-701
  • Status: open  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    In UML 2.5, Annex B.7.13.6 (UMLDiagram, Constraints) states:

    • heading_modelElement
      The modelElement of the heading is the same as the modelElement of the diagram it heads.
    inv: (heading->isEmpty()) or (heading.modelElement = modelElement)
    

    However, several specializations of UMLDiagram are constrained to have no model element:

    • UMLClassDiagram (B.7.6.3)
    • UMLComponentDiagram (B.7.10.3)
    • UMLDeploymentDiagram (B.7.12.3)
    • UMLObjectDiagram (B.7.26.3)
    • UMLPackageDiagram (B.7.27.3)
    • UMLProfileDiagram (B.7.28.3)
    • UMLUseCaseDiagram (B.7.37.3)

    The constraint from B.7.3.16 means that all the above diagrams cannot have any heading, which is inconsistent with the descriptions of these diagrams in Annex A and elsewhere in the spec.

  • Reported: UML 2.5 — Mon, 18 Jul 2016 01:57 GMT
  • Updated: Mon, 18 Jul 2016 15:22 GMT

Notation of a reception: Keyword <> is superfluous

  • Key: UMLR-699
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    According to figure 10.6. receptions are depicted in a special compartment with headline receptions. It makes no sense that the keyword <<signal>> precedes every reception in the list. It is superfluous and clutters the diagram.

    There is a similar issue for the SysML specification: http://issues.omg.org/browse/SYSMLR-227

  • Reported: UML 2.5 — Mon, 4 Jul 2016 10:59 GMT
  • Disposition: Deferred — $issue.fixedSpecification.name
  • Disposition Summary:
  • Updated: Tue, 5 Jul 2016 12:08 GMT

OpaqueExpression should own Behavior

  • Key: UMLR-698
  • Status: open  
  • Source: Fraunhofer FOKUS ( Mr. Marc-Florian Wendland)
  • Summary:

    It would be much simpler if the Behavior referenced by an OpaqueExpression as 'behavior' would be contained by the OpaqueExpression. Currently, it is not.

  • Reported: UML 2.5 — Tue, 21 Jun 2016 20:24 GMT
  • Updated: Tue, 21 Jun 2016 20:24 GMT

Semantics of Lifeline.selector not clear

  • Key: UMLR-627
  • Legacy Issue Number: 19835
  • Status: open  
  • Source: Fraunhofer FOKUS ( Mr. Marc-Florian Wendland)
  • Summary:

    In UML 2.4.1 the semantics of Lifeline.selector is defined as "If the referenced ConnectableElement is multivalued (i.e, has a multiplicity > 1), then the Lifeline may have an expression (the ‘selector’) that specifies which particular part is represented by this Lifeline."

    This part (even though not very precise) is completely removed from UML 2.5, section 17.3.3. Instead a constraint has been introduced that restricts the selector ValueSpecification to being LiteralString or LiteralInteger, without further explaining how the corresponding parts out of a multivalued part are selected.

    Since parts (i.e., metaclass Property) may represent unordered collections, the selector should rather be restricted to evaluate to a Boolean expression. The Lifeline would represent select all instances contained in the multivalued part for which the Boolean expression evaluates to true.

    No technical changes to the metamodel required, but editorial changes and update of Constraints.

  • Reported: UML 2.5 — Fri, 18 Sep 2015 04:00 GMT
  • Updated: Tue, 21 Jun 2016 19:28 GMT

Notation is depreciated for inherited interface

  • Key: UMLR-640
  • Legacy Issue Number: 19853
  • Status: open  
  • Source: Anonymous
  • Summary:

    In p. 170, the spec. says "Interfaces inherited from a generalization of the BehavioredClassifier may be notated on a diagram through a lollipop. These Interfaces are indicated on the diagram by preceding the name of the Interface by a caret symbol. Earlier versions of UML permitted a forward slash preceding the name to indicate inherited Interfaces; this notation is permitted but discouraged." But in Figure 11.46 in p. 212, the inherited interface OrderableItem on component proudct still uses the depreciated one.

  • Reported: UML 2.5 — Thu, 5 Nov 2015 05:00 GMT
  • Updated: Tue, 21 Jun 2016 19:24 GMT

Comment is misleading

  • Key: UMLR-692
  • Status: open  
  • Source: N/A ( Barrie Treloar)
  • Summary:

    "(the right-most of the States within the composite State)."

    Nothing has indicated that the final state must be the right most state.
    Additionally your example documents do not follow this.

    I think this text should be deleted.

  • Reported: UML 2.5 — Tue, 17 May 2016 05:07 GMT
  • Updated: Tue, 17 May 2016 15:02 GMT

Mixed plural/singular

  • Key: UMLR-689
  • Status: open  
  • Source: N/A ( Barrie Treloar)
  • Summary:

    Transitions whose source Vertex is a composite State[del:s] are called high-level or group Transitions.

    Whoever it might be better to rewrite the sentence:

    High-level or group Transitions have a composite State source Vertex.

  • Reported: UML 2.5 — Tue, 17 May 2016 01:46 GMT
  • Updated: Tue, 17 May 2016 15:01 GMT

Plural vs Singulr?

  • Key: UMLR-688
  • Status: open  
  • Source: N/A ( Barrie Treloar)
  • Summary:

    "There is a number of ways" sound like it should be "There are a number of ways" since "number of ways" is a plural rather than singular.

  • Reported: UML 2.5 — Thu, 12 May 2016 05:05 GMT
  • Updated: Thu, 12 May 2016 14:37 GMT

Unclear sentence

  • Key: UMLR-687
  • Status: open  
  • Source: N/A ( Barrie Treloar)
  • Summary:

    Stereotypes imported from another Profile using ElementImport or PackageImport are added to the namespace members of the importing profile.Profile Contents.

    I think "the sentence "Profile Contents." can be deleted.

  • Reported: UML 2.5 — Wed, 11 May 2016 23:54 GMT
  • Updated: Thu, 12 May 2016 14:36 GMT

Missing words in sentence

  • Key: UMLR-686
  • Status: open  
  • Source: N/A ( Barrie Treloar)
  • Summary:

    Relationships between elements in different Models generally [^has] no direct impact on the contents of the Models because each Model is meant to be complete.

  • Reported: UML 2.5 — Wed, 11 May 2016 07:33 GMT
  • Updated: Wed, 11 May 2016 16:02 GMT

reply messages in interactions

  • Key: UMLR-68
  • Legacy Issue Number: 8899
  • Status: open  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    Similar situation with reply messages in interactions.

    <messageident> ::= ([<attribute> ‘=’] <signal-or-operation-name> [‘(‘ [<argument> [‘,’<argument>]* ‘)’] [‘:’ <return-value>]) | ‘*’

    Message can display return values and variable assignments, but there is no way to store this information in the model, because Message has no attributes for these properties.

  • Reported: UML 2.5 — Mon, 20 Jun 2005 04:00 GMT
  • Updated: Sun, 8 May 2016 06:54 GMT

Subclasses of InstanceSpecification

  • Key: UMLR-101
  • Legacy Issue Number: 9962
  • Status: open  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    Now, when link is not Link and is not Relationship, tool
    >> developers must use
    >> a lot of hacks for handling this "special kind of instance"
    >> as path, to
    >> create special algorithms for "relatedElements" calculation,
    >> to prevent
    >> type changes to regular classifier and for many other situations.
    >> Why Link metaclass was removed? Why all subclasses of
    >> Instance were removed?

    >I don't know. I personally would like to see an explicit Link class in
    >the Instances metamodel - see the MOF Core specification (abstract
    >semantics chapter - which is purely descriptive and does not add these
    >Instance extensions to MOF or UML) for what I have in mind. I would
    >support adding this all into UML since it would be a non-disruptive
    >(forward compatible) extension.

    >> Node instance and Component instance "different handling" and
    >> notation
    >> creates a lot problems also, because it is not possible to
    >> recognize them in
    >> the model (classifier could be unspecified).

  • Reported: UML 2.5 — Tue, 25 Jul 2006 04:00 GMT
  • Updated: Sun, 8 May 2016 05:25 GMT

ValueSpecification that refers to some Element shall be defined

  • Key: UMLR-112
  • Legacy Issue Number: 10821
  • Status: open  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    ValueSpecification that refers to some Element shall be defined. It could be named ElementValue. We need that for tagged values that references to model elements. It could be used for Argument value also

  • Reported: UML 2.5 — Fri, 23 Feb 2007 05:00 GMT
  • Updated: Sun, 8 May 2016 05:20 GMT

Ability to define "context specific" default values for Part

  • Key: UMLR-113
  • Legacy Issue Number: 10822
  • Status: open  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    Ability to define "context specific" default values for Part. It is widely used for system modeling (SysML), but it is not possible to map that to UML

  • Reported: UML 2.5 — Fri, 23 Feb 2007 05:00 GMT
  • Updated: Sun, 8 May 2016 05:19 GMT

Order of example information should be diagram first, then explanation.

  • Key: UMLR-683
  • Status: open  
  • Source: N/A ( Barrie Treloar)
  • Summary:

    Figure 11.29 has the correct ordering:

    • summary of figure
    • the figure
    • explanation of figure

    Figure 11.30 has an incorrect ordering:

    • summary of figure
    • explanation of figure
    • the figure

    Because both figures have elements named the same, but are completely different diagram, the ordering as included in the document is confusing because you can still see figure 11.29 and not yet figure 11.30.

  • Reported: UML 2.5 — Tue, 3 May 2016 03:55 GMT
  • Updated: Wed, 4 May 2016 12:40 GMT

Link to "see" sections missing

  • Key: UMLR-682
  • Status: open  
  • Source: N/A ( Barrie Treloar)
  • Summary:

    "Let the Property that constitutes the other end be called oep, so that the Classifiers at the chosen N-1 ends are the context for oep (see 9.5.3)."
    and
    "The value represented by oep (see 9.5.3)..."

    are missing clickable cross-references.

    Elsewhere (for example, "Subsetting of Association ends has the meaning specified for Property (see 9.5.3).") do have a clickable link.

  • Reported: UML 2.5 — Tue, 3 May 2016 03:30 GMT
  • Updated: Wed, 4 May 2016 12:40 GMT

AssociationEnd/Attribute redefintion consistency

  • Key: UMLR-679
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    A Property may be an AssociationEnd (association <> null) or an Attribute (association = null).

    Is it permissible for an AssociationEnd to be redefined as an Attribute and vice-versa?

    "6.4.2 The constraint

    {redefines endA}

    means that the association end to which this constraint is applied redefines the association end endA."

    suggests such a redefinition is wrong.

    "9.9.17.7 Property::isConsistentWith"

    does not exclude such a redefinition..

    Suggest isConsistentWith should require consistency wrt Property::association <> null.

  • Reported: UML 2.5 — Wed, 27 Apr 2016 14:50 GMT
  • Updated: Wed, 27 Apr 2016 15:41 GMT

Why is a qualified association qualifier composed by a Property?

  • Key: UMLR-678
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    Consider the example in Fig 11.37 that is supported by the OCL navigation aBank.Person[accountNo].

    The nested Property is novel but avoids any bias as to whether the keys are actually part of e.g. a HashMap in Bank, or a linear search in Person. Seems good, but...

    How does aPerson discover their accountNo? Oops need to do a total content search of the Bank. Or provide duplicate Person::accountNo state with all the hazards that duplicate state entails.

    How can two qualified associations share the same qualifier? Can't it's Composed. Need yet more state duplication.

    If instead, Property::qualifier was not Composed, many qualified associations can refer to a Property that can be a regular unnested Property that can be navigated as aPerson.accountNo. Although the now regular Property appears hosted by the target, there is no prohibition on an implementation using a HashMap and locating it in the source, iff all required forms of access are supported.

  • Reported: UML 2.5 — Wed, 13 Apr 2016 21:37 GMT
  • Updated: Thu, 14 Apr 2016 19:31 GMT

UML should support proxies for linking models

  • Key: UMLR-355
  • Legacy Issue Number: 19599
  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    For support of federated models, UML should provide an element used as a proxy for an element in another (meta)model.

    This should have a property to represent the URL of the external element – which will get converted to a “href” attribute when the model is serialized.

    The ODM Profile has an equivalent capability that as proved very useful for federating with external ontologies.

  • Reported: UML 2.5 — Mon, 15 Sep 2014 04:00 GMT
  • Updated: Mon, 28 Mar 2016 22:51 GMT

No UML approach to create an infix operator

  • Key: UMLR-676
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    In UML 1.x there was depicted notation that could be used to create an infix operator for a numerical type. In current UML 2.5, there are no examples. The old notation was for some type Tp was (if I remember correctly)
    '+' (field2:Tp):Tp

    without this ability it is not possible to create an ADT such as complexNumberType.

  • Reported: UML 2.5 — Wed, 16 Mar 2016 22:30 GMT
  • Updated: Wed, 16 Mar 2016 22:30 GMT

Parameter types required for operation parameters

  • Key: UMLR-674
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Operation parameters point to 9.4.4 notation. The BNF there requires a parameter to include the ':' and <type-expression>.

    In practice, the tools do not require the display of the parameter type.

    Now, I understand that the <type-expression> could be blank, because we don't say what a type-expression requires. I think this interpretation is not reasonable, the features of BNF should be used to explicility allow this field to be omitted. In addition, the ':' should not be required if the type is omitted.

    Replace
    <parameter name> ':' <type-expression>
    with
    <parameter name> [':' <type-expression>]

  • Reported: UML 2.5 — Tue, 15 Mar 2016 15:34 GMT
  • Updated: Tue, 15 Mar 2016 15:34 GMT

TypeElement / TypedElement typo

  • Key: UMLR-329
  • Legacy Issue Number: 19350
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    The Property::isCompatibleWith constraint has a TypeElement/TypedElement typo.

    A similar typo occurs in 7.5.3.

  • Reported: UML 2.5 — Tue, 22 Apr 2014 04:00 GMT
  • Updated: Sun, 13 Mar 2016 15:42 GMT

Spec refers to TypeElement twice. Should be TypedElement

  • Key: UMLR-673
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    In two places an undefined TypeElement is referred to. From the context it should be TypedElement.
    As the 2nd occurrence is in an OCL constraint, tools using the OCL cannot be working unless they corrected it.
    7.5.3 p 26
    9.9 Operations p 154

  • Reported: UML 2.5 — Sun, 13 Mar 2016 06:32 GMT
  • Updated: Sun, 13 Mar 2016 13:38 GMT

Constraint TemplateSignature::own_elements too constraining

  • Key: UMLR-672
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Axel Scheithauer)
  • Summary:

    The Constraint TemplateSignature::own_elements says:

    Parameters must own the ParameterableElements they parameter or those ParameterableElements must be owned by the TemplateableElement being templated.

    This is not always possible.

    For example in Figure 9.5 a LiteralInteger (sic) is shown as the ParameterableElement. This LiteralInteger is used as the upperValue of the Multiplicity of Property "contents". As such it is owned by the Property and only indirectly by the template "FArray".

    I'm not sure how useful it would be to change the constraint. In Figure 9.5 parameter "k" could also own an InstanceSpecification as ParameterableElement. This would then in turn be used by an InstanceValue as the upperValue of Property "contents". This way it would even be possible to reuse this value in various places across the template (e.g. for other Multiplicities or ValuePins in Activities). I think this would be the preferred way to use Integers as TemplateParameters.

    So unless there are good examples, where the ParameterableElement cannot be owned by the TemplateParameter, the constraint could stay like it is and only the Figures 9.5 and 9.7 must be changed.
    (we could assume that the upperValues are OpaqueExpressions. But if it is not necessary, we should avoid using opaque elements. And even OpaqueExpressions should refer to InstanceSpecifications instead of LiteralIntegers.)

  • Reported: UML 2.5 — Fri, 11 Mar 2016 22:06 GMT
  • Updated: Fri, 11 Mar 2016 22:10 GMT

Need example of derived qualifier.

  • Key: UMLR-671
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Based on the results of UML25-322, it appears that the a qualifier can be a derived attribute. This is very powerful, as it allow for situational mappings to across the association. Please make this explicitly possible, best with an example.

    I still believe a query function call would be the clearest. For example, I want to cross an association based on the name of a person

    Hotel [map(guestName):enumeratedKey]--->* Reservation

    This is very useful, needed by database modelers, and a very small, and limited change to the UML Spec.

  • Reported: UML 2.5 — Wed, 9 Mar 2016 22:40 GMT
  • Updated: Wed, 9 Mar 2016 22:40 GMT

The Kind field from frame names should be bold

  • Key: UMLR-670
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    In Annex A, the possible values for the kind field is given on page 682. The abbreviated forms are shown in bold, but the full forms (e.g., activity, component..) is given non-bold (roman) type face.

    In the Annex B, the field is required to be in bold face (p 686).

    Please correct the list on page 682.

    Also consider supplying the full BNF for the heading field, something like:

    <kind> ::= ‘activity’ | ‘act’ | ‘class’ | ‘component’ | ‘cmp’ | ‘deployment’ | ‘dep’ | ‘interaction’ | ‘sd’ | ‘package’ | ‘pkg’ | ‘state machine’ | ‘stm’ | ‘use case’ | ‘uc

    I also notice that no abbreviation for "class" exists.

  • Reported: UML 2.5 — Sun, 6 Mar 2016 06:46 GMT
  • Updated: Sun, 6 Mar 2016 16:41 GMT

Need BNF for Protocol State Machines Transitions

  • Key: UMLR-659
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    There is no BNF for the transition syntax of Protocol State Machines. The standard BNF for behavior State Machines is not sufficient as it allows for actions and doesn't allow for post-conditions.

    It is not clear currently, for example, whether a post-condition is required, and if it's not there, does the transition string require a trailing / (as shown in the examples)?
    My guess is that the missing BNF should be something like:

    ['['<pre-condition>']'][<trigger>[‘,’ <trigger>]*]  ['/' ['['post-condition']']] 
    

    To not invalidate any existing diagrams, the trailing "/" is allowed even without a following post condition. It also allows multiple triggers, but only one pre and only one post condition as per the abstract syntax.

    Since I based this on the pre-existing transistion trigger, it will allow all triggers, including change events, time events, and ALL.
    Whatever the syntax is decided on should be included in the spec.

  • Reported: UML 2.5 — Mon, 15 Feb 2016 20:25 GMT
  • Updated: Sun, 6 Mar 2016 06:54 GMT

DI refers to putting the Diagram Kind in bold...

  • Key: UMLR-669
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    The DI material for UML 2.5 on p 686 Appendix B
    "The diagram kind in the heading shall be rendered in boldface"

    Unfortunately, there is no field anywhere defined to be Diagram kind or Diagramkind, anywhere in UML 2.5 or the DI annex.

    Apparently, what was meant was the kind field in annex A, p 681.

    [<kind>]<name>[<parameters>]
    The heading of a diagram represents the kind, name, and parameters of the namespace enclosing or the model element owning elements that are represented by symbols in the contents area.

    The DI material also refers to diagram kind on p 696 in the context of activity diagrams vs activity frames.

    I suggest that frameKind be formally defined and referred to properly.

  • Reported: UML 2.5 — Fri, 4 Mar 2016 19:03 GMT
  • Updated: Fri, 4 Mar 2016 19:06 GMT

Package names in wrong location.

  • Key: UMLR-667
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    in 12.2.4 Notation (package) on p 259, it says

    • If the members of the Package are not shown within the large rectangle, then the name of the Package should be placed within the large rectangle.
    • If the members of the Package are shown within the large rectangle, then the name of the Package should be placed within the tab.

    These rules are also repeated in Annex B. on B.3.2 page 728

    However, in several figures these rules are not obeyed.
    E.g., Figure 12.14 p 269
    Figure A.3 i p 717

    Please make consistent or relax the location rules

  • Reported: UML 2.5 — Tue, 1 Mar 2016 20:36 GMT
  • Updated: Tue, 1 Mar 2016 20:36 GMT

Disjointness should be independent of generalization

  • Key: UMLR-35
  • Legacy Issue Number: 8014
  • Status: open  
  • Source: NIST ( Mr. Evan K. Wallace)
  • Summary:

    Disjointness should be independent of generalization. Two classes can be disjoint, but have no common supertype. This facilitates the mapping to OWL

  • Reported: UML 2.0 — Thu, 30 Dec 2004 05:00 GMT
  • Updated: Sun, 28 Feb 2016 03:57 GMT

section 7.3.17 /EnumerationLiteral should not be an InstanceSpecification

  • Key: UMLR-41
  • Legacy Issue Number: 8278
  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    In Super (but not Infra) EnumerationLiteral inherits from InstanceSpecification.
    This allows a single Enumeration value e.g. 'private' or 'red' to have many slots (InstanceSpecification.slot).
    Moreover it allows the value to have many classifiers (InstanceSpecification.classifier) independently of the Enumeration that owns the EnumerationLiteral - it does not make any sense to have this redundant property.

    All that is needed surely is a value: so if anything EnumerationLiteral should inherit from ValueSpecification. However this still inherits too much: for example an EnumerationLiteral should be owned only by its Enumeration and so should not inherit from PackageableElement as does ValueSpecification. Furthermore inheriting from TypedElement seems to introduce capability that is not catered for in the notation etc: if anything the underlying type for an Enumeration should be specified at the Enumeration not the EnumerationLiteral level (which would allow the different alternatives for an Enumeration to have different types).

    The only useful capability on EnumerationLiteral is that it should have a name (which is all that Infrastructure allows), and optionally a value. The latter should be specified in the same way as the default value of a Property.

    Proposed resolution:
    EnumerationLiteral should inherit only from NamedElement.
    It should have an optional property:
    value:ValueSpecification [0..1]

    The Notation section should describe how to indicate the value, which should be the same as for the default value of a Property

  • Reported: UML 2.5 — Mon, 14 Feb 2005 05:00 GMT
  • Updated: Sun, 28 Feb 2016 03:56 GMT

Impossiblity to specify links for connected roles.

  • Key: UMLR-665
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Axel Scheithauer)
  • Summary:

    The specification says

    [...]Associations, [...] specify links between any suitably-typed instance of the associated Classifiers, Connectors specify links between instances playing the connected roles [...]

    A link specified by an Association can be modeled by an InstanceSpecification. A link only specified by a Connector cannot be modeled, since Connector is not a Classifier.

    That means that no object-diagram can show the links between connected roles, when the Connector is not typed by an Association. It doesn't help, that the InstanceSpecification could be left without classifier. In this case, it would not be possible to define the linked instances, since an InstanceSpecification without classifier can't have Slots.

  • Reported: UML 2.5 — Fri, 26 Feb 2016 18:00 GMT
  • Updated: Fri, 26 Feb 2016 18:00 GMT

Delegation Connector should not be typed

  • Key: UMLR-664
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Axel Scheithauer)
  • Summary:

    The Specification says

    A delegation Connector [...] links a Port to a role within the owning EncapsulatedClassifier. It represents the forwarding of requests.

    What would be the meaning of an Association used as a type for this Connector? I fail to see one. Should there be a Constraint, that doesn't allow a type for a delegation Connector?

    Suggestion
    Add following Constraint to the Connector definition
    inv: self.kind = ConnectorKind::delegation implies type = null
    (OCL needs to be verified, I'm not sure that it is valid)

  • Reported: UML 2.5 — Fri, 26 Feb 2016 17:24 GMT
  • Updated: Fri, 26 Feb 2016 17:24 GMT

Decide whether the document divisions are "sub clauses" or "subclauses"

  • Key: UMLR-663
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    The spec uses both.
    The spelling with the space predominates.

    ISO probably has a preference. Their document How to write standards http://www.iso.org/iso/how-to-write-standards.pdf use "subclauses" as one word.

    However some of their actual documents use either "subclauses" or "sub-clauses". I didn't see anyone using "sub clauses" and their documents appear to be internally consistent.

  • Reported: UML 2.5 — Wed, 24 Feb 2016 03:15 GMT
  • Updated: Wed, 24 Feb 2016 07:32 GMT

Unexpected trigger reception has contradictory results in Protocol State Machines

  • Key: UMLR-660
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    On page 340, we have a definition of a unexpected trigger reception.
    14.4.3.2.1 Unexpected trigger reception
    The interpretation of the reception of an Event occurrence that does not match a valid trigger for the current State, state invariant, or pre-condition is not defined (e.g., it can be ignored, rejected, or deferred; an exception can be raised; or the application can stop on an error). It corresponds semantically to a pre-condition violation, for which no predefined Behavior is defined in UML

    However, in 14.4.3.2.3 under Unreferred Operations. We have:
    Unreferred Operations
    If a BehavioralFeature is not referred by any ProtocolTransition, then the operation can be called for any State of the ProtocolStateMachine, and will not change the current State or pre- and post-conditions.


    The problem I have is that an Unreferred operation fits the criteria for an Unexpected Trigger reception – as it does not match a valid trigger for the current state.

    It may be that once a behavioral feature is referred to on any of the PSM states, then it loses it's potentiality to be an unreferred to operation. If that is so, it should be made much clearer.

    But it is still not very useful. Imagine a protocol state machine with many states. Now imagine an operation that can be called while the psm is any of these states (with no precondition, post-condition, or state change). This would allow the PSM not to mention the behavior at all. Now imagine a change that would prohibit the operation from only one state. Perhaps it's not allowed while initializing. To model this all the states would have to explicitly mention this operation, which is a unwieldy solution.

    It is also unclear about the scope. If the classifier has a) more than one PSM or b) different concurrent regions within one PSM. Is an unreferred to behavioral feature evaluated by looking at the concurrent region, or by looking at the sum of all the PSMs for the classifier

  • Reported: UML 2.5 — Mon, 15 Feb 2016 22:44 GMT
  • Updated: Tue, 16 Feb 2016 20:46 GMT

What does calling an "operation for a state" mean in PSM.

  • Key: UMLR-661
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    in 14.4.3.2.4, the text says:
    Unreferred Operations
    If a BehavioralFeature is not referred by any ProtocolTransition, then the operation can be called for any State of the ProtocolStateMachine, and will not change the current State or pre- and post-conditions.

    The phrase "the operation can be called for any State of the PSM" does not seem to conform to normal UML syntax.

    Please change to something like. "...the operation can be called on the Classifier while in any State of the ProtocolStateMachine"

  • Reported: UML 2.5 — Mon, 15 Feb 2016 23:48 GMT
  • Updated: Mon, 15 Feb 2016 23:48 GMT

No notation for associations defined for abstract classes

  • Key: UMLR-658
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Cory Casanave)
  • Summary:

    Use of abstraction is an essential part of design. One way UML supports abstraction is with abstract classes and their subclasses. For semantic clarity and precision, associations are defined on these abstract classes.
    However, when presented to stakeholders the view frequently needs to be "flattened" to more concrete classes Such concrete classes that subclass more abstract classes may show inherited properties and operations without showing the abstractions. The same is not true of associations - there is no way to show associations between concrete classes that are derived from abstract classes. This results in the abstractions becoming confusing and/or incomplete. Not all people can follow the abstractions.
    The suggested resolution is, on a class diagram, to allow associations to be shown between classes where that association is defined between supertypes of the more concrete classes. This "inherited association" should have some visible marker, such as a greyed out line.
    The result would be a "flattened view" of an abstract hierarchy more accessible to stakeholders only interested in the more concrete representation.

  • Reported: UML 2.5 — Thu, 4 Feb 2016 21:06 GMT
  • Updated: Tue, 9 Feb 2016 14:46 GMT

UML:Notational option to display inherited features in a subclass

  • Key: UMLR-202
  • Legacy Issue Number: 14942
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    The ability to see the inherited features is often necessary, however, such items should be displayed in a graphically consistent manner – and available on all tools.

  • Reported: UML 2.5 — Mon, 11 Jan 2010 05:00 GMT
  • Updated: Mon, 8 Feb 2016 23:06 GMT

Deploying a «deployment spec» has no explicit interpretation

  • Key: UMLR-657
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    In figure 19.6 "DeploymentSpecifications related to the DeployedArtifacts that they parameterize."
    there is a «deployment spec» with a dependency replacement to an «artifact», but there is a «deployment spec» that is contained with no relationship to anything. The possible interpretation for the later containment is that it is A) a physical containment, B) a deployment (as with the other contained artifacts), or C) a "configuration" of the deployment of the containing artifact, ShoppingApp.ear.

    Problem 1) There is not sufficient guidance to choose about A,B,C or something else
    Problem 2) The parameterization referred to in the diagram title is not justifiable. If interpretation C) is intended, which is my guess, the title should be have parameterize-->configure, so that a new term is not introduced. Even if C) is not intended, the title should be changed.

  • Reported: UML 2.5 — Mon, 8 Feb 2016 22:19 GMT
  • Updated: Mon, 8 Feb 2016 22:19 GMT

Shoppin->Shopping

  • Key: UMLR-656
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Spelling error on Figure 19.6 page 686.

    ShoppinCart.jar should be ShoppingCart.jar

    Identical problem occurs on Figure 19.2 page 685
    Figure 19.3 page 685

  • Reported: UML 2.5 — Mon, 8 Feb 2016 17:57 GMT
  • Updated: Mon, 8 Feb 2016 22:02 GMT

UML 2.5 refers to EBNF, but the spec uses a variant BNF, not EBNF

  • Key: UMLR-655
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    In 8.2.4 Notation, the 6th bullet (page 70), we have:

    This notation is specified by the following EBNF rules:

    However, in 6.4 How to Read this Specification, last paragraph of page 16, we have

    For textual notations a variant of the Backus-Naur Form (BNF) is often used to specify the legal formats. The conventions of this BNF are:

    Everywhere else in the spec the notation is called BNF.

    Please fix this by deleting the "E" in EBNF on p 70.

  • Reported: UML 2.5 — Thu, 4 Feb 2016 06:37 GMT
  • Updated: Thu, 4 Feb 2016 06:37 GMT

Classifiers can contain Packages, but they can't have appropriate visibility

  • Key: UMLR-384
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    It appears that Classes, as Namespaces, can contain Packages.

    The consequences of this are unclear and a bit confusing.

    For example, a package within a class can contain attributes for organization purposes.

    It appears that the package can have visibility that is marked private or public, but not protected nor package level visibility.

    In this case, when there is a package in the class, it appears that you can't make the package protected (and visible to a specialization of the class) or package level visibility (visible to member of any immediate outer package).

  • Reported: UML 2.5 — Tue, 4 Nov 2014 03:00 GMT
  • Updated: Sat, 30 Jan 2016 12:07 GMT

Pin rectangles in examples should not overlap the action border

  • Key: UMLR-654
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Axel Scheithauer)
  • Summary:

    The specification says:

    Pin rectangles may be notated as small rectangles that are attached to the symbol for the Action that owns them.

    There is one other option to show pins:

    The situation in which the OutputPin of one Action is connected to the InputPin of the same name in another Action via an ObjectFlow may be shown by the optional notations of Figure 16.6.

    This Figure shows a rectangle in the middle between two actions.

    In many diagrams the Pins are shown overlapping the border of their owning Action. According to the specification this is wrong. I suggest to correct following Figures:

    • 15.63
    • 15.64 (here additionally the frame should be dashed and the keyword «structured» is missing)
    • 16.50
    • 16.52
    • 16.53
  • Reported: UML 2.5 — Thu, 28 Jan 2016 18:43 GMT
  • Updated: Thu, 28 Jan 2016 18:43 GMT

Activity Generalization is underspecified

  • Key: UMLR-653
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Axel Scheithauer)
  • Summary:

    Inheritance is specified as

    When a Classifier is generalized, certain members of its generalizations are inherited

    There is a derived attribute /inheritedMember, whose derivation is given in OCL, making it perfectly clear, what is inherited.
    In Activities the inherited elements are defined only in the semantics paragraph:

    A specialized Activity inherits the nodes and edges of its general Activities.

    Since they are not members of the Activity, /inheritedMember will not contain them.

    Suggestion
    Add two derived attributes /inheritedNode and /inheritedEdge and specify the derivation.

  • Reported: UML 2.5 — Wed, 27 Jan 2016 18:56 GMT
  • Updated: Wed, 27 Jan 2016 18:56 GMT

Rename Specialization/Generalization between abstract classes

  • Key: UMLR-315
  • Legacy Issue Number: 19322
  • Status: open  
  • Source: NobleProg Ltd ( Bernard Szlachta)
  • Summary:

    Inheritance between an abstract and a solid class should not be named Inheritance (or specialization or generalization).
    Reason: If abstract classes do not have filled in methods, the concrete class just implements them, not extend. Therefore inheritance between concrete class and an abstract class is really an implementation. But implementation is used for interfaces. Therefore we need different name to describe the relationship between abstract class and concrete class.

  • Reported: UML 2.5 — Mon, 31 Mar 2014 04:00 GMT
  • Updated: Wed, 27 Jan 2016 17:54 GMT

In Sequence diagrams, the duration constraint shown as a vertical two-headed is ambiguous

  • Key: UMLR-652
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    If the duration constraint goes from the midst of one message to the midst of another (e.g., the return message), it is unclear whether it is from Start Msg1 to Start Msg2, End Msg1 to End MSg2, Start1 to End Msg2, or End1 to Start Msg2.

    How should this be disambiguated

  • Reported: UML 2.5 — Thu, 21 Jan 2016 17:09 GMT
  • Updated: Thu, 21 Jan 2016 17:09 GMT

In the time-related syntax for Sequence diagrams, there are used two terms (now, duration). Are there more? Are these defined?

  • Key: UMLR-651
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    See Summary

  • Reported: UML 2.5 — Thu, 21 Jan 2016 16:31 GMT
  • Updated: Thu, 21 Jan 2016 16:31 GMT

It doesn't seem possible to use a time-based trigger in the alternate format transition-focused state machine.

  • Key: UMLR-650
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Signal receipt symbol
    ....
    Where <trigger> is specified as described in sub clause 13.3.4 with the restriction that only Signal and change Event types are
    allowed.
    ...

    How can I show, using the alternative format, a time trigger

  • Reported: UML 2.5 — Thu, 21 Jan 2016 16:29 GMT
  • Updated: Thu, 21 Jan 2016 16:29 GMT

Use of decomposition indicator

  • Key: UMLR-649
  • Legacy Issue Number: 19879
  • Status: open  
  • Source: Anonymous
  • Summary:

    Fig. 14.8 uses a decomposition indicator (a lying 8) which is not defined in the document. Actually it is already in UML 1.5 (fig. 3-74 on p. 3-141) in the HiddenComposite. There needs to be some formal description of this icon.

    Actually in Enterprise Architect this icon is used as commonplace for decomposition of arbitrary elements. This is a very convenient feature and it should be part of the general UML specification.

  • Reported: UML 2.5 — Mon, 7 Dec 2015 05:00 GMT
  • Updated: Tue, 5 Jan 2016 21:30 GMT

InstanceSpecification for a qualified Property

  • Key: UMLR-648
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Axel Scheithauer)
  • Summary:

    As far as I can see, there is no possibility to specify an instance for a Class with a qualified Property.

    In figure 11.37 there is the example of a Class Bank that is associated with a Person with the qualifier accountNo. Where would the accountNo be specified in an InstanceSpecification of the Bank?

    If this is intentionally left out, this intention should be mentioned in the specification.

  • Reported: UML 2.5 — Mon, 4 Jan 2016 14:37 GMT
  • Updated: Mon, 4 Jan 2016 14:37 GMT

Recursive use of Interaction Use

  • Key: UMLR-646
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    It appears possible that an interaction use refers to an interaction that it also appears in causing a kind of recursive call.

    This capability is not a problem (to me), but the specification should probably say something about this – limitations, constraints, etc.

  • Reported: UML 2.5 — Thu, 3 Dec 2015 02:20 GMT
  • Updated: Thu, 3 Dec 2015 07:04 GMT

Limitation on isDimension Partition to be uncontained appears unwarranted

  • Key: UMLR-647
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    In 15.7.7.6 a constraint state that an isDimension Activity Partition may not be contained in another Activity Partition.

    Certain common modeling situations arise that make hierarchical dimensions of more than 2 levels useful.

    For example. Let Location be an isDimension ActivityPartition. It could have three lowerlevel partitions: US, EU, Other. Within the US, we could lower-level partitions, NY, Chicago, and Miami and so forth. It seems to me that the US would be also be an isDimension Activity Partition.

  • Reported: UML 2.5 — Thu, 3 Dec 2015 02:47 GMT
  • Updated: Thu, 3 Dec 2015 02:47 GMT

Classifier.allSlottableFeatures shall incorporate redefinition

  • Key: UMLR-645
  • Legacy Issue Number: 19863
  • Status: open  
  • Source: Fraunhofer FOKUS ( Mr. Marc-Florian Wendland)
  • Summary:

    The Operation Classifier.allSlottableFeatures() is not correct for it does not take into account potentially redefined StructuralFeatures. This leads to a situation where Feature are defined as slottable that are, in fact, not visible in the scope of the Classifier of an InstanceSpecification.

    There are two options:
    1. Enhance allSlottableFeatures in a way that redefined StructuralFeatures are resolved first.
    2. Introduce another operation allEffectiveSlottableFeatures that invokes allSlottableFeatures and resolves the redefinition of those Features afterwards.

    In my opinion, option 1 should be followed.

  • Reported: UML 2.5 — Wed, 2 Dec 2015 05:00 GMT
  • Updated: Wed, 2 Dec 2015 20:24 GMT

Location of owning fully qualifed name not specified.

  • Key: UMLR-643
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    When an package or other element is contained within another element, the path name / fully qualified name has no place to appear on the diagrams.

    In some tools they can appear below the Element name or above the Element name or in-line (as a prefix) with the Element name. The specification should clarify which, if any or all, are acceptable.

    Also, it should be clear that these paths are surrounded by {} or perhaps by [] or () or whatever. Currently, there is no guidance on what is acceptable,

  • Reported: UML 2.5 — Tue, 10 Nov 2015 22:33 GMT
  • Updated: Tue, 10 Nov 2015 22:33 GMT

Clarify the difference between «create» and «instantiate»

  • Key: UMLR-642
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    The descriptions of these two dependencies seem to be identical in meaning and the UML discussion communities on LinkedIn and StackOverflow seem to be confused. It would help to have some differences identified. Here's my proposal.

    I use the dependency «Instantiate».when I mean a true object-oriented instantiation arrived at by calling the constructor (which is how the I would translate the model into code). I would use «Create» when it's a different kind of creation, either more indirect, conceptual, or using non-object-oriented features.

    Here are some examples. I would use «Create» to say Word-->«Create» a Document, a modeler «Create» a model. Though I normally wouldn't model this in detail, I would use «Create» to indicate a component «Create» a new database record, the database manager «Create» a new database, a programmer «Create» a new app. Or create a new element in an (non-object-oriented) array. These can happen without directly calling a traditional object-oriented constructor – and can't be directly converted to code.

    On the other hand, if I had a marriage operation on a person, it would probably «Instantiate» the association class object of marriage.

  • Reported: UML 2.5 — Tue, 10 Nov 2015 05:26 GMT
  • Updated: Tue, 10 Nov 2015 06:36 GMT

Missing parameter properties of stream and exception in BNF

  • Key: UMLR-641
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    on Page 117 Paragraph 9.6.4 Notation, it says:

    The notation in class diagrams for exceptions and streaming Parameters on Operations has the keywords “exception” or “stream” in the property string.

    However, these are not shown as possible in the BNF definition of Operation Notation, nor in the section on Parameter notation in 9.4.4.

    I assume, though it is not completely clear that these keywords go on the parm-property and not the oper-property.

    Recommendations
    1) Modify the paragraph on 117 to say:

    The notation in class diagrams for exceptions and streaming Parameters on Operations has the keywords “exception” or “stream” in the parameter's property string.

    2) Modify the BNF in 9.4.4 as follows:

    <parm-property> indicates additional property values that apply to the Parameter.
    <parm-property> ::= ’ordered’ | ’unordered’ | ’unique’ | ’nonunique’ | ’seq’ | ’sequence’ | 'exception' | 'stream' where...

    and add after (on page 109)

    • ’seq’ or ’sequence’ applies when there is a multi-valued Parameter and means that its values constitute an ordered bag, i.e., isUnique = false and isOrdered = true.

    the following:

    • 'exception' indicates that this parameter has isException = true.
    • 'stream' indicates that this parameter has isStreaming = true.
  • Reported: UML 2.5 — Mon, 9 Nov 2015 17:52 GMT
  • Updated: Mon, 9 Nov 2015 17:52 GMT

What is the order for EnumerationLiterals?

  • Key: UMLR-637
  • Legacy Issue Number: 19850
  • Status: open  
  • Source: Anonymous
  • Summary:

    The constraint #1 (i.e., Matching EnumerationLiterals must be in the same order.) indicates the order of literals is meaningful and important for enumeration. So the question is what is the order for none matching literals in the resulting enumeration? For example, consider enumeration A is

    {A, B, C, E}

    and enumeration B (matching A) is

    {A, C, D, F}

    , what is the order for literals E, D, and F in the resulting enumeration?

  • Reported: UML 2.5 — Thu, 5 Nov 2015 05:00 GMT
  • Updated: Sun, 8 Nov 2015 21:38 GMT

Wrong expression for dipicting package merge process?

  • Key: UMLR-639
  • Legacy Issue Number: 19852
  • Status: open  
  • Source: Anonymous
  • Summary:

    In the example, the specification says X is the receiving element and Y is the merged element for the representation X@Y. But the Figure 12.7 displays a reverse order for the receiving element and the merged element for element A. Is this a bug or I misunderstand it?

  • Reported: UML 2.5 — Thu, 5 Nov 2015 05:00 GMT
  • Updated: Thu, 5 Nov 2015 16:55 GMT

Inconsistency in constraints and rules for property merge

  • Key: UMLR-638
  • Legacy Issue Number: 19851
  • Status: open  
  • Source: Anonymous
  • Summary:

    The constraint #2 (i.e., The value of isUnique of matching Properties must be the same.) demands the values of isUnique for matching properties are the same, which is a prerequisite for merging, but the transformation rule #7 (i.e., For matching Properties: if either the merged and/or receiving elements have isUnique = false, the resulting element has isUnique = false; otherwise, the resulting element has isUnique = true.) ignores it. How to explain it?

  • Reported: UML 2.5 — Thu, 5 Nov 2015 05:00 GMT
  • Updated: Thu, 5 Nov 2015 16:55 GMT

How to deal with guard in Transition redefinition?

  • Key: UMLR-636
  • Legacy Issue Number: 19849
  • Status: open  
  • Source: Anonymous
  • Summary:

    In p. 336 (i.e., 14.3.3.1.2 Transition redefinition) of UML 2.5 specification, the spec. says "A Transition of an extended StateMachine may in the StateMachine extension be redefined. Transitions can have their effect and target State replaced, while the source State and trigger are preserved." It does not mention the guard property of Transition, so, the guard property must be preserved or can be replaced? Any ideas?

  • Reported: UML 2.5 — Thu, 5 Nov 2015 05:00 GMT
  • Updated: Thu, 5 Nov 2015 16:55 GMT

Typing error in figure 9.11

  • Key: UMLR-635
  • Legacy Issue Number: 19848
  • Status: open  
  • Source: Anonymous
  • Summary:

    "Integer = 7" in ClassB in Figure 9.11 should be "height: Integer = 7".

  • Reported: UML 2.5 — Thu, 5 Nov 2015 05:00 GMT
  • Updated: Thu, 5 Nov 2015 16:55 GMT

Wrong figure referrence in text

  • Key: UMLR-634
  • Legacy Issue Number: 19847
  • Status: open  
  • Source: Anonymous
  • Summary:

    In the first sentence "Figure 15.71 depicts multidimensional swimlanes." of the last paragraph on p. 408. It should be Figure 15.72, not 15.71.

  • Reported: UML 2.5 — Thu, 5 Nov 2015 05:00 GMT
  • Updated: Thu, 5 Nov 2015 16:55 GMT

Computation error for the example of ReduceAction

  • Key: UMLR-633
  • Legacy Issue Number: 19846
  • Status: open  
  • Source: Anonymous
  • Summary:

    the sum of (2, 7, 5, 3) in the example for ReduceAction should be 17, not 11.

  • Reported: UML 2.5 — Thu, 5 Nov 2015 05:00 GMT
  • Updated: Thu, 5 Nov 2015 16:55 GMT

UML 2: Lifeline should be made a TemplateableElement

  • Key: UMLR-631
  • Legacy Issue Number: 19841
  • Status: open  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    To support generic interaction specifications, it would be useful to make Lifeline a TemplateableElement. This would allow a given interaction specification to be used in multiple places with different instances playing the appropriate roles.

  • Reported: UML 2.5 — Wed, 21 Oct 2015 04:00 GMT
  • Updated: Fri, 23 Oct 2015 16:20 GMT

Semantics of UnlimitedNatural in notation section.

  • Key: UMLR-630
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Clause 8.2.4 (Notation) mentions that "unlimited" denotes a lack of limit and not infinity. This is semantics, rather than notation, would be better in 8.2.3.

  • Reported: UML 2.5 — Mon, 19 Oct 2015 13:19 GMT
  • Updated: Mon, 19 Oct 2015 13:19 GMT

Matching between '+-#~' in Property's and "public-private-protected-package" is not described

  • Key: UMLR-629
  • Legacy Issue Number: 19838
  • Status: open  
  • Source: Anonymous
  • Summary:

    In 9.5.4:
    <visibility> is the visibility of the Property. (See VisibilityKind - sub clause 7.4.)
    <visibility> ::= ‘+’ | ‘-‘ | ‘#’ | ‘~’

    In 7.8.24 VisibilityKind [Enumeration]:
    • public
    • private
    • protected
    • package

    Matching between keywords and symbols is not described anywhere.

  • Reported: UML 2.5 — Sun, 11 Oct 2015 04:00 GMT
  • Updated: Wed, 14 Oct 2015 16:24 GMT

Constraint wording implies aggregation is only for associations

  • Key: UMLR-628
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Filed for Alexander Knapp (DOL team).
    The third constraint in 11.8.1.8 says "Only binary Associations can be aggregations", which can be read to mean composite properties must be ends of associations (compare to the OCL). Suggested rewording: "Aggregate associations must be binary".

  • Reported: UML 2.5 — Fri, 9 Oct 2015 13:00 GMT
  • Updated: Fri, 9 Oct 2015 13:00 GMT

Need to constrain where triggers can be put in state machines

  • Key: UMLR-626
  • Legacy Issue Number: 19821
  • Status: open  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    There does not seem to be any constraint that prevents a transition that does not emanate from an actual State from having a trigger. This means, for instance, that a transition originating on an entry or exit pseudostate, or a history pseudostate, could have a trigger, which is semantically invalid.

    A constraint should be added to ensure that only transitions originating from an actual State (except for the Final state) can have a trigger.

  • Reported: UML 2.5 — Fri, 24 Jul 2015 04:00 GMT
  • Updated: Fri, 31 Jul 2015 20:45 GMT

Missing: how +-#~ symbols map to VisibilityKind

  • Key: UMLR-625
  • Legacy Issue Number: 19819
  • Status: open  
  • Source: Anonymous
  • Summary:

    Although section 7.8.24 describes the VisibilityKind enumeration and its values, and sections 9.5.4 and 9.6.4 state that the +, -, # and ~ symbols can be used to denote visibility, nowhere is the mapping made explicit.

    I would expect a list like that at the end of section 9.21.2 of format-12-05-06 or section 7.3.56 of formal-12-05-07:

    '+' public
    '-' private
    '#' protected
    '~' package

  • Reported: UML 2.5 — Sun, 26 Jul 2015 04:00 GMT
  • Updated: Fri, 31 Jul 2015 20:34 GMT

Example for association-like notation for attribute contradicts description.

  • Key: UMLR-624
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    In 9.5.4 page 114, it says
    "In a Classifier, an attribute may also be shown using association notation, where only an aggregation adornment (hollow or filled diamond) may be shown at the tail of the arrow."

    However, in Figure 9.12 on page 116, an example is given with the following problems
    1) No aggregation adornment is shown
    2) A navigation adornment is given
    3) An ownership ball is given.
    4) An association name (role) is given.
    5) Multiplicity is given

    I assume that the attribute this is supposed to illustrated is endName:ClassName.

    Also, it doesn't seem to make sense to use a hollow aggregation adornment, as this would allow an attribute to be shared, which is otherwise not possible.

    Please add a little text to this example, showing
    1) what notation is required
    2) How it is distinguished (if all all) from an actual association end.
    3) What the attribute name is derivable from the diagram

  • Reported: UML 2.5 — Mon, 6 Jul 2015 06:06 GMT
  • Updated: Tue, 7 Jul 2015 09:15 GMT

In OCL, the use of ::_'in' appears unwarranted

  • Key: UMLR-623
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    In several places in the UML spec, we find the following expression

    ParameterDirectionKind::_'in'

    What are the leading _ and ' ' doing there.
    For example, on page 310 we have.

    body: ownedParameter->select(direction=ParameterDirectionKind::_'in' or direction=ParameterDirectionKind::inout)

    See that the inout literal does not require _ or the quotes.

    This appears to happen with all OCL mentions of the "in" literal

  • Reported: UML 2.5 — Thu, 4 Jun 2015 19:54 GMT
  • Updated: Thu, 4 Jun 2015 21:34 GMT

Define well-formed/ill-formed

  • Key: UMLR-622
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    These terms are used in a few places and are very unclear. Are activity diagrams that are blocked (because of diverted forks) well-formed? Are non-deterministic diagrams well-formed?

  • Reported: UML 2.5 — Thu, 4 Jun 2015 01:19 GMT
  • Updated: Thu, 4 Jun 2015 06:51 GMT

Clarify Property Qualifiers with a full Example

  • Key: UMLR-621
  • Legacy Issue Number: 19772
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    Figure 11.37 has an example with presumably an Association for:

    Bank::persons : Person[*]

    {opposites Person::banks}

    Person::banks : Bank[*]

    {opposites Bank::persons}

    adding explicit names for clarity.

    The qualifier presumably adds a nested Property

    Bank::persons::accountNo : Person[?]

    specifying an important multiplicity and a possibly redundant type, although a qualified association might perhaps return a derived type.

    Where is it modeled that the qualifier itself is Integer[1] or perhaps String[3]?

    Presumably an opposite qualifier is required and this must form part of a refined Association. If this is indeed the case it needs a better example. If it not the case, the alternative solution needs an example.

  • Reported: UML 2.5 — Tue, 2 Jun 2015 04:00 GMT
  • Updated: Tue, 2 Jun 2015 14:13 GMT

Repr. of applied stereotypes and their properties insufficiently described

  • Key: UML22-307
  • Legacy Issue Number: 10826
  • Status: closed  
  • Source: International Business Machines ( Andreas Maier)
  • Summary:

    Issue: UML representation of applied stereotypes and their properties is
    insufficiently described
    Nature: Clarification
    Severity: Significant
    Summary:

    1. In the Superstructure spec 2.1.1, it is not clearly stated what an
    applied stereotype is in terms of metaclasses. The spec talks
    about "instance of a Stereotype", but it fails to sufficiently
    clarify the so-called meta-level crossing, i.e. the fact that an
    instance of the Stereotype metaclass at the same time is a new
    metaclass. The description of Stereotype says in the Semantics
    section: "An instance “S” of Stereotype is a kind of (meta) class
    ". I think "a kind of" as well as putting "(meta)" in parenthesis
    is confusing. I suggest to say: "An instance “S” of the Stereotype
    metaclass is itself a metaclass.". Also, the text currently does
    not describe what the name and particularly the namespace of the
    metaclass corresponding to the instance of the Stereotype
    metaclass would be. Because of the current uncertainty, UML tools
    have taken different (and incompatible) interpretations on how an
    applied stereotype should be represented in terms of UML
    metaclasses.

    2. It is not described currently how any property values of applied
    stereotypes are represented in terms of instances of metaclasses.
    When looking at generated XMI, it seems that this representation
    is quite different from Property metaclass instances that are
    ownedAttributes of user model classes, so there is a need to
    clarify this. Because of the current uncertainty, UML tools have
    taken different (and incompatible) interpretations on how these
    values should be represented in terms of UML

  • Reported: UML 2.1 — Sat, 17 Mar 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Mon, 11 May 2015 23:49 GMT

Class.isAbstract attribute is not necessary

  • Key: UMLR-619
  • Legacy Issue Number: 19756
  • Status: open  
  • Source: Anonymous
  • Summary:

    Class.isAbstract attribute has the same type, multiplicity and default value as Classifier.isAbstract. Meaning of these attributes is also the same. Probably the Class.isAbstract attribute is not necessary and can be removed

  • Reported: UML 2.5 — Fri, 8 May 2015 04:00 GMT
  • Updated: Fri, 8 May 2015 21:12 GMT

Multiplicity of opposite end of a number of associations from various action metaclasses

  • Key: UMLR-420
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    The opposite ends to the properties have the multiplicity 0..1:

    • ClearAssociationAction::association
    • ReadExtentAction::classifier
    • ReadLinkObjectEndAction::end
    • ReadLinkObjectEndQualifierAction::qualifier
    • ReplyAction::replyToCall

    This means that there can be at most one action in a model for any one value of the above properties. This clearly incorrect. The multiplicity should be 0..* in all these cases.

  • Reported: UML 2.5 — Fri, 13 Feb 2015 17:33 GMT
  • Updated: Mon, 20 Apr 2015 14:37 GMT

isDirectlyInstantiated is defined in reverse

  • Key: UMLR-618
  • Legacy Issue Number: 19741
  • Status: open  
  • Source: Anonymous
  • Summary:

    The following paragraph from the specification defines isDirectlyInstantiated in reverse (need to swap "true" and "false"):

    The isDirectlyInstantiated property specifies the kind of instantiation that applies to a Component. If false, the Component is instantiated as an addressable object. If true, the Component is defined at design-time, but at run-time (or execution-time) an object specified by the Component does not exist, that is, the Component is instantiated indirectly, through the instantiation of its realizing Classifiers or parts.

  • Reported: UML 2.5 — Mon, 13 Apr 2015 04:00 GMT
  • Updated: Sun, 19 Apr 2015 23:20 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

NamedElement::allNamespaces is invalid at model root

  • Key: UMLR-328
  • Legacy Issue Number: 19349
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    The specified OCL body for NamedElement::allNamespaces has its tests in the wrong order and consequently fails at the root since in:

    if owner.oclIsKindOf(TemplateParameter) and
    owner.oclAsType(TemplateParameter).signature.template.oclIsKindOf(Namespace) then
    ...
    else
    if namespace->isEmpty()
    then ...

    At the root owner is null and the navigation results in invalid for both arms of the conjunction and consequently the if condition and if result.

    Suggest the more readable, less redundant and more correct:

    if owner = null
    then OrderedSet{}
    else
    let enclosingNamespace : Namespace =
    if owner.oclIsKindOf(TemplateParameter)
    and owner.oclAsType(TemplateParameter).signature.template.oclIsKindOf(Namespace)
    then owner.oclAsType(TemplateParameter).signature.template.oclAsType(Namespace)
    else namespace
    endif
    in enclosingNamespace.allNamespaces()->prepend(enclosingNamespace)
    endif

  • Reported: UML 2.5 — Sun, 20 Apr 2014 04:00 GMT
  • Updated: Wed, 11 Mar 2015 03:37 GMT

Section 15.5.3: a missed word

  • Key: UMLR-351
  • Legacy Issue Number: 19545
  • Status: open  
  • Source: mail.ru ( Alexei Zinoviev)
  • Summary:

    In fourth paragraph, phrase "While the ExecutableNode is executing, it is considered to hold a single control indicating it is execution." the word "token" is missed.
    The corrected sentence: "While the ExecutableNode is executing, it is considered to hold a single control token indicating it is execution."

  • Reported: UML 2.5 — Tue, 29 Jul 2014 20:23 GMT
  • Updated: Wed, 11 Mar 2015 03:36 GMT

Section: 7.3.10/Associations

  • Key: UML22-1380
  • Legacy Issue Number: 12383
  • Status: closed  
  • Source: Steria Mummert Consulting AG ( Torsten Binias)
  • Summary:

    Please explain why constrainedElement has to be an ordered set and not a set

  • Reported: UML 2.1.2 — Wed, 16 Apr 2008 04:00 GMT
  • Disposition: Duplicate or Merged — UML 2.2
  • Disposition Summary:

    Duplicate

  • Updated: Sun, 8 Mar 2015 21:04 GMT

section on connectors in the component chapter

  • Key: UML22-1376
  • Legacy Issue Number: 7364
  • Status: closed  
  • Source: Missouri University of Science and Technology ( Thomas Weigert)
  • Summary:

    The section on connectors in the component chapter does not add any new functionality to the connectors defined in internal structure. It does provide an additional notation for assembly connectors. There is no reason to have this section in components. Everything that is said semantically about connectors here applies equally to the more general connector. Suggestion: Do not subtype connector in component but move the content of this section to the connector section in internal structure and merge with the section there. Adjust the examples to apply to structured classifiers in general (i.e., delete the component symbol). Further, the ConnectorKind should be derived as it is determined by the manner in which the connector is attached to connectable elements. Deriving this connector ensures that constraints are always true and allows to do away with some consistency constraints. (Actually, it is not clear what the value of this attribute is, as it is already determined from the attachments.) Alternatively, if the presentation option is not in general desired (albeit I cannot see why this additional consistency would not be wanted), the text can be moved up but the presentation option can be added in this section.

  • Reported: UML 2.0 — Wed, 19 May 2004 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    Moving all of BasicComponents.Connector into InternalStructures, although perhaps strategically a good idea, seems like a bridge too far for the RTF. Also Thomas is not entirely accurate when he says it adds no new functionality apart from the notation. In particular BasicComponents adds the idea of a connector contract, which is a set of Behaviors.
    Therefore I propose that we leave the text where it is, albeit we should fix the many bugs in it that are the topics of this and other issues.
    However the proposal that kind:ConnectorKind should be derived is entirely sensible, especially since the current constraints on connector kind are the topic of numerous issues (7248-7251).

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

No unambiguous way in UML 2.4 to serialize StructuredActivityNode

  • Key: UML241-47
  • Legacy Issue Number: 16232
  • Status: closed  
  • Source: NASA ( Dr. Maged Elaasar)
  • Summary:

    We just recently had discussion with Ed about an issue with Activity::node and Activity::group. Both are composite non-derived properties and it causes problems with all StructuredActivityNodes, which are ActivityNodes and ActivityGroups at the same time.
    MagicDraw or Eclipse implementation of UML does not allow to own the same element in two composites , even if owner element is the same.
    Does XMI support that?

    So, ExpansionRegion or any other StructuredActivityNode appears in Activity::group only.

    fUML spec/engine expects to find them in Activity::node , as all owned nodes should be there.

    Any suggestions? Don't you think we should fix that somehow?

  • Reported: UML 2.4 — Wed, 11 May 2011 04:00 GMT
  • Disposition: Resolved — UML 2.4.1
  • Disposition Summary:

    No Data Available

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

navigation only possible to generalization but not to specializations of elements

  • Key: UML24-152
  • Legacy Issue Number: 15766
  • Status: closed  
  • Source: Vienna University of Economics and Business ( Bernhard Hoisl)
  • Summary:

    I am using the UML specification very often and I am navigating a lot through specific elements. One thing which bothers me most is that I can only hop to the generalization of elements but not to their specializations. For example for activity diagrams, if I go to Section 12.3.16 CentralBufferNode (p. 360) I know that it is a sub-type of an ObjectNode. But now I have no chance to see which sub-types of a CentralBufferNode exists (e.g. a DataStoreNode). So I have to navigate back to p. 312 to see the dependencies of a CentralBufferNode.

    In my point of view would displaying not only generalizations but also specializations of elements directly at an element's description be a great advantage to the readability of the specification.

    It would certainly be a great surplus to me, maybe others have thought the same way, too.

  • Reported: UML 2.3 — Tue, 19 Oct 2010 04:00 GMT
  • Disposition: Closed; No Change — UML 2.4
  • 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: Sun, 8 Mar 2015 15:04 GMT

Japan Superstructure PAS Ballot Comments - comment 9

  • Key: UML23-155
  • Legacy Issue Number: 14266
  • Status: closed  
  • Source: Anonymous
  • Summary:

    GE All the heading should be numbered as subclauses or itemized as lists.

    Follow Directives part2 5.2.

  • Reported: UML 2.2 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    There are a large number of Bold headings in the document, which are not numbered. Many OMG specs do this, and it was used in ISO/IEC 19501. Changing the spec at this time to give each one of these Bold headers their own subsection number. e.g., sec 7.3.3 has sub headings "Generalization" , "Description" etc., is too large too large an undertaking to incorporate into version 2.3 of UML.
    Revised Text:

    Disposition: Closed, No Change

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

New proposal for conjugate types for ports

  • Key: UML23-154
  • Legacy Issue Number: 13081
  • Status: closed  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    The SoaML submission team understands the concerns about making UML extensions at all, let alone introducing changes too high up in the hierarchy that might introduce additional unintended inheritance issues. But we are also reluctant to submit to the UPMS RFP without addressing the need to distinguish services from requests, and without addressing the usability issues that result from the need to create separate types for both ends of a connector.

    Recall that the problem is that ports appear on two ends of a connector. It is very often the case that consumers and providers can agree on the provided and required interfaces, and the interaction characteristics (protocol) and should therefore be able to use the same type to highlight that agreement. This is not possible with UML2. Ports don't have direction to indicate whether the owning component is using the operations or providing them. So users are forced to create "conjugate" types that flip the usage and realization relationships between classes and interfaces. This is especially troubling for the common simple case where the port is typed by a simple Interface.

    There have been a number of suggestions about how to solve this problem, many involving how ports define provided and required interfaces, and whether they need a type at all. We wanted to solve this problem without making a lot of changes to UML that may have other unintended consequences, or not sufficiently address the issues. So our updated proposal is very simple, and hopefully not something that would in any way effect future changes to UML2.

    We suggest the addition of a new Enumeration called PortDirection which has literals incoming and outgoing. Then add a new ownedAttribute to Port called direction: PortDirection = incoming. This would provide a direction on port that would be used to change how the provided and required interfaces are calculated. If direction=incoming, then the provided interfaces are those realized by the port's type and the required interfaces are those used by its type. If the direction is outgoing, the calculations are reversed: the provided interfaces are those used by the port's type, and the required interfaces are those realized by the port's type. Therefore, provided and required interfaces are calculated from the point of view of the owner of the port based on whether they are using the capabilities defined by the port's type, or providing them.

    This does not provide similar capabilities for things like connected collaborationRole Properties in a Collaboration. These properties are of course not Ports, and there is no specific specialization of Property (i.e., Role) that distinguishes the usage of a property in a collaboration that could specify the direction from other usages of property where direction is not relevant. We will miss that capability, but don't want to expand the scope of the UML change to address it at this time. Rather we'll wait and see if the UML2 RTF comes up with a more general solution that is also consistent with port direction.

    Is this acceptable?

  • Reported: UML 2.1.2 — Thu, 6 Nov 2008 05:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    This is a verbatim duplicate of 13080 which I will address soon.

    Revised Text:
    None.

    Disposition: Duplicate.

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

proper content for Figure 13.8

  • Key: UML23-153
  • Legacy Issue Number: 10083
  • Status: closed  
  • Source: Capability Measurement ( Karl Frank)
  • Summary:

    The UML 2.1 spec, 06-04-02, has lost the proper content for Figure 13.8, by duplicating the content of Figure 13.7 again and labeling it 13.8. See pages 442 and 443 as paginated in the pdf, 462 and 463 as paginated by Adobe in onscreen display.

    above from the 06-04-02 spec, below from the 05-07-04 spec

  • Reported: UML 2.1 — Wed, 2 Aug 2006 04:00 GMT
  • Disposition: Closed; No Change — UML 2.3
  • Disposition Summary:

    Discussion: Fixed in an earlier release; also duplicate of10469 Revised Text: N/A Disposition: Closed, no change

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

Section: 15.3.8

  • Key: UML23-152
  • Legacy Issue Number: 10082
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    It is unclear what exactly is a path in the context of history pseudo states. For example: "Entry actions of states entered on the path to the state represented by a shallow history are performed." Is it the shortest path? The history path? What happens if the history state isn't the first state after the initial state, but located somewhere in the middle of the statemachine?

  • Reported: UML 2.1.1 — Wed, 2 Aug 2006 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    The word 'Path' has raised ambiguity with respect to how the history state will restore the active state configuration. There is only one way that the history will restore the active state, and that is through an implicit direct path from the history state to the last active state being reactivated (as though a transition is drawn directly from H to the last active substate). It in no way implies a state-by-state approach. (e.g. a path from the initial state to the last active state)

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

Section: 14.3.20

  • Key: UML23-151
  • Legacy Issue Number: 10076
  • Status: closed  
  • Source: Thomson Transaction Services ( Tim Grunewald)
  • Summary:

    My question regards the following: Syntax for the Message name is the following: <messageident> ::= ([<attribute> ‘=’] <signal-or-operation-name> [‘(‘ [<argument> [‘,’<argument>]* ‘)’] [‘:’ <return-value>]) | ‘*’ <argument> ::= (<[parameter-name> ‘=’] <argument-value>) | (<attribute> ‘=’ <out-parameter-name> [‘:’ <argument-value>] | ‘ -’ First, I see a typo in the argument definition where the beginning of the definition should read as follows (Note the first square bracket and less than symbol): <argument> ::= ([<parameter-name> ‘=’] Second, I would like clarification on this item. From the definition it seems that I cannot specify a message by just showning the parameters. For example, if I have a class that has an operation of setFoo(int value): void, I cannot have a message of the method and its parameters, for example, "setFoo(value)". It would look like this instead "setFoo(value=)" according to the definition in the specification. To me this just doesn't seem right to have this hanging equal sign. There are other examples, pages 458 and 491 for example, that show a parameter without the equals sign. Could someone clarify this for me?

  • Reported: UML 2.0 — Mon, 31 Jul 2006 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    Discussion:
    This issue seems to have been fixed already.
    Disposition: ClosedNoChange

  • Updated: Sun, 8 Mar 2015 14:22 GMT

7.3.41 Parameter (from Kernel, AssociationClasses)"

  • Key: UML22-1375
  • Legacy Issue Number: 9338
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Please note however, that (as far as I can see) Parameter only occurs in Kernel, NOT in AssociationClasses. So the correct statement would be "Parameter (from Kernel). This might bear a relation to the already existing FTF issue 8117.

  • Reported: UML 2.1 — Mon, 30 Jan 2006 05:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    This is an exact duplicate of issue 9337 Revised Text: N/A Disposition: Duplicate

  • Updated: Sun, 8 Mar 2015 14:22 GMT

UML 2 Super / Activities / missing subsets

  • Key: UML23-150
  • Legacy Issue Number: 8668
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Activity::node, Activity::edge, and Activity::group do not subset Namespace::ownedMember, but they should

  • Reported: UML 2.1 — Wed, 30 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 14:22 GMT

Profiles::ObjectNode has wrong default multiplicity

  • Key: UML22-1374
  • Legacy Issue Number: 8455
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    ObjectNode::upper should have default multiplicity unbounded (“*”) in order of object nodes to be multi-valued by default.

    Recommendation:

    Redefine inherited MultiplicityElement::upper to have default “*” in ObjectNode.

  • Reported: UML 2.1 — Fri, 4 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1.1
  • Disposition Summary:

    See issue 8454 for disposition

  • Updated: Sun, 8 Mar 2015 14:22 GMT

UML 2 Super / Components / realizingClassifier

  • Key: UML23-148
  • Legacy Issue Number: 8385
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    InterfaceRealization is a subclass of Realization that inherits the attribute Realization::realizingClassifier (defined in the Components package). This attribute has a multiplicity of 1, which means that InterfaceRealization must have a "realizingClassifier", even though this attribute only makes sense when the target is a Component and not an Interface. This is complicated further by the fact that InterfaceRealization has its own association end that serves a similar purpose called "implementingClassifier". But, this only makes sense for the case when the target of the realization is an Interface and not a Component.

    InterfaceRealization should not be forced to have a "realizingClassifier" attribute. The best way to fix this may be to define a separate subclass of Realization for the case of Components (e.g., ComponentRealization) such that the two cases are kept apart. Alternatively, the multiplicity on Realization::realizingClassifier could be set to 0..1.

  • Reported: UML 2.0 — Fri, 25 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    This has already been resolved in 2.2.

    Revised Text:
    None.

    Disposition: Closed, no change.

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

Section: 12.3.52

  • Key: UML22-1373
  • Legacy Issue Number: 8277
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    The association activityScope:Activity[0..1] substes owner as indicated in fit. 195. Add OCL notation to Constraints. Type - lower case the second letter in the second sentence of sub-section Additional Operations.

  • Reported: UML 2.0 — Mon, 14 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    OCL is duplicate with 6346. Subsets addressed in issue 9000.

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

Section: 8.3.4

  • Key: UML23-149
  • Legacy Issue Number: 8386
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Notation of a component realization is described as the same as the realization dependency, i.e. dashed line with open arrow-head. But the realization dependency has a triangular arrow-head. Please note that all component example figures use the open arrow-head. I would prefer the triangular arrow-head.

  • Reported: UML 2.0 — Fri, 25 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    This is a duplicate of part of 10651.

    Revised Text:
    None.

    Disposition: Duplicate.

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

LiteralReal has no default value. It would make sense if it had a value of 0 as for LiteralInteger.

  • Key: UML23-147
  • Legacy Issue Number: 19293
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    LiteralReal has no default value. It would make sense if it had a value of 0 as for LiteralInteger.

  • Reported: UML 2.2 — Mon, 24 Mar 2014 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    withdrawn by submitter

  • Updated: Sat, 7 Mar 2015 03:22 GMT

UML 2 chapter 17: template model cannot represent templates parameterized by value types

  • Key: UML23-146
  • Legacy Issue Number: 14062
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    In a programming language such as C# it is common, in libraries, to create parameterized types such as List<T>, which can be instantiated as List<Foo>, List<int>, List<Boolean> and so on.

    UML templates do not permit the equivalent. The parameters of a template are all instantiated objects of a known concrete metaclass. It is therefore invalid for parameter-kind (17.5.4) to be an abstract metaclass, such as Type. This is a very severe limitation when trying to map UML to C#.

  • Reported: UML 2.2 — Wed, 8 Jul 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    withdrawn by submitter, duplicate of 13257

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

Instance modeling does not take into account stereotypes properties

  • Key: UML22-1372
  • Legacy Issue Number: 13291
  • Status: closed  
  • Source: International Business Machines ( James Bruck)
  • Summary:

    Instance modeling does not take into account stereotypes properties.

    Assume I create a stereotype that I apply to some Class. That stereotype adds some property 'p' of type String. Now assume I create an InstanceSpecification of that Class.

    I believe I should be able to create a slot for 'p' and assign some value to it.

    Constraint [1] on InstanceSpecification 7.3.22 seems to restrict this since it mentions that the defining feature of each slot is a structural feature of a classifier of the instance specification. The properties contributed by the stereotype are not considered to be part of the features of the Classifier (assuming the stereotype is applied to a Classifier)

  • Reported: UML 2.1.2 — Thu, 15 Jan 2009 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    withdrawn by issue submitter

  • Updated: Fri, 6 Mar 2015 22:56 GMT

Comments owned by Packages (02)

  • Key: UML22-1371
  • Legacy Issue Number: 12262
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Typo in attributes section of comment: Remove "multiplicity" (red colored) before attribute body.

  • Reported: UML 2.1.2 — Wed, 5 Mar 2008 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 22:56 GMT

Comments owned by Packages

  • Key: UML22-1370
  • Legacy Issue Number: 12261
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    A package can only own packageable elements. That excludes comments. On the other hand the comment definition states: A comment can be owned by any element. That's a contradiction. It's important that packages can own comments. Therefore I propose a change of the package to allow the ownership of comments.

  • Reported: UML 2.1.2 — Wed, 5 Mar 2008 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion: It is not quite right to say that “a package can only own packageable elements”. The spec only says that “Only packageable elements can be owned members of a package.” That is, any owned members of the package, considered as a namespace, must be packageable elements – this is because packagedMember subsets the ownedMember derived union and no other property of Package does. However, a namespace (and hence a package) can have owned elements that are not owned members. In fact, all elements inherit the Element::ownedComment property that subsets ownedElement. For a namespace, ownedMember also subsets ownedElement, so the owned elements of a namespace (and hence a package) include both comments and namespace members. However, while a comment can thus owned by a namespace, it cannot be a member of the namespace, since it is not a named element. Disposition: Closed, no change.

  • Updated: Fri, 6 Mar 2015 22:56 GMT

section 15.3.14 Transition :: Constraints

  • Key: UML22-1369
  • Legacy Issue Number: 12170
  • Status: closed  
  • Source: International Business Machines ( James Bruck)
  • Summary:

    Using the 07-02-03, 2.1.1 spec we have the following (pg 569 or 583/732 section 15.3.14 Transition :: Constraints)):
    [5] Transitions outgoing pseudostates may not have a trigger. source.oclIsKindOf(Pseudostate) and ((source.kind <> #junction) and (source.kind <> #join) and (source.kind <> #initial)) implies trigger->isEmpty()

    This OCL erroneously states that Junctions and Joins may have outgoing transitions with triggers. As far as I understand, one can never be waiting in a junction point or join for a trigger to occur.

  • Reported: UML 2.1.2 — Tue, 8 Jan 2008 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 22:56 GMT

Regarding the quote on p128

  • Key: UML22-1368
  • Legacy Issue Number: 12169
  • Status: closed  
  • Source: International Business Machines ( James Bruck)
  • Summary:

    In the 2.1.1 specification (070205):

    Regarding the quote on p128:
    "All redefinitions should be made explicit with the use of a

    {redefines <x>}

    property string. Matching features in subclasses without an explicit redefinition result in a redefinition that need not be shown in the notation. Redefinition prevents inheritance of a redefined element into the redefinition context thereby making the name of the redefined element available for reuse, either for the redefining element, or for some other."

    I interpret the following quote from the UML 2.1.1 spec to mean that when a subclass includes a property whose name is equal to a property in one of its general classes, then it should be treated as a redefinition even if there is no explicit redefinition between those properties in the model.
    This should be clarified in the spec. It is unclear and also includes at least one spelling mistake. Alternatively, we should ban implicit redefinitions and flag them as simple name conflicts.

    Two features of the same kind defined in a class and a superclass (i.e., they are both either structural features or behavioral features) does indeed imply a redefinition and, therefore, must conform to the compatibility constraint on redefinitions.

  • Reported: UML 2.1.2 — Tue, 8 Jan 2008 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 22:56 GMT

Section: Composite Structures/Abstract syntax

  • Key: UML22-1367
  • Legacy Issue Number: 11503
  • Status: closed  
  • Source: Validas AG ( Reinhard Jeschull)
  • Summary:

    There are two diagrams on page 164, 'Connectors' and 'The port metaclass'. The two diagrams are the same. Can you send me the picture of this diagram via e-mail? We need it to create a metamodel.

  • Reported: UML 2.1.1 — Thu, 20 Sep 2007 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    withdrawn, this issue has been resolved

  • Updated: Fri, 6 Mar 2015 22:56 GMT

ptc/06-01-02:14.3.14, Notation

  • Key: UML22-1366
  • Legacy Issue Number: 9606
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    The following notation expression isn’t well formed:

    <interactionconstraint> ::= [‘[‘ (<Boolean-expression’ | ‘else‘) ‘]’]

  • Reported: UML 2.1 — Mon, 24 Apr 2006 04:00 GMT
  • Disposition: Resolved — UML 2.1.1
  • Disposition Summary:

    withdrawn by submitter

  • Updated: Fri, 6 Mar 2015 22:55 GMT

Output tokens

  • Key: UML22-1142
  • Legacy Issue Number: 8675
  • Status: closed  
  • Source: FUNDP ( Pierre Yves Schobbens)
  • Summary:

    In: [4] The output tokens are now available Replace ``available'' by ``offered''

  • Reported: UML 2.1 — Tue, 5 Apr 2005 04:00 GMT
  • Disposition: Duplicate or Merged — UML 2.1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 22:25 GMT

Problems with OCL definition of Package::makesVisible

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

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

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

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

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

    So here goes:

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

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

    ei.importedElement = VisibilityKind::public

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

    ei.visibility= VisibilityKind::public

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

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

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

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

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

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

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

    importedPackage.member->includes(el)

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

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

    {false, false, true, false, true}

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

    Then it makes no sense to test that for emptiness:

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

    I think this passage should be restated as follows:

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

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

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

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

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

    No Data Available

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

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

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

    To put it simply, I'm saying this:

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

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

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

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

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

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

A comment is a specialization of Element

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

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

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

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

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

Surplus classifier field serialized in Superstructure.xmi

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

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

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

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

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

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

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

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

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

Attribute is represented by Property

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

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

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

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

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

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

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

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

Operation "isConsistentWith" is not overridden for any RedefinableElement

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

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

    Please add an operation for ObjectNode at least.

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

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

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

Question About Arrows In Communication Diagramms

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

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

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

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

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

Constraint [1] uses undefined attribute "ownedAttribute

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

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

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

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

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

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

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

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

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

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

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

missing words in section 14.1

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

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

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

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

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

Incomplete sentence

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

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

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

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

    No Data Available

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

DurationObservation#event should be ordered

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

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

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

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

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

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

LifeLine instead of Lifeline

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

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

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

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

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

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

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

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

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

    I think this constraint is too limiting.

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

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

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

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

    corresponding to the outgoing transition from the junction.”

    Conclusion:

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

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

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

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

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

    Suggestion

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

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

    Then another constraint needs to be added

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

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

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

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

Modeling sent messages in State Machines

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

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

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

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

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

TestIdentityAction for datatypes

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

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

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

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

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

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

Behavior should be derived from Classifier, not Class

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Error in UML diagrams?

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

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

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

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

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

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

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

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

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

Suggestions for editorial changes

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

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

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

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

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

how to instantiate associations between stereotypes

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Core package caption wrong

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

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

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

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

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

Add an example for the lifeline head shape

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

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

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

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

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

    Merged with 11068

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

color of the notation is specified

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Opposite ends of derived unions should be derived unions

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

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

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

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

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

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

Use of term "locus of control"

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

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

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

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

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

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

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

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

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

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

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

default is wrong

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

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

    {incomplete, disjoint}

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

    {incomplete, overlapping}

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

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

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

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

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

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

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

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

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

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

Reference in index to item that does not exist in contents

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

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

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

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

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

incorrect upper value of coveredBy of Lifeline

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

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

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

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

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

ChangeEvent association mismatch

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

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

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

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

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

EnumerationLiterals in the XMI

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

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

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

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

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

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

"A_realization_abstraction_component" is useless

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

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

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

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

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

Subpart I and II are missing in Bookmarks

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

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

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

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

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

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

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

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

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

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

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

Figure 15.2 does not include TransitionKind

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

    enumeration TransitionKind should appear in Figure 15.2.

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

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

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

role "interval" appears "interva"

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

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

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

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

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

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

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

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

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

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

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

misspelling: io-oargument

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

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

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

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

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

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

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

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

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

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

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

RedefinableElement (from Kernel) is preferable

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

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

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

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

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

UML Superstructure Specification

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

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

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

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

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

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

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

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

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

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

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

{ordered} is rather far from +bodyOutput

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

    In Figure 12.22, there is "

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

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

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

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

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

Problem with ExtensionEnd::lower

  • Key: UML24-111
  • Legacy Issue Number: 15762
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    In the UML 2.4 metamodel, there is a definition of ExtensionEnd::/lower in the superstructure that marks the property as derived, and at the same time gives it a default of 0. The spec text and diagrams do not show it as derived, so the metamodel and diagrams are inconsistent. The same is true in 2.3.

    This seems to be a significant issue with regard to profile interchange, so I’d like to fix it in 2.4. Juergen, could we have an issue number please?

    Profiles::ExtensionEnd::/lower redefines MultiplicityElement::/lower.

    MultiplicityElement::/lower is marked as derived. It does not have a default value. Instead, there is a derivation constraint:

    lower = lowerBound(); and operation

    lowerBound() = if lowerValue->isEmpty() then 1 else lowerValue.integerValue() endif

    In the metamodel, ExtensionEnd::/lower is marked as derived, redefining MultiplicityElement::/lower, and with default value = 0. What is this supposed to mean? If it redefines MultiplicityElement::/lower, presumably it should redefine the way that it is derived. But it does not. So there is no well-defined derivation.

    If we regarded the derivation in MultiplicityElement to be somehow “inherited” across the redefinition, we would then have a clash between the 1 defined in Multiplicity::lowerBound(), and the 0 defined as the default value for ExtensionEnd::lower.

    I think to fix this what we ought to do is the following. Instead of giving ExtensionEnd::/lower a default value, we should provide the following constraints and operations in ExtensionEnd:

    lower = lowerBound(); and

    lowerBound() = if lowerValue->isEmpty() then 0 else lowerValue.integerValue() endif

    This seems to be consistent with current profile interchange practice. I see the following in MIWG testcase3, which is consistent with my proposal.

    <packagedElement xmi:type="uml:Extension" xmi:id="_9YgZUFzvEd6YpLSSRX9zkg" name="Property_Stereotype3" memberEnd="_9YgZUVzvEd6YpLSSRX9zkg _9YgZU1zvEd6YpLSSRX9zkg">

    <ownedEnd xmi:type="uml:ExtensionEnd" xmi:id="_9YgZUVzvEd6YpLSSRX9zkg" name="extension_Stereotype3" type="_FbscYFzfEd6YpLSSRX9zkg" aggregation="composite" owningAssociation="_9YgZUFzvEd6YpLSSRX9zkg" association="_9YgZUFzvEd6YpLSSRX9zkg">

    <lowerValue xmi:type="uml:LiteralInteger" xmi:id="_9YgZUlzvEd6YpLSSRX9zkg" value="1"/>

    </ownedEnd>

    </packagedElement>

  • Reported: UML 2.3 — Tue, 19 Oct 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    After analysis, it becomes clear that the diagnosis above is flawed. When Profiles are merged in at L2 and above, Kernel is merged in too. When they are all merged in, the complete definition of ExtensionEnd::/lower [0..1] is acquired from the following sources:

    • the fact that it is derived is from AuxiliaryConstructs::Profiles
    • the constraint that determines how it is derived from lowerBound() is inherited from Kernel::MultiplicityElement
    • the redefined operation lowerBound() is merged from InfrastructureLibrary::Profiles::ExtensionEnd: the operation is specified there even though lower is not derived in that place. This operation redefines Core::Constructs::MultiplicityElement::lowerBound(), so after merging will redefine Kernel::MultiplicityElement::lowerBound().
      However, the [0..1] multiplicity of lower() – the operation which gives the derivation for ExtensionEnd::/lower in the metamodel – conflicts with the [1] multiplicity of the corresponding redefined lower() operation in MultiplicityElement – it represents a “widening” of the multiplicity in a redefinition. This turns out to be a bug in the metamodel. In the spec, MultiplicityElement::lower(), MultiplicityElement::lowerBound() MultiplicityElement::upper(), MultiplicityElement::upperBound(), ValueSpecification::integerValue() are all defined with result types of Set(Integer), but have been implemented in the metamodel as Integer[1]. So the material defects are that lower is not correctly defined in the text or diagrams of clause 18, and the operations around MultiplicityElement and ValueSpecification should have their multiplicities corrected.
  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML state machines: inconsistent subset of StateMachine::extendedStatemachine

  • Key: UML24-108
  • Legacy Issue Number: 15669
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Issue 15265 proclaimed that StateMachine::extendedStatemachine should subset Classifier::redefinedClassifier. However, while the text entry for this field does this, the diagram in Figure 15.3 subsets Behavior::redefinedBehavior instead. It seems that the fix was not applied properly. Note that Behavior::redefinedBehavior is not a derived union property, so Figure 15.3 is just plain wrong – although it could be argued that the proper fix is to make it a derived union and have StateMachine::extendedStatemachine redefine Behavior::redefinedBehavior

  • Reported: UML 2.3 — Thu, 30 Sep 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    Figure 15.3 (referring to the version of 2.4 published in September 2010) is not wrong – it is valid for a property to subset a non-derived one. However the semantic question here is what exactly extendedStateMachine is supposed to mean that cannot be accomplished by using redefinedBehavior.
    It is wrong, however, in the sense that resolution 15265 was not correctly or consistently applied.
    At this point we need at least to make the resolution consistent.
    I propose to do this by making extendedStateMachine redefine behavior::redefinedBehavior, having the effect that only a state machine may redefine a state machine.

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

isDerived with DefaultValue

  • Key: UML24-107
  • Legacy Issue Number: 15668
  • Status: closed  
  • Source: NASA ( Dr. Maged Elaasar)
  • Summary:

    I think derived properties should not have default values, since they are calculated from other info in the model and not from those default values.

    Here is a list of such derived properties in the metamodel:

    PropertyIsDerivedWithDefaultValue : 13
    property = <Property> UML::State::/ isSubmachineState : Boolean
    defaultValue = <Literal Boolean> false
    property = <Property> UML::State::/ isSimple : Boolean
    defaultValue = <Literal Boolean> true
    property = <Property> UML::State::/ isOrthogonal : Boolean
    defaultValue = <Literal Boolean> false
    property = <Property> UML::State::/ isComposite : Boolean
    defaultValue = <Literal Boolean> false
    property = <Property> UML::Operation::/ upper : UnlimitedNatural [0..1]
    defaultValue = <Literal UnlimitedNatural> 1
    property = <Property> UML::Operation::/ lower : Integer [0..1]
    defaultValue = <Literal Integer> 1
    property = <Property> UML::Operation::/ isUnique : Boolean
    defaultValue = <Literal Boolean> true
    property = <Property> UML::Operation::/ isOrdered : Boolean
    defaultValue = <Literal Boolean> false
    property = <Property> UML::MultiplicityElement::/ upper : UnlimitedNatural [0..1]
    defaultValue = <Literal UnlimitedNatural > 1
    property = <Property> UML::MultiplicityElement::/ lower : Integer [0..1]
    defaultValue = <Literal Integer> 1
    property = <Property> UML::Message::/ messageKind : MessageKind
    defaultValue = <Instance Value> unknown
    property = <Property> UML::ExtensionEnd::/ lower : Integer [0..1]
    defaultValue = <Literal Integer > 0
    property = <Property> UML::Extension::/ isRequired : Boolean
    defaultValue = <Literal Boolean> false

    do we need to fix them?

  • Reported: UML 2.3 — Thu, 30 Sep 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    The FTF agrees that these default values are meaningless, and in many cases confusing. Remove them

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

Change all properties typed by data types to aggregation=none

  • Key: UML24-104
  • Legacy Issue Number: 15575
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    There is no semantic for making a property with a data type composite, so remove these markings

  • Reported: UML 2.3 — Wed, 22 Sep 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    UML::OpaqueAction::language
    UML::OpaqueAction::body
    UML::OpaqueBehavior::language
    UML::OpaqueBehavior::body
    UML::OpaqueExpression::language
    UML::OpaqueExpression::body

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

Give all constraints unique names within their context.

  • Key: UML24-103
  • Legacy Issue Number: 15574
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    Several constraints have no names. A couple of constraints have different names in different merge increments, but are the same constraint:

    UML::Constraint::not_apply_to_self, UML::Constraint::not_applied_to_self,

    UML::Classifier::generalization_hierarchies, UML::Classifier::no_cycles_in_generalization

  • Reported: UML 2.3 — Wed, 22 Sep 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    Here are the constraints with no names.
    UML::Transition::isConsistentWith::
    UML::RedefinableTemplateSignature::isConsistentWith::
    UML::RedefinableElement::isConsistentWith::
    UML::Property::isConsistentWith::
    UML::Package::makesVisible::
    UML::Operation::isConsistentWith::
    UML::OpaqueExpression::value::
    UML::OpaqueExpression::isPositive::
    UML::OpaqueExpression::isNonNegative::
    UML::MultiplicityElement::isMultivalued::
    UML::MultiplicityElement::includesMultiplicity::
    UML::MultiplicityElement::includesCardinality::
    UML::Classifier::inheritableMembers::
    UML::Classifier::hasVisibilityOf::
    These are all preconditions of operations. All of the bodies are named “spec” so I propose that all of the preconditions are named “pre”. I notice that Classifier::inheritableMembers has an incorrect un-named postcondition.

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

UML 2.4 - ConditionalNode - Semantics

  • Key: UML24-110
  • Legacy Issue Number: 15711
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    The last paragraph of the semantics section of 12.3.18 ConditionalNode, states

    Within the body section, variables defined in the loop node or in some higher-level enclosing node may be accessed and updated with new values. Values that are used in a data flow manner must be created or updated in all clauses of the conditional; otherwise, undefined values would be accessed.

    I assume that the reference to ‘loop node’ is incorrect.

  • Reported: UML 2.3 — Sat, 9 Oct 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    This issue is obsolete. The quoted text is no longer used in the UML 2.5 beta specification.
    Disposition: Closed - No Change

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

DecisionNode at all guards evaluated to false

  • Key: UML24-109
  • Legacy Issue Number: 15708
  • Status: closed  
  • Source: gmx.net ( Stephan Grund)
  • Summary:

    DecisionNode's behaviour when a token cannot pass any edge at the moment it arrives and the guards are evaluated is not specified.
    When will the guards be evaluated next time?

  • Reported: UML 2.3 — Thu, 7 Oct 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    This is covered in the UML 2.5 beta specification in Subclause 15.3.3 under “Decision Nodes”. The specification
    states: “If any of the outgoing edges of a DecisionNode have guards, then these are evaluated for each incoming
    token.” and “A token offered on the primary incoming edge of a DecisionNode shall not traverse any outgoing edge
    for which the guard evaluates to false.” So, if no guards evaluate to true, the token will not traverse any of the outgoing
    edges. The next time the guards are evaluated is when the next token is offered to the DecisionNode.
    Disposition: Closed - No Change

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

EnumerationHasOperations : UML::VisibilityKind::bestVisibility

  • Key: UML24-101
  • Legacy Issue Number: 15572
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    This is disallowed by MOF. [8] Enumerations may not have attributes or operations. This operation is not used – remove it.

  • Reported: UML 2.3 — Wed, 22 Sep 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    Agreed: the operation is defined in both Infrastructure 9.21.2 (and index) and Superstructure 7.3.56 but is not used anywhere.

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

Parameter have Effects

  • Key: UML24-100
  • Legacy Issue Number: 15571
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    These are attributes in the metamodel, but are not included in MOF 2.4, so should be removed.

  • Reported: UML 2.3 — Wed, 22 Sep 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    Here are the parameters that have effect set in the metamodel. Parameter::effect is defined with multiplicity [0..1], and in metamodels should be set to null.
    UML::Classifier::maySpecializeType::c
    UML::Classifier::inheritableMembers::c
    UML::Property::isAttribute:
    UML::Region::isRedefinitionContextValid::redefined
    UML::State::isRedefinitionContextValid::redefined
    UML::Component::usedInterfaces::classifier
    UML::Component::realizedInterfaces::classifier
    UML::StateMachine::isRedefinitionContextValid::redefined
    UML::RedefinableElement::isRedefinitionContextValid::redefined

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

Property::isID should not be optional

  • Key: UML24-106
  • Legacy Issue Number: 15664
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    Property::isID should not be optional”. The summary is “Property::isID should have multiplicity 1..1 and default value = false. There is no additional useful semantic provided by making it optional

  • Reported: UML 2.3 — Tue, 28 Sep 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    agreed

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

stereotype <> for defining parameterized classes is nowhere defined

  • Key: UML24-112
  • Legacy Issue Number: 15765
  • Status: closed  
  • Source: Vienna University of Economics and Business ( Bernhard Hoisl)
  • Summary:

    Usage of <<bind>> to define parameterized classes in object diagrams is nowhere defined in the UML specification. Not as a keyword in Annex B (p. 707) and also not as a standard stereotype (Annex C, p. 713).

    I just wondered what the actual definition of <<bind>> may be. Maybe it would be good to define it somewhere.

  • Reported: UML 2.3 — Tue, 19 Oct 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    Merged with 18454

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

UML 2.4 - Interaction

  • Key: UML24-105
  • Legacy Issue Number: 15622
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    In the semantics section of MessageEnd it says “Subclasses of MessageEnd define the specific semantics appropriate to the concept they represent.”

    However, in the semantics section of MessageOccurrenceSpecification, a subclass of MessageEnd, it says “No additional semantics”

    So it’s not clear what the semantics of MessageOccurrenceSpecification are.

  • Reported: UML 2.3 — Tue, 21 Sep 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • 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:58 GMT

The metamodel contains instances of Model

  • Key: UML24-102
  • Legacy Issue Number: 15573
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    InfrastructureLibrary and UML are instances of Model, and MOF does not include Model.

  • Reported: UML 2.3 — Wed, 22 Sep 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    Change Models to Packages

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

xmi files in the 2.4 RTF deliverables have cmof tags contained in a non-XMI root element

  • Key: UML24-80
  • Legacy Issue Number: 15438
  • Status: closed  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    xmi files in the 2.4 RTF deliverables have cmof tags contained in a non-XMI root element. Was it intentional that the current UML format XMI files use MOF/2.4 and
    XMI/2.4 in their namespaces, even though these namespaces won't actually be correct? There is also an error in the structure of the .xmi files. A non xmi:XMI root element has been used that includes a cmof:Tag element, which is incorrect. The following files are affected:
    10-08-17.xmi
    10-08-18.xmi
    10-08-22.xmi
    10-08-23.xmi
    10-08-27.xmi
    10-08-28.xmi
    10-08-29.xmi
    L0.merged.xmi
    L1.merged.xmi
    L2.merged.xmi
    LM.merged.xmi

    Example:
    ==> LM.merged.xmi <==
    </ownedComment>
    </ownedLiteral>
    </packagedElement>
    <cmof:Tag xmi:id="_2" name="org.omg.xmi.nsPrefix" value="uml" element="_0"/> </uml:Package> Should be:
    ==> LM.merged.xmi <==
    </ownedComment>
    </ownedLiteral>
    </packagedElement>
    </uml:Package>
    <cmof:Tag xmi:id="_2" name="org.omg.xmi.nsPrefix" value="uml" element="_0"/> </xmi:XMI>

    I've also just noticed that the most recent package resolution added a property named "URI" rather than "uri", which is inconsistent with the old MOF property and is slightly unusual capitalisation for a property.
    However that's a minor point.

  • Reported: UML 2.3 — Thu, 26 Aug 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    It was intentional to use the 2.4 namespaces, see 15530.
    Publish all of the xmi files that include cmof:Tag elements with a top-level XMI tag.
    Leave the property named URI as it is.
    Fix the profile XMI examples to conform to the normative specs.

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

Operation::isConsistentWith

  • Key: UML24-82
  • Legacy Issue Number: 15499
  • Status: closed  
  • Source: NASA ( Dr. Maged Elaasar)
  • Summary:

    The description for Operation::isConsistentWith(redefinee : RedefinableElement) suggests that parameter direction should be consistent

    "A redefining operation is consistent with a redefined operation if it has the same number of formal parameters, the same number of return results, and the type of each formal parameter and return result conforms to the type of the corresponding redefined parameter or return result."

    However, the OCL provided does not check that the "direction" of parameters is consistent.

    Operation::isConsistentWith(redefinee: RedefinableElement): Boolean;

    pre: redefinee.isRedefinitionContextValid(self)

    result = 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(1).type))

  • Reported: UML 2.3 — Mon, 13 Sep 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    Clause 9.6.3 currently says “This redefinition may specialize the types of the owned Parameters. . . ” and,
    contradicting this, says “In UML, such rules for type conformance are intentionally not specified.”
    We do not mandate either covariance or contravariance for parameters in operation definition, explicitly
    allowing either. We will require parameter direction, uniqueness and ordering to be the same. We will
    require a multiplicity for which one of the following is true:
    • The same as the redefined parameter
    • For an in parameter, multiplicity including (wider than) that of the redefined parameter
    • For an out or return parameter, the redefined parameter’s multiplicity includes (is wider than) that of
    the redefining parameter.
    This also resolves Issues 17924 and 17612.

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

UML2.4: StandardProfileL2 & L3 are incomplete as delivered

  • Key: UML24-81
  • Legacy Issue Number: 15439
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    1) the deliverables below are not well formed; each of StandardProfileL2 and StandardProfileL3 below is missing a reference to the UML2.4 metamodel as a PackageImport element.

    Filename: StandardProfileL2.xmi
    Description: This file contains the XMI of the UML v2.4 Standard Profile L2 as an instance of UML 2.4 using XMI 2.1.
    Doc Number (if any): ptc/2010-08-22
    Normative: Yes
    Dependencies: UML.xmi
    URL: http://www.omg.org/spec/UML/20100901/StandardProfileL2.xmi

    Filename: StandardProfileL3.xmi
    Description: This file contains the XMI of the UML v2.4 Standard Profile L3 as an instance of UML 2.4 using XMI 2.1.
    Doc Number (if any): ptc/2010-08-23
    Normative: Yes
    Dependencies: UML.xmi
    URL: http://www.omg.org/spec/UML/20100901/StandardProfileL3.xmi

    2) the inventory is missing the StandardProfileL2 & StandardProfileL3 as an instance of UML2.4 using XMI2.4.

    The artifacts on the UML2.xRTF SVN for StandardProfileL2/L3 as UML2.4/XMI2.4 have the same problem as the artifacts in (1).

  • Reported: UML 2.3 — Mon, 30 Aug 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    agreed

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

bodyCondition and isQuery

  • Key: UML24-84
  • Legacy Issue Number: 15501
  • Status: closed  
  • Source: NASA ( Dr. Maged Elaasar)
  • Summary:

    Constraint [7] in Kernel::Operation says:

    "A bodyCondition can only be specified for a query operation"

    Let us look at the definition of isQuery and bodyCondition:

    bodyCondition: Constraint[0..1]
    An optional Constraint on the result values of an invocation of this Operation.

    isQuery : Boolean
    Specifies whether an execution of the BehavioralFeature leaves the state of the system unchanged (isQuery=true) or whether side effects may occur (isQuery=false).

    Question:

    I am not sure why specifying a condition on the result of an operation is only limited to operations with no side effects. What is wrong with specifying a condition on the result of a non-query operation?

  • Reported: UML 2.3 — Mon, 13 Sep 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    Body conditions are already a major source of logical uncertainty and inconsistency between OCL and UML. Relaxing
    their usage would only make this worse: the OCL spec states “An OCL expression may be used to indicate the result
    of a query operation”.
    This also resolves 15768.
    Disposition: Closed - No Change

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

isConsistentWith

  • Key: UML24-83
  • Legacy Issue Number: 15500
  • Status: closed  
  • Source: NASA ( Dr. Maged Elaasar)
  • Summary:

    The operation RedefinableElement::isConsistentWith(redefinee : RedefinableElement) has the documentation:

    "The query isConsistentWith() specifies, for any two RedefinableElements in a context in which redefinition is possible, whether redefinition would be logically consistent. By default, this is false"

    It is not clear from this description above whether the parameter "redefinee" is the redefining or the redefined element.

    A look at some of the overrides of this operation like Property::isConsistentwith(redefinee : RedefinableElement):

    " A redefining property is consistent with a redefined property if the type of the redefining property conforms to the type of the redefined property, and the multiplicity of the redefining property (if specified) is contained in the multiplicity of the redefined property. "

    The description suggests that the "redefinee" is probably the "redefined" property.

    On the other hand, the precondition provided in OCL suggests that "refinee" is definitely the "redefining" property:

    pre: redefinee.isRedefinitionContextValid(self)

    since RedefinableElement::isRedefinitionContext(redefined : RedefinableElement) has the description:

    "...at least one of the redefinition contexts of this element must be a specialization of at least one of the redefinition contexts of the specified element."

    In summary, this means RedefinableElement has the two operations:

    RedefinableElement::isConsistentWith(redefining : RedefinableElement)
    RedefinableElement::isRedefinitionContext(redefined : RedefinableElement)

    At least "redefinee" should be renamed to "redfining" since this is the term used in the descriptions. However, having the two closely related operations taking opposite parameters make it very confusing and inconsistent.

  • Reported: UML 2.3 — Mon, 13 Sep 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    The issue has identified a serious problem of understanding with the operations that define what consistency
    between RedefinableElements means. Does A.isConsistentWith(B) get calculated when A is redefining, or
    when A is being redefined? The parameter name “redefinee” seems to imply that it gets calculated when A
    is redefining. But this turns out not to be the case. According to constraint redefinition_consistent, it is when A is being redefined. This also applies to the
    logic of Property::inConsistentWith and Operation::isConsistentWith (although see also 15499). For all
    other definitions of isConsistentWith the direction does not matter. So the logic consistently states that the
    parameter is the redefining element. Make this clear by renaming the parameter as redefiningElement.
    Now isRedefinitionContextValid is the other way around, as evidenced by the precondition for inConsistentWith:
    redefinee.isRedefinitionContextValid(self).
    Make this clearer by naming the parameter redefinedElement.
    It would perhaps be better to systematically reverse the sense of one of these operations, but that seems
    overly disruptive at this point. The constraint redefinition_context_valid is wrong. It omits the term “self”,
    rendering the constraint tautological. All of the constraints in RedefinableElement are too cryptic to be clear.

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

"unique" annotation

  • Key: UML24-74
  • Legacy Issue Number: 15399
  • Status: closed  
  • Source: NASA ( Dr. Maged Elaasar)
  • Summary:

    Since the "isUnique" and "isOrdered" properties have default values, do we need to have both 'unique'/'nonunique' and 'ordered'/'unordered' textual annotations? or do we only need ones for non-default values?

    I noticed that in some presentation option sections in the spec both annotation values are mentioned, while in other sections only one value is mentioned (diagrams in the spec also use them inconsistently):

    Superstructure:

    7.3.3 Association has 'nonunique' and 'ordered <= This seems to be the most correct
    7.3.32 MultiplicityElement has 'unique'/'nonunique' and 'ordered'/'unordered'
    7.3.36 Operation has 'unique' and 'ordered'
    7.3.44 Property have 'unique'/ 'nonunique' and 'ordered'

    Infrastructure:

    9.12.1 MultiplicityElement has 'unique'/'nonunique' and 'ordered'/'unordered'
    11.8.2 Operation has 'unique' and 'ordered'
    11.3.5 Property have 'unique' and 'ordered'

    What made me notice that is the addition of 'id' by resolution 15369, do we need to log an issue to fix this later?

  • Reported: UML 2.3 — Thu, 5 Aug 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    The inconsistency is still there as specified in the issue. The general notation is defined in MultiplicityElement.
    It does have to be repeated for Property because the syntax allows the insertion of ‘=’ <default>
    between the multiplicity and prop-modifiers, and for Operation because the <oper-property> can be intermingled
    with others. The ‘sequence’ option is present for Property but inconsistently absent for Operation.
    The <parm-property> term is currently undefined and needs to have the same options.

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

The stereotype «Create» and keyword «create» are both defined in the UML 4 document

  • Key: UML24-77
  • Legacy Issue Number: 15419
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    The stereotype «Create» and keyword «create» are both defined in the UML 4 document

    a. Figure 9.10 uses «create»

    b. Figure 9.27 uses «create»

    c. In appendix B, 2nd page, the «create» keyword is defined to apply to an operation that is a constructor, and to apply to a usage dependency, both uses of «create» appear in the Table B.1. This is consistent with items a and b above.

    d. In table C.1, both these uses are also defined as stereotypes, but with «Create». However, as stereotype matching is case insensitive, this is also consistent with items a and b above. So are the usages in a and b, keywords or stereotypes?

    e. In the last (and unlabeled) table in section C of obsolete elements, «create» is obsolete when applying to a CallEvent or Usage. How does this fit in?

    similar problems apply to several elements in table B.1 which are both stereotypes and keywords

  • Reported: UML 2.3 — Tue, 17 Aug 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    Merged with 18454

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

Figure 9.2 (Abstractions subpackage dependencies) has wrong dependency

  • Key: UML24-76
  • Legacy Issue Number: 15413
  • Status: closed  
  • Source: gmail.com ( Dmitry Semikin)
  • Summary:

    On the figure 9.2 "The Abstractions package contains several subpackages, all of which are specified in this clause" (shows all dependencies of Abstractions package subpackages)the Namespaces package do not depend on any others. But actually it depends on Ownerships package. Note: it is shown in right way in section "9.14 Namespaces Package".

    Side effect:
    Classifiers package depends (directly) on Namespaces package (which is shown in right way in chapter "9.4 Classifiers Package". And it depends on Ownerships package only indirectly (through Namespaces package). But on "Figure 9.2 - The Abstractions package contains several subpackages, all of which are specified in this clause" both dependencies are shown (which is not correct).

    To be fixed:
    on the "Figure 9.2 - The Abstractions package contains several subpackages, all of which are specified in this clause"
    1. Add dependency "Namespaces ---> Ownerships"
    2. Remove dependency "Classifiers ---> Ownerships"

  • Reported: UML 2.3 — Thu, 12 Aug 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • 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:58 GMT

"isStatic" property of Feature no longer appears in any diagram

  • Key: UML24-79
  • Legacy Issue Number: 15429
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    I noticed that the "isStatic" property of Feature no longer appears in any diagram. There may be others missing meta-attributes, but this is the one I detected. I realize that the XMI is the definitive spec of the metamodel, but, nonetheless, I think that the diagrams should be complete and not partial. Diagrams are for human readers and XMI for machines (unless, of course, you are Pete Rivett – just kidding, Pete!).

    Also, I am disappointed that you retained the practically useless notion of navigability in the metamodel, even though we now have the dot notation supported in diagrams. Given the fact that navigability is a run-time concept, I see no value in keeping it in the metamodel, which is, after all, a static definition. (But, I am pretty sure I will now be deluged with people who will try to convince me that navigability arrows are still useful (my response: no, they are not).)

    Perhaps the "isStatic" problem can be fixed as an editorial fix prior to the meeting?

  • Reported: UML 2.3 — Wed, 25 Aug 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    Show the isStatic property. In addition, this is a systematic error, and there are other cases where the metamodel has content that does not show on any diagram.

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

coveredBy : InteractionFragment [0..1] should be [*]

  • Key: UML24-78
  • Legacy Issue Number: 15427
  • Status: closed  
  • Source: NEC ( Tateki Sano)
  • Summary:

    coveredBy holds a number of MessageOccurenceSpecifications and so on. It mustn't be [0..1] but be [*].

  • Reported: UML 2.3 — Tue, 24 Aug 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • 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:58 GMT

redefinitionContext of Property

  • Key: UML24-85
  • Legacy Issue Number: 15525
  • Status: closed  
  • Source: NASA ( Dr. Maged Elaasar)
  • Summary:

    Constraint [4] in Property implies an owned end can redefine any end of any ancestor of its owning association, whether that end is association owned or not.

    However in the case of an association-owned end redefining a (non-association) classifier-owned end, whose association is an ancesor (of the owning association), the redefinitionContexts are stil:

    the owningAssociation for the redefining proeprty
    the classifier for the redefined property

    Doesn't this violate constraint [1] of RedefinableElement

    [1] At least one of the redefinition contexts of the redefining element must be a specialization of at least one of the redefinition contexts for each redefined element.
    self.redefinedElement->forAll(e | self.isRedefinitionContextValid(e))

    where

    RedefinableElement::isRedefinitionContextValid(redefined: RedefinableElement): Boolean;
    result = self.redefinitionContext->exists(c | c.allParents()->includes(redefined.redefinitionContext))

    since the classifier can never be an ancestor of the association?

  • Reported: UML 2.3 — Wed, 15 Sep 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    There was an earlier discussion in the RTF that agreed that this constraint is inconsistent with the operation
    isRedefinitionContextValid, and proposed that the operation isRedefinitionContextValid should be redefined
    for Property, to give the correct logic, which is that a property may redefine another in the inheritance
    hierarchy regardless of whether the property is association-owned or class-owned. This is the same logic as
    for subsetting.

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

Ambiguous constraints for transitions

  • Key: UML24-73
  • Legacy Issue Number: 15394
  • Status: closed  
  • Source: Safran Engineering Services ( Samuel Rochet)
  • Summary:

    Current UML specification use the two following constraints:

    15.3.8 Pseudostate (from BehaviorStateMachines)
    Constraint [9] The outgoing transition from an initial vertex may have a behavior, but not a trigger or guard
    (self.kind = PseudostateKind::initial) implies (self.outgoing.guard->isEmpty() and self.outgoing.trigger->isEmpty())

    15.3.14 Transition (from BehaviorStateMachines)
    Constraint [5] Transitions outgoing pseudostates may not have a trigger (except for those coming out of the initial pseudostate)
    (source.oclIsKindOf(Pseudostate) and (source.kind <> #initial)) implies trigger->isEmpty()

    These constraints are not really contradictory but it is not clear to know if an initial pseudostate can or cannot have a trigger.

  • Reported: UML 2.3 — Tue, 3 Aug 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    In UML 2.5 these constraints have been removed. In fact, there is now a constraint “initial_transition” that makes it
    explicit that an initial pseudostate cannot have a trigger.
    Disposition: Closed - No Change

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

Typo: isStric => isStrict

  • Key: UML24-72
  • Legacy Issue Number: 15384
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Typo in third paragraph below fig. 18.8: isStric should be isStrict

  • Reported: UML 2.3 — Wed, 28 Jul 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • 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:58 GMT

Qualified name is incorrectly claimed to be unambiguous

  • Key: UML24-75
  • Legacy Issue Number: 15401
  • Status: closed  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    The description of NamedElement claims that:

    A named element also has a qualified name that allows it to be
    unambiguously identified within a hierarchy of nested namespaces.

    However the validation rules for names within a namespace take, by default, the type into account and, for a behavioral feature, parameters. The qualified name uses only the name and thus isn't unambiguous as claimed.

  • Reported: UML 2.3 — Fri, 6 Aug 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    Merged with 15400

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

UML 2.4: Add package:URI

  • Key: UML24-68
  • Legacy Issue Number: 15370
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    This is one of two structural extensions added to UML by MOF, which if incorporated into UML would allow (constrained) Superstructure models to be used as MOF metamodels.

    Regardless of MOF, it has been requested that UML have ability to uniquely reference external elements in order to support:

    Federated models

    References to libraries of datatypes

    Profiles

    At the moment, although XMI does support such references, there is no way in the model itself, to specify the URI that should be used.

    This has been a specific problem for Profile definition where there is no standard way in UML to specify the URI to be used for XMI interchange.

    Proposed Resolution:

    Superstructure

    Add the following to the Attributes section of 7.3.77, Package:

    URI: String [0..1]

    {id} Provides an identifier for the package that can be used for many purposes. A URI is the universally unique

    identification of the package following the IETF URI specification, RFC 2396 http://www.ietf.org/rfc/rfc2396.txt and it must comply with those syntax rules.

    .

    Add the following to the end of the Semantics section of 7.3.77, Package:

    The URI can be specified to provide a unique identifier for a Package. Within UML there is no predetermined usage for this, with the exception of profiles (see Using XMI to exchange Profiles in section 18.3.6). It may, for example, be used by model management facilities for model identification. The URI should hence be unique and unchanged once assigned. There is no requirement that the URI be dereferenceable (though this is of course permitted) .



    Add the following to the end of the Notation section of 7.3.77, Package:

    The URI for a Package may be indicated with the text {uri=<uri>} following the package name.



    Update Figure 7.63 to add the following under the word Types in the middle package example:

    {uri=http://www.abc.com/models/Types}



    Update Figure 7.14 to include URI: String {id}

    in class Package

    Update subsection Using XMI to exchange profiles in section 18.3.6, Profile as follows:

    Replace:

    The Profile to CMOF mapping should also include values for CMOF Tags on the CMOF package corresponding to

    Profile in order to control the XMI generation. The exact specification of these tags is a semantic variation point. A

    recommended convention is:

    nsURI = http://<profileParentQualifiedName>/schemas/<profileName>.xmi

    where:

    • <profileParentQualifiedName> is the qualified name of the package containing the Profile (if any) with

    (dot) substituted for ::, and all other illegal XML QName characters removed, and

    • <profileName> is the name of the Profile,

    • nsPrefix = <profileName>,

    • all others use the XMI defaults.

    With:

    For a Profile the URI attribute (inherited from package) is used to determine the nsURI to be used to identify instances of the profile in XMI. The name attribute of the Profile is used for the nsPrefix in XMI.

    Infrastructure

    Add the following to the Attributes section of 11.9.2, Package:

    URI: String [0..1]

    {id} Provides an identifier for the package that can be used for many purposes. A URI is the universally unique

    identification of the package following the IETF URI specification, RFC 2396 http://www.ietf.org/rfc/rfc2396.txt and it must comply with those syntax rules.

    .

    Add the following to the end of the Semantics section of 11.9.2, Package:

    The URI can be specified to provide a unique identifier for a Package. Within UML there is no predetermined usage for this, with the exception of profiles (see Using XMI to exchange Profiles in section 18.3.6). It may, for example, be used by model management facilities for model identification. The URI should hence be unique and unchanged once assigned. There is no requirement that the URI be dereferenceable (though this is of course permitted) .



    Add the following to the end of the Notation section of 11.9.2, Package:

    The URI for a Package may be indicated with the text {uri=<uri>} following the package name.



    Update Figure 11.27 to add the following under the word Types in the middle package example:

    {uri=http://www.abc.com/models/Types}



    Update Figure 11.26 to include URI: String {id}

    in class Package

    Update subsection Using XMI to exchange profiles in section 13.1.6, Profile as follows:

    Replace:

    The Profile to CMOF mapping should also include values for CMOF Tags on the CMOF package corresponding to

    Profile in order to control the XMI generation. The exact specification of these tags is a semantic variation point. A

    recommended convention is:

    nsURI = http://<profileParentQualifiedName>/schemas/<profileName>.xmi

    where:

    • <profileParentQualifiedName> is the qualified name of the package containing the Profile (if any) with

    (dot) substituted for ::, and all other illegal XML QName characters removed, and

    • <profileName> is the name of the Profile,

    • nsPrefix = <profileName>,

    • all others use the XMI defaults.

    With:

    For a Profile the URI attribute (inherited from package) is used to determine the nsURI to be used to identify instances of the profile in XMI. The name attribute of the Profile is used for the nsPrefix in XMI.

  • Reported: UML 2.3 — Tue, 13 Jul 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    Add the proposed property.

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

UML 2.4: Add Property::isId

  • Key: UML24-67
  • Legacy Issue Number: 15369
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    This is one of two structural extensions added to UML by MOF, which if incorporated into UML would allow (constrained) Superstructure models to be used as MOF metamodels.

    Regardless of MOF, it is a fundamental capability missing from UML in being able to model various data structures for languages such as SQL and XML Schema which all have the notion of identifier.

    Although MOF restricts classes to have only one Property with isId = true, for generality the proposal does not restrict this in UML.

    Should this issue be applied to UML, a mirror issue will be applied to MOF.

    Proposed Resolution:

    Superstructure

    Add the following to the Attributes section of 7.3.44, Property:

    isID: Boolean [0..1] - True indicates this property can be used to uniquely identify an instance of the containing Class.

    Add the following to the end of the Semantics section of 7.3.44, Property, immediately before the sub-heading ‘Package AssociationClasses’:

    A property may be marked as being (part of) the identifier (if any) for classes of which it is a member. The interpretation of this is left open but this could be mapped to implementations such as primary keys for relational database tables or ID attributes in XML. If multiple properties are marked (possibly in superclasses) then it is the combination of the (property, value) tuples that will logically provide the uniqueness for any instance. Hence there is no need for any specification of order and it is possible for some (but not all) of the property values to be empty. If the property is multivalued then all values are included.

    Replace the following in the definition of <prop-modifier> in the Notation section of 7.3.44, Property:

    ‘redefines’ <property-name> | ‘ordered’ | ‘unique’ | ‘nonunique’ | <prop-constraint>

    With:

    ‘redefines’ <property-name> | ‘ordered’ | ‘unique’ | ‘nonunique’ | ‘id’ | <prop-constraint>

    Add the following line before that defining <prop-constraint>:

    · id means that the property is part of the identifier for the class

    Update Figure 7.12 to include isID : Boolean[0..1] in class Property

    Update the definition of the attribute ‘qualifiedName’ in section 7.3.33, NamedElement, from:

    / qualifiedName: String [0..1]

    To:

    / qualifiedName: String [0..1]

    {id}

    Infrastructure

    Add the following to the Attributes section of 10.2.5, Property:

    isID: Boolean [0..1] - True indicates this property can be used to uniquely identify an instance of the containing Class.

    Add the following to the end of the Semantics section of 10.2.5, Property:

    A property may be marked as being (part of) the identifier for classes of which it is a member. The interpretation of this is left open but this could be mapped to implementations such as primary keys for relational database tables or ID attributes in XML. If multiple properties are marked (possibly in superclasses) then it is the combination of the (property, value) tuples that will logically provide the uniqueness for any instance. Hence there is no need for any specification of order and it is possible for some (but not all) of the property values to be empty. If the property is multivalued then all values are included.

    Replace the following in the definition of <prop-modifier> in the Notation section of 11.3.5, Property:

    ‘redefines’ <property-name> | ‘ordered’ | ‘unique’ | <prop-constraint>

    With:

    ‘redefines’ <property-name> | ‘ordered’ | ‘unique’ | ‘id’ | <prop-constraint>

    Add the following line before that defining <prop-constraint>:

    · id means that the property is part of the identifier for the class

    Update Figures 10.3 and 11.5 to include isId : Boolean[0..1] in class Property

  • Reported: UML 2.3 — Tue, 13 Jul 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    Add the proposed property.

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

UML 2.4: Inconsistent rendering of OCL in UML metamodel

  • Key: UML24-71
  • Legacy Issue Number: 15378
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    This is a UML 2.4 issue please:

    Inconsistent rendering of OCL in UML metamodel.

    According to the conventions mostly applied in the UML metamodel, the specifications of the body conditions of operations have the form “result = <OCL expression>” and the operation is specified to have a return parameter named “result”. Invariants, pre- and post-conditions, on the other hand, are simply Boolean expressions with no “result = “. Note that many invariants are specified in OCL as “true”, being placeholders for invariants that are currently only specified in text. There are some placeholder operations, for which the specification should be “result = <default value for the type of result>”, i.e. result = false, result = 0, or result = null.

    Applying these conventions consistently will greatly enable future generation of specification documents. This means making the following changes:

    All operations in the metamodel should be changed to have a return parameter named “result”.

    The following operation and constraint specifications should be changed as indicated by changeto:

    InfrastructureLibrary::Core::Constructs::Classifier::hasVisibilityOf()

    “hasVisibilityOf = (n.visibility <> VisibilityKind::private)” changeto “result = (n.visibility <> VisibilityKind::private)”

    InfrastructureLibrary::Core::Constructs::Classifier::inheritedMember()

    “self.inheritedMember->includesAll(self.inherit(self.parents()>collect(p|p.inheritableMembers(self))>asSet()))” changeto “result = self.inherit(self.parents()>collect(p|p.inheritableMembers(self))>asSet())”

    UML::Classes::Kernel::Classifier::hasVisibilityOf()

    “hasVisibilityOf = (n.visibility <> VisibilityKind::private)” changeto “result = (n.visibility <> VisibilityKind::private)”

    UML::Classes::Kernel::Classifier::inheritedMember()

    “self.inheritedMember->includesAll(self.inherit(self.parents()>collect(p|p.inheritableMembers(self))>asSet()))” changeto “result = self.inherit(self.parents()>collect(p|p.inheritableMembers(self))>asSet())”

    UML::Classes::Kernel::OpaqueExpression::value()

    “true” changeto “result = 0”

    UML::Classes::Kernel::VisibilityKind::bestVisibility()

    “pre: not vis->includes(#protected) and not vis->includes(#package)” changeto “not vis->includes(#protected) and not vis->includes(#package)”

    UML::Deployments::ComponentDeployments::DeploymentSpecification

    “result = self.deployment->forAll (d | d.location..oclIsKindOf(ExecutionEnvironment))” changeto “self.deployment->forAll (d | d.location.oclIsKindOf(ExecutionEnvironment))”

    UML::Deployments::Nodes::CommunicationPath

    “result = self.endType->forAll (t | t.oclIsKindOf(DeploymentTarget))” changeto “self.endType->forAll (t | t.oclIsKindOf(DeploymentTarget))”

    UML::Interactions::Fragments::InteractionUse

    Two placeholder invariants specified as “N/A” –changeto- “true”

    UML::StateMachines::BehaviorStateMachines::StateMachine::LCA()

    “true” – changeto- “result = null”

  • Reported: UML 2.3 — Wed, 21 Jul 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    Agree to the changes proposed in the summary, except for OpaqueExpression::value() and StateMachine::LCA(). For these operations the result is undefined so it is incorrect to return a defined result. Instead a body of true is actually correct: it is logically equivalent to result=result.

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

Over-general sentence about MOF and Profiles

  • Key: UML24-70
  • Legacy Issue Number: 15372
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    18.3.6 Semantics contains the following untrue sentence which should be deleted

    “The profile mechanism may be used with any metamodel that is created from MOF, including UML and CWM.”

  • Reported: UML 2.3 — Tue, 13 Jul 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • 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:58 GMT

UML 2.3 Superstructure: Non-sensible text for modelLibrary stereotype

  • Key: UML24-69
  • Legacy Issue Number: 15371
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    The description for the stereotype in Annex C contains significant semantics which are not reflected anywhere else in the specification, nor as Constraints associated with the stereotype. Because this is a stereotype, not a keyword, these are not warranted.

    The full text is as follows:

    A package that contains model elements that are intended to be reused by other packages. Model libraries are frequently used in conjunction with applied profiles. This is expressed by defining a dependency between a profile and a model library package, or by defining a model library as contained in a profile package.

    The classes in a model library are not stereotypes and tagged definitions extending the metamodel. A model library is analogous to a class library in some programming languages. When a model library is defined as a part of a profile, it is imported or deleted with the application or removal of the profile. The profile is implicitly applied to its model library. In the other case, when the model library is defined as an external package imported by a profile, the profile requires that the model library be there in the model at the stage of the profile application. The application or the removal of the profile does not affect the presence of the model library elements

    Specifically the problems are:

    a) More specifics should be given for “This is expressed by for a dependency between a profile and a model library package” – such as the direction and name.

    b) Replace ‘tagged definitions’ by ‘properties’ or at least ‘tag definition’

    c) The text ‘is imported or deleted’ is vague and goes beyond anything in Profile semantics (for example does it mean a PackageImport is implicitly created?)

    d) “The profile is implicitly applied to its model library” does not make sense except in the specific case that the model library is a set of stereotyped elements, regardless of whether the model library owned by the profile: if the model library is for use within or with the profile why would it be necessary to apply stereotypes to its elements? And it goes beyond Profile semantics as well as resulting in a circular dependency between library and profile.

    e) “In the other case, when the model library is defined as an external package imported by a profile,” is inconsistent with the earlier description of ‘the other case’ which is as defined via a Dependency (not an import).

    f) “the profile requires that the model library be there in the model at the stage of the profile application” is both vague (‘be there’) and beyond profile semantics.

    Proposed resolution

    Replace the paragraph with the following:

    A package that contains model elements that are intended to be reused by other packages. Though model libraries are frequently used in conjunction with applied profiles, the classes in a model library are not stereotypes extending the metamodel. A model library is analogous to a class library in some programming languages.

  • Reported: UML 2.3 — Tue, 13 Jul 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    Accept the proposal

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

UML 2.3, Figure 18.1

  • Key: UML24-58
  • Legacy Issue Number: 15269
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    In UML 2.3, Figure 18.1 shows that InfrastructureLibrary::Profiles imports InfrastructureLibrary::Core::Constructs; however, this relationship should be a merge, not an import because:
    1) the InfrastructureLibrary::Profiles package adds merge increments to several metaclasses from Core::Constructs, e.g., Class, Package.
    2) the InfrastructureLibrary::Profiles package copies metaclasses from Core::Constructs without adding any content, e.g., NamedElement.

    Although UML merges Profiles at L2, the use of (1) and (2) requires a package merge relationship betwen Profiles & Constructs to reflect the intended semantics of merge increment for (1) and copy-down for (2).

    Resolution:

    Change the PackageImport relationship from InfrastructureLibrary::Profiles to InfrastructureLibrary::Core::Constructs to a PackageMerge relationship in:

    • figure 13.1 of the infrastructure specification
    • the infrastructure metamodel
    • figure 18.1 of the superstructure specification.
  • Reported: UML 2.3 — Thu, 27 May 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    as suggested

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

Term "method activation" deprecated?

  • Key: UML24-57
  • Legacy Issue Number: 15268
  • Status: closed  
  • Source: Technische UniversitäMü Institut füormatik I1 ( Florian Schneider)
  • Summary:

    In the section describing Lifelines, the term "method activations" is used twice, both times on page 508.

    (1) "To depict method activations we apply a thin grey or white rectangle that covers the Lifeline line."
    (2) "See Figure 14.12 to see method activations."

    Having had a look at Figure 14.12 and having read section 14.3.10 ExecutionSpecification, I believe that the term "method activation" is deprecated and should be substituted by the term "execution specification".

  • Reported: UML 2.3 — Fri, 28 May 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    Agree that "method activation" should be changed to "execution specification" in 17.3.4 and 17.3.5

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

UML 2.3 Issue: Constraint InformationFlow.sources_and_target_kinds

  • Key: UML24-66
  • Legacy Issue Number: 15356
  • Status: closed  
  • Source: NIST ( Mr. Peter Denno)
  • Summary:

    Section 17.2.1 of the superstructure document, InformationFlow

    The text of the constraint reads "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)."

    The OCL reads:
    (self.informationSource->forAll(p | p->oclIsKindOf(Actor) or oclIsKindOf(Node) or ...

    the "p->" is missing from the second term above (should be "p->oclIsKindOf(Node)") and from all subsequent terms.

  • Reported: UML 2.3 — Wed, 7 Jul 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • 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:58 GMT

NamedElement::clientDependency constrained to subset DirectedRelationship::source

  • Key: UML24-65
  • Legacy Issue Number: 15288
  • Status: closed  
  • Source: yahoo.com ( Scott Forbes)
  • Summary:

    In Figure 7.15, NamedElement::clientDependency is constrained to subset DirectedRelationship::source. Should be Dependency::client constrained, similarly Dependency::supplier should subset target.

  • Reported: UML 2.3 — Thu, 10 Jun 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • 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:58 GMT

Figure 7.10 shows Feature::isStatic as abstract

  • Key: UML24-64
  • Legacy Issue Number: 15285
  • Status: closed  
  • Source: yahoo.com ( Scott Forbes)
  • Summary:

    In Figure 7.10, Feature::isStatic is shown as an abstract attribute. Also StructuralFeature::isReadOnly and all attributes of MultiplicityElement in Figure 7.5, p27

  • Reported: UML 2.3 — Wed, 9 Jun 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • 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:58 GMT

split the addition of generalization relationships among association in 14977 in two parts

  • Key: UML24-59
  • Legacy Issue Number: 15274
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    Please create a new issue number to split the addition of generalization relationships among association in 14977 in two parts.

    Cases 2 and 3 below will remain in 14977 and the generalization relationships added for case 1 below will be moved to a resolution for this new issue number.

    This will give everyone in the RTF an opportunity to vote on the relationship between association end subsetting & association generalization separately from the fixes to the association end subsets.

  • Reported: UML 2.3 — Sat, 5 Jun 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • 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:58 GMT

It seems odd to say that Service “computes a value”.

  • Key: UML24-62
  • Legacy Issue Number: 15280
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    It seems odd to say that Service “computes a value”.

  • Reported: UML 2.3 — Tue, 6 Apr 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    Delete the offending phrase

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

Create

  • Key: UML24-61
  • Legacy Issue Number: 15279
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    I do not understand the following in Create (when applied to BehavioralFeature) “May be promoted to the Classifier containing the feature.” The same appears on Destroy

  • Reported: UML 2.3 — Tue, 6 Apr 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    Merged with 15144

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

issues relating to Figure 7.14 - The Packages diagram of the Kernel package

  • Key: UML24-63
  • Legacy Issue Number: 15283
  • Status: closed  
  • Source: Anonymous
  • Summary:

    1 A_owningPackage_packagedElement shown as directional
    2 owningPackage shown as public member of association, not declared as an association of PackageableElement (7.3.38)
    3 A_package_ownedType shown as bidirectional, but package not declared as an association of Type (7.3.51)
    4 PackageableElement::visibility:VisibilityKind default value is 'false' (7.3.38) - already submitted

  • Reported: UML 2.3 — Tue, 8 Jun 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • 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:58 GMT

Auxiliary

  • Key: UML24-60
  • Legacy Issue Number: 15278
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    "The class that the auxiliary supports may be defined explicitly using a Focus class or implicitly by a dependency relationship." - how a class be defined implicitly let alone via a Dependency? Likewise in the description of Focus

  • Reported: UML 2.3 — Tue, 6 Apr 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    Merged with 15144

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

MultiplicityElement constraint 1 inconsistent with possible [0..0] multiplicity

  • Key: UML24-130
  • Legacy Issue Number: 16595
  • Status: closed  
  • Source: gmail.com ( Joost Doesburg)
  • Summary:

    In the description of a MultiplicityElement in the superstructure, constraint 1 claims that
    'upperBound()->notEmpty() implies upperBound() > 0', while in the last paragraph of the semantics, it is declared that a multiplicity of [0..0] is possible.
    These statements are in conflict with each other.

  • Reported: UML 2.3 — Thu, 13 Oct 2011 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • 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:58 GMT

Figure 7.31 propose an “association-like” notation for attributes

  • Key: UML24-128
  • Legacy Issue Number: 15899
  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    Figure 7.31 propose an “association-like” notation for attributes:

    • clarifying whether aggregation kind can be shown
    • the notation for association end property attribute should be clearly distinct from that for a property attribute that is not an association end, even for the visually impaired.
  • Reported: UML 2.3 — Tue, 14 Dec 2010 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    Merged with 15237

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

Statement mistake

  • Key: UML24-127
  • Legacy Issue Number: 15898
  • Status: closed  
  • Source: CGI ( Wayne Li)
  • Summary:

    On page 613, the section of "Semantic", the first sentence of "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." , the "including" should be "included"

  • Reported: UML 2.3 — Mon, 13 Dec 2010 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • 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:58 GMT

Section numbering

  • Key: UML24-129
  • Legacy Issue Number: 16043
  • Status: closed  
  • Source: web.de ( Kay Weihmann)
  • Summary:

    In my opinion section 9.2 should be numbered as section 9.1.2. That would match to the rest of the numbering scheme.

  • Reported: UML 2.3 — Thu, 24 Feb 2011 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • 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:58 GMT

UML 2.4: “Figure 7.31 shows the dot at the wrong end.”

  • Key: UML24-124
  • Legacy Issue Number: 15873
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    UML 2.4: “Figure 7.31 shows the dot at the wrong end.” From: Pete Rivett pete.rivett@adaptive.com
    Sent: 14 December 2010 17:50
    To: Steve Cook
    Cc: Maged Elaasar; andrew@omg.org
    Subject: RE: New notation for attribute

    No it did not come from me: I think it was Jim or Bran or Ed (see attached).

    However attached is an updated figure I drew from scratch.

    Pete

    From: Steve Cook Steve.Cook@microsoft.com
    Sent: Tuesday, December 14, 2010 4:44 AM
    To: Pete Rivett
    Cc: Maged Elaasar; Andrew Watson (andrew@omg.org)
    Subject: RE: New notation for attribute

    Pete – I believe you made that figure. Is it possible to supply a correct one?

    From: Pete Rivett pete.rivett@adaptive.com
    Sent: 13 December 2010 20:10
    To: Ed Seidewitz; Steve Cook; Bran Selic
    Cc: BERNARD, Yves; uml2-rtf@omg.org
    Subject: RE: New notation for attribute

    I agree the diagram should be fixed as an editorial change: things are confusing enough as it is. We need to check with Andrew on the correct procedure.

    In terms of the concepts, it seems that navigability is the thing we should lose – specifically for metamodeling.

    What does it mean to say that it’s not possible (‘efficiently’) to navigate from a class to its specializations (for example)? What modeling tool would disallow a user (or OCL conditions or QVT transformations) from discovering this information?

    That’s not to say navigability has no value for other types of model. I don’t feel qualified to comment. Clearly some people like it.

    However, given the current definition of navigability and the fact that we have the dot notation (love it or hate it) for end ownership, I propose we eliminate the use of navigability from the definition of UML itself (and indeed any other metamodel) – since it’s redundant, confusing and makes no sense for metamodels. And it sets a poor example for use of navigability as a general modeling capability.

    This will make no difference at all to the XMI for model interchange – since it’s the end ownership that determines serialization. So I believe it is something we should do for UML 2.5.

    Pete

    From: Ed Seidewitz ed-s@modeldriven.com
    Sent: Monday, December 13, 2010 10:21 AM
    To: Steve Cook; Bran Selic
    Cc: BERNARD, Yves; uml2-rtf@omg.org
    Subject: RE: New notation for attribute

    Steve –

    I checked the actual resolution in Ballot 5, and the revised text actually does proposed updating the diagram with the dot in the wrong place. So the document was indeed updated properly per the resolution. However, the issue itself called for the use of the dot notation, which was simply applied incorrectly in the figure update. I am concerned that, now that the figure has been noticed, some people will start actually thinking that the “dot on the wrong end” is the right way to show an attribute using “association-like notation”, which will just cause even more confusion!

    As to getting rid of the dot notation, the was a looong discussion in the UML 2.0 FTF about the need to have both the concepts of navigability and end ownership and that these need to be separated (which they were not in UML 2.0 as originally submitted). You can talk to Conrad Bock more about the reasons for this, but unless the constituency behind this has gone away (which I don’t think it has), I don’t think we will be able to get rid of the dot notation. In the past 5 years, no one has really like this notation, but no one has come up with anything better that satisfies everyone involved!

    – Ed

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

    From: Steve Cook Steve.Cook@microsoft.com
    Sent: Monday, December 13, 2010 1:09 PM
    To: Ed Seidewitz; Bran Selic
    Cc: BERNARD, Yves; uml2-rtf@omg.org
    Subject: RE: New notation for attribute

    I’ve said it before and I will say it again: the dot notation for association end ownership is a mistake. To put it mildly. No normal user of UML cares a fig about this stupid dot. It means nothing semantically, being purely about model management, and is a step in diametrically the wrong direction, simply adding more unnecessary complexity UML.

    The fact that the RTF screwed it up in 2.4 only goes to show how non-intuitive this notation is: it gets through an RTF review and vote, despite the fact that the proposal is introduced by a UML expert and represents the simplest possible example.

    I don’t believe that this is an editorial change. I think we deserve to be embarrassed by it for a good few months. Maybe this embarrassment would convince us to get rid of the thing altogether in 2.5.

    – Steve

    From: Ed Seidewitz ed-s@modeldriven.com
    Sent: 13 December 2010 17:55
    To: Bran Selic
    Cc: BERNARD, Yves; uml2-rtf@omg.org
    Subject: RE: New notation for attribute

    Bran –

    You are right, I was looking at the UML 2.3 spec. The resolution to Issue 10087 changed Figure 7.31 “to show dot-notation”. But it looks like the dot was placed at the wrong end! I am hoping this can be considered an editorial error that can be fixed in the final clean up of the spec document (Steve, Maged??).

    In any case, I think the intention was that this notation alternative look exactly like association notation – that is, it is indeed overloaded notation, which I agree is a bad idea. But changing this would be more than an editorial change, hence the suggestion of recording this as an issue.

    – Ed

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

    From: bran.selic@gmail.com bran.selic@gmail.com On Behalf Of Bran Selic
    Sent: Monday, December 13, 2010 12:42 PM
    To: Ed Seidewitz
    Cc: BERNARD, Yves; uml2-rtf@omg.org
    Subject: Re: New notation for attribute

    ???I believe that you are saying that this is a case of an overloaded notation. If I understood you correctly, you are telling me that the line that looks like an association is not an association and that the black dot – which definitely appears on one line end in Figure 7.31 in my copy of ptc/10-08-02 (smudge on my screen?) – which looks like the notation for denoting end ownership also means something else (and, furthermore, reverses the usual convention).

    Ugh! Overloading notations is a bad idea.

    Cheers...Bran

    On Mon, Dec 13, 2010 at 12:31 PM, Ed Seidewitz <ed-s@modeldriven.com> wrote:

    Bran –

    I don’t see any black dot at all in Figure 7.31. Note that there are no association ends in Figure 7.31, since it is showing an attribute Window with no association. It just looks like an association, which is an ambiguity in the notation which should probably be fixed. Just putting a black dot on the far end would still leave the graphical notation ambiguous as to whether there was actually an association or not. Not having any association end name at the near end is not enough, since this can be suppressed even when there is an association.

    – Ed

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

    From: bran.selic@gmail.com bran.selic@gmail.com On Behalf Of Bran Selic
    Sent: Monday, December 13, 2010 12:14 PM
    To: Steve Cook
    Cc: Rouquette, Nicolas F (316A); BERNARD, Yves; uml2-rtf@omg.org

    Subject: Re: New notation for attribute

    Hmmmm. That example looks wrong to me; that is, the black dot is at the wrong end. I believe the intent of this example was to show an attribute Window::size[1] of type Area. But, according to Figure 7.19, the black dot indicating end ownership should appear on the association end that is AWAY from its owning classifier. But, the diagram in figure 7.31 has the black dot on the near association end. Do I have this wrong?

    In retrospect, we should have simply completely dispensed with the concept of navigability and retained the arrow to mean end ownership, which is what most people expect and which is actually intuitive. The black dot is not intuitive and bound to create confusion – such as the case above (regardless of whether I am right or wrong above).

    Cheers...Bran

    On Sun, Dec 12, 2010 at 6:59 AM, Steve Cook <Steve.Cook@microsoft.com> wrote:

    I believe this option is already there: see figure 7.31.

    From: Rouquette, Nicolas F (316A) nicolas.f.rouquette@jpl.nasa.gov
    Sent: 11 December 2010 11:59
    To: BERNARD, Yves
    Cc: uml2-rtf@omg.org
    Subject: Re: New notation for attribute

    Yves,

    This idea makes sense as part of the Diagram Definition for UML.

    • Nicolas.

    On Dec 10, 2010, at 4:01 AM, BERNARD, Yves wrote:

    According to several discussions I had with UML users, it appears that many of them, who have the intent to simply to add an attribute to a class, finally create an association to the type of the required attribute. In all case I faced, the reason was that they prefer the notation UML proposes for association which is much more powerful. Mainly:

    Capability to get a modular diagram thanks to the “link notation”
    Capability to show the aggregation kind

    However attributes and association are not the same and it is a pity to introduce such a drift in the semantics just because of the notation.

    What do you think about adding a notation for the attributes that would offer the capability to represent all their properties and to designate their type using a link?

  • Reported: UML 2.3 — Tue, 14 Dec 2010 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    Replace the offending diagrams.

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

UML 2: Multiplicity of Lifeline's coveredBy is incorrectly specified

  • Key: UML24-123
  • Legacy Issue Number: 15870
  • Status: closed  
  • Source: Anonymous
  • Summary:

    In the UML 2.3, UML 2.4 Superstructure spec, "14.3.17 Lifeline" section, coveredBy is
    marked with [0..1] multiplicity. In the corresponding figure in the
    beginning of the Interactions chapter it is marked *.

    coveredBy : InteractionFragment [0..1]

  • Reported: UML 2.3 — Fri, 3 Dec 2010 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • 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:58 GMT

Fix minor inconsistencies between infrastructure specification document & metamodel

  • Key: UML24-116
  • Legacy Issue Number: 15778
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    Description: To ensure that the UML2.4 metamodel is consistent with the specification document, the following inconsistencies must be resolved:

    1) NamedElement::qualifiedName()

    InfrastructureLibrary::Core::Abstractions::Namespaces::NamedElement::qualifiedName()

    ? this corresponds to 9.14.1 constraint [2] – OK

    InfrastructureLibrary::Core::Constructs::NamedElement::qualifiedName()

    ? no description of this in clause 11 for Core::Constructs – OK per current conventions that clause 11 does not duplicate the constraints/operations from the merged increments shown in 11.2

    For the superstructure:

    ? the description in super 7.3.34 constraint [2] is copied from 9.14.1 constraint [2] ? OK

    ? UML::Classes::Kernel::NamedElement::qualifiedName() is missing ? not OK per current conventionss that Kernel in the superstructure has all of the elements corresponding to the resulting merge of Core::Constructs and what it merges per infra figure 11.2

    Resolution:

    In the metamodel add qualifiedName() to UML::Classes::Kernel::NamedElement with the same definition as in InfrastructureLibrary::Core::Constructs::NamedElement::qualifiedName()

    2) DataType::inherit()

    ? No description anywhere of InfrastructureLibrary::Core::Constructs::DataType::inherit() in infra 11.6.1 or super 7.3.11

    ? UML::Classes::Kernel::DataType::inherit() is missing ? not OKK per current conventions that Kernel in the superstructure has all of the elements corresponding to the resulting merge of Core::Constructs and what it merges per infra figure 11.2

    Resolution:

    1.a) figure 11.2 is only in the document, the package merge relationships are not in the infrastructure at all.

    ? add the relationships as described in infra 11.2

    ? add a package merge relationship from Core::Constructs to Core::Abstractions::Element, which other merge increments in Core::Abstractions import.

    2) DataType::inherit()

    In the metamodel, copy InfrastructureLibrary::Core::Constructs::DataType::inherit() into UML::Classes::Kernel::DataType::inherit()

    In Infrastructure 11.6.2 and Superstructure 7.3.11, add the following section:

    Additional Operations

    [1] The inherit operation is overridden to exclude redefined properties.

    DataType::inherit(inhs: Set(NamedElement)) : Set(NamedElement);

    inherit = inhs->excluding(inh | ownedMember->select(oclIsKindOf(RedefinableElement))>select(redefinedElement>includes(inh)))

  • Reported: UML 2.3 — Mon, 25 Oct 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    The issue summary is a bit garbled, but here is a summary of what it proposes, in order to make the metamodel and specification document consistent.
    In the metamodel add qualifiedName() to UML::Classes::Kernel::NamedElement with the same definition as in InfrastructureLibrary::Core::Constructs::NamedElement::qualifiedName()
    In the metamodel change infrastructure figure 11.2 so that Constructs does not merge Basic, and instead Constructs does merge Core::Abstractions::Elements. The merge to Basic is conceptually flawed because Basic has a different and conflicting definition and semantics for Operation.
    Note that these merges remain purely conceptual – they are not explicit in the metamodel.
    In the metamodel, delete the association Core::Abstractions::BehavioralFeatures::A_parameter::behavioralFeature, because if this association was actually merged according to figure 11.2 it would be an orphaned derived union, with no subsets in the metamodel.
    In the metamodel, copy InfrastructureLibrary::Core::Constructs::DataType::inherit() into UML::Classes::Kernel::DataType::inherit()
    In Infrastructure 11.6.1 and Superstructure 7.3.11, add the following section:
    Additional Operations
    [1] The inherit operation is overridden to exclude redefined properties.
    DataType::inherit(inhs: Set(NamedElement)) : Set(NamedElement);
    inherit = inhs->excluding(inh | ownedMember->select(oclIsKindOf(RedefinableElement))>select(redefinedElement>includes(inh)))

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

Missing relation between "Namespaces" package and "Ownerships" package in fig. 9.2 (p. 30)?

  • Key: UML24-115
  • Legacy Issue Number: 15774
  • Status: closed  
  • Source: TU Darmstadt ( Martin Wieber)
  • Summary:

    Compare "Figure 9.37 - The Namespaces package" on page 71 of same document.

  • Reported: UML 2.3 — Fri, 22 Oct 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • 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:58 GMT

Deep history for orthogonal states

  • Key: UML24-120
  • Legacy Issue Number: 15791
  • Status: closed  
  • Source: asu.edu ( Joe Mooney)
  • Summary:

    "A region may have at most one deep history vertex." (pg 564)
    "A composite state may have at most one deep history vertex." (pg 557)

    This implies that only one region of a composite state may have a deep history vertex. There is no formal constraint to the effect. Please clarify.

    "deepHistory represents the most recent active configuration of the composite state that directly contains this pseudostate" (pg 557)
    This implies that all regions of a orthogonal composite state are returned to the the most recent active configuration of the composite state but...at the bottom of page 570 it asserts the other regions are entered "by default" which has a different semantic. Please clarify.

  • Reported: UML 2.3 — Mon, 1 Nov 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    The second quoted sentence is no longer there, but there is still some text that implies that history vertices
    are State based rather than Region based. These should be fixed.
    Fix all places where it is implied that history vertices belong to States rather than Regions.

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

Parameter semantics related to Behavior and BehavioralFeature

  • Key: UML24-119
  • Legacy Issue Number: 15787
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    On my first UML 2.5 efforts at consolidating the semantics of Classifiers in the merged model it becomes very obvious that Parameter has two sets of semantics: one related to the parameters of BehavioralFeatures and one related to the parameters of Behaviors.

    ParameterSet semantics talks almost exclusively about Behaviors. There is a forward reference in 12.3.13 that says “See semantics of ParameterSet”. But all 12.3.43 says is “A behavior with output parameter sets can only post outputs to the parameters in one of the sets per execution. The same is true for operations with parameter sets.” 12.3.13 also says “See notation for ParameterSet” – that is simply false, because 12.3.43 only has notation for Behaviors (well, actually Activities, because Behavior has no notation (13.3.2) but that’s the topic of a separate discussion).

    ParameterEffectKind, as well, talks exclusively about Behaviors.

    So on the face of it, the Parameter behavior related to BehavioralFeatures is distinct from the Parameter behavior related to Behaviors.

    Now, in the UML specification, there actually appear to be two separate metaclasses called Parameter. There is the one defined in Kernel, together with the one defined in Collaborations as a merge increment: the merge happens via Collaborations->InternalStructures->Interfaces->Dependencies->Kernel.

    There is a second one defined in CompleteActivities. According to the specification text, this is a specialization (it does not say merge) of the one in Kernel. However these are the merges: CompleteActivities->IntermediateActivities->BasicActivities->FundemantalActivities->BasicBehaviors->Kernel. So CompleteActivities::Parameter is also merged with the others.

    The end result is Parameter which defines both direction: ParameterDirectionKind and effect: ParameterEffectKind, that can be organized into subsets, regardless of where it is used. But there are almost no semantics and no notation specified for the Behavior-oriented features as they relate to BehavioralFeature.

    One explanation of this might that the merge is accidental, and there are supposed to be two definitions of Parameter. This is belied, however, by 12.3.13 and figure 12.18.

    Can anybody explain what this is supposed to be about? Are these meanings of Parameter really supposed to be integrated like this? What are the meanings of effect and parameterSet for Operations and Receptions? What is the relationship between direction and effect for a Parameter?

  • Reported: UML 2.3 — Wed, 27 Oct 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    In UML 2.5 it has been made clear that there is only one metaclass Parameter and its semantics are now defined in one
    place.
    Disposition: Closed - No Change

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

Property.isReadOnly is redundant with StructuralFeature.isReadOnly

  • Key: UML24-118
  • Legacy Issue Number: 15781
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    According to figure 7.12, Property.isReadOnly redefines StructuralFeature.isReadOnly. But the redefinition is not mentioned in 7.3.45.

    Both of these properties have the same name, type, multiplicity and default, so Property.isReadOnly is unnecessary.

    The resolution will be to delete Property.isReadOnly from metamodel, text and diagram.

  • Reported: UML 2.3 — Mon, 25 Oct 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    We decided to delete Property::isReadOnly and move the words used to specify it to StructuralFeature::isReadOnly.
    This will not affect interoperability.
    This also resolves 7857.

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

Part document structures in Infrastructure need to conform to ISO Standard Document Template Conventions

  • Key: UML24-122
  • Legacy Issue Number: 15822
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    UML 2.3 RTF resolved ISSUE 14277 as follows:

    Japan Superstructure PAS Ballot Comments - comment 20
    Summary:
    Part I, II, III,, IV This is a multipart standard, use of "Part I,
    II, III, IV" make confusion. Delete unnecessary Part IV and Make others
    rewrite as clauses. 7. Structure, 12 Behavior, 19 Supplement and
    renumber other clauses.
    Resolution:
    Agree to change word “Part” to “Sub Part” throughout document.

    PTC/9-9-10 , the UML 2.3 Infrastructure convenience document has the changes of the
    tem “Part” to “Subpart”, as per the resolution to ISSUE 14277 by the UML 2.3 RTF.

    However the published UML 2.3 Infrastructure reverted to the use of the term “Part”.

    Also, ISO document templates do not allow hanging text.

    The introductory text for each is not in any numbered clause.

    Proposed Resolution:

    Change term “Part” to “Subpart”, as in PTC/9-9-10.

    Change title of section 6.2 to be “How to Read this Specificaton” as in PTC/9-9-10, and
    to be consistent with Superstructure.

    Add a new section

    6.2.2 Contents of Subparts

    6.2.2.1 Contents of Subpart I ­ Introduction

    <move the hanging intro from Part I into this subclause, with minor edits to fix pointers
    to sections>

    6.2.2.2 Contents of Subpart II ­ Infrastructure Library

    <move the hanging intro from Part II into this subclause, with minor edits to fix pointers
    to sections>

    6.2.2.3 Contents of Subpart III - Annexes

    <move the hanging intro from Part II into this subclause,>

  • Reported: UML 2.3 — Mon, 22 Nov 2010 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • 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:58 GMT

Big UML 2.4 problem: missing defaults in XMI

  • Key: UML24-121
  • Legacy Issue Number: 15804
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    This came up in the MIWG testing (though that was for UML 2.2)

    There seem to be several cases where the specification has defaults that are not represented in the XMI.

    Examples of this are as follows:

    ActivityEdge::guard : ValueSpecification [1..1] = true

    ActivityEdge::weight : ValueSpecification [1..1] = 1

    ObjectNode::upperBound : ValueSpecification [1..1] = *

    They all seem to be ValueSpecifications so I’m sure there are others.

    BTW these are all listed under Attributes of the metaclass whereas they are in fact modeled as Associations with ValueSpecification. So should they not be placed into the Associations section? Something to look at for 2.5 I guess.

  • Reported: UML 2.3 — Mon, 1 Nov 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • 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:58 GMT

Operation with multiple return parameter

  • Key: UML24-114
  • Legacy Issue Number: 15769
  • Status: closed  
  • Source: NASA ( Dr. Maged Elaasar)
  • Summary:

    We are talking about an operation declared in the UML metamodel, so

    Operation::returnResult() : Parameter [0..1]

    is definitely valid UML notation.

    while

    Operation::returnResult() : Set(Parameter)

    which is the way it is now in spec is definitely not valid UML notation, it is supposed to be:

    Operation::returnResult() : Parameter [*]

    In both cases, the way OCL interprets the result of such opertion is similar to how it interprets any value, as a collection, and as such collection operations can be called on it.

    Therefore, to be consistent, this operation should be changed have a simple "Parameter" as a return type.

    However, if we are going to leave this operation with * multiplicity to be more robust or OCL friendly, then at least we should be consistent in those other cases, where we have singular return result.

    OperationHasSingularReturnResult : 16
    operation = <Operation> UML::Vertex::containingStateMachine () : StateMachine
    operation = <Operation> UML::Transition::redefinitionContext () : Classifier
    operation = <Operation> UML::Transition::containingStateMachine () : StateMachine
    operation = <Operation> UML::Stereotype::profile () : Profile
    operation = <Operation> UML::Stereotype::containingProfile () : Profile
    operation = <Operation> UML::StateMachine::LCA (s1 : State, s2 : State) : Namespace
    operation = <Operation> UML::State::redefinitionContext () : Classifier
    operation = <Operation> UML::State::containingStateMachine () : StateMachine
    operation = <Operation> UML::Region::redefinitionContext () : Classifier
    operation = <Operation> UML::Region::containingStateMachine () : StateMachine
    operation = <Operation> UML::Property::opposite () : Property
    operation = <Operation> UML::Package::containingProfile () : Profile [0..1]
    operation = <Operation> UML::Operation::type () : Type
    operation = <Operation> UML::LinkAction::association () : Association
    operation = <Operation> UML::Extension::metaclassEnd () : Property
    operation = <Operation> UML::Extension::metaclass () : Class

  • Reported: UML 2.3 — Fri, 15 Oct 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    The issue is obsolete. The generated Operation descriptions are now correct.
    Disposition: Closed - No Change

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

Wrong constraint on Operation::bodyCondition

  • Key: UML24-113
  • Legacy Issue Number: 15768
  • Status: closed  
  • Source: NASA ( Dr. Maged Elaasar)
  • Summary:

    The spec says:

    bodyCondition: Constraint[0..1]
    An optional Constraint on the result values of an invocation of this Operation. Subsets Namespace::ownedRule

    couple this with:

    The bodyCondition for an operation constrains the return result. The bodyCondition differs from postconditions in that
    the bodyCondition may be overridden when an operation is redefined, whereas postconditions can only be added during
    redefinition.

    Also, in the current MM, the defined operations logic is implemented as a body Condition.

    Therefore, the bodyCondition is not an invariant, but rather a condition that describes the return result. of an operation

    Since a non-query operation can also have a return result, I see no reason to prevent a body condition on it.

  • Reported: UML 2.3 — Fri, 15 Oct 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    Merged with 15501

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

Be explicit that type does not need to be set for LiteralBoolean etc.

  • Key: UML24-117
  • Legacy Issue Number: 15779
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    Today we are inconsistent in the metamodel about whether the type of a LiteralBoolean value is set or not. Some are; most are not, and there is no guidance in the spec about which is correct. Since the type is completely obvious, we can be explicit about this:

    LiteralBoolean

    Constraints:

    [1] Since the type of a LiteralBoolean is by definition a Boolean, it would be redundant to specify the type explicitly.

    type->isEmpty()

    LiteralInteger

    Constraints:

    [1] Since the type of a LiteralInteger is by definition an Integer, it would be redundant to specify the type explicitly.

    type->isEmpty()

    LiteralReal

    Constraints:

    [1] Since the type of a LiteralReal is by definition a Real, it would be redundant to specify the type explicitly.

    type->isEmpty()

    LiteralString

    Constraints:

    [1] Since the type of a LiteralString is by definition a String, it would be redundant to specify the type explicitly.

    type->isEmpty()

    LiteralUnlimitedNatural

    Constraints:

    [1] Since the type of a LiteralUnlimitedNatural is by definition an UnlimitedNatural, it would be redundant to specify the type explicitly.

    type->isEmpty()

  • Reported: UML 2.3 — Mon, 25 Oct 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    After discussion the RTF resolved that making changes of this kind to the spec is too controversial. Instead, we simply go through the metamodel making sure that all instances of subtypes of LiteralSpecification have their type set to null, in order to make the metamodel consistent.

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

Constraint is Wrong

  • Key: UML24-126
  • Legacy Issue Number: 15881
  • Status: closed  
  • Source: motorola ( bruce lu)
  • Summary:

    In the first item of the 'Constraints' clause,
    (self.name->isEmpty() or self.allNamespaces()>select(ns | ns.name>isEmpty())->notEmpty())
    implies self.qualifiedName->isEmpty()

    should be
    self.name->isEmpty() or (self.allNamespaces()>select(ns | ns.name>isEmpty())->notEmpty())
    implies self.qualifiedName->isEmpty()

  • Reported: UML 2.3 — Wed, 8 Dec 2010 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • 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:58 GMT

Wrong Classifier Name

  • Key: UML24-125
  • Legacy Issue Number: 15880
  • Status: closed  
  • Source: NSN ( bruce lu)
  • Summary:

    In the 'Associations' clause of section 9.10.3, the last association 'value : InstanceSpecification [*]' is wrong. It should be 'value : ValueSpecification [*]

  • Reported: UML 2.3 — Tue, 7 Dec 2010 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • 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:58 GMT

UML2 - Invalid constraint for Actor

  • Key: UML24-49
  • Legacy Issue Number: 15162
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    16.3.1 Actor says: [1] An actor can only have associations to use cases, components, and classes. Furthermore these associations must be binary. self.ownedAttribute->forAll ( a | (a.association->notEmpty()) implies ((a.association.memberEnd.size() = 2) and (a.opposite.class.oclIsKindOf(UseCase) or (a.opposite.class.oclIsKindOf(Class) and not a.opposite.class.oclIsKindOf(Behavior))))

    But an Actor does not have any ownedAttribute property, so this constraint is invalid.

  • Reported: UML 2.3 — Wed, 7 Apr 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    Merged with 10780

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

Detailed modeling of the Standard Profiles

  • Key: UML24-48
  • Legacy Issue Number: 15144
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    I was reading through the descriptions of the Standard Stereotypes and noticed some oddities, and some aspects that should be explicitly modeled now we are creating normative definitions thereof.

    Overall this exercise has illustrated to me that the tabular approach for defining them is utterly inadequate and we should use one or more profile diagrams. Rather than having the explicit modeling only in the XMI

    BTW it seems to me that the 2nd 'Language Unit' column of the table in Annex C is misleading and pointless so should be deleted: the Stereotypes do not have a language unit. Not even the extended metaclasses have one, once merged into their L2 or L3 metamodel.

    Also if it's not too much hassle it would be handy to include the descriptions from Annex C in the XMI Stereotype definitions.

    If for no other reason these need to be updated to reference other stereotypes using their upper case name.

    The following are points where explicit modeling is called for; I also raise some questions about the descriptions which may need to be raised as issues:

    1. I'm a bit baffled by the following from Auxiliary: "The class that the auxiliary supports may be defined explicitly using a Focus class or implicitly by a dependency relationship." - how a class be defined implicitly let alone via a Dependency? Likewise in the description of Focus

    2. We should model a Constraint that the client and supplier of Dependencies stereotyped by Call must both be Operations. The description should use client and supplier not source and target

    3. Likewise for Create (when applied to Dependencies) they must both be Classifiers.

    4. There are 2 rows for Create – I presume this is one Stereotype that extends 2 metaclasses.

    5. I do not understand the following in Create (when applied to BehavioralFeature) “May be promoted to the Classifier containing the feature.” The same appears on Destroy

    6. The Derive stereotype should have a computation Property to ‘specify the computation’. I suggest this should be of type OpaqueExpression?

    7. The description of Implement is a bit unclear - does it imply that the stereotype itself has a Dependency property? Or should we model a Constraint that the base_Component must be the client of a Dependency?

    8. We should model that Document is a subclass of File. And, I guess, the Constraint that an element with Document applied cannot also have Source and Executable applied (what about Script and Library though?). Is File abstract as implied by the description?

    9. Executable is a subclass of File. And I guess it should have the same constraint?

    10. Library is a subclass of File

    11. ModelLibrary needs to be cleaned up - I will raise a separate issue

    12. Description of Process seems a bit lacking

    13. It seems Realization and ImplementationClass cannot both be applied to the same element?

    14. Script is a subclass of File.

    15. Send should have constraint that the client and supplier of Dependencies to which it is applied are instances of Operation and Signal respectively. The description should use client and supplier not source and target

    16. It seems odd to say that Service “computes a value”.

    17. Source is a subclass of File.

    18. It seems Specification and Type cannot both be applied to the same element?

    19. The description of Utility “A class that has no instances, but rather denotes a named collection of non-member attributes and operations, all of which are class-scoped” – not sure what it means by ‘non-member’, but this seems to imply a constraint on the features of the Class to which it is applied. And I guess a Constraint that the Class must also be abstract (it has no instances).

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

    This is quite a lot of things in one issue, most of which have already been resolved by explicitly modeling
    the profile. Some of the points suggest adding constraints to stereotypes, which I propose not to resolve
    here but instead to submit a new issue to capture the proposal. Some of the points require rewording for
    clarification, and the current resolution does this.
    The point about Derive is incorrect: Abstraction already has a mapping in the model.
    I am averse to copying the definitions into the metamodel because it will introduce redundancy and run the
    risk of future inconsistency.
    This also resolves 15278 and 15279.

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

UML 2 issue - misleadingly named associations

  • Key: UML24-52
  • Legacy Issue Number: 15263
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    The association between Package and Stereotype called “A_ownedStereotype_profile” is misleadingly named. It should be called “A_ownedStereotype_package”.

    The association between BehavioredClassifier and Behavior called “A_ownedParameter_behavioredClassifier” is misleadingly named. It should be called “A_ownedBehavior_behavioredClassifier”.

  • Reported: UML 2.3 — Tue, 25 May 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    Make the changes as suggested.

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

Meaning of BodyCondition and its alignment with OCL

  • Key: UML24-51
  • Legacy Issue Number: 15259
  • Status: closed  
  • Source: NASA ( Dr. Maged Elaasar)
  • Summary:

    The UML superstructure allows an Operation to have:

    bodyCondition: Constraint[0..1] : An optional Constraint on the result values of an invocation of this Operation. Subsets Namespace::ownedRule

    Since bodyCondition is of type Constraint, its expression must be boolean according to clause 7.3.10 (Constraint):

    [1] The value specification for a constraint must evaluate to a Boolean value.

    Now, the OCL spec states in 7.3.6 that an operation body expression has the form:

    context Typename::operationName(param1 : Type1, ... ): ReturnType
    body: – some expression

    and gives an example:

    context Person::getCurrentSpouse() : Person
    pre: self.isMarried = true
    body: self.mariages->select( m | m.ended = false ).spouse

    Notice that in this example, the expression is NOT boolean, therefore if "self.mariages->select( m | m.ended = false ).spouse" was used as an expression in the bodyCondition, it would not be valid.

    Am I missing something?

    in RSA, we got around this by requiring the expression to be of the format:

    context Typename::operationName(param1 : Type1, ... ): ReturnType
    body: result = some expression

    Is the keyword "result" legal in the expression of bodyCondition?

  • Reported: UML 2.3 — Wed, 19 May 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    OCL body expressions and UML bodyConditions are inconsistently specified. For the UML spec, the
    bodyConditions need to be Boolean. The way we do this is by naming the result parameter of all of the
    operations as “result”. Then the body expressions should be of the form “result = <expression>”.
    Unfortunately, doing this in RSA causes type errors because RSA gives a well-typed expression its internal
    Boolean type which is not the same type as the UML 2.5 PrimitiveType Boolean.
    So in order to keep RSA as happy as possible, and reduce error-prone work, we’ll keep the body expressions
    in the metamodel in the OCL-like form (without the “result =”) and cause the XMI generation process to
    wrap result = (. . . ) around all of the body expressions.
    This also resolves 13258.

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

Resolution to issue 14063

  • Key: UML24-53
  • Legacy Issue Number: 15264
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    Accepted resolution in UML 2.4 Ballot 8 for issue 14063 has a problem because ActivityGroup::inActivity needs to refer to StructuredActivities::Activity

  • Reported: UML 2.3 — Tue, 25 May 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    The accepted resolution for 14063 in Ballot 8 states the following:
    “In the UML 2.3 Superstructure Specification, Subclause 12.2 Abstract Syntax, in Figures 12.21 and 12.22, replace the unqualified ActivityGroup classes on the diagrams with the qualified UML::Activities::FundamentalActivities::ActivityGroup class. Remove the StructuredActivities::ActivityGroup and CompleteStructuredActivities::ActivityGroup classes from the metamodel.”
    The problem is that ActivityGroup in StructuredActivities refers, via its property inActivity, to Activity in StructuredActivities. Removing StructuredActivities::ActivityGroup deprives this property of a home. Hence we need to reinstate the copies of ActivityGroup.
    Then we also need to copy down Action into CompleteStructuredActivities, and its associations input and output, so that the structuredNodeInput

    {subsets input}

    and structuredNodeOutput

    { subsets output}

    work correctly, i.e. subset the correct types of InputPin and OutputPin.
    Note than none of this will have any effect on the merged definition of UML.

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

Issue 14287 and 13330 resolutions are inconsistent and incorrectly applied.

  • Key: UML24-55
  • Legacy Issue Number: 15266
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    13330, resolved in UML 2.3, was not correctly applied to the specification diagrams. The following instructions were not carried out:

    Show the association name label in Figure 17.18

    Show the association name label in Figure 17.29

    Show the association name label in Figure 17.30

    Perhaps as a consequence of this, 14287 in 2.4 should have been resolved as a dup of 13330, not as an inconsistent set of changes.

  • Reported: UML 2.3 — Wed, 26 May 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    Do not make the changes to association names as proposed in 13287. Instead, leave the names as resolved in 13330 and in the UML 2.3 metamodel.
    Show the names in the diagrams as specified by 13330.

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

UML 2 Subclasses of Classifier should subset redefinedClassifier when they redefine

  • Key: UML24-54
  • Legacy Issue Number: 15265
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    UML 2 Subclasses of Classifier should subset redefinedClassifier when they redefine. In particular, Behavior::redefinedBehavior should subset Classifier::redefinedClassifier, not Element::redefinedElement; and StateMachine::extendedStateMachine should subset Classifier::redefinedClassifier, not Element::redefinedElement. These are exactly analogous to the problem raised in issue 14554.

  • Reported: UML 2.3 — Tue, 25 May 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    Make the suggested changes.

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

MessageEvents

  • Key: UML24-47
  • Legacy Issue Number: 15136
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    Could you guys shed some light in this area?
    Every tool vendor has different ideas (and implementation) what event types should be used at message ends for call message, reply message, create message or destroy message.

  • Reported: UML 2.3 — Tue, 9 Mar 2010 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    See issue 14629 for disposition

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

Association owned derived union

  • Key: UML24-46
  • Legacy Issue Number: 15128
  • Status: closed  
  • Source: NASA ( Dr. Maged Elaasar)
  • Summary:

    Is it really illegal to define a non-navigable association-owned property as derived union?

    When I try that I invalidate the following constraint in section 7.3.44 the metamodel:

    [6]Only a navigable property can be marked as readOnly.
    isReadOnly implies isNavigable()

    Why "efficiency of access" (as implied by navigability) restrics read-only access?

    One way to get around that is to make the property owned in the "navigableOwnerEnd" vs. "ownedEnd" of the association? do we have any precedence of doing that in an abstract syntax?

  • Reported: UML 2.3 — Mon, 22 Mar 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    This constraint seems to be an old constraint from UML 1.x when navigability meant the same as ownership of property. It is not consistent with the meaning of navigability now, which is about “efficiency of access”.

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

composite tags

  • Key: UML24-50
  • Legacy Issue Number: 15167
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    Are composite tag definitions allowed?

  • Reported: UML 2.3 — Tue, 6 Apr 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    A Stereotype is a kind of Class and the semantics of a Property defined on a Stereotype is the same as
    that of a Property defined on a Class. Therefore, a Stereotype Property can have composite aggregation.
    The value of a composite Stereotype Property will be owned by an instance of such Stereotype. The type
    of such Property cannot be a Stereotype (since Stereotypes are owned by their Extensions) or a metaclass
    (since instances of metaclasses are owned by other instantances of metaclasses); however, the type of such
    Property can be a Class defined in the Profile or a DataType defined in the Profile or accessible via import
    or via the Profile’s metamodel reference.

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

UML2 Issue: OCL in resolution 11114 is incorrect

  • Key: UML24-56
  • Legacy Issue Number: 15267
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    The OCL is the resolution is:

    self.inheritedMember->includesAll(self.inherit(self.parents()->collect(p | p.inheritableMembers(self)))

    It has two problems:

    1- It is missing a closing ")" needed to balance the brackets, correcting this yields

    self.inheritedMember->includesAll(self.inherit(self.parents()->collect(p | p.inheritableMembers(self))))

    2- the "collect" operation above returns a Bag, and since "inherit" operation expects a Set as input, the cast "toSet()" is needed, correcting this yields:

    self.inheritedMember->includesAll(self.inherit( self.parents()>collect(p | p.inheritableMembers(self))>asSet() ))

  • Reported: UML 2.3 — Wed, 26 May 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    As the summary says

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

UML2.3 definition of Classifier::hasVisibilityOf is circular

  • Key: UML24-45
  • Legacy Issue Number: 15126
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    If we consider class A inherits from class B, and we have an instance of A called a, and a property in B called p. Let’s calculate the visibility of p in a, assuming p is private. I’m doing substitutions, a bit loosely, but you’ll get the point.

    a::hasVisibilityOf(p) : Boolean if (a.inheritedMember->includes(p)) then hasVisibilityOf = false else hasVisibilityOf = true

    -> we need to calculate a.inheritedMember

    a.inheritedMember->includesAll(a.inherit(

    {B.inheritableMembers(a) }

    ))

    -> we need to calculate B.inheritableMembers(a)

    B.inheritableMembers(a) =

    {p}

    ->select(m | a.hasVisibilityOf(m)) …. a.hasVisibilityOf(p)

    -> we are in a loop!

  • Reported: UML 2.3 — Wed, 10 Mar 2010 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    See issue 10006 for disposition

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

UML2.3: Missing subsetting from A_redefinedClassifier_classifier in XMI

  • Key: UML24-44
  • Legacy Issue Number: 15125
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    The XMI for A_redefinitionContext_redefinableElement is this:

    <ownedMember xmi:type="cmof:Association" xmi:id="Classes-Kernel-A_redefinedClassifier_classifier" name="A_redefinedClassifier_classifier" memberEnd="Classes-Kernel-Classifier-redefinedClassifier Classes-Kernel-A_redefinedClassifier_classifier-classifier">
    <ownedEnd xmi:type="cmof:Property" xmi:id="Classes-Kernel-A_redefinedClassifier_classifier-classifier" name="classifier" type="Classes-Kernel-Classifier" upper="*" lower="0" owningAssociation="Classes-Kernel-A_redefinedClassifier_classifier" association="Classes-Kernel-A_redefinedClassifier_classifier"/>
    </ownedMember>

    In the spec, classifier is shown as

    {subsets redefinitionContext}

    . This is missing from the XMI.

  • Reported: UML 2.3 — Wed, 10 Mar 2010 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    See issue 14977 for disposition

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

loopVariable ownership

  • Key: UML24-29
  • Legacy Issue Number: 14962
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    Specification: OMG UML Superstructure, Version 2.3 (ptc/2009-09-09)

    Subclause: 12.3.35 LoopNode

    The loopVariables of a LoopNode are OutputNodes, but they are not part of the outputs of the LoopNode. Therefore, they need to be independently owned by the LoopNode.

    The propery LoopNode::loopVariable should subset Element::ownedElement, and the association should be shown as composite on Figure 12.22. Otherwise the mustBeOwned constraint will be violated for loopVariables.

  • Reported: UML 2.3 — Tue, 12 Jan 2010 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    This issue is obsolete. loopVariables are owned by LoopNodes in UML 2.5.
    Disposition: Closed - No Change

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

Association conflicts with MemberEnds IsDerived flags

  • Key: UML24-95
  • Legacy Issue Number: 15566
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    UML::CompositeStructures::InternalStructures::A_feature_featuringClassifier

    UML::Activities::FundamentalActivities::A_subgroup_superGroup

    UML::Activities::FundamentalActivities::A_containedNode_inGroup

    UML::Activities::CompleteStructuredActivities::A_containedEdge_inGroup

    UML::Activities::StructuredActivities::A_containedNode_inGroup

    UML::Activities::CompleteActivities::A_containedNode_inGroup

    UML::Activities::IntermediateActivities::A_subgroup_superGroup

    UML::Activities::IntermediateActivities::A_containedEdge_inGroup

    UML::Activities::IntermediateActivities::A_containedNode_inGroup

    InfrastructureLibrary::Core::Abstractions::Constraints::A_ownedMember_namespace

    InfrastructureLibrary::Core::Abstractions::Classifiers::A_feature_featuringClassifier

    InfrastructureLibrary::Core::Abstractions::Namespaces::A_ownedMember_namespace

    InfrastructureLibrary::Core::Abstractions::Ownerships::A_ownedElement_owner

  • Reported: UML 2.3 — Wed, 22 Sep 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    These are associations with both ends derived. There is a MOF constraint: An Association is derived if all its Properties are derived. Hence all of these associations should be marked as derived. In addition, there is currently inconsistency elsewhere in the metamodel about which associations should be marked as derived. For example, A_redefinitionContext_region, with derived=false, and A_redefinitionContext_state, with derived=true. These are obviously inconsistent.
    In order to correct this we?ll apply the following additional constraint:
    ? An association in which all navigable (class-owned) ends are derived is derived
    The reasoning behind this is as follows.
    If you take the meaning of an association to be a set of links, and the meaning of an association end to be a set of instances of the type at the end of the association, then “derived” means that these sets can be calculated from other information. The other ingredient is whether the set can be altered “by hand”, as it were: and I am assuming that non-navigable ends cannot be altered by hand, i.e. they do not correspond to a settable API on a class. I don?t believe there is anything formal to substantiate this assumption, but it seems to be current practice for the metamodel to be constructed according to it. In this sense, all non-navigable ends are “derived”, whether you say so or not.
    The following are violations of this additional constraint:
    InfrastructureLibrary::Core::Abstractions::BehavioralFeatures::A_parameter_behavioralFeature
    InfrastructureLibrary::Core::Abstractions::Constraints::A_member_memberNamespace
    InfrastructureLibrary::Core::Abstractions::Generalizations::A_general_classifier
    InfrastructureLibrary::Core::Abstractions::Namespaces::A_member_memberNamespace
    InfrastructureLibrary::Core::Abstractions::Redefinitions::A_redefinedElement_redefinableElement
    InfrastructureLibrary::Core::Abstractions::Redefinitions::A_redefinitionContext_redefinableElement
    InfrastructureLibrary::Core::Abstractions::Relationships::A_relatedElement_relationship
    InfrastructureLibrary::Core::Abstractions::Relationships::A_source_directedRelationship
    InfrastructureLibrary::Core::Abstractions::Relationships::A_target_directedRelationship
    InfrastructureLibrary::Core::Abstractions::Super::A_inheritedMember_classifier
    InfrastructureLibrary::Core::Constructs::A_attribute_classifier
    InfrastructureLibrary::Core::Constructs::A_endType_association
    InfrastructureLibrary::Core::Constructs::A_importedMember_namespace
    InfrastructureLibrary::Core::Constructs::A_inheritedMember_classifier
    InfrastructureLibrary::Core::Constructs::A_member_memberNamespace
    InfrastructureLibrary::Core::Constructs::A_opposite_property
    InfrastructureLibrary::Core::Constructs::A_parameter_behavioralFeature
    InfrastructureLibrary::Core::Constructs::A_redefinedElement_redefinableElement
    InfrastructureLibrary::Core::Constructs::A_redefinitionContext_redefinableElement
    InfrastructureLibrary::Core::Constructs::A_relatedElement_relationship
    InfrastructureLibrary::Core::Constructs::A_source_directedRelationship InfrastructureLibrary::Core::Constructs::A_target_directedRelationship
    InfrastructureLibrary::Core::Constructs::A_type_operation
    InfrastructureLibrary::Profiles::A_ownedStereotype_owningPackage
    InfrastructureLibrary::Profiles::A_profile_stereotype
    UML::Actions::BasicActions::A_input_action
    UML::Actions::BasicActions::A_output_action
    UML::Activities::CompleteStructuredActivities::A_input_action
    UML::Activities::CompleteStructuredActivities::A_output_action
    UML::AuxiliaryConstructs::Templates::A_inheritedParameter_redefinableTemplateSignature
    UML::AuxiliaryConstructs::Templates::A_redefinitionContext_redefinableElement
    UML::Classes::Interfaces::A_attribute_classifier
    UML::Classes::Kernel::A_attribute_classifier
    UML::Classes::Kernel::A_classifier_enumerationLiteral
    UML::Classes::Kernel::A_endType_association
    UML::Classes::Kernel::A_general_classifier
    UML::Classes::Kernel::A_importedMember_namespace
    UML::Classes::Kernel::A_inheritedMember_classifier
    UML::Classes::Kernel::A_member_memberNamespace
    UML::Classes::Kernel::A_opposite_property
    UML::Classes::Kernel::A_parameter_behavioralFeature
    UML::Classes::Kernel::A_redefinedElement_redefinableElement
    UML::Classes::Kernel::A_redefinitionContext_redefinableElement
    UML::Classes::Kernel::A_relatedElement_relationship
    UML::Classes::Kernel::A_source_directedRelationship
    UML::Classes::Kernel::A_superClass_class
    UML::Classes::Kernel::A_target_directedRelationship
    UML::Classes::Kernel::A_type_operation
    UML::CommonBehaviors::BasicBehaviors::A_context_behavior
    UML::CommonBehaviors::BasicBehaviors::A_result_opaqueExpression
    UML::Components::BasicComponents::A_provided_component
    UML::Components::BasicComponents::A_required_component
    UML::CompositeStructures::InternalStructures::A_attribute_classifier
    UML::CompositeStructures::InternalStructures::A_definingEnd_connectorEnd
    UML::CompositeStructures::InternalStructures::A_part_structuredClassifier
    UML::CompositeStructures::InternalStructures::A_role_structuredClassifier
    UML::CompositeStructures::Ports::A_ownedPort_encapsulatedClassifier
    UML::CompositeStructures::Ports::A_provided_port
    UML::CompositeStructures::Ports::A_required_port
    UML::StateMachines::BehaviorStateMachines::A_redefinitionContext_region
    UML::StateMachines::BehaviorStateMachines::A_redefinitionContext_transition
    UML::StateMachines::ProtocolStateMachines::A_referred_protocolTransition

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

Fix association end multiplicities

  • Key: UML24-94
  • Legacy Issue Number: 15565
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    InfrastructureLibrary::Profiles::A_metamodelReference_profile::profile from [1] to [0..1]

    InfrastructureLibrary::Profiles::A_metaclassReference_profile::profile from [1] to [0..1]

    CompleteStructuredActivities::A_structuredNodeInput_structuredActivityNode::structuredActivityNode from [1] to [0..1]

    CompleteStructuredActivities::A_structuredNodeOutput_structuredActivityNode::structuredActivityNode from [1] to [0..1]

  • Reported: UML 2.3 — Wed, 22 Sep 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    The first change is needed because otherwise a PackageImport and an ElementImport must be owned by a profile, which is bad.
    The second change is needed because otherwise InputPins and OutputPins must be the inputs and outputs of StructuredActivityNode (fig 12.22), which is also bad.

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

Multiplicity Element Is MultiValued With Default Value

  • Key: UML24-98
  • Legacy Issue Number: 15569
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    This applies to DurationObservation::firstEvent[0..2] default = true, and DurationConstraint::firstEvent[0..2], defaultValue = true. This conflicts with CMOF constraint [9] Multivalued properties cannot have defaults, and is also meaningless because firstEvent size is constrained to be 0 or 2.

  • Reported: UML 2.3 — Wed, 22 Sep 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    Remove the default as it violates a CMOF constraint

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

Derived properties that are not marked read-only

  • Key: UML24-97
  • Legacy Issue Number: 15568
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    Although there is a case in general modeling that derived properties need not be read-only, we should apply a convention in the UML metamodel that derived properties are read-only. There are 24 exceptions to this convention.

  • Reported: UML 2.3 — Wed, 22 Sep 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    Here is the list of properties that are derived but not readonly. In the absence of compelling arguments why each should not be made readonly, we should make it readonly. This will make the metamodel more systematic and consistent.
    Vertex::outgoing
    Vertex::incoming
    Stereotype::profile (Infra fig 12.2, Super fig 18.2)
    Property::opposite (Super fig 7.12)
    Property::isComposite (Super fig 7.12)
    Property::default (Super fig 7.12)
    Parameter::default (Super fig 7.11)
    Package::ownedType (Infra fig 11.26, Super fig 7.14)
    Package::ownedStereotype (Infra fig 12.2, Super fig 18.2)
    Package::nestedPackage (Infra fig 11.26, Super fig 7.14)
    Operation::upper (Super fig 7.11)
    Operation::type (Super fig 7.11)
    Operation::lower (Super fig 7.11)
    Operation::isUnique (Super fig 7.11)
    Operation::isOrdered (Super fig 7.11)
    MultiplicityElement::upper
    MultiplicityElement::lower
    EnumerationLiteral::classifier (Super fig 7.13)
    EncapsulatedClassifier::ownedPort
    Connector::kind (Super fig 8.3)
    ConnectableElement::end (Super fig 8.3)
    Classifier::general
    Class::superClass (Super fig 7.12)
    ExtensionEnd::lower However we cannot make all of these properties read-only, because some of them are defined as non-derived in infrastructure. Because the merge rules are such that writeable overrides read-only, in order to make them read-only in the merged model, we.d have to make them read-only even when they are non-derived in Infrastructure, which would make no sense.
    Another reason not to make them all readonly is the following paragraph in Superstructure 2.3:
    ¡°Thus, it is not meaningful to claim compliance to, say, Level 2 without also being compliant with the Level 0 and Level 1. A tool that is compliant at a given level must be able to import models from tools that are compliant to lower levels without loss of information.¡±
    This implies that properties writable at L0 should be writeable at L3.
    The properties affected by this are:
    Property::opposite
    Property::isComposite
    Property::default
    Parameter::default
    Package::ownedType
    Package::nestedPackage
    MultiplicityElement::upper
    MultiplicityElement::lower
    Classifier::general
    Class::superClass
    We are allowed by the notation not to show

    {readOnly} on the diagrams. We will show {readOnly}

    on some diagrams because (a) we are changing these diagrams for other reasons and (b) the tool enforces an ¡°all or nothing¡± rule on which decorations we show for attributes. Our current convention is not to show readOnly in the specification text (with one exception), so we.ll carry on with the convention.

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

Message's signature is still derived property (in text only):

  • Key: UML24-89
  • Legacy Issue Number: 15560
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    /signature:NamedElement[0..1] The signature of the Message is the specification of its content. It refers either an Operation or a Signal.

  • Reported: UML 2.3 — Wed, 22 Sep 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    This is as a result of an incomplete application of resolution 14629, which was formulated slightly ambiguously.

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

UML 2 issue: UML 2.4 normative deliverables should be published in MOF2.4 / XMI 2.4 format

  • Key: UML24-88
  • Legacy Issue Number: 15530
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    UML 2.4 normative deliverables should be published in MOF2.4 / XMI 2.4 format.

  • Reported: UML 2.3 — Thu, 16 Sep 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    Remove all of the cmof files from the published set of artifacts for UML 2.4. Instead, publish the following normative artifacts in MOF2.4/XMI2.4 format:
    Infrastructure.xmi
    Superstructure.xmi
    L0.xmi
    L1.xmi
    L2.xmi
    L3.xmi
    LM.xmi
    PrimitiveTypes.xmi
    UML.xmi (the merged L3 model)
    StandardProfileL2.xmi
    StandardProfileL3.xmi
    Also publish the following non-normative artifacts in MOF2.4/XMI2.4 format:
    L0.merged.xmi
    LM.merged.xmi
    L1.merged.xmi
    L2.merged.xmi
    Change all references to MOF 2 and XMI 2 in the specification text accordingly.

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

Redefinition of association-owned ends requires association generalization

  • Key: UML24-96
  • Legacy Issue Number: 15567
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    There are 21 examples of association generalizations that need to be introduced in order to make association-owned end redefinition valid

  • Reported: UML 2.3 — Wed, 22 Sep 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    The redefinition context for an association-owned end is the association itself. Hence in order for redefinition of such ends to be well-formed, the associations must participate in appropriate generalizations.
    Here are the problematic redefinitions:
    redefiningElement = A_specification_timeConstraint::timeConstraint
    redefinitionContext = A_specification_timeConstraint
    redefinedElement = A_specification_intervalConstraint::intervalConstraint
    redefinedContext = A_specification_intervalConstraint
    redefiningElement = A_specification_intervalConstraint::intervalConstraint
    redefinitionContext = A_specification_intervalConstraint
    redefinedElement = A_specification_owningConstraint::owningConstraint
    redefinedContext = A_specification_owningConstraint
    redefiningElement = A_specification_durationConstraint::durationConstraint
    redefinitionContext = A_specification_durationConstraint
    redefinedElement = A_specification_intervalConstraint::intervalConstraint
    redefinedContext = A_specification_intervalConstraint
    redefiningElement = A_request_sendObjectAction::sendObjectAction
    redefinitionContext = A_request_sendObjectAction
    redefinedElement = A_argument_invocationAction::invocationAction
    redefinedContext = A_argument_invocationAction
    redefiningElement = A_representation_classifier::classifier redefinitionContext = A_representation_classifier
    redefinedElement = A_collaborationUse_classifier::classifier
    redefinedContext = A_collaborationUse_classifier
    redefiningElement = A_redefinitionContext_transition::transition
    redefinitionContext = A_redefinitionContext_transition
    redefinedElement = A_redefinitionContext_redefinableElement::redefinableElement
    redefinedContext = A_redefinitionContext_redefinableElement
    redefiningElement = A_redefinitionContext_state::state
    redefinitionContext = A_redefinitionContext_state
    redefinedElement = A_redefinitionContext_redefinableElement::redefinableElement
    redefinedContext = A_redefinitionContext_redefinableElement
    redefiningElement = A_redefinitionContext_region::region
    redefinitionContext = A_redefinitionContext_region
    redefinedElement = A_redefinitionContext_redefinableElement::redefinableElement
    redefinedContext = A_redefinitionContext_redefinableElement
    redefiningElement = A_preCondition_protocolTransition::protocolTransition
    redefinitionContext = A_preCondition_protocolTransition
    redefinedElement = A_guard_transition::transition
    redefinedContext = A_guard_transition
    redefiningElement = A_ownedStereotype_owningPackage::owningPackage
    redefinitionContext = A_ownedStereotype_owningPackage
    redefinedElement = A_packagedElement_owningPackage::owningPackage
    redefinedContext = A_packagedElement_owningPackage
    redefiningElement = A_ownedDefault_templateParameter::templateParameter
    redefinitionContext = A_ownedDefault_templateParameter
    redefinedElement = A_default_templateParameter::templateParameter
    redefinedContext = A_default_templateParameter
    redefiningElement = A_ownedAttribute_structuredClassifier::structuredClassifier
    redefinitionContext = A_ownedAttribute_structuredClassifier
    redefinedElement = A_role_structuredClassifier::structuredClassifier
    redefinedContext = A_role_structuredClassifier
    redefiningElement = A_ownedActual_templateParameterSubstitution::templateParameterSubstitution
    redefinitionContext = A_ownedActual_templateParameterSubstitution
    redefinedElement = A_actual_templateParameterSubstitution::templateParameterSubstitution
    redefinedContext = A_actual_templateParameterSubstitution redefiningElement = A_min_timeInterval::timeInterval
    redefinitionContext = A_min_timeInterval
    redefinedElement = A_min_interval::interval
    redefinedContext = A_min_interval
    redefiningElement = A_min_durationInterval::durationInterval
    redefinitionContext = A_min_durationInterval
    redefinedElement = A_min_interval::interval
    redefinedContext = A_min_interval
    redefiningElement = A_max_timeInterval::timeInterval
    redefinitionContext = A_max_timeInterval
    redefinedElement = A_max_interval::interval
    redefinedContext = A_max_interval
    redefiningElement = A_max_durationInterval::durationInterval
    redefinitionContext = A_max_durationInterval
    redefinedElement = A_max_interval::interval
    redefinedContext = A_max_interval
    redefiningElement = A_endData_destroyLinkAction::destroyLinkAction
    redefinitionContext = A_endData_destroyLinkAction
    redefinedElement = A_endData_linkAction::linkAction
    redefinedContext = A_endData_linkAction
    redefiningElement = A_endData_createLinkAction::createLinkAction
    redefinitionContext = A_endData_createLinkAction
    redefinedElement = A_endData_linkAction::linkAction
    redefinedContext = A_endData_linkAction
    redefiningElement = A_classifier_enumerationLiteral::enumerationLiteral
    redefinitionContext = A_classifier_enumerationLiteral
    redefinedElement = A_classifier_instanceSpecification::instanceSpecification
    redefinedContext = A_classifier_instanceSpecification
    redefiningElement = A_classifierBehavior_behavioredClassifier::behavioredClassifier
    redefinitionContext = A_classifierBehavior_behavioredClassifier
    redefinedElement = A_ownedBehavior_behavioredClassifier::behavioredClassifier
    redefinedContext = A_ownedBehavior_behavioredClassifier

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

Fix 14977 vs. 14638

  • Key: UML24-93
  • Legacy Issue Number: 15564
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    There is an inconsistency between 14977 and 14638 that results in inconsistent association end subsets due to incomplete copy-down from Kernel to InternalStructures.

    The resolution is to introduce 2 new generalizations

  • Reported: UML 2.3 — Wed, 22 Sep 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    The generalizations that need to be added are between InternalStructures::StructuredClassifier and Kernel::Classifier, and between InternalStructures::Connector and Kernel::Feature. This enables the ends of A_ownedConnector_structuredClassifier to subset all the things they need to, especially redefinitionContext/redefinableElement. This becomes obvious when you look at the draft figure 9.2. The root cause of this was an attempt to apply both 14638 and 14977 which led to the error.

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

Association-owned association end name changes

  • Key: UML24-92
  • Legacy Issue Number: 15563
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    Kernel & Infrastructure:

    A_member_namespace => A_member_memberNamespace

    Change the association-owned association end from 'namespace' to 'memberNamespace'

    Interactions::BasicInteractions

    Change:

    A_sendEvent_message => A_sendEvent_endMessage

    A_receiveEvent_message => A_receiveEvent_endMessage

    + association-owned association end: 'message' => 'endMessage'

  • Reported: UML 2.3 — Wed, 22 Sep 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    The reason for the first change can be understood by looking at figure 7.4. This shows importedMember subsets member. The other end of this association, non-navigable and un-named on the diagram, is called namespace in the metamodel. This needs, by symmetry, to subset the other end of the association A_member_namespace. That cannot be called namespace, because of the constraint “A Property cannot be subset by a Property with the same name”. Hence we change its name to member_Namespace, and change the association name to follow the convention.
    The second change is for similar reasons. It is actually reflected in the current figure 14.4 but the association name has not been changed to match, and the change has not been introduced in any existing resolution.

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

The resolution to issue 13993 that moved PrimitiveTypes to an independent package contained a mistake

  • Key: UML24-87
  • Legacy Issue Number: 15529
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    The resolution to issue 13993 that moved PrimitiveTypes to an independent package contained a mistake. It specified deleting the import from InfrastructureLibrary::Core::Abstractions to PrimitiveTypes. This is incorrect. Instead it should have specified retargeting the import from InfrastructureLibrary::Core::Abstractions to the new PrimitiveTypes package, to be consistent with the new figure 7.3.

  • Reported: UML 2.3 — Thu, 16 Sep 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    No Data Available

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

Missing subsetting of redefinitionContext by Property::owningAssociation

  • Key: UML24-86
  • Legacy Issue Number: 15526
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    Specification: UML Superstructure version 2.4 (ptc/2010-08-02)

    Subclause: 7.3.45 Property

    In Subclause 7.3.45, the description of Property::owningAssociation indicates that it subsets RedefinableElement::redefinitionContext. However, this is not shown in Figure 7.12. This subsetting relationship is necessary if an owned end of an association is to be able to redefine the ends of parent associations.

    Since this is a metamodel error, it should be fixed in UML 2.4.

  • Reported: UML 2.3 — Tue, 14 Sep 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    agreed

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

InstanceValue has no type

  • Key: UML24-99
  • Legacy Issue Number: 15570
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    There are many cases where the default value of a property is represented by an InstanceValue, which is a TypedElement, but has no type. These types should be inserted.

  • Reported: UML 2.3 — Wed, 22 Sep 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    In fact there are four cases where this is true for an InstanceValue that refers to an EnumerationLiteral. Other cases are instances of LiteralInteger, LiteralBoolean, etc and it seems completely redundant to mark the type of these as Integer, Boolean etc.
    UML::Classes::Kernel::Property::aggregation
    UML::Classes::Kernel::Parameter::direction
    UML::Activities::CompleteActivities::ObjectNode::ordering
    InfrastructureLibrary::Core::Constructs::Parameter::direction

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

DestructionOccurenceSpecification is inherited from OccurenceSpecification instead of MessageOccurenceSpecification

  • Key: UML24-90
  • Legacy Issue Number: 15561
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    That means, it can't be set as message end of delete message (message with "cross" sign at end). Critical bug I think

  • Reported: UML 2.3 — Wed, 22 Sep 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    The following existing text describes the notation:
    The form of the line or arrowhead reflects properties of the message: …
    • Object deletion Message should end in a DestructionOccurrenceSpecification.
    This clearly implies that a DestructionOccurrenceSpecification must be a possible message end, so the issue is correct.

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

DestructionOccurenceSpecification text in Semantics still refers to events

  • Key: UML24-91
  • Legacy Issue Number: 15562
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    DestructionOccurenceSpecification text in Semantics still refers to events:
    "A destruction event represents the destruction of the instance described by the lifeline containing the OccurrenceSpecification that references the destruction event. "

  • Reported: UML 2.3 — Wed, 22 Sep 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    It should not refer to events.

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

serialization of a profile should always include the nsURI and nsPrefix tags

  • Key: UML24-38
  • Legacy Issue Number: 15006
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    The UML Superstructure Specification (in Subclause 18.3.6) says that the

    serialization for a profile "should" (not "shall") specify the values for the

    nsURI and nsPrefix XMI tags and makes recommendations for what these values

    should be. However, this is not normative and "the exact specification of these

    tags is a semantic variation point".

    For the purposes of maximizing successful interchange, however, the

    serialization of a profile should always include the nsURI and nsPrefix tags,

    set as recommended in the specification. The serialization of any application

    of such a profile must then use the recommended forms for the URI and namespace

    prefix for any stereotype applications.

  • Reported: UML 2.3 — Mon, 25 Jan 2010 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    The offending paragraph is altered to make the nsURI and nsPrefix tags mandatory. Also phrases such as “CMOF package corresponding to the” is deleted because we are not serializing a CMOF package; we are serializing a profile as a UML model.
    We do not make the format of the tags mandatory, because organizations are at liberty to create their own formats for proprietary profiles, as long as they follow XMI rules.
    The XMI examples are modified to be up to date and to follow the rules, in resolution 14448.

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

Incomplete resolution to 10826

  • Key: UML24-37
  • Legacy Issue Number: 15001
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    Issue 10826 was asking for two things:

    what is an applied stereotype, as opposed to the definition of the stereotype that was applied
    what are tag/value pairs, as opposed to the definition of the stereotype properties that led to the tag/value pairs

    The resolution for 10826 added the following paragraph:

    An instance “S” of Stereotype is a kind of metaclass that extends other metaclasses through association (Extension) rather
    than generalization/specialization. Relating it to a metaclass “C” from the reference metamodel (typically UML) using an
    “Extension” (which is a specific kind of association), signifies that model elements of type C can be extended by an
    instance of “S” (see example in Figure 18.13). At the model level (such as in Figure 18.18) instances of “S” are related to
    “C” model elements (instances of “C”) by links (occurrences of the association/extension from “S’ to “C”).

    Up to the last sentence, the paragraph refers to ‘an instance “S” of Stereotype’ – i.e., the definition of “S”, a stereotype, in a profile — as illustrated in figure 18.13.

    The last sentence is relevant to question (1) of 10826; however, the resolution doesn’t actually answer the question — i.e., it doesn’t explain what ‘an instance of “S”’ actually is. >From Figure 18.18, the notation suggests that ‘an instance of “S”’ is some kind of instance specification but the resolution doesn’t actually say so and doesn’t address question (2) of 10826 either.

    I propose then to file a new issue about this and include Ed’s suggestion below as well as clarifying that in Figure 18.18, ‘an instance of “S”’ is actually an instance specification whose classifier happens to be ‘an instance “S” of Stereotype’, i.e., the definition of “S”, a kind of Class since Stereotype extends Class.

  • Reported: UML 2.3 — Thu, 17 Dec 2009 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    The UML 2.5 specification and in particular the resolution to issue 17160 make this issue obsolete.
    Disposition: Closed - No Change

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

Definition of Behavior::context is not correct

  • Key: UML24-31
  • Legacy Issue Number: 14964
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    Specification: OMG UML Superstructure, Version 2.3 (ptc/2009-09-09)

    Subclause: 13.3.2 Behavior

    Behavior::context is a derived association, with its derivation given by:

    “If the behavior is owned by a BehavioredClassifier, that classifier is the context; otherwise, the context is the first BehavioredClassifier reached by following the chain of owner relationships. For example, following this algorithm, the context of an entry action in a state machine is the classifier that owns the state machine.”

    However, an entry behavior is owned by a state which is owned by a region which must be owned (directly or indirectly) by a state machine. But a state machine is a behavior, which is a class, which is a behaviored classifier. Therefore, by the given algorithm, it is the state machine that is the context of the entry behavior, not the owner of the state machine, even if the state machine is a classifier behavior.

    This is a serious problem, since the definition for Behavior::context further says “The features of the context classifier as well as the elements visible to the

    context classifier are visible to the behavior.” And it is generally assumed in state machine modeling that an entry behavior in a state machine that is a classifier behavior has visibility to the elements of the owner of the state machine. Similarly, the semantics of a read self action is determined by the context of the activity that contains that action, and if that activity is the entry behavior of a state machine that is a classifier behavior, then the result of this action should be the owner of the state machine, not the state machine.

    In summary, the second sentence given in the first quote above seems to be the true intent of Behavior::context. The first sentence should be changed to:

    “To determine the context of a Behavior, find the first BehavioredClassifier reached by following the chain of owner relationships from the Behavior, if any. If there is such a BehavioredClassifier, then it is the context, unless it is itself a Behavior with a non-empty context, in which case that is also the context for the original Behavior.”

  • Reported: UML 2.3 — Tue, 12 Jan 2010 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    Agreed, except that a slight change to the proposed text will also resolve Issue 14963

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

Context of a behavior owned as a nested classifier

  • Key: UML24-30
  • Legacy Issue Number: 14963
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    Specification: OMG UML Superstructure, Version 2.3 (ptc/2009-09-09)

    Subclause: 13.3.2 Behavior

    Since a behavior is a classifier, and a class is a behaviored classifier, it is possible for a class to own a behavior either as an ownedBehavior (inherited from BehavioredClassifier), or as a nestedClassifier (defined specifically for Class). The intended semantics of nestedClassifier is simply that a classifier is a member of the owning class as a namespace. On would not expect this to imply the additional semantics given later for owned behaviors.

    However, the derivation for Behavior::context is based on the ownership of the behavior, directly or indirectly, by a behaviored classifier, regardless of how this ownership happens. Thus it would seem that a behavior owned as a nestedClassifier would have the owning class as its context, even though it is not an ownedBehavior. It would seem better to have behaviors owned as nestedClassifiers not have the owner as a context, allowing normal visibility rules to apply for access from within the behavior to elements of its owning namespace

  • Reported: UML 2.3 — Tue, 12 Jan 2010 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    See issue 14964 for disposition

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

Matching subsettting across association ends

  • Key: UML24-32
  • Legacy Issue Number: 14977
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    What’s our position about matching subsetting across association ends? I’m looking, for example, at the property Extend::Extension. This subsets source; but its other end subsets ownedMember. This clearly implies that Extend::Extension also subsets namespace (and owner); and the ownerMember end should also subset ownedElement.

    There are plenty of examples of this all over the spec.

    It would be nice to get this right for 2.4. Is this something we’ve already identified?

  • Reported: UML 2.3 — Thu, 14 Jan 2010 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    The following OCL query is designed to find all associations that have asymmetric subsetting of their association ends:
    https://dev.enterprisecomponent.com/repository/repos/UML-RTF/trunk/Models/Constraints/RSA7.5-OCL/associationsWithAsymmetricSubsetting.ocl
    For the UML 2.4 metamodel created from the UML 2.3 metamodel, this query found 182 cases of asymmetric subsetting.
    Here is a proof that subsetting is symmetric (refer to fig 16.2 for the example, but the proof applies to any example):
    Consider UseCase u and Extend e, such that u ? e.extension.
    Then e ? u.extend [because of association invariant: c2 ? c1.p implies c1 ? c2.(p.opposite)]
    It is given that e ? u.ownedMember [ because extend subsets ownedMember ]
    Therefore u ? e.namespace [ because of association invariant ]
    Hence u ? e.extension implies u ? e.namespace, i.e. extension subsets namespace.
    For a redefined association end, the redefinition means that the same set of links are traversed by the redefining property as the redefined property. The same set of links is a special case of subsetting, and the argument then follows as for subsetting. (See 14993 which is resolved as a duplicate of this).
    Where classes and associations have needed to be copied down into a package in order to enable these changes, it has been done. We minimize changes to the current specification diagrams and text by applying the following rules:

    • Where a subsetted property is owned by an association, it is not shown in either diagram or text.
    • Where a subset constraint can be deduced, it does not need to be shown in the diagrams or text.
    • Redundant subsetted properties whose presence can be inferred from others, that are currently in the diagrams and/or text, are left there.
      We anticipate that a future version of UML may apply different conventions to its diagrams to make it simpler to reason about property subsetting.
      The vast majority of the changes involved in this resolution only occur in the metamodel and XMI, where missing subset constraints have been introduced.
      In a few cases documented in this resolution, changes are needed to the diagrams and text to show where metaclasses and/or associations are introduced into a package to make the model merge correctly. Changes are also needed to the diagrams and text wherever a material “subsets” statement is absent.
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Activity vs Action completion

  • Key: UML24-43
  • Legacy Issue Number: 15120
  • Status: closed  
  • Source: Anonymous
  • Summary:

    "In both UML activities and UML statecharts it is sometimes necessary to recognize when some behavior (activity or state-based, respectively) has completed. However, in models without an explicit final node or final state respectively, it is not always clear when this condition is achieved

  • Reported: UML 2.3 — Thu, 4 Mar 2010 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    This is covered for Activities in the UML 2.5 beta specification this is now covered in Subclause 15.2.3 under “Activity
    Execution”:
    “The execution of an Activity with no streaming Parameters completes when it has no nodes executing and no nodes
    enabled for execution, or when it is explicitly terminated using an ActivityFinalNode (see sub clause 15.3). The
    execution of an Activity with streaming input Parameters shall not terminate until the cumulative number of values
    posted to each of those input Parameters (by the invoker of the Activity) is at least equal to the Parametermultiplicity
    lower bound. The execution of an Activity with streaming output Parameters shall not terminate until the cumulative
    number of values posted to each of those output Parameters (by the Activity itself) is at least equal to the Parameter
    multiplicity lower bound.”
    A StateMachine that does not reach a final state simply does not terminate (unless it is terminated by an explicit
    external action, such as the destruction of its context object).
    Disposition: Closed - No Change

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

Enumeration Literal

  • Key: UML24-42
  • Legacy Issue Number: 15107
  • Status: closed  
  • Source: NASA ( Dr. Maged Elaasar)
  • Summary:

    EnumerationLiteral specializes InstanceSpecification, which specializes PackageableElement, which inturn specializes NamedElement

    This allows enum lterals to be owned by packages and have visibility, both of which do not make a lot of sense.

    is it another case of unintended inheritance?

    Another note: does it make sense to couple the capabilities of having a 'name' and 'visibilty', as given by NamedElement?

  • Reported: UML 2.3 — Fri, 15 Jan 2010 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    There is another related problem. The derivation of EnumerationLiteral::/classifier is simply “enumeration”,
    but EnumerationLiteral::/classifier is [1..1] and EnumerationLiteral::enumeration is [0..1]. Creating a literal
    in a package and then asking for its classifier would cause some kind of unpleasant run-type exception.
    Since an EnumerationLiteral surely must be owned by an Enumeration, fix this by changing the multiplicity
    of EnumerationLiteral::enumeration to [1..1].
    As for the visibility, unless we change the metamodel we are stuck with it. Indeed, the constraint namespace_
    needs_visibility forces the visibility to be present.

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

Lack of graphical example of multi-element Dependency Notation

  • Key: UML24-40
  • Legacy Issue Number: 15047
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    The Notation part of section 7.3.12 includes the following text but no graphical example. Furthermore the text seems less than clear (for example whether there must be a ‘junction’ (and whether shown as a point or a line) and whether each arrow entering the junction is required to have its own (open?) arrow head.

    I think that as a result of this few, if any, tools support this notation.

    “ It is possible to have a set of elements for the client or supplier. In this case, one or more arrows with their tails on the clients are connected to the tails of one or more arrows with their heads on the suppliers. A small dot can be placed on the junction if desired. A note on the dependency should be attached at the junction point.”

  • Reported: UML 2.3 — Wed, 10 Feb 2010 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    Merged with 12511

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

Poor example of Dependency notation

  • Key: UML24-39
  • Legacy Issue Number: 15046
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    Figure 7.37 shows an example of Dependency with <<dependencyName>> in guillemets.

    The Notation text above it states:” The arrow may be labeled with an optional stereotype and an optional name.” However surely the name of the Dependency itself should not be in guillemets – only that of the stereotype.

    Note that (subclasses of) Dependency are notated using a keyword instead of a stereotype so this should also be allowed for in the text.

    Proposed resolution: the Figure should be revised to show the dependencyName not in guillemets and possibly with a stereotype name in guillemets.

  • Reported: UML 2.3 — Wed, 10 Feb 2010 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    The corresponding figure in UML 2.5 is Figure 7.18. The proposed resolution is accepted.

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

Figure 7.15

  • Key: UML24-41
  • Legacy Issue Number: 15056
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    There are non-derived properties at both ends - clientDependency and supplierDependency.

    One association is non-navigable, that means supplierDependency is owned by Association, but what does it mean in UML metamodel implementation? How it should be implemented?

    Eclipse has no associations at all, we (MD) simply added this property into NamedElement, but not serializing it into XMI.

    I would suggest to make this property derived or remove at all (if it is not serialized, it does not affect backward compatibility).

  • Reported: UML 2.3 — Thu, 18 Feb 2010 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    Regarding the implementation of supplierDependency as an owned end of an Association, the specification
    does not give implementations, but in the metamodels, it means the supplierDependency property is owned
    by the corresponding association between NamedElement and Dependency (the one with supplier on the
    other end). One-way associations in UML are modeled this way.
    Make NamedElement::clientDependency derived to avoid modifying the client.

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

The containment between Activity and StructuredActivityNode has one end redefining and the other subsetting

  • Key: UML24-35
  • Legacy Issue Number: 14994
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    The containment between Activity and StructuredActivityNode has one end redefining (wrong) and the other subsetting (right). Because redefining and subsetting should be symmetric, this means that both ends are both redefining and subsetting. This is clearly wrong, because it would mean that all nodes and groups are StructuredActivityNodes. The

    {redefines activity, redefines inactivity}

    should be turned into subsetting.

  • Reported: UML 2.3 — Wed, 20 Jan 2010 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    This issue is incorrect. The redefinition is necessary, per the revisions made for UML/MOF/XMI 2.4.1.
    Disposition: Closed - No Change

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

UML 2: property redefinitions should be symmetric across associations

  • Key: UML24-34
  • Legacy Issue Number: 14993
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    When one end of an association is redefined in the metamodel, the other end should be redefined as well. Otherwise the semantics are ill-defined.

  • Reported: UML 2.3 — Wed, 20 Jan 2010 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    See issue 14977 for disposition

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

Expansion nodes using all the tokens in them as a single collection

  • Key: UML24-33
  • Legacy Issue Number: 14991
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    UML expansion regions currently treat each input as a collection, rather
    than all the inputs as members of a single collection, as the execution
    engine currently assumes. The description of Expansion Region says
    "Each input is a collection of values. If there are multiple inputs,
    each of them must hold the same kind of collection, although the types
    of the elements in the different collections may vary. The expansion
    region is executed once for each element (or position) in the input
    collection."

    If it is decided that the execution engine should not reflect the above
    semantics, then UML needs an additional attribute on ExpansionRegion to
    indicate whether the individual tokens of the input and out expansion
    nodes are taken as collections, or whether all the tokens in the nodes
    are taken as one collection. In ExecUML this attribute value would
    always be for the second option.

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

    This issue is obsolete. The specification of the semantics of ExpansionRegions in the UML 2.5 beta specification, in
    Subclause 16.12.3, covers this.
    Disposition: Closed - No Change

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

Subsetting clauses should show the subsetted property fully qualified.

  • Key: UML24-36
  • Legacy Issue Number: 14995
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    In addition to the current notation:

    {subsets activity, subsets inActivity}

    Add a notation where subsetted/redefined properties can be qualified by their owning classifier, i.e.:

    {subsets ActivityNode::activity, subsets ActivityGroup::inActivity}

    And use this notation throughout the metamodel.

    This would make it clear where to look for the subsetted/redefined properties when trying to understand the spec.

  • Reported: UML 2.3 — Wed, 20 Jan 2010 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    The qualified names from the metamodel are now used correctly throughout the generated definitions. Make
    clear that this is allowed in the notation for Property. Do the same for Operation

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

Semantics of the AddVariableValueAction

  • Key: UML23-145
  • Legacy Issue Number: 14027
  • Status: closed  
  • Source: European Software Institute (ESI -Tecnalia) ( Aitor Aldazabal)
  • Summary:

    In the Semantics of the AddVariableValueAction there is a line stating: "If isReplaceAll is false and the variable is unordered and non-unique, then adding an existing value has no effect." I find this statement in correct and in conflict with the semantics defined in multiplicity element. multiplicityElement.ordered -> Specifies whether the values are inserted in a certain position which can be identified by an Integer. This has no influence whatsoever on WHAT values can be added to a variable. multiplicityElement.unique -> An instance (of any type) cannot appear more than once in the collection of values. addVariableValueAction.isReplaceAll -> Specifies if all the previous values are removed before inserting the new ones. This does have influence on WHAT values can be added to a variable. Therefore if the addVariableValueAction is true then the input collection only needs to be evaluated. Else the input collection and the existing values need to be cheked. If the variable IS unique then it must be ensured that the add operation does not put the same instance more than once in the variable. This means that input collection will be merged with the existing values collection (empty collection if isReplaceAll==true) and then the repeated isntances will be removed. If the variable IS NOT unique then there is no need to check anything. Having repeated values in an unordered collection might have sense, for example to execute an algorithm to retrieve the number of times a user has logged in.

  • Reported: UML 2.2 — Wed, 24 Jun 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3b1
  • Disposition Summary:

    duplicate of issue # 8972

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

Errros with some "subsets" and redefines" where the contexts of subsetting/redefintion do not conform

  • Key: UML24-15
  • Legacy Issue Number: 14634
  • Status: closed  
  • Source: NASA ( Dr. Maged Elaasar)
  • Summary:

    a) StructuredActivities::StructuredActivityNode (specializes FundamentalActivities::ActivityGroup) with the following errors:
    StructuredActivities::StructuredActivityNode::activity redefines StructuredActivities::ActivityGroup::inActivity
    StructuredActivities::StructuredActivityNode::node subsets StructuredActivities::ActivityGroup::containedNode

    b) IntermediateActivities::Activity (does not specialize any other class), with the following errors
    IntermediateActivities::Activity::group subsets Kernel::Element::ownedElement (notice that IntermediateActivities::Activity::partition subsets IntermediateActivities::Activity::group)

    c) IntermediateActivities::ActivityGroup (does not specialize any other class), with the following errors
    IntermediateActivities::ActivityGroup::inActivity subsets Kernel::Element::owner

    d) IntermediateActivities::ActivityPartition (specializes IntermediateActivities::ActivityGroup), with the following errors
    IntermediateActivities::ActivityPartition::subpartition subsets FundamentalActivities::ActivityGroup::subgroup
    IntermediateActivities::ActivityPartition::superPartition subsets FundamentalActivities::ActivityGroup::superGroup (also notice the capitaliation diff between subpartitiion and superPartiion)

    e) CompleteActivities::InterruptibleActivityRegion (specializes BasicActivities::ActivityGroup), with the following errors
    CompleteActivities::InterruptibleActivityRegion::node subsets CompleteActivities::ActivityGroup::containedNode

    f) Interfaces::Property (specializes Kernel::StructuralFeature), with the following errors
    Interfaces::Property::interface subsets Kernel::A_attribute_classifier::classifier

      • Fixes for those require fixing the spec and metamodel
  • Reported: UML 2.3 — Thu, 12 Nov 2009 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    These problems are a consequence of improper understanding and documentation of package merge.
    a). The problem is caused because StructuredActivities::StructuredActivityNode inherits from FundamentalActivities::ActivityGroup, not StructuredActivities::ActivityGroup. Although according to the text the latter does not exist, it is actually present in the UML 2.3 metamodel. (See also 15264). The resolution is to inherit from the local ActivityGroup. Researching this also shows that the spec document is already quite seriously adrift from the metamodel. Although this will be fixed in UML 2.5, this resolution takes some steps to fix it.
    b) The problem is caused because IntermediateActivities::Activity has no base class. The resolution is to remove the subset assertion from IntermediateActivities::Activity::group. Since the subset is correctly declared in FundamentalActivities, it is reintroduced by the merge.
    c) The problem and resolution are analogous to (b).
    d) The problem is that the subsetted properties are those in FundamentalActivities, not those in IntermediateActivities. This is like (a).
    e) The problem is that InterruptableActivityRegion inherits from BasicActivities::ActivityGroup, not CompleteActivities::ActivityGroup. We make it inherit from the latter.
    f) The problem is that the Property defined in Interfaces is not related to Classifier, so there is no /attribute association to subset. We create a local Classifier and copy down the association.

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

Attributes without a type

  • Key: UML24-14
  • Legacy Issue Number: 14633
  • Status: closed  
  • Source: NASA ( Dr. Maged Elaasar)
  • Summary:

    Profiles::ExtensionEnd::lower is not typed (should have been of type Integer)

      • This fix is only in the metamodel
  • Reported: UML 2.3 — Thu, 12 Nov 2009 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    As suggested, set the type of „lower? to Integer

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

UML 2 Events referred to by OccurrenceSpecifications should be optional

  • Key: UML24-10
  • Legacy Issue Number: 14629
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    In UML 2, every OccurrenceSpecification must be associated with an Event. The Event in turn should have a name and an owning package. But in general, drawing an interaction diagram does not specify a name or owner for the Events associated with the OccurrenceSpecifications.

    This means that conforming tools have to invent Events including their names and owners for all OccurrenceSpecifications in an Interaction, even though these objects have no relevance to the model. This simply consumes memory footprint without providing any user value.

    If people want to model Events, that is fine; if they wish to associate OccurrenceSpecifications with them that is fine too; what is not fine is forcing the existence of these spurious objects. Hence the multiplicity of OccurrenceSpecification.event and its redefinitions should be changed to 0..1.

  • Reported: UML 2.3 — Fri, 6 Nov 2009 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    The Events that are only defined for Interactions are superfluous and is removed. The necessary information is in the Signal or Operation designated by the signature property of Message together with the MessageKind and MessageSort properties.
    In UML 2.3 the signature attribute is derived, in this revision it is changed to non-derived.

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

Associations with same name that live in different packages violate unique name constraint

  • Key: UML24-13
  • Legacy Issue Number: 14632
  • Status: closed  
  • Source: NASA ( Dr. Maged Elaasar)
  • Summary:

    Some associations that have the same name, but exist in different packages in the unmerged model, show up together in the merged model violating the unique name constraint

    BasicActivities::A_outgoing_source (Figure 12.5) and BehaviorStateMachines::A_outgoing_source (Figure 15.2).
    BasicActivities::A_incoming_target (Figure 12.5) and BehaviorStateMachines::A_incoming_target(Figure 15.2).
    BasicComponents::A_realization_abstraction (Figure 8.2) and AuxilliaryConstructs::InformationFlow::A_realization_abstraction (Figure 17.2)

    One way to fix that is to rename the associations to avoid the name collission, for example:

    BasicActivities::A_outgoing_source_node and BehaviorStateMachines::A_outgoing_source_vertex
    BasicActivities::A_incoming_target_node and BehaviorStateMachines::A_incoming_target_vertex
    BasicComponents::A_realization_abstraction_component (Figure 8.2) and AuxilliaryConstructs::InformationFlow::A_realization_abstraction_flow (Figure 17.2)

      • This fix affects the respective figures to show the non-default association names explicitly
  • Reported: UML 2.3 — Thu, 12 Nov 2009 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    Agree to the suggestion given in the issue.

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

All enumertion literals in the model have their "classifier" collections empty

  • Key: UML24-12
  • Legacy Issue Number: 14631
  • Status: closed  
  • Source: NASA ( Dr. Maged Elaasar)
  • Summary:

    All enumertion literals in the model have their "classifier" collections empty (i.e do not contain the corresponding enumertion)

    This issue also existed in UML 2.1.1. To fix, I can add the enumeration to the "classifier" collection of the literals. But, shouldn't EnumertionLiteral have redefined "classifier" and made it derived from "enumeration" association end?

    **This is a metamodel only fix

  • Reported: UML 2.3 — Wed, 18 Nov 2009 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    The „classifier? association is inherited by EnumerationLiteral from InstanceSpecification in the UML spec, not in the MOF spec, which the UML metamodel is an instance of. Therefore, the enumeration literals in UML should not have this property.
    However, in the UML spec, an enumeration literal?s classifier should always be set to the enumeration owning it. Therefore, „classifier? should be redefined to be a derived association end that gets it value from the „enumeration? property of enumeration literal, which should also be made non-optional, since an enumeration should not be owned by anything other than an enumeration.

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

Constraint [3] on TestIdentityAction is incorrect

  • Key: UML24-4
  • Legacy Issue Number: 14570
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    Specification: UML Superstructure (formal/09-02-02)

    Subclause: 11.3.49 TestIdentityAction

    Constraint [3] for TestIdentityAction is:

    [3] The type of the result is Boolean.

    self.result.type.oclIsTypeOf(Boolean)

    While the English statement expresses the correct intent, the OCL is wrong. As written, the OCL requires that the type of the object referenced by the type property of the OutputPin be Boolean. But this is, of course, impossible, since the type of OutputPin::type is the metaclass Type, and any value for this property must be for an instance of a concrete subclass of type, such as Classifier or PrimitiveType. Boolean, on the other hand, is represented as an instance of the metaclass PrimitiveType. That is, the OCL for this constraint is confusing metalevels.

    The OCL should really be something like:

    self.result.type = PrimitiveType instance representing Boolean

    However, unless some sort of standard way to reference the M1 instance representing Boolean within the UML metamodel, it is unclear how to formally write “PrimitiveType instance representing Boolean”.

  • Reported: UML 2.3 — Fri, 16 Oct 2009 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    agreed

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

Constraint [1] for WriteStructuralFeatureAction is incorrect

  • Key: UML24-3
  • Legacy Issue Number: 14569
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    Specification: UML Superstructure (formal/09-02-02)

    Subclause: 11.3.55

    The OCL for constraint [1] of WriteStructuralFeatureAction incorrectly constraints the type of the value pin of the action to be the featuring classifier of the structural feature being written to. The type of the value should actually be the same as the type of the structural feature. It is the object pin which should be constrained to have a featuring classifier as its type – but this constraint is own the parent StructuralFeatureAction class, not on WriteStructuralFeatureAction itself. The correct OCL is:

    self.value->notEmpty() implies self.value.type = self.structuralFeature.type

    (The possibility of self.value being empty is due to the resolution of Issue 9870 in UML 2.3.)

  • Reported: UML 2.3 — Fri, 16 Oct 2009 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    agreed

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

UML2 - derivation for DeploymentTarget.deployedElement is invalid

  • Key: UML24-7
  • Legacy Issue Number: 14621
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    According to 10.3.6:

    context DeploymentTarget::deployedElement derive: ((self.deployment->collect(deployedArtifact))>collect(manifestation))>collect(utilizedElement)

    But self.deployment->collect(deployedArtifact) gives a collection of DeployedArtifact, not of Artifact; therefore the call to manifestation is invalid. To make it correct from a type point of view, there needs to be an additional select to pick the DeployedArtifacts that are actually Artifacts.

    While we are at it, it is highly inappropriate to have a subclass of DeployedArtifact called Artifact: the names imply the reverse of the inheritance hierarchy.

  • Reported: UML 2.3 — Wed, 11 Nov 2009 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • 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:58 GMT

UML2 - non-unique association names in L3.merged.cmof

  • Key: UML24-6
  • Legacy Issue Number: 14613
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    I think the rules say that associations should be uniquely named in a package. L3.merged has three non-unique association names:

    A_outgoing_source

    A_realization_abstraction

    A_templateParameter_parameteredElement

  • Reported: UML 2.3 — Wed, 4 Nov 2009 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    See issues 14287 and 14632 for disposition

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

Some owned operations with OCL expression bodies but without their "isQuery" set to "true"

  • Key: UML24-11
  • Legacy Issue Number: 14630
  • Status: closed  
  • Source: NASA ( Dr. Maged Elaasar)
  • Summary:

    A body condition is specified for operation '<Operation> ConnectableElement::end () : ConnectorEnd [0..*]', but it is not a query.
    A body condition is specified for operation '<Operation> Vertex::incoming () : Transition [0..*]', but it is not a query.
    A body condition is specified for operation '<Operation> Vertex::outgoing () : Transition [0..*]', but it is not a query.

    **This is a metamodel only fix

  • Reported: UML 2.3 — Thu, 12 Nov 2009 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    All additional operations in the UML metamodel are queries and as such must be marked with isQuery = true in the metamodel

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

UML2 - definition of Property.opposite is wrong

  • Key: UML24-8
  • Legacy Issue Number: 14626
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    Currently the spec says:

    If this property is owned by a class associated with a binary association, and the other end of the association is also owned by a class, then opposite gives the other end.

    opposite = if owningAssociation->isEmpty() and association.memberEnd->size() = 2 then let otherEnd = (association.memberEnd - self)>any() in if otherEnd.owningAssociation>isEmpty() then otherEnd else Set{} endif else Set {} endif

    This is wrong. The opposite should be calculated properly whatever the property is owned by. It should say “if the property is an association end of a binary association, opposite gives the other end”.

  • Reported: UML 2.3 — Fri, 13 Nov 2009 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • 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:58 GMT

Parameter type of MultiplicityElement::includesMultiplicity()

  • Key: UML24-5
  • Legacy Issue Number: 14580
  • Status: closed  
  • Source: Northrop Grumman ( Mr. Christopher McClure)
  • Summary:

    In the UML Infrastructure XMI, the type of Core::Abstractions::Multiplicities::MultiplicityElement::includesMultiplicity() parameter M is Core::Basic::MultiplicityElement. The type of M should be Core::Abstractions::Multiplicities::MultiplicityElement to keep Abstractions independent of Basic.

  • Reported: UML 2.3 — Tue, 27 Oct 2009 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • 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:58 GMT

UML2: Incomplete definition for Activity.structuredNode

  • Key: UML24-9
  • Legacy Issue Number: 14627
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    Currently the sentence is incomplete:

    /structuredNode : StructuredActivityNode [0..*] Top-level structured nodes in the activity. Subsets

    It should subset node and group (according to the diagram).

  • Reported: UML 2.3 — Fri, 13 Nov 2009 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    agreed

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

What is "top-tier packages of the UML metamodel"?

  • Key: UML23-143
  • Legacy Issue Number: 17370
  • Status: closed  
  • Source: aol.com ( Brian Book)
  • Summary:

    Under Compliance Levels, the first paragraph following the level descriptions is confusing, since it references the terms "top-tier" and "second-tier" packages without ever defining what those means.
    For me, this entire paragraph is meaningless as a result.

  • Reported: UML 2.2 — Wed, 16 May 2012 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • 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:58 GMT

Names of ownedEnds that were there in UML 2.1.1 are missing in UML 2.2

  • Key: UML23-125
  • Legacy Issue Number: 14355
  • Status: closed  
  • Source: The MathWorks ( Mr. Salman Qadri)
  • Summary:

    The MOF 2.0 Specification section 12.4 states that "Names are required for all Types and Properties". We should ensure that all Properties in the UML xmi files have names, preferably the same as the ones that were already there in UML 2.1.1 (this is a regression). An example is:

    " Classes-Interfaces-A_interface_ownedAttribute-_ownedEnd.0" in Superstructure.xmi (2.3) and " Classes-Interfaces-A_interface_ownedAttribute-_ownedEnd.0" in Superstructure.cmof (2.2) have no names. But " Classes-Interfaces-A_interface_ownedAttribute-interface" in Superstructure.cmof (2.1.1) has names.

  • Reported: UML 2.2 — Fri, 4 Sep 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    The UML 2.1.1 XMI files are fully compliant with the quoted constraint that "Names are required for all Types and Properties". The UML 2.3 XMI files; however, no longer have names for several association end properties (298 in the in Superstructure.xmi; 55 in the Infrastructure.xmi). Most of these association end properties are in fact owned ends of their respective associations. These ownedEnds are MOF Properties that had names in UML 2.1.1. We consider this to be a regression, and we are to repair all such ownedEnds by restauring their name according to the naming convention specified in clause 6.4.2 that was used to name the corresponding association.
    In addition, we will ensure that there are no other Types or Properties that have no name. In Superstructure.xmi (2.3), there are 5 Associations which also must be given names. This is an XMI-only change.
    The OCL query used to find associations with unnamed association ends using RSA 7.5.3 & the RSA-proprietary *.emx representation of the infrastructure & superstructure metamodels is the following:
    let As : Collection(Association) = self.allOwnedElements()
    ->select(oclIsKindOf(Association)).oclAsType(Association) in
    As->select(a|a.member->exists(name->isEmpty()))
    ->sortedBy(qualifiedName).qualifiedName
    The OCL query used to report unnamed associations using RSA 7.5.3 & the RSA-proprietary *.emx representation of the infrastructure & superstructure metamodels is the following:
    let As : Collection(Association) = self.allOwnedElements()
    ->select(oclIsKindOf(Association)).oclAsType(Association) in
    As->select(a|a.name->isEmpty())->collect(a|Tuple

    { pkg=a.namespace.qualifiedName, end1_type=a.member->asSequence()->at(1).oclAsType(Property).type.name, end1_name=a.member->asSequence()->at(1).oclAsType(Property).name, end2_type=a.member->asSequence()->at(2).oclAsType(Property).type.name, end2_name=a.member->asSequence()->at(2).oclAsType(Property).name}

    )

    The OCL query used to verify that all occurrences of unnamed association ends are in fact owned ends of their associations using RSA 7.5.3 & the RSA-proprietary *.emx representation of the infrastructure & superstructure metamodels is the following:
    let As : Collection(Association) = self.allOwnedElements()->select(oclIsKindOf(Association)).oclAsType(Association) in
    As->select(a|a.member->exists(name->isEmpty()))
    >forAll(a|a.member>one(m|m.name->isEmpty() and
    m.oclAsType(Property).association->notEmpty()))

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

notation of objet flow <> and <>

  • Key: UML23-127
  • Legacy Issue Number: 14431
  • Status: closed  
  • Source: Teuchos ( Samuel Rochet)
  • Summary:

    Description:

    Notation of ObjectFlow "selection" and "transformation" as a note symbole does not specifiy the content of the note relatively to these behaviors.

    In exemples figures 12.75 and 12.112 this note contains OCL constraints or free text.

    It could be usefull to specify what needs to be displayed. For exemple :

    • if the selection/transformation is an OpaqueBehavior then the body of the OpaqueBehavior is dislayed in the note
    • if the selection/transformation is another Behavior then the name of the Behavior is displayed in the note

    Note that same problem occurs for ObjectNode selection

  • Reported: UML 2.2 — Thu, 24 Sep 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    This issue is obsolete. The UML 2.5 specification, in subclause 15.2.4, at the end of the paragraph describing the
    selection and transformation Behavior notation, has the sentence: “The body of the note symbol may either contain
    a textual representation of the Behavior (e.g., the body of an OpaqueBehavior) or the name of a Behavior that is not
    represented textually.”
    Disposition: Closed - No Change

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

UML 2.3 draft, 11.3.1 - AcceptCallAction

  • Key: UML23-126
  • Legacy Issue Number: 14429
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    The text of the description is contradictory. The first sentence says:

    “AcceptCallAction is an accept event action representing the receipt of a synchronous call request. ....”

    In the second paragraph it says:

    This action is for synchronous calls. If it is used to handle an asynchronous call, execution of the subsequent reply action will complete immediately with no effects.

    Although the description states twice that it is for the receipt of synchronous calls it then goes on to describe its use for asynchronous calls.

  • Reported: UML 2.2 — Tue, 22 Sep 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    Accept call actions are intended to receive synchronous calls, however they will, indeed, also accept asynchronous calls, but, as already noted in the spec, no reply will be sent in such cases. The description could be better worded to make this clear without sounding contradictory.

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

Duplicate association in normative UML 2.3 superstructure file

  • Key: UML23-124
  • Legacy Issue Number: 14287
  • Status: closed  
  • Source: Adaptive ( Mr. Gene Mutschler)
  • Summary:

    What state is UML 2.3 in with respect to filing issues?

    In particular, there is a duplicate association name in the Superstructure Library normative XMI file for UML 2.3 that was detected by my CMOF Import:

    Duplicate association in package: Logical View::UML::AuxiliaryConstructs::Templates: A_templateParameter_parameteredElement.
    Duplicate association in package: Logical View::UML::AuxiliaryConstructs::Templates: A_templateParameter_parameteredElement.

    I checked the XMI file and, yes, the association is duplicated

  • Reported: UML 2.2 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    This issue is covered by the resolution to 13330

    Revised Text:

    Disposition: Duplicate of 13330

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

Japan Infrastructure PAS Ballot Comments - comment 9

  • Key: UML23-123
  • Legacy Issue Number: 14286
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Part I, II, III GE This is a multipart standard, use of "Part I, II, III" make confusion. Delete Part III and Make others rewrite as clauses. 7. General Introduction, 10 Infrastructure Library, and renumber other clauses. Also, delete Part III page.

  • Reported: UML 2.2 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    Agree to change word "Part" to "Sub Part" throughout document.

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

Japan Infrastructure PAS Ballot Comments - comment 8

  • Key: UML23-122
  • Legacy Issue Number: 14285
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Annex E GE Acknowledgements are not normative specification.

    Leave them as OMG only document. Remove Annex E from ISO standard.

  • Reported: UML 2.2 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    Acknowledgements are now in Section 6.3. However agree should be removed from ISO spec.

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

Japan Infrastructure PAS Ballot Comments - comment 4

  • Key: UML23-118
  • Legacy Issue Number: 14281
  • Status: closed  
  • Source: Anonymous
  • Summary:

    GE The following standard must be refer.

    • XMI ISO/IEC19503
    • MOF ISO/IEC19502 ISO/IEC 19502:2005 Information technology – Meta Object Facility (MOF)
      ISO/IEC 19503:2005 Information technology – XML Metadata Interchange (XMI)
  • Reported: UML 2.2 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    Issue 14280 proposal adds the proper references for UML 2. The older versions of MOF/XMI and OCL are not compatible with UML 2.

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

Japan Infrastructure PAS Ballot Comments - comment 3

  • Key: UML23-117
  • Legacy Issue Number: 14280
  • Status: closed  
  • Source: Anonymous
  • Summary:

    GE The format of normative references doesn't meet ISO format.

    Write reference like as follow if you refer OMG's documents
    IEC Std Template, IEC, available at <http://www.iec.ch/tiss/templates.htm>

  • Reported: UML 2.2 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    add references with full text.

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

Japan Superstructure PAS Ballot Comments - comment 20

  • Key: UML23-114
  • Legacy Issue Number: 14277
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Part I, II, III,, IV GE This is a multipart standard, use of "Part I, II, III, IV" make confusion. Delete unnecessary Part IV and Make others rewrite as clauses. 7. Structure, 12 Behavior, 19 Supplement and renumber other clauses.

  • Reported: UML 2.2 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    Agree to change word "Part" to "Sub Part" throughout document.

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

Japan Superstructure PAS Ballot Comments - comment 19

  • Key: UML23-113
  • Legacy Issue Number: 14276
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Annex K GE Acknowledgements are not normative specification. . Leave them as only OMG document but not ISO standard. Remove Annex K.

  • Reported: UML 2.2 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    Acknowledgements are now in Section 6.5. Needs to be removed from ISO spec. remove section 6.5 from ISO spec and OMG spec for consistency.

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

Japan Infrastructure PAS Ballot Comments - comment 7

  • Key: UML23-121
  • Legacy Issue Number: 14284
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Annex D GE This is ISO standard, thus it is unnecessary OMG's procedure. Leave them as OMG only document.

    Remove Annex D from ISO standard.

  • Reported: UML 2.2 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    Resolution:
    Agree, this annex is no longer in UML 2.3.
    Revised Text:

    Disposition: Closed, No Change

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

Japan Infrastructure PAS Ballot Comments - comment 6

  • Key: UML23-120
  • Legacy Issue Number: 14283
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Annex C TH This annex .defines OMG and related companies's copyright and patent condition. But ISO defines another copyright and patent condition.

    Remove Annex C or make it informative Annex.

  • Reported: UML 2.2 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    Agreed, but Annex C is no longer in UML 2.3
    Revised Text:

    Disposition: Closed, No Change

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

Japan Infrastructure PAS Ballot Comments - comment 2

  • Key: UML23-116
  • Legacy Issue Number: 14279
  • Status: closed  
  • Source: Anonymous
  • Summary:

    GE ISO standard documents are described with "shall", "should" and "may".

    Define this standard with "shall", "should" and "may".

  • Reported: UML 2.2 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    specification uses RFC 2119 Terminology

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

Japan Infrastructure PAS Ballot Comments - comment 5

  • Key: UML23-119
  • Legacy Issue Number: 14282
  • Status: closed  
  • Source: Anonymous
  • Summary:

    4,5 GE There is no terms ,definitions and symbols.

    Remove the clause "4 Terms and definitions" and "5 Symbols".

  • Reported: UML 2.2 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    Resolution:
    Leave section 4 for future revisions to add terms and definitions.
    Issue 14279 replaces section 5 with a new Notational Conventions section. see Issue 14279 (JP 2) resolution.
    Revised Text:

    Disposition: Duplicate of 14279

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

Japan Infrastructure PAS Ballot Comments - comment 1

  • Key: UML23-115
  • Legacy Issue Number: 14278
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Japan will approve this DIS if the TH comment will accept.

  • Reported: UML 2.2 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    Revised Text:
    See resolution to OMG Issues 14283

    Disposition: Duplicate of 14283

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

UML type Real specification

  • Key: UML241-12
  • Legacy Issue Number: 16301
  • Status: closed  
  • Source: - ( Marijan Matic)
  • Summary:

    Version 2.4 intruduces a new UML primitive type - Real.

    This information has not been mentioned on page 127 - 7.3.44.

    The package name (I suppose Kernel) has not been defined for LiteralReal - chapter 7.3.29 (page 95); table of contents (page II).

  • Reported: UML 2.4 — Wed, 1 Jun 2011 04:00 GMT
  • Disposition: Resolved — UML 2.4.1
  • 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:58 GMT

Interface element - associations multiplicity not defined

  • Key: UML241-11
  • Legacy Issue Number: 16268
  • Status: closed  
  • Source: - ( Marijan Matic)
  • Summary:

    On page 36, Figure 7.16 shows the content of Interface package. Interface element has associations to four other elements with multiplicity of *. Multiplicity information is not defined on page 89, where the association names for Interface element has been defined.

  • Reported: UML 2.4 — Thu, 26 May 2011 04:00 GMT
  • Disposition: Resolved — UML 2.4.1
  • 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:58 GMT

Property::isID

  • Key: UML241-9
  • Legacy Issue Number: 16210
  • Status: closed  
  • Source: NASA ( Dr. Maged Elaasar)
  • Summary:

    Is there a semantic difference between markign an associationEnd with isID=true and putting an upper bound of "1" on its opposite end (i.e., a value of this end is related to a maximum of 1 value on the other end)?

    If there is no semantic difference, is Property::isID only useful for attributes that are not association ends (like primitive attributes that are typically not ends)?

  • Reported: UML 2.4 — Mon, 2 May 2011 04:00 GMT
  • Disposition: Resolved — UML 2.4.1
  • Disposition Summary:

    Assume a classifier A has a property that is an association end typed by B, and assume its opposite end has the
    multiplicity 1..1.
    Even if this implies that, at any time, only one instance of A can be associated with a given instance of B, nothing
    stops this association from changing over time. Thus, a given instance of B cannot be used “a priori” for identifying
    an instance of A. So there is no redundancy with the semantics of Property::isID as suggested by the issue.
    Disposition: Closed - No Change

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

Wrong package name on several Figures

  • Key: UML241-6
  • Legacy Issue Number: 16120
  • Status: closed  
  • Source: email.com ( Kirill Fakhroutdinov)
  • Summary:

    Several Figures has wrong package name shown. In all cases package name should be "Core" instead of "Constructs":

    • Figure 7.3 - The Core packages
    • Part II, Figure 2 - The Core package contains the packages PrimitiveTypes, Abstractions, Basic, and Constructs...
    • Figure 9.1 - The Core package is owned by the InfrastructureLibrary pack...
    • Figure 10.1 - The Core package is owned by the InfrastructureLibrary package...
    • Figure 11.1 -The Core package is owned by the InfrastructureLibrary package...

    Also, the package name should be shown on the tab.

  • Reported: UML 2.4 — Tue, 19 Apr 2011 04:00 GMT
  • Disposition: Resolved — UML 2.4.1
  • 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:58 GMT

Missing Namespace in Dependencies package definition?

  • Key: UML241-10
  • Legacy Issue Number: 16267
  • Status: closed  
  • Source: - ( Marijan Matic)
  • Summary:

    On page 35, Figure 7.15 the Namespace element is described as Namespace from Dependencies package, but (on page 103) Namespace element is defined from Kernel package only.

  • Reported: UML 2.4 — Thu, 26 May 2011 04:00 GMT
  • Disposition: Resolved — UML 2.4.1
  • 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:58 GMT

typo on page 46

  • Key: UML241-3
  • Legacy Issue Number: 16110
  • Status: closed  
  • Source: Anonymous
  • Summary:

    look at Page 46, there is a typo in the word "metaatribute" in the sentence:
    ...
    "AssociationEnd was a metaclass in prior UML, now demoted to a member of
    Association. The metaatribute targetScope"

  • Reported: UML 2.4 — Wed, 6 Apr 2011 04:00 GMT
  • Disposition: Resolved — UML 2.4.1
  • 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:58 GMT

typo in new attribute name

  • Key: UML24-1
  • Legacy Issue Number: 14565
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    The new 2.3 spec contains typo (double i) in new attribute name:

    iisLocallyReentrant : Boolean = false

    In Subclause 12.3.2 Action, under Attributes.

  • Reported: UML 2.3 — Thu, 15 Oct 2009 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    agreed

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

Section: Classes

  • Key: UML23-144
  • Legacy Issue Number: 8768
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Notation for navigable ends owned by an association. Figure 21 should include a notation for navigable ends owned by the association

  • Reported: RAS 2.2 — Thu, 5 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    This was effectively resolved by the introduction of the "dot" notation in UML 2.1 for ends owned by end types.
    Revised Text:
    None.
    Disposition: Closed No Change

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

CMOF missing several redefined property relationships

  • Key: UML24-2
  • Legacy Issue Number: 14566
  • Status: closed  
  • Source: The MathWorks ( Mr. Salman Qadri)
  • Summary:

    Since CMOF does a PackageMerge of Infrastructure-Core-Basic with Infrastructure-Core-Constructs, the resulting metaclass Operation ends up having 'isOrdered', 'isUnique', 'type', 'lower' and 'upper' properties, which conflict with the names of properties it inherits, particularly from MultiplicityElement and TypedElement. This is illegal unless these properties explicitly have redefinedProperty relationships.

  • Reported: UML 2.3 — Thu, 15 Oct 2009 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • 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:58 GMT

Setting Classes-Interfaces-Interface-ownedAttribute would fail to populate Classes-Kernel-Property-owner

  • Key: UML23-95
  • Legacy Issue Number: 14235
  • Status: closed  
  • Source: The MathWorks ( Mr. Salman Qadri)
  • Summary:

    In Superstructure.xmi (2.3):

    Classes-Interfaces-Interface-ownedAttribute has a one-directional association to Classes-Kernel-Property and subsets Classes-Kernel-Namespace-ownedMember. Adding an instance of a merged Property to Interface-ownedAttribute would fail to populate the ‘owner’ or ‘namespace’ attributes of the Property (because the only slots are ‘class’ and ‘datatype’).

    This is inconsistent in 2 ways:

    1) The merged Property has the slots ‘class’ and ‘datatype’, but there is no slot for ‘interface’.

    2) Compare this to a merged Operation, which has ‘class’, ‘datatype’ as well as ‘interface’ (from Classes-Interfaces-Operation-interface). Also, Classes-Interfaces-Interface-ownedOperation has a bidirectional association with Classes-Interfaces-Operation-interface, which also feels at odds with Classes-Interfaces-Interface-ownedAttribute.

    3) Since Classes-Interfaces-Interface-ownedAttribute explicitly subsets ‘Classes-Kernel-Namespace-ownedMember’, we would expect that the association to ‘Classes-Kernel-NamedElement-namespace’ should produce a result. However since ‘namespace’ is a derived-union with no slots that accept an ‘Interface’, this remains empty (and consequently so does ‘owner’ even though the Property IS being owned by an Interface).

    I would like to suggest the following:

    1) Add a cmof:Class ‘Classes-Interfaces-Property’ to the package ‘Classes-Interfaces’ as an ‘ownedMember’ and change the ‘type’ of ‘Classes-Interfaces-Interface-ownedAttribute’ to ‘Classes-Interfaces-Property’.

    2) Add a cmof:Property ‘Classes-Interfaces-Property-interface’ as an ‘ownedAttribute’ of ‘Classes-Interfaces-Property’. This attribute should be 0..1 with the type ‘Classes-Interfaces-Interface’ and should subset ‘Classes-Kernel-RedefinableElement’, ‘Classes-Kernel-Feature-featuringClassifier’ and ‘Classes-Kernel-NamedElement-namespace’. Its’ association should be ‘Classes-Interfaces-A_interface_ownedAttribute’.

    3) Modify ‘Classes-Interfaces-A_interface_ownedAttribute’ to have the member ends be ‘Classes-Interfaces-Property-interface’ and ‘Classes-Interfaces-Interface-ownedAttribute’.

  • Reported: UML 2.2 — Fri, 28 Aug 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    This inconsistency issue is substantiated as explained; the suggestion amounts to repairing Classes::Interfaces as a package merge extension of Classes::Kernel. In fact, the "copy-down" suggested in item (2) is implicitly shown in the fact that 'Property' like all of the other metaclasses defined in the Classes::Interfaces package are unqualified whereas the other metaclasses defined but not copied in this package are fully qualified.

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

Incorrect OCL in Infrastructure.xmi for 'Core-Constructs-Operation-isConsistentWith'

  • Key: UML23-94
  • Legacy Issue Number: 14228
  • Status: closed  
  • Source: The MathWorks ( Mr. Salman Qadri)
  • Summary:

    The body of the ‘Core-Constructs-Operation-isConsistentWith’ Operation in Infrastructure.xmi uses an attribute called ‘formalParameter’, which does not exist in the metamodel:

    result = (redefinee.oclIsKindOf(Operation) and let op: Operation = redefinee.oclAsType(Operation) in self.formalParameter.size() = op.formalParameter.size() and self.returnResult.size() = op.returnResult.size() and forAll(i | op.formalParameter[i].type.conformsTo(self.formalParameter[i].type)) and forAll(i | op.returnResult[i].type.conformsTo(self.returnResult[i].type))

    We should instead borrow the body from Superstructure.xmi which does not have that problem:

    result = (redefinee.oclIsKindOf(Operation) and let op: Operation = redefinee.oclAsType(Operation) in self.ownedParameter.size() = op.ownedParameter.size() and forAll(i | op.ownedParameter[i].type.conformsTo(self.ownedParameter[i].type))

  • Reported: UML 2.2 — Thu, 27 Aug 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    Resolve discrepancies for RedefinableElement amongst the following artifacts:

    • Infrastructure document (clause 11.4.4)
    • Superstructure document (clause 7.3.46)
    • Infrastructure XMI: Core::Constructs::RedefinableElement
    • Superstructure XMI: Classes::Kernel::RedefinableElement
      Resolve discrepancies for Operation::isConsistentWith amongst the following artifacts:
    • Infrastructure document (clauses 11.3.4 & 11.8.2)
    • Superstructure document (clause 7.3.36)
    • Infrastructure XMI: Core::Constructs::Operation
    • Superstructure XMI: Classes::Kernel::Operation
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Japan Superstructure PAS Ballot Comments - comment 4

  • Key: UML23-99
  • Legacy Issue Number: 14261
  • Status: closed  
  • Source: Anonymous
  • Summary:

    JP4 3 GE The following standard must be refer.

    • XMI ISO/IEC19503
    • MOF ISO/IEC19502
    • OCL 2.0 ISO/IEC 19502:2005 Information technology – Meta Object Facility (MOF)
      ISO/IEC 19503:2005 Information technology – XML Metadata Interchange (XMI)
      OCL 2, OMG, available at
      <http://www.omg.org/spec/OCL/2.0/PDF>
  • Reported: UML 2.2 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    Issue 14260 proposal adds the proper references for UML 2. The older versions of MOF/XMI and OCL are not compatible with UML 2.

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

Japan Superstructure PAS Ballot Comments - comment 3

  • Key: UML23-98
  • Legacy Issue Number: 14260
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The format of normative references doesn't meet ISO format.

    Write reference like as follow if you refer OMG's documents
    IEC Std Template, IEC, available at <http://www.iec.ch/tiss/templates.htm>

  • Reported: UML 2.2 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    add references with full text.

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

Language unit of Usage

  • Key: UML23-93
  • Legacy Issue Number: 14220
  • Status: closed  
  • Source: No company ( Eduardo Palermo)
  • Summary:

    On C.1 StandardProfileL2 the stereotype «create» is on language unit Dependencies, and «responsability» is on language unit Classes::Kernel. I think both belong to language unit Classes::Dependencies

  • Reported: UML 2.2 — Tue, 25 Aug 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • 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:58 GMT

Documentation of merge increments in the superstructure

  • Key: UML23-92
  • Legacy Issue Number: 14216
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    Specification: UML Superstructure v2.2 (formal/09-02-02)

    In the superstructure specification, when a class is intended primarily as an increment to be merged with some other “base” class, this is usually documented by listing the “base” class under the Generalization section, with the annotation “(merge increment)”. While such documentation of merge intent is extremely useful for the understanding of the reader, putting this documentation under the “Generalization” section is confusing, since the way package merge is now used in the superstructure abstract syntax model has nothing to do with generalization. Further, this documentation convention is not always consistently applied, especially when the class also has “real” generalizations.

    So, the specification should retain documentation for merge increments, but the overall approach for doing this should be revised and clarified, and then this approach should be applied consistently across the specification.

  • Reported: UML 2.2 — Mon, 24 Aug 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • 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:58 GMT

Japan Superstructure PAS Ballot Comments - comment 2

  • Key: UML23-97
  • Legacy Issue Number: 14259
  • Status: closed  
  • Source: Anonymous
  • Summary:

    ISO standard documents are described with "shall", "should" and "may".

    Define this standard with "shall", "should" and "may".

  • Reported: UML 2.2 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    specification uses RFC 2119 Terminology

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

Japan Superstructure PAS Ballot Comments - comment 1

  • Key: UML23-96
  • Legacy Issue Number: 14258
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Japan will approve this DIS if the TH comments will accept.

  • Reported: UML 2.2 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    The TH comments (OMG Issues 14271 - JP14, 14274 - JP17) were accepted in the approved resolutions for UML 2.3. See resolutions to OMG Issues 14271 and 14274
    Revised Text:

    Disposition: Duplicate of 14271 and 14274

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

is composite, but does not subset ownedElement

  • Key: UML24-23
  • Legacy Issue Number: 14926
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    I tried to collect critical metamodel implementation issues we have in our tool.

    Critical means that every time we must do changes in metamodel to be able to implement it.

    I believe, Eclipse UML2 implementation has exactly same issues.

    Issues may be devided into such groups:

    1. Properties which are composite, but do not subset ownedElement. Our solution - subset ownedElement

    2. Properties which are composite and subset other composite non-derived property. Our solution - make it non-composite as element can't be owned in two places

    I'm not sure all issues are reported, could someone help me manage that and check if all these are really must-be-fixed bugs?

    Most of these issues may be verified by running automatic script on metamodel file.

    See details below:

    1) is composite, but does not subset ownedElement

    Duration::expr:ValueSpecification [0..] is composite, but not ownedElement
    LinkEndData::qualifier:QualifierValue [0..*] is composite, but not ownedElement
    LinkAction::endData:LinkEndData [2..*] is composite, but not ownedElement
    TimeExpression::expr:ValueSpecification [0..] is composite, but not ownedElement
    ValuePin::value:ValueSpecification [1] is composite, but not ownedElement
    State::deferrableTrigger:Trigger [0..*] is composite, but not ownedElement
    CreateLinkAction::endData:LinkEndCreationData [2..*] is composite, but not ownedElement
    StructuredActivityNode::edge:ActivityEdge [0..*] is composite, but not ownedElement
    ValueSpecificationAction::value:ValueSpecification [1] is composite, but not ownedElement
    AcceptEventAction::trigger:Trigger [1] is composite, but not ownedElement
    DestroyLinkAction::endData:LinkEndDestructionData [2..*] is composite, but not ownedElement
    Stereotype::icon:Image [0..*] is composite, but not ownedElement
    TimeEvent::when:TimeExpression [1] is composite, but not ownedElement
    InteractionUse::argument:Action [0..*] is composite, but not ownedElement
    SequenceNode::executableNode:ExecutableNode [0..*] is composite, but not ownedElement
    Transition::trigger:Trigger [0..*] is composite, but not ownedElement
    StructuredActivityNode::node:ActivityNode [0..*] is composite, but not ownedElement

  • Reported: UML 2.3 — Thu, 7 Jan 2010 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    This issue affects the Model Interchange Working Group (MIWG).
    Issue 1 is accepted: All properties which are composite, are made to subset ownedElement.
    Issue 2 is not accepted. It is acceptable for a composition to subset another composition. This does not lead to an element being owned in two places; it leads to an element being owned in one place by two links.

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

wrong Actor's constraint [1]"

  • Key: UML24-22
  • Legacy Issue Number: 14875
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    Good point, it is clearly incorrect, as "ownedAttribute" is property of Class, not Classifier (Actor).
    Even more interesting, this is the only way to access attached associations (by checking owned properties), so I have no ideas how OCL can check attached associations when all properties are owned by association

  • Reported: UML 2.3 — Thu, 17 Dec 2009 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    Merged with 10780

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

AcceptEventAction notation

  • Key: UML24-20
  • Legacy Issue Number: 14643
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    The Notation chapter of AcceptEventAction is very weak, there is no description where Event name or Signal name could be displayed.
    It says:
    "An accept event action is notated with a concave pentagon. A wait time action is notated with an hour glass. "

    There are some usage examples in “AcceptEventAction (as specialized)” on page 309 where signal names are inside AcceptEventAction symbol, but such notation is not described under Notation !

  • Reported: UML 2.3 — Tue, 17 Nov 2009 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    This issue is obsolete. The description of the AcceptEventAction notation in the UML 2.5 beta specification, Subclause
    16.10.4, calls out the placement of names.
    Disposition: Closed - No Change

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

Some associations in the normative XMI has one memberEnd

  • Key: UML24-19
  • Legacy Issue Number: 14638
  • Status: closed  
  • Source: NASA ( Dr. Maged Elaasar)
  • Summary:

    The problems regarding some associations with one memberEnd actually started in the "unmerged" model but show themselves in the "merged" model.

    In 2.3, we added copy-down merge increments for some associations, in particular we added:

    a- InternalStructures::A_feature_classifier (Figure 9.2) as a merge increment for Kernel::A_feature_featuringClassifier (Figure 7.10)
    b- BasicComponents::A_role_connectorEnd (Figure 8.3) as a merge increment for InternlStructures::A_end_role (Figure 9.3)
    c- BasicComponents::A_end_connector (Figure 8.3) as a merge increment for InternalStructures::A_end_connector (Figure 9.3)

    The problem in (a) and (b) is that the merge-increment association has a different name than the original association, thus the package merge algorithm could not match them by name and they ended up both in the merged model. Since the navigable ends of those associations still have similar names, they were matched and merged in their respective Classes but their "association" references were set to the merge-increment associations, leaving the original association with only one reference in their "memberEnd" collections.

    Trying to rename the merge increment associations in (a) and (b) similar to the original associations (by renaming the non-navigable ends and also switching the order of memberEnds references in (b)) and re-performing the package merge, the associations got matched up and only one association in each case ended up in the merged model, as expected. However, the merge algorithm could not merge the non-navigable ends of the merge increment associations with their corresponding navigable ends in the original associations (due to a bug in the algorithm implementation I think), which should have resulted in keeping only the navigable ends, so both ends showed up in the merged model and the "memberEnd" collections had 3 references. To fix that temporarily (until the bug is fixed), I manually deleted the extraneous non-navigable ends from the resulting associations in the merged model.

    **These fixes affect Figures 9.2 and 8.3 to show the names of the non-naviagle ends

    The problem in (c) is different. The two associations have similar names and matching navigable/non-navigable ends so no problem there. The problem is that the non-navigable end of the merge increment has wrong "aggregation" and "multiplicity". Currently, its "aggregation" is "None" and its multiplicity is *, where it should have had "Composite" and 1, similar to the original association end (the resulting merged end now has "Composte" and * which violates a constraint about composite ends having multiplicity more than 1). To fix that, I just had to put the "aggregation" and "multipclity" of the merge increment similar to the original.

  • Reported: UML 2.3 — Thu, 12 Nov 2009 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    As suggested by the issue, for cases (a) and (b), both the original and the copy down association need to have the same association names, same role names and same role navigability/ownership, in order for package merge to merge them into “one” association in the target package.
    The problem in (c) is different. The two associations have similar names and matching navigable/non-navigable ends so no problem there. The problem is that the non-navigable end of the merge increment has wrong "aggregation" and "multiplicity". Currently, its "aggregation" is "None" and its multiplicity is *, where it should have had "Composite" and 1, similar to the original association end (the resulting merged end now has "Composte" and * which violates a constraint about composite ends having multiplicity more than 1). To fix that, the "aggregation" and "multiplicity" of the role in the merge increment association should be similar to the original.

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

Namespace collission due to package import

  • Key: UML24-18
  • Legacy Issue Number: 14637
  • Status: closed  
  • Source: NASA ( Dr. Maged Elaasar)
  • Summary:

    Package InfrastructureLibrary::Core::Abstractions::BehavioralFeatures contains two or more indistinguishable members named "<Class> Element."
    Package InfrastructureLibrary::Core::Abstractions::Changeabilities contains two or more indistinguishable members named "<Class> Element."
    Package InfrastructureLibrary::Core::Abstractions::Classifiers contains two or more indistinguishable members named "<Class> Element."
    Package InfrastructureLibrary::Core::Abstractions::Comments contains two or more indistinguishable members named "<Class> Element."
    Package InfrastructureLibrary::Core::Abstractions::Constraints contains two or more indistinguishable members named "<Class> Element."
    Package InfrastructureLibrary::Core::Abstractions::Expressions contains two or more indistinguishable members named "<Class> Element."
    Package InfrastructureLibrary::Core::Abstractions::Generalizations contains two or more indistinguishable members named "<Class> Element."
    Package InfrastructureLibrary::Core::Abstractions::Instances contains two or more indistinguishable members named "<Class> Element."
    Package InfrastructureLibrary::Core::Abstractions::Literals contains two or more indistinguishable members named "<Class> Element."
    Package InfrastructureLibrary::Core::Abstractions::MultiplicityExpressions contains two or more indistinguishable members named "<Class> Element."
    Package InfrastructureLibrary::Core::Abstractions::Namespaces contains two or more indistinguishable members named "<Class> Element."
    Package InfrastructureLibrary::Core::Abstractions::Ownerships contains two or more indistinguishable members named "<Class> Element."
    Package InfrastructureLibrary::Core::Abstractions::Redefinitions contains two or more indistinguishable members named "<Class> Classifier."
    Package InfrastructureLibrary::Core::Abstractions::Relationships contains two or more indistinguishable members named "<Class> Element."
    Package InfrastructureLibrary::Core::Abstractions::StructuralFeatures contains two or more indistinguishable members named "<Class> Element."
    Package InfrastructureLibrary::Core::Abstractions::Super contains two or more indistinguishable members named "<Class> Element."
    Package InfrastructureLibrary::Core::Abstractions::TypedElements contains two or more indistinguishable members named "<Class> Element."
    Package InfrastructureLibrary::Core::Abstractions::Visibilities contains two or more indistinguishable members named "<Class> Element."
    Package InfrastructureLibrary::Profiles contains two or more indistinguishable members named "<Class> Package."
    Package UML::Actions contains two or more indistinguishable members named "<Class> Classifier."
    Package UML::Actions::BasicActions contains two or more indistinguishable members named "<Class> BehavioralFeature."
    Package UML::Actions::CompleteActions contains two or more indistinguishable members named "<Class> OpaqueExpression."
    Package UML::Actions::IntermediateActions contains two or more indistinguishable members named "<Class> MultiplicityElement."
    Package UML::Actions::StructuredActions contains two or more indistinguishable members named "<Class> OutputPin."
    Package UML::Activities contains two or more indistinguishable members named "<Class> Classifier."
    Package UML::Activities::CompleteActivities contains two or more indistinguishable members named "<Class> OpaqueExpression."
    Package UML::Activities::IntermediateActivities contains two or more indistinguishable members named "<Class> OpaqueExpression."
    Package UML::AuxiliaryConstructs contains two or more indistinguishable members named "<Class> Classifier."
    Package UML::AuxiliaryConstructs::InformationFlows contains two or more indistinguishable members named "<Class> Pin."
    Package UML::Classes contains two or more indistinguishable members named "<Class> Classifier."
    Package UML::Classes::Dependencies contains two or more indistinguishable members named "<Class> Classifier."
    Package UML::CommonBehaviors contains two or more indistinguishable members named "<Class> Classifier."
    Package UML::Components contains two or more indistinguishable members named "<Class> Classifier."
    Package UML::Components::BasicComponents contains two or more indistinguishable members named "<Class> Property."
    Package UML::CompositeStructures contains two or more indistinguishable members named "<Class> Classifier."
    Package UML::CompositeStructures::Ports contains two or more indistinguishable members named "<Class> Property."
    Package UML::Deployments contains two or more indistinguishable members named "<Class> Classifier."
    Package UML::Deployments::Artifacts contains two or more indistinguishable members named "<Class> NamedElement."
    Package UML::Interactions contains two or more indistinguishable members named "<Class> Classifier."
    Package UML::Interactions::BasicInteractions contains two or more indistinguishable members named "<Class> MultiplicityElement."
    Package UML::StateMachines contains two or more indistinguishable members named "<Class> Classifier."

      • Fixes for those require fixing the spec and metamodel
  • Reported: UML 2.3 — Thu, 12 Nov 2009 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • 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:58 GMT

Cycles in package imports

  • Key: UML24-17
  • Legacy Issue Number: 14636
  • Status: closed  
  • Source: NASA ( Dr. Maged Elaasar)
  • Summary:

    "<Package> Actions" has one or more package import cycles involving "<Package> AuxiliaryConstructs, <Package> Classes, <Package> CommonBehaviors, <Package> Activities."
    "<Package> Components" has one or more package import cycles involving "<Package> AuxiliaryConstructs, <Package> Classes, <Package> CompositeStructures."
    "<Package> Deployments" has one or more package import cycles involving "<Package> AuxiliaryConstructs, <Package> Classes, <Package> CompositeStructures, <Package> Components."
    "<Package> Interactions" has one or more package import cycles involving "<Package> AuxiliaryConstructs, <Package> Classes, <Package> CommonBehaviors."
    "<Package> StateMachines" has one or more package import cycles involving "<Package> AuxiliaryConstructs, <Package> Classes, <Package> CommonBehaviors."

      • Fixes for those require fixing the spec and metamodel
  • Reported: UML 2.3 — Thu, 12 Nov 2009 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • 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:58 GMT

Errors with types of association ends not conforming to their subsetted ends

  • Key: UML24-16
  • Legacy Issue Number: 14635
  • Status: closed  
  • Source: NASA ( Dr. Maged Elaasar)
  • Summary:

    The type of AuxiliaryConstructs::Templates::RedefinableTemplateSignature::classifier does not comform to the type of the subsetted end redefinitionContext : Classifier
    The type of Classes::Interfaces::InterfaceRealization::contract does not comform to the type of the subsetted end supplier : NamedElement
    The type of CompositeStructures::Ports::A_ownedPort_encapsulatedClassifier::encapsulatedClassifier does not comform to the type of the subsetted end encapsulatedClassifier : EncapsulatedClassifier
    The type of Activities::IntermediateActivities::Activity::group does not comform to the type of the subsetted end group : ActivityGroup
    The type of Activities::IntermediateActivities::ActivityGroup::inActivity does not comform to the type of the subsetted end inActivity : Activity
    The type of Activities::CompleteActivities::ActivityNode::inInterruptibleRegion does not comform to the type of the subsetted end inInterruptibleRegion : InterruptibleActivityRegion
    The type of Classes::Interfaces::Interface::ownedAttribute does not comform to the type of the subsetted end ownedAttribute : Property
    The type of CommonBehaviors::Communications::Class::ownedReception does not comform to the type of the subsetted end ownedReception : Reception
    The type of CommonBehaviors::Communications::Interface::ownedReception does not comform to the type of the subsetted end ownedReception : Reception
    The type of Components::BasicComponents::ComponentRealization::realizingClassifier does not comform to the type of the subsetted end realizingClassifier : Classifier
    The type of CompositeStructures::InternalStructures::A_ownedConnector_structuredClassifier::structuredClassifier does not comform to the type of the subsetted end structuredClassifier : StructuredClassifier
    The type of Activities::CompleteStructuredActivities::StructuredActivityNode::structuredNodeInput does not comform to the type of the subsetted end structuredNodeInput : InputPin
    The type of Activities::CompleteStructuredActivities::StructuredActivityNode::structuredNodeOutput does not comform to the type of the subsetted end structuredNodeOutput : OutputPin
    The type of Activities::IntermediateActivities::ActivityPartition::subpartition does not comform to the type of the subsetted end subpartition : ActivityPartition
    The type of Activities::IntermediateActivities::ActivityPartition::superPartition does not comform to the type of the subsetted end superPartition : ActivityPartition
    The type of Deployments::Artifacts::Manifestation::utilizedElement does not comform to the type of the subsetted end supplier : NamedElement

      • Fixes for those require fixing the spec and metamodel
  • Reported: UML 2.3 — Thu, 12 Nov 2009 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • 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:58 GMT

Unclear constraint on stereotype associations

  • Key: UML24-28
  • Legacy Issue Number: 14961
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    18.3.3 Semantics contains the following:

    “Stereotypes can participate in 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. For these associations there must be a property owned by

    the Stereotype to navigate to the opposite class. The opposite property must be owned by the Association itself rather than

    the other class/metaclass.”

    However this is not represented in a formal Constraint and the last sentence in particular is not relevant to associations between 2 stereotypes.

  • Reported: UML 2.3 — Tue, 12 Jan 2010 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    The offending paragraph is actually in 18.3.6, not 18.3.3 as stated in the issue.
    There are two aspects to the resolution: rewording of the paragraph, and adding a formal constraint.
    The paragraph is clearly (through the repeated use of the word “opposite”) intended to convey that stereotypes can participate in binary associations. This is consistent with the corresponding limitation in MOF. The rewording recognizes this.

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

remove BehavioredClassifier::ownedTrigger

  • Key: UML24-26
  • Legacy Issue Number: 14931
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    can someone explain what is the purpose of "ownedTriggers" in BehavioredClassifier (page 435 of UML 2.3 spec) and how it should be used?
    There is nothing in the spec about it. The description is : "References Trigger descriptions owned by a Classifier".

    If it is intended to be container (or filter) of event types which can be consumed by this classifier behaviors, maybe it should be derived (from all owned behaviors)?
    The samantics section talks about "event pool" of the object at runtime, is it related?

  • Reported: UML 2.3 — Fri, 8 Jan 2010 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    In general, the event pool of an object holds events that may be dispatched to triggers of that object. However, those triggers are generally part of a state machine or activity related to the object (either as its type or as a classifier behavior of its type). The specification does not describe what the semantics of dispatching an event directly to an ownedTrigger is, since there is not response behavior associated with such triggers. And a trigger directly owned by a behaviored classifier cannot also be owned in the normal way by a state machine or activity.
    Indeed, it is not clear that owned triggers have any purpose in UML 2 as it stands, and their inclusion without any explicit semantics is confusing. Therefore, it is agreed that BehavioredClassifier::ownedTrigger should be removed.

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

lowered multiplicity

  • Key: UML24-25
  • Legacy Issue Number: 14929
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    Redefined with lowered multiplicity. It is not possible to have correct Java implementation of that, as inherited class must have getter with same name which return type is not collection, but single element. We (and Eclipse) simply ignoring these redefinitions or adding constraint which checks value number in collection.

    OccurrenceSpecification::covered [1] redefines InteractionFragment::covered [0..*]
    Transition::redefinitionContext [1] redefines RedefinableElement::redefinitionContext [0..*]
    State::redefinitionContext [1] redefines RedefinableElement::redefinitionContext [0..*]
    StateInvariant::covered [1] redefines InteractionFragment::covered [0..*]
    Extension::ownedEnd [1] redefines Association::ownedEnd [0..*]
    Region::redefinitionContext [1] redefines RedefinableElement::redefinitionContext [0..*]

  • Reported: UML 2.3 — Fri, 8 Jan 2010 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    Merged with 6200

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

Issue on generalization

  • Key: UML24-21
  • Legacy Issue Number: 14862
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    While looking over Use Cases for other changes, I realize that I’m not sure about how inheritance (generalization) works. It appears that only constraints and features are inherited. Features include structural and behavioral features, and structural features include associations.

    This seems to exclude dependencies and other directed relationships and other potentially named elements in the namespace.

    I must have something wrong, but this means that

    · include and extends are not inherited;

    · realizations are not inherited;

    · nested qualifiers are not inherited;

    · general dependencies are not inherited

  • Reported: UML 2.3 — Mon, 14 Dec 2009 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    Clause 9 is clear that it is members that are inherited. Include and extend are members. Dependencies (including
    Realizations) are not inherited. Qualifiers are owned by Properties which are inherited.
    Disposition: Closed - No Change

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

is composite and subsets not derived composite property:

  • Key: UML24-24
  • Legacy Issue Number: 14927
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    2) is composite and subsets not derived composite property:

    ProtocolTransition::preCondition:Constraint [0..]
    Profile::metaclassReference:ElementImport [0..*]
    Profile::metamodelReference:PackageImport [0..*]

    Transition::guard:Constraint [0..]
    ProtocolTransition::postCondition:Constraint [0..]
    Operation::postcondition:Constraint [0..*]
    Operation::precondition:Constraint [0..*]
    Behavior::precondition:Constraint [0..*]
    Operation::bodyCondition:Constraint [0..]
    Behavior::postcondition:Constraint [0..*]

  • Reported: UML 2.3 — Thu, 7 Jan 2010 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • 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:58 GMT

UML is vague about which Element should own Comments

  • Key: UML24-27
  • Legacy Issue Number: 14960
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    For example, if a comment appears on a Class diagram for a Package and is attached to one of the classes then should it be owned by the Class or the Package?

    What if there is no Package shown and it is attached to several Classes from multiple Packages?

  • Reported: UML 2.3 — Tue, 12 Jan 2010 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    No Data Available

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

UML 2.3: Errors in example serialization for Profiles in Chapter 18

  • Key: UML23-129
  • Legacy Issue Number: 14448
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    There are many errors in the example XMI serialization for the profile and the profile application and the xsd in section 18.3.6:

    The UML namespaces (in the definitions and the hrefs) refer to version 2.0 (and in some places inconsistently to 2.1) and should be correct for the current version

    The profile definition is missing a definition of a namespace and prefix for xmi

    The ownedMember tag should be packagedElement to be consistent with how superstructure is serialized.

    The isComposite, lower and upper tags are not valid in a superstructure serialization (and upper is not valid in an infrastructure serialization).

  • Reported: UML 2.2 — Mon, 5 Oct 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    The examples are corrected to follow the rules. We remove the schema example altogether because it presupposes that we are publishing an XML Schema for UML, and we are not doing so. The text just preceding the schema example is incomprehensible and unnecessary so is deleted.

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

errors in OCL statements of Additional Operations?

  • Key: UML23-128
  • Legacy Issue Number: 14439
  • Status: closed  
  • Source: University of Bayreuth ( Thomas Buchmann)
  • Summary:

    shouldn't the OCL statement for the Utility [1] return a collection: collect(dependency|dependency.supplier)

    instead of

    collect(dependency|dependency.client) ?

    and in the OCL statement for the Utility [2] shouldn't it be (classifier.clientDependency->...)

    instead of

    (classifier.supplierDependency->...) ?

    Please clarify.

  • Reported: UML 2.2 — Tue, 29 Sep 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • 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:58 GMT

Value of a Property

  • Key: UML23-132
  • Legacy Issue Number: 14560
  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    In several places of §7.3.44 one speaks about the value(s) of a property. However, there is no property on the Property meta-class that map to this value, except the defaultValue property. On the other hand, it is stated that "If a property is derived, then its value or values can be computed from other information " but nothing make mandatory the specification of how this value is computed.

    "isDerived", "defaultValue" and the missing "valueSpecification" property of the Property meta-class cannot be totaly independent.

    Suggested resolution :

    • Add an optional valueSpecification property to the Property meta-class with the type ValueSpecification
    • Change defaultValue to be derived according to the following constraint: {OCL}

      defaultValue = if self.isDerived then self.valueSpecification else NULL endif

  • Reported: UML 2.2 — Wed, 14 Oct 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    There is some confusion in the issue. In the UML 2.5 text it is made clear that the phrase “value of a property”
    describes the state of instances of the classifier. The property has no value except in the context of an instance.
    Disposition: Closed - No Change

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

Interface-redefinedInterface should subset Classifier-redefinedClassifier

  • Key: UML23-131
  • Legacy Issue Number: 14554
  • Status: closed  
  • Source: The MathWorks ( Mr. Salman Qadri)
  • Summary:

    In UML 2.3 and earlier, Interface-redefinedInterface subsets RedefinableElement-redefinedElement. However, since Interface specializes Classifier, the property should subset Classifier-redefinedClassifier instead, which will in turn subset RedefinableElement-redefinedElement

  • Reported: UML 2.2 — Mon, 12 Oct 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    It is legal for Interface::redefinedInterface to have a subset relation with Classifier::redefinedClassifier, even if the latter is not a derived union. Such a relation simply means that, even though there are two distinct associations, any redefinedInterface must also be a redefinedClassifier – but that there may be redefinedClassifiers (of an interface) that are not redefinedInterfaces.
    Of course, if it is desired that an interface only be able to redefine another interface, then the simplest thing to do would be to just add a constraint to Interface that all redefinedClassifiers must be interfaces. Actually, the proper way to do this is to redefined the OCL operation RedefinableElement::isConsistentWith.
    On the other hand, if we make redefinedClassifier a derived union, then we also need to add non-derived subsetting associations to all the subclasses of Classifier, not just Interface. And this would result in a definite semantics change. For example, right now a class can, seemingly, realize any classifier.
    RedefinableElement::isConsistentWith is false by default, and needs to be “must be overridden for subclasses of RedefinableElement to define the consistency conditions”. Class and Interface would therefore need to override isConsistentWith in order to define the meaning of redefinition of specific kinds of classifiers. Redefinition of classifiers was introduced in order to allow behaviors, which are Classifiers, to redefine other behaviors.
    This is possibly a bigger problem. The model for redefinable elements sets up a relatively simple but quite flexible mechanism for establishing the consistency of the redefinition of various kinds of elements. But this simply has not been used properly in the specification of most kinds of redefinable elements. However, section 7.3.24 does have a simpler error, redefinedInterface cannot subset Element::redefinedElement since it doesn?t exist. See figure 7.9 and figure 7.16. Rather than address the meaning of interface redefinition in this resolution, the error should be corrected so that at least the redefineInterface contributes to a valid subset as suggested in the issue.

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

'false' is not a member of VisibilityKind

  • Key: UML23-142
  • Legacy Issue Number: 15281
  • Status: closed  
  • Source: yahoo.com ( Scott Forbes)
  • Summary:

    under Attributes -
    visibility: VisibilityKind [1]
    Default value is false.

    'false' is not a member of VisibilityKind. I assume 'private' is intended, though I notice some tools have gone for 'public'.

  • Reported: UML 2.2 — Mon, 7 Jun 2010 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    No Data Available

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

Guard of activity edge should be optional

  • Key: UML23-141
  • Legacy Issue Number: 15251
  • Status: closed  
  • Source: IBM ( Mattias Mohlin)
  • Summary:

    The standard specifies the guard of an activity edge like this:

    guard : ValueSpecification [1..1] = true

    Hence it is required that every activity edge has a guard. This should be changed to [0..1] to make the guard optional.
    The standard should also say that if a guard is not present it means the same as a "true" guard.

    Note that the guard of a state machine transition is optional, so this change will make things more consistent

  • Reported: UML 2.2 — Thu, 6 May 2010 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • 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:58 GMT

Bug in Core::Abstractions::Super::Classifier::hasVisibilityOf

  • Key: UML23-140
  • Legacy Issue Number: 15221
  • Status: closed  
  • Source: Titian Software ( Tomasz Biegacz)
  • Summary:

    In Core::Abstractions::Super::Classifier::hasVisibilityOf there is
    Classifier::hasVisibilityOf(n: NamedElement) : Boolean;
    pre: self.allParents()>collect(c | c.member)>includes
    if (self.inheritedMember->includes ) then
    hasVisibilityOf = (n.visibility <> #private)
    else
    hasVisibilityOf = true

    This is wrong because “NamedElement” doesn’t have “visibility” attribute. In fact “Feature” doesn’t have “visibility” attribute as well, so all of the properties and operations for Classifier needs to be public. That’s why I think that for now “hasVisiblityOf” should be fixed to:
    Classifier::hasVisibilityOf(n: NamedElement) : Boolean;
    pre: self.allParents()>collect(c | c.member)>includes
    hasVisibilityOf = true

    but maybe it should be considered to add visibility attribute to Feature.

  • Reported: UML 2.2 — Fri, 23 Apr 2010 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • 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:58 GMT

Ordered derived unions

  • Key: UML23-130
  • Legacy Issue Number: 14552
  • Status: closed  
  • Source: NASA ( Dr. Maged Elaasar)
  • Summary:

    When you specify a property as an ordered derived union, with the implied derivation of union-ing the subsetting properties, how do you specify the order of the resulting union?

  • Reported: UML 2.2 — Wed, 7 Oct 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    This problem actually occurs in the UML spec itself, in the definition of ExceptionHandler::output_pins
    which relies on the ordering of Action::output, which is a derived union.
    We can specify a determinate order for the common case where all of the subsetting properties are class
    owned and there is single inheritance: which is the case for Action::output. In other cases, we can just say
    that the order is undefined.

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

Package Extension

  • Key: UML23-135
  • Legacy Issue Number: 15019
  • Status: closed  
  • Source: vtmw ( Peter Hammer)
  • Summary:

    The term "Package Extension" on page 142 seems to be obsolet and possibly may be omitted

  • Reported: UML 2.2 — Mon, 1 Feb 2010 05:00 GMT
  • Disposition: Resolved — UML 2.3
  • 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:58 GMT

Wrong Spelling for "development"

  • Key: UML23-134
  • Legacy Issue Number: 14889
  • Status: closed  
  • Source: Lockheed Martin ( John Watson)
  • Summary:

    In the first table of section C.2, the first row, <<buildComponents>>, in the column called "Description" the word development is misspelled in the phrase ”for the purpose of system level decelopment activities"

  • Reported: UML 2.2 — Tue, 22 Dec 2009 05:00 GMT
  • Disposition: Resolved — UML 2.3
  • 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:58 GMT

Cyclick dependency

  • Key: UML23-133
  • Legacy Issue Number: 14563
  • Status: closed  
  • Source: asd-software ( Jiri Schubert)
  • Summary:

    1)
    In paragraph "7.3.8 Classifier (from Kernel, Dependencies, PowerTypes)" is constraint:
    [4] self.inheritedMember->includesAll(self.inherit(self.parents()->collect(p | p.inheritableMembers(self)))

    2)
    inheritableMembers() is query with definition:
    [4] Classifier::inheritableMembers(c: Classifier): Set(NamedElement);
    pre: c.allParents()->includes(self)
    inheritableMembers = member->select(m | c.hasVisibilityOf(m))

    3)
    hasVisibilityOf() is query with definition:
    [5] Classifier::hasVisibilityOf(n: NamedElement) : Boolean;
    pre: self.allParents()>collect(c | c.member)>includes
    if (self.inheritedMember->includes) then
    hasVisibilityOf = (n.visibility <> #private)
    else
    hasVisibilityOf = true

  • Reported: UML 2.2 — Thu, 15 Oct 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • 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:58 GMT

Invalid type for NamedElement.namespace

  • Key: UML23-138
  • Legacy Issue Number: 15209
  • Status: closed  
  • Source: Titian Software ( Tomasz Biegacz)
  • Summary:

    For NamedElement there is:

    namespace: NamedElement [0..1]

    when it should be

    namespace: Namespace [0..1]

  • Reported: UML 2.2 — Mon, 19 Apr 2010 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    No Data Available

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

Invalid type for Slot.value

  • Key: UML23-137
  • Legacy Issue Number: 15208
  • Status: closed  
  • Source: Titian Software ( Tomasz Biegacz)
  • Summary:

    For Slot there is:

    value : InstanceSpecification [*]

    when it should be

    value : ValueSpecification [*]

  • Reported: UML 2.2 — Mon, 19 Apr 2010 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    See issue 10005 for disposition

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

Minor bug in Namespace::importMembers() query

  • Key: UML23-139
  • Legacy Issue Number: 15216
  • Status: closed  
  • Source: Titian Software ( Tomasz Biegacz)
  • Summary:

    There is:

    importMembers = self.excludeCollisions(imps)>select(imp | self.ownedMember>forAll(mem |
    mem.imp.isDistinguishableFrom(mem, self)))

    when it should be

    importMembers = self.excludeCollisions(imps)>select(imp | self.ownedMember>forAll(mem |
    imp.isDistinguishableFrom(mem, self)))

  • Reported: UML 2.2 — Wed, 21 Apr 2010 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • 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:58 GMT

Contents of Dependencies package

  • Key: UML23-136
  • Legacy Issue Number: 15020
  • Status: closed  
  • Source: vtmw ( Peter Hammer)
  • Summary:

    Fig. 7.15 contains two misplaced

    {subsets}

    -clauses.

    In the two associations between Dependency and NamedElement,

    {subsets target}

    only makes sense for property supplier; the same holds for

    {subsets source}

    and property client.

  • Reported: UML 2.2 — Mon, 1 Feb 2010 05:00 GMT
  • Disposition: Resolved — UML 2.3
  • 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:58 GMT

Japan Superstructure PAS Ballot Comments - comment 6

  • Key: UML23-101
  • Legacy Issue Number: 14263
  • Status: closed  
  • Source: Anonymous
  • Summary:

    GT Regarding Description, Notation and Semantics section, It is difficult to distinguish MetaClass name from general term, since there are several confusing occurrences which are shown in lower case letter. It seems those are inconsistent.

    Clarify their usages through the entire specification.

  • Reported: UML 2.2 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    Resolution:
    Context is often required to distinguish use of names - sometimes the name means both the metaclass and the common meaning of the term. Ideally, the spec should have notational conventions for these and follow them, but this would be too large an undertaking to incorporate into version 2.3 of UML.
    The Japanese National body provided the following clarification on this issue:
    "Could you just confirm the capitalization?
    We have to translate this standard to establish the Japanese Industrial Standard (JIS) after ISO standardization. In that case, unclear usage of the capitalization will make us confused."
    In many cases the capitalization is an editorial matter. There is not enough time to make a detailed proposal for making capitalization more consistent in time for this RTF.
    Should leave this issue of consistent capitalization open for discussion in future RTF for detailed proposals to be considered for resolution in the next UML version..
    Revised Text:

    Disposition: Deferred

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

Japan Superstructure PAS Ballot Comments - comment 5

  • Key: UML23-100
  • Legacy Issue Number: 14262
  • Status: closed  
  • Source: Anonymous
  • Summary:

    JP5 4,5 GE There is no terms, definitions and symbols.

    Remove the clause "4 Terms and definitions" and "5 Symbols".

  • Reported: UML 2.2 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    Leave section 4 for future revisions to add terms and definitions. Issue 14259 replaces section 5 with a new Notational Conventions section. see Issue 14259 (JP 2) resolution.
    Revised Text:

    Disposition: Duplicate of 14259

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

Japan Superstructure PAS Ballot Comments - comment 15

  • Key: UML23-109
  • Legacy Issue Number: 14272
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Fig. 13.15, 13.17, 14.12, 14.16~31, …, 16.10 E The annotations with red characters and a red arrow which outside the framework are not parts of example. They are class names and/or their attributes. Also, the arrow symbol is same as UML notation. Thus, those annotations lead misunderstand.
    *Add annotation convention to somewhere.

    • Unify the arrow symbol, someone are white hatching, others are red hatching.
  • Reported: UML 2.2 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    Suggest adding description of red annotations to section 5, Notational Conventions.

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

Japan Superstructure PAS Ballot Comments - comment 11

  • Key: UML23-105
  • Legacy Issue Number: 14268
  • Status: closed  
  • Source: Anonymous
  • Summary:

    12.4, E There is no subheading representing a particular diagram.

    Add subheading "Activity Diagram".

  • Reported: UML 2.2 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    Since the section 12 is titled Activities, it serves as the context for sub-section 12.4
    Revised Text:

    Disposition: Closed, No Change

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

Japan Superstructure PAS Ballot Comments - comment 10

  • Key: UML23-104
  • Legacy Issue Number: 14267
  • Status: closed  
  • Source: Anonymous
  • Summary:

    TL It is unclear whether the names of diagrams, e.g. Class Diagram, are within normative part or informative part of the standard.

    State clearly whether the names of diagrams, e.g. Class Diagram, are within normative part or informative part of the standard.

  • Reported: UML 2.2 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    RTF does not see why Japan thinks the names might be anything but normative - they are in Annex A clearly marked as Normative. Resolution to Issue 14265 (JP 8) results in all annexes being labeled as normative or informative.
    Revised Text:

    Disposition: Closed, No Change

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

Japan Superstructure PAS Ballot Comments - comment 17

  • Key: UML23-111
  • Legacy Issue Number: 14274
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Annex I TH This annex .defines OMG and related companies's copyright and patent condition. But ISO defines another copyright and patent condition. Remove Annex I or make it informative Annex.

  • Reported: UML 2.2 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    agreed, Annex I is no longer in UML 2.3
    Revised Text:

    Disposition: Closed, No Change

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

Japan Superstructure PAS Ballot Comments - comment 16

  • Key: UML23-110
  • Legacy Issue Number: 14273
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Table 16.1 E Many people may misunderstand the annotations inside table 16.1 are notations of graphical nodes. Remove annotations inside table 16.1.

  • Reported: UML 2.2 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    Resolution:
    add explanation of annotations.
    Revised Text:
    See Issue 14272 revision, which adds explanation of graphical annotations.

    Disposition: Duplicate of 14272

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

Japan Superstructure PAS Ballot Comments - comment 7

  • Key: UML23-102
  • Legacy Issue Number: 14264
  • Status: closed  
  • Source: Anonymous
  • Summary:

    GE There are a lot of sentences which start with Metaclass name (in upper case letter) without preceding letter. In that case, It is difficult to distinguish Metaclass name from general term.

    Clarify their usages through the entire specification. When sentence starts with metaclass name, put certain preceding letter, for example article, and make it distinguishable.

  • Reported: UML 2.2 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    Context is often required to distinguish use of names - sometimes the name means both the metaclass and the common meaning of the term. Ideally, the spec should have notational conventions for these and follow them, but this would be too large an undertaking to incorporate into version 2.3 of UML. Leave Issue open for consideration in future Revisions.
    Revised Text:

    Disposition: Deferred

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

Japan Superstructure PAS Ballot Comments - comment 13

  • Key: UML23-107
  • Legacy Issue Number: 14270
  • Status: closed  
  • Source: Anonymous
  • Summary:

    16.4 E There is no subheading representing a particular diagram.

    Add subheading "Use Case Diagram".

  • Reported: UML 2.2 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    Since the section 16 is titled "Use Cases", it serves as the context for sub-section 16.4
    Revised Text:

    Disposition: Closed, No Change

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

Japan Superstructure PAS Ballot Comments - comment 12

  • Key: UML23-106
  • Legacy Issue Number: 14269
  • Status: closed  
  • Source: Anonymous
  • Summary:

    15.4 E There is no subheading representing a particular diagram.

    Add subheading "State Machine Diagram"

  • Reported: UML 2.2 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    Since the section 15 is titled "State Machines", it serves as the context for sub-section 15.4.
    Revised Text:

    Disposition: Closed, No Change

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

Japan Superstructure PAS Ballot Comments - comment 8

  • Key: UML23-103
  • Legacy Issue Number: 14265
  • Status: closed  
  • Source: Anonymous
  • Summary:

    GT Distinction between normative and informative part is unclear.

    Make distinction between normative and informative part.

  • Reported: UML 2.2 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    Ensure that all annexes are labled as "normative" or "informative"
    All statements in the body of the spec (unless explicitly stated as informative) are considered as normative. The formal semantics of use of term "may" from resolution to Issue 14259 (jp 2) clarifies its use as in normative statements.
    Eg: In Section "Notation" in 7.3.3 Association" the sentence:
    "Users may conceptualize the dot as showing that the model includes a property of the type represented by the classifier touched by the dot."
    is a normative statement.

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

Japan Superstructure PAS Ballot Comments - comment 14

  • Key: UML23-108
  • Legacy Issue Number: 14271
  • Status: closed  
  • Source: Anonymous
  • Summary:

    17.3.1 1st paragrap, Semantics section. (There are several "physical" in the section) TH According to the standard, "Model" is restricted to "physical system". However, It is required to apply to conceptual/logical system.

    Remove "physical". Otherwise, add "conceptual/logical" before "system".

  • Reported: UML 2.2 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    agreed to remove prefix "physical" before "system" in Section 17.3.1, para 1

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

Japan Superstructure PAS Ballot Comments - comment 18

  • Key: UML23-112
  • Legacy Issue Number: 14275
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Annex J GE This is ISO standard, thus it is unnecessary OMG's procedure. Leave them as only OMG document but not ISO standard.
    Remove Annex J.

  • Reported: UML 2.2 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    Resolution:
    Agree, this annex is no longer in UML 2.3
    Revised Text:
    Annex J already removed in UML 2.3.

    Disposition: Closed, No Change

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

Irritating occurrence of subsystem stereotype in use case example diagrams

  • Key: UML241-22
  • Legacy Issue Number: 16494
  • Status: closed  
  • Source: in.tum.de ( Florian Schneider)
  • Summary:

    Referenced UML Superstructure Version: 2.4 beta2

    Issue:

    In chapter 16 on use cases, a <<subsystem>> stereotype is applied to the subject (or system boundary) in three figures:

    • Figure 16.5 - Example of the use cases and actors for an ATM system (p. 614)
    • Figure 16.8 - Example of a use case for withdrawal and transfer of funds (p. 616)
    • Figure 16.11 - Use cases owned by a package (p. 621)

    According to Table B.1 - UML Keywords (p. 712), that specific stereotype is only applicable to Component. The subject of a use case is of type Classifier.

    So the named diagrams are not syntactically wrong but slightly irritating to the reader because there is no indication that in these examples, the use case subject is actually a more specific type of a classifier, namely a component. The diagrams could lead to misinterpretations like "it is allowed to use the subsystem stereotype for any use case subject".

    The textual description for Figure 16.5 does not clarify but only states "For example, the use cases shown in Figure 16.5 on page 614 apply to the “ATMsystem” classifier"
    Regarding Figure 16.8 the accompanying text makes no clarification.
    Figure 16.11 is even more confusing as it seems to be the case that the component being subject to the use cases is part of a package. Also the package name "ATMtopPkg" does not seem to be a good name for a package.

    Recommendation:

    1) Add textual description to explain the origin of the <<subsystem>> stereotype on the three diagrams
    or
    remove subsystem stereotype as UML examples should not include constructs of any profile (even if it is one of the standard profiles)

    2) Rename "ATMtopPkg" in Figure 16.11 (e.g. to ATMNetwork)

  • Reported: UML 2.4 — Wed, 17 Aug 2011 04:00 GMT
  • Disposition: Resolved — UML 2.4.1
  • Disposition Summary:

    Merged with 18071

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

UML 2.4: NamedElement.ownedRule could be ordered

  • Key: UML241-21
  • Legacy Issue Number: 16493
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    Graphically, Constraints appear independently so the unordered
    characteristric of NamedElement.ownRule seems sensible. However in a textual
    rendering ordering is appropriate.

    For instance, Constraints may sensibly be layered so that simple Constraints
    come first and act as guards against redundant evaluation of later
    Constraints.

    For instance, when auto-generating a specification such as the OCL
    specification, a specific ordering is required in the generated output.

    Please change to

    {ordered}

    .

  • Reported: UML 2.4 — Mon, 15 Aug 2011 04:00 GMT
  • Disposition: Resolved — UML 2.4.1
  • Disposition Summary:

    The ownedRule property is actually on Namespace, not NamedElement.
    In general, it is not appropriate to add constraints to the abstract syntax in order to capture presentation issues, like the
    textual rendering of an order. Further, the UML semantics provide no requirement that ownedRules be evaluated in
    any particular order, so, as far as UML is concerned, there is no underlying meaning to such ordering.
    Disposition: Closed - No Change

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

property.opposite

  • Key: UML241-19
  • Legacy Issue Number: 16412
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    It seems there is an issue with derived Property.opposite.

    Spec says:

    / opposite : Property [0..1] In the case where the property is one navigable end of a binary association with both ends navigable, this gives the other end.

    By description, it should keep reference to opposite navigable end, but OCL works only when navigable end is owned by class.
    It does not work when navigable end is owned by association:

    Constraint #1:
    [1] If this property is owned by a class associated with a binary association, and the other end of the association is also owned by a class, then opposite gives the other end.
    opposite = if owningAssociation->isEmpty() and association.memberEnd->size() = 2 then let otherEnd = (association.memberEnd - self)>any() in if otherEnd.owningAssociation>isEmpty() then otherEnd else Set{} endif else Set {} endif

    Any comments?
    Which one is correct? Property description or constraint text?

  • Reported: UML 2.4 — Mon, 1 Aug 2011 04:00 GMT
  • Disposition: Resolved — UML 2.4.1
  • 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:58 GMT

ProfileApplication::appliedProfile as "importedProfile" instead of "appliedProfile"

  • Key: UML241-18
  • Legacy Issue Number: 16400
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    I noticed that all normative UML2.x infrastructure and superstructure documents have the same bug:

    In ProfileApplications, under Associations, the following property is incorrect:

    • importedProfile: Profile [1]
    References the Profiles that are applied to a Package through this ProfileApplication.
    Subsets PackageImport::importedPackage

    It should describe the following property ProfileApplication::appliedProfile : Profile[1] as follows:

    appliedProfile : Profile[1]
    References the Profile that is applied to a Package through this ProfileApplication.
    Subsets DirectedRelationship::target

    In the UML2.xInfrastructure metamodel and the 2.4 beta2 merged metamodel
    the documentation for ProfileApplication::appliedProfile should be changed from:

    References the Profiles that are applied to a Package through this ProfileApplication.

    to:

    References the Profile that is applied to a Package through this ProfileApplication.

    This affects the following documents:

    UML2.4 Infrastructure & Superstructure beta2 (ptc/2010-11-16 and ptc/2010-11-14)
    UML2.3 Infrastructure & Superstructure (formal/2010-05-03 and formal/2010-05-05)
    UML2.2 Infrastructure & Superstructure (formal/2009-02-04 and formal/2009-02-02)
    UML2.1.2 Infrastructure & Superstructure (formal/2007-11-04 and formal/2011-11-02)
    UML2.1.1 Infrastructure & Superstructure (formal/2007-02-06 and formal/2007-02-05)
    UML2.0 Infrastructure & Superstructure (formal/2005-07-04 and formal/2005-07-05)

    This affects the following normative files:

    http://www.omg.org/spec/UML/20101101/UML.xmi
    http://www.omg.org/spec/UML/20101101/Infrastructure.xmi
    http://www.omg.org/spec/UML/20090901/Infrastructure.cmof
    http://www.omg.org/spec/UML/20061012/Infrastructure.cmof
    http://www.omg.org/spec/UML/20061012/Infrastructure.cmof

    The same bug is also in the Documents/Specifications/2.4/Deliverable files in SVN revision 21132

  • Reported: UML 2.4 — Fri, 29 Jul 2011 04:00 GMT
  • Disposition: Resolved — UML 2.4.1
  • 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:58 GMT

ChangeEvent::changeExpression should be of type ValueSpecification

  • Key: UML241-25
  • Legacy Issue Number: 16896
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Mr. Marc-Florian Wendland)
  • Summary:

    Subsection Associations is not in synch with the abstract syntax depicted in Figure 13.12.

    In the abstract syntax, change expression is typed by ValueSpecification, whereas in Association section it is described as Expression.

    Possible resolution:

    Change changeExpression : Expression

    to

    changeExpression : ValueSpecification.

  • Reported: UML 2.4 — Wed, 14 Dec 2011 05:00 GMT
  • Disposition: Resolved — UML 2.4.1
  • 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:58 GMT

Validity duration of implicitly assigned parameters in SignalEvent/CallEvent

  • Key: UML241-24
  • Legacy Issue Number: 16649
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Mr. Marc-Florian Wendland)
  • Summary:

    The textual syntax of CallEvent and SignalEvents states the following:

    "<call-event> :: <name> [‘(‘ [<assignment-specification>] ‘)’]
    <assignment-specification> ::= <attr-name> [‘,’ <attr-name>]*

    <assignment-specification> is optional and may be omitted even if the operation has parameters."

    Does this mean that the parameters of the event are still assigned to attributes of the context object? If so, how long are those implicitly assigned
    attribute values stored in the context object? Since this is just a workaround to be able to express guard conditions that evaluate whether a transition can fire based
    on the recieved trigger, I would assume, the implicitly assigned attribute values are kind of transient or temporarly and will become invalid (or deleted) after all guards of the outgoing state are evaluated. Otherwise, I would like have this paragraph stated
    clearer. It is a vital and crucial part how to deal with triggering events and with guard that refer to those trigger events.

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

    There is no implication in this notation of “transient” or “temporary” assignment. The values are assigned to the given
    attributes, which retain those values until reassigned. However, the exact mechanism for accomplishing the intent
    behind this notation is not formalized in the specification. The UML 2.5 specification now includes the following
    clarification (from Subclause 13.3.4):
    “<assignment-specification> is optional and may be omitted even if the Operation has Parameters. No standard mapping
    is defined from an assignment specification to the UML abstract syntax. A conforming tool is not required to
    support this notation. If it does, it may provide a mapping to standard UML abstract syntax, e.g., by implicitly inserting
    Actions to carry out the behavior implied by the notation.”
    Disposition: Closed - No Change
    Report

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

XMI in small caps

  • Key: UML241-17
  • Legacy Issue Number: 16363
  • Status: closed  
  • Source: Visionnaire ( Sergio Mainetti)
  • Summary:

    On page 177, Clause 12, second paragraph, in the middle, XMI is written
    in small case, as "...whose xmi serialization...", maybe it's recomended
    to write in upper case as in the rest of the document.

  • Reported: UML 2.4 — Fri, 8 Jul 2011 04:00 GMT
  • Disposition: Resolved — UML 2.4.1
  • 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:58 GMT

Core Package versus Construct Package

  • Key: UML241-16
  • Legacy Issue Number: 16362
  • Status: closed  
  • Source: Visionnaire ( Sergio Mainetti)
  • Summary:

    On page 14, Figure 7.3 of the OMG Unified Modeling Language (OMG UML),
    Infrastructure document, I think there's a small error in the picture.

    The picture details the Core package, as explained in the text. But
    the name in the top of the package is written as "Construct" (please
    note that I'm talking about the name of the whole package, the left-
    hand side one in the picture, and not the name os the sub-package
    Construct itself).

    It gets a little bit confusing that the name of the whole package
    is written as "Construct" instead of "Core".

    Please note also that the Figure "Part II, Figure 2" on page 27 is
    the same. And Figure 9.1 on page 29. And Figure 10.1 on page 91. And
    11.1 on page 103. And maybe others that I couldn't find now.

  • Reported: UML 2.4 — Fri, 8 Jul 2011 04:00 GMT
  • Disposition: Resolved — UML 2.4.1
  • 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:58 GMT

UML Appendix A : Figure A.3 Two Diagrams of Packages”

  • Key: UML241-20
  • Legacy Issue Number: 16483
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    In “Figure A.3 Two Diagrams of Packages” the left most diagram has a header that says:

    “i) Package symbol (as part of a larger diagram diagram)”

    This text should be (as far as I can figure out)

    “i) Package symbol (as part of a larger package diagram)”

    Similarly, the paragraph before the diagram has the following text

    “Figure A.3 illustrates that a package symbol for package P (in some containing package CP) may show the same contents as the class diagram for the package. i) is a diagram for package CP with graphical symbols representing the fact that the CP package contains a package P.”

    To clarify this, make the following one word change

    “Figure A.3 illustrates that a package symbol for package P (in some containing package CP) may show the same contents as the class diagram for the package. i) is a package diagram for package CP with graphical symbols representing the fact that the CP package contains a package P.”

  • Reported: UML 2.4 — Tue, 2 Aug 2011 04:00 GMT
  • Disposition: Resolved — UML 2.4.1
  • Disposition Summary:

    Accept the proposals

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

XML Metadata Interchange (XMI) - p9

  • Key: UML241-15
  • Legacy Issue Number: 16361
  • Status: closed  
  • Source: Visionnaire ( Sergio Mainetti)
  • Summary:

    On page 9 of the OMG Unified Modeling Language (OMG UML), Superstructure
    document, there is the same error (or maybe, typo) as in the Infrastructure
    document. It's in the seventh bullet at the beginning of the page, where
    it's written:

    XMI Metadata Interchange (XMI)

    Maybe the correct text would be:

    XML Metadata Interchange (XMI)

    That is, XML instead of XMI at the beginning of the phrase.

  • Reported: UML 2.4 — Fri, 8 Jul 2011 04:00 GMT
  • Disposition: Resolved — UML 2.4.1
  • 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:58 GMT

XML Metadata Interchange (XMI)

  • Key: UML241-14
  • Legacy Issue Number: 16360
  • Status: closed  
  • Source: Visionnaire ( Sergio Mainetti)
  • Summary:

    On page 5 of the OMG Unified Modeling Language (OMG UML), Infrastructure
    document, I think there's a small error (maybe a typo). It's in the last
    line of this page, where it's written:

    XMI Metadata Interchange (XMI)

    Maybe the correct text would be:

    XML Metadata Interchange (XMI)

    That is, XML instead of XMI at the beginning of the phrase.

  • Reported: UML 2.4 — Fri, 8 Jul 2011 04:00 GMT
  • Disposition: Resolved — UML 2.4.1
  • 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:58 GMT

Implicit parameter assignment may cause name clashes

  • Key: UML241-23
  • Legacy Issue Number: 16648
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Mr. Marc-Florian Wendland)
  • Summary:

    The textual syntax of CallEvent and SignalEvents states the following:

    "<call-event> :: <name> [‘(‘ [<assignment-specification>] ‘)’]
    <assignment-specification> ::= <attr-name> [‘,’ <attr-name>]*

    <attr-name> is an implicit assignment of the corresponding parameter of the operation to an attribute (with this name)
    UML Superstructure Specification, of the context object owning the triggered behavior"

    This may lead to a situation where name clashes can occurr, if the context object already contains an identically named attibute.
    How should situations like a name clashes be resolved?

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

    The corresponding wording in the UML 2.5 specification is (from Subclause 13.3.4):
    “<assigned-name> is an implicit assignment of the argument value for the corresponding Parameter of the Operation
    to a Property or Variable of the context object for the triggered Behavior.”
    The “assigned-name” is the name of a Property or Variable that the context object already contains, not a definition of
    a new attribute. There is therefore no possibility of “name clash”.
    Disposition: Closed - No Change

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

Number of Compliance Levels

  • Key: UML241-13
  • Legacy Issue Number: 16359
  • Status: closed  
  • Source: Visionnaire ( Sergio Mainetti)
  • Summary:

    In the OMG Unified Modeling Language (OMG UML), Infrastructure document,
    it is said that this document, and the Superstructure document, should be
    used in conjunction (page 9) as the two volumes cross-reference each other
    and the specifications are fully integrated.

    But on page 2 of the OMG Unified Modeling Language (OMG UML), Infrastructure
    document we can find 2 compliance levels. And on page 2 of the OMG Unified
    Modeling Language (OMG UML), Superstructure document (ptc/2010-11-14 version
    2.4) we can find 4 compliance levels. Which is rioght ? Two our four ? As
    both documents are integrated shouldn't them have the same explanation for
    compliance levels ?

    It gets a little confusing to understand this.

  • Reported: UML 2.4 — Fri, 8 Jul 2011 04:00 GMT
  • Disposition: Resolved — UML 2.4.1
  • 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:58 GMT

Presentation options of statemachine transitions: Figure 15.45 is ambiguous or wrong

  • Key: UML241-2
  • Legacy Issue Number: 16002
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Arnaud Cuccuru)
  • Summary:

    Figure 15.45 of superstructure v2.3 illustrates the representation of deferred triggers on states. The transition between states "Get Cups" and "Pour coffee" specifies a trigger "light goes out" which is also identified as a deferred trigger of state "Get Cups". Does "light goes out" trigger the transition, or is it deferred? If the figure is not wrong, it would probably be helpful to add a comment in the text (note that figure 15.45 is not referenced in the text).

  • Reported: UML 2.4 — Tue, 1 Feb 2011 05:00 GMT
  • Disposition: Resolved — UML 2.4.1
  • Disposition Summary:

    Indeed, this is a very confusing example and is also wrong as the submitter points out. Also, there should
    be some explanation of this diagram.
    Replace this diagram with a simpler one and add some explanatory text.

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

Can a Generalization really be in multiple GeneralizationSets?

  • Key: UML241-1
  • Legacy Issue Number: 15993
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    According to the abstract syntax, Generalization::generalizationSet has upper bound *.

    According to the text:

    Package PowerTypes A generalization can be designated as being a member of a particular generalization set.

    There is only one place where the possibility of many sets is mentioned, where it says:

    “The generalizationSet association designates the collection of subsets to which the Generalization link belongs. All of the Generalization links that share a given general Classifier are divided into subsets (e.g., partitions or overlapping subset groups) using the generalizationSet association. Each collection of subsets represents an orthogonal dimension of specialization of the general Classifier.”

    The first of these sentences implies that a Generalization can belong to many (“collection of”) GeneralizationSets. The second sentence contains a phrase “subsets (e.g., partitions or overlapping subset groups)” that makes little sense. Rephrasing “subset groups” as “subsets” gives us “e.g., partitions or overlapping subsets” which seems to imply that the GeneralizationSets may overlap. But then “Each collection of subsets represents an orthogonal dimension of specialization” translates to “each collection of GeneralizationSets represents an orthogonal dimension…” which is obviously wrong. Rephrasing as “Each GeneralizationSet represents an orthogonal dimension …” makes more sense: but if they are orthogonal, how can they overlap?

    Then, in the notation and further explanations, there is no discussion whatsoever of the possibility of a generalization belonging to many GeneralizationSets.

    I think this is clearly an error in the metamodel.

  • Reported: UML 2.4 — Thu, 27 Jan 2011 05:00 GMT
  • Disposition: Resolved — UML 2.4.1
  • Disposition Summary:

    The text that the issue complains about is no longer in the spec. It’s clear that a Generalization can belong
    in more than one GeneralizationSet: “The generalizationSet property designates the GeneralizationSets to
    which the Generalization belongs.”
    However, there is a misleading phrase in the Notation that could be improved.

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

No Rules for Element Names

  • Key: UML241-5
  • Legacy Issue Number: 16115
  • Status: closed  
  • Source: email.com ( Kirill Fakhroutdinov)
  • Summary:

    UML specification does not provide exact rules for element names. For example, namespace "provides a means for resolving composite names, such as name1::name2::name3." What are the rules for the name1/2/3? Could we use spaces, dashes, digits?
    For the class name we should: "capitalize the first letter of class names (if the character set supports uppercase)." But what are the rules for the class name? "A use case is shown as an ellipse, either containing the name of the use case or with the name of the use case placed below the ellipse." But what are the rules for the use case name?

  • Reported: UML 2.4 — Sun, 17 Apr 2011 04:00 GMT
  • Disposition: Resolved — UML 2.4.1
  • Disposition Summary:

    There are no rules for names in UML. The UML standard does not restricted what characters can be used in a name
    or how the name is constructed.
    Disposition: Closed - No Change

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

Figure 15.32

  • Key: UML241-4
  • Legacy Issue Number: 16111
  • Status: closed  
  • Source: Anonymous
  • Summary:

    I downloaded (and partially read) the UML Superstructure file "10-05-05.pdf" from your site. That's one of two defining documents of UML 2.3.

    Figure 15.32 shows the "Typing password" state from a Statechart diagram. It defines two "entry" actions: setEchoInvisible and setEchoNormal. Clearly, the second action should be an exit action, not an entry action. Can you correct this error in the next version of the document? It's a minor error, but you'll agree with me that it's a bad example this way, I suppose.

  • Reported: UML 2.4 — Fri, 18 Mar 2011 04:00 GMT
  • Disposition: Resolved — UML 2.4.1
  • Disposition Summary:

    Agreed. This is diagram 14.5 in the new text.
    Fix the diagram by replacing the second “entry” label with the label “exit”.

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

Figure 15.32

  • Key: UML241-8
  • Legacy Issue Number: 16169
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Figure 15.32 shows the "Typing password" state from a Statechart diagram. It defines two "entry" actions: setEchoInvisible and setEchoNormal. Clearly, the second action should be an exit action, not an entry action. Can you correct this error in the next version of the document? It's a minor error, but you'll agree with me that it's a bad example this way, I suppose

  • Reported: UML 2.4 — Fri, 18 Mar 2011 04:00 GMT
  • Disposition: Resolved — UML 2.4.1
  • Disposition Summary:

    Merged with 16111

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

Typo: "joint" should say "join"

  • Key: UML241-7
  • Legacy Issue Number: 16164
  • Status: closed  
  • Source: asu.edu ( Joe Mooney)
  • Summary:

    Typo: say join and not joint.

    The notation for a fork and join is a short heavy bar (Figure 15.25). The bar may have one or more arrows from source
    states to the bar (when representing a joint).

  • Reported: UML 2.4 — Wed, 4 May 2011 04:00 GMT
  • Disposition: Resolved — UML 2.4.1
  • Disposition Summary:

    It should indeed be “join” and not “joint”. Correct the text appropriately

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

Section: Activities: Modifications to the approved resolution of 10815

  • Key: UML22-1141
  • Legacy Issue Number: 12433
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Modifications to the approved resolution of 10815. It should use a different keyword for decision input flows than the existing one for decision input behaviors. It should include an update to the notation figure, and to the keyword index.

  • Reported: SysML 1.0 — Fri, 9 May 2008 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Revise the resolution to 10815 as suggested

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

Diagram metaclass shall be introduced and shall be subclass of Element

  • Key: UML22-1122
  • Legacy Issue Number: 10819
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    Diagram metaclass shall be introduced and shall be subclass of Element, because every tool need to add Diagrams into packages (and uses hacks to do that) , Dependencies between diagrams is usable also. Stereotypes for diagrams are also used and even represented in DiagramFrame notation

  • Reported: UML 2.1 — Fri, 23 Feb 2007 05:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Discussion: This is definitely outside the scope of an RTF. However, it is also very much against one of the fundamental architectural principles of UML, that the abstract and concrete syntaxes are to be kept distinct. For instance, it should be possible to provide a UML concrete syntax that is completely textual and, hence, has no notion of diagram. Finally, the question of defining concrete syntaxes for MOF-based modeling languages and the issue of how these relate to the models themselves is being addressed by a separate RFP (the “Diagram Definition RFP”). Disposition: Closed, no change

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

Setting structural features of a data type

  • Key: UML22-1121
  • Legacy Issue Number: 10816
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    Document: Unified Modeling Language: Superstructure, Version 2.1.1 (formal/2007-02-03)
    Sections: 11.3.12 (ClearStructuralFeatureAction) and 11.3.53 (WriteStructuralFeatureAction)

    (This issue surfaced during work on the Semantics of a Foundational Subset for Executable UML Models submission.)

    Background:

    Use the term "structured" data type to refer to a data type that is not a primitive type or an enumeration. Such a data type may have attributes, which can be read and written by the read and write structural feature actions (for the purposes of this discussion, consider clear structural feature action to be a kind of write structural feature action).

    Semantically, the main difference between a data value that is an instance of a structured data type and an object that is an instance of a class is that a data value is passed "by value" while an object is passed "by reference". That is, a data value is itself a true value that can be passed as a parameter value to behavior and can flow on "object" flow edges ("object flow" really isn't a better name than "data flow", but the way...). On the other hand, an object exists with its own identity in the extent of their class at a specific locus, and only references to an object can be passed as values.

    Thus, there may be many references all to the same object. As a result of this, any change to the attributes of an object via one reference will be reflected in future reads of that attribute via different references to that object.

    In the case of a structured data value, however, a change to one of its attributes will only be reflected in the value actually being acted on. If that value is not then itself passed on, this change will not be visible in any other data value. Unfortunately, write structural feature actions do not have output pins. The assumption seems to be that such writes always happen "in place". This works for objects that have their own identity, but there is no clear "place" for which the change can happen for structured data values.

    Note that this would still be an issue even if variables were allowed in fUML (and so it is an issue in full UML 2 with variables, too). To change a value in a variable, one needs to use a read variable action. If the value in the variable is a structured data value, then the read variable action will place a "by value" copy of the data value on the output pin of the action (since data values don't have identity or references, it can't really do anything else...). Therefore, a write structural value action acting on the output of a read variable action will make a change to this copy, not the value in the variable. But then, since the write structural value action has no output pin, there is no way to get the changed copy back into the variable (or use it in any other way, for that matter.)

    Proposed resolution:

    Add an output pin to write structural feature actions. If the "object" being acted on is really an object (that is, an instance of a class), then the input reference to that object is just place on the output pin. But if the "object" being acted on is a data value (that is, an instance of a structured data type), then the value placed on the output pin is a copy of the input data value, but with the given structural feature value appropriately updated.

    (Note that the output pin is not strictly necessary for a true object update, but it seems simpler to always have the output pin. In the case of a write to an object, the output pin can simply be ignored – though it might sometimes be convenient even in this case for "chaining" actions on an object.)

  • Reported: UML 2.1 — Fri, 9 Mar 2007 05:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    No Data Available

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

Figure 7.14: "Type" does not show its inheritance from "PackageableElement"

  • Key: UML22-1124
  • Legacy Issue Number: 10828
  • Status: closed  
  • Source: International Business Machines ( Andreas Maier)
  • Summary:

    In the Superstructure spec 2.1.1, in figure 7.14, the "Type"
    metaclass is shown right below the "PackageableElement" metaclass,
    but without any inheritance arrow between them. This is not wrong,
    since a class diagram is not obliged to show all existing
    relaitonships.

    However, it would ease the understanding and be consistent if in this
    case, the inheritance arrow between these two metaclasses was shown
    in that figure.

  • Reported: UML 2.1 — Sat, 17 Mar 2007 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Discussion: This strikes me as a matter of taste; someone else might object to the generalization being shown in this diagram since it would clutter the diagram. Disposition: Closed, no change

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

ConnectorEnd shall have references to provided or required interfaces

  • Key: UML22-1123
  • Legacy Issue Number: 10820
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    ConnectorEnd shall have references to provided or required interfaces. It helps to use assembly connectors in composite structure diagrams between parts and ports, connector will be able to display two compatible interfaces using "ball in socket" notation.
    Now it is impossible to implement that, because there are no references to interfaces.

  • Reported: UML 2.1 — Fri, 23 Feb 2007 05:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Resolution: There are two problems with this issue: (a) The ball-and-socket notation is unique to the components chapter, so this issue cannot be resolved in general for ConnectorEnd, but would have to be addressed specifically in the components chapter by introducing a subtype of ConnectorEnd. More importantly, though, (b) connectors do not have a semantic relation to interfaces. They connect ports or parts based on their compatability. The compatability between interfaces is a derived notation, and does not require metamodel support. Disposition: Closed, no change

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

constraining Classifiers

  • Key: UML22-1134
  • Legacy Issue Number: 11243
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    It should be possible to specify multiple constraining classifiers for ClassifierTemplateParameter.
    For example, Java programming language allows to specify multiple interfaces as constraining types of template parameter, I see no reasons why UML can't allow several constraining types.

    Resolution:

    17.5.8
    Change multiplicity of "constrainingClassifier" from [0..1] to [0..*].

  • Reported: UML 2.1.1 — Mon, 6 Aug 2007 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    No Data Available

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

defaultClassifier of ClassifierTemplateParameter

  • Key: UML22-1133
  • Legacy Issue Number: 11240
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    Problem:

    "defaultClassifier" of ClassifierTemplateParameter shall redefine "default" of TemplateParameter and restrict type to Classifier.

    "default" shall be not accessible in ClassifierTemplateParameter.

    Resolution:

    Add

    {redefines default} to end of "defaultClassifier"property description in chapter 17.5.8 ClassifierTemplateParameter

    Add {redefines default}

    in metamodel association. Unfortunately diagram of abstract syntax of ClassifierTemplateParameter is not included into 17.5 Templates chapter.

    It should be added also.

  • Reported: SysML 1.0 — Wed, 1 Aug 2007 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Remove this redundant association

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

Section: 9.3.11 p 182

  • Key: UML22-1129
  • Legacy Issue Number: 11087
  • Status: closed  
  • Source: UPM ( Juan Pedro Silva)
  • Summary:

    All rolenames in non-navigable associations in the UML metamodel should be stated, to allow reaching from one element of the association to the other using OCL. Currently, this is limited to un-ambigous type names if the rolename is not stated. For example, in section "9.3.11 Port (from Ports)", Port has required and provided interfaces, and has no rolename on both associations. There is no current way, using OCL, of getting from one Interface to a Port that provides or requires it, as "self.port" is ambigous because it doesn't specify if the programmer is looking for Ports providing or requiring such Interface. The situation repeats in many other associations.

  • Reported: UML 2.1.1 — Thu, 31 May 2007 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Discussion: It is not required for the specification to name such associations. Navigation is not that hard if this is really desired: find all ports and select the subset that has the appropriate interface. Also, OCL is not constrained by navigability. Discussion: Closed, no change

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

Wrong notation description

  • Key: UML22-1128
  • Legacy Issue Number: 11007
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    "A component realization is notated in the same way as the realization dependency (i.e., as a general dashed line with an open arrow-head). ", BUT
    A Realization dependency is shown as a dashed line with a triangular arrowhead at the end that corresponds to the realized element

  • Reported: SysML 1.0 — Wed, 16 May 2007 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    agreed

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

Section: 9.3.8

  • Key: UML22-1127
  • Legacy Issue Number: 11004
  • Status: closed  
  • Source: NIST ( Mr. Peter Denno)
  • Summary:

    In UML 2.1.1 L3 metamodel (and the UML 2.1.1 Superstructure spec) EncapsulatedClassifier.ownedPort is declared to be derived. No derivation is provided and it seems unlikely that one was intended. For a list of other properties declared derived for which there is no derivation, see the 2006-12-09 entry here: http://syseng.nist.gov/se-interop/plugfest/tools/changelog

  • Reported: UML 2.1.1 — Mon, 14 May 2007 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Discussion: This derivation is given: EncapsulatedClassifier.ownedPort is all ownedAttributes that are of type Port. Disposition: Closed, no change

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

page 449 chapter 13.3.24 (Signal (from Communications)

  • Key: UML22-1126
  • Legacy Issue Number: 11003
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    there is a mistake in document formal/07-02-03 (UML Superstructure,
    v2.1.1) on page 449 chapter 13.3.24 (Signal (from Communications)). A
    Signal does not have an association to a signal of type Signal. It is
    probably a mix-up with SignalEvent

  • Reported: SysML 1.0 — Mon, 14 May 2007 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Discussion: Duplicate of issue 10960 Revised Text: N/A Disposition: Duplicate

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

UML 2 superstructure -- figure 9.4 is duplicate of figure 9.3

  • Key: UML22-1125
  • Legacy Issue Number: 10992
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Figure 9.4 in formal/07-02-05 is a duplicate of figure 9-3. There should be a different diagram in place of figure 9-4 that shows the ports metamodel.

  • Reported: SysML 1.0 — Tue, 8 May 2007 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Discussion: Fixed in 2.1.2 Revised Text: N/A Disposition: Closed, no change

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

Change multiplicity of ClassifierTemplateParameter role

  • Key: UML22-1136
  • Legacy Issue Number: 11400
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    Problem:
    The same Classifier could be used only in one template parameter as "constrainingClassifier", it brokes usage of ClassifierTemplateParameters.

    Solution:
    Change multiplicity of ClassifierTemplateParameter role from "1" to "*" on association between ClassifierTemplateParameter and Classifier in Figure 17.18 - Classifier templates

  • Reported: UML 2.1.1 — Thu, 13 Sep 2007 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    No Data Available

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

Any ownedBehavior should be able to have AcceptEventAction

  • Key: UML22-1135
  • Legacy Issue Number: 11265
  • Status: closed  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    Section 13.3.31, Trigger indicates the receipt of an event by and active object can either directly cause the occurrence of a behavior, or is delivered to the classifier behavior. This is insufficient. An Event should be able to be handled by any active AcceptEventAction in any thread of control in any running method Activity that is an ownedBehavior of the receiving object. This is how events are commonly handled in business process models and BPEL. It allows an active object to indicate when it is able to accept a call or signal event at a specific point in an already running method activity. If there are more than one such AcceptEventAction, then the AcceptEventAction that handles the event is arbitrary.

  • Reported: UML 2.1.1 — Thu, 9 Aug 2007 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    No Data Available

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

composite values

  • Key: UML22-1132
  • Legacy Issue Number: 11239
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    UML 2.1.1

    Problem:

    Duration value and TimeExpression value can't be owned by Duration or TimeExpression.

    Solution:

    Make Duration "expr" and TimeExpression "expr" properties composite.
    Change Figure 13.13 SimpleTime to reflect these ownerships.

  • Reported: SysML 1.0 — Wed, 1 Aug 2007 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    No Data Available

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

Section: 9 composite structures

  • Key: UML22-1131
  • Legacy Issue Number: 11164
  • Status: closed  
  • Source: Student at IFI UIO Norway ( Tormod Vaksvik Håvaldsrud)
  • Summary:

    Figure 9.3 : Is it riht that a connector can hold more than 2 ConnectorEnds? It is stated that it can hold: 2..*

  • Reported: SysML 1.0 — Fri, 20 Jul 2007 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Discussion: Yes, it is possible that a connector have more than 2 ends, in case it is an n-way connector. Disposition: Closed, no change

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

"representation"

  • Key: UML22-1130
  • Legacy Issue Number: 11089
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    Classifier from Kernel packages has "representation" property of type InformationItem.
    Classifier from Collaborations package has "representation" property of type CollaborationUse.

    After package merge these properties conflict, one of them shall be renamed.

  • Reported: SysML 1.0 — Tue, 5 Jun 2007 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    No Data Available

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

TimeEvent

  • Key: UML22-1138
  • Legacy Issue Number: 11409
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    TimeEvent has "when" property for time value.

    13.3.27 TimeEvent

    • when: TimeExpression [1] Specifies the corresponding time deadline.

    However in Figure 13.13 - SimpleTime Time Event has association with ValueSpecification.

    Model shall correspond to text, so Figure 13.13 shall be fixed.

  • Reported: UML 2.1.1 — Fri, 14 Sep 2007 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    No Data Available

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

Figure 14.5 - Messages.

  • Key: UML22-1137
  • Legacy Issue Number: 11401
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    Problem:
    Only one MessageEnd could have the same Message as "message", because of multiplicity [0..1] near MessageEnd on association between Message and MessageEnd in Figure 14.5 - Messages.

    Solution:
    Change multiplicity [0..1] near MessageEnd on association between Message and MessageEnd to [0..2] in Figure 14.5 - Messages.

  • Reported: UML 2.1.1 — Thu, 13 Sep 2007 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    No Data Available

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

Section: 7.3.7

  • Key: UML22-1140
  • Legacy Issue Number: 11625
  • Status: closed  
  • Source: Volvo Technology Corporation ( Hans Blom)
  • Summary:

    nestedClassifier should subset Namespace::ownedMember. There is no ownedMember in Element, i.e. Element::ownedMember is incorrect.

  • Reported: UML 2.1.1 — Mon, 22 Oct 2007 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    This is a subset of the problem raised in issue 10829 Revised Text: N/A Disposition: Duplicate

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

Figures 9.4 identical to figure 9.3

  • Key: UML22-1139
  • Legacy Issue Number: 11524
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Figures 9.4 should show the Port metaclass, but it is identical to Figure 9.3, Connectors

  • Reported: UML 2.1.1 — Fri, 28 Sep 2007 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Discussion: Fixed in an earlier release Revised Text: N/A Disposition: Closed, no change

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

Flowing data into decision input behaviors

  • Key: UML22-1120
  • Legacy Issue Number: 10815
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    Document: Unified Modeling Language: Superstructure, Version 2.1.1 (formal/2007-02-03)
    Sections: 12.3.22, DecisionNode

    (This issue surfaced during work on the Semantics of a Foundational Subset for Executable UML Models submission.)

    Background

    There is no direct way to flow a supporting value into the decision input behavior of a decision node.

    Suppose one wants to set up a decision node with a decision input behavior that, say, takes an object as an input and tests whether an attribute of that object has a certain value. Further, suppose that value is given by an input parameter of the enclosing activity. The value of the parameter is provided via an activity parameter node, but there is no direct way to connect an object flow from the activity parameter node to the test for the decision node.

    Currently, a decision input behavior can only have a single input parameter, which will get the object flowing into the decision node that is to be tested. And, since it is a separate behavior from the enclosing activity, a flow from the enclosing activity can't be connected into the decision behavior. Of course, it would be possible to save the parameter value into an attribute of the enclosing activity, and then read that attribute in the decision behavior – but this seems awfully round about!

    Note that there is no problem using a Conditional Node since, in that case, the test is not a separate behavior, and data can flow from the enclosing action into the test. It is just with (the supposedly simpler) Decision Node that there is a problem.

    Proposal

    Decision nodes may optionally have one additional incoming edge identified as the "decision input". If there is no decision input behavior, tokens offered on the decision input edge are made available to the guards on outgoing edges to determine whether the offer on the other incoming edge is passed along that edge. If there is a decision input behavior and a decision input edge, the token offered on the decision input edge is passed to the behavior (as the only argument if the regular incoming edge is control flow, as the second argument if it is object flow). Decision nodes with the additional decision input edge will offer tokens to outgoing edges only when one token is offered on each incoming edge.

  • Reported: UML 2.1 — Fri, 9 Mar 2007 05:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Adopt as proposed

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

Section: Composite Structures

  • Key: UML22-1119
  • Legacy Issue Number: 10814
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Figure 9.4 duplicates 9.3

  • Reported: UML 2.1.1 — Sat, 10 Mar 2007 05:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Discussion: Fixed in 2.1.2 Revised Text: N/A Disposition: Closed, no change

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

issue regarding required and provided interfaces

  • Key: UML22-1107
  • Legacy Issue Number: 10354
  • Status: closed  
  • Source: International Business Machines ( James Bruck)
  • Summary:

    There appears to be an issue with required and provided interfaces of Components in the UML2 Super Structure specification 2006-04-02 section 8.3.1., p.151 .

    In the OCL and the paragraph discussing required and provided interfaces there is no mention of inheriting provided or required interfaces from the supertypes of the component.
    Should we also consider required or provided interfaces of inherited ports?
    Should we also consider supertypes of realizing classifiers?

    The fact that Components don't consider supertypes is contrary to how Ports get required and provided interfaces on p187. Ports consider supertypes of the classifiers that type them when collecting required and provided interfaces.

  • Reported: UML 2.1 — Tue, 19 Sep 2006 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    No Data Available

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

UML 2: Semantics of isOrdered need to be clarified

  • Key: UML22-1106
  • Legacy Issue Number: 10151
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Text should read something like:

    isOrdered : Boolean For a multivalued multiplicity, this
    attribute specifies whether the values in an instantiation of this
    element are maintained in the order that they where insertedsequentially
    ordered. Default is false.

  • Reported: UML 2.1 — Fri, 1 Sep 2006 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Actually, the original description is more general, since the ordering can be based on different ordering criteria, not just based on the order of insertion. Revised Text: N/A Disposition: Closed, no change

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

Ptc/06-04-02/Pg 188

  • Key: UML22-1118
  • Legacy Issue Number: 10788
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    Where the spec currently says:

    “If the port was typed by a class, the interaction point object will be an instance of that class. The latter case allows elaborate specification of the communication over a port. For example, it may describe that communication is filtered, modified in some way, or routed to other parts depending on its contents as specified by the classifier that types the port.”

    Consider whether this should in fact be defined as a semantic variation point.

  • Reported: UML 2.1 — Tue, 27 Feb 2007 05:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Resolution: The dynamic semantics of a port, when it is typed by a class, is already a semantic variation point. Most of the text above is an example, rather than a definition of behavior. The only normative text above is that the interaction point object will be an instance of the type of the port, if the port is typed by a class. That aspect is currently used by tools to give dynamic semantics to ports in a domain-specific manner. If such is not desired, the modeler can always close the semantic variation point as to the meaning of this construct to behave as desired, e.g., to reduce to the case where the type of the port is an interface. Disposition: Closed, no change

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

Section: 7.3.32

  • Key: UML22-1117
  • Legacy Issue Number: 10783
  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    It should be possible to set the upperBound of a MultiplicityElement to 0 (it's currently forbidden by the constraint [1]). Example : if a class A is associated to a class B with a multiplicity of "0..*" (on the role of B). It should be possible to derive from the class A a class C of which the multiplicity of the role of B is always "0".

  • Reported: UML 2.1.1 — Wed, 21 Feb 2007 05:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    No Data Available

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

A notation for Trigger

  • Key: UML22-1116
  • Legacy Issue Number: 10777
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Sebastien Gerard)
  • Summary:

    My new question is about the notation for Trigger. In on ehand, I understand the notation as described in section 13.3.31 (p. 475) for specifyng the trigger of a transition in a statemachine (even if it is not so clear because the notation for Trigger refers in fact to the notation of event (p475) ?). But how is it possible to describe the Trigger owned by a classifier? What is the notation for a class to specify which Trigger a class is owning?
    In previous version of UML, it was clear in my head (it does no harm just this once that the description of the behavioral features (either Operations, or Receptions) of a class was implicitly the description of what kind of events a class may reponse to. But now, one hand a class specify its behavioral features, but what happen with its Triggers? Is the description of the behavioral features of a class the implicit description of its Triggers? But in this case, as Trigger are linked to Events, what is the need this intermediate concept of Triggers?

  • Reported: UML 2.1 — Thu, 15 Feb 2007 05:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Discussion: There is no notation for trigger independent of its specific notation in a behavioral feature. (Note that this notation reduces to the specific notation for the associated event.) For example, in state machines, a notation is defined for representing triggers on states or transitions. Disposition: Closed, no change

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

Section: Activities - Action semantic clarification

  • Key: UML22-1102
  • Legacy Issue Number: 9875
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    Action semantic clarification. In Activities, Action, Semantics, bullet [1], third sentence, after "offered", insert "all necessary".

  • Reported: UML 2.1.1 — Tue, 27 Jun 2006 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    accepted

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

Section: Activities -StartClassifeirBehaviorAction and classifier behaviors

  • Key: UML22-1101
  • Legacy Issue Number: 9872
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    StartClassifeirBehaviorAction and classifier behaviors. StartClassifeirBehaviorAction should support passing values to the classifier behavior.

  • Reported: UML 2.1.1 — Tue, 27 Jun 2006 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    No Data Available

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

Section: Activities - isSingleExecution default

  • Key: UML22-1100
  • Legacy Issue Number: 9871
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    isSingleExecution default. Default of isSingleExecution is in text, but not in metamodel diagram.

  • Reported: UML 2.1.1 — Tue, 27 Jun 2006 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    This is already resolved in UML 2.1.1 (formal/2007-02-03). Disposition: Closed, no change

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

Profile Structure Diagrams are missing from Annex A

  • Key: UML22-1105
  • Legacy Issue Number: 10044
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    Section 18.4 describes what are called "Structure Diagrams" for depicting profiles, stereotypes and their associated metaclasses.
    However such diagrams are not included in the Normative Appendix A (Figure A.5 does show 'Structure Diagram' but only as an abstract diagram type).

    Proposed resolution:
    For clarity use the term 'Profile Diagram in section 18.4
    Add Profile Diagram to Annex A as a 14th UML2 Diagram Type.

  • Reported: SysML 1.0b1 — Mon, 31 Jul 2006 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    No Data Available

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

Missing inheritance in 9.3.12

  • Key: UML22-1104
  • Legacy Issue Number: 10000
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    Figure 9.2 shows that Property inherits from ConnectableElement - which is not included in the Generalizations section of 9.3.12 (though it is in the metamodel

  • Reported: SysML 1.0b1 — Wed, 26 Jul 2006 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    The submitter is correct; see revised text.

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

No default value specified for Generalization::isSubstitutable

  • Key: UML22-1103
  • Legacy Issue Number: 9963
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    No default value specified for Generalization::isSubstitutable.
    This is the only Boolean attribute in the whole specification without a default value

  • Reported: SysML 1.0b1 — Tue, 25 Jul 2006 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    For consistency and correctness, add a default value as the summary mentions.

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

consistent descriptions of semantics of event consumption needed

  • Key: UML22-1115
  • Legacy Issue Number: 10776
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Pr. Dr. François Terrier)
  • Summary:

    make consistent the descriptions of semantics of event consumption in section 13.3.4 and in section 13.3.2

  • Reported: UML 2.1 — Thu, 15 Feb 2007 05:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Section 13.3.2 is generic and does not define details of the semantics of event consumption. In fact it states that this is handled by BehavioredClassifier, section 13.3.4. I do not see any inconsistency between these two sections. Disposition: Closed, no change

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

section 13.3.2 – doc ptc/2006-04-02, v.2.1

  • Key: UML22-1114
  • Legacy Issue Number: 10775
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Pr. Dr. François Terrier)
  • Summary:

    Issue a: ) in behaviour description (section 13.3.2 – doc ptc/2006-04-02, v.2.1) precise more formally and explicitely which elements can have behaviors, and how the behavior context is defined.

    Typically clarification should say something like:

    • [A] Any subclasses of BehavioredClassifier (that is: Collaboration, Class, Actor, UseCase) can have a Behavior and its context is defined through the “context” association
    • [B] Any subclasses of BehavioralFeature (that is: xxx to be listed xxx) can have a Behavior and its context is defined through the “specification” association
    • [C] Additionally, Transitions and States can have a Behavior and its context is defined by the first BehavioredClassifier reached through their “owned” relation
    • [D] A Behavior can stand alone and be its own context (e.g. as equivalent to a C/C++ program)

    è Is it here necessary to add a context association from the Behavior to itself…? or should we consider that in this case it is always owned by a modelling element (eg a package) that defines its context… and should we explicitly define to which kind of element this can be considered and add these elements to the list of the [C] situation ?

  • Reported: UML 2.1 — Thu, 15 Feb 2007 05:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Discussion: The issue is somewhat confusing in its wording when it asks what “elements can have behaviors”. In one reading, only BehavioredClassifier can have behaviors. Probably the issue means to ask what “elements can own behaviors”. It would be not in the style of the UML specification to summarize in a central location such information, as this would conflict with the object-oriented style of the specification, or it would cause a maintenance difficulty. Behavior::context clearly defines how the context object is determined, independent of the type of behavior or its owner. Disposition: Closed, no change

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

Uses notation "Subsets Element::ownedElement" and similar

  • Key: UML22-1113
  • Legacy Issue Number: 10731
  • Status: closed  
  • Source: Missouri University of Science and Technology ( Thomas Weigert)
  • Summary:

    Uses notation "Subsets Element::ownedElement" and similar. I believe this should be "Element.ownedElement", as :: is a separator for path. Please check the document throughout.

  • Reported: UML 2.1.1 — Wed, 14 Feb 2007 05:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Discussion: In one of the earlier revisions, the decision was made to use the “::” operator as a qualifier and not the “.” operator. Disposition: Closed, no change

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

UML2: Behavior without a specification should not be a classifier behavior

  • Key: UML22-1112
  • Legacy Issue Number: 10655
  • Status: closed  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    Section 13.3.3, in the description of Behavior::specification says: "If a behavior does not have a specification, it is directly associated with a classifier (i.t., it is the behavior of the classifier as a whole."

    This appears to be incorrect. Assuming the "associated classifier" is the context Classifier: a Behavior might not be an ownedBehavior of any Classifier and has no context. For example, and Activity in a Package. Such a Behavior could not have a specification, but is not the behavior of any associated classifier.

    An ownedBehavior of a context Classifier can be explicitly designated as the behavior of the classifier using the BehavioredClassifier::classifierBehavior property. So there should be no need to define implicit classifier behaviors.

    Finally, a BehavioredClassifier might contain any number of ownedBehaviors that factor out reusable, private functions that are used in the implementations of other ownedBehaviors. These behaviors could be invoked using CallBehaviorActions and do not need specification operations. These behaviors would need a parameter for self if they need to refer to information in the context classifier.

  • Reported: UML 2.1 — Fri, 9 Feb 2007 05:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    The issue correctly points to that the text in Behavior::specification is misleading

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

Figure 13.8 shows the wrong diagram

  • Key: UML22-1109
  • Legacy Issue Number: 10469
  • Status: closed  
  • Source: Eclipse Foundation ( Mr. Kenneth Hussey)
  • Summary:

    diagrams for UML 2.1.1 - Figure 13.8 shows the wrong diagram

  • Reported: UML 2.1 — Wed, 22 Nov 2006 05:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

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

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

Section: 13.3.25

  • Key: UML22-1108
  • Legacy Issue Number: 10383
  • Status: closed  
  • Source: Bergson Technology ( Marc Hamilton)
  • Summary:

    SignalEvent notation interpretes Signal as an Operation. Details: A SignalEvent is associated to a Signal. The notation of SignalEvent contains an <assignment-specification> that consists of a list of <attr-name>. Quote: "<attr-name> is an implicit assignment of the corresponding parameter of the signal to...". Signal is however a Classifier and has no parameters. Either Signal should be an Operation or the notation of SignalEvent must utilize the explicit assignment of "corresponding attributes of the signal". In the latter case, this assignment should include the attribute name of the signal since the attributes of a Classifier are not ordered.

  • Reported: UML 2.1 — Fri, 6 Oct 2006 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    The issue is correct. What is meant was the attributes of the signal

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

Section: 13 SimpleTime

  • Key: UML22-1111
  • Legacy Issue Number: 10643
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    What the time model needs is the concept of an optional time reference that can be attached to a time observation (e.g. to model a spacecraft/ground station situation). The MARTE profile has done some excellent work on this and it should be taken into account when resolving the issue

  • Reported: UML 2.1.1 — Mon, 5 Feb 2007 05:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Resolution: The simple time model is just that: a very simple model to attach time specifications to observations, for example. When a more sophisticated handling of time is required, profiles such as the MARTE profile should be used. The proposal is not to attempt to enhance the simple time model but only fix problems with that model. Disposition: Closed, no change

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

Section: 13.2

  • Key: UML22-1110
  • Legacy Issue Number: 10513
  • Status: closed  
  • Source: UFRJ (Federal Uniersity of Rio de Janeiro) ( Felipe Gomes Dias)
  • Summary:

    In the UML Superstructure 2.1 available in the download section, the picture 13.8 is the same as the picture 13.7, in the page 463 of the document. The picture 13.8 should be explaining about the classes "Behavior" and "Constraint", as shown in the UML Superstructure 2.0 version.

  • Reported: UML 2.1 — Fri, 15 Dec 2006 05:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Discussion: Fixed in an earlier release; also duplicate of10469 Revised Text: N/A Disposition: Closed, no change

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

UML2: No notation for BehavioredClassifier::ownedTrigger

  • Key: UML22-1084
  • Legacy Issue Number: 9407
  • Status: closed  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    UML2 provides a number of different ways to initiatiate execution of some behavior, and for specifying what behaviors are offered for invocation. Behaviors provide a realization of these specifications.

    The simplest is a BehavioredClassifier can respond to invocations of its ownedBehaviors through a CallOperationAction. The ownedBehavior is a method of a specification Operation which defines the client interface, external view, signature, contract (whatever one likes to call it) of the behavior.

    If the ownedBehavior is an Activity, then the activity may contain any number of AcceptEventAction or AcceptCallAction/ReplyAction actions to enable the activity to control when and how additional behavior may be invoked by clients in the context of some broader, perhaps long-running activity. Both AcceptEventAction and AcceptCallAction have trigger: Triger properties whose event: Event could be a SignalEvent or CallEvent respectively. A BehavioredClassifier should indicate to clients its ability to receive the corresponding SignalEvent or CallEvent by including an ownedTrigger designating the event it is prepared to receive.

    However, there is no notation specified for BehavioredClassifier::ownedTrigger. In addition, there are other ways to specify the ability to receive signal and/or call events that may make ownedTrigger redundant. The ability to receive a SignalEvent can be denoted by an ownedReception: Reception in a Class. The notation for an ownedReception is a <<signal>> Operation where the operation name is the Signal name, and the in parameters provide the values for the signal's ownedAttributes. There can be no inout, out, or return parameters, and no raisedExceptions. An ownedOperation is all that is needed to indicate the ability to receive a CallEvent.

    The metamodel for ownedTrigger needs to be reconciled with ownedOperation and ownedReception. Perhaps the notation should provide a way to distinguish operations that invoke behaviors and operations that indicate the ability to respond to call events as <<trigger>> operations.

  • Reported: UML 2.0 — Wed, 1 Mar 2006 05:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Discussion: A classifier declares its “willingness” to handle events by its behavioral features. Currently there are two such features: Operations and Receptions. The former declares that the classifier will handle call events, the latter that the classifier handles signal events. These are the only kinds of events that can be caused by other objects. The issue requests another mechanism to accomplish the same thing without explaining why a second mechanism is required to accomplish what behavioral features already accomplishing. Disposition: Closed, no change

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

UML 2/Templates -- single argument?

  • Key: UML22-1083
  • Legacy Issue Number: 9398
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    A TemplateParameterSubstitution corresponds to exactly one template parameter, but the metamodel allows multiple actual arguments to be supplied for the parameter. There does not seem to be any compelling reason for multiple arguments to be provided for a single template parameter in a substitution (nor are the semantics of this clearl). Therefore, the multiplicity of TemplateParameterSubstitution::actual and Template ParameterSubstitution::ownedActual should be restricted to [1].

  • Reported: UML 2.0 — Fri, 24 Feb 2006 05:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    No Data Available

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

Use the new 'dot' notation in examples

  • Key: UML22-1082
  • Legacy Issue Number: 9373
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    Currently there is only one example of its use. However most of the examples have taken an unadorned line to indicate that both ends are owned by the respective classes: now the same diagram indicates both ends are owned by the association. Though tools may be at liberty to hid the adornments the spec itself should be extremely precise in the examples and show the adornments explicitly since otherwise the diagrams are ambiguous.
    Note that the conventions in 6.5.2 explicitly apply only to the diagrams for the metamodel itself (see line 1 of 6.5.2).

  • Reported: UML 2.0 — Thu, 23 Feb 2006 05:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    This is a duplicate of issue 9372

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

Section: Activities - Join node edge constraint

  • Key: UML22-1099
  • Legacy Issue Number: 9867
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    Join node edge constraint. Join node should have a constraint between the incoming and outgoing flow kinds (control vs data).

  • Reported: UML 2.1.1 — Tue, 27 Jun 2006 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Constraint [2] in Section 12.3.34 (JoinNode) of formal/2007-02-03 already says “If a join node has an incoming object flow, it must have an outgoing object flow, otherwise, it must have an outgoing control flow.” Since the intent is to allow a join node to have both incoming control and object flows, it is not clear what other constraint might be needed. Disposition: Closed, no change

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

Section: Activities - Offer ordering on joins

  • Key: UML22-1098
  • Legacy Issue Number: 9866
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    Offer ordering on joins. Is the ordering of offers from joins the same as they were offered to the join?

  • Reported: UML 2.1.1 — Tue, 27 Jun 2006 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    According to the Semantics in Section 12.3.34 (JoinNode) of formal/2007-02-03: “Tokens are offered on the outgoing edge in the same order they were offered to the join.” Disposition: Closed, no change

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

Section: Activities - Multiple activity parameters nodes for a single inout

  • Key: UML22-1097
  • Legacy Issue Number: 9865
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    Multiple activity parameters nodes for a single inout. Can there be multiple activity parameters nodes for a single inout parameter? If not, the node will have both incoming and outgoing edges, which violates constraint [3] of ActivityParameterNode.

  • Reported: UML 2.1.1 — Tue, 27 Jun 2006 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    There is nothing that prevents a single inout parameter having multiple activity parameter nodes, one with outgoing flows and one with incoming flows. Further, the semantics for activity parameter nodes deals with this case consistently. However, there are actually no limits on the number of activity parameter nodes for a parameter at all, without clear semantics for the general case.

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

A notation for Trigger

  • Key: UML22-1088
  • Legacy Issue Number: 9750
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Sebastien Gerard)
  • Summary:

    My new question is about the notation for Trigger. In on ehand, I understand the notation as described in section 13.3.31 (p. 475) for specifyng the trigger of a transition in a statemachine (even if it is not so clear because the notation for Trigger refers in fact to the notation of event (p475) ?). But how is it possible to describe the Trigger owned by a classifier? What is the notation for a class to specify which Trigger a class is owning?
    In previous version of UML, it was clear in my head (it does no harm just this once that the description of the behavioral features (either Operations, or Receptions) of a class was implicitly the description of what kind of events a class may reponse to. But now, one hand a class specify its behavioral features, but what happen with its Triggers? Is the description of the behavioral features of a class the implicit description of its Triggers? But in this case, as Trigger are linked to Events, what is the need this intermediate concept of Triggers?

  • Reported: SysML 1.0b1 — Thu, 18 May 2006 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    This issue is an identical duplicate, submitted by the same author, as issue 10777

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

Section: 9.3.13 - connectors

  • Key: UML22-1087
  • Legacy Issue Number: 9619
  • Status: closed  
  • Source: Unisys ( Paul Koerber)
  • Summary:

    Connectors cannot be properly represented in a UML model using only constructs available in Compliance Level 1. The Connector class is part of the InternalStructures package which is in Level 1. The class that can own Connectors is StructuredClassifier through the ownedConnector association. This class is also in Level 1 but is abstract. All non-abstract subclasses of StructuredClassifer (such as Collaboration and EncapsulatedClassifier) are in Level 2. Because of this there is no class that can own Connector instances in a model that uses only Level 1 constructs. Therefore Connectors can’t be used in a Level 1 compliant model

  • Reported: UML 2.1 — Mon, 8 May 2006 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Resolution: This was a decision made in the design of UML 2. A tool that wants to offer internal structure with only compliance level 1 would have to at least define a profile that introduces a concrete subtype of StructuredClassifier. Disposition: Closed, no change

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

Section: Activities - Semantics of fork node wording

  • Key: UML22-1096
  • Legacy Issue Number: 9864
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    Semantics of fork node wording. The semantics for fork node should say it copies the tokens onto outgoing edges. The wording currently used is the same as initial node and decision node, which do not copy tokens ("offered to all outgoing edges")

  • Reported: UML 2.1.1 — Tue, 27 Jun 2006 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    The Semantics for ForkNode (formal/2007-02-03, Section 12.3.30) begins: “Tokens arriving at a fork are duplicated across the outgoing edges.” The fact that tokens are duplicated by a fork node is emphasized several times in the subsequent text. Disposition: Closed, no change

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

ReadLinkAction

  • Key: UML22-1095
  • Legacy Issue Number: 9859
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    ReadLinkAction. In Actions, ReadLinkAction, Semantics, second paragraph, before the fourth sentence (the one starting "The multiplicity of"), add the sentence "The order of the retrieved values in the output pin is the same as the ordering of the values of the links." This aligns with the text added to ReadStructuralFeatureAction and ReadVariableAction by issue 8036 in the UML 2.1 RTF.

  • Reported: UML 2.1.1 — Tue, 27 Jun 2006 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    accepted

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

Section: Activities - Weight notation

  • Key: UML22-1094
  • Legacy Issue Number: 9857
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    Weight notation. In Activities, ActivityEdge, Notation, Package CompleteActivities subheading, the text in the first paragraph about weight notation is inconsistent with the figure below it.

  • Reported: UML 2.1.1 — Tue, 27 Jun 2006 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Correct text as below

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

Section: Activities - Weight description

  • Key: UML22-1093
  • Legacy Issue Number: 9856
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    Weight description. In Activities, Attribute and Semantics sections, the description of weight in these are not the same. Should be as in the Semantic section.

  • Reported: UML 2.1.1 — Tue, 27 Jun 2006 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Fix the Associations and Semantics headings under Section 12.3.5, ActivityEdge

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

Section: Activities

  • Key: UML22-1092
  • Legacy Issue Number: 9855
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    StructuredActivityNode. In Activities, StructuredActivityNode, Semantics, Package CompleteStructuredActivities subheading, first sentence, replace "An object node attached to" with "The contents of an input pin of".

  • Reported: UML 2.1.1 — Tue, 27 Jun 2006 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    The remainder of the paragraph discusses both input and output pins on structured activity nodes. Both input and output pins are “accessible” within the structured activity node, in the sense that data can flow out of the input pin and into the output pin. Thus, the sentence should refer to all pins, not just input pins.

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

Section: 9.3.11

  • Key: UML22-1091
  • Legacy Issue Number: 9821
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Sebastien Gerard)
  • Summary:

    Semantics of ports needs to be define with regard to interfaces having attributes and associations

  • Reported: UML 2.1.1 — Mon, 12 Jun 2006 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Attributes and associations of interfaces do not affect the semantics of ports, and thus, no further definition is required. Disposition: Closed, no change

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

Section: 9.3.11

  • Key: UML22-1090
  • Legacy Issue Number: 9814
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Sebastien Gerard)
  • Summary:

    Could you clarify the semantics of port according to its visibility property, i.e. clarify the following sentence: "A port by default has public visibility. However, a behavior port may be hidden but does not have to be."

  • Reported: UML 2.1.1 — Fri, 9 Jun 2006 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    The last sentence was added to clarify that a port is not necessarily public, and to highlight that often behavior ports are hidden. However, as the issue submitter points out, that “clarification” is probably more confusing than it is worth. It would be better placed in the description section, but that would require explaining behavior port there. Best to drop.

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

Section: 9.2

  • Key: UML22-1089
  • Legacy Issue Number: 9813
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Sebastien Gerard)
  • Summary:

    In Figure 9.4, the role name "required" of the association between Port and Interface is not at the right place.

  • Reported: UML 2.1.1 — Fri, 9 Jun 2006 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Resolution: In the current version of the spec, the name is at the correct place. Disposition: Closed, no change

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

Section: 13.3.24 Signal (from Communications)

  • Key: UML22-1086
  • Legacy Issue Number: 9576
  • Status: closed  
  • Source: PostFinance ( Karl Guggisberg)
  • Summary:

    Replace • signal: Signal [1] The signal that is associated with this event. with * ownedAttribute: Property[*] The owned attributes of the signal

  • Reported: UML 2.1.1 — Sun, 16 Apr 2006 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    No Data Available

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

page 467, Section 13.3.24

  • Key: UML22-1085
  • Legacy Issue Number: 9514
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    On page 467, Section 13.3.24, a Signal is said to have one association:

    signal : Signal[1] The signal that is associated with this event.

    I don't understand this. A signal is associated with another signal?
    Which one? Why? Could that be incorrect?

    Perhaps a cut-and-paste error, because on the same page, Section 13.3.25,
    a SignalEvent is said to have one association:

    signal : Signal[1] The specific signal that is associated with
    this event.

  • Reported: UML 2.0 — Wed, 5 Apr 2006 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Duplicate of issue 9576

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

Figure 18.15 does not reflect the example before

  • Key: UML23-53
  • Legacy Issue Number: 13860
  • Status: closed  
  • Source: University of Kassel ( Michael Zapf)
  • Summary:

    Figure 18.15 does not reflect the example before. The property names "wrap" and "resolution" do not match. Moreover, a link is missing from :Extension to :Class which has the "metaclass" and "extension" as a role names

  • Reported: UML 2.2 — Thu, 9 Apr 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • 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:58 GMT

The XMI document contains elements which should be

  • Key: UML23-52
  • Legacy Issue Number: 13857
  • Status: closed  
  • Source: University of Kassel ( Michael Zapf)
  • Summary:

    The XMI document contains "<ownedMember>" elements which should be "<packagedElement>" due to the change in the abstract syntax (see Fig. 18.2). Actually, Eclipse UML support correctly exports "<packagedElement>". The same holds for all other XMI documents.

  • Reported: UML 2.2 — Thu, 9 Apr 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • 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:58 GMT

chapter 2.2, p.3 Last paragaph, second sentence

  • Key: UML23-47
  • Legacy Issue Number: 13846
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    chapter 2.2, p.3 Last paragaph, second sentence: "Note that each of the four packages..." There are more than four packages.

  • Reported: UML 2.2 — Mon, 30 Mar 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • 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:58 GMT

"Associations" part of the "9.10.3 Slot" chapter/section

  • Key: UML23-46
  • Legacy Issue Number: 13834
  • Status: closed  
  • Source: Thales Rail Signalling Solutions ( Stoica Alexandru)
  • Summary:

    In the "Associations" part of the "9.10.3 Slot" chapter/section the text : "• value : InstanceSpecification [*]" should be changed to : "• value : ValueSpecification [*]" according to the diagram provied at page 54.

  • Reported: UML 2.2 — Wed, 25 Mar 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • 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:58 GMT

In paragraph 4, the text should read "Class has a derived association ...". Currently, the sentence is missing "a".

  • Key: UML23-44
  • Legacy Issue Number: 13799
  • Status: closed  
  • Source: Institute for Defense Analyses ( Steven Wartik)
  • Summary:

    In paragraph 4, the text should read "Class has a derived association ...". Currently, the sentence is missing "a".

  • Reported: UML 2.2 — Wed, 18 Mar 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • 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:58 GMT

In paragraph 2, the package reference to InfrastructureLibrary::Constructs::Class omits intermediate package "Core"

  • Key: UML23-43
  • Legacy Issue Number: 13798
  • Status: closed  
  • Source: Institute for Defense Analyses ( Steven Wartik)
  • Summary:

    In paragraph 2, the package reference to InfrastructureLibrary::Constructs::Class omits intermediate package "Core".

  • Reported: UML 2.2 — Wed, 18 Mar 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • 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:58 GMT

18.3.6 Typo in Profile section

  • Key: UML23-50
  • Legacy Issue Number: 13853
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Third paragraph below Figure 18.8, second word: isStrict instead of isStric

  • Reported: UML 2.2 — Sun, 5 Apr 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • 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:58 GMT

Section: Fig. 7.15: subsets at wrong side

  • Key: UML23-49
  • Legacy Issue Number: 13852
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Subsets target and subsets source at the associations from Dependency to NamedElement are at the wrong side. They are property strings of the association ends supplier and client.

  • Reported: UML 2.2 — Thu, 2 Apr 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    No Data Available

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

Figure 13.2 shows class InfrastructureLibrary::Profiles::Element. Section 13 doesn't define a class named Element.

  • Key: UML23-41
  • Legacy Issue Number: 13796
  • Status: closed  
  • Source: Institute for Defense Analyses ( Steven Wartik)
  • Summary:

    Figure 13.2 shows class InfrastructureLibrary::Profiles::Element. Section 13 doesn't define a class named Element. The "Generalizations" on p. 185 says it generalizes Core::Basic::Element. Is that correct? Other classes in Core::Profiles generalize a class from Core::Constructs

  • Reported: UML 2.2 — Wed, 18 Mar 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • 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:58 GMT

Figure 13.2 shows an association between ProfileApplication and Profile that has role "appliedProfile

  • Key: UML23-42
  • Legacy Issue Number: 13797
  • Status: closed  
  • Source: Institute for Defense Analyses ( Steven Wartik)
  • Summary:

    Figure 13.2 shows an association between ProfileApplication and Profile that has role "appliedProfile". The text on p. 196 states that the role is "importedProfile". The respective statements of subsetting also do not correspond.

  • Reported: UML 2.2 — Wed, 18 Mar 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • 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:58 GMT

Section: Chapter 2.2 Compliance levels

  • Key: UML23-48
  • Legacy Issue Number: 13847
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    p.4, fig 2.2. The package L0 is missing which should also be merged into L1.

  • Reported: UML 2.2 — Mon, 30 Mar 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • 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:58 GMT

In the Attributes section, "integer" should be capitalized

  • Key: UML23-45
  • Legacy Issue Number: 13800
  • Status: closed  
  • Source: Institute for Defense Analyses ( Steven Wartik)
  • Summary:

    In the Attributes section, "integer" should be capitalized

  • Reported: UML 2.2 — Wed, 18 Mar 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • 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:58 GMT

Section: 18.3.2

  • Key: UML23-51
  • Legacy Issue Number: 13855
  • Status: closed  
  • Source: University of Kassel ( Michael Zapf)
  • Summary:

    Remove the $ character in 'extension$_' stereotypeName

  • Reported: UML 2.2 — Thu, 9 Apr 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • 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:58 GMT

UML 2.2 Profiles Issue: Stereotypes extending multiple metaclasses are ill-formed as metamodel equivalents

  • Key: UML23-23
  • Legacy Issue Number: 13482
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    (This is quite a nasty and significant issue that arose from discussions of issues raised on the UPDM profile. It may well be declared as Urgent.)

    (start of issue)

    The Profiles chapter claims in a few places (with an example in Figure 18.16) that it’s possible to have a single Stereotype extend many metaclasses. However this is contradicted by the description of Stereotype semantics defined by means of a MOF metamodel equivalent (in Figure 18.4) which shows a ‘base_Interface’ 1..1 composite ownership property on the Home Stereotype. Which makes intuitive sense since you cannot have a free-floating stereotype instance (unattached to any element). However in the case of a Stereotype extending 2 metaclasses this would result in it having 2 mandatory composite owners (e.g. for the example in Figure 18.16 base_Class and base_Component) – which is not permitted (you could never have a valid model since an instance can only ever have one composite owner) and would not make sense (it would require each instance of the Stereotype to be attached to 2 distinct model elements – each property is mandatory).

    This 1..1 property is also reflected in the XMI serialization of a Profile (in 18.3.6) that makes the multiplicity of the base_Interface property 1..1 (by default). And in the Profile XSD where the xsd:element and xsd:attribute are again 1..1 (by default).

    Note that this issue also arises when a Stereotype inherits from another Stereotype and they both extend different metaclasses. This situation could however be addressed in the restricted case that one metaclass is a specialization of the other and by declaring that one property redefined the other. For example assume we modify Figure 18.16 to have an additional Stereotype SuperClock which generalizes Clock and extends Class (instead of Clock directly extending Class). We could then define that Clock::base_Component

    {redefines} SuperClock::base_Class. Thus the Stereotype Clock ends up with only one composite owner property.



    It seems there are two main options, one with variants, for addressing the general problem:



    A) Prohibit a stereotype extending more than one metaclass. Or restrict to the special case above where one base_X property can redefine the other.

    I’m not sure how useful it is to have Stereotypes extending multiple metaclasses anyway since one could always declare common properties on an abstract Stereotype with specialized concrete stereotypes each extending a single metaclass. Extending multiple metaclasses also gives rise to potential problems of how to express constraints – which typically require navigation to the extended element and use of its properties: if there are multiple such navigations and different properties at the target element this becomes tortuous to say the least. However I’m sure there are such profiles out there so this will ‘break’ those (despite the fact that they are inherently ill-formed anyway according to profile semantics)

    B) Modify the ‘MOF equivalent metamodel’ and the XMI and XSD rendition of Profiles to make the base_X property 0..1 instead of 1..1. This would need to be combined with a somewhat-tortuous-to-express (especially if there are more than 2 metaclasses extended) constraint that exactly one of the base_X properties (including those inherited from other Stereotypes) must be non-empty. And this constraint could not be expressed in the XSD (not that XSDs are very good for validation anyway).

    C) A variant of B) is to make the base_X property optional only if the Stereotype extends more than one metaclass (including those inherited). This would minimize the impact for the vast majority of existing profiles. However there are complications. In particular it would require redefinition of properties from general stereotypes which extend a single metaclass. In the above extended example with SuperClock, since that extends only one metaclass then SuperClock::base_Class would be defined as 1..1 as in the current specification. However Clock, in addition to defining Clock::base_Component[0..1] would also require Clock::base_Class[0..1} {redefines}

    SuperClock::base_Class. This however only works because Component specializes Class. In the general case (for example if SuperClock extended Package) then redefinition would not be possible and SuperClock::base_package would have to be changed to be optional. This violates the general design principle that extending something should not change it.

    D) Due to the complications with C), a further variant of B) is to make explicit the multiplicity of the base_X property, in the same way that it can be made explicit for

    {required}

    stereotypes. So SuperClock::basePackage may be explicitly declared to be 0..1. If defaulted to 1..1 then that prohibits it from being specialized – except by a stereotype which extends a subclass of Package and {redefines) SuperClock::basePackage with a [0..1] property. So that makes the use of [1..1] for base_X the equivalent of declaring in Java that the Stereotype is ‘final’ and cannot be extended.

    To summarize the impact of these options on existing profiles:

    A) Requires a change only for Stereotypes that extend more than one metaclass (directly or indirectly) and probably requires new Stereotypes to be created to cover the multiple metaclasses. In those cases it will have an impact on models applying those Steretypes (to migrate to the new Stereotype) but this is a transformation that can be easily automated.

    B) Requires a change to the XMI serialization of all Stereotypes in all existing Profiles (though not models applying those profiles) and their XSD files

    C) Requires a change only for Stereotypes that extend more than one metaclass (directly or indirectly) and requires a change to the XMI serialization of their profiles and XSD but for those stereotypes only and possibly their general stereotypes (which could be in another Profile: I think though the only case I’m aware of that does this is UPDM itself which has not yet been Finalized).

    D) Has the same impact on existing profiles as C), but has the benefit of simpler and more predictable generation rules.

    Option A) has the advantage of retaining the current simple 1..1 structural constraint which is amenable to MOF and XSD validation without the need for OCL support. The other options make it harder to validate that an instance of a stereotype is applied to exactly one instance of a UML metaclass.

    (end of issue)

  • Reported: UML 2.2 — Wed, 11 Feb 2009 05:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    The FTF agreed that this is an issue that needs to be resolved. The solution is to provide another example in
    the specification besides the single metaclass example given in Figure 12.15 for multiple metaclass extension
    and its MOF equivalent class. Furthermore, informal constraints need to be added to the Stereotype’s
    classifier description, stating that: The upper bound of a base property is always 1
    • The multiplicity of the base property in single metaclass extension is always 1..1
    • The multiplicity of all base properties in multiple metaclass extension is always 0..1, whereas only
    one base property is allowed to contain a value at any point during runtime

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

UML 2: conflicting specifications for how to calculate context for a Behavior

  • Key: UML23-17
  • Legacy Issue Number: 13476
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    According to 13.3.2 context is calculated as follows: “If the behavior is owned by a BehavioredClassifier, that classifier is the context; otherwise, the context is the first BehavioredClassifier reached by following the chain of owner relationships.” Also according to 13.3.2 ”When a behavior is instantiated as an object, it is its own context.” These two statements are contradictory.

  • Reported: UML 2.2 — Mon, 9 Feb 2009 05:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    The second quoted sentence is confusing, though the intended meaning is not contradictory with the calculation of the context classifier. The intent is that, when a Behavior without a context classifier is instantiated then, at runtime, the behavior instance acts as its own context object, even though it is not its own context classifier.

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

use of "internal" transition is used incorrectly in many places where "local" should be used.

  • Key: UML23-16
  • Legacy Issue Number: 13325
  • Status: closed  
  • Source: IBM ( Adam Neal)
  • Summary:

    The use of "internal" transition is used incorrectly in many places where "local" should be used. The specification should be updated to correct this inconsistencies. For example, on page (575/748) of UML2.2, it states: "An entry pseudostate is used to join an external transition terminating on that entry point to an internal transition emanating from that entry point. An exit pseudostate is used to join an internal transition terminating on that exit point to an external transition emanating from that exit point" However, internal transitions are not meant to be used in this context and must be connected directly to a state. A 'local' transition is used to navigate to a subvertex which is more the use case being described here.

  • Reported: UML 2.2 — Fri, 23 Jan 2009 05:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    This misuse of the term “internal transition” was rectified in UML 2.5. An inspection of the text reveals no remaining
    cases.
    Disposition: Closed - No Change

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

default multiplicty of association ends are defined more than one

  • Key: UML23-18
  • Legacy Issue Number: 13477
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    In the infrastructure 6.2.1 it says

    If no multiplicity is shown on an association end, it implies a multiplicity of exactly 1.

    However, in

    8.3.3 Associations

    The opposite ends of associations connected to the class are also listed in the same way. The sub clause states if the association is derived, or if it is a specialization of another association. The multiplicity of an association end is suppressed if it is ‘*’ (default in UML).

    It appears that the default is 1 and the default is also * which is confusing.

    I believe it should be clarified something like this.

    When an association is shown as an attribute/property, the default multiplcity is the same as the default attribute/property multiplictty (1)

    When an assocation or attribute is shown as a association (that is, on the end of a line), the default multiplicity should be

  • Reported: UML 2.2 — Wed, 11 Feb 2009 05:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    The default multiplicity is always 1.
    This text appears only in the section describing the structure and conventions used by the specification itself. Superstructure has the following similar text:
    The “Attributes” sub clause of a concept description lists each of the attributes that are defined for that metaclass. Each attribute is specified by its formal name, its type, and multiplicity. If no multiplicity is listed, it defaults to 0..*.
    Which is inconsistent with the Infrastructure text for Attributes:
    The multiplicity of the attribute is suppressed it defaults to „1? (default in UML). In practice both documents are now explicit about all association multiplicities, and suppress only attribute multiplicities of [1].

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

Section: 7.4 Diagrams text on page 144

  • Key: UML23-25
  • Legacy Issue Number: 13591
  • Status: closed  
  • Source: email.com ( Kirill Fakhroutdinov)
  • Summary:

    text on page 144: "Package diagram The following nodes and edges are typically drawn in a package diagram: • Dependency • Package • PackageExtension • PackageImport" Search in the document for "PackageExtension" produces a single result on this same page, which means that the term "PackageExtension" is no longer defined. Most likely, the text above should have "PackageMerge" instead, smth like: Package diagram The following nodes and edges are typically drawn in a package diagram: • Dependency • Package • PackageMerge • PackageImport

  • Reported: UML 2.2 — Fri, 27 Feb 2009 05:00 GMT
  • Disposition: Resolved — UML 2.3
  • 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:58 GMT

UML 2.2 Beta1 Figure 12.18 is misleading about Parameter::effect : ParameterEffectKind [0..1]

  • Key: UML23-24
  • Legacy Issue Number: 13543
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    Specification: UML 2.1 Beta 1 (2008/05/01)

    Section: 12.2 Activities (Abstract Syntax), Figure 12.18

    Summary:

    This figure shows Parameter::effect : ParameterEffectKind in a way that suggests that its multiplicity is [1..1] when in fact it is [0..1]. Also, the figure incorrectly shows an Eclipse ECore stereotype, <<eAttribute>>.

    Proposed Resolution:

    In Figure 12.18:

    • Remove the <<eAttribute>> stereotype notation for the Parameter::effect attribute
    • Show the multiplicity of the attribute explicitly, i.e.: effect : ParameterEffectKind [0..1]
  • Reported: UML 2.2 — Tue, 24 Feb 2009 05:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    This issue is obsolete. The attribute Parameter::effect is shown on Figure 9.9 in the UML 2.5 specification, and the
    problems identified in the issue have already been resolved.
    Disposition: Closed - No Change

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

Figure 12.95 - "Fork node example"

  • Key: UML23-28
  • Legacy Issue Number: 13659
  • Status: closed  
  • Source: email.com ( Kirill Fakhroutdinov)
  • Summary:

    Figure 12.95 - "Fork node example" shows "Fill Order" twice, while it should show - as explained right above - that when "Fill Order" is completed, "Ship Order" and "Send Invoice" get control.

  • Reported: UML 2.2 — Thu, 5 Mar 2009 05:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    See issue 10818 (resolved in UML 2.3) for disposition

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

UML2 : Lifeline identity for InteractionUse

  • Key: UML23-27
  • Legacy Issue Number: 13653
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    Section 14.3. 18 says “An InteractionUse refers to an Interaction. The InteractionUse is a shorthand for copying the contents of the referred Interaction where the InteractionUse is.” What is the relationship of the Lifelines in the used interaction to those in the using interaction? Are they supposed to be the very same lifeline instances, or are they matched by name?

  • Reported: UML 2.2 — Mon, 2 Mar 2009 05:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    UML 2.5 added constraints on covered lifelines of interactionUse stating “Lifelines are common if they have
    the same selector and represents associationEnd values.” It also clarified that selector values are constrained
    to be LiteralString or LiteralInteger
    However, it is necessary to fix some Bugs in the new lifeline and interactionUse constraints. Fix constraint
    interaction_uses_share_lifeline of lifeline and all_lifelines of interactionUse to ensure coverage of Literal-
    Integer Selector value. Also Fix selector_int_or_string constraint to properly cover both LiteralInteger and
    LiteralString options for Selector value.
    This resolution also incorporates the change from Issue 18465, which proposes changing
    : “x.oclIsKindOf(T)->notEmpty()” To: “x.oclIsKindOf(T)’’

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

In the XMI, Ownerships::Element erroneously includes an association for ownedComment.

  • Key: UML23-22
  • Legacy Issue Number: 13481
  • Status: closed  
  • Source: N/A ( Rob Grainger)
  • Summary:

    In the XMI, Ownerships::Element erroneously includes an association for ownedComment. Similarly, the XMI for this package includes an association A_ownedComment_owningElement. These more properly belong in the Comments package of Abstractions.

  • Reported: UML 2.2 — Wed, 11 Feb 2009 05:00 GMT
  • Disposition: Resolved — UML 2.3
  • 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:58 GMT

In the XMI, Ownerships::Element fails to include a superClass attribute for Elements::Element

  • Key: UML23-21
  • Legacy Issue Number: 13480
  • Status: closed  
  • Source: N/A ( Rob Grainger)
  • Summary:

    In the XMI, Ownerships::Element fails to include a superClass attribute for Elements::Element

  • Reported: UML 2.2 — Wed, 11 Feb 2009 05:00 GMT
  • Disposition: Resolved — UML 2.3
  • 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:58 GMT

Section: 9.8.3 XMI fails to include a "lower" attribute

  • Key: UML23-20
  • Legacy Issue Number: 13479
  • Status: closed  
  • Source: N/A ( Rob Grainger)
  • Summary:

    The XMI for the various operations integerValue, booleanValue, stringValue and unlimitedValue fails to include a "lower" attribute, so the default of [1..1] is assumed.

  • Reported: UML 2.2 — Wed, 11 Feb 2009 05:00 GMT
  • Disposition: Resolved — UML 2.3
  • 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:58 GMT

The UML XMI fails to include an ownedRule for the Constraint specified for an OpaqueExpression

  • Key: UML23-19
  • Legacy Issue Number: 13478
  • Status: closed  
  • Source: N/A ( Rob Grainger)
  • Summary:

    The UML XMI fails to include an ownedRule for the Constraint specified for an OpaqueExpression

  • Reported: UML 2.2 — Wed, 11 Feb 2009 05:00 GMT
  • Disposition: Resolved — UML 2.3
  • 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:58 GMT

"Table 7.3 - Graphic paths included in structure diagrams" on pp.143-144

  • Key: UML23-26
  • Legacy Issue Number: 13592
  • Status: closed  
  • Source: email.com ( Kirill Fakhroutdinov)
  • Summary:

    "Table 7.3 - Graphic paths included in structure diagrams" on pp.143-144 includes PackageImport but does not include ElementImport, described in "7.3.15 ElementImport (from Kernel)". It is also missing on p.144 in: "Package diagram The following nodes and edges are typically drawn in a package diagram: • Dependency • Package • PackageExtension • PackageImport" It should look smth like: "Package diagram The following nodes and edges are typically drawn in a package diagram: • Dependency • Package • PackageMerge • PackageImport • ElementImport

  • Reported: UML 2.2 — Fri, 27 Feb 2009 05:00 GMT
  • Disposition: Resolved — UML 2.3
  • 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:58 GMT

Statemachine diagram in section 15.3.12 diagram 15.42 (and the text above)

  • Key: UML23-15
  • Legacy Issue Number: 13324
  • Status: closed  
  • Source: IBM ( Adam Neal)
  • Summary:

    In the Statemachine diagram in section 15.3.12 diagram 15.42 (and the text above) it is specifying the use of 'final' to define that a redefinable element (state or transition in this case) can not be redefined. However, there is no other mention of this 'final' in the rest of the document (maybe its leftover from before?). RedefinableElement's have an isLeaf attribute which is used to determine this property. Therefore we should probably use

    {leaf}

    .

  • Reported: UML 2.2 — Fri, 23 Jan 2009 05:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    Merged with 12380

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

Propagate RTF 2.3 changes to Infrastructure

  • Key: UML23-88
  • Legacy Issue Number: 14116
  • Status: closed  
  • Source: NASA ( Dr. Maged Elaasar)
  • Summary:

    "Some of the resolutions that affected the superstructure doc in RTF 2.3 also have implications for Infrastructure. Please do the proper changes to Infrastrcture to keep the two documnets in sync"

  • Reported: UML 2.2 — Mon, 27 Jul 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    This is confirmed. All the relevant changes are proposed below.

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

Need to copy down merged content to make constraints parse in receiving package

  • Key: UML23-87
  • Legacy Issue Number: 14115
  • Status: closed  
  • Source: NASA ( Dr. Maged Elaasar)
  • Summary:

    "Currently in the metamodel:

    1- InternalStructures::StructuredClassifier specialize Kernel::Classifier and InternalStructures::StructuredClassifier::ownedAttribute subsets Kernel::Classifier::attribute

    2- InternalStructures::Classifier and its "attribute" association are there but not referenced any where else.

    A question: is the subsetting in 1 valid?

    The answer appears at least to me as "No". The type of the InternalStructures::StructuredClassifier::ownedAttribute is InternalStructures::Property, and the type of Kernel::Classifier::attribute is Kernel::Property, and there is no generalization between the two types. That is probably why the Classifier merge increment was introduced in InternalStructures, to make "attribute" of compatible type to "ownedAttribute", but it was never reflected in the metamodel.

    So to make things consistent, as Nic said, we should:

    • Make InternalStructures::StructuredClassifier specialize InternalStructures::Classifier instead of Kernel::Classifier
    • Make InternalStructures::StructuredClassifier::ownedAttribute subset InternalStructures::Classifier::attribute instead of Kernel::Classifier::attribute.

    in addition:

    • don't we need to change 9.3.2 to indicate that Classifier comes from both Collaboration and InternalStructures?
    • Ironically, the "generalization" section in 9.3.2. says that Collaborations::Classifier specialize Kernel::Classifier (as seen in Figure 9.2 "Internal Structures"), where it is supposed to be as given in Figure 9.7 "Collaboration".
    • So to document "Classifier" property in 9.3.2, there would be two generalization headings one "Package InternalStructure" and "Package Collaborations" with different content. "
  • Reported: UML 2.2 — Mon, 27 Jul 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    For chapter 8, this resolution incorporates part of the resolution from the accepted resolution 7364, but modifies it in order to copy down the merged class and features required for the OCL constraint to parse in the context of the receiving package.
    For chapter 9, it sorts out InternalStructures::Classifier, which was introduced according to this "copy down" principle, but is not documented properly. Also Collaborations::Classifier inherits more than is necessary, so to simplify the overall documentation of Classifier in chapter 9, we can make both InternalStructures::Classifier and Collaborations::Classifier just specialize Kernel::Namespace.

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

Remove InputPint from StructuredActivities

  • Key: UML23-86
  • Legacy Issue Number: 14114
  • Status: closed  
  • Source: NASA ( Dr. Maged Elaasar)
  • Summary:

    My inclination would be to remove StructuredActivities::InputPin, and have it only in CompleteStructuredActivities, with OutputPin in both StructuredActivities and CompleteStructuredActivities. The constraints, if they are in the model at all in their unformalized form, should only be on the InputPin and OutputPin classes in CompleteStructuredActivities. Then we can deal as a separate issue with the proper constraints for flows into and out of OutputPins and InputPins at L1 and L2."

  • Reported: UML 2.2 — Mon, 27 Jul 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    Make InputPin only coming from CompleteStructuredActivities (and remove it from StructuredActivities in the metamodel).
    Then, for OutputPin sections add "Package CompleteStructuredActivities" as a subheading for the constraint (and move it in the metamodel to the counterparts in that package).

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

BNF of Constructs::Property

  • Key: UML23-85
  • Legacy Issue Number: 14093
  • Status: closed  
  • Source: n/a ( Jonas Gorski)
  • Summary:

    The BNF of Constructs::Property defines <Visibility> ::= '+' | '-' clearly missing the package and protected visibilities. This Contradicts the Superstructure in 7.3.44, where the BNF states all four visibilites.

  • Reported: UML 2.2 — Fri, 24 Jul 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • 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:58 GMT

Ambiguity in the names of the stereotypes in the standard profiles

  • Key: UML23-84
  • Legacy Issue Number: 14092
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    Specification: UML Superstructure, v2.2

    Section: Annex C, Standard Profiles

    It is not clear what the names actually are of the stereotypes in the standard profiles of UML. The stereotypes are listed in Annex C as they would be applied (using guillemet notation). However, Subclause 18.3.8 has the style guideline: “The first letter of an applied stereotype should not be capitalized.” Due to the above style guideline, this leaves it ambiguous as to whether the actual stereotype model element is named “metaclass” or “Metaclass”. This affects XMI serialization of an application of the stereotype, because the XML element for the stereotype should use the actual stereotype model element name.

    Indeed, as a classifier, the normal practice would be for its name to be capitalized but it would then still be allowable to display this on the diagram using a lower case letter, as in «metaclass». Unfortunately, there is no normative XMI for the standard profiles, so there is currently no way to resolve this based on the normative standard.

  • Reported: UML 2.2 — Wed, 22 Jul 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    The resolution is to provide normative XMI for the standard profiles, and to fix up the document accordingly. In order to do this properly we need to resolve 13306 by shipping a normative version of the UML metamodel expressed in UML. Having done this we can resolve 14092 by shipping standard profiles that refer to this normative UML metamodel.
    We change the convention so that references to stereotypes are shown with upper case letters, and change all the examples accordingly, fixing errors as we go.
    We permit lower case references but remark that they are stylistically obsolete.

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

The primitive types in the UML 2.3 infrastructure.xmi are private; they should be public

  • Key: UML23-91
  • Legacy Issue Number: 14192
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    In the SysML 1.2 RTF, we found a small bug in the normative UML 2.3 infrastructure.xmi here:
    https://dev.enterprisecomponent.com:9992/repos/UML-RTF/trunk/Documents/Specification/Deliverables/UML2.3%20Normative%20XMI.zip

    The bug is described at the bottom of the SysML 1.2 RTF wiki page where I described how I adapted Maged’s excellent instructions for generating the normative UML 2.3 xmi to SysML 1.2.
    It was a bit more complicated for SysML 1.2 because we added an OCL constraint in SysML issue 11091 that required the same “copy down” package merge trick we did for UML issue 7364.
    Fortunately for SysML, it was easier for us since we had to mimick what we did in UML. Nonetheless, we should do something to avoid these annoying last-minute surprises.

  • Reported: UML 2.2 — Thu, 13 Aug 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • 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:58 GMT

Difference between OCL and text in constraint [2] of 15.3.15

  • Key: UML23-90
  • Legacy Issue Number: 14135
  • Status: closed  
  • Source: NASA ( Dr. Maged Elaasar)
  • Summary:

    Constraint [2] in 15.3.15 says:

    [2] A transition with kind external can source any vertex except entry points.
    context Transition inv:
    source.oclIsKindOf(Pseudostate) and source.oclAsType(Pseudostate).kind = PseudostateKind::entryPoint implies kind = TransitionKind::local)

    • Is the text and OCL saying that same thing? I think the text is saying "A implies not B", while the OCL is saying "B implies C", where:

    A : kind = TransitionKind::external
    B : source.oclIsKindOf(Pseudostate) and source.oclAsType(Pseudostate).kind = PseudostateKind::entryPoint
    C: kind = TransitionKind::local (this is not the oppsite of "A" as there is a third kind of transition "internal")

  • Reported: UML 2.2 — Tue, 28 Jul 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    This constraint should be fixed to match the text.

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

Remove redundantant constraint [2] in 7.3.4

  • Key: UML23-89
  • Legacy Issue Number: 14123
  • Status: closed  
  • Source: NASA ( Dr. Maged Elaasar)
  • Summary:

    "Actually, reading 7.3.8 Classifier [8], I realize that the constraint in the resolution 9374 is superfluous since [8] already prevents a Class from specializing an AssociationClass or an Association from specializing an AssociationClass.

    So, the options are:

    1) leave the constraint editorially fixed as we did and file an issue to remove it at the next RTF
    2) cancel the editorial fix and editorially remove the (superfluous) constraint from 9374

    Either way is fine with me but I think that option (2) is better than (1)."

  • Reported: UML 2.2 — Tue, 28 Jul 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    No Data Available

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

UML 2.2 Issue - availability of PrimitiveTypes for UML models

  • Key: UML23-73
  • Legacy Issue Number: 13993
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    The introduction to section 17.4 states the following:

    A number of primitive types have been defined for use in the specification of the UML metamodel. These include

    primitive types such as Integer, Boolean, and String. These types are reused by both MOF and UML, and may potentially

    be reused also in user models.

    However the XMI for UML provides the definitions only as CMOF types not as UML types – so they cannot reliably/interchangeably be used/reused or referenced from user models. There would also need to be a normative URI defined for them.

  • Reported: UML 2.2 — Mon, 15 Jun 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    Indeed for better interchange of UML user models, there needs to be a normative PrimitiveTypes package (with a normative URI) with the common primitive types that can be referenced by UML XMI documents.
    Additionally, since such primitive types are also needed by almost all CMOF-based metamodels, a PrimitiveTypes CMOF package is needed. Unfortunately, the PrimitiveTypes package provided in the InfrastructureLibrary is meant to be package merged vs. referenced by metamodels. Since only few metamodels merge it (still resulting in private copies), the rest duplicate these primitive types in their context.
    This resolution proposes moving the PrimitiveTypes package out of InfrastructureLibrary.cmof and into its own independent package (PrimitiveTypes.cmof). This package can then be referenced instead of copied (through package merge) by metamodels. Additionally, the package can also be exported in UML XMI as PrimitiveTypes.xmi, to be referenced by user models.

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

lowerBound/upperBound constraints and derivations wrong

  • Key: UML23-72
  • Legacy Issue Number: 13992
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    Issue on UML 2.2 Superstructure, Section 7.3.32:

    1. There are 2 constraints numbered [1]

    2. The 2nd of these is: lowerBound()->notEmpty() implies lowerBound() >= 0.

    However the way lowerBound() is defined (operation [4]) means it can never be empty: lowerBound = if lowerValue->isEmpty() then 1 else lowerValue.integerValue() endif

    It makes more sense to have the constraint condition apply to the stored lowerValue. i.e. lowerValue()->notEmpty() implies lowerBound() >= 0

    3. Likewise constraint [2] should be: upperValue()->notEmpty() implies upperBound() >= lowerBound()

    4. Note that this omits the test currently in constraint for lowerValue notEmpty since lowerBound will then default to 1 – and it’s necessary to have the constraint check that upperValue is not less.

    5. /upper and /lower are defined as [0..1]. However since they are defined in terms of upper/lowerValue – which always has a value - then they will never be empty so should be declared as [1].

  • Reported: UML 2.2 — Mon, 15 Jun 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    1. This is no longer relevant in UML 2.5.
    2. Actually, lowerBound can be empty, because lowerValue.integerValue() will be empty if lowerValue does
    not have an integer value. Redefining lowerBound() to check if lowerValue.integerValue() is null, rather
    than just lowerValue, would ensure that lowerBound always was non-empty. With this change, simply
    lowerBound() >=0 would be sufficient for the constraint. (But see also the resolution to Issue 17583.)
    3. Similarly changing the definition of upperBound() to check upperValue.unlimitedValue() would mean
    that upperBound() >= lowerBound() would be sufficient as the constraint.
    4. Actually, including the constraint upperValue->notEmpty() is not correct. Because if the upperValue is
    empty, then upperBound() defaults to 1, which still needs to be greater than or equal to lowerBound().
    5. Actually, upper and lower are defined in terms of upperBound() and lowerBound(), not upperValue
    and lowerValue. Modified as described above, those operations will always return a value. So, the return
    parameters for upperBound() and lowerBound() should have multiplicity 1..1, as well as the attributes upper
    and lower.
    This also resolves Issue 17808.

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

UML2: Missing semantics in definition of RedefinableTemplateSignature with multiple parents

  • Key: UML23-81
  • Legacy Issue Number: 14065
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    In RedefinableTemplateSignature.Associations we have this

    extendedSignature : RedefinableTemplateSignature[*] The template signature that is extended by this template signature. Subsets RedefinableElement::redefinedElement.

    It should read “The template signatures that are extended ...”

    Similarly the constraint says:

    The inherited parameters are the parameters of the extended template signature.

    And should read “extended templates signatures”.

    More seriously, the semantics says nothing about what happens when more than one of the extended template signatures have parameters with the same name. Is it an error? Are they merged (in which case what happens if they are different types)? Are they all there in which case what is the syntax for differentiating them? (e.g. Super1::T : Class, Super2::T : Class)

  • Reported: UML 2.2 — Fri, 10 Jul 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    Correct the plurals, and explain that qualified names will be used to differentiate in the case of clashes. Fix
    the logic of qualified names so that template parameters have them. This is a bit tricky because TemplateParameter,
    TemplateSignature, TemplateableElement and ParameterableElement do not specialize NamedElement.
    The approach adopted is to change the allNamespaces() operation on NamedElement so that if the
    template is a namespace, it is used as the enclosing namespace for the ParameterableElement, which is in
    fact guaranteed to be a NamedElement because all specializations of ParameterableElement are

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

remove StructuredActivities::ActivityGroup

  • Key: UML23-80
  • Legacy Issue Number: 14063
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    The fact that StructuredActivityNode specializes ExecutableNode but does not specialize Action in figure 12.21 is intentional. The StructuredActivities package is merged into L2, and at this level it is intended that “simple” structured nodes be usable on activities without being actions themselves, without pins, etc. This is to support a “procedural” style of the use of actions (along with the use of variables, sequence nodes and value pins).

    It is only in CompleteStructuredActivites (figure 12.22) that StructuredActivityNode specializes Action. CompleteStructuredActivities is merged into L3. As a result, at this level, StructuredActivityNode ends up specializing both ExecutableNode and Action, even though this is redundant. But I don’t think it is avoidable if the structured nodes are to be kept as non-actions in StructuredActivities and L2.

    Finally, the extra ActivityGroup element that appears on figure 12.21 seems to be completely irrelevant. ActivityGroup already has an association with Activity as originally defined in FundamentalActivities, so the merge increment doesn’t seem to add anything. And, as you note, StructuredActivityNode doesn’t even specialize it. My (unresearched) guess is that there was a change at some point to have StructuredActivityNode specialize FundamentalActivities::ActivityGroup rather than the StructuredActivities::ActivityGroup merge increment, and then the latter was just never removed (and remained unnoticed in its little corner of the diagram!).

    So, I think the class description text is OK, but there should be an issue filed to remove StructuredActivities::ActivityGroup – it is probably more than should be done “editorially”. But this is not particularly urgent, since the extra ActivityGroup merge increment on figure 12.21 doesn’t actually hurt anything in the end.

  • Reported: UML 2.2 — Tue, 7 Jul 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    See issue 15264 for disposition

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

Profile::allOwningPackages

  • Key: UML23-83
  • Legacy Issue Number: 14083
  • Status: closed  
  • Source: NASA ( Dr. Maged Elaasar)
  • Summary:

    I noticed that in section 18.3.6 (as well as Infrastructure 13.1.6) the addition operation allOwningPackages is defined in the namespace of NamedElement and not Profile. In the metamodel, this operation is defined in InfrastructureLibrary::Profiles::NamedElement, which is a class that is not defined in the spec doc in clause 18 (neither in clause 13 in InfrastructureLibrary).

    Shouldn't there be a section NamedElement in clause 18 (superstructure) and clause 13 (infrastructure libary) to define this additional operation, as implemented by the metamodel now? (since the operation is already defined in that namespace)

  • Reported: UML 2.2 — Thu, 16 Jul 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • 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:58 GMT

Properties need not be owned

  • Key: UML23-82
  • Legacy Issue Number: 14066
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Based on UML 2.2 Diagram 9.2, it appears that Property is optionally part of StructuredClassifer. Now I understand that Properties may also be part of other things (such as associations and interfaces). But it appears that in all such places such ownership is optional.

    As Properties are features, looking at the multiplicity on Feature, we see Feature:featuring Classifier is 0..*. This means that Properties (and other features) need not be part of anything.

    So can you have a “free-floating” property? Where can you put it? Since Properties are not packagable, they can’t be owned by Packages.

    There are (at least) two ways of solving this (I prefer the first)

    1) Make properties packageable. This gives us the advantage of making a package or model-library of constants properties.

    2) Fix the hole and make properties required to be owned by something.

    A nearly identical argument arises from Connectors which also may be free-floating, but are not packageable.

    In SysML there is some interest in making connectors packageable (possibly as we care not about code-generation in the UML sense) as it would allow us to use Binding connectors (a SysML type of connector that declares equivalence) in package or class (in SysML, Block) diagrams

    Again there are two ways of solving this (I prefer the first)

    1) Make connectors packageable.

    2) Fix the hole and make connectors required to be owned by something.

    A more general solution may be to just apply the solution strategy to features as a whole, which would minimize the changes.

  • Reported: UML 2.2 — Thu, 9 Jul 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    The issue is incorrect to state that properties/connectors need not be owned. They both inherit Element::mustBeOwned(),
    which means that they must have an owner.
    Disposition: Closed - No Change

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

Operation-interface should subset Feature-featuringClassifier and NamedElement-namespace

  • Key: UML23-71
  • Legacy Issue Number: 13991
  • Status: closed  
  • Source: The MathWorks ( Mr. Salman Qadri)
  • Summary:

    In UML, Operation-interface should subset Feature-featuringClassifier and NamedElement-namespace, just like Operation-class and Operation-datatype. This is needed since the opposite of Operation-interface, which is ‘Interface-ownedOperation’ subsets ‘Classifier-feature’ and ‘Namespace-ownedMember’.

  • Reported: UML 2.2 — Mon, 15 Jun 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    This issue affects the XMI and the specification document of the UML2 superstructure.

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

UML2.2 chapter 16 : Actor constraint [1] has invalid OCL

  • Key: UML23-70
  • Legacy Issue Number: 13948
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    Actor constraint [1] says: self.ownedAttribute->forAll ( a | (a.association->notEmpty()) implies ((a.association.memberEnd.size() = 2) and (a.opposite.class.oclIsKindOf(UseCase) or (a.opposite.class.oclIsKindOf(Class) and not a.opposite.class.oclIsKindOf(Behavior))))

    But Actor has no ownedAttribute property, so this constraint is ill-formed.

  • Reported: UML 2.2 — Mon, 8 Jun 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    Merged with 10780

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

UML2: error in definition of Class::nestedClassifier

  • Key: UML23-76
  • Legacy Issue Number: 14021
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    Class::nestedClassifier currently reads:

    nestedClassifier: Classifier [*] References all the Classifiers that are defined (nested) within the Class. Subsets Element::ownedMember

    Element::ownedMember does not exist. It should say Subsets Namespace::ownedMember.

  • Reported: UML 2.2 — Tue, 23 Jun 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    See issue 10829 for disposition

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

confusion re diagram on p. 83

  • Key: UML23-75
  • Legacy Issue Number: 13995
  • Status: closed  
  • Source: SocialCanvas ( Paul Quinn)
  • Summary:

    The diagram on page 83 states that Classifier generalises Namespace, but the text of 9.19.1 states that Classifier (as specialized) generalises Classifier. Which is it? Should it be both?

  • Reported: UML 2.2 — Tue, 16 Jun 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • 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:58 GMT

Currently is it possible for a Classifier to specialize the same classifier directly more than once

  • Key: UML23-79
  • Legacy Issue Number: 14035
  • Status: closed  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    Currently is it possible for a Classifier to specialize the same classifier directly more than once, that is, generalization.general contains duplicates. There should probably be a constraint to make this invalid.

  • Reported: UML 2.2 — Mon, 29 Jun 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    This seems harmless. Also, there might be scenarios where the same pair of classifiers are related by more than one
    generalization each associated with different GeneralizationSets. Prohibiting this might also invalidate existing models
    unnecessarily.
    Disposition: Closed - No Change

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

nestedClassifier

  • Key: UML23-77
  • Legacy Issue Number: 14023
  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    the definition of nestedClassifier is misleading. Maybe something like: "Classifier definitions owned by the class. Subsets NameSpace::ownedMember" would be better.

  • Reported: UML 2.2 — Tue, 23 Jun 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    Rephrase the metamodel documentation, and remove a difficult-to-parse and redundant sentence from the
    semantics.

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

Section 9.9 should classifier be added to the diagram on p 50?

  • Key: UML23-74
  • Legacy Issue Number: 13994
  • Status: closed  
  • Source: SocialCanvas ( Paul Quinn)
  • Summary:

    The diagram on page 50 shows that a Classifier is generalized from Type , whereas the accompanying text states that Classifier is generalized from Type AND Classifier (as Specialized). Should Classifier (as Specialized) be added to the diagram? Thanks, Paul

  • Reported: UML 2.2 — Tue, 16 Jun 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • 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:58 GMT

type mismatch

  • Key: UML23-78
  • Legacy Issue Number: 14034
  • Status: closed  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    Classifier::parents() is defined as "parents = generalization.general". However there is a type mismatch: the operation return type is a Set whereas the expression is a Bag. It should be defined as "parents = generalization.general->asSet()".

  • Reported: UML 2.2 — Mon, 29 Jun 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • 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:58 GMT

Section 12.3.48 on page 412

  • Key: UML23-32
  • Legacy Issue Number: 13718
  • Status: closed  
  • Source: International Business Machines ( James Bruck)
  • Summary:

    Spec. version 2.2 ptc/2008-05-xx

    Regarding section 12.3.48 on page 412, I believe that both StructuredActivityNode::node and StructuredActivityNode::edge should also subset Namespace::ownedElement.

  • Reported: UML 2.2 — Fri, 13 Mar 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    Agreed, except that the reference would normally be to just Element::ownedElement, especially since this is inherited from multiple immediate superclasses of StructuredActivityNode.

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

Figure 7.1 shows no dependency

  • Key: UML23-34
  • Legacy Issue Number: 13789
  • Status: closed  
  • Source: Institute for Defense Analyses ( Steven Wartik)
  • Summary:

    Paragraph 1: The text states that Figure 7.1 shows a dependency between Profiles and Core. Figure 7.1 shows no dependency.

  • Reported: UML 2.2 — Wed, 18 Mar 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • 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:58 GMT

Section 2.3 para 1 needs to be re-written

  • Key: UML23-33
  • Legacy Issue Number: 13788
  • Status: closed  
  • Source: Institute for Defense Analyses ( Steven Wartik)
  • Summary:

    Paragraph 1, which appears to be copied from the Superstructure, is incorrect in this context. The Superstructure has compliance levels L0-L3, but the infrastacture only has L0 and LM. The paragraph needs to be rewritten.

  • Reported: UML 2.2 — Wed, 18 Mar 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • 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:58 GMT

Section 13 "Core::Profiles" inconsistency

  • Key: UML23-40
  • Legacy Issue Number: 13795
  • Status: closed  
  • Source: Institute for Defense Analyses ( Steven Wartik)
  • Summary:

    The section title is "Core::Profiles". In Figure 1 on p. 27, "Core" and "Profiles" are top-level, sibling packages (and the previous paragraph states as much). Which is correct?

  • Reported: UML 2.2 — Wed, 18 Mar 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • 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:58 GMT

Should the definition of Element state that it reuses the definition of Element from Abstractions::Elements?

  • Key: UML23-39
  • Legacy Issue Number: 13794
  • Status: closed  
  • Source: Institute for Defense Analyses ( Steven Wartik)
  • Summary:

    Should the definition of Element state that it reuses the definition of Element from Abstractions::Elements?

  • Reported: UML 2.2 — Wed, 18 Mar 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • 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:58 GMT

The "Generalizations" heading is missing before the "ValueSpecification" bullet.

  • Key: UML23-37
  • Legacy Issue Number: 13792
  • Status: closed  
  • Source: Institute for Defense Analyses ( Steven Wartik)
  • Summary:

    The "Generalizations" heading is missing before the "ValueSpecification" bullet.

  • Reported: UML 2.2 — Wed, 18 Mar 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • 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:58 GMT

Paragraph 5: The text states that class Comment has no generalizations

  • Key: UML23-36
  • Legacy Issue Number: 13791
  • Status: closed  
  • Source: Institute for Defense Analyses ( Steven Wartik)
  • Summary:

    Paragraph 5: The text states that class Comment has no generalizations. This conflicts with Figure 9.10 on p. 37.

  • Reported: UML 2.2 — Wed, 18 Mar 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • 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:58 GMT

UML 2 7.3.3 : incorrect text about aggregationKind in associations

  • Key: UML23-31
  • Legacy Issue Number: 13662
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    The following paragraph appears in 7.3.3: “An association with aggregationKind = shared differs in notation from binary associations in adding a hollow diamond as a terminal adornment at the aggregate end of the association line. The diamond shall be noticeably smaller than the diamond notation for associations. An association with aggregationKind = composite likewise has a diamond at the aggregate end, but differs in having the diamond filled in.”

    aggregationKind is a property of Property, not of Association, so this paragraph is incorrect.

  • Reported: UML 2.2 — Fri, 6 Mar 2009 05:00 GMT
  • Disposition: Resolved — UML 2.3
  • 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:58 GMT

Table 12.1 - "Graphic nodes included in activity diagrams",

  • Key: UML23-29
  • Legacy Issue Number: 13660
  • Status: closed  
  • Source: email.com ( Kirill Fakhroutdinov)
  • Summary:

    Table 12.1 - "Graphic nodes included in activity diagrams", the row "ActivityNode" states: "See ExecutableNode, ControlNode, and ObjectNode." But the "ExecutableNode" row is missing in the table. The action needed is to insert another row in the table for "ExecutableNode" with smth like "See Action, StructuredActivityNode". But the "StructuredActivityNode" row is not present in the table as well. So insert another row for "StructuredActivityNode" with notation taken from p.419, Figure 12.133 "Notation for structured nodes".

  • Reported: UML 2.2 — Fri, 6 Mar 2009 05:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    See issue 11162 (resolved in UML 2.3) for disposition

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

Generalizations" for StructuredActivityNode on p. 417

  • Key: UML23-30
  • Legacy Issue Number: 13661
  • Status: closed  
  • Source: email.com ( Kirill Fakhroutdinov)
  • Summary:

    "Generalizations" for StructuredActivityNode on p. 417 include: • Action • ActivityGroup • ExecutableNode • Namespace but "Figure 12.21 - Structured nodes" on page 313 shows StructuredActivityNode and Action as siblings (generalization for both is ExecutableNode). So either "Action" should be removed from Generalizations for StructuredActivityNode on p. 417 or the diagram on p. 313 to be updated to show different relations between these nodes.

  • Reported: UML 2.2 — Fri, 6 Mar 2009 05:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    No Data Available

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

Two issues regarding Figure 10.2: 1

  • Key: UML23-38
  • Legacy Issue Number: 13793
  • Status: closed  
  • Source: Institute for Defense Analyses ( Steven Wartik)
  • Summary:

    Two issues regarding Figure 10.2: 1) What is the "<<eAttribute>>" stereotype that's applied to Comment::body? I can't find a definition for it elsewhere in the document. 2) Why aren't the NamedElement::name and Comment::body attributes suffixed with "[0..1]"?

  • Reported: UML 2.2 — Wed, 18 Mar 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • 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:58 GMT

Parameter is part of the BehavioralFeatures package.

  • Key: UML23-35
  • Legacy Issue Number: 13790
  • Status: closed  
  • Source: Institute for Defense Analyses ( Steven Wartik)
  • Summary:

    Should this section be numbered 9.1.2? Parameter is part of the BehavioralFeatures package.

  • Reported: UML 2.2 — Wed, 18 Mar 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • 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:58 GMT

Validator issues with TestCase 2

  • Key: UML23-65
  • Legacy Issue Number: 13930
  • Status: closed  
  • Source: NIST ( Mr. Peter Denno)
  • Summary:

    looked at the 7 OCL constraint failures reported in Test Case 2. There are 5 different kinds of constraints that failed. In summary I found:

    • In 2 of these it appears that the model, valid.xmi, is wrong.
    • In 2 the OCL is wrong. One can be fixed. The other should be removed from the UML spec.
    • In 1 I made a mistake when correcting an unrelated problem in the OCL.

    I'll update the Validator. If my conclusions below are correct, someone should update valid.xmi too.

    Details below:

    (Model 'TestCase2')
    Summary of Model Content:
    Total objects: 94.
    UML objects: 94
    SysML objects: 0
    The model: <uml:Model TestCase2, id=1>
    Object Inventory
    Summary of Warnings:

    • Referent not found: 0
    • Unresolved URI used for object identification: 0
    • Set members not unique: 0
    • Missing mandatory value: 0
    • No class with name specified: 0
    • Property not found: 0
    • Cannot infer class of object: 0
    • Multiplicity violation: 0
    • Type violation: 0
    • Invalid stereotype application: 0
    • No object for stereotyping: 0
    • Creation of abstract class: 0
    • OCL constraint violation: 7 <================
    • OCL execution errors: 3
    • OCL errors while evaluating derived attribute: 0
    • OCL errors due to missing derived attribute specifications: 315
    • Identical XMI attribute xmi:id used by multiple XML elements: 0
    • Expected a uml:PrimitiveType: 0
    • XMI attribute xmi:id references excessive space chars: 0

    OCL constraint violation (7)
    There are 5 variations of this error:

    1 instances of this:
    The constraint Property.redefined_property_inherited() was violated.
    View Instance 1

    2 instances of this:
    The constraint NamedElement.has_no_qualified_name() was violated.
    View Instance 1

    1 instances of this:
    The constraint Constraint.value_specification_boolean() was violated.
    View Instance 1

    1 instances of this:
    The constraint Interface.visibility() was violated.
    View Instance 1

    2 instances of this:
    The constraint RedefinableElement.redefinition_context_valid() was violated.
    View Instance 1

    The constraint Property.redefined_property_inherited() was violated.
    This one on instance 84, a Property named "redefiningProperty"

    The constraint is:
    redefinedProperty->notEmpty() implies
    redefinitionContext->notEmpty() and
    redefinedProperty->forAll(rp|redefinitionContext->
    collect(fc | fc.allParents())>asSet()>
    collect(c| c.allFeatures())>asSet()>includes(rp))

    ... 84.redefinedProperty is not empty, but 84.redefinitionContext is empty.

    In as far as this constraint is what was intended, the validator is doing the right thing. The file should specify a redefinition context. If you believe the contraint or my conclusion is incorrect, let me know. Otherwise, shall I'll write an issue against the testcase?

    The constraint Interface.visibility() was violated.
    This one on instance 29:

    The constraint is:
    self.feature->forAll(f | f.visibility = #public)

    self.feature contains one instance, named "operation1", and its visibility is not set. In as far as this constraint is what was intended, the validator is doing the right thing. If you believe the constraint or my conclusion is incorrect, let me know.

    The constraint NamedElement.has_no_qualified_name() was violated.

    This one is my mistake. I corrected an error in the derivation of qualified names, and in an unrelated act, placed that "self.name" text before the endif below. It was Set{} and should be Set{}. I'll fix the OCL in Validator and put out a new version.

    result = if self.name->notEmpty() and
    self.allNamespaces()>select(ns | ns.name>isEmpty())->isEmpty()
    then self.allNamespaces()->iterate( ns : Namespace;
    result : String = self.name | ns.name.concat(self.separator()).concat(result))
    else self.name endif <=== should be Set{}

    The constraint Constraint.value_specification_boolean() was violated.

    The constraint is:
    self.specification.booleanValue().oclIsKindOf(Boolean)

    The function booleanValue():
    result = value

    It looks like this intends to perform runtime evaluation of the OCL string in the specification property (which should more accurately be specification.body, anyway). Technically, I could do this, but there is no way to describe the evaluation in OCL, and I wouldn't really want to execute arbitrary code on my server.

    I will mark this OCL as an error, and have it return True. This OCL should be removed from the UML spec.

    The constraint RedefinableElement.redefinition_context_valid() was violated.

    After some digging I found that the definition of isRedefinitionContextValid, which is called by this was:

    redefinitionContext->
    exists(c | c.allParents()->
    includes(redefined.redefinitionContext))

    But redefined.redefinitionContext is a Collection, so the use of includes here is not correct. It should be:

    redefinitionContext->
    exists(c | c.allParents()->
    oclIntersection(redefined.redefinitionContext)->notEmpty())

    Things work fine with this correction.

  • Reported: UML 2.2 — Tue, 12 May 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    The problems highlighted by the issue have already been resolved in the specification.
    Disposition: Closed - No Change

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

current definition of a 'local' transition does not allow the case to have a local transition

  • Key: UML23-64
  • Legacy Issue Number: 13920
  • Status: closed  
  • Source: International Business Machines ( Mr. Adam Neal)
  • Summary:

    To properly and unambiguously constrain which Region 'should' own a transition, requires that the transition kind be used (further work on issue 10498). The current definition of a 'local' transition does not allow the case to have a local transition whose target is a composite state and source is nested within that composite state. It should be possible to assign this kind of transition local semantics, i.e., the composite state will not be exited nor entered; only the nested configuration of composite state will be affected as a result of exiting the nested source state and establishing a configuration for the composite state itself, i.e., the target.

  • Reported: UML 2.2 — Tue, 5 May 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    Update the text to explicitly include the possibility. Also, remove the reference to local self-transitions and
    replace them with an explanation about the representation of internal transitions

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

Figures 9.17 and 9.19 and related text

  • Key: UML23-59
  • Legacy Issue Number: 13909
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    Figures 9.17 and 9.19 and related text show that an Engine requires Power on the same port as it provides a powertrain. This makes no sense conceptually – an engine does not require power from its powertrain, it delivers power to its powertrain. Modify the examples so they make sense.

  • Reported: UML 2.2 — Thu, 30 Apr 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • 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:58 GMT

what's the difference > between weight=1 and weight=*?

  • Key: UML23-58
  • Legacy Issue Number: 13898
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    I agree with the resolution, but I > ask myself what's the difference > between weight=1 and weight=? Edge weight controls how many offers must be accepted by the target of the edge for any tokens to traverse the edge at the same time ("the minimum number of tokens that must traverse the edge at the same time."). The default weight=1 lets just one offer be accepted for a token to traverse (all tokens might be offerred to the ObjectFlow, but it's OK if only one is accepted, it traverses). Weight=2 requires two to be accepted, or none traverse. Weight = * requires all tokens currently at the source to be accepted for any to traverse. If for some reason the target of the ObjectFlow can't accept all the tokens required by the weight (maybe the target is full), the object flow can't accept any. In the example Ed was concerned with, there's no reason for the target of an ObjectFlow to reject offers, so weight=1 causes all the tokens at the source to move at once, as if weight=. Weight=* gives a different execution of the join in Figure 12.45 than weight=1 (refered to in the Semantics of ActivityEdge). Normally the join would take one token from Bids For Proposal when the Ready to Award Bid event occurs (or at least I thought it would, the join semantics isn't clear on that I notice), but with weight=, the join must take all the tokens in Bids For Proposal. The semantics of weight= is slightly bent, because you would think it means an infinite number of tokens must traverse at the same time. It actually means whatever number of tokens are at the source must traverse at the same time (it's using "*" like a wildcard instead of infinity, not so good). The wording of the paragraph in Semantics of ActivityEdge could be improved if you'd like to file issue. In particular: - Where it says "When the minimum number of tokens are offered" it should say "accepted" instead of "offered". - The sentence starting "An unlimited weight" should continue "means that all the tokens at the source must be accepted for any of them to traverse the edge". Conrad

  • Reported: UML 2.2 — Sat, 25 Apr 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    Clarify that weight gives the minimum number of tokens that must be accepted by the target of an ActivityEdge for any tokens to traverse the edge, and that weight=UnlimitedInteger means the minimum number of tokens is the number currently at the source of the ObjectFlow.

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

Clarify that input pins do not accept more tokens than their actions can immediately consume

  • Key: UML23-63
  • Legacy Issue Number: 13914
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Clarify that input pins do not accept more tokens than their actions can immediately consume

  • Reported: UML 2.2 — Mon, 4 May 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    The Activities, (12.3.2) Action, Semantics, item 1, says
    The object flow prerequisite is satisfied when all of the input pins are offered all necessary tokens and accept them all at once, precluding them from being consumed by any other actions. This ensures that multiple action executions competing for tokens do not accept only some of the tokens they need to begin, causing deadlock as each execution waits for tokens that are already taken by others.
    The "necessary tokens" in the first sentence above are the ones needed to execute the actions (meeting the minimum multiplicity), but should include any additional ones offered up the maximum multiplicity. Only these are accepted by the input pins, then immediately consumed by the action. The second sentence gives the motivation, which is to avoid having tokens in input pins that are not immediately consumed. This would prevent those tokens from being used to execute other actions, potentially creating deadlock or starvation. Deadlock is discussed more in issue 7221 of the UML 2.0 FTF report (http://doc.omg.org/ptc/04-10-01).

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

The OCL for /required interfaces of Component is using ports.provided instead of ports.required

  • Key: UML23-62
  • Legacy Issue Number: 13912
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    The OCL for /required interfaces of Component is using ports.provided instead of ports.required

  • Reported: UML 2.2 — Thu, 30 Apr 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • 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:58 GMT

Clarification need on circle plus notation for containment

  • Key: UML23-67
  • Legacy Issue Number: 13933
  • Status: closed  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    It is not clear when the circle plus notation is available for showing containment. Can it be used for showing nested class, packages, ownedBehaviors, etc.? Any containment association in the metamodel?

  • Reported: UML 2.2 — Fri, 15 May 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    Merged with 13936

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

Color errors on figures in UML 2.2

  • Key: UML23-66
  • Legacy Issue Number: 13931
  • Status: closed  
  • Source: Object Management Group ( Dr. Jon M. Siegel)
  • Summary:

    Here are some (hopefully editorial) errors in the figures in the recent UML 2.2 release, document 09-02-02. A conscientious OCUP candidate brought the first of these to my attention.

    Figure 6.2: What is the significance of the red color of the symbols and arrows? If none, they should be black.

    Figure 14.1: The <<merge>> arrows are black, as is most of the rest of the figure, but the <<import>> arrows are red. This confuses at least one conscientious OCUP candidate who wrote in asking the significance of the color in the figures. i.e. Are <,import>> arrows supposed to be Red?

    Now I'm going back in the spec and checking all of the Abstract Syntax sections for color. Here we go...

    Part I, Figure 1, on page 21, also has red <<import>> arrows.

    Figure 8.1: Here, one of the <<merge>> arrows is red.

    Figure 9.1: The StructuredActivities box outline is maroon.

    Figure 10.1: Red <<import>> arrow

    Figure 11.1: Red <<import>> arrows

    Figure 12.1: Two boxes have red outlines and yellow fill. (Ouch!) Lots of red arrows.

    Figure 15.2: Red <<import>> arrows

    Figure 17.1: Red <<import>> arrows

    Figure 18.1: Red <<import>> arrows

    That's all I found. Hopefully it won't take a bunch of votes to turn all of these lines black

  • Reported: UML 2.2 — Thu, 14 May 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • 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:58 GMT

Figure 7.38 needs to be revised

  • Key: UML23-69
  • Legacy Issue Number: 13947
  • Status: closed  
  • Source: Hendryx & Associates ( Stan Hendryx)
  • Summary:

    Figure 7.38 needs to be revised. The arrowhead on the dependency of Figure 7.38 is on the wrong end. The example it illustrates is not consistent with software engineering practices and is consequently ambiguous and misleading and should be revised. These errors lead to endless confusion and debate among UML modelers as to the correct usage of the standard notation for dependencies. p.62 Notation, says, "The model element at the tail of the arrow (the client) depends on the model element at the arrowhead (the supplier)." The example of Fig. 7.38 says, "the Car class has a dependency on the CarFactory class. In this case, the dependency is an instantiate dependency, where the Car class is an instance of the CarFactory class." These sentences should be revised. Suggested wording: "the Car class depends on on the CarFactory class. In this case, the dependency is an instantiate dependency, where the Car class is instantiated by the CarFactory class. That is, the Car class depends on the CarFactory class to produce instances of Car, i.e., to produce cars."

  • Reported: UML 2.2 — Thu, 4 Jun 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    Merged with 11489

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

Activity groups should be named

  • Key: UML23-68
  • Legacy Issue Number: 13943
  • Status: closed  
  • Source: INCOSE ( Sanford Friedenthal)
  • Summary:

    Activity groups should be named. Interruptible Regions in particular. Nodes, Edges, and some Activity Groups are already named, such as Activity Partitions.

  • Reported: UML 2.2 — Sun, 31 May 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    Activity Groups specialize NamedElement intead of Element.

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

Table 2.2 Example feature support statement references Note (4) and Note (5)

  • Key: UML23-57
  • Legacy Issue Number: 13868
  • Status: closed  
  • Source: individual ( Robert Dunn)
  • Summary:

    Page 24 of PDF. Table 2.2 Example feature support statement references Note (4) and Note (5). Notes only number 1 - 3. There is no Note (4) nor Note (5).

  • Reported: UML 2.2 — Wed, 15 Apr 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • 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:58 GMT

Description of Level 1 diagram does not make sense with respect to figure 2.2

  • Key: UML23-56
  • Legacy Issue Number: 13867
  • Status: closed  
  • Source: individual ( Robert Dunn)
  • Summary:

    Page 19 and 20 of PDF. Description of Level 1 diagram does not make sense with respect to figure 2.2. "...packages merged into Level 0 and their contents are extended...," yet packages listed on figure 2.1 (Level 0 diagram) are not shown in figure 2.2 and no <<extend>> relationship is shown. Even a <<merge>> relationship between L1 and L0 would seem clear except for the defect noted next. "Note that each of the four packages shown in the figure...," but I see twelve packages shown in figure 2.2.

  • Reported: UML 2.2 — Wed, 15 Apr 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • 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:58 GMT

Clarify how the provided and required interfaces of a Port are calculated

  • Key: UML23-61
  • Legacy Issue Number: 13911
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    Clarify how the provided and required interfaces of a Port are calculated when the type of a Port is a Component or a Class with Ports

  • Reported: UML 2.2 — Thu, 30 Apr 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • 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:58 GMT

Missing keyword?

  • Key: UML23-60
  • Legacy Issue Number: 13910
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    Figure 9.19 shows some kind of "dependency" between interfaces, so if that means Usage, <<use>> keyword must be used

  • Reported: UML 2.2 — Thu, 30 Apr 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    The issue is obsolete. The figure no longer appears in the spec.
    Disposition: Closed - No Change

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

Replace "extensionClock" with "extension_Clock" and "baseClass" with "base_Class"

  • Key: UML23-54
  • Legacy Issue Number: 13861
  • Status: closed  
  • Source: University of Kassel ( Michael Zapf)
  • Summary:

    Replace "extensionClock" with "extension_Clock" and "baseClass" with "base_Class"

  • Reported: UML 2.2 — Thu, 9 Apr 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • 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:58 GMT

URIs do not refer to existing resources (404 errors) Annex H

  • Key: UML23-55
  • Legacy Issue Number: 13863
  • Status: closed  
  • Source: University of Kassel ( Michael Zapf)
  • Summary:

    URIs do not refer to existing resources (404 errors)

  • Reported: UML 2.2 — Thu, 9 Apr 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • 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:58 GMT

Section: 14.3.13 Interaction (from BasicInteraction, Fragments)

  • Key: UML23-14
  • Legacy Issue Number: 13256
  • Status: closed  
  • Source: email.com ( Kirill Fakhroutdinov)
  • Summary:

    Text from the specs states: "Description An interaction is a unit of behavior that focuses on the observable exchange of information between ConnectableElements. ..." "Semantics Interactions are units of behavior of an enclosing Classifier. Interactions focus on the passing of information with Messages between the ConnectableElements of the Classifier." One issue is that in several other places of the specs interactions are described as being "owned" - not "enclosed" - by Classifier, e.g below on p. 492 we read "The classifier owning an Interaction may be specialized, and ..." Another question I have is that semantics of interaction as described now is focusing on passing of information between ConnectableElements of that specific Classifier - but traces of interaction include OccurrenceSpecifications of possibly several participants represented by LifeLines of one to many Classifiers. The case when Classifier interacts only with itself or a single other Classifier should be quite rare. When we have several Classifiers (represented by LifeLines) interacting, that interaction should include ConnectableElements of those several Classifiers involved, unless the "ConnectableElements of the Classifier" are considered to be some transitive closure of all ConnectableElements depicted on the interaction. In other words, I'd clarify both Description and Semantics of Interaction to something like: Interactions are units of behavior of an owning Classifier. Interactions focus on the passing of information with Messages between the ConnectableElements of the owning Classifier and ConnectableElements of other interacting Classifiers. All Classifiers participating in the interaction - including owner Classifier - are represented by LifeLines."

  • Reported: UML 2.2 — Wed, 14 Jan 2009 05:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    The requested change contradicts the Lifeline Constraint “same_classifier” which states:
    “The classifier containing the referened ConnectableElement must be the same classifier, or an ancestor, of the classifier
    that contains the intraction enclosing the Lifeline.”
    Disposition: Closed - No Change

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

Notation for ExecutionSpecification

  • Key: UML23-13
  • Legacy Issue Number: 13254
  • Status: closed  
  • Source: email.com ( Kirill Fakhroutdinov)
  • Summary:

    Notation for ExecutionSpecification is described as: "Notation ExecutionOccurences are represented as thin rectangles (grey or white) on the lifeline (see “Lifeline (from BasicInteractions, Fragments)” on page 500). We may also represent an ExecutionSpecification by a wider labeled rectangle, ..." It seems that "ExecutionOccurences" above is typo as this paragraph is about ExecutionSpecifications, and thus text should read as: "Notation ExecutionSpecifications are represented as thin rectangles (grey or white) on the lifeline ..."

  • Reported: UML 2.2 — Wed, 14 Jan 2009 05:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    No Data Available

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

Section: 7.3.39 PackageImport (from Kernel)

  • Key: UML23-6
  • Legacy Issue Number: 13137
  • Status: closed  
  • Source: email.com ( Kirill Fakhroutdinov)
  • Summary:

    There is some obvious copy/paste error: "Presentation options As an alternative to the dashed arrow, it is possible to show an element import by having a text that uniquely identifies the imported element within curly brackets either below or after the name of the namespace..." This 7.3.39 section is about package import - not element import - so that sentence should look like: "As an alternative to the dashed arrow, it is possible to show a package import by having a text that uniquely identifies the imported package within curly brackets either below or after the name of the namespace..."

  • Reported: UML 2.2 — Wed, 3 Dec 2008 05:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    No Data Available

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

Section: 7.3.12 Dependency (from Dependencies)

  • Key: UML23-5
  • Legacy Issue Number: 13136
  • Status: closed  
  • Source: email.com ( Kirill Fakhroutdinov)
  • Summary:

    Explanation to Figure 7.38 - An example of an instantiate dependency - states: "In the example below, the Car class has a dependency on the CarFactory class. In this case, the dependency is an instantiate dependency, where the Car class is an instance of the CarFactory class." (1) Logically and from the diagram itself, it should be opposite: CarFactory class has a dependency on the Car class. (2) Instantiate dependency does not mean that "Car class is an instance of the CarFactory class". That sentence most likely should read simply as "Car class is instantiated by the CarFactory class".

  • Reported: UML 2.2 — Wed, 3 Dec 2008 05:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    Merged with 11489

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

Val(MyCar.Interaction [SVWB

  • Key: UML23-11
  • Legacy Issue Number: 13250
  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    Constraint [2] implies that: "The name of the NamedElement referenced by signature must be the same as that of the Message" The point is that the syntax describe for the signature in the Notation section (p503) cannot ensure that the Message name will be unique inside its Namespace (i.e. its owning Interaction)

  • Reported: UML 2.2 — Tue, 13 Jan 2009 05:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    The message notation for message name was clarified in UML 2.5. The operation isDistinguishableFromwas overidden
    to always be True to avoid namespace problem. These changes address the concern raised in the issue.
    No change needed.
    Disposition: Closed - No Change

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

Section: 12.3.14 Figure 12.29 on page 320

  • Key: UML23-10
  • Legacy Issue Number: 13193
  • Status: closed  
  • Source: Mamezou Co.,Ltd. ( Kenichi Kobayashi)
  • Summary:

    Incorrect: behavior can be shown similarly to Figure 12.29 on page 320, using keywords «precondition» and «postcondition». Correct: behavior can be shown similarly to Figure 12.29 on page 320, using keywords «localPrecondition» and «localPostcondition».

  • Reported: UML 2.2 — Fri, 26 Dec 2008 05:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    This issue is incorrect. The annotations on a CallBehaviorAction that are being described are supposed to show the
    pre- and postconditions of the called behavior, not the local pre- and postconditions. This is stated more explicitly in
    the corresponding wording in the UML 2.5 beta specification, in Subclause 16.3.4, under “Call Behavior Actions”.
    Disposition: Closed - No Change

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

Section: 14.3.24 MessageSort (from BasicInteractions)

  • Key: UML23-8
  • Legacy Issue Number: 13149
  • Status: closed  
  • Source: email.com ( Kirill Fakhroutdinov)
  • Summary:

    "MessageSort is an enumeration of the following values: ... • asynchSignal - The message was generated by an asynchronous send action.createMessage - The message designating the creation of another lifeline object." The "createMessage" should be on a separate line: • asynchSignal - The message was generated by an asynchronous send action. • createMessage - The message designating the creation of another lifeline object.

  • Reported: UML 2.2 — Tue, 9 Dec 2008 05:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    No Data Available

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

Section: 14.3.3 CombinedFragment (from Fragments)

  • Key: UML23-7
  • Legacy Issue Number: 13148
  • Status: closed  
  • Source: email.com ( Kirill Fakhroutdinov)
  • Summary:

    Explanation for: "Presentation Options for “coregion area” ... This means that in a given “coregion” area of a Lifeline all the directly contained fragments are considered separate operands of a parallel combined fragment. See example in Figure 14.12." The "Figure 14.12 - Continuation" - seems to have no example of coregion as expected. Example of coregion could be found on "Figure 14.22 - Sequence Diagrams where two Lifelines refer to the same set of Parts", p.519.

  • Reported: UML 2.2 — Mon, 8 Dec 2008 05:00 GMT
  • Disposition: Resolved — UML 2.3
  • 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:58 GMT

"description" section of the Behavior metaclass

  • Key: UML23-9
  • Legacy Issue Number: 13188
  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    In the "description" section of the Behavior metaclass, there is the following sentence: "A classifier behavior is always a definition of behavior and not an illustration". The consequences of this statement should be explained and especially its impact on the capability of using Interactions for that purpose. A constraint should be added to the specification of the BehavioredClassifier metaclass.

  • Reported: UML 2.2 — Mon, 22 Dec 2008 05:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    In the UML 2.5 beta specification, this sentence still appears in Subclause 13.2.3, under the semantics of
    “Behaviored Classifiers”. However, it is not clear that the sentence is really necessary at all. In the same
    paragraph it says “For example, the classifierBehavior of a Collaboration (see sub clause 11.7) represents
    emergent behavior of all the parts. . . ” Certainly, it is common to use Interactions as Collaboration classifier-
    Behaviors, and it is not really clear what it means to “define” an emergent behavior anyway. The contrast
    of “definition of behavior not an illustration” thus seems methodological, and the sentence can be removed
    without changing the essential specification of classifierBehavior semantics.

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

Parameter isn't package (Heading 2 level)

  • Key: UML23-2
  • Legacy Issue Number: 13092
  • Status: closed  
  • Source: ESL ( Janis Alksnis)
  • Summary:

    Parameter isn't package (Heading 2 level), but class (need to be Heading 3 level under Heading 2 "9.1. BehavioralFeatures package")

  • Reported: UML 2.2 — Fri, 21 Nov 2008 05:00 GMT
  • Disposition: Resolved — UML 2.3
  • 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:58 GMT

Super package should import NamedElement from the Visibilities package, not Namespaces

  • Key: UML23-1
  • Legacy Issue Number: 13091
  • Status: closed  
  • Source: ESL ( Janis Alksnis)
  • Summary:

    Figure 9.48 - The elements defined in the Super package As Classifier is associated to NamedElement's property of visibility, Super package should import NamedElement from the Visibilities package, not Namespaces

  • Reported: UML 2.2 — Fri, 21 Nov 2008 05:00 GMT
  • Disposition: Resolved — UML 2.3
  • 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:58 GMT

description of Interaction provided by the Semantic section inconsistent

  • Key: UML23-12
  • Legacy Issue Number: 13253
  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    The description of Interaction provided by the Semantic section sounds good by itself but is widely inconsistent with the meta-model, according Attributes sections, Association sections and Figures 14.x. For instance: the Semantic section mentions "ordered sets of occurences" that can not be found in the meta-model. It does exist an ordered property in the association between Lifeline and OccurenceSpecification but: first it's not exactly the same thing, second the related property cannot be found anywhere in the meta-classes!... My global feeling is that the chapter 14 of the meta-model is not mature, very (too much?) complex and ambiguous.

  • Reported: UML 2.2 — Wed, 14 Jan 2009 05:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    Semantics of interactions were clarified considerably.
    Disposition: Closed - No Change

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

Section: 14.3.20 Actors in Interactions

  • Key: UML23-4
  • Legacy Issue Number: 13134
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    It is common to model interactions with actors, e.g. to show scenarios how actors interact with the system. For example in the context of a collaboration it is possible to model lifelines that represent system actors. However it is not possible that they receive messages in an interaction. According to constraint [2] in chapter 14.3.20 each message must correspond to an operation or signal. But it is not allowed to have actors with operations or receptions.

  • Reported: UML 2.2 — Tue, 2 Dec 2008 05:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    Merged with 11068

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

Figure 9.20

  • Key: UML23-3
  • Legacy Issue Number: 13093
  • Status: closed  
  • Source: ESL ( Janis Alksnis)
  • Summary:

    Figure 9.20 - The elements defined in the Expressions package Associations • operand: ValueSpecification[*] Specifies a sequence of operands. Subsets Element::ownedElement.

    {non-unique; ordered}
  • Reported: UML 2.2 — Fri, 21 Nov 2008 05:00 GMT
  • Disposition: Resolved — UML 2.3
  • 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:58 GMT

UML 2 Superstructure / CommonBehaviors / Incorrect types in text

  • Key: UML22-1081
  • Legacy Issue Number: 9352
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    TimeConstraint::specification and DurationConstraint::specification properties are shown as having the wrong type in the text (the diagrams are OK). They should be TimeInterval and DurationInterval respectively.

  • Reported: UML 2.0 — Thu, 2 Feb 2006 05:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Resolution: This issue has been resolved in an earlier version of the specification. Disposition: Closed, no change

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

7.3.41 Parameter (from Kernel, AssociationClasses)"

  • Key: UML22-1080
  • Legacy Issue Number: 9337
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Please note however, that (as far as I can see) Parameter only occurs in Kernel, NOT in AssociationClasses. So the correct statement would be "Parameter (from Kernel). This might bear a relation to the already existing FTF issue 8117.

  • Reported: UML 2.0 — Mon, 30 Jan 2006 05:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    No Data Available

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

UML 2.0 issue: ownedMember xsi:type="uml:Stereotype" should be used

  • Key: UML22-1063
  • Legacy Issue Number: 9185
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    ownedMember xsi:type="uml:Stereotype" should be used in XMI instance documents instead of ownedStereotype xsi:type="uml:Stereotype" (especially if it becomes a derived subset).

  • Reported: UML 2.0 — Mon, 28 Nov 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

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

UML 2.0: CMOF/UML mixup for profiles

  • Key: UML22-1062
  • Legacy Issue Number: 9184
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The end of the semantics section for Profiles informally describes a CMOF model equivalent to a Profile. This discussion in the spec about profiles and equivalent MOF metamodels could be confusing and potentially misleading. A profile is an instance of a UML2 model which is not a CMOF model. Therefore the MOF to XMI mapping rules do not apply for instances of a profile. The equivalent CMOF model is a means to explain and formalize how profiles are serialized and exchanged as XMI. The spec should make it clear that the equivalent MOF model is a model-to-model mapping being introduced as a means for describing how a profile is serialized and exchanged using XMI and how an XSD schema for validating instances of a profile is defined.

    The mapping from a profile to a CMOF model is incomplete. For example, there is no statement that an instance of a stereotype maps to an instance of a CMOF::Class. This mapping needs to be completed; e.g., by direct reference

    The Profile to CMOF mapping also needs to specify the XMI tags for persisting and exchanging profiles. According to the UML2 metamodel, instances of a Profile can't have Tags because an instance of a Profile is not a CMOF::Element, UML2 is not reflective. Tools will have to provide tag support for instances of stereotypes some other way. These properties can be left undefined and tools can provide values as needed. Another possible solution would be to specify how the XMI tag values and options for profile exchange would be defined, perhaps derived from other information in the profile. For example:
    nsURI = http://<profilePackagePath>/schemas/<profileName>.xmi
    nsPrefix = <profileName>
    all others use the XMI defaults

  • Reported: UML 2.0 — Mon, 28 Nov 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

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

Required attributes

  • Key: UML22-1069
  • Legacy Issue Number: 9191
  • Status: closed  
  • Source: Eclipse Foundation ( Mr. Kenneth Hussey)
  • Summary:

    Required attributes (i.e. those with a lower bound greater than 0) without a specified default must either be assigned a default or made non-required (see below). There should also be a statement in the specification to the effect that attributes whose values are set to their default need not be serialized.

    uml::Artifact::fileName is required, default is <unspecified>

    uml::Behavior::isReentrant is required, default is <unspecified>

    uml::BehavioralFeature::concurrency is required, default is <unspecified>
    uml::BehavioralFeature::isAbstract is required, default is <unspecified>

    uml::Class::isActive is required, default is <unspecified>

    uml::CombinedFragment::interactionOperator is required, default is <unspecified>

    uml::Comment::body is required, default is <unspecified>

    uml::ConditionalNode::isAssured is required, default is <unspecified>
    uml::ConditionalNode::isDeterminate is required, default is <unspecified>

    uml::DeploymentSpecification::deploymentLocation is required, default is <unspecified>
    uml::DeploymentSpecification::executionLocation is required, default is <unspecified>

    uml::ElementImport::visibility is required, default is <unspecified>

    uml::ExpansionRegion::mode is required, default is <unspecified>

    uml::Expression::symbol is required, default is <unspecified>

    uml::GeneralizationSet::isCovering is required, default is <unspecified>
    uml::GeneralizationSet::isDisjoint is required, default is <unspecified>

    uml::LiteralBoolean::value is required, default is <unspecified>

    uml::LiteralInteger::value is required, default is <unspecified>

    uml::LiteralString::value is required, default is <unspecified>

    uml::LiteralUnlimitedNatural::value is required, default is <unspecified>

    uml::LoopNode::isTestedFirst is required, default is <unspecified>

    uml::Message::messageKind is required, default is <unspecified>
    uml::Message::messageSort is required, default is <unspecified>

    uml::Model::viewpoint is required, default is <unspecified>

    uml::OpaqueAction::body is required, default is <unspecified>

    uml::OpaqueBehavior::body is required, default is <unspecified>

    uml::OpaqueExpression::body is required, default is <unspecified>

    uml::PackageableElement::visibility is required, default is <unspecified>

    uml::PackageImport::visibility is required, default is <unspecified>

    uml::Pseudostate::kind is required, default is <unspecified>

    uml::State::isComposite is required, default is <unspecified>
    uml::State::isOrthogonal is required, default is <unspecified>
    uml::State::isSimple is required, default is <unspecified>
    uml::State::isSubmachineState is required, default is <unspecified>

    uml::StructuredActivityNode::mustIsolate is required, default is <unspecified>

    uml::TimeEvent::isRelative is required, default is <unspecified>

    uml::Transition::kind is required, default is <unspecified>

  • Reported: UML 2.0 — Tue, 29 Nov 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

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

Parameter::effect

  • Key: UML22-1068
  • Legacy Issue Number: 9190
  • Status: closed  
  • Source: Eclipse Foundation ( Mr. Kenneth Hussey)
  • Summary:

    Parameter::effect is documented in the specification as having multiplicity 0..* (instead of 0..1 - this should have been addressed as part of Issue 8261).

  • Reported: UML 2.0 — Tue, 29 Nov 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

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

UML 2.1 XMI Issue

  • Key: UML22-1065
  • Legacy Issue Number: 9187
  • Status: closed  
  • Source: Eclipse Foundation ( Mr. Kenneth Hussey)
  • Summary:

    uml::EncapsulatedClassifier::ownedPort should be derived (from the owned attributes that are instances of Port) so as to be consistent with Package::ownedType, Package::nestedPackage, and Profile::ownedStereotype (see issue 9181).

  • Reported: UML 2.0 — Tue, 29 Nov 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

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

UML 2.0: Inconsistencies in profile example XMI

  • Key: UML22-1064
  • Legacy Issue Number: 9186
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    In the Home Example for Profiles in chapter 18, the body of the text and the examples use different conventions for naming ExtensionEnds "base$Interface", "base_Interface", and "baseInterface" all appear in various places. The spec says it should be base$Interface (although this is not a valid identifier in many common programming languages including Java).

  • Reported: UML 2.0 — Mon, 28 Nov 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

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

parameter of operation isRedefinitionContextValid() is inconistently named

  • Key: UML22-1073
  • Legacy Issue Number: 9195
  • Status: closed  
  • Source: Eclipse Foundation ( Mr. Kenneth Hussey)
  • Summary:

    The parameter of operation isRedefinitionContextValid() is inconistently named in the specification, which in turn cause package merge problems (parameters do not match). The parameter should be consitently named 'redefined', and the OCL for the associated constraints updated accordingly.

  • Reported: UML 2.0 — Tue, 29 Nov 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

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

Compliance package L2 does not merge StructuredActions in the metamodel

  • Key: UML22-1072
  • Legacy Issue Number: 9194
  • Status: closed  
  • Source: Eclipse Foundation ( Mr. Kenneth Hussey)
  • Summary:

    Compliance package L2 does not merge StructuredActions in the metamodel. Also, CompleteActions (merged by L3) does not currently merge StructuredActions.

    In general, higher compliance levels should merge lower compliance levels; the merge relationships in the specification should be reorganized to reflect this.

  • Reported: UML 2.0 — Tue, 29 Nov 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    Resolved by the solution to issue 9182

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

The following properties should not subset DirectedRelationship::target

  • Key: UML22-1071
  • Legacy Issue Number: 9193
  • Status: closed  
  • Source: Eclipse Foundation ( Mr. Kenneth Hussey)
  • Summary:

    The following properties should not subset DirectedRelationship::target since they subset Dependency::supplier, which already subsets DirectedRelationship::target:

    ComponentRealization::realizingClassifier
    Deployment::deployedArtifact
    InterfaceRealization::contract
    Manifestation::utilizedElement
    Substitution::contract

  • Reported: UML 2.0 — Tue, 29 Nov 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

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

The following properties should not subset DirectedRelationship::source

  • Key: UML22-1070
  • Legacy Issue Number: 9192
  • Status: closed  
  • Source: Eclipse Foundation ( Mr. Kenneth Hussey)
  • Summary:

    The following properties should not subset DirectedRelationship::source since they subset Dependency::client, which already subsets DirectedRelationship::source:

    ComponentRealization::abstraction
    Deployment::location
    InterfaceRealization::implementingClassifier
    Substitution::substitutingClassifier

  • Reported: UML 2.0 — Tue, 29 Nov 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

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

Artifact::fileName

  • Key: UML22-1067
  • Legacy Issue Number: 9189
  • Status: closed  
  • Source: Eclipse Foundation ( Mr. Kenneth Hussey)
  • Summary:

    Artifact::fileName appears in the metamodel but is not documented in the specification.

  • Reported: UML 2.0 — Tue, 29 Nov 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

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

uml::Extension::ownedEnd should not subset uml::Association::ownedEnd

  • Key: UML22-1066
  • Legacy Issue Number: 9188
  • Status: closed  
  • Source: Eclipse Foundation ( Mr. Kenneth Hussey)
  • Summary:

    uml::Extension::ownedEnd should not subset uml::Association::ownedEnd since it already (implicitly) redefines it.

    There should be a constraint that states that it is invalid for a property to subset a property with the same name.

  • Reported: UML 2.0 — Tue, 29 Nov 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

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

Figure 12.18: Small typo: "subsets ownedMember" not "ownedmember"

  • Key: UML22-1079
  • Legacy Issue Number: 9235
  • Status: closed  
  • Source: LIANTIS GmbH ( Constantin Szallies)
  • Summary:

    Figure 12.18: Small typo: "subsets ownedMember" not "ownedmember"

  • Reported: UML 2.0 — Mon, 12 Dec 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Discussion: This was resolved in some previous revision. Disposition: Closed, no change

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

Page: 161

  • Key: UML22-1078
  • Legacy Issue Number: 9232
  • Status: closed  
  • Source: LIANTIS GmbH ( Constantin Szallies)
  • Summary:

    Figure 9.7: property "representation" subsets "collaborationUse" not "occurrence"? "Classifier" has no property named "occurrence"!

  • Reported: UML 2.0 — Mon, 12 Dec 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Discussion: This issue has already been fixed in the current version of the specification. Disposition: Closed, no change

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

Issue regarding "Action::effect : String"

  • Key: UML22-1075
  • Legacy Issue Number: 9197
  • Status: closed  
  • Source: Eclipse Foundation ( Mr. Kenneth Hussey)
  • Summary:

    What has become of the dropped property : "Action::effect : String" ? ( referenced in Ballot 7319 )

  • Reported: UML 1.3 — Thu, 30 Nov 2000 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

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

Transition guards cannot currently be evaluated because they have no contex

  • Key: UML22-1074
  • Legacy Issue Number: 9196
  • Status: closed  
  • Source: Eclipse Foundation ( Mr. Kenneth Hussey)
  • Summary:

    Transition guards cannot currently be evaluated because they have no context. Transition should be made a specialization of Namespace and Transition::guard should subset Namespace::ownedRule

  • Reported: UML 2.0 — Tue, 29 Nov 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

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

StateMachine::extendedStateMachine should have a multiplicity of 0..*.

  • Key: UML22-1077
  • Legacy Issue Number: 9224
  • Status: closed  
  • Source: Eclipse Foundation ( Mr. Kenneth Hussey)
  • Summary:

    StateMachine::extendedStateMachine should have a multiplicity of 0..*. It currently does in the text, but it is shown with a multiplicity of 0..1 in Figure 15.3.

  • Reported: UML 2.0 — Thu, 8 Dec 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

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

Behavior::context

  • Key: UML22-1076
  • Legacy Issue Number: 9198
  • Status: closed  
  • Source: Eclipse Foundation ( Mr. Kenneth Hussey)
  • Summary:

    Behavior::context is derived (ensure that this is indicated in the diagram and the text); it should also be read-only.

  • Reported: UML 2.0 — Thu, 1 Dec 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

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

UML 2.0 issue: Package Primitive Types not merged

  • Key: UML22-1058
  • Legacy Issue Number: 9180
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Package PrimitiveTypes is not merged into UML2 and there is no nsURI for InfrastructureLibrary. So there's no way to reference UML primitive types in any UML2 model including profiles. Resolve by merging PrimitiveType into L0.

  • Reported: UML 2.0 — Mon, 28 Nov 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

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

Section: Appendix A: Diagrams

  • Key: UML22-1057
  • Legacy Issue Number: 9179
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    There's no diagram kind for deployment diagrams

  • Reported: UML 2.0 — Sat, 26 Nov 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    No Data Available

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

Section 7.2.1 of ptc/04-10-14

  • Key: UML22-1056
  • Legacy Issue Number: 9146
  • Status: closed  
  • Source: Red Hat ( John Verhaeg)
  • Summary:

    Page 13 of section 7.2.1 of the "Unified Modeling Language (UML) Specification: Infrastructure" (ptc/04-10-14) states:

    "There are minor differences in the design rationale for the other two packages."

    There are actually 4 packages being discussed, with the first being PrimitiveTypes. So, either "two" should be changed to "three" when referring to the "other" packages, or the two packages (amongst the "other" three being discussed) containing the "minor differences in design rationale" should be identified.

  • Reported: UML 2.0 — Thu, 10 Nov 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    No Data Available

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

Section: 7.3.36 Operation

  • Key: UML22-1055
  • Legacy Issue Number: 9143
  • Status: closed  
  • Source: Paranor AG ( Earl Waldin)
  • Summary:

    The BNF for the textual specification of an operation does not allow one to specify the multiplicity of an operation's return type. The current BNF is [<visibility>] <name> ‘(‘ [<parameter-list>] ‘)’ [‘:’ [<return-type>]

    {‘ <oper-property> [‘,’ <oper-property>]* ‘}’] It should allow the multiplicity to be specified in a manner similar to that for a property. For example: [<visibility>] <name> ‘(‘ [<parameter-list>] ‘)’ [‘:’ [<return-type>] [‘[‘ <multiplicity> ‘]’] ‘{‘ <oper-property> [‘,’ <oper-property>]* ‘}

    ’]

  • Reported: UML 2.0 — Tue, 8 Nov 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    No Data Available

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

Section 8 Issue - Component Realization-Classifier multiplicity

  • Key: UML22-1054
  • Legacy Issue Number: 9142
  • Status: closed  
  • Source: Cutter Information ( Oliver Sims)
  • Summary:

    Issue: The multiplicity on the relationship from Realization to Classifier is 1. This seems wrong - it should be 1 or more.

    Rationale:
    A component realization consisting of only a single classifier would be very odd - although not impossible for a Hello World component perhaps.

  • Reported: UML 2.0 — Sat, 10 Sep 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    No Data Available

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

Section: Actions, Figure 156

  • Key: UML22-1053
  • Legacy Issue Number: 9123
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Figure 156, I think LinkEndCreationData and QualifierValue aren't supposed to be on this diagram: - The associations to/from these aren't in the entries for CreateLinkObjectAction of LinkEndCreationData, - endData is inherited from CreateLinkAction and isn't changed. - The qualifier association would clash with the one inherited fromn LinkEndData in CompleteActivities. There is nothing in the spec on why qualifier is specialized this way. - The multiplicity on qualifier would require qualifiers, even when there aren't any.

  • Reported: UML 2.0 — Thu, 27 Oct 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

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

UML 2.1 Regressions

  • Key: UML22-1052
  • Legacy Issue Number: 9122
  • Status: closed  
  • Source: Eclipse Foundation ( Mr. Kenneth Hussey)
  • Summary:

    The following regressions were introduced in ballot 10:

    Issue 8134

    DeployedArtifact should NOT specialize Kernel::NamedElement since it already specializes Dependencies::NamedElement, and adding a redundant generalization violates the uniqueness constraint on Classifier::general (in the merged result).

    Issue 8136

    DeploymentSpecification should NOT specialize Artifacts::Artifact since it already specializes Nodes::Artifact, and adding a redundant generalization violates the uniqueness constraint on Classifier::general (in the merged result).

    Issue 8457

    The proposed new Figure 124 introduces an undesired (generalization) dependency between Kernel and Dependencies. The preferred resolution would be for Artifact (not Kernel::Namespace) to specialize Dependencies::NamedElement. Figure 124 should be:

    The proposed new Figure 77 introduces an undesired (generalization) dependency between Kernel and Dependencies. The preferred resolution would be for Component (not Kernel::Namespace) to specialize Dependencies::NamedElement. Figure 77 should be:

    Issue 8468

    UseCase::extend must NOT subset Classifier::feature because Extend is not a specialization of Feature. Likewise, UseCase::include must NOT subset Classifier::feature because Include is not a specialization of Feature.

  • Reported: UML 2.0 — Thu, 27 Oct 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    agreed

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

Realization classifier

  • Key: UML22-1051
  • Legacy Issue Number: 9119
  • Status: closed  
  • Source: Eclipse Foundation ( Mr. Kenneth Hussey)
  • Summary:

    The Realization classifier should not be redefined in UML::Components::BasicComponents. In a component realization, the direction of the dependency is reversed, i.e. the client (source) of the dependency is the component abstraction and the supplier (target) of the dependency is the realizing classifier; this conflicts with other specializations of Realization (e.g. InterfaceRealization).

    -> A new specialization ('ComponentRealization') should be introduced instead, upon which the 'abstraction' and 'realizingClassifier' properties would be defined. This could be achieved by simply renaming Realization to 'ComponentRealization' in UML::Components::BasicComponents and adding a generalization from it to UML::Classes::Dependencies::Realization.

  • Reported: UML 2.0 — Wed, 26 Oct 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

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

UML 2 issue: redefining isComposite on association ends

  • Key: UML22-1050
  • Legacy Issue Number: 9117
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The association ends IntervalConstraint::specification, TimeConstraint::specification, and DurationConstraint::specification should be composite, since, redefining an isComposite = true property with one where isComposite = false causes problems in the XMI generation. More on isComposite redefinition : 1) LinkEndCreationData::qualifier should be composite.

    2) It should be considered inconsistent for a non-composite property to redefine a composite property. The body expression for Property::isConsistentWith(RedefinableElement) should be updated as follows:
    This should probably be disallowed in general.

  • Reported: UML 2.0 — Thu, 27 Oct 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

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

Classifier::parameter, Operation::parameter, and ConnectableElement::parame

  • Key: UML22-1049
  • Legacy Issue Number: 9110
  • Status: closed  
  • Source: Eclipse Foundation ( Mr. Kenneth Hussey)
  • Summary:

    Classifier::parameter, Operation::parameter, and ConnectableElement::parameter should be renamed to templateParameter (they redefine ParameterableElement::templateParameter) to make it clear that these are template parameters (in fact not related to the Parameter metaclass). ParameterableElement::owningParameter should also be renamed to owningTemplateParameter, for consistency.

  • Reported: UML 2.0 — Wed, 19 Oct 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    agreed

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

Component::realization should NOT be derived

  • Key: UML22-1048
  • Legacy Issue Number: 9109
  • Status: closed  
  • Source: Eclipse Foundation ( Mr. Kenneth Hussey)
  • Summary:

    Component::realization should NOT be derived

  • Reported: UML 2.0 — Wed, 19 Oct 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

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

Rename ActivityGroup::activity to containingActivity

  • Key: UML22-1047
  • Legacy Issue Number: 9108
  • Status: closed  
  • Source: Eclipse Foundation ( Mr. Kenneth Hussey)
  • Summary:

    StructuredActivityNode inherits two properties with the same name, ActivityNode::activity and ActivityGroup::activity.

    -> Rename ActivityGroup::activity to containingActivity.

  • Reported: UML 2.0 — Wed, 19 Oct 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

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

Rename OpaqueAction::output to outputPin.

  • Key: UML22-1046
  • Legacy Issue Number: 9107
  • Status: closed  
  • Source: Eclipse Foundation ( Mr. Kenneth Hussey)
  • Summary:

    OpaqueAction::output (non-derived) invalidly redefines Action::output (derived union).

    -> Rename OpaqueAction::output to outputPin.

  • Reported: UML 2.0 — Wed, 19 Oct 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

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

Make ActivityGroup::containedNode a derived union

  • Key: UML22-1045
  • Legacy Issue Number: 9106
  • Status: closed  
  • Source: Eclipse Foundation ( Mr. Kenneth Hussey)
  • Summary:

    ActivityNode::inGroup is a derived union but its opposite, ActivityGroup::containedNode, is not.

    -> Make ActivityGroup::containedNode a derived union. As a result, ActivityPartition::containedNode, StructuredActivityNode::containedNode, and InterruptibleActivityRegion::containedNode will invalidly redefine ActivityGroup::containedNode, so rename ActivityPartition::containedNode to node, rename StructuredActivityNode::containedNode to ownedNode, rename InterruptibleActivityRegion::containedNode to node, and replace

    {redefines containedNode}

    with

    {subsets containedNode}

    on all three.

  • Reported: UML 2.0 — Wed, 19 Oct 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

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

Make ActivityGroup::containedEdge a derived union

  • Key: UML22-1044
  • Legacy Issue Number: 9105
  • Status: closed  
  • Source: Eclipse Foundation ( Mr. Kenneth Hussey)
  • Summary:

    ActivityEdge::inGroup is a derived union but its opposite, ActivityGroup::containedEdge, is not.

    -> Make ActivityGroup::containedEdge a derived union. As a result, ActivityPartition::containedEdge and StructuredActivityNode::containedEdge will invalidly redefine ActivityGroup::containedEdge, so rename ActivityPartition::containedEdge to edge, rename StructuredActivityNode::containedEdge to ownedEdge, and replace

    {redefines containedEdge}

    with

    {subsets containedEdge}

    on both.

  • Reported: UML 2.0 — Wed, 19 Oct 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

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

compliance levels L2 and L3

  • Key: UML22-1039
  • Legacy Issue Number: 9098
  • Status: closed  
  • Source: Eclipse Foundation ( Mr. Kenneth Hussey)
  • Summary:

    In (merged) compliance levels L2 and L3, ExtensionEnd::lower (non-derived) invalidly redefines feature MultiplicityElement::lower (derived).

    -> Either remove this redefinition (of the default value) or add a Profiles package to UML and redefine ExtensionEnd::lower to be derived.

  • Reported: UML 2.0 — Wed, 19 Oct 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

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

Change type of WriteStructuralFeatureAction::value to ValueSpecification

  • Key: UML22-1038
  • Legacy Issue Number: 9097
  • Status: closed  
  • Source: Eclipse Foundation ( Mr. Kenneth Hussey)
  • Summary:

    TimeObservationAction::now (type TimeExpression) invalidly redefines WriteStructuralFeatureAction::value (type InputPin) because TimeExpression is not a specialization of InputPin.

    -> Change type of WriteStructuralFeatureAction::value to ValueSpecification?

  • Reported: UML 2.0 — Wed, 19 Oct 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

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

Change type of WriteStructuralFeatureAction::value

  • Key: UML22-1037
  • Legacy Issue Number: 9096
  • Status: closed  
  • Source: Eclipse Foundation ( Mr. Kenneth Hussey)
  • Summary:

    DurationObservationAction::duration (type Duration) invalidly redefines WriteStructuralFeatureAction::value (type InputPin) because Duration is not a specialization of InputPin.

    -> Change type of WriteStructuralFeatureAction::value to ValueSpecification?

  • Reported: UML 2.0 — Wed, 19 Oct 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

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

UML 2.0: separate profile application from profile importing

  • Key: UML22-1061
  • Legacy Issue Number: 9183
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Package::appliedProfile should not subset packageImport. Why not? A profile can be imported without being applied, but any applied profile is also implicitly imported in order to make the namespace visible. (The current assumption that a package import implies a profile application does not allow importing of profiles without application – which might be required just for namespace purposes.)

    The simplest solution is to define ProfileApplication to be a subclass of DirectedRelationship with a meta-association (Profile::appliedProfile : Profile) indicating the applied profile

  • Reported: UML 2.0 — Mon, 28 Nov 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

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

UML 2.0: invalid package merge diagrams for compliance points

  • Key: UML22-1060
  • Legacy Issue Number: 9182
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The diagrams in section 2 describing the compliance levels of UML 2, should show:

    (1) have a separate package for each level (instead of the "UML" package); e.g., L2 for level 2.

    (2) each package except L0 should also merge the package belonging to the immediately preceding level (e.g., L2 should merge package L1).

  • Reported: UML 2.0 — Mon, 28 Nov 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

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

UML 2.0 issue: Profile::ownedStereotype should be derived

  • Key: UML22-1059
  • Legacy Issue Number: 9181
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Profile::ownedStereotype should be derived (just like Package::/ownedType) from those ownedMembers which are Stereotypes.

  • Reported: UML 2.0 — Mon, 28 Nov 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

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

Rename LinkAction::input to inputPin

  • Key: UML22-1043
  • Legacy Issue Number: 9104
  • Status: closed  
  • Source: Eclipse Foundation ( Mr. Kenneth Hussey)
  • Summary:

    LinkAction::input (non-derived) invalidly redefines Action::input (derived union).

    -> Rename LinkAction::input to inputPin.

  • Reported: UML 2.0 — Wed, 19 Oct 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

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

Rename OpaqueAction::input to inputPin

  • Key: UML22-1042
  • Legacy Issue Number: 9103
  • Status: closed  
  • Source: Eclipse Foundation ( Mr. Kenneth Hussey)
  • Summary:

    OpaqueAction::input (non-derived) invalidly redefines Action::input (derived union).

    -> Rename OpaqueAction::input to inputPin.

  • Reported: UML 2.0 — Wed, 19 Oct 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

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

Rename InformationFlow::source

  • Key: UML22-1041
  • Legacy Issue Number: 9100
  • Status: closed  
  • Source: Eclipse Foundation ( Mr. Kenneth Hussey)
  • Summary:

    InformationFlow::source (non-derived) invalidly redefines DirectedRelationship::source (derived union).

    -> Rename InformationFlow::source to informationSource and remove

    {redefines source}

    .

  • Reported: UML 2.0 — Wed, 19 Oct 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

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

Rename InformationFlow::target

  • Key: UML22-1040
  • Legacy Issue Number: 9099
  • Status: closed  
  • Source: Eclipse Foundation ( Mr. Kenneth Hussey)
  • Summary:

    InformationFlow::target (non-derived) invalidly redefines DirectedRelationship::target (derived union).

    -> Rename InformationFlow::target to informationTarget and remove

    {redefines target}

    .

  • Reported: UML 2.0 — Wed, 19 Oct 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

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

Rename ActivityPartition::subgroup to subpartition

  • Key: UML22-1036
  • Legacy Issue Number: 9095
  • Status: closed  
  • Source: Eclipse Foundation ( Mr. Kenneth Hussey)
  • Summary:

    ActivityPartition::subgroup (non-derived) invalidly redefines ActivityGroup::subgroup (derived union).

    -> Rename ActivityPartition::subgroup to subpartition, replace

    {redefines subgroup}

    with

    {subsets subgroup}

    .

  • Reported: UML 2.0 — Wed, 19 Oct 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

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

Replace {redefines redefinedElement}

  • Key: UML22-1035
  • Legacy Issue Number: 9094
  • Status: closed  
  • Source: Eclipse Foundation ( Mr. Kenneth Hussey)
  • Summary:

    State::redefinedState (non-derived) invalidly redefines RedefinableElement::redefinedElement (derived union).

    -> Replace

    {redefines redefinedElement}

    with

    {subsets redefinedElement}

    .

  • Reported: UML 2.0 — Wed, 19 Oct 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

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

Replace {redefines redefinedElement}

  • Key: UML22-1034
  • Legacy Issue Number: 9093
  • Status: closed  
  • Source: Eclipse Foundation ( Mr. Kenneth Hussey)
  • Summary:

    Transition::redefinedTransition (non-derived) invalidly redefines RedefinableElement::redefinedElement (derived union).

    -> Replace

    {redefines redefinedElement}

    with

    {subsets redefinedElement}

    .

  • Reported: UML 2.0 — Wed, 19 Oct 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

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

Replace {redefines redefinedElement}

  • Key: UML22-1033
  • Legacy Issue Number: 9092
  • Status: closed  
  • Source: Eclipse Foundation ( Mr. Kenneth Hussey)
  • Summary:

    Region::extendedRegion (non-derived) invalidly redefines RedefinableElement::redefinedElement (derived union).

    -> Replace

    {redefines redefinedElement}

    with

    {subsets redefinedElement}

    .

  • Reported: UML 2.0 — Wed, 19 Oct 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

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

body expression for Property::isConsistentWith(RedefinableElement)

  • Key: UML22-1026
  • Legacy Issue Number: 9085
  • Status: closed  
  • Source: Eclipse Foundation ( Mr. Kenneth Hussey)
  • Summary:

    The body expression for Property::isConsistentWith(RedefinableElement) is incorrect; it should be:

    result = redefinee.oclIsKindOf(Property) and
    let prop : Property = redefinee.oclAsType(Property) in
    (prop.type.conformsTo(self.type) and
    ((prop.lowerBound()>notEmpty() and self.lowerBound()>notEmpty()) implies prop.lowerBound() >= self.lowerBound()) and
    ((prop.upperBound()>notEmpty() and self.upperBound()>notEmpty()) implies prop.lowerBound() <= self.lowerBound()) and
    (self.isDerived implies prop.isDerived))

  • Reported: UML 2.0 — Wed, 19 Oct 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

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

following imports from merged packages to unmerged packages should be remov

  • Key: UML22-1025
  • Legacy Issue Number: 9084
  • Status: closed  
  • Source: Eclipse Foundation ( Mr. Kenneth Hussey)
  • Summary:

    UML::Deployments::ComponentDeployments -> UML::CommonBehaviors
    UML::StateMachines::ProtocolStateMachines -> UML::CommonBehaviors
    UML::UseCases -> UML::CommonBehaviors

    UML::AuxiliaryConstructs::InformationFlows -> UML::CompositeStructures
    UML::AuxiliaryConstructs::Models -> UML::CompositeStructures
    UML::Classes::AssociationClasses -> UML::CompositeStructures
    UML::CommonBehaviors::Communications -> UML::CompositeStructures
    UML::Interactions::Fragments -> UML::CompositeStructures
    UML::StateMachines::BehaviorStateMachines -> UML::CompositeStructures
    UML::StateMachines::ProtocolStateMachines -> UML::CompositeStructures

  • Reported: UML 2.0 — Wed, 19 Oct 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

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

UML2 Superstructure Fig 2.2 Incomplete

  • Key: UML22-1024
  • Legacy Issue Number: 9080
  • Status: closed  
  • Source: Thematix Partners LLC ( Dr. Doug Tolbert)
  • Summary:

    The current version of the UML 2 Superstructure specification
    (formal/05-07-04) has a diagram for the (top-level) package merges
    comprising L1 (Figure 2.2). The packages that are shown as merged in
    the diagram are: BasicActivities, BasicInteractions, Interfaces and
    UseCases. The definitional XML file for L1, however, actually merges
    BasicActivities, BasicInteractions, UseCases, Communicatiions and
    InternalStructures

  • Reported: UML 2.0 — Fri, 14 Oct 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    This is resolved by the resolutions to issues 9180 and 8459 (ballot 12).

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

Section: 14.4

  • Key: UML22-1023
  • Legacy Issue Number: 9077
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The statement "Interaction Overview Diagrams are specialization of Activity Diagrams that represent Interactions." is misleading. An Interaction Overview Diagram is not a special activity diagram. It just re-uses the activity notation.

  • Reported: UML 2.0 — Wed, 12 Oct 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

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

Section: Common Behaviors

  • Key: UML22-1020
  • Legacy Issue Number: 9007
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    In Description section of Common Behaviors, CallConcurrencyKind, how can "Multiple invocations of a behavioral feature" occuring simultaneously have a "first behavioral feature". Full text: "Multiple invocations of a behavioral feature may occur simultaneously to one instance, but only one is allowed to commence. The others are blocked until the performance of the first behavioral feature is complete. It is the responsibility of the system designer to ensure that deadlocks do not occur due to simultaneous blocks."

  • Reported: UML 2.0 — Sun, 25 Sep 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    While nit-picking, the issue submitter is correct

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

Section: Actions

  • Key: UML22-1019
  • Legacy Issue Number: 9006
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Figure 143 should show MultiplicityElement as being from Kernel (the MDL file accidentally used a copy).

  • Reported: UML 2.0 — Sun, 25 Sep 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Discussion: This issue was fixed in a previous revision. Disposition: Closed, no change

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

7.3.22 InstanceSpecification

  • Key: UML22-1022
  • Legacy Issue Number: 9023
  • Status: closed  
  • Source: Anonymous
  • Summary:

    on reading UML Superstructure I found a little mistake regarding chapter
    >7.3.22 InstanceSpecification. This inconsistency seems although to be
    >corrected within UML Infrasturcture.
    >UML Superstructure, page 79, InstanceSepcification - Associations
    >classifier : Classifier [0..*] ...
    >
    >UML Infrastructure, page 66, InstanceSpecification - Associations
    >classifier : Classifier [1..*]
    >
    >I guess the specification within UML Infrasturcture is true. However I
    >hope to get some kind of confirmation from you (as I want to be sure).

  • Reported: UML 2.0 — Wed, 28 Sep 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see page 504 of ptc/2006-04-01

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

Section: Activities

  • Key: UML22-1021
  • Legacy Issue Number: 9010
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Clarify that multiple arrows coming out of an object-node-in-the-middle notation has the semantics of multiple edges coming out of an output pin.

  • Reported: UML 2.0 — Sun, 25 Sep 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

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

Section: Classes

  • Key: UML22-1018
  • Legacy Issue Number: 9003
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Association.memberEnd should specialize Relationship:relatedElement. Programs accessing the repository with RelatedElement should get the elements being associated

  • Reported: UML 2.0 — Sun, 25 Sep 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    No Data Available

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

Section: Activities

  • Key: UML22-1017
  • Legacy Issue Number: 9000
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    In Figure 195, subsetting opposite Variable should be of namespace, rather than owner

  • Reported: UML 2.0 — Sun, 25 Sep 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

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

Invalid stereotype in StandardProfile

  • Key: UML22-1016
  • Legacy Issue Number: 8996
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    Page 671 (ormal/05-07-04),<< script>> is in StandardProfileL1, but its base element, Deployments::Artifact isn’t in L1.

  • Reported: UML 2.0 — Thu, 22 Sep 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    See issue 8459 for disposition

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

UML 2 Super / miscellaneous figure-text discrepancies

  • Key: UML22-1015
  • Legacy Issue Number: 8993
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    There are a few discrepancies between the figures and the latest Superstructure text (formal/05-07-04) that need to be fixed:

    (1) figure 15.2 contains State::doAcvity – it should be State::doActivity (the textual description of this item uses correct spelling)

    (2) resolutions to issues 6185 and 7342 indicate that Behavior::context should be derived and that it should subset "redefinitionContext". This needs to be fixed in figure 13.6. Also, the description in the text for this item on page 417 should be updated to show that "context" is derived ("/context").

    (3) the association end Pseudostate::state shown in figure 15.2 is not documented. It should be.

  • Reported: UML 2.0 — Thu, 22 Sep 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see pages 500 -501 of ptc/2006-04-01

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

Rename Package::ownedMember

  • Key: UML22-1028
  • Legacy Issue Number: 9087
  • Status: closed  
  • Source: Eclipse Foundation ( Mr. Kenneth Hussey)
  • Summary:

    Package::ownedMember (non-derived) invalidly redefines Namespace::ownedMember (derived union).

    -> Rename Package::ownedMember to packagedElement and replace

    {redefines ownedMember}

    with

    {subsets ownedMember}

    . Update all references to ownedMember (e.g. in sample profiles XMI) as appropriate.

  • Reported: UML 2.0 — Wed, 19 Oct 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

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

Rename Constraint::namespace

  • Key: UML22-1027
  • Legacy Issue Number: 9086
  • Status: closed  
  • Source: Eclipse Foundation ( Mr. Kenneth Hussey)
  • Summary:

    Constraint::namespace (non-derived) invalidly redefines NamedElement::namespace (derived union).

    -> Rename Constraint::namespace to context, replace

    {redefines namespace, subsets context}

    with

    {subsets namespace}

    on it, and remove Constraint::context.

  • Reported: UML 2.0 — Wed, 19 Oct 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see pages 510 - 512 of ptc/2006-04-01

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

Rename ActivityEdge::redefinedElement

  • Key: UML22-1030
  • Legacy Issue Number: 9089
  • Status: closed  
  • Source: Eclipse Foundation ( Mr. Kenneth Hussey)
  • Summary:

    ActivityEdge::redefinedElement (non-derived) invalidly redefines RedefinableElement::redefinedElement (derived union).

    -> Rename ActivityEdge::redefinedElement to redefinedEdge, replace

    {redefines redefinedElement}

    with

    {subsets redefinedElement}

    .

  • Reported: UML 2.0 — Wed, 19 Oct 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

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

Rename Component::ownedMember

  • Key: UML22-1029
  • Legacy Issue Number: 9088
  • Status: closed  
  • Source: Eclipse Foundation ( Mr. Kenneth Hussey)
  • Summary:

    Component::ownedMember (non-derived) invalidly redefines Namespace::ownedMember (derived union).

    -> Rename Component::ownedMember to packagedElement and replace

    {redefines ownedMember}

    with

    {subsets ownedMember}

    . Update any references to ownedMember as appropriate.

  • Reported: UML 2.0 — Wed, 19 Oct 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

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

Replace {redefines redefinedElement}

  • Key: UML22-1032
  • Legacy Issue Number: 9091
  • Status: closed  
  • Source: Eclipse Foundation ( Mr. Kenneth Hussey)
  • Summary:

    StateMachine::extendedStateMachine (non-derived) invalidly redefines RedefinableElement::redefinedElement (derived union).

    -> Replace

    {redefines redefinedElement}

    with

    {subsets redefinedElement}

    .

  • Reported: UML 2.0 — Wed, 19 Oct 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

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

Rename ActivityNode::redefinedElement

  • Key: UML22-1031
  • Legacy Issue Number: 9090
  • Status: closed  
  • Source: Eclipse Foundation ( Mr. Kenneth Hussey)
  • Summary:

    ActivityNode::redefinedElement (non-derived) invalidly redefines RedefinableElement::redefinedElement (derived union).

    -> Rename ActivityNode::redefinedElement to redefinedNode, replace

    {redefines redefinedElement}

    with

    {subsets redefinedElement}

    .

  • Reported: UML 2.0 — Wed, 19 Oct 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

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

Section: 6.5

  • Key: UML22-1012
  • Legacy Issue Number: 8987
  • Status: closed  
  • Source: Vtron ( Minghua Liu)
  • Summary:

    "“Part I. Structure” defines the static, structural constructs (e.g., classes, components, nodes artifacts) used in various structural diagrams, such as class diagrams, component diagrams, and deployment diagrams. Part II - “Behavior” specifies the dynamic, behavioral constructs (e.g., activities, interactions, state machines) used in various behavioral diagrams, such as activity diagrams, sequence diagrams, and state machine diagrams. “Part ~~~~ I. Structure” defines auxiliary constructs ~~~~~~~~~~~~~~ (e.g., information flows, models, templates, primitive types) and the profiles used to customize UML for various domains, platforms, and methods" The words underlined shoude be "Part III - Supplement.

  • Reported: UML 2.0 — Wed, 7 Sep 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    No Data Available

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

UML2 should specify default property ownership for association ends

  • Key: UML22-1011
  • Legacy Issue Number: 8978
  • Status: closed  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    UML2 should define the defaults for property ownership and the explicit meaning of navigation notation. It should also provide notation for overriding these defaults in order to specify explicity the classifier that owns a property without relying on navigability. This recognizes a common notation practice and will result in predictable metamodel interchange. I general, the UML2 spec should attempt to avoid situations like the pair EF and IJ in figure 21, and instead use sensible defaults. If the default isn't what the model wants, then there should be notation to explicitly say what is needed. This will limit semantic variation points or unspecified notation meaning that may result in interchange and interoperability issues.

    The diagram conventions used in Superstructure section 6.5.2 tie navigability and property ownership together in a manner that is consistent with the notaiton used in Basic and EMOF. However section 7.3.1 Notation for Association says:

    Various options may be chosen for showing navigation arrows on a diagram. In practice, it is often convenient to suppress
    some of the arrows and crosses and just show exceptional situations:
    • Show all arrows and x’s. Navigation and its absence are made completely explicit.
    • Suppress all arrows and x’s. No inference can be drawn about navigation. This is similar to any situation in which
    information is suppressed from a view.
    • Suppress arrows for associations with navigability in both directions, and show arrows only for associations with oneway
    navigability. In this case, the two-way navigability cannot be distinguished from situations where there is no navigation
    at all; however, the latter case occurs rarely in practice.

    This is fine, but given a UML2 diagram what are we to assume if all navigations are not explicit as in the first bullet? Wouldn't such such a model be ambiguous? Should UML2 specify which one of these conventions are implied by the notation? The last bullet represents common practice as well as the conventsions used in the UML2 specification. Perhaps the UML2 spec should to be specific about what the notation means and not leave this up to the reader.

    Later in the spec (page 42) under Issue 6243, Figure 22 shows a class containing a property with non-primitive type and indicates this is an ownedAttribute of the class, and can be shown as an association too as described in Basic and EMOF. What it doesn't say is what the notation

    by itself means. We know ClassA can navigate to b, but we don't know anything about who owns the properties and therefore where the ends go in an instance of the metamodel. Are they both ownedEnds of the Association? Is b an ownedAttribute of ClassA and a is an ownedEnd? Since there is currently no notation for specifying which classifier owns the properties, the notation should specify the default owners. Otherwise different tools may produce different XMI as it is not clear when a property on an association end is an ownedEnd of the association or an ownedAttribute of one of the associated classes.

    The conventions in 6.5.2 should be the definitive notation for navigation arrows (with x on the ends options to make non-navigable explicit), and also specifies the default for property ownership. That is, the bullet lists in 7.3.1 should be replaced with those in 6.5.2 for association navigability and property ownership.

    Then a notation should be specified for explicitly stating property ownership when the default is not appropriate.

  • Reported: UML 2.0 — Fri, 26 Aug 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

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

Figure 430 references invalid metaclass

  • Key: UML22-1002
  • Legacy Issue Number: 8947
  • Status: closed  
  • Source: Eclipse Foundation ( Mr. Kenneth Hussey)
  • Summary:

    Figure 430 references an 'IntegerExpression' metaclass that doesn't exist. Either such a metaclass (and others for other kinds of expressions?) should be added, or the example should be changed to use a different type of expression.

  • Reported: UML 2.0 — Tue, 2 Aug 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

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

Section: 9.3.5

  • Key: UML22-1001
  • Legacy Issue Number: 8946
  • Status: closed  
  • Source: Bergson TA ( Marc Hamilton)
  • Summary:

    A Property is a ConnectableElement, which currently is (should be?) a TypedElement. The Description in 9.3.5 however states: "A ConnectableElement is an abstract metaclass representing a set of instances that play roles of a classifier. Connectable elements may be joined by attached connectors and specify configurations of linked instances to be created within an instance of the containing classifier. Note on p.84 states: "When used to specify the existence of an entity in a modelled system, an instance specification represents part of that system." In 9.3.12. it says:"When an instance of the containing classifier is created, a set of instances corresponding to its properties may be created either immediately or at some later time. These instances are instances of the classifier typing the property. A property specifies that a set of instances may exist; this set of instances is a subset of the total set of instances specified by the classifier typing the property. A part declares that an instance of this classifier may contain a set of instances by composition." So, the concepts must be related. I propose that a ConnectableElement is a specialization of InstanceSpecification, not just a TypedElement. Current problems in practise: A TypedElement is not a PackageableElement and it thus cannot be imported in some other namespace. This makes is hard to create orthogonal views of architectures (e.g. logical vs. execution) in which 'roles' (parts!) are shared. On the other hand, using InstanceSpecifications instead of "Parts" makes it impossible to refer them in interactions. Besides, the meaning of an InstanceSpecification in the context of a classifier is unclear in contrast to the Property.

  • Reported: UML 2.0 — Tue, 2 Aug 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Discussion: The concept of connectable element is not an instance specification, so it would be a mistake to make it a specialization of InstanceSpecification. As the issue also points out, doing so would cause problems with interactions (where connectable elements are heavily used) as well as with their meaning. The issue really at hand appears to be that ConnectableElements are not packageable elements. The reason is that they have really no meaning outside of the context of the classifier they are owned by and thus would not be packaged separately. Disposition: Closed, no change

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

UML2 Navigability Impact on Tools

  • Key: UML22-1006
  • Legacy Issue Number: 8963
  • Status: closed  
  • Source: Thematix Partners LLC ( Dr. Doug Tolbert)
  • Summary:

    The notion of navigability for association ends may be interpreted as
    limiting the ability of UML tools to traverse associations with
    non-navigable ends. However, discussion among RTF members indicates
    that UML tools need not be specifically limited in their ability to
    traverse non-navigable ends. To prevent confusion about the impact of
    non-navigable ends among tool developers studying the specification, the
    ability of UML repositories and other tooling to ignore navigability
    limitations should be explicitly stated.

  • Reported: UML 2.0 — Thu, 11 Aug 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

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

UML 2 XMI DTD requirement

  • Key: UML22-1005
  • Legacy Issue Number: 8957
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    In section 6.5.1 of both the RFP for the UML 2 Superstructure and the RFP for the UML 2 Infrastructure it is required that

    Proposals shall specify an XMI DTD for the UML metamodel.

    This was based on the assumption that such schemas carry sufficient information for tool vendors to construct facilities for meaningful interchange of models. Unfortunately, due to the introduction of certain more complex features such as package merge in UML 2.0, these schemas are not sufficient. On the other hand, the XMI for the individual compliance levels (Lm, L0, L1, L2, and L3) is sufficient for the interchange objective. Therefore, instead of the XMI schemas, it is proposed to make the latter normative for the UML 2 Superstructure and Infrastructure specs.

  • Reported: UML 2.0 — Wed, 10 Aug 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    This is resolved by the resolution to 3898 and the explanatory text for 8678.

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

UML2 issue: {unrestricted} described in text but not BNF

  • Key: UML22-998
  • Legacy Issue Number: 8935
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    In section 7.3.49 of Super, and 9.2.2 of Infra,

    {unrestricted} is given as a notation option: "A modifiable structural feature is shown using {unrestricted}

    as part of the notation for the structural feature."
    However unrestricted is is not included in the BNF for Property (in 7.3.44).
    It does not seem useful as a keyword since it is the default; nor is 'unrestricted' a very suggestive term for the meaning.

    Proposed Resolution:
    Delete the above sentence from 7.3.49 of Super, and 9.2.2 of Infra.

  • Reported: UML 2.0 — Tue, 19 Jul 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

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

UML Superstructure / Actions / Missing package heading

  • Key: UML22-997
  • Legacy Issue Number: 8933
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    In section 11.3.21, (Actions, LinkAction), the second constraitns section should include the phrase (CompleteActions) at the end

  • Reported: UML 2.0 — Mon, 18 Jul 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

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

UML 2 Super / Undocumented properties

  • Key: UML22-1010
  • Legacy Issue Number: 8976
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The following properties appear in the metamodel diagrams but are not documented in the spec:

    UML::Classes::Kernel::Property::class
    UML::Components::BasicComponents::Connector::contract
    UML::Components::BasicComponents::Realization::abstraction
    UML::Components::BasicComponents::Realization::realizingClassifier
    UML::Interactions::BasicInteractions::Lifeline::coveredBy

  • Reported: UML 2.0 — Thu, 25 Aug 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see pages 494 - 495 of ptc/2006-04-01

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

Page: 591,592

  • Key: UML22-1009
  • Legacy Issue Number: 8968
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Constraint 9 and 10 state that entry and exit points are only allowed in the topmost region of a statemachine. On page 592 the entry/exit point semantic describes that these points are also allowed on composite states (see also issue 6075). I think the constraints don't take into account that composite states are also allowed.

  • Reported: UML 2.0 — Wed, 17 Aug 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

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

Core::Constructs::Operation

  • Key: UML22-1008
  • Legacy Issue Number: 8966
  • Status: closed  
  • Source: Vienna University of Technology ( Lorenz Froihofer)
  • Summary:

    This is a question or an issue for the UML 2.0 Superstructure and Infrastructure Revision Task Force (http://www.omg.org/issues/uml2-rtf.html An operation, e.g. Core::Constructs::Operation does no longer contain the isAbstract attribute (compared to UML version 1.5). I could not find a note in any of the classes within the inheritance hierarchy stating that this is a change to the 1.x versions. Was this attribute intentionally dropped for version 2.0? If yes, what is the suggested replacement?

  • Reported: UML 2.0 — Tue, 9 Aug 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Discussion: This ability is still there, since the attribute isAbstract is inherited from BehavioralFeature (which is a superclass of Operation) as defined in CommonBehaviors. Disposition: Closed, no change

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

Interaction::lifeline should be ordered

  • Key: UML22-1007
  • Legacy Issue Number: 8964
  • Status: closed  
  • Source: Eclipse Foundation ( Mr. Kenneth Hussey)
  • Summary:

    Interaction::lifeline should be ordered so as to dictate the ordering of lifelines (in a diagram for example).

  • Reported: UML 2.0 — Fri, 12 Aug 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    No Data Available

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

UML 2 Classes Notation for association end ownership

  • Key: UML22-1004
  • Legacy Issue Number: 8956
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    UML 2.0 has separated the concepts of navigability from association end ownership. However there is as yet no explicit notation for specifying who owns an association end. An explicit notation is required and, possibly, a set of default notational conventions for the most frequent cases.

  • Reported: UML 2.0 — Wed, 10 Aug 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see pages 489 - 490 of ptc/2006-04-01

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

connection point reference

  • Key: UML22-1003
  • Legacy Issue Number: 8955
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    Is this known issue, that just one ConnectionPointReference can point into same connection point?
    It's not possible to create two SubMachineStates with ConnectionPointReferences assigned with same StateMachine, because meta Association between PseudoState (connection point) and ConnectionPointReference has multiplicity [0..1].

    This destructs all concept of reusable StateMachines

  • Reported: UML 2.0 — Wed, 10 Aug 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

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

UML 2 Super / Collaboration use issues (02)

  • Key: UML22-1014
  • Legacy Issue Number: 8990
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    2) The caption of Figure 106 still refers to "collaboration occurrence" (should be "collaboration use")

  • Reported: UML 2.0 — Thu, 22 Sep 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

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

UML 2 Super / Collaboration use issues (01)

  • Key: UML22-1013
  • Legacy Issue Number: 8989
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    (1) All the dependencies in Figure 109 of ptc/04-10-02 are pointing in the wrong direction. Note that constraint [1] of CollaborationUse says:
    "All the client elements of a roleBinding are in one classifier and all supplier elements of a roleBinding are in one collaboration..."

    which implies that the supplier elements (the ends with the arrow, according to the notation subsection of Dependency) are the roles in the collaboration and the client elements are the parts that are playing specific roles of that collaboration. The figure actually shows the inverse of that.

  • Reported: UML 2.0 — Thu, 22 Sep 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see page 498 of ptc/2006-04-01

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

Section: 12.3.18 and 12.3.35

  • Key: UML22-1000
  • Legacy Issue Number: 8939
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Add constraint to conditional and loop node that the result output pins have no outgoing edges

  • Reported: UML 2.0 — Mon, 25 Jul 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

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

Section: 15.3.14

  • Key: UML22-999
  • Legacy Issue Number: 8938
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    BNF for transition specifies that a trigger is mandatory. That's not the case, e.g. for the initial state transition.

  • Reported: UML 2.0 — Fri, 22 Jul 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

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

p. 732: Show examples of new stereotype notation

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

    Recommended Changes to UML 2.0 Profiles to Support SysML

    Source: SysML Partners (Partners@SysML.org)
    Nature: Revision
    Severity: Significant
    Summary:
    SysML extends the use of Profile notation and requires that stereotypes can reference UML metaclasses. In order to satisfy the needs of SysML, the following changes need to be made to the the UML 2.0 Superstructure Profiles chapter. "Convenience documents" in .fm and .pdf formats, which redline the proposed changes to the Profiles chapter, are provided as attachments to this issue submission. (See
    UML2-Super-Profiles-ConvenienceDoc-050525.fm and UML2-Super-Profiles-ConvenienceDoc-050525.pdf.)

    Recommended changes:
    8) p. 732: Show examples of new stereotype notation. Add the following including new Figure 463:
    "Finally, the two alternate notational forms are shown.

    • Other notational forms for showing values
      AlarmClock is valid for OS version 1.1, is POSIX-compliant and it has a starting operation called Start. The compartment form of notation is shown on the left and the in-symbol form on the right (note that not all properties of Clock are shown on the right."
  • Reported: RAS 2.2 — Thu, 2 Jun 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see pages 468 - 469 of ptc/2006-04-01

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

p. 732: Change example to be consistent with new definition of Clock

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

    Recommended Changes to UML 2.0 Profiles to Support SysML

    Source: SysML Partners (Partners@SysML.org)
    Nature: Revision
    Severity: Significant
    Summary:
    SysML extends the use of Profile notation and requires that stereotypes can reference UML metaclasses. In order to satisfy the needs of SysML, the following changes need to be made to the the UML 2.0 Superstructure Profiles chapter. "Convenience documents" in .fm and .pdf formats, which redline the proposed changes to the Profiles chapter, are provided as attachments to this issue submission. (See
    UML2-Super-Profiles-ConvenienceDoc-050525.fm and UML2-Super-Profiles-ConvenienceDoc-050525.pdf.)

    Recommended changes:
    7) p. 732: Change example to be consistent with new definition of Clock. Replace figure 462 with:

  • Reported: RAS 2.2 — Thu, 2 Jun 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see pages 466 -467 of ptc/2006-04-01

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

Section: 12.3.5

  • Key: UML22-994
  • Legacy Issue Number: 8919
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Description
    Section Associations (CompleteActivities): weight specifies the number of tokens instead of objects consumed from the source node on each traversal. It's a common property for object flow as well as for control flows.

  • Reported: UML 2.0 — Wed, 6 Jul 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

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

Page: 163

  • Key: UML22-993
  • Legacy Issue Number: 8901
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Fig. 93: The only message of the notation abstraction is that some components offer and some components require an interface. That the same as in a component diagram. Fig. 93 shows an internal view of a component. A composite structure diagram must show how the components are wired together. For examples that :BackOrder uses :Customer and NOT :Organization or vice versa. I propose to not use the notation abstraction.

  • Reported: UML 2.0 — Thu, 30 Jun 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    Introducing a minimalist resolution, to just fix the incorrectly used terminology.

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

Make instance model consistent with new definition of Clock

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

    Recommended Changes to UML 2.0 Profiles to Support SysML

    Source: SysML Partners (Partners@SysML.org)
    Nature: Revision
    Severity: Significant
    Summary:
    SysML extends the use of Profile notation and requires that stereotypes can reference UML metaclasses. In order to satisfy the needs of SysML, the following changes need to be made to the the UML 2.0 Superstructure Profiles chapter. "Convenience documents" in .fm and .pdf formats, which redline the proposed changes to the Profiles chapter, are provided as attachments to this issue submission. (See
    UML2-Super-Profiles-ConvenienceDoc-050525.fm and UML2-Super-Profiles-ConvenienceDoc-050525.pdf.)

    Recommended changes:
    4) p. 730: Make instance model consistent with new definition of Clock. Replace Figure 458 with:

  • Reported: RAS 2.2 — Thu, 2 Jun 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see page 463 of ptc/2006-04-01

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

p. 729: Extend the Clock example to show metaclass property

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

    Recommended Changes to UML 2.0 Profiles to Support SysML

    Source: SysML Partners (Partners@SysML.org)
    Nature: Revision
    Severity: Significant
    Summary:
    SysML extends the use of Profile notation and requires that stereotypes can reference UML metaclasses. In order to satisfy the needs of SysML, the following changes need to be made to the the UML 2.0 Superstructure Profiles chapter. "Convenience documents" in .fm and .pdf formats, which redline the proposed changes to the Profiles chapter, are provided as attachments to this issue submission. (See
    UML2-Super-Profiles-ConvenienceDoc-050525.fm and UML2-Super-Profiles-ConvenienceDoc-050525.pdf.)3) p. 729: Extend the Clock example to show metaclass property and the use of Boolean. Replace Figure 456 with:

  • Reported: RAS 2.2 — Thu, 2 Jun 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see pages 462 of ptc/2006-04-01

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

p. 731: Make example consistent with new definition of Clock.

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

    Recommended Changes to UML 2.0 Profiles to Support SysML

    Source: SysML Partners (Partners@SysML.org)
    Nature: Revision
    Severity: Significant
    Summary:
    SysML extends the use of Profile notation and requires that stereotypes can reference UML metaclasses. In order to satisfy the needs of SysML, the following changes need to be made to the the UML 2.0 Superstructure Profiles chapter. "Convenience documents" in .fm and .pdf formats, which redline the proposed changes to the Profiles chapter, are provided as attachments to this issue submission. (See
    UML2-Super-Profiles-ConvenienceDoc-050525.fm and UML2-Super-Profiles-ConvenienceDoc-050525.pdf.)

    Recommended changes:
    6) p. 731: Make example consistent with new definition of Clock. Replace Figure 461 with:

  • Reported: RAS 2.2 — Thu, 2 Jun 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    See issue 8849 for disposition

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

p. 731: Make this example consistent with the new definition of Clock

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

    Recommended Changes to UML 2.0 Profiles to Support SysML

    Source: SysML Partners (Partners@SysML.org)
    Nature: Revision
    Severity: Significant
    Summary:
    SysML extends the use of Profile notation and requires that stereotypes can reference UML metaclasses. In order to satisfy the needs of SysML, the following changes need to be made to the the UML 2.0 Superstructure Profiles chapter. "Convenience documents" in .fm and .pdf formats, which redline the proposed changes to the Profiles chapter, are provided as attachments to this issue submission. (See
    UML2-Super-Profiles-ConvenienceDoc-050525.fm and UML2-Super-Profiles-ConvenienceDoc-050525.pdf.)

    Recommended changes:
    5) p. 731: Make this example consistent with the new definition of Clock. Replace Figure 459 with:

  • Reported: RAS 2.2 — Thu, 2 Jun 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see pages 464 - 465 of ptc/2006-04-01

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

Section: 12.3.37 ObjectFlow

  • Key: UML22-989
  • Legacy Issue Number: 8859
  • Status: closed  
  • Source: Sapiens Deutschland GmbH ( Helmut Barthel)
  • Summary:

    On page 418, Constraints (BasicActivities), you write: "[1] Object flows may not have actions at either end." In contrast, on page 420, Notation, the description of the upper right part of figure 281 is: "Two object flow edges linking object nodes and actions(!!)." After many cycles of re-reading the Activities chapter I got convinced that the constraint is really meant as-is. So, the notation mentioned above likely means the "standalone pin notation" from page 433. If so, you should make it very clear, that this notation maps to two Pin instances (one at either action) and ONE ObjectFlow instance in-between, in the model (just like the alternative notation in the same figure shows). In addition, you should add this clarification throughout the Activities chapter. In addition, on page 433, regarding the explanation of the standalone pin notation, you should add, that it maps to ONE object flow edge in-between the two pins, in the model.

  • Reported: UML 2.0 — Tue, 7 Jun 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

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

UML Superstructure / Actions / incorrect form for subsetting

  • Key: UML22-996
  • Legacy Issue Number: 8932
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The Actions chapter uses the convention "Specialized from" in describing properties that are specialized in a metaclass, instead of the "Subsets " convention used throughout the rest of the document. The former should all be changed to follow the conventional form.

  • Reported: UML 2.0 — Mon, 18 Jul 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

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

Section: 12.3.9

  • Key: UML22-995
  • Legacy Issue Number: 8930
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Semantics section, last sentence: Recursive reference to semantics section of ActivityParameterNode.

  • Reported: UML 2.0 — Mon, 18 Jul 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

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

pp. 733-734: Add association as valid graphic path

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

    Recommended Changes to UML 2.0 Profiles to Support SysML

    Source: SysML Partners (Partners@SysML.org)
    Nature: Revision
    Severity: Significant
    Summary:
    SysML extends the use of Profile notation and requires that stereotypes can reference UML metaclasses. In order to satisfy the needs of SysML, the following changes need to be made to the the UML 2.0 Superstructure Profiles chapter. "Convenience documents" in .fm and .pdf formats, which redline the proposed changes to the Profiles chapter, are provided as attachments to this issue submission. (See
    UML2-Super-Profiles-ConvenienceDoc-050525.fm and UML2-Super-Profiles-ConvenienceDoc-050525.pdf.)

    Recommended changes:
    9) pp. 733-734: Add association as valid graphic path. Add the following row to Table 24:

    Unidirectional Association See "Profile (from Profiles)" on page 720

  • Reported: RAS 2.2 — Thu, 2 Jun 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

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

TimeExpression

  • Key: UML22-991
  • Legacy Issue Number: 8894
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    TimeExpression should hold time value, but there is no attribute for that. Maybe TimeExpression should be inherited from OpaqueExpression and hold value in "body"?

  • Reported: RAS 2.2 — Mon, 20 Jun 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see pages 472 - 478 of ptc/2006-04-01

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

OpaqueAction

  • Key: UML22-990
  • Legacy Issue Number: 8867
  • Status: closed  
  • Source: Eclipse Foundation ( Mr. Kenneth Hussey)
  • Summary:

    should specialize input and output, so opaque actions can have pins.

  • Reported: UML 2.0 — Tue, 14 Jun 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see page 471 of ptc/2006-04-01

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

abstract Action in Activity diagram

  • Key: UML22-992
  • Legacy Issue Number: 8896
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    4. The same situation is with abstract Action in Activity diagram. OpaqueAction also can't be used, because can't have Pins.
    How to draw "human friendly" action (activity)? The only way is to use CallBehaviorAction?

  • Reported: RAS 2.2 — Mon, 20 Jun 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    See issue 8867 for disposition

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

p. 728: New presentation options. Replace the following paragraph

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

    Recommended Changes to UML 2.0 Profiles to Support SysML

    Source: SysML Partners (Partners@SysML.org)
    Nature: Revision
    Severity: Significant
    Summary:
    SysML extends the use of Profile notation and requires that stereotypes can reference UML metaclasses. In order to satisfy the needs of SysML, the following changes need to be made to the the UML 2.0 Superstructure Profiles chapter. "Convenience documents" in .fm and .pdf formats, which redline the proposed changes to the Profiles chapter, are provided as attachments to this issue submission. (See
    UML2-Super-Profiles-ConvenienceDoc-050525.fm and UML2-Super-Profiles-ConvenienceDoc-050525.pdf.)

    2) p. 728: New presentation options. Replace the following paragraph:
    "The values of a stereotype that has been applied to a model element can be shown as part of a comment symbol tied to the model element. The values from a specific stereotype are optionally preceded with the name of the applied stereotype within a pair of guillemets, which is useful if values of more than one applied stereotype should be shown."
    with the following text:
    "The values of a stereotype that has been applied to a model element can be shown in one of three ways:
    ·As part of a comment symbol tied to the symbol representing the model element
    ·In compartments of a graphic node representing the model element.
    ·Above the name string within a graphic node or before the name string otherwise
    In the case where a compartment or comment symbol is used, the user may elect to show the stereotype name in guillemets before the name string in addition to in the compartment or comment.
    They are displayed as name/value pairs, thus:
    <namestring>'='<valuestring>
    If a stereotype property is multi-valued then the valuestring is displayed as a comma-separated list:
    <valuestring>::=<value>

    {','<value>}

    Certain values have special display rules:
    ·As an alternative to a name/value pair, when displaying the values of boolean properties diagrams may use the convention that if the namestring is displayed then the value is True, otherwise the value is False;
    ·If the value is the name of a NamedElement then optionally its qualifiedName can be used.
    If compartments are used to display stereotype values then an additional compartment is required for each applied stereotype whose values are to be displayed. Each such compartment is headed by the name of the applied stereotype in guillemets. Any graphic node may have these compartments.
    Within a comment symbol, or if displayed before/above the symbols's namestring, the values from a specific stereotype are optionally preceded with the name of the applied stereotype within a pair of guillemets, which is useful if values of more than one applied stereotype should be shown.
    When displayed in compartments or comment symbol at most one name/value pair can appear on a single line. When displayed above/before a namestring the name/value pairs are separated by semicolons and all pairs for a given stereotype are enclosed in braces."

  • Reported: RAS 2.2 — Thu, 2 Jun 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see pages 460 - 461 of ptc/2006-04-01

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

p. 721: Allow stereotypes to have properties that are typed by metaclasses

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

    SysML extends the use of Profile notation and requires that stereotypes can reference UML metaclasses. In order to satisfy the needs of SysML, the following changes need to be made to the the UML 2.0 Superstructure Profiles chapter. "Convenience documents" in .fm and .pdf formats, which redline the proposed changes to the Profiles chapter, are provided as attachments to this issue submission. (See
    UML2-Super-Profiles-ConvenienceDoc-050525.fm and UML2-Super-Profiles-ConvenienceDoc-050525.pdf.)
    . Change paragraph 4 to:
    "As part of a profile, it is not possible to have an association between two stereotypes or from a metaclass in the reference metamodel to a stereotype, although a unidirectional association from a stereotype to a metaclass, or equivalently typing a stereotype property by a metaclass, is allowed. The effect of new (meta) associations between stereotypes can be achieved in limited ways either by:"

  • Reported: RAS 2.2 — Thu, 2 Jun 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    See issue 7756 for disposition

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

Can't specify mutator semantics for derived properties

  • Key: UML22-968
  • Legacy Issue Number: 8769
  • Status: closed  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    It is currently not possible to specify the effect of setting derived properties that are not read-only. As a result, derived properties are under-specified in the model because the semantics of updating them cannot be modeled or stated formally.

  • Reported: RAS 2.2 — Fri, 6 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

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

Section: 12.3.37

  • Key: UML22-967
  • Legacy Issue Number: 8766
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    It's a common modeling scenario that an object flow with an outpin pin at the source must target an action directly (without a pin). For example a decision node with an incoming object flow - the object is necessary for the guard condition -, but one or more of the target actions don't need that object. Due to the constraint that object flows don't have actions at either end I must model an input pin. For example in case of a CallOperationAction an operation with an additional parameter must be defined even if I don't use it. It's just for modeling purposes. I've assumed before reading the constraint in the specification that an object flow can target an action directly. In that case it's semantic is the same as for the control flow. That works perfect for me. I would propose to weaken the constraint for object flows that actions as targets are allowed. The object token enables the action and gets lost. Any other solution with the same semantic is also acceptable.

  • Reported: RAS 2.2 — Thu, 5 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    closed no change

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

MessageEnd

  • Key: UML22-976
  • Legacy Issue Number: 8784
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    MessageEnd is MessageOccurrenceSpecification that redefines "event" as MessageEvent.
    DestructionEvent and CreationEvent are not subclasses of MessageEvent, so can't be on message end, so how to map "create message" and "destroy message"?

  • Reported: RAS 2.2 — Wed, 18 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

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

ExecutableNode should be abstract in Figure 195. It is in Figure 197.

  • Key: UML22-975
  • Legacy Issue Number: 8782
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    ExecutableNode should be abstract in Figure 195. It is in Figure 197.

  • Reported: UML 2.0 — Sun, 15 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    See issue 8239 for disposition

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

Section: 12 and 13

  • Key: UML22-979
  • Legacy Issue Number: 8826
  • Status: closed  
  • Source: Ostfold University College ( Dr. Oystein Haugen)
  • Summary:

    Figure numbers 306,307,308,309 appear in both the Activities chapter (12) and the Common Behavior chapter (13)

  • Reported: UML 2.0 — Thu, 26 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

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

Incorrect Communication Domain Model

  • Key: UML22-978
  • Legacy Issue Number: 8825
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. James J. Odell)
  • Summary:

    Fig. 308 does not contain the correct domain model. The current model that
    appears in Fig. 308 is a duplicate of Fig. 307.

  • Reported: RAS 2.2 — Thu, 26 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    See issue 8292 for disposition

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

Obsolete term EventOccurrence still used in multiple places

  • Key: UML22-977
  • Legacy Issue Number: 8824
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. James J. Odell)
  • Summary:

    1) 14.3.25 OccurrenceSpecification, the change in class name was from EventOccurrence to OccurrenceSpecification. This change needs to be noted in this document. Also, the reason why the change was made.
    2) EventOccurrence is still being use in the toBefore and toAfter association descriptions of OccurrenceSpecification.
    3) EventOccurrence is still be referenced in other areas:
    a) in the last word of the Example text on page 476,
    b) In the Notation text on Page 489,
    c) In the fifth paragraph of the overview on Page 497
    d) Multiple times on Page 509 and 510
    e) First paragraph on Page 528
    f) Multiple times on Page 531
    g) Multiple times on Fig. 347

  • Reported: RAS 2.2 — Thu, 26 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see pages 453 - 457 of ptc/2006-04-01

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

Notation of Attributes and Associations subsections

  • Key: UML22-972
  • Legacy Issue Number: 8774
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Notation of Attributes and Associations subsections in the whole specification should be consistently follow the rules: Every entry must include * attribute/association end name * its type * its multiplicity: you should NOT omit this even if it maps to the default value of *. Also, both upper and lower multiplicities should be provided; i.e., NOT "[*]" but "[0..*]") * ALL modifiers such as subsets and redefines. When referencing other association ends, use the following convention: "<metaclass-name>::<association-end-name> (do NOT use the "." notation for this) * if something is derived, the explanation should be given how it is derived and an OCL formula might have to be provided.

  • Reported: RAS 2.2 — Tue, 10 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Discussion: Most of these issues have been resolved through numerous editorial changes that were intended to ensure consistency. The exceptions are:
    „h the use of * instead of 0..* – simply not worth the effort given that the two are equivalent. It will take a lot of effort to do this with no real value; chances are that this will NEVER get done. There is no point in keeping the issue open.
    „h The derivation specification already has another open issue.
    Revised Text: N/A Disposition: Closed, no change

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

Page: 330

  • Key: UML22-971
  • Legacy Issue Number: 8773
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Typo in fig. 192: Association from BehavioralFeature to Parameterset: should be ownedMember instead of ownedmember (uppercase).

  • Reported: UML 2.0 — Tue, 10 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Discussion: This issue refers to an older version of the specification. It is fixed in the meantime. Disposition: Closed, no change

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

Section: 11.3.48

  • Key: UML22-970
  • Legacy Issue Number: 8772
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Semantic sections mentions the order of structural features of the specified classifier. The list of structural features is ordered for a class, but unordered for a classifier.

  • Reported: UML 2.0 — Mon, 9 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

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

Section: Actions

  • Key: UML22-969
  • Legacy Issue Number: 8770
  • Status: closed  
  • Source: Object Management Group ( Stephen Mellor)
  • Summary:

    The third sentence of the Actions chapter implies that most of the actions are specialization of the one that supports implementation-dependent semantics. Should be reworded.

  • Reported: UML 2.0 — Fri, 6 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

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

Actions should be able to overlap partitions, to support multiple participa

  • Key: UML22-974
  • Legacy Issue Number: 8781
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Actions should be able to overlap partitions, to support multiple participants

  • Reported: UML 2.0 — Sun, 15 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

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

Section: 8.3.1 Page: 156 ff

  • Key: UML22-973
  • Legacy Issue Number: 8778
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Fig. 86, 87, and 89 have no dividing line between name compartment and internal view compartment

  • Reported: UML 2.0 — Thu, 12 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Discussion: This dividing line is optional. Revised Text: N/A Disposition: Closed, no change

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

OpaqueAction

  • Key: UML22-966
  • Legacy Issue Number: 8759
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    In chapter 11.3.26 OpaqueAction is described as subclass of Pin. It
    > should be subclass of Action.

    That's a bug. Please raise an issue.

    > Can OpaqueAction be used as default Action type in Activity diagrams
    > and be as replacement of old-style user defined ActionStates in UML 1.4?

    It sounds like you are asking for a new feature. I don't see that the RTF will accept this default. You can always do this woth a profile.

  • Reported: RAS 2.2 — Tue, 3 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

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

Page: 591

  • Key: UML22-965
  • Legacy Issue Number: 8753
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The semantics section describes that the transition from an initial pseudostate may have an action. There should be a constraint in the constraints section that actions are allowed, but no triggers and guards. Instead of action it should be named behavior.

  • Reported: UML 2.0 — Sun, 1 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see page 442 of ptc/2006-04-01

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

Clarify caption of Figure 56

  • Key: UML22-961
  • Legacy Issue Number: 8746
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Clarify caption of Figure 56. The wording of caption of Figure 56 gives the impression that it is a general notation to provided/required interfaces, especially because it is in the Presentation Option section. Discussion during FTF was that this is only an example, rather than a general notation.

  • Reported: UML 2.0 — Sun, 1 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

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

Section: Interactions

  • Key: UML22-960
  • Legacy Issue Number: 8745
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Messages to self. Are curved arrows in interactions (sending to self) still supported in UML 2? See Figure 3-56 in UML 1.5 (doc.omg/org/formal/03-03-01). If not, how are messages to self shown?

  • Reported: UML 2.0 — Sun, 1 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

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

Clarify first constraint on InputPin and OutputPin, move "only" to before "

  • Key: UML22-953
  • Legacy Issue Number: 8734
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Clarify first constraint on InputPin and OutputPin, move "only" to before "when".

  • Reported: UML 2.0 — Sun, 1 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

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

LoopNode should move rather than copy values to/from loop variables

  • Key: UML22-952
  • Legacy Issue Number: 8733
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    LoopNode should move rather than copy values to/from loop variables. Otherwise, tokens will be dangling tokens. Same for ConditionalNode bodyOutput, etc.

  • Reported: UML 2.0 — Sun, 1 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

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

In Figure 210, put merge before Use Part to merge the incoming flows

  • Key: UML22-951
  • Legacy Issue Number: 8732
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    In Figure 210, put merge before Use Part to merge the incoming flows

  • Reported: UML 2.0 — Sun, 1 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see page 431 of ptc/2006-04-01

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

Exceptions thrown across synchronous invocations

  • Key: UML22-950
  • Legacy Issue Number: 8730
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Exceptions thrown across synchronous invocations. Clarify that exceptions are thrown across synchronous invocations, not asynchronous ones. Or introduce an attribute to tell whether it is thrown across call boundaries.

  • Reported: UML 2.0 — Sun, 1 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

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

Multiple exception handlers

  • Key: UML22-949
  • Legacy Issue Number: 8729
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Multiple exception handlers. Clarify that one exception handler is executed if multiple match, and it is undefined which

  • Reported: UML 2.0 — Sun, 1 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

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

Actions, CallBehaviorAction, third sentence,

  • Key: UML22-955
  • Legacy Issue Number: 8736
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Actions, CallBehaviorAction, third sentence, should be limited to synchronous calls

  • Reported: UML 2.0 — Sun, 1 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

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

The Syle Guidelines for Stereotype

  • Key: UML22-954
  • Legacy Issue Number: 8735
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The Syle Guidelines for Stereotype says "The values of an applied stereotype are normally not shown." This is application-dependent. Sentence should be removed

  • Reported: UML 2.0 — Sun, 1 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

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

CollaborationUse: Constraint 1,

  • Key: UML22-959
  • Legacy Issue Number: 8744
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    CollaborationUse: Constraint 1, allows parameters from different operations to be coordinated. Is that intended?

  • Reported: UML 2.0 — Sun, 1 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Discussion: This issue appears to refer to an earlier version of the specification. It is impossible to identify in the current version what this issue concerns. Disposition: Closed, no change

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

ConditionalNode and LoopNode test and bodies should be ExecutableNodes

  • Key: UML22-958
  • Legacy Issue Number: 8740
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    ConditionalNode and LoopNode test and bodies should be ExecutableNodes

  • Reported: UML 2.0 — Sun, 1 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

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

ExpansionRegion

  • Key: UML22-957
  • Legacy Issue Number: 8739
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    ExpansionRegion, clarify that tokens in input pins and expansion nodes are destroyed when the expansion node completes

  • Reported: UML 2.0 — Sun, 1 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

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

ControlFlow

  • Key: UML22-956
  • Legacy Issue Number: 8737
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    ControlFlow should say that if it targets an action, or control pin of action, then the action requires a control token to start executing

  • Reported: UML 2.0 — Sun, 1 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

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

Last element in transition BNF

  • Key: UML22-964
  • Legacy Issue Number: 8752
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Last element in transition BNF should be <behavior-expression> instead of <activity-expression>. The term is used on the next side.

  • Reported: UML 2.0 — Sun, 1 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    Update as suggested.

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

Notation for connector end multiplicities.

  • Key: UML22-962
  • Legacy Issue Number: 8747
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Notation for connector end multiplicities. Notation of ConnectorEnd, first paragraph says the multiplicities shown are the association multiplicities. What about the connector end multiplicities?

  • Reported: UML 2.0 — Sun, 1 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Discussion: This issue has been fixed in the current version of the specification. Disposition: Closed, no change

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

ParameterSet, first line: "inputs *or* outputs".

  • Key: UML22-963
  • Legacy Issue Number: 8749
  • Status: closed  
  • Source: International Business Machines ( Dr. Tracy Gardner)
  • Summary:

    ParameterSet, first line: "inputs or outputs".

  • Reported: UML 2.0 — Sun, 1 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

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

In Activities, Figure 176, Action should be abstract

  • Key: UML22-942
  • Legacy Issue Number: 8718
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    In Activities, Figure 176, Action should be abstract

  • Reported: UML 2.0 — Sun, 1 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

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

Profile Semantics, pag 723

  • Key: UML22-941
  • Legacy Issue Number: 8706
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    "A reference metamodel typically consists of metaclasses that are either
    imported or locally owned. All metaclasses that
    are extended by a profile have to be members of the same reference
    metamodel. A tool can make use of the information
    about which metaclasses are extended in different ways, for example to
    filter or hide elements when a profile is applied, ..."

    The specification must be explicit about the mechanism used to hide/filter
    reference metamodel elements. The SysML Partners are trying to do exactly
    this with SysML but it's not clear from the above paragraph or any other
    part of the Profiles section how to do it.

  • Reported: RAS 2.2 — Thu, 28 Apr 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

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

Section: 12

  • Key: UML22-935
  • Legacy Issue Number: 8680
  • Status: closed  
  • Source: FUNDP ( Pierre Yves Schobbens)
  • Summary:

    "Any object nodes declared as outputs are passed out of the containing activity." Only tokens can be passed, not nodes. I suggest: "The last token from each output Activity Parameter Node is offered on the corresponding output of the calling action."

  • Reported: UML 1.4.2 — Tue, 5 Apr 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

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

token

  • Key: UML22-934
  • Legacy Issue Number: 8679
  • Status: closed  
  • Source: FUNDP ( Pierre Yves Schobbens)
  • Summary:

    "All tokens offered on the incoming edges are accepted." 1- The edges of of the terminated Activity or of the Activity Final Node? 2- In general, it is not possible to accept all tokens offered. For instance, a same token in an ObjectNode could cause two token offers throughtwo forks. Yet, only one of these offered tokens can be accepted, causing the other to be no longer offered. I suggest to delete this sentence.

  • Reported: UML 1.4.2 — Tue, 5 Apr 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

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

String is primitive but has structure.

  • Key: UML22-944
  • Legacy Issue Number: 8720
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    String is primitive but has structure. Section 17.4 (PrimitiveTypes) has String, even though the definition of primitive type in Section 7.3.43 excludes any structure: "A primitive type defines a predefined data type, without any relevant substructure (i.e. it has no parts). A primitive datatype may have an algebra and operations defined outside of UML, for example, mathematically."

  • Reported: UML 2.0 — Sun, 1 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

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

``conditional node or conditional node'' delete one.

  • Key: UML22-937
  • Legacy Issue Number: 8683
  • Status: closed  
  • Source: FUNDP ( Pierre Yves Schobbens)
  • Summary:

    ``conditional node or conditional node'' delete one.

  • Reported: UML 1.4.2 — Tue, 5 Apr 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

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

add the rule of ``natural termination''

  • Key: UML22-936
  • Legacy Issue Number: 8681
  • Status: closed  
  • Source: FUNDP ( Pierre Yves Schobbens)
  • Summary:

    I suggest to add the rule of ``natural termination'': An activity terminates when it has a token in each of its output Activity Parameter Nodes. This removes the need for Activity Final Nodes in most cases, and makes UML less error-prone, since it is an error to terminate without a token in each output Activity Parameter Node. It also makes the languages more consistent, since this rule is used for loops.

  • Reported: UML 1.4.2 — Tue, 5 Apr 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

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

Solid triange notation for Association

  • Key: UML22-948
  • Legacy Issue Number: 8728
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Solid triange notation for Association. Association, Examples, shows a solid triangle notation that is not mentioned in the notation section. It says it indicates the order of reading, but association generally don't have an order or reading, the end names express the order of reading. I thought it showed the order of the association ends (Association.memberEnd is ordered), because there's no other notation for that.

  • Reported: UML 2.0 — Sun, 1 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

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

The create stereotype on Usage dependency

  • Key: UML22-947
  • Legacy Issue Number: 8727
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The create stereotype on Usage dependency. The create stereotype on Usage dependency is defined in standard stereotypes (Table 25) and in retired stereotypes (Table 28). It is used in Figures 103 and 121.

  • Reported: UML 2.0 — Sun, 1 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Discussion: This issue was resolved in an earlier revision. The “create” stereotype is now defined in the table in appendix C section C.1. Disposition: Closed, no change

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

Section: 12.2

  • Key: UML22-939
  • Legacy Issue Number: 8690
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Sebastien Gerard)
  • Summary:

    In figure 195, p332, StructuredActivityNode and Action inherit from ExecutableNode. In figure 196, p333, StructuredActivityNode inherits from Action. => StructuredActivityNode inherits two times of Action. A priori, you could delte the inheritance link between StructuredActivityNode and ExeutableNode in figure 195

  • Reported: UML 2.0 — Thu, 7 Apr 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

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

Delete sentence

  • Key: UML22-938
  • Legacy Issue Number: 8685
  • Status: closed  
  • Source: FUNDP ( Pierre Yves Schobbens)
  • Summary:

    " One frequent case is a total ordering of clauses, in which case the result is determinate." The clauses themselves can be nondeterministic, making this sentence false (although the idea is clear). Delete.

  • Reported: UML 1.4.2 — Tue, 5 Apr 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

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

Element to Constraint navigation

  • Key: UML22-946
  • Legacy Issue Number: 8726
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Element to Constraint navigation. The "constrainedElement" association between Constraint and Element is unidirectional from Constraint to Element. That means implementations are not required to provide efficient navigation from an element to the constraints on it. Can't see how an API could do without this.

  • Reported: UML 2.0 — Sun, 1 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    This is a duplicate of issue 8020 Revised Text: N/A Disposition: Duplicate

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

Disjointness should be independent of generalization

  • Key: UML22-945
  • Legacy Issue Number: 8723
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Disjointness is applicable to classes that are not specializations of the same class. It should be independent of generalization

  • Reported: UML 2.0 — Sun, 1 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Same as issue 8014 Revised Text: N/A Disposition: Duplicate

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

Semantics for instances applies to InstanceSpecification?

  • Key: UML22-943
  • Legacy Issue Number: 8719
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Semantics for instances applies to InstanceSpecification? Clarify whether the semantics for instances specified in other chapters applies to InstanceSpecification. For example, will deleting an InstanceSpecification delete other instances it owns by association composition?

  • Reported: UML 2.0 — Sun, 1 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

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

policy to describe the Associations sub section of a meta class description

  • Key: UML22-940
  • Legacy Issue Number: 8696
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Sebastien Gerard)
  • Summary:

    what is the official policy to describe the Associations sub section of a meta class description (using EBNF style):

    /?<end-name> : <associated-class-name> : <cardinality> (= <DefaultValue>)? <FeaturesList>? <tab> <Description>

    where:

    <end-name> ::= String

    <associated-class-name> ::= String

    <cardinality> ::= [<n>, <m>]

    <DefaultValue> ::= String

    <FeaturesList> ::=

    {<Features>}

    <Features> ::= <FeatureKind>} | {<FeatureKind>, <Features>

    <FeatureKind> ::= subsets <property-name> | redefined <end-name> | union | ordered | bag | sequence | readOnly | unrestricted

    <property-name> ::= String

    <n> ::= Integer

    <m> ::= Integer | * and m >= n

    <tab> is a tabulation

    ps: ? means it is optional part.

  • Reported: RAS 2.2 — Tue, 12 Apr 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

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

UML 2 -- Need explanations of XMI structure and usage

  • Key: UML22-933
  • Legacy Issue Number: 8678
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Appendix G is intended to contain the XMI for UML. However, there is no explanation of the meaning of its various parts, or its structure, or how it is to be used. This information should be included in the introduction to the XMI appendix in both the Infrastructure (Appendix A) and the Superstructure (Appendix G).

  • Reported: UML 1.4.2 — Tue, 5 Apr 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

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

token movement

  • Key: UML22-932
  • Legacy Issue Number: 8677
  • Status: closed  
  • Source: FUNDP ( Pierre Yves Schobbens)
  • Summary:

    The verbs ``flow'', ``pass'', ``traverse'' seem used interchangeably to describe token movement. I suggest to reserve ``flow'' for a complex path (So e.g. p.309 should be: ``Activity edges are directed connections, that is, they have a source and a target, along which tokens may

    {\bf pass}

    ). , ``pass'' for an elementary move, and to replace ``traverse'' by ``pass''. (p.303, 304, 309, 310, etc.)

  • Reported: UML 1.4.2 — Tue, 5 Apr 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

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

output tokens (02)

  • Key: UML22-931
  • Legacy Issue Number: 8676
  • Status: closed  
  • Source: FUNDP ( Pierre Yves Schobbens)
  • Summary:

    In, e.g.: [4] The output tokens are now available Replace ``available'' by ``offered''. Also p.310, p.330, p.342, etc.

  • Reported: UML 1.4.2 — Tue, 5 Apr 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

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

Section: 12

  • Key: UML22-927
  • Legacy Issue Number: 8670
  • Status: closed  
  • Source: FUNDP ( Pierre Yves Schobbens)
  • Summary:

    there should be a consistent convention as whether unused Paragraphs must be omitted or filled with ``None''. We suggest the first, and thus to delete the Paragraphs pp.110, 163, 216, 217, 220-262, 280, 285, 298, 301, 304, 311-320, 323, 331, etc.

  • Reported: UML 1.4.2 — Tue, 5 Apr 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    See issue 8155 for disposition

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

Section: Appendix F

  • Key: UML22-926
  • Legacy Issue Number: 8619
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    The following classifiers show no inheritance hierarchy because the link (inheritance arrow) is missing: Classifier (from Templates), Classifier (from PowerTypes), Interface (from Communications), BehavioredClassifier (from Interfaces), Behavior (from CompleteActivities), Activity (from BasicActivities), Activity (from StructuredActivities), and Activity (from CompleteActivity). In addition, Classifier (from UseCases) and Classifier (from Dependencies) are just kind of sitting there without showing any inheritance. It is strange to see classifiers on a diagram with no relationships expressed.

  • Reported: UML 2.0 — Mon, 21 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

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

Section: E.1

  • Key: UML22-925
  • Legacy Issue Number: 8617
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Typos - Remove the extra space beginning the paragraphs of #4, 6, 9, 10, 11, 12, and 14. There is also an extra space in #10 in "sequence /communication."

  • Reported: UML 2.0 — Mon, 21 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see page 412 of ptc/2006-04-01

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

text p.297

  • Key: UML22-930
  • Legacy Issue Number: 8674
  • Status: closed  
  • Source: FUNDP ( Pierre Yves Schobbens)
  • Summary:

    The text p.297: [1] An action execution is created when all its object flow and control flow prerequisites have been satisfied (implicit join). Exceptions to this are listed below. The flow prerequisite is satisfied when all of the input pins are offered tokens and accept them all at once, precluding them from being consumed by any other actions. contains, I believe, the problems: 1. Flows need not be connected by input pins, so ``inputs'' must replace ``input pins''. 2. The current text implies that all offered tokens are consumed when an action starts, which is not intended, we believe (specially if two offers are incompatible). 3. ``precluding them from being consumed by any other actions'' does not belong here. We suggest: To start, the action must have at least one token per input. When starting, it accepts simultaneously exactly one token per input, then creates an action execution.

  • Reported: UML 1.4.2 — Tue, 5 Apr 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

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

Section 12 (03)

  • Key: UML22-929
  • Legacy Issue Number: 8672
  • Status: closed  
  • Source: FUNDP ( Pierre Yves Schobbens)
  • Summary:

    ``Result pin'', ``Output pin'' or even ``Result output pin'' seem used interchangeably throughout the text. Replace by ``Output pin''.

  • Reported: UML 1.4.2 — Tue, 5 Apr 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

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

Section 12 (02)

  • Key: UML22-928
  • Legacy Issue Number: 8671
  • Status: closed  
  • Source: FUNDP ( Pierre Yves Schobbens)
  • Summary:

    A section ``Use'' containing methodological indications about the use of the construct should be added. Currently, such remarks are randomly spread into ``Description'', ``Semantics'', etc.

  • Reported: UML 1.4.2 — Tue, 5 Apr 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Discussion: UML is methodology independent; there should not be any methodological advice in the spec at all. Revised Text: N/A Disposition: Closed, no change

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

Section: Appendix C Table 27

  • Key: UML22-920
  • Legacy Issue Number: 8610
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Typo - Description column for <<systemModel>> Capitalize SystemModel when using the stereotype name. Is the description for <<metamodel>> worded correctly?

  • Reported: UML 2.0 — Fri, 18 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    agreed - fix

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

Section: Appendix C Table 26

  • Key: UML22-919
  • Legacy Issue Number: 8609
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Typos - Column Description for <<realization>> Change spelling to <<implementationClass>> to agree with the spelling in <<type>>. It's unfortunate that the column Name breaks the stereotype label so that one can't tell if the stereotype lable is one or two words. - Description for <<specification>> change to "...such as attributes and methods which are useful..." Place column headings on all pages.

  • Reported: UML 2.0 — Fri, 18 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

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

Section: D.1

  • Key: UML22-922
  • Legacy Issue Number: 8613
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    EJBService has incorrect stereotype name shown inside guillemets. In description for EJBBusiness, change "level methods" to "level method."

  • Reported: UML 2.0 — Mon, 21 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    agreed - fix

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

Section: 15.3.8

  • Key: UML22-921
  • Legacy Issue Number: 8611
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Constraints 9 and 10 exclude composite states from using entry or exit points. Entry/exit points are allowed on composite states as mentioned on page 592 (see Issue 6075).

  • Reported: UML 2.0 — Sat, 19 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    Remove constraints [9] and [10] as entry/exit point are essentially allowed on any region.

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

Section: D.3

  • Key: UML22-924
  • Legacy Issue Number: 8615
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Correct spelling of "oferred" to "offered" in Description of NETProperty. The Description of NETAssembly is an incomplete sentence that doesn't make a lot of sense. Rewrite

  • Reported: UML 2.0 — Mon, 21 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    agreed- fix

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

Section: D.2

  • Key: UML22-923
  • Legacy Issue Number: 8614
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Correct spelling of "oferred" in Description of COMInterface. Complete cells (Parent, Tage, and Constraints) for COMTLB

  • Reported: UML 2.0 — Mon, 21 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    agreed - fix

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

Section: 18

  • Key: UML22-915
  • Legacy Issue Number: 8605
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    General comments - The format of the Generalizations statement is not the same as previous chapters. For sub-sections that are empty either delete them or change the wording to "None."

  • Reported: UML 2.0 — Fri, 18 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    See issue N/A for disposition

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

Section: 18.4

  • Key: UML22-914
  • Legacy Issue Number: 8604
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Typos - Place a "." in the Reference cell for row Metaclass of table 23 and ProfileApplication of table 24

  • Reported: UML 2.0 — Fri, 18 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

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

Section: 18.3.8

  • Key: UML22-913
  • Legacy Issue Number: 8603
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Add OCL notation or a note that OCL notation is not available to Constraint [2]. Typo - Change "stereotypes is shown" to "stereotypes are shown" in 3rd line of 2nd para of Notation. - Change 3rd sent of 1st para below bullets under Icon presentation to "Some tools may use different images for the icon replacing the box." In fig. 447 lower case stereotypes "clock" and "creator, clock" to agree with naming convention and figs. 461 & 462. In para immediately following fig. 457, I believe the statement should be: "Note that the extensionEnd must be composite, and that the derived "isRequired" attribute in this case is false. Fig. 458 needs the derived slash infront of the isRequired attribute for :Extension. Typos - Lower case the stereostype name "clock" in sentence immediately fololowing fig. 458, immediately preceding fig. 460 and sentences preceding and following fig. 462. Lower case the stereotype name "creator" in the sentence following fig. 461.

  • Reported: UML 2.0 — Fri, 18 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

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

Section: Appendix C Table 25

  • Key: UML22-918
  • Legacy Issue Number: 8608
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Suggest that the column headings are found on each page of the table. Typos - In the description of <<focus>> capitalize the first "Auxiliary." - In the description of <<implementationClass>> capitalize the word "Class" when used following "Implementation" as indicated by the statement "The actual name of the stereotype is the same as the stereotype label except that the first letter of each is capitalized." (Assuming you meant the first letter of each word of each stereotype label.) - Ditto with "Model Library." - Ditto with "Type." - In the description of <<modelLibrary>> correct spelling of "inteded" to "intended."

  • Reported: UML 2.0 — Fri, 18 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see page 405 of ptc/2006-04-01

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

Section: Appendix B (02)

  • Key: UML22-917
  • Legacy Issue Number: 8607
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Table number does not fit with other tables in this Supersturcture and Appendixes. (Appendix C starts with Table 25.)

  • Reported: UML 2.0 — Fri, 18 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

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

Section: Appendix B

  • Key: UML22-916
  • Legacy Issue Number: 8606
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Typos - 2nd sent. of last para pg 745, rewrite as "...to indacate that it is a constructor..." - 3) under Notation Placement, delete the word "to." Check capitalization of keyword "buildcomponent" because pgs 771 and 777 spell it "buildComponent."

  • Reported: UML 2.0 — Fri, 18 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

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

Section: 18.3.7

  • Key: UML22-912
  • Legacy Issue Number: 8602
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Typo - under Associations change "is" to "are."

  • Reported: UML 2.0 — Fri, 18 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

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

Section: 18.3.3

  • Key: UML22-911
  • Legacy Issue Number: 8600
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Typo - 3rd sent, 2nd para under Description, change "changed" to "change." Association type:Stereotype[1] does not show the redefines statement in fig. 446. Additional Operations [1] "which was 1" statement does not agree with the last statement under Description. Fig. 446 shows a directional arrow from ExtensionEnd to Stereotype. This disagrees with first sentence of paragraph 2 of Description.

  • Reported: UML 2.0 — Fri, 18 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    There is no disagreement with first sentence of paragraph 2 of Description.

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

Section: 18.3.2

  • Key: UML22-910
  • Legacy Issue Number: 8599
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    The derived attribute isRequired default multiplicity is not supported by fig. 446. Please verify all mutliplicities between fig 446 and text for this concept agree. The association ownedEnd:ExtensionEnd[1] does not show that it redefines ownedEnd in the fig.446. Statement under attributes implies that the lower and upper bound must = 1 but Additional Operations [3] does not suppport this. Fig. 448 notation does not agree with text. If MOF notation is different, then clarify.

  • Reported: UML 2.0 — Fri, 18 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    See issue 8453 for disposition

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

Section: 18.2

  • Key: UML22-909
  • Legacy Issue Number: 8598
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Typo - remove the extra slash below line between Class and Extension in fig. 446

  • Reported: UML 2.0 — Fri, 18 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

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

Section: 18.3.2

  • Key: UML22-908
  • Legacy Issue Number: 8596
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    The definition of the attribute indicated that multiplicity may be [0..1], yet this is not supported by fig. 446 no by the association ownedEnd:ExtensionEnd[1]. Further, fig 446 does not indicate that the association ownedEnd:ExtensionEnd[1] redefines Association::ownedEnd. Additional Operations [3] says that a lower bound of 1 makes isRequired true, but the statement discussing attributes implies that the lower bound = upper bound. Shouldn't the Additional Operation [3] also indicate this? Notation in fig. 448 does not agree with the text description of the proper notation unless the notation for a MOF model is different than for UML in which case the text should explain that fig. 448 is not a UML notated diagram.

  • Reported: UML 2.0 — Thu, 17 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

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

Section: 17.5.6

  • Key: UML22-893
  • Legacy Issue Number: 8517
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Delete sub-section Attributes or change wording to "None." Change definition of association parameter:TemplateParameter to "The complete set of ordered formal template parameters for this template signature." This is indicated by fig. 427. I believe Constraint [2] should say "parameters are the owned parameter." Change wording of 2nd sent. of 2nd para of Semantics to "Either the parameter that owns the parametered element, or the element that is owned, directly or indirectly, but the template subclasses of TemplateSignature can add additional rules constraining what a parameter can reference in the context of a particular kind of template." I see no subclasses for TemplateSignature in the diagrams--just composite parts. The paragraph under ClassifierTemplates needs enhancement. What figure is being referenced? If it is fig. 429, that diagram does not support the text paragraph.

  • Reported: UML 2.0 — Tue, 8 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see pages 379 - 380 of ptc/2006-04-01

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

Section: 17.5.5

  • Key: UML22-892
  • Legacy Issue Number: 8516
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Delelte sub-section Attributes or change wording to "None." Change association name from "binding":Tto "templateBinding" to agree with fig. 428 or change fig. 428 association name from "templateBinding" to "binding."

  • Reported: UML 2.0 — Tue, 8 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

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

Section: 17.5.4

  • Key: UML22-891
  • Legacy Issue Number: 8515
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Under sub-section Notation, the last sentence says to see "ParameterableElement (from Templates)" on page 679 (and its subclasses)." What subclasses? I find none listed or diagrammmed in any figure. Delete sub-section Attributes or change wording to "None." Typo - Delete the second word ("the") of the second para of Semantics.

  • Reported: UML 2.0 — Tue, 8 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

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

Section: 17.5.7

  • Key: UML22-895
  • Legacy Issue Number: 8527
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    The classifier for the association parameter:ParameterableElement[0..1] does not agree with fig. 429. The classifier is titled ClassifierTemplateParameter in the figure. In addition, the figure does not support that this association redefines ParameterableElement::parameter Fig. 413 shows an additional association: representation:InformationItem[*]. Please add this to the sub-section Typos - 2nd line, 1st para under Section, rewrite as "parameterable element so that a classifier can be exposed as a formal template paramenter, and provided as ...." - 1st line, under sub-section Description, put a comma after Kernal::Classifier. - 3rd line, 3rd para under sub-section Semantics insert the word "of" between "specialization" and "this anonymous." - Last sent., para 2 of Collaboration under sub-section Semantics, change the word "used" to something "identified" or "defined" or "decided." "We have used that..." is not very understandable. - Last para. of Collaboration under sub-section Semantics: change "produce" to "producer" and "NrokeredSale" to "BrokeredSale." Delete "And anyway," and change "Parameters, by the very nature..." to "Parameters, by their very nature..."

  • Reported: UML 2.0 — Wed, 9 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see pages 382 - 383 of ptc/2006-04-01

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

Section: 17.1

  • Key: UML22-894
  • Legacy Issue Number: 8518
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    In fig. 412 the PrimitiveTypes package is sitting alone with no dependencies or navigation lines yet it is on the same level as Kernal, BasicActivities, BasicInteractions, and InternalStructures. If all of the other packages don't import elements from PrimitiveTypes, I would suggest offsetting the PrimitiveTypes package or putting it in a separate figure. Question - Why not develop PrimitiveTypes as an enumeration with Boolean, Integer, String, UnlimitedNatural, and UserDefinedKind or UserDefinedList as the elements of the enumeration?

  • Reported: UML 2.0 — Tue, 8 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

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

Section: 17.5.15

  • Key: UML22-901
  • Legacy Issue Number: 8588
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    It is very confusing to have two very similar concepts with the same name (17.5.14 and 17.5.15). Could the two concepts be combined into one, combining figure 440 with 441 and the text? If not, consider changing the name of one of the concepts. Association parameter:ParameterableElement is not what is diagrammed in fig. 441. Instead fig. 441 shows parameter:OperationTemplateParameter[0..1] with no redefinition mentioned.

  • Reported: UML 2.0 — Thu, 17 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

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

Section: 17.5.14

  • Key: UML22-900
  • Legacy Issue Number: 8587
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Typo - Be consistent with the capitalization of "Operation" in sub-section Semantics

  • Reported: UML 2.0 — Thu, 17 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    Indeed. Change the first case to lower case initial letter.

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

Section: 17.5.12

  • Key: UML22-897
  • Legacy Issue Number: 8529
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    The classifier name for the association nameExpression: in fig. 438 is StringExpression not Expression as indicated by text. In addition, the figure indicates that nameExpression:StringExpression[0..1] subsets ownedElement. Typo - under sub-section Notation in para "With alias:" change "is" in the first sent. to "are."

  • Reported: UML 2.0 — Wed, 9 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    Indeed. These errors must be fixed.

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

Section: 17.5.8

  • Key: UML22-896
  • Legacy Issue Number: 8528
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    The redefines statement of association parameteredElement:Classifier[1] is not supported in fig. 429. Delete sub-section Constraints or change wording to "None." Change spelling of alloswSubstitutable to allowSubstitutable in 2nd sent. of last para of sub-section Notation.

  • Reported: UML 2.0 — Wed, 9 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see page 384 of ptc/2006-04-01

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

Section: 18.1.2

  • Key: UML22-907
  • Legacy Issue Number: 8595
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Typos - Requirement 4 - delete the "of" immediately preceding the word "specializations." - Requirement 9 - Change the word "constraint" to "constrain."

  • Reported: UML 2.0 — Thu, 17 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

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

Section: 17.5.20

  • Key: UML22-906
  • Legacy Issue Number: 8593
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:
  • Reported: UML 2.0 — Thu, 17 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    This seems to be a leftover from a previous edit. Remove the association item.

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

Section: 12 Activities

  • Key: UML22-899
  • Legacy Issue Number: 8544
  • Status: closed  
  • Source: Universidad Peruana de Ciencias Aplicadas (UPC) ( ILVER ANACHE PUPO)
  • Summary:

    In Figure 178 and 183 there is two different inheritance relationships. In 178 the class ControlNode is a direct parent for classes ActivityFinalNode and InitialNode. These two classes are a direct descendant from FinalNode in figure 183. These introduce two different inheritance taxonomy with different meaning.

  • Reported: UML 2.0 — Fri, 11 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    See issue 8237 for disposition

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

Section: 17.5.13

  • Key: UML22-898
  • Legacy Issue Number: 8530
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Fig. 438 shows an additional associaton: owningExpression:StringExpression[0..1] that subsets owner

  • Reported: UML 2.0 — Wed, 9 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    Indeed. This item needs to be added.

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

Section: 17.5.17

  • Key: UML22-903
  • Legacy Issue Number: 8590
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Fig. 442 does not show that the association parameter:ConnectableElementTemplateParameter redefines anything.

  • Reported: UML 2.0 — Thu, 17 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    See the discussion to issue 8528. We will add a clarification to the diagram.

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

Section: 17.5.16

  • Key: UML22-902
  • Legacy Issue Number: 8589
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Fig 441 for the association parameteredElement:Operation[1] does not mention that the association redefines TemplateParameter::parameteredElement.

  • Reported: UML 2.0 — Thu, 17 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see page 389 of ptc/2006-04-01

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

Section: 17.5.19

  • Key: UML22-905
  • Legacy Issue Number: 8592
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Add OCL notation to the constraint or a note that OCL notation is not available

  • Reported: UML 2.0 — Wed, 3 May 2000 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see page 392 of ptc/2006-04-01

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

Section: 17.5.18

  • Key: UML22-904
  • Legacy Issue Number: 8591
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Fig. 442 does not show that association parameteredElement:ConnectableElement redefines anything

  • Reported: UML 2.0 — Tue, 9 May 2000 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    See the discussion on issue 8590.

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

Section: 17.2.2

  • Key: UML22-883
  • Legacy Issue Number: 8507
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Not all of the sub-package names given in the sub-section Generalizations are shown in fig. 413. Add them or ellipses. Change capitalization of "information Item" and "Information Items" in sub-section Description to agree. If Information Item is an abstraction shouldn't the name appear in italics in fig. 413? Change last sent. of para 1, sub-section Description to "...for representing information in a very abstract way, one which cannot be instantiated." Change "taken" to "made" in first sent. of para 2 of Descriptions. Delete sub-section Attributes or change wording to "None." Add OCL notation to constraints [1] and [2] or a note that OCL notation is not available. Constraint [1] contains an enumeration list but this is not diagrammed as part of fig. 413. The constraint reads like a guard whose condition is that the InformationItem can only be of the enumerationKind listed in the constraint. Why not diagram it that way? Typos - 1st sent., Para 2 of sub-section Semantics, change "item" to "items." - 2nd sent., Para 3 of sub-section Semantics, reword to "specifying this detailed information belongs to the represented classifier." Question - Why is the multiplicity in fig. 418 0..1? Suggest removing all multiplicities from diag. 418 as they add nothing to it.

  • Reported: UML 2.0 — Tue, 8 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

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

Section: 17.2.1

  • Key: UML22-882
  • Legacy Issue Number: 8506
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Typo - Change first sent. under sub-section Description to "...one or more information items circulates from its sources to its targets." Subject of phrase is singular (one or more) and needs the singular verb. Add OCL notation to the constraints or state that OCL notation is not available. Constraint [1] reads like an enumeration. Why is it not diagrammed showing an enumeration. Reword the except clause to "...and InstanceSpecification except when the classifier of the InstanceSpecification is a relationship (i.e., it represents a link)." Constraint [2] change "target" to "targets" and delete the prepositional phrase "if any." (Or explain how information can flow if there isn't at least one source and one target.)

  • Reported: UML 2.0 — Tue, 8 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

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

Expansion region description

  • Key: UML22-872
  • Legacy Issue Number: 8488
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Expansion region description: "The number of output collections at runtime can differ from the number of input collections." Drop "at runtime".

  • Reported: UML 2.0 — Sun, 6 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    The sentence is supposed to be about modeling time, rather than runtime.

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

ExpansionRegioin example, Figure 261: concurrent => parallel

  • Key: UML22-871
  • Legacy Issue Number: 8487
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    ExpansionRegioin example, Figure 261: concurrent => parallel

  • Reported: UML 2.0 — Sun, 6 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Activities, ExpansionRegion (05)

  • Key: UML22-870
  • Legacy Issue Number: 8486
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    <pre> In ExpansionRegion, clarify the interaction of elements from multiple input collections (ie, there is none). Clarify that the region operates on each collection in the specified mode. From Jim R: If there are N input collections (note there may also be plain scalar inputs, whose value remains constant in each of the executions), then one value from the same position in each of them represents a "slice". The slice is not actually formed into an object or a single value. The body of the region is executed once for each slice. Each of its pins gets the value from the given position in the corresponding input collection. Each execution is independent and concurrent, therefore the values from different positions do not interact. If the body interacts with an outside object, then there is a high possibility of conflict among the concurrent executions, so that is not usually recommened, although it is not forbidden by the UML2 rules. If it does happen, you can't assume any particular order of execution or even that two executions won't hit the same slot at the same time (in this, it is the same as all other uses of concurrency in UML). If each execution keeps to its own subset of values (for example, by indexing into a collection using the input position for that execution), then things might be OK; otherwise it's probably a real bad idea to use this construct. It works best when the computations are purely internal, in that case the concurrency poses no problems at all and permits total freedom in implementation; those kinds of computations are pretty common in practice. </pre>

  • Reported: UML 2.0 — Sun, 6 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

mustIsolate:

  • Key: UML22-879
  • Legacy Issue Number: 8500
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    mustIsolate: The wording of UML 2 for StructuredActivityNode.mustIsolate refers to individual nodes instead of all the nodes in the group: If the mustIsolate flag is true for an activity node, then any access to an object by an action within the node must not conflict with access to the object by an action outside the node. A conflict is defined as an attempt to write to the object by one or both of the actions. If such a conflict potentially exists, then no such access by an action outside the node may be interleaved with the execution of any action inside the node. The UML 1.5 wording was better: Because of the concurrent nature of the execution of actions within and across procedures, it can be difficult to guarantee the consistent access and modification of object memory. [Examples snipped] In order to avoid these problems, it is necessary to isolate the effects of a group of actions from the effects of actions outside the group. This is indicated by setting the mustIsolate attribute to "true" on a group action. If a group action is isolated, then any object used by an action within the group cannot be accessed by any action outside the group until the group action as a whole completes. Any concurrent actions that would result in accessing such objects are required to have their execution deferred until the completion of the group action. In the first example above, if the read actions on the temperature and pressure attributes are wrapped in a group action with mustIsolate set to "true", then the temperature and pressure values read are assured to be consistent, since no changes can intervene between the two reads. Similarly, if an isolated group is used for the second action, then the update is assured to be consistent, since no action outside the group can change the list until the update is complete. Note" The term "isolation" is used here in the sense used in traditional transaction terminology. An execution engine may achieve any required isolation using locking mechanisms, or it may simply sequentialize execution to avoid concurrency conflicts. Isolation is different than the property of "atomicity", which is the guarantee that a group of actions either all complete successfully or have no effect at all. Atomicity generally requires a rollback mechanism to prevent committing partial results. This is beyond the scope of what can be guaranteed by the basic action semantics.

  • Reported: UML 2.0 — Sun, 6 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

No notation

  • Key: UML22-878
  • Legacy Issue Number: 8499
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    In ConditionalNode: "A notational gloss is provided for this frequent situation." There is no notation

  • Reported: UML 2.0 — Sun, 6 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Semantics of isAssured/isDeterminant in conditional node

  • Key: UML22-875
  • Legacy Issue Number: 8493
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Semantics of isAssured/isDeterminant in conditional node, the phrase "concurrently yield a value" sounds it is referring to tests that complete at the same instant in time. Would be clearer to drop "concurrently", since it isn't the concurrency that isAssured/isDeterminant is concerned with, it's the results.

  • Reported: UML 2.0 — Sun, 6 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Add constraint in LoopNode

  • Key: UML22-874
  • Legacy Issue Number: 8491
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Add constraint in LoopNode that loop variable inputs should not have edges coming out of them. Otherwise, the value could leave the pin in the middle of the loop.

  • Reported: UML 2.0 — Sun, 6 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Activities

  • Key: UML22-873
  • Legacy Issue Number: 8490
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Loop node owns output pins as loop input variables, but pins must be owned by actions under the input/output associations in UML 2 (not in UML 1.5).

  • Reported: UML 2.0 — Sun, 6 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    The filer is referring to the loop variable pins.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 17.5.3

  • Key: UML22-890
  • Legacy Issue Number: 8514
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Under sub-section Notation, the last sentence says to see "ParameterableElement (from Templates)" on page 679 (and its subclasses)." What subclasses? I find none listed or diagrammmed in any figure.

  • Reported: UML 2.0 — Tue, 8 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 17.5.3

  • Key: UML22-889
  • Legacy Issue Number: 8513
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Delete sub-section Attributes or change wording to "None." Add that the association boundElement also subsets Element::owner as shown in fig. 428. Change the association name from "template":TemplateSignature to "signature" in the text or change fig. 428 association name from "signature" to "template." The Examples sub-section makes no sense. ClassifierTemplate and PackageTemplate are not to be found in this document. Do you mean Classifier (pg 689) and Package (pg 696)? This section is TemplateBinding but no specializations are listed or referenced. Clarify this sub-section, in particular provide page numbers for the sections to which the reader is referred. Or change the name of Classifier to ClassifierTemplate and Package to PackageTemplate. If name change is made then change the names in all figures that contain these template names

  • Reported: UML 2.0 — Tue, 8 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see page 376 of ptc/2006-04-01

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 17.5.1

  • Key: UML22-888
  • Legacy Issue Number: 8512
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Add associaton owningSubstitution:TemplateParameterSubstitution[0..1] that subsets Element:owner as shown in fig. 428.

  • Reported: UML 2.0 — Tue, 8 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 17.4

  • Key: UML22-885
  • Legacy Issue Number: 8509
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    PprimitiveTypes strike me more as an enumeration or list than a package. Consider changing them to an enumeration or list. Boolean is derived from George Boole and is generally capitalized whenever used. Please be consistent in capitalization of "Boolean" when using the word as an adjective. Sometimes on page 673 it is capitalized ("The Boolean condition") but other times it is not ("boolean type," "boolean attribute," and "boolean expression"). Delete sub-sections Attributes, Associations, and Constraints or change the wording to "None.

  • Reported: UML 2.0 — Tue, 8 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 17.3.1

  • Key: UML22-884
  • Legacy Issue Number: 8508
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    If model is an abstraction of the physical system shouldn't the name in fig. 419 be in italics? Attribute viewpoint:String[*] does not have the same multiplicity as shown in fig. 419 which is the default multiplicity of [0..*] as indicated on page 14 of this document. Delete sub-sections Associations and Constraints or change the wording to "None." Add the word "open" between small and triangle in 1st sent. of Notation. Typo - 2nd sent of sub-section Notation, change "is" to "are."

  • Reported: UML 2.0 — Tue, 8 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see page 371 of ptc/2006-04-01

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 17.5.2

  • Key: UML22-887
  • Legacy Issue Number: 8511
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Delete the sub-sections Attributes and Constraints or change the wording to "None." Association templateBinding:TemplateBinding[*] subsets Element::ownedElement according to fig. 428. Change wording in para 3, sent. 2 of sub-section Semantics to "...by expanding the templates to which it binds, since..." The Examples sub-section makes no sense. ClassifierTemplate and PackageTemplate are not to be found in this document. Do you mean Classifier (pg 689) and Package (pg 696)? This section is TemplateableElement but no specializations are listed or referenced. Clarify this sub-section, in particular provide page numbers for the sections to which the reader is referred.

  • Reported: UML 2.0 — Tue, 8 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see page 374 0f ptc/2006-04-01

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 17.5.1

  • Key: UML22-886
  • Legacy Issue Number: 8510
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Delete sub-sections Attributes and Constraints or change wording to "None." Add the association owningDefault:TemplateParamenter[0..1] that subsets owner. Fig. 427 shows this.

  • Reported: UML 2.0 — Tue, 8 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Clarify the semantics of minimum multiplicity > 0 for streaming parameters

  • Key: UML22-881
  • Legacy Issue Number: 8503
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Clarify that the semantics of minimum multiplicity > 0 for streaming parameters that it is required sometime during execution

  • Reported: UML 2.0 — Mon, 7 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Figure 209 of Activites

  • Key: UML22-880
  • Legacy Issue Number: 8502
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Figure 209 of Activites, and entry in index: <<singleCopy>> should be replaced with <<singleExecution>>.

  • Reported: UML 2.0 — Sun, 6 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    In Activities, Activity, Figure 209, replace "singleCopy" with "singleExecution".

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Add constraints on conditional and loop nodes (02)

  • Key: UML22-877
  • Legacy Issue Number: 8497
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Add constraints on conditional and loop nodes that body outputs are pins on action contained in the body part of the clauses

  • Reported: UML 2.0 — Sun, 6 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see page 361 of ptc/2006-04-01

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Add constraints on conditional and loop nodes

  • Key: UML22-876
  • Legacy Issue Number: 8496
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Add constraints on conditional and loop nodes that decider is an output pin of an action in the test body, and that its type is boolean

  • Reported: UML 2.0 — Sun, 6 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / Conformance / inconsistencies

  • Key: UML22-853
  • Legacy Issue Number: 8459
  • Status: closed  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    Summary:

    There are two fundamental inconsistencies in the way that conformance is defined:
    · BasicActions and BasicInteractions, which are defined at L1, both reference Signal and Event, defined in CommonBehaviors::Communications, which is defined at L2.
    · Profiles are defined as L2 but Appendix C defines a profile for level L1. Clearly, if L1 is to support profiles, the definition of profiles needs to be defined at that level as well or a lower level.

    Recommendation:

    For the first item, move CommonBehaviors::Communications from L2 to L1

    For the second item, a minimal impact resolution is to retain the L1 system as such, but to include it as part of compliance level L2. In general, the standard profiles should be specified explicitly as belonging to the appropriate compliance levels in section 2.4

  • Reported: UML 1.4.2 — Fri, 4 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see pages 335 - 336 of ptc/2006-04-01

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / General / missing merges

  • Key: UML22-852
  • Legacy Issue Number: 8458
  • Status: closed  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    Compliance level L3 references, but does not merge:

    Superstructure::Logical View::UML::CommonBehaviors

    Superstructure::Logical View::UML::CompositeStructures

    There are a number of diagrams in the UML2 Rose model that contain unlabeled dependencies between packages. In particular, Activities, Interactions, StateMachines, and UseCases have dependencies to CommonBehaviors that are unlabeled. See diagram UML/Behavior Packages and UML/UML Top-Level Packages.

    Since CommonBehaviors does not contain any classes, it does not necessarily need to be merged into any compliance level. Instead, the packages it contains are merged as needed.

    Recommendation:

    Remove all unlabeled dependencies between packages, or mark them as either package imports or package merges as needed.

  • Reported: UML 1.4.2 — Fri, 4 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / General / improper subsetting

  • Key: UML22-851
  • Legacy Issue Number: 8457
  • Status: closed  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    The following properties (in the subsets constraints) are unresolved in their unmerged, containing package. The problem is that the properties in these subsets constraints are not defined in the unmerged package. They will be defined in the various compliance levels once the packages have been merged. However, the package merge rules (and the desire to be able to check OCL constraints on unmerged packages) require all references to be resolved before the merge.

    Superstructure::LogicalView::UML::CompositeStructures::InternalStructures::Property::_structuredClassifier

    {subsets classifier}

    Superstructure::LogicalView::UML::Components::BasicComponents::Component::realization

    {subsets clientDependency}

    Superstructure::Logical View::UML::Deployments::Artifacts::Artifact::manifestation {subsets clientDependency}

    Recommendation:

    These are either resolved by including the proper superclass in the unmerged package so that the properties are visible, or copying the associations from another merged package in order to make the properties visible.

  • Reported: UML 1.4.2 — Fri, 4 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see pages 330 - 333 of ptc/2006-04-01

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / General / invalid subset rule too strict

  • Key: UML22-855
  • Legacy Issue Number: 8462
  • Status: closed  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    The redefinition rule [4] of Property on page 127 of ptc/04-10-02 restricts a navigable property from being redefined by a non-navigable property. Unfortunately, this rule is violated in many parts of the model.

    Recommendation:

    As a practical resolution for this problem, it is suggested that this constraint be removed since it does not seem to provide any benefits and yet prevents the realization of the agreed design intent

  • Reported: UML 1.4.2 — Fri, 4 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / Kernel / excessive restriction on redefinition

  • Key: UML22-854
  • Legacy Issue Number: 8461
  • Status: closed  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    In section 7.3.44 on pg. 130 of ptc/04-10-02 there is a constraint that states: “All redefinitions shall be made explicit with the use of a

    {redefines <x>}

    property string.” Unfortunately, this is violated in numerous places in the metamodel. This results in numerous inconsistencies in the metamodel.

    Recommendation:

    As a practical resolution with minimal impact, it is recommended that this restriction be removed. This means that the use of the same association end name for a given association end implies a redefinition of the corresponding association end in an ancestor class.

  • Reported: UML 1.4.2 — Fri, 4 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 14.3.3

  • Key: UML22-861
  • Legacy Issue Number: 8469
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Typo: Constraint 3 contains the word "IntectionFragment". Should be InteractionFragment

  • Reported: UML 2.0 — Sat, 5 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 16.3.6

  • Key: UML22-860
  • Legacy Issue Number: 8468
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Delete sub-section Attributes or change wording to "None." For the associations include:Include[*] and extend:Extend[*], the "Specialized Classifier.feature" is not shown in fig. 401. Add OCL notation to constraints [2] and [3] or indicate the OCL notation is not available. Add an ending ")" to Additional Operation OCL notation--one missing. Typo - 1st sent. of para 3 of Semantics, change "describe" to "Describes." There is no association or navigable link between UseCase and Actor shown in fig. 401. Add appropriate link(s).

  • Reported: UML 2.0 — Fri, 4 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Activities, ExpansionRegion (04)

  • Key: UML22-869
  • Legacy Issue Number: 8485
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    In ExpansionRegion, clarify that that input pins on expansion regions (introduced by merge with CompleteStructuredActivities) provide values that are constant across the execution of the region, and that output pins are not allowed.

  • Reported: UML 2.0 — Sun, 6 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Activities, ExpansionRegion (03)

  • Key: UML22-868
  • Legacy Issue Number: 8484
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    ExpansionRegion: require that all input collections have the same number of elements at runtime.

  • Reported: UML 2.0 — Sun, 6 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Activities, ExpansionRegion (02)

  • Key: UML22-867
  • Legacy Issue Number: 8483
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    ExpansionRegion: remove "If an expansion region has outputs, they must be collections of the same kind and must contain elements of the same type as the corresponding inputs." Inputs and outputs of expansion regions do not need to correspond, this was intended to refer to the pins that flows to the output. Add general constraints on types of source and targets of object flows rather than have the a special case for expansion nodes.

  • Reported: UML 2.0 — Sun, 6 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 16.3.5

  • Key: UML22-859
  • Legacy Issue Number: 8467
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Add the generalization "NamedElement (from Kernal)" on page xxx (page 100 I believe). This generalization is shown in fig. 401 and mentioned in the Description sub-section. Delete sub-sections Attributes and Constraints or change wording to "None." In sub-section Semantics, I'm not certain that the following statement is reflected in fig. 401 "Since the primary use of the include relationship is for reuse of common parts, what is left in a base use case is usually not complete in iteself by dependent on the included parts to be meaningful. This is relfected in the direction of the relationship, indicating that the base use case depends on the addition but not vice versa." Reword 2nd sent of para 2, Semantics, to "All of the behavior of the included use case is executed...." or "The included use case behavior is executed at a single..."

  • Reported: UML 2.0 — Fri, 4 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 16.3.4

  • Key: UML22-858
  • Legacy Issue Number: 8466
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Fig. 401 shows 2 associations: extend:Extend{*] and useCase:UseCase[1]. Define these in the sub-section Associations. Delete sub-section Attributes or change the wording to "None."

  • Reported: UML 2.0 — Fri, 4 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see page 342 of ptc/2006-04-01

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 16.3.3

  • Key: UML22-857
  • Legacy Issue Number: 8465
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Under sub-section Generalizations add the generalization "NamedElement (from Kernal)" on page xxx" (page 100 I believe). This generalization is diagrammed in fig. 401. Delete sub-section Attributes or change wording to "None."

  • Reported: UML 2.0 — Fri, 4 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    Indeed. This was a missed generalization.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / Common Behaviors / missing multiplicites

  • Key: UML22-856
  • Legacy Issue Number: 8463
  • Status: closed  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    In figure 318 on page 463, the multiplicities of DurationObservationAction::duration and TimeObservationAction::now are not specified. This results in violations of the redefinition rules for these association ends.

    Recommendation:

    Set the multiplicities for these association ends to 1, to conform to the multiplicity of WriteStructuralfeatureAction::value association end that they redefine

  • Reported: UML 1.4.2 — Fri, 4 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Activities, ExpansionRegion

  • Key: UML22-866
  • Legacy Issue Number: 8482
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    ExpansionRegion, clarify wording in description: expansion nodes are not input pins.

  • Reported: UML 2.0 — Sun, 6 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Activities

  • Key: UML22-865
  • Legacy Issue Number: 8481
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    <pre> ExceptionHandler, clarify working of constraint [1]: "[1] The exception body may not have any explicit input or output edges." It should say the exception handler and its input object node are not the source or target of any edge. </pre>

  • Reported: UML 2.0 — Sun, 6 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ValueSpecificationAction, Attribute section, is missing the return pin

  • Key: UML22-864
  • Legacy Issue Number: 8478
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    ValueSpecificationAction, Attribute section, is missing the return pin

  • Reported: UML 2.0 — Sun, 6 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Actions

  • Key: UML22-863
  • Legacy Issue Number: 8477
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Figure 141, remove import from IntermediateActions to Communications. Add an import from BasicActions to Communications

  • Reported: UML 2.0 — Sun, 6 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Common Behavior

  • Key: UML22-862
  • Legacy Issue Number: 8476
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Common Behavior: why does Figure 326 refer to Signal from Communications, but not Operation form Communications? (it looks like Communications can refer to Kernel:Operations rather than defining its own).

  • Reported: UML 2.0 — Sun, 6 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 15.3.14

  • Key: UML22-841
  • Legacy Issue Number: 8443
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Association guard:Constraint[0..1] subsets ownedElement. Need to add this to the definition. Association replacedTransition:Transition[0..1] redefined redefinedElement. Need to add this to the definition. Association /redefinitionContext:Classifier[1] subsets redefinitionContext. Need to add this to the definition. Also need to add OCL notation. Constraint [2] - delete last paranthesis. Add OCL notation or a note that OCL cannot express constraint [7]. Add OCL notation or a note that OCL cannot express Additional operation [1]. Typos - pg. 626, para 4, sent 2, add "s" to transition. - pg. 627, 1st bullet under sub-section Example, first sent, delete the final "s" in "states." Why aren't he bulleted statements under sub-section Enabled (compound) transitions constraints? The activities named in fig. 396 ("MinorReq = ID;" and "MajorReq = ID:") are not the same format as indicated in Table 20 ("MinorReq := Id;") - the colon is missing before the equal sign in the figure.

  • Reported: UML 2.0 — Thu, 3 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Appendix A

  • Key: UML22-840
  • Legacy Issue Number: 8440
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    A use case diagram is a structural diagram. Similar to operations in classes in shows the structure of the system services. Therefore a use case is a specialized Classifier and not Behavior like model elements of all other behavior diagrams (interaction, activity, and state machine).

  • Reported: UML 2.0 — Thu, 3 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 15.3.11

  • Key: UML22-837
  • Legacy Issue Number: 8416
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Attributes are derived and need this noted. Also add OCL notation to the derived attributes as per the "How to Read this Specification" (page 14)indicates will be done. isComposit=(region>1) - modified from page 14. isOrthogonal=(region>=2) ??? isSimple=((region=0) and (submachineState=0)) ??? isSubmachineState=(SubmachineState>0) I question the multiplicity of the association connection:ConnectionPointReference[*]. Shouldn't it be [0..*] because the association wouldn't exist if the state was simple or compound. Ths association also subsets ownedMember and that needs to be added to the definition. According to fig. 354, the multiplicity for connectionPoint:Pseudostate is 0..8 and this association subsets ownedElement. I question the multipliticy of the association deferrableTrigger:Trigger[*]. Do all state have MULTIPLE deferrable triggers? First paragraph on page 605 says "a state may specify a set or event types that may be deferred in that state." Associations doActivity:Behavior[0..1], entry:Behavior[0..1], and exit:Behavior[0..1] all subset ownedElement according to fig. 354. Association redefinedState:State[0..1] redefines redefinedElement. This needs stating in the definition. I question the multiplicity of region:Region[*]. If the state is a simple state it has no regions (page 600). Change the multiplicity to [0..*] here and in fig. 354. Association /redefinitionContext:Classifier[1] subsets redefinitionContext and needs mentioning in the definition. Add OCL notation to constraint [3]. OCL font format doesn't appear correct for constraint [4]. Constraint [7] repeats constraint [1] but is just worded and expressed slightly differently. Should bulleted statements on page 605 immediately above Entering a non-orthogonal state be added as constraints? Should an exit point be added to the ATM state machine in fig. 391?

  • Reported: UML 2.0 — Tue, 1 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 15.3.11

  • Key: UML22-836
  • Legacy Issue Number: 8415
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    No mention of figures 387 and 390 are made in the text. Reference figure 387 on pages 600 (Composite state) and page 606 (Entering an orthogonal composite state). Reference figure 390 at end of paragraph 2 on page 613. Typos - In sentence under Exiting an orthogonal state, change "is" in last sentence to "are." - Under Composite state (pg 609) Upper case Decomposition compartment. - Page 606, Under Exiting non-orthogonal state, change "from a composite state..." to "from a simple composite state..." to agree with the line just above Simple state in sub-section Description on page 600. - Page 606, first paragraph, change "il defined" to "ill defined." - Page 612, under Examples, change "sub state machine" to "submachine state." - Page 614, first line, change "In Figure 391 this state machine" to "In Figure 391 the state machine of figure 389 an figure 390." - Page 614, first line of Rational change "Submachine states...has been..." to "State machines...have been...."

  • Reported: UML 2.0 — Tue, 1 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    Minor typos and consistency with figures.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Action Semantics Section: 9.5

  • Key: UML22-835
  • Legacy Issue Number: 8413
  • Status: closed  
  • Source: Codesic Consulting, Inc. ( Jeff Barnes)
  • Summary:

    The JumpAction->Inputs section documents jumpOccurrence:RuntimeInstance[1..1]. The second sentence of the documentation contains a typo that makes the meaning of the documentation unclear. Please re-write the second sentence.

  • Reported: UML 1.4.2 — Tue, 1 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Appendix C.1

  • Key: UML22-839
  • Legacy Issue Number: 8439
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    script is an artifact stereotype on compliance level L1. Artifact is an element on level L2. That's a mismatch.

  • Reported: UML 2.0 — Wed, 2 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    Indeed. The entry should be moved to compliance level L2.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 15.3.12

  • Key: UML22-838
  • Legacy Issue Number: 8433
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Delete sub-section Attributes or change line to "None." Association connectionPoint:Pseudostate[*] subsets ownedMember. According to fig. 354, there is an association submachineState:State[*] that needs to be added and defined in the text. Association extendedStateMachine:StateMachine[*] redefines:redefinableElement I think. Figure 355 is overwritten by fig. 356 and this association is hard to read. In fig. 355, classifier StateMachine is not generalized or connected to any other classifier in the figure. Draw appropriate connections or make the StateMachine classifier a separate figure. Correct spelling of "conectionPoint" in OCL notation for constraint [3]. Add OCL notation to Additional Operations [1], [3], and [4] or otherwise note that OCL notation is not available for these operations. Typos - Para immediately above Run-to-completion and concurrency (pg. 671), change "... the invoked object complete..." to "...the invoked object completes..." - Page 619, 7th para. change "is" to "are." - Page 612, 1st para, last sent., does the capitalization of "verifyTransaction" need changing? - Personal preference for easier understanding place commas in "for, e.g., classes" on page 623 in sub-section Rational (second such labeled sub-section). Complete the sentence/paragraph for the last paragraph under StateMachine extension.

  • Reported: UML 2.0 — Tue, 1 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Specification: Action Semantics Section: 9.5

  • Key: UML22-834
  • Legacy Issue Number: 8412
  • Status: closed  
  • Source: Codesic Consulting, Inc. ( Jeff Barnes)
  • Summary:

    Figure 27 illustrates a directed association from JumpHandler to HandlerAction. Yet the documentation on page 115 says there is a reference from HandlerAction to JumpHandler (jumpHandler 1..1). Where is the association from HandlerAction to JumpHandler? The multiplicity at the (non-navigable) JumpHandler end of A_HandlerAction_JumpHandler is 0..*.

  • Reported: UML 1.4.2 — Tue, 1 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 15.3.10

  • Key: UML22-833
  • Legacy Issue Number: 8411
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Delete sub-section Attributes or change line to "None." Fig. 354 shows that association transition:Transition[*] subsets ownedMember as does association subvertex:Vertex[*]. Fig. 355 shows that association extendedRegion:Region[0..1] redefines redefinedElement and that association /redefinitionContext:Classifier[1] subsets redefinitionContext. Within subsections Additional constraints and Additional operations stateMachine often appears with a lower case "m." Typo - delete the apostrophy starting the sentence in Additional constraing [2].

  • Reported: UML 2.0 — Mon, 28 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 15.3.9

  • Key: UML22-832
  • Legacy Issue Number: 8410
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Font style is not consistent in the list of literal values for PseudoStateKind. Delete sub-sections Attributes and Associations or change line to "None."

  • Reported: UML 2.0 — Mon, 28 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    Minor editorial – follow suggestions

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 15.3.16

  • Key: UML22-843
  • Legacy Issue Number: 8445
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    The multiplicities for the association definitions do not agree with those shown in fig. 354. Typo - Additional operation [1], change "sate" to "state." Question - Are the "?" and "-- no other valid cases possible" legal OCL notation?

  • Reported: UML 2.0 — Thu, 3 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see pages 319/320 of ptc/2006-04-01

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 15.3.15

  • Key: UML22-842
  • Legacy Issue Number: 8444
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Add OCL notation to the constraints or a note that OCL notation is unavailable for these constraints. Typos - first bullet of sub-section Semantics, change "occur" to "occurs." - second bullet of sub-section Semantics, cange "stat" to "state." If a transition of kind external leaves the border of the composite state, how can it end at the composite state itself? Please provide a figure to illustrate this.

  • Reported: UML 2.0 — Thu, 3 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / Collaborations / improper subset

  • Key: UML22-850
  • Legacy Issue Number: 8456
  • Status: closed  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    In figure 100 of ptc/04-10-02, the association end Classifier::representation subsets “Classifier::occurrence” and should subset “Classifier::collaborationUse”. The fix should also be applied to the Associations specification for Classifier in the Composite Structures chapter on page 175.

    Recommendation:

    Change figure 100 as specified above.

    In the entry for Associations of Classifier on page 175, replace the parenthesized expression:

    Subsets Classifier.occurrence

    By the expression:

    Subsets Classifier.collaborationUse

  • Reported: UML 1.4.2 — Fri, 4 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Profiles::ObjectNode has wrong default multiplicity

  • Key: UML22-849
  • Legacy Issue Number: 8454
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    ObjectNode::upper should have default multiplicity unbounded (“*”) in order of object nodes to be multi-valued by default.

    Recommendation:

    Redefine inherited MultiplicityElement::upper to have default “*” in ObjectNode.

  • Reported: UML 1.4.2 — Fri, 4 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Profiles::ExtensionEnd has wrong default multiplicity

  • Key: UML22-848
  • Legacy Issue Number: 8453
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    ExtensionEnd should have a default multiplicity of 0..1 which differs from the inherited MultiplicityElements::lower which defaults to 1. I think therefore that there needs to be an override by ExtensionEnd redefining lower with a different default.

    Recommendation:

    Redefine inherited MultiplicityElement::lower to have default 0 in ExtensionEnd.

  • Reported: UML 1.4.2 — Fri, 4 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    OK, that is a more accurate specification.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Should Profiles::Image be an Element?

  • Key: UML22-845
  • Legacy Issue Number: 8449
  • Status: closed  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    Should Image a subclass of Element? Image and diagram interchange may benefit from reflective capabilities inherited from MOF. Having Image, and all UML metaclasses be a subclass of Element may make it easier for MOF based tools to reflectively navigate the visual notation.

    Recommendation:

    Make Profiles::Image a subclass of Element

  • Reported: UML 1.4.2 — Fri, 4 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see pages 323/324 of ptc/2006-04-01

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 15.3.7

  • Key: UML22-844
  • Legacy Issue Number: 8446
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Inconsistent in the spelling of pre- and post-condition vs pre condition and post condition. Other sections use pre- and post-condition. Association postCondition:Constraint[0..1] subsets ownedElement and preCondition:Constraint[0..1] subsets guard according to fig 357. Question: Why doesn't association postCondition:Constraint subset guard instead or inaddition to ownedElement? For other concepts where pre- and post-conditions exist, they both subset guard

  • Reported: UML 2.0 — Thu, 3 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Remove redundant superclass for Element

  • Key: UML22-847
  • Legacy Issue Number: 8452
  • Status: closed  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    Abstractions::Comments::Comment is a subclass of Abstractions::Comments::Element which is a subclass of Abstractions::Ownerships::Element. The resolution to issue 6279 redefines package merges such that the Element superclass of Element should be removed.

    Recommendation:

    Delete Abstractions::Comments::Element, and make Comment a subclass of Ownerships::Element. Move the associations from Comments::Element to Ownerships::Element

  • Reported: UML 1.4.2 — Fri, 4 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

OCL for Property::opposite() is incorrect:

  • Key: UML22-846
  • Legacy Issue Number: 8451
  • Status: closed  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    OCL for InfrastructureLibrary::Core::Constructs::Property::opposite() should it be:

    opposite =

    if owningAssociation->empty() and association.memberEnd->size() = 2 then

    let otherEnd = (association.memberEnd - self)->any() in

    if otherEnd.owningAssociation->empty() then otherEnd else Set{} endif

    else Set {}

    endif

    Recommendation:

    Fix the operation definition.

  • Reported: UML 1.4.2 — Fri, 4 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 15.3.8

  • Key: UML22-831
  • Legacy Issue Number: 8409
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Typo - Change "Pseudostate are" to "Pseudostates are" in sub-section Description. Fig. 354 says that the association stateMachine:Statemachine[0..1] subsets namespace. Also correct "Statemachine" to S"tateMachine." Fig 354 also shows an association state:State[0..1] that subsets owner. Correct the number of parantheses for constraints [1], [4], and [6]. Bold the word "and" in constraint [3.

  • Reported: UML 2.0 — Mon, 28 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    Minor editorials – change following suggestions

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 15.3.7

  • Key: UML22-830
  • Legacy Issue Number: 8408
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Typos - "In a protocol state machine, several transitions can refer to the same operation as illustrated below." Change below to "Figure 366" as the figure is above the text in the current version. Para. above Unreferred Operations, change "stat" to "state." Association "\referred:Operation[0..*]" needs the slash direction changed to "/" and the multiplicity of fig. 357 doesn't agree with that listed in the text. Change "No additional attributes" to "None."

  • Reported: UML 2.0 — Mon, 28 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    Minor editorials

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 14.3.26

  • Key: UML22-817
  • Legacy Issue Number: 8350
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Typos - Place a period "." at the ent of i) and iii); In first line of Style guidelines sub-section, change "are" to "is."

  • Reported: UML 2.0 — Thu, 24 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 14.3.25

  • Key: UML22-816
  • Legacy Issue Number: 8349
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    The associations toBefore:GeneralOrdering and toAfter:GeneralOrdering use "EventOccurrence" in the definition. OccurrenceSpecification appears to be the renamed "EventOccurrence." The class EventOccurrence is not defined as a concept in this document. However, the name is still used in many places. EventOccurrence occurs in the following places: figures 307, 308, and 347; pages 509 (weak sequencing # 3), 544, 549, and 794; and in the Frame row, Notation column of tables 14, 16, 18, and 19. Either change the class name or define the concept

  • Reported: UML 2.0 — Thu, 24 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 15.3.1

  • Key: UML22-823
  • Legacy Issue Number: 8401
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Typo - Delete the word "of" from the first sent. of sub-section Descriptions. Delete sub-section Attributes or state "None" instead of "No additional attributes." The multiplicities for the associations entry:Pseudostate[1..*] and exit:Pseudostate[1..*] don't agree with figure 354. Change the word "refreshens" to "references" in association definition for state:State[0..1]. In sub-section Semantics, last words of para 2, change "pseudo states" to "pseudostates." Under sub-section Presentation Options change Figure "362" to "361" in the para talking about entry point and change Figure "361" to "362" in the para talking about exit point. Just thought I'd mention that when I printed a hardcopy (PDF using Adobe Acrobat Reader 6.0), the submachine state symbol in fig. 359 had a bold outline and the entry circle is normal weight whereas the submachine state symbol line weight in figs. 360-362 are normal weight as is the example on pg, 638. The exit circle in fig. 360 and on pg. 638 is in bold line weight. There also appears to be a difference in the line weights in the softcopy version.

  • Reported: UML 2.0 — Mon, 28 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 8.3.1

  • Key: UML22-822
  • Legacy Issue Number: 8387
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Fig. 87 on page 157 shows a composite structure diagram. Therefore the horizontal line below the component name is missing (see 9.3.13 for composite structure notation).

  • Reported: UML 2.0 — Sun, 27 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Discussion: This line is optional. Revised Text: N/A Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 15.3.6

  • Key: UML22-829
  • Legacy Issue Number: 8407
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Change "No additional attributes" to "None." The association conformance:ProtocolConformance[*] subsets ownedElement. Please add a specialization statement to the definition. Fig. 357 shows another association: interface:Interface[0..1] that subsets namespace. Add to associations or delete from fig. Constraint [3] is missing two ending parantheses but they may be found in constraint [4] as it has two extra. Delete the very small dot in front of the list of specifications in sub-section Semantics. "Depending on the context" is confusing in light of constraint [1] and "or they can be different" needs further explanation. Totally reword and redefine this paragraph. I, unfortunately, don't know enough to help you further. Typos - Reword to "Protocol state machine interpretation can be: Change "sub-statemachines" to "sub-state machines" in first line of next to last para in sub-section Semantics. In last para of sub-section Semantics, last word of second sent. should be "machines."

  • Reported: UML 2.0 — Mon, 28 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.42

  • Key: UML22-828
  • Legacy Issue Number: 8406
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Chokri Mraidha)
  • Summary:

    In the ReplyAction specification, the association replyValue is specified as an OutputPin which is inconsistant with the specification of this association on Figure 152 (p 241) where it is specified as an InputPin to ReplyAction. The specification page 300 should be changed to InputPin instead of OutputPin.

  • Reported: UML 2.0 — Mon, 28 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    See issue 8197 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 14.3.20

  • Key: UML22-812
  • Legacy Issue Number: 8345
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    According to fig. 329 the association interaction:Interaction[1] subsets namespace and the association argument:ValueSpecification[*] is ordered and subsets ownedElement. Correct text to reflect fig. Constraint [3] change the last word from "Parameter" to "Argument." In sub-section Semantics, para. 4, delete the dash . Typo - First para., pg 540, put a space between "as" and "well" In sub-section Notation, begin a new paragraph with the second sent. of the current 3rd paragraph

  • Reported: UML 2.0 — Thu, 24 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 14.3.19

  • Key: UML22-811
  • Legacy Issue Number: 8343
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Change class name for the association selector to OpaqueExpression (as per fig. 328) or change class name on fig. 328. Interaction:Interaction[1] subsets namespace according to the fig. Mention the specialization in the text definition. Typo - First sent. of Semantics change "OccurrenceSpecification" to "OccurrenceSpecifications."

  • Reported: UML 2.0 — Thu, 24 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 14.3.24

  • Key: UML22-815
  • Legacy Issue Number: 8348
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Change the name of the enumeration list to MessageSortKind on fig. 329, as the section heading, and in sub-section Description

  • Reported: UML 1.4.2 — Thu, 24 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 14.3.21

  • Key: UML22-814
  • Legacy Issue Number: 8347
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    In sub-section Description, change enumerator name from MessageSort to MessageKind

  • Reported: UML 2.0 — Thu, 24 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    Notice that the Issue refers the wrong section. The correct section number is 14.3.22.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 14.3.21

  • Key: UML22-813
  • Legacy Issue Number: 8346
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Since the description say that a MessageEnd represents what can and not what must occur at the end of a message and fig. 329 shows the multiplicity of the association to be 0..1, change the multiplicity of messate:Message from [1] to [0..1].

  • Reported: UML 2.0 — Thu, 24 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 15.3.5

  • Key: UML22-827
  • Legacy Issue Number: 8405
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Typos - For consistency, spell as "pre- and post-conditions" in the Semantics sub-section

  • Reported: UML 2.0 — Mon, 28 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 15.3.5

  • Key: UML22-826
  • Legacy Issue Number: 8404
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Typo - In sub-section Description, change "abide" to "abides." Under sub-section Attributes, change "No additonal attributes" to "None." According to fig. 357, associations specificMachine:ProtocolStateMachine[1] subsets source, subsets owner and generalMachine:ProtocolStateMachine[1] subsets target. Mention these specializations in the definitions. Change sent. under sub-section Constraints to "None."

  • Reported: UML 2.0 — Mon, 28 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 14.4

  • Key: UML22-819
  • Legacy Issue Number: 8352
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Be consistent in the use of the period (.) ending the statement in the reference column of the tables. Place a period at the end of the sentence under sub-section Graphic Paths, pages 554 and 561. First line, page 556 shange shows to show.

  • Reported: UML 2.0 — Thu, 24 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 14.3.29

  • Key: UML22-818
  • Legacy Issue Number: 8351
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Association invariant:Constraint[1] subsets ownedElement and association covered:Lifekube[1] redefines (not subsets/specializes) covered according to fig. 328. Typos - Last sentence of sub-section Semantics, change has to have and is to are.

  • Reported: UML 2.0 — Thu, 24 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.4

  • Key: UML22-821
  • Legacy Issue Number: 8357
  • Status: closed  
  • Source: CEA ( Gerard Sebastien)
  • Summary:

    p 346, keyword «singleExecution» is used for activities that execute as a single shared execution. p 347, keyword «singleCopy» is used in figure is used to specify single execution. Anyway use an uppercase for the first letter of the keyword, as done for Precondition and Postcondition.

  • Reported: UML 2.0 — Fri, 25 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    Pre and postconditions use lowercase first letter like all keywords, see Figure 207.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.5

  • Key: UML22-820
  • Legacy Issue Number: 8356
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Chokri Mraidha)
  • Summary:

    The specification says: "If isReplaceAll is false and the structural feature is unordered and nonunique, then adding an existing value has no effect." This should be replaced by: "If isReplaceAll is false and the structural feature is unordered and UNIQUE, then adding an existing value has no effect."

  • Reported: UML 2.0 — Fri, 25 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 15.3.3

  • Key: UML22-825
  • Legacy Issue Number: 8403
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Change "No additonal attributes." to "None."

  • Reported: UML 2.0 — Mon, 28 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 15.3.2

  • Key: UML22-824
  • Legacy Issue Number: 8402
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Fig. 354 shows the association owningState:State[*]. Please add this to the sub-section or delete it from the diagram. Also, explain how a state can have multiple final states as indicated by the multiplicity in the figure. In the sub-section Semantics, the first sentence seems to contradict constraint number [4]. Please clarify more fully how a final state may be entered if there can be no entry behavior.

  • Reported: UML 2.0 — Mon, 28 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 14.3.17

  • Key: UML22-810
  • Legacy Issue Number: 8341
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Change the name of this enumeration to InteractionOperatorKind and add "break" to the list of Literals in the text

  • Reported: UML 2.0 — Thu, 24 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 14.3.16

  • Key: UML22-809
  • Legacy Issue Number: 8340
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Typo - 2nd sent. under sub-section Description change represent to represents. Add specialization notes to definitions for associations. Association fragment:InteractionFragment subsets ownedMember according to fig. 331 and is ordered. Typo - End the 2nd paragraph under sub-section Semantics with a period. Association guard:InteractionConstraint subsets ownedElement.

  • Reported: UML 2.0 — Thu, 24 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 14.3.15

  • Key: UML22-808
  • Legacy Issue Number: 8339
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Separate the associations into packages. Add the specialization for subsets namespace to enclosingOperand:InteractionOperand[0..1] and subets ownedElement for enclosingInteraction:Interaction[0..1] as shown in the appropriate figures.

  • Reported: UML 2.0 — Thu, 24 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 14.3.2

  • Key: UML22-797
  • Legacy Issue Number: 8323
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Multiplicity of the association does not agree with fig. 330. Change fig. to agree with text definition

  • Reported: UML 2.0 — Wed, 23 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 13

  • Key: UML22-796
  • Legacy Issue Number: 8322
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    General comments: Add OCL notation to the constraints where possible. If not possible state that OCL notation is not available for the constraint. Either delete sub-section headings where there is no data for the sub-section or add the word "None." Make certain that the multiplicities for the associations agree between the text and the associated figures. There is inconsistency in representation of 0..* on figures, sometimes the figures use * to mean 0..* (according to the text definitions) and then sometimes 0..* is used. Several times the figures will note that an association is a redefinition of or subsets a class but the text does not mention this. Be certain to add the appropriate statement to the text definition.

  • Reported: UML 2.0 — Wed, 23 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    See issue N/A for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 13.3.30

  • Key: UML22-795
  • Legacy Issue Number: 8320
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    The generalization "Dependencies" is not listed in fig. 316 under NamedElement. Add this to the figure. The association port:Port[*] is not diagrammed anywhere. Either remove this association from the text or add it to a figure. The sub-section Changes from UML 1.x indicates that the corresponding metaclass was changed from Event but names listed in the BNF definition are all children or grandchildren of the metaclass Event in fig. 317. I believe something needs to change or be clarified but I don't know what.

  • Reported: UML 2.0 — Tue, 22 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 14.3.13

  • Key: UML22-807
  • Legacy Issue Number: 8338
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Separate the associations into appropriate packages which are identified. Multiplicity of association lifeline:LifeLine[0..*] is not diagrammed as 0..*. The association is diagrammed as subsets ownedMember. The association event:MessageEnd is not diagrammed anywhere. If such an association exists, it should probably be diagrammed in fig. 329. Association message:Message[*] subsets ownedMember in fig. 329. Association action:Action[*] subsets ownedElement in fig. 330. Typos - 2nd paragraph, pg 527, 2nd sent. should be "Similarly the deteailed actions...are often omited in Interactions,..." Delete the word "are" from 1st sent. of 3rd para under Notation

  • Reported: UML 2.0 — Thu, 24 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 14.3.14

  • Key: UML22-806
  • Legacy Issue Number: 8337
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Both associations are shown in fig. 331 as "subsets ownedElement" so please add this specialization to the definition text or remove notes from the figure.

  • Reported: UML 2.0 — Thu, 24 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 14.3.4

  • Key: UML22-799
  • Legacy Issue Number: 8325
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Attribute sub-section heading needs to be changed to Associations. Fig. 331 shows message:NamedElement[0..*] as an association

  • Reported: UML 2.0 — Wed, 23 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 14.3.3

  • Key: UML22-798
  • Legacy Issue Number: 8324
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Association operand:InteractionOperand[1..*] subsets ownedElement according to fig. 332. Please add appropriate specializes comment to text. Typo - In the last sentence of sub-section Semantics for Loop change wording from "The loop construct represent..." to "The loop construct represents..."

  • Reported: UML 2.0 — Wed, 23 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 14.3.10

  • Key: UML22-803
  • Legacy Issue Number: 8329
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Typos - Under sub-section Notation, start 3rd paragraph with "For ExecutionSpecification..." In the last sentence of paragraph 3 of Notation write " "(and start and finish associations refer to the very same OccurrenceSpecification)."

  • Reported: UML 2.0 — Wed, 23 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 14.3.8

  • Key: UML22-802
  • Legacy Issue Number: 8328
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Typos - Correct Semantics sub-section sentence to "An execution event represents the start or finish of the execution of an action or a behavior."

  • Reported: UML 2.0 — Wed, 23 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 14.3.6

  • Key: UML22-801
  • Legacy Issue Number: 8327
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    If DescriptionEvent has a constraint that no other OccurrenceSpecification may appear below the OccurrenceSpecification that references the DescructionEvent on a given Lifeline in an InteractionOperand then a similar constraint should be added to the CreationEvent. "No other OccurrenceSpecification may appear above an OccurrenceSpecification which references a CreaationEvent on a given Lifeline in an InteractionOperand."

  • Reported: UML 2.0 — Wed, 23 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 14.3.5

  • Key: UML22-800
  • Legacy Issue Number: 8326
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Fig. 331 does not show package name for the generalization InteractionFragment. Typo - Change paragraph 3 of Notation to "A Continuation that is alone in an InteractionFragment is considered to be at the end of the enclosing InteractionFragment."

  • Reported: UML 2.0 — Wed, 23 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 13.3.29

  • Key: UML22-794
  • Legacy Issue Number: 8319
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    To be consistent with other multiplicities in fig. 318, add the association multiplicity to the figure. Mention that the association redefines value as shown in the figure. I am not familiar with BNF notation but should "<timeobservation>" be spelled "<timeObservation>?"

  • Reported: UML 2.0 — Sat, 26 Feb 2000 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 13.3.28

  • Key: UML22-793
  • Legacy Issue Number: 8318
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    To be consistent with other multiplicities on the figure, add the multiplicities for the associations. Also mention that each association redefines minimum or maximum

  • Reported: UML 2.0 — Tue, 22 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see ptc/2006-04-01 p 261

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 13.3.27

  • Key: UML22-792
  • Legacy Issue Number: 8317
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Under sub-section Description change "represent" to "represents." Under sub-section Notation, reword "Often a TimeExpression is a non-negative integer" to "Often a TimeExpression is an UnlimitedNatural number." Saying that often a TimeExpression is a non-negative integer implies that it may, at times, be a negative integer

  • Reported: UML 2.0 — Tue, 22 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see ptc/2006-04-01 p 260

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 14.3.12

  • Key: UML22-805
  • Legacy Issue Number: 8331
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Change wording of definitions for associations to: "The OccurrenceSpecification referenced that comes before the OccurrenceSpecification referenced by after" and "The OccurrenceSpecification referenced that comes after the OccurrenceSpecification referenced by before"

  • Reported: UML 2.0 — Wed, 23 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 14.3.3 & 14.3.11

  • Key: UML22-804
  • Legacy Issue Number: 8330
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    The Description for the concept Gate identifies the different roles gates play as formal, actual, and expression. Fig. 332 uses the terms formal and actual in the association names but not expression. I think expression is very descriptive and suggest changing the name of the association from cfragmentGateGate to expressionGate:Gate. This would require changing figure 332 and the text for CombinedFragment.

  • Reported: UML 2.0 — Wed, 23 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 13.3.26

  • Key: UML22-791
  • Legacy Issue Number: 8316
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Add package name SimpleTime to association when:TimeExpression[1]. Fig. 318 shows that this association redefines when. Add the association for the package Communications as shown in fig. 317. This is when:ValueSpecification[1] that subsets ownedElement.

  • Reported: UML 2.0 — Tue, 22 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    Resolved by resolution to issue 8894.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 13.3.24

  • Key: UML22-790
  • Legacy Issue Number: 8315
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Fig. 317 shows signal:Signal[1] as an association of SignalEvent, not an attribute. Either correct text or figure. Delete the "." leading the first paragraph under the sub-section Notation

  • Reported: UML 2.0 — Tue, 22 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 13.3.3

  • Key: UML22-776
  • Legacy Issue Number: 8297
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Multiplicities for the associations need to be added to the text for raisedException:Classifier[0..*], and changed in the associated diagrams to reflect the correct multiplicity (1 for method:Behavior (according to the text) and not * as shown in fig. 311 and 0..* for fig. 315). Unless "specializes" means the same thing as "redefines" change either the text for raisedException:Classifier from specializes to redefines or change fig 315. from redefines to specializes. Regardless, less confusion would occur if the text and the figure used the same word.

  • Reported: UML 2.0 — Fri, 18 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 13.3.2

  • Key: UML22-775
  • Legacy Issue Number: 8295
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Specialization mentioned for the association context:BehavioredClassifier[0..1] is not shown on figure 311. Multiplicities for ownedParameter:Parameter in the text do not agree with fig. 311. According to the text the ownedParameter:Parameter references a list of parameters "that can be given" which implies that no parameters may be given and therefore the multiplicity should be [0..*]. This is not what is shown in fig. 311. Multiplicities for remaining associations listed do not agree between the text and the diagrams (fig. 311 & 313). Multiplicities should probably be [0..*] which are not what are shown in figs. 311 & 313. Add the specialization for the association redefinedBehavior:Behavior in the text to agree with fig. 311. Specializations listed for the associations precondition:Constraint and postcondition:Constraint do not agree with fig. 313. Figure 313 shows that these associations subset ownedRule. Add OCL notation to the constraints where possible or indicate that OCL notation is not available.

  • Reported: UML 2.0 — Thu, 17 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    In the recent version of the specification, the specialization for context:BehavioredClassifier has already been added. The multiplicities mentioned above are all “” which is equivalent to “0..”. To correct the remaining mismatch between text and diagram:

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 13.3.14

  • Key: UML22-784
  • Legacy Issue Number: 8308
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Add OCL notation or a note that OCL is unable define a notation for the constraints.

  • Reported: UML 2.0 — Tue, 22 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 13.3.12

  • Key: UML22-783
  • Legacy Issue Number: 8307
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    To be consistent, add the multiplicity for duration:Duration[1] to figure 318. Also, fig. 318 indicates that the association redefines value. Please indicate this in the text. I am not familiar with BFN but should "<urationobservation>" be "<durationObservation>"?

  • Reported: UML 2.0 — Tue, 22 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 13.3.4

  • Key: UML22-778
  • Legacy Issue Number: 8301
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Under sub-section Generalizations change "Class" to "Classifier." Figures use italics for displaying the concept name so you need to mention that BehavioredClassifier is an abstract class. Under sub-section Associations add package name BasicBehaviors before the first two associations. Add the multiplicity which should probably be [0..*] and if this is correct then change fig. 311 to agree with [0..*] or 1 as is currently indicated by the text. If the multiplicity is as indicated in fig. 311 , then change the text to agree. For the association ownedTrigger:Trigger[0..*], fig. 316 does not indicate this multiplicity. Make the two agree. Add OCL notation or a note that OCL can not supply notation. The sub-section Semantics describes two BehavioredClassifiers - an immediate event and an input event pool. Possibly consider making these children of BehavioredClassifiers or of Event (fig. 316), i.e. ImmediateEventOccurrence and InputEventPool, instead of just Event. If this is done then two additional concepts would need to be added.

  • Reported: UML 2.0 — Tue, 22 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 13.3.8

  • Key: UML22-780
  • Legacy Issue Number: 8303
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Under sub-section Description change "each of its instance" to "each of its instances." The multiplicity for the association ownedReception:Reception in the text does not agree with fig. 314. If it is [0..*} both text and fig. 314 need changing. Specializes Classifier.feature is not shown in fig. 314 as a specialization of Class but rather as a subset of Interface. Correct either the fig. 314 or text.

  • Reported: UML 2.0 — Tue, 22 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 13.3.7

  • Key: UML22-779
  • Legacy Issue Number: 8302
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Add the specializes or subsets comment to the association to agree with fig. 317. Question: If the default value of a Boolean expression is true and its value changes to false would there be a corresponding changeExpression? To me the description and semantics imply that the default value for all Boolean expressions is set at false and this isn't true (e.g., MutliplicityElement attribute isUnique; Port attribute isService). Therefore, what happens when those values change?

  • Reported: UML 2.0 — Tue, 22 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 13.3.23

  • Key: UML22-789
  • Legacy Issue Number: 8314
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Under sub-section Description change wording to the following: "A signal is a specification of a type of send request instances that communicated..." and "The data...are representedas attributes..."

  • Reported: UML 2.0 — Tue, 22 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 13.3.22

  • Key: UML22-788
  • Legacy Issue Number: 8313
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Add OCL notation to constraint [2] or the note that ICL notation is not definable

  • Reported: UML 2.0 — Tue, 22 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 13.3.9

  • Key: UML22-782
  • Legacy Issue Number: 8305
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Reword the last sentence under sub-section Semantics. Assuming is not good. State clearly that the ending point in time and the starting point in time would swap. Change "assuming" to "because." Under sub-section Notation, change "Often a Duration is a non-negative integer expression..." to "Often a Duration is an UnlimitedNatural number..." Use of the word "often" implies that the notation could be expresses as a negative integer which, for Duration is an impossibility (at least in our universe

  • Reported: UML 2.0 — Tue, 22 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 13.3.10

  • Key: UML22-781
  • Legacy Issue Number: 8304
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Figure 318 shows an association of specification:DurationInterval[1] that redefines specification. Add this to the text or delete the association from the figure. Delete the "." after "DurationConstaint in Figure 320 caption.

  • Reported: UML 2.0 — Tue, 22 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 13.3.19

  • Key: UML22-786
  • Legacy Issue Number: 8311
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    The multiplicity of the attribute language:String[*] in the text does not agree with that shown in fig. 311. Change fig. 311 to agree with the text. Delete the sub-section heading Examples are there none.

  • Reported: UML 2.0 — Tue, 22 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 13.3.15

  • Key: UML22-785
  • Legacy Issue Number: 8309
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    The association multiplicity in the text does not agree with fig. 314. If multiplicity is [0..*], both text and figure need to be changed

  • Reported: UML 2.0 — Tue, 22 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 13.3.20

  • Key: UML22-787
  • Legacy Issue Number: 8312
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Add OCL notation to or a note that OCL can not define the constraints

  • Reported: UML 2.0 — Tue, 22 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 7.3.36

  • Key: UML22-777
  • Legacy Issue Number: 8298
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    BNF of a operation defines name and type of a parameter as mandatory fields. But both are optional

  • Reported: UML 2.0 — Tue, 22 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.35

  • Key: UML22-755
  • Legacy Issue Number: 8255
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    I forgot to mention that "ordered" needs to be added to the following associations: results:OutputPin[0..*], loopVariable:OutputPin[0..*], and loopVariableInput:InputPin[0..*] as shown in fig. 196.

  • Reported: UML 2.0 — Mon, 7 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    Also added subsets statements to results, loopVariable, and loopVariableInput.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3

  • Key: UML22-754
  • Legacy Issue Number: 8254
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Add sections for front end node and back end node as mentioned in LoopNode

  • Reported: UML 2.0 — Mon, 7 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.35

  • Key: UML22-753
  • Legacy Issue Number: 8253
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Correct multiplicities of associations so that the figures (195 and 196) agree with text. Add subsets statments to descriptions as shown in fig. 96. Typo - 5th para, 1st sent of Semantic sub-section change "body sections has" to "body section has." Delete sub-sections Notation and Examples as there are none.

  • Reported: UML 2.0 — Mon, 7 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    Multiplicities are in consistent format. Headers issue is duplicate with 8155.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.48

  • Key: UML22-767
  • Legacy Issue Number: 8273
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Under sub-section Notation, say see fig. 307

  • Reported: UML 2.0 — Mon, 14 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.48

  • Key: UML22-766
  • Legacy Issue Number: 8272
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    In sub-section Description, structured activity node is noted as possibly having pins in CompleteStructuredActivities but no pins show any relationship to StructuredActivityNode in fig. 196. The association variable:Variable[0..1] is diagrammed (fig. 195) as belonging to the StructuredActivities package which does not agree in multiplicity and which does indicate that ownedMember is subsetted. A third association is also diagrammed in fig. 195. The association activity:Activity[o..1]. The figure also shows that this association redefines Activity. Figure 196 shows an association of containedEdge:ActivityEdge[?..*]. The figure shows multiplicity as * but in too many cases this should be shown as 0..* In addition, fig. 196 indicates that this association redefined contaniedEdge. Add OCL notation to constraints. In 3rd para of sub-section Semantics, last sentence add the verb "are" between tokens and left. Under the sub-section notation change the word enclosed to enclosing and add the appropriate notation symbology as it is not found in the descriptions of the children of StructuredActivityNode (conditionalNode, loopNode, or sequenceNode as shown in fig. 195) or in section 12.4.

  • Reported: UML 2.0 — Mon, 14 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12

  • Key: UML22-771
  • Legacy Issue Number: 8280
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    General comments. Change the multiplicities on the figures to reflect 0..* instead of only . Some of the figures show it the 0.. way but most do not. If the text lists associations as [0..*] the associated figures should agree. Add OCL notation where possible and where there is no OCL notation available so note it. Delete sub-section headings where there is nothing under them or state None. For specialized concepts, if there is no new information to impart change the word from none to the phrase no new if there was some information in the original concept description sub-section. Generalizations are often not diagrammed in the appropriate Abstract Syntax package diagrams. For instance, the concept ControlNode generalized ActivityNode (from BasicActivities. Even though ActivityNode (the parent) is found in other packages, ControlNode (the child) is not. Should mention be made that ControlNode generalizes ActivityNode from the StructuredActivities package when ContronNode isn't in this package? If so, explain more fully in the How to Read This Specification Section (6.5) about the direct generalizations of a concept being generalized to all packages to which the parent belongs. Where a generalization is diagrammed not all of the "from" packages are listed as indicated in the concept text. Add all package names to the parent namespace or use ellipses to indicate that the list is longer than the namespace allows.

  • Reported: UML 2.0 — Mon, 14 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.4

  • Key: UML22-770
  • Legacy Issue Number: 8279
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Typos - remove the dash from between page and the number when referencing. ActivityNode Notation cell delete ExecutableNode and ControlNode as they just refer the reader elsewhere. ControlNode Notation cell delete FinalNode as it just refers reader elsewhere. Add ActivityNode and FlowNode. ExeceptionHandler Notation cell does not exactly agree with fig. 253. In fig. 253 the small square sits across the HandlerBodyNode instead of abutting it.

  • Reported: UML 2.0 — Mon, 14 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.38

  • Key: UML22-758
  • Legacy Issue Number: 8258
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    The multiplicity of association (CompleteActivities) inState:State[0..*] does not agree with fig. 189. Add OCL notation to constraint (BasicActivities) [1]. Add OCL notation to contraints (CompleteActivities. Add "(BasicActivities)" to the 1st Semantics sub-section

  • Reported: UML 2.0 — Tue, 8 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.37

  • Key: UML22-757
  • Legacy Issue Number: 8257
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Add OCL notation to constraints. In the Semantics (CompleteActivities) sub-section, third para change receiving to multireceiving and is to are. In Examples sub-section, the example describing fig. 286, last line indicates that the selection specifies that a query operatiion that takes an Order evaluates the customer object via the Order.customer:Party association. This is not what is diagrammed in the right side of fig. 286.

  • Reported: UML 2.0 — Tue, 8 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    OCL is duplicate with 6346.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Profiles:Extension End

  • Key: UML22-756
  • Legacy Issue Number: 8256
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    Profiles:Extension End - the spec needs to be clear on the behaviour of the

    {required}

    property of an extension if the extending stereotype in question
    has subclasses. Are those sub-stereotypes also required?

  • Reported: UML 1.4.2 — Tue, 8 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.2

  • Key: UML22-765
  • Legacy Issue Number: 8271
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Fig. 196 shows no relationship between concepts immediately under Action (StructuredActivityNode and ActivityEdge) and any of the other concepts in the diagram. There are no connecting lines. If this is truly the case, break this single diagram into two or, as I think (after reading section 12.3.47) there should be some relationship shown between the concepts on the right side of the diagram and those on the extreme left, add lines to show the appropriate relationships.

  • Reported: UML 2.0 — Mon, 14 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.47

  • Key: UML22-764
  • Legacy Issue Number: 8270
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Fo the association executableNode:ExecutableNode[*] mention that it redefines containedNode as shown in diagram 195

  • Reported: UML 2.0 — Mon, 14 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    Also added ordered to the property string.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 super/templates/

  • Key: UML22-763
  • Legacy Issue Number: 8265
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The definition of Classifier and ClassifierTemplateParameter indicates that there may be additional constraint placed on the parameter. Examples and notation also indicate that. However, there is no defined way to express that constraint in the metamodel (at the very least it is not obvious and is very open for interpretation). The metamodel must provide a meta-association from ClassifierTemplateParameter to Classifier to represent the constraining classifier.

  • Reported: UML 1.4.2 — Thu, 10 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see pages 232/233 of ptc/2006-04-01

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.43

  • Key: UML22-760
  • Legacy Issue Number: 8262
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    The association condition:Constraint[0..*] does not have the same multiplicity as fig. 192. Also the fig. indicates that the association subsets ownedElement. Add OCL notation to constraints

  • Reported: UML 2.0 — Tue, 8 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.41

  • Key: UML22-759
  • Legacy Issue Number: 8261
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    The attribute effect:ParameterEffectKind[0..1] does not display this multiplicity in fig. 192. Reword the definition of attribute isStream:Boolean[1..1]=false to "Tells whether an input parameter may accept valuses or an output parameter post values while the behavior is executing." parameterSet:ParameterSet[0..*] listed as an attribute is an association. Please move it to the Association sub-section. The multiplicity for parameterSet:ParameterSet[0..*] does not agree with fig. 192. Add OCL notation to the constraints. Under sub-section Notation the last sent. says to "See notation for Operations." but gives no reference location. Is this supposed to be at page 105?

  • Reported: UML 2.0 — Tue, 8 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.49

  • Key: UML22-774
  • Legacy Issue Number: 8294
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Under sub-section Associations and Constraints change None to No new

  • Reported: UML 2.0 — Mon, 14 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    See issue 8232 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.46

  • Key: UML22-773
  • Legacy Issue Number: 8293
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    For sub-sections Associations and Constraints change the None to No new.

  • Reported: UML 2.0 — Mon, 14 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    See issue 8231 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 13.1

  • Key: UML22-772
  • Legacy Issue Number: 8292
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Figures 307 and 308 are identical. Fig. 308 does not show what the text is describing as the Communication Domain Model(especially the paragraph on pg 457 starting with "As shown in Figure 308..."). Fig. 307 (and current 308) multiplicity for the association execution:BehaviorExecution is diagrammed as * but I wonder if it shouldn't be 0..* since the text indicates that an object may or may not cause the execution of a behavior. In the paragraph immediately following fig. 309, I believe that "The execution of a send action results in a send request, which results in a signal event occurrence (not a call event occurrence as stated). Minor editing call - In the first line on page 457, change synchronously and asynchronously to synchronous and asynchronous.

  • Reported: UML 2.0 — Wed, 16 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see pages 240/241 of ptc/2006-04-01

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/templates/inexplicable constraint on defaults

  • Key: UML22-762
  • Legacy Issue Number: 8264
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The definition of TemplateParameter states that the parameter cannot own at the same time its parametered element and default element. The ownership of those two elements is mutually exclusive. It is also expressed as an OCL constraint. However, there is no justification offered in the spec for this constraint and one is not obvious. The constraint should be removed.

  • Reported: UML 1.4.2 — Thu, 10 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    Indeed, cannot see any justification for this. Remove the constraint.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.44

  • Key: UML22-761
  • Legacy Issue Number: 8263
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Add package name to first Constraint sub-section. Left fig of fig. 295 needs an "s" on end. Shouldn't exception handler edges also be used in figures 296 and 303? If not, please clarify that the execption pin notation takes the place of the notation for the exception handler notation.

  • Reported: UML 2.0 — Wed, 9 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.51

  • Key: UML22-769
  • Legacy Issue Number: 8276
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Under sub-sections Associations and Constraints change none to no new

  • Reported: UML 2.0 — Mon, 14 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    See issue 8232 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.50

  • Key: UML22-768
  • Legacy Issue Number: 8275
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Add "See "ValuePin (from BasicAQctions)" on page 309." immediately under concept heading. Change None to No new under the sub-section Associations. Delete the word "these" in the 3rd sentence of sub-section Semantics. Delete sub-section Examples as there are none.

  • Reported: UML 2.0 — Mon, 14 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    Empty section issue is duplicate with 8231. Headers issue is duplicate with 8155.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.34

  • Key: UML22-752
  • Legacy Issue Number: 8252
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Add the package name IntermediateActivities to the first Associations sub-section. Add the subsets ownedElement statement (as shown in fig 193) to the association joinSpec:ValueSpecification[1..1]. Typo - remove the second a between containing and join in the 4th sent of the Notation sub-section 1st para. Change AcceptOrder behavior to SendInvoice behavior (as shown in fig 277) in the 1st sentence in the Examples sub-section. Add OCL notation to the constraints

  • Reported: UML 2.0 — Mon, 7 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.33

  • Key: UML22-751
  • Legacy Issue Number: 8250
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    The order cancellation request example lends itself to enhancement. Fig. 274 could be enhanced if there was drawn a fork from invoice providing multiple edges of "no payment needed" or "make payment" with the "no payment needed" edge directly entering the join. Another fork could also be added after the AcceptPayment activity with one outgoing edge labeled "refund payment" with an edge to an activity "IssueRefund" then an edge going to the join. The explanation would reiterate that a token transfer, once initiated (SendInvoice activity), that is outside of the region is not interruptable. That since the SendInvoice activity is outside the region, no matter when the CancelOrder interrupt activity is issued, the SendInvoice activity is issued. However, corrective activities are needed to be performed before the CloseOrder actvity can be accomplished. This would be to either issue the invoice stating no payment is due or to issue a refund once payment is received. Additionally, wouldn't the CancelOrder activity more likely go to the merge before the CloseOrder activity instead of directly to the Activity Final? Otherwise, logically thinking, some order is out there not closed (just canceled). But then maybe (probably??) I'm missing the point of the example in which case a better explanation of the example needs to be provided.

  • Reported: UML 2.0 — Mon, 7 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.17

  • Key: UML22-738
  • Legacy Issue Number: 8234
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Multiplicity for StructuredActivities associations test:ActivityNode[0..*] and body:ActivityNode[0..*] and for CompleteStructuredActivities association bodyOutput:outputPin[0..*] do not agree with figures 195 and 196 respectively. Remove the second set of parantheses from the sub-section heading Associations ((CompleteStructuredActivities)).

  • Reported: UML 2.0 — Fri, 4 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.16

  • Key: UML22-737
  • Legacy Issue Number: 8233
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Package CompleteActivities is not supported by fig. 182 as a generalization for this concept. Change Figure 293 reference in sub-section Notation to either figure 294 or, more likely, figure 301.

  • Reported: UML 2.0 — Fri, 4 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.15

  • Key: UML22-736
  • Legacy Issue Number: 8232
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Change "None" to "No new" for sub-sections Attributes, Associations, and Constraints

  • Reported: UML 2.0 — Fri, 4 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    See issue 8670 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.14

  • Key: UML22-735
  • Legacy Issue Number: 8231
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    For the Attributes, Associations, and Constraints sub-sections change "None" to "No new." This would be a good policy to follow for all "(as Specialized)" concepts where no new information is presented in the 'as Specialized" concept.

  • Reported: UML 2.0 — Fri, 4 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Discussion: This was fixed as part of an editorial pass in a previous release. Revised Text: N/A Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

MultiplicityElement BNF too restrictive

  • Key: UML22-731
  • Legacy Issue Number: 8226
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    The BNF for Notation in 9.12 of Infra and 7.3.32 of Super does not allow specification of uniqueness-designator without preceding order-designator.
    This seems too restrictive and is in fact inconsistent with the example in Fig 59 of Super which just shows

    {unique}

    .

  • Reported: UML 1.4.2 — Thu, 3 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.13

  • Key: UML22-730
  • Legacy Issue Number: 8225
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Fig. 192 spells the association as ownedParameterSet (no "s"), does not express the same multiplitity as the text, and indicates that the association subsets ownedmember (need to capitalize the "M" in the figure). Make text and figure agree.

  • Reported: UML 2.0 — Thu, 3 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.6 & 12.3.19

  • Key: UML22-741
  • Legacy Issue Number: 8237
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    I'm confused. Fig. 178 shows ActivityFinalNode as a child of ControlNode in the BasicActivities sub-package, but in fig. 183 it is a "grandchild" of ControlNode and a child of FinalNod in the IntermediateActivities sub-package. Can a concept be both a child and a grandchild of the same higher-level concept, in this case ControlNode?

  • Reported: UML 2.0 — Fri, 4 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.19

  • Key: UML22-740
  • Legacy Issue Number: 8236
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Fig. 179 does not support generalizations of CompleteActivities, CompleteStructuredActivities, or IntermediateActivities packages. Add OCL notation

  • Reported: UML 2.0 — Fri, 4 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.18

  • Key: UML22-739
  • Legacy Issue Number: 8235
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    The generalization from CompleteStructuredActivities is not supported by the figures. Typo - add a space before last sentence in para 2 of sub-section Description. (Before Note that... .) Change wording of definition of attribute isDeterminate:Boolean to "If true, the modeler asserts that at most only one of concurrent tests will succeed and therefore the choice of the clause is deterministic." The multiplicity of the CompleteStructuredActivities association result:OutputPin[0..*] is not what is shown on fig 196. Also change the definition to reflect that the association is ordered and subsets output. Delete sub-section headers Notation, Presentation Option, and Examples are there are none. Suggest changing wording in sent 5 para 4 of sub-section semantics to "If the isDeterminate attribute has a true value, the modeler asserts that at most only one of concurrent test sections will yeild a test value (the predecessor relationship may be used to enforce this assertion)."

  • Reported: UML 2.0 — Fri, 4 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.28

  • Key: UML22-746
  • Legacy Issue Number: 8242
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Add OCL notation to the constraint

  • Reported: UML 2.0 — Mon, 7 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    See issue 6425 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.27

  • Key: UML22-745
  • Legacy Issue Number: 8241
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Add OCL notation to the constraint. In sub-section Semantics, last sent. of para 1 change "concurrency" to "mode." Typo - In sub-section Presentation Option, put a space after Figure 259. On Page 399, change figure reference number to 261. In fig. 261, chane <<concurrent>> to <<parallel>>.

  • Reported: UML 2.0 — Mon, 7 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    Missing OCL issue is a duplicate of 6452. Empty section issues are duplicates of 8155.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.23

  • Key: UML22-744
  • Legacy Issue Number: 8240
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Add subsets note to association protectedNode:ExecutableNode[1..1] as shown on fig. 197. Add OCL notation to constraints. Under sub-section Presentation Option change "interrupting edge is a zig-zag adornment..." to "exception handler is a zig-zag adornment..." Delete sub-section heading Rationale as there is none. Typo - Under sub-section Changes from previous UML in para 2 put a space between first and second sentences.

  • Reported: UML 2.0 — Mon, 7 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    OCL is duplicate with 6346. Headers issue is duplicate with 8155.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Used of "Redefines ...from Abstractions" in descriptions is misleading

  • Key: UML22-734
  • Legacy Issue Number: 8229
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    For example 11.7.2 of Infra: the name property states
    Redefines the corresponding attributes from Basic::NamedElement and Abstractions::Visibilities::NamedElement.

    However there is no redefinition occurring; nor would it make sense.

  • Reported: UML 1.4.2 — Thu, 3 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

BNF Notation for Operation is too restrictive

  • Key: UML22-733
  • Legacy Issue Number: 8228
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    In 11.8.2 (Infra) and 7.3.36 (Super) the notation BNF requires a

    {<oper-property}

    any time there is a ':' after the operation name

  • Reported: UML 1.4.2 — Thu, 3 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Incomplete BNF for Property

  • Key: UML22-732
  • Legacy Issue Number: 8227
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    In BNF Notation for Property (11.3.4 of Infra, 7.3.44 of Super), <prop-modifier> is defined but never refered to

  • Reported: UML 1.4.2 — Thu, 3 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.24

  • Key: UML22-743
  • Legacy Issue Number: 8239
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Change type font to italics on fig. 195. Change association handler:ExceptionHandler [0..1] so that fig. 197 and text agree. Add the subsets ownedElement note as shown in fig 197.

  • Reported: UML 2.0 — Mon, 7 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.22

  • Key: UML22-742
  • Legacy Issue Number: 8238
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Add OCL Notation to constraints. Typo - remove 2nd "a" from sent3 of para 2 of sub-section Notation. Delete sub-section headers Presentation Option and Style Guidelines as there are none.

  • Reported: UML 2.0 — Fri, 4 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    Missing OCL issue is a duplicate of 6452. Empty section issues are duplicates of 8155.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.38

  • Key: UML22-748
  • Legacy Issue Number: 8245
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    I may be all wet (after all it is a Monday morning and raining here) but I think fig. 265 needs to be redrawn. The notation between the BuildComponent and InstallComponent activites is different than the notation between the InstallComponent and DeliverApplication activities yet the flow is basically the same. To agree with the left side of the flow between BuildComponent and InstallComponent activities, there should be a fork after the InstallComponent activity with an edge going to DeliverApplication activity and an edge going to a decisionNode. The decisionNode should have two edges exiting it. One labeled [more components to be installed] and going back to the InstallComponent activity; a second labeled [no more components to be installed] going to a Flow final node. The edge and the [no more components to be installed] label need to be removed from the edge going from the decisionNode to the DeliverApplication activity. Out of curiosity, why was a fork notation used and not the decisionNode with three control flow edges leading from it?

  • Reported: UML 2.0 — Mon, 7 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.30

  • Key: UML22-747
  • Legacy Issue Number: 8243
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Add OCL notation to the constraints

  • Reported: UML 2.0 — Mon, 7 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    See issue 6425 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.32

  • Key: UML22-750
  • Legacy Issue Number: 8248
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Add OCL notation

  • Reported: UML 2.0 — Mon, 7 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    See issue 6425 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.31

  • Key: UML22-749
  • Legacy Issue Number: 8247
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Add OCL notation to constraints. Reword last sentence in last paragraph of sub-section Semantics. The entire sentence is confusing and unclear

  • Reported: UML 2.0 — Mon, 7 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    The missing OCL issue is a duplicate of 6425.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.1

  • Key: UML22-729
  • Legacy Issue Number: 8224
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Typo - Capitalize the "M" in ownedMember of the subsets not for the BehavioralFeature association ownedParameterSet:ParameterSet

  • Reported: UML 2.0 — Thu, 3 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.12

  • Key: UML22-728
  • Legacy Issue Number: 8223
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Associated fig. 192 spells association name as ownedParameterSet (no "s"), does not show the same multiplicity, and shows that this association subsets ownedMember. Make fig and text agree.

  • Reported: UML 2.0 — Thu, 3 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    Multiplicity in fig. 192 is “*” and in associations section “[0..*]”. Both are the same.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.10

  • Key: UML22-727
  • Legacy Issue Number: 8222
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Associated fig. 184 does not show generalizations from FundamentalActivities for ActivityGroup or from Dependencies for NamedElement. The association activity:Activity[0..1] is not diagrammed in fig. 184. The description for the association represents:Element[0..1] needs rewording. Does it mean "An element constraining the behaviors invoked by the nodes in the partition" (constraining used as a verb) or "The element constraining behaviors that are invoked by the nodes in the partition (constraining used as the noun "constraining behaviors")? Fig. 184 shows additional associations: ContainedEdge:ActivityEdge[1..1] and containedNode:ActivityNode[1..1]. These need to be added to text. Add OCL notation to constraints.

  • Reported: UML 2.0 — Thu, 3 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12

  • Key: UML22-726
  • Legacy Issue Number: 8220
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Use of the term edge(s)is confusing without the appropriate qualifier - "Control" or "Object." Suggest changing edge or edges to ControlEdge(s) and/or ObjectEdge(s) as appropriate

  • Reported: UML 2.0 — Thu, 3 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.9

  • Key: UML22-725
  • Legacy Issue Number: 8219
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Add the multiplicity [1..] to the association. Reword the description of the association parameter:Parameter. It could be interpreted as "the same object node will accept as well as provide parameter values." If that's not the case, i.e., one node accepts and another not provides (which I think is what is meant) then change the "and" to "or." Add OCL notation to the constraints. Constraint [3] needs rewording to something like "Activity parameter nodes must have neither incoming nor outgoing edges" or "Activity parameter nodes must have only incoming or outgoing edges but not both." Wording depends on meaning of constraint. Please clarify semantics to address the following questions. Are input values placed as tokens on input activity parameter nodes at the beginning of flows? Since this node is at the beginning of the flow is that why it has no incoming edges? If it has no incomind edges, how are the values placed on the node? Para 1 of semantics says to see semantics at ObjectNode, Action, and ActivityParamenterNode. This is the semantics section for ActivityParameterNode. Delete that phrase or correct it to the proper reference semantics section. The package CompleteActivities does not show any diagrams with ActivityParameterNode. Delete those package references on pg. 366 or explain why that package is referenced.

  • Reported: UML 2.0 — Thu, 3 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see pages 200/201 of prc/2006-04-01

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.4

  • Key: UML22-716
  • Legacy Issue Number: 8208
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    None of the multiplicities listed with the associations agree with the multiplicities diagrammed. Please correct either figures (probable) or the text. Associations in the text do not mention any subsets that are illustrated in the associated figures. There is no figure given for Activity in the IntermediateActivity Package but several references to that package (pg 343, 345. Please add a figure for that package for Activity or add Activity to one of the IntermediateActivity figures. Figure 211 is not discussed and appears to give no added value to the section unless figure 210 should contain an action to create a Trouble Ticket.

  • Reported: UML 2.0 — Tue, 1 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    The multiplicities only differ in format.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.2

  • Key: UML22-715
  • Legacy Issue Number: 8207
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    According to fig. 187 the associations localPrecondition:Constraint[0..*] and localPostcondition:Constraint[0..*] are subsets of ownedElement. In addition, the multiplicity shown in the fig does not agree with the multiplicity of the text for either association. Para 1, pg 338, sentence 3 appears to have an extra word - tokens - before control tokens. If this isn't extra, then rewrite sentence to make it more clear. The Rationale is a very good description of what an Action is and I suggest placing that paragraph in the Description section. The paragraph for the rationale is not really a rationale or justification--it is a description.

  • Reported: UML 2.0 — Tue, 1 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.2

  • Key: UML22-714
  • Legacy Issue Number: 8206
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Remove duplicate redefines activity statement for association activity between StructuredActivityNode and Activity.

  • Reported: UML 2.0 — Tue, 1 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    See issue 7099 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.8

  • Key: UML22-721
  • Legacy Issue Number: 8215
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Delete the package name "(CompleteStructuredActivities)" after Attributes because ActivityNode is not part of that package according to the figures. Add subsets notations to the associations as shown in the figures. Change the multiplicities of the associations so that the figures and the text agree. Add OCL notation to the constraints

  • Reported: UML 2.0 — Wed, 2 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.7

  • Key: UML22-720
  • Legacy Issue Number: 8214
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Add IntermediateActivities to the section header list of packages. Typo - remove "that" from the first sentence. Add appropriate subsets information to the associations as shown in the diagrams. Make the text and diagram multiplicities agree for the associations. Add OCL notation to the constraints

  • Reported: UML 2.0 — Wed, 2 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.6

  • Key: UML22-719
  • Legacy Issue Number: 8213
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Delete the headers Presentation Option and Style Guidelines as there are none. "In Figure 222, two ways to reach an activity final exist;..." the figure number needs to be changed to 223

  • Reported: UML 2.0 — Wed, 2 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.25

  • Key: UML22-683
  • Legacy Issue Number: 8170
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Add the superclass pointer "(from Kernal)" to fig. 143. No operations are indicated in fig 143. Constraint [2] appears to have an operation name missing or misspelled

  • Reported: UML 2.0 — Fri, 28 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.24

  • Key: UML22-682
  • Legacy Issue Number: 8169
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    If this is not an action why is it discussed in Actions? Move to appropriate Chapter. Wouldn't the action be more like writing to LinkEndDestroyData? If it stays in this chapter please clarify the introduction and description especially explaining how this is different from LinkEndData. Also need to clarify/explain statement "Qualifer values are used in CompleteActions." I don't see a fit with that statement in this section. Attribute in fig 150 is isRemoveDuplicates:Boolean = false so change either the figure or the attribute name in the text. Add OCL notation to Constraints. Constraint [1] typo in "DestroyLinkActiuon" Constraint [2] needs to emphasize that the type UnlimitedNatural is >0. Delete the header Examples as there are none. Typo in Rationale - "LinkeEndDestructionData"

  • Reported: UML 2.0 — Sun, 2 Jan 2000 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 7.3.35

  • Key: UML22-629
  • Legacy Issue Number: 8100
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    The modifications made for multiple languages (Issue 3391) could often be taken by the reader to mean that multiple languages may exist simultaneously in a single opaque expression. An example is the attribute "language:String[0..*] specifies the languages in which the expression is stated" could be interpreted to mean that the expression could be stated in mixed languages. Additionally plurality of verbs and modifying expressions often do not agree with the plurality of the sentence subject. An example of this is "The languages of an opaque expression, is specified, is often..." Subject is the sentence is "languages" so verb should be "are." Furthermore, this statement implies that a single ("an") opaque expression may have more than one language ("languages").

  • Reported: UML 2.0 — Thu, 20 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 8.3.1 - typo

  • Key: UML22-631
  • Legacy Issue Number: 8104
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Typo - Change "Components" to Component in ownedMember:PackageableElement[*] 1st sentence

  • Reported: UML 2.0 — Fri, 21 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 8.3.1

  • Key: UML22-630
  • Legacy Issue Number: 8103
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Add ending guillemets to specification in isIndirectlyInstantiated. Verify that OCL for /provided:Interface[*] is correct. 3rd and 4th lines don't look right to me

  • Reported: UML 2.0 — Fri, 21 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 7.3.34

  • Key: UML22-628
  • Legacy Issue Number: 8099
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    The sentence "The contraint does not apply to the namespace itself, but may also apply to elements in the namespace." would be better if "also" was replaced with "instead."

  • Reported: UML 2.0 — Thu, 20 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 7.3.33

  • Key: UML22-627
  • Legacy Issue Number: 8098
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    I am not an OCL expert (barely a novice) but it seems to me that Constraint [2] is incorrect in stating ">select(ns|ns.name>isEmpty())". Shouldn't that be >select(ns|ns.name>notEmpty()) because the constraint is saying that there is a name and all of the containing namespaces have a names (in other words, all of the containing namespaces are notEmpty).

  • Reported: UML 2.0 — Thu, 20 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 9.3.5

  • Key: UML22-637
  • Legacy Issue Number: 8112
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Add Generalization TypedElement (from Kernal) to fig. 96.

  • Reported: UML 2.0 — Mon, 24 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 9.3.3

  • Key: UML22-636
  • Legacy Issue Number: 8110
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Incorrect page number for reference for "Property" under Description

  • Reported: UML 1.4.2 — Mon, 24 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 9.3.2

  • Key: UML22-635
  • Legacy Issue Number: 8109
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Better choice of word in Changes from UML 1.x would be to change the "of" in last sentence to "that."

  • Reported: UML 2.0 — Mon, 24 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 8.3.1

  • Key: UML22-632
  • Legacy Issue Number: 8105
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Add component icon to fig. 90 <<component>> :ShoppingCart to be consistent with others in diagram

  • Reported: UML 2.0 — Mon, 24 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 9.20.2

  • Key: UML22-633
  • Legacy Issue Number: 8107
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Either delete Issue 7240 note from page, make the correction, or explain why the correction was not made.

  • Reported: UML 2.0 — Mon, 24 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 9.3.1

  • Key: UML22-634
  • Legacy Issue Number: 8108
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Page references are incorrect for "Property" and "StructuredClassifier".

  • Reported: UML 2.0 — Mon, 24 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 9.3.9

  • Key: UML22-638
  • Legacy Issue Number: 8115
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Add generalization for InvocationAction to fig 101 to agree with text on 187

  • Reported: UML 2.0 — Mon, 24 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

InfrastructureLibrary defines, but should not use package merge

  • Key: UML22-561
  • Legacy Issue Number: 7956
  • Status: closed  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    The resolution to 7623 said to replace all «import» by «merge» in Infrastructure Figure 70. These changes should be reversed because they result in InfrastructureLibrary both defining and being defined by package merge making it very difficult to implement UML2.

    Any implementation would have to do these merges by hand in order to have an implementation of Constructs that could be used to implement package merge, EMOF CMOF, or any other UML2 compliance level.

  • Reported: UML 1.4.2 — Wed, 1 Dec 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    closed no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

section 2.10.4.1 detailed semantics of collaborations

  • Key: UML22-557
  • Legacy Issue Number: 7948
  • Status: closed  
  • Source: Anonymous
  • Summary:

    My question concerns section 2.10.4.1 (detailed semantics of collaborations). The last part of the 4th paragraph starts as follows:

    "However, instances of different classifiers can play the role defined by the classifier role, as long as they have all the required properties."

    Allow me to illustrate my interpretation of this section by means of an example.

    Suppose there is a class A with 5 operations, o1, o2, o3, o4 and o5, and there is a class B with 3 operations, identical to o2, o3 and o4.
    Suppose there is a classifier role R in a collaboration, which has A as its base. The role can then specify a subset of the features of A. These features are then required by instances which play the role. Suppose this subset consists of o2 and o3. Then the quote from the spec above claims that instances of B are allowed to play role R. Is this correct so far?

    Then, the spec goes on:

    "Several classifier roles may have the same base classifier, even in the same collaboration, but their features and contained elements may be different subsets of the features and contained elements of the classifier. These classifier roles specify different roles played by (possibly different) instances of the same classifier."

    So, considering again role R from my example, suppose there is now a different classifier role Q, which also has A as its base. Suppose Q specifies o3 and o4 as the required subset of A's features.

    Now the last sentence from the spec quote seems to say that only (possibly different) instances of A can play roles R and Q. This would mean that an instance of B is NOT allowed to play either R or Q, which would contradict my example above.

  • Reported: UML 1.4.2 — Wed, 24 Nov 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 7.3.43

  • Key: UML22-554
  • Legacy Issue Number: 7942
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Notation for a primitive type should be <<primitiveType>> instead of <<primitive>>. That's more consistent to the general usage of keywords that they are identical to the metaclass name

  • Reported: UML 2.0 — Mon, 22 Nov 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Interactions

  • Key: UML22-559
  • Legacy Issue Number: 7950
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    In the description of the Graphic Paths for a Communication Diagram I can
    find no mention of what the lines between the Lifelines correspond to -
    although I did find this in the description of Message: "On Communication
    Diagrams, the Messages are decorated by a small arrow along the connector
    close to the Message
    name and sequence number in the direction of the Message." I assume this
    means that the lines correspond to a Connector model element.

    The Graphic Paths section should be updated to include this information and
    justification added as to why a Connector is needed in order for Messages to
    be shown between two lifelines on a Communication Diagram (this seems an
    overly tight constraint to me).

  • Reported: UML 1.4.2 — Fri, 26 Nov 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 7.3.44 - OCL incorrect

  • Key: UML22-558
  • Legacy Issue Number: 7949
  • Status: closed  
  • Source: Paranor AG ( Earl Waldin)
  • Summary:

    The OCL for the derivation of association /opposite for Property in section 7.3.44, page 126 is incorrect. It's derivation in section "Constraints" on page 126 as given as follows: [1] If this property is owned by a class, associated with a binary association, and the other end of the association is also owned by a class, then opposite gives the other end. opposite = if owningAssociation->notEmpty() and association.memberEnd->size() = 2 then let otherEnd = (association.memberEnd - self)>any() in if otherEnd.owningAssociation>notEmpty() then otherEnd else Set{} endif else Set {} endif I think that the prose "this property is owned by a class" should translate into "class" and not "owningAssociation" in the above OCL. In other words, the prose does not agree with the OCL. So contraint [1] for opposite should read opposite = if class->notEmpty() and ... let ... in if otherEnd.class -> notEmpty() then ... else Set {} endif

  • Reported: UML 1.4.2 — Fri, 26 Nov 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    See issue 6201 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 7.2.8

  • Key: UML22-555
  • Legacy Issue Number: 7946
  • Status: closed  
  • Source: INSA ( Jean Louis Sourrouille)
  • Summary:

    In my opinion, the sentence "When a language is reflective, there is no need to define another language to specify its semantics." is false. Any natural language is reflective. However, just take a dictionary of a language that you don't know, you will not understand anything. In fact, the semantics of UML is described in english, not in UML, which explains that you can understand the metamodel.

  • Reported: UML 1.4.2 — Tue, 23 Nov 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super Basic Interactions

  • Key: UML22-560
  • Legacy Issue Number: 7951
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    Basic Interactions includes SendOperationEvent whose superclass is
    MessageEvent, which is in CommonBehaviors::Communications.

    The problem is that the Basic Interactions package is in Level 1, but
    CommonBehaviors::Communications is in Level 2.

    The same is true for SendSignalEvent. In fact Event itself is also in
    Communications so there's a problem with the whole set of Event subtypes
    defined in BasicInteractions.

    Also BasicActions::SendSignalAction references Communications::Signal

  • Reported: UML 1.4.2 — Fri, 26 Nov 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Discussion: This issue was fixed in release 2.1.. Revised Text: N/A Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

An observed time value must be written into a structural feature

  • Key: UML22-562
  • Legacy Issue Number: 7967
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    TimeObservationAction is a specialized WriteStructuralFeatureAction. An observed time value must be written into a structural feature. If modeling activities with that kind of action it would be useful to be able to write the time value to a variable instead of a structural feature. The time value is often used temporarily

  • Reported: UML 2.0 — Fri, 3 Dec 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Discussion: These actions were removed as part of an earlier fix. Revised Text: N/A Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Classes

  • Key: UML22-556
  • Legacy Issue Number: 7947
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    I see a problem in the definition of the InstanceSpecification of a new primitive like Real. The value is specified by a ValueSpecification. The UML metamodel of ValueSpecifications reflects the predefined primitive types of UML: LiteralInteger, LiteralString, and so on. This is an indirect dependency from the Kernel package to the AuxiliaryConstructs package. That dependency direction shouldn't be allowed. How to specify a value specification for a primitive type Real? I think that we need LiteralReal to do that.

  • Reported: UML 1.4.2 — Wed, 24 Nov 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    See issue 8069 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.34

  • Key: UML22-691
  • Legacy Issue Number: 8178
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Association result:OutputPin[1..1] is Specialized from Action:output according to fig. 155. Rewrite Constraint [4] as "The type of the object input pin is the type of the association class that owns the association end." Complete the Semantics section. Delete the header Examples as there are none

  • Reported: UML 2.0 — Fri, 28 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.33

  • Key: UML22-690
  • Legacy Issue Number: 8177
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Delete Examples header as there are none

  • Reported: UML 2.0 — Fri, 28 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    See issue N/A for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.31

  • Key: UML22-689
  • Legacy Issue Number: 8176
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Fig 153 shows that the association result:OutputPin[1..1] is subsetted. Add OCL notation for constraint [1]. I believe the wording of constraint [1] might be better as: "The type of the result output pin is the type of the classifier."

  • Reported: UML 2.0 — Fri, 28 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.26

  • Key: UML22-684
  • Legacy Issue Number: 8171
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    The generalization in figure 142 doesn't agree with that mentioned in the section. Attributes are both ordered. Delete header Examples as there are none

  • Reported: UML 2.0 — Fri, 28 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    Example header is duplicate of 8155.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.27

  • Key: UML22-694
  • Legacy Issue Number: 8182
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Delete the Examples header as there are none

  • Reported: UML 2.0 — Mon, 31 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    See issue 8155 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.36

  • Key: UML22-693
  • Legacy Issue Number: 8181
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Add OCL notation to constraint [2]. Delete Examples header as there are none

  • Reported: UML 2.0 — Mon, 31 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    See issue 6452, 8155 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.28

  • Key: UML22-686
  • Legacy Issue Number: 8173
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Typos - In description delete provide and change accept to accepts. Add OCL notation to Constraints. Delete header Examples as there are none.

  • Reported: UML 2.0 — Fri, 28 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    OCL issue is a duplicate of 6452. Header issue is a duplicate of 8155.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.29

  • Key: UML22-687
  • Legacy Issue Number: 8174
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Please clarify the relationship and differences between QualifierValue, LinkEndCreationData, LinkEndData, and LinkEndDestructionData especially since QualifierValue, LinkEndData, and LinkEndCreationData are all in the CompleteActions package. Constraint [2] change "are" to "is" Delete Examples header as there are none.

  • Reported: UML 2.0 — Fri, 28 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.35

  • Key: UML22-692
  • Legacy Issue Number: 8180
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Add the specialized statement needed for the association result"OutputPin[1..1] as shown in fig. 155. Add semantics or delete the header. Delete the Examples header as there are none.

  • Reported: UML 2.0 — Mon, 31 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    See issue 8155 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.30

  • Key: UML22-688
  • Legacy Issue Number: 8175
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Association exception:InputPin[1..1] is subsetted according to fig 158. Delete Examples heading as there are none

  • Reported: UML 2.0 — Fri, 28 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    Headers issue is duplicate with 8155.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.27

  • Key: UML22-685
  • Legacy Issue Number: 8172
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Description should mention the multiplicity expressed in fig. 143. Delete the header Examples as there are none

  • Reported: UML 2.0 — Fri, 28 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Optional inputs

  • Key: UML22-588
  • Legacy Issue Number: 8037
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    When does an action start when all its inputs are optional?

  • Reported: UML 2.0 — Thu, 30 Dec 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Preserve order in result of read actions

  • Key: UML22-587
  • Legacy Issue Number: 8036
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The semantics of the various read actions (ReadStructuralFeatureAction, etc) should specify that the order of the retrieved collections is preserved in the values of the output pin.

  • Reported: UML 2.0 — Thu, 30 Dec 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Interactions chapter refers to ActivityInvocations

  • Key: UML22-582
  • Legacy Issue Number: 8030
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Interactions chapter refers to ActivityInvocations The Interactions chapter still refers to ActivityInvocations, which was only in an intermediate draft of the original submission. I think it should be CallBehaviorAction or CallOperationAction, not sure.

  • Reported: UML 2.0 — Thu, 30 Dec 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    The term ActivityInvocations only appears once, on page 563 of ptc/04-10-02.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Destruction semantics in StructuredClassifier

  • Key: UML22-583
  • Legacy Issue Number: 8031
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Destruction semantics in StructuredClassifier The destruction semantics in StructuredClassifier should include destruction of links created due to connectors between noncomposite properties

  • Reported: UML 2.0 — Thu, 30 Dec 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Figure 119 missing multiplicity

  • Key: UML22-585
  • Legacy Issue Number: 8033
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Figure 119 missing multiplicity. Figure 119 (Connectors and parts in a structure diagram) is missing a multiplicity on the right side of the connetor

  • Reported: UML 2.0 — Thu, 30 Dec 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Link maintenance in StructuredClassifier

  • Key: UML22-584
  • Legacy Issue Number: 8032
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Link maintenance in StructuredClassifier The semantics of StructuredClassifier should indicate that links are created/destroyed according to connectors when objects are added/removed from the connected properties. Extend Create/Destroy/ClearLinkAction and Add/Remove/ClearStructuralFeature with boolean properties that "turn on" this semantics.

  • Reported: UML 2.0 — Thu, 30 Dec 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see ptc/2006-04-01 p 94

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ObjectNode, constraint 1 In ObjectNode

  • Key: UML22-591
  • Legacy Issue Number: 8040
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    ObjectNode, constraint 1 In ObjectNode, Constraints (Complete Activities), the first constraint regarding upperbound should be removed. The size of the object node buffers can be any size.

  • Reported: UML 2.0 — Thu, 30 Dec 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

DestroyObjectAction semantics

  • Key: UML22-590
  • Legacy Issue Number: 8039
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Clarify the "owns" language in DestroyObjectAction to mean the objects related by composite associations

  • Reported: UML 2.0 — Thu, 30 Dec 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

IsReadOnly constriant

  • Key: UML22-589
  • Legacy Issue Number: 8038
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    done) IsReadOnly constriant Constraint on StructuralFeature::isReadOnly: if true and there is no intialization value, then the lower multiplicity must be zero.

  • Reported: UML 2.0 — Thu, 30 Dec 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Notation for method

  • Key: UML22-586
  • Legacy Issue Number: 8035
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Need a notation for instances of the specification/method metaassociation (Figure 311).

  • Reported: UML 2.0 — Thu, 30 Dec 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    See issue 6150 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.1

  • Key: UML22-659
  • Legacy Issue Number: 8145
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Add that retureInformation:OutputPin[1..1] is a specialization or subsets output as shown in fig. 152. Add OCL expression for constraint 1 or that the constraint cannot be expressed in OCL. Constraint [3] contains a typo in the 1st line "isUnmrashall" should be "isUnmarshall"

  • Reported: UML 2.0 — Thu, 27 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    Missing OCL is a duplicate of 6452.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.1

  • Key: UML22-658
  • Legacy Issue Number: 8144
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Typos and rewording requests Basic Concepts para 2 - Change "Behavior" to "Behaviors" Basic Concepts para 3 - Change "Operations" to "Operation calls" Intermediate Concepts para 1 sentence 1 - change "various action primitive actions" to "various primitive actions" Intermediate Concepts para 1 sentence 3 - rewrite to something like: S"pecifically, a single primitive action is defined so that it either carries out a computation or accesses object memory, but never both." Intermediate Concepts para 6 sentence 4 - Add verb in "multiplicity bound ignored" to "multiplicity bound is ignored" Intermediate Concepts para 6 last sentence - replace the pronoun "these" with the appropriate noun - I don't know if "these" refers to the points where the lower multiplicity bound is ignored or the points where the modeler has determined that the lower multiplicity bound is enforced. Intermediate Actions, Read Write Actions (page 230) para 3 sentence 1 - needs rewording: "ranging from" implies a "to" something which is not listed; "implementation-dependent" is a modifiying phrase but I don't know what it is modifying (the following comma may not be needed). My interpretation of the sentence meaning is: "Value specificationc cover various expressions ranging from implementation-dependent constants to complex expressions with possible side-effects."

  • Reported: UML 2.0 — Thu, 27 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 7.3.15

  • Key: UML22-621
  • Legacy Issue Number: 8092
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    I am confused by the statements that say "the name of the imported element must be qualified in order to to used and is not added to the importing namespace." Add a statement to clarify that if the name is qualified, how the element is referenced by another element.

  • Reported: UML 2.0 — Wed, 19 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 7.3.12

  • Key: UML22-620
  • Legacy Issue Number: 8091
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Issues 6164 and 6159 still have not been addressed. Figure 36 reads that the client CarFactory is dependent upon the supplier Car which is not what the text states.

  • Reported: UML 2.0 — Wed, 19 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    The fix was not completed. Instead of VehicleType the text should refer to CarFactory.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 7.3.32 Page: 96-99

  • Key: UML22-626
  • Legacy Issue Number: 8097
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    The document defines multiplicity as an "inclusive interval of non-negative integers" which is the same thing as Unlimited Naturals, but in several other places the "non-negative" qualifier for integer is left off leaving only integer as the definition of the lower bound and integers may be negative. Examples are Additional Operations [4]and in the second paragraph of semantics. Additional Operations [2] OCL is incorrect if the type for includesCardinality(c:Integer) is Integer because the third line says that includesCardinality = (lowerBound() <= C) and (UpperBound () >= C). Everywhere else it is stated that the upperBound is UnlimitedNatural NOT an integer. Remove the word "is" following specification in the second sentence of the first paragraph under Notation.

  • Reported: UML 2.0 — Thu, 20 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 7.3.32

  • Key: UML22-625
  • Legacy Issue Number: 8096
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Since the lower bound of multiplicity can not be negative by definition, shouldn't the type of /lower MultiplicityElement be UnlimitedNatural? Also, /upper is missing from the list of attributes

  • Reported: UML 2.0 — Thu, 20 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 7.3.22

  • Key: UML22-624
  • Legacy Issue Number: 8095
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Figures 50 and 51 cause me confusion because Fig. 50 uses as the classifier name a type (String). Yet Fig. 51 shows "Other properties of the feature, such as type" on the second line of the slot streetNumber:Integer = 381. Should the classifier name in Fig. 50 be a type or something more like myAddress. Please clarify, especially that there is a difference, as indicated by the naming convertion, between the instance specification and the feature shown in the slot.

  • Reported: UML 2.0 — Wed, 19 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 6.5.1: Error in example

  • Key: UML22-616
  • Legacy Issue Number: 8086
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Error in example. Text for /isComposite : Boolean A state with isComposite = True is said to be a composite state. A composite state is a state that contains at leas one region> BUT the OCL says IsComposite = (region >1) which translates to is greater than one. Use the is equal to or greater than symbol or change the number to 0.

  • Reported: UML 2.0 — Fri, 14 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 7.3.10

  • Key: UML22-619
  • Legacy Issue Number: 8090
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    If constraind elements are those elements required to evaluate the constraint spedividation, why is the multiplicity for the specification: ValueSpecification[0..1]? Shouldn't the multiplicity be 1? If not, please clarify.

  • Reported: UML 2.0 — Tue, 18 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 7.3.20

  • Key: UML22-622
  • Legacy Issue Number: 8093
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Text says that Manager constitutes one GeneralizationSet but Figure 42 uses the word Employee. Please correct

  • Reported: UML 2.0 — Wed, 19 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    The submitter is correct. This is a bug.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 7.3.8

  • Key: UML22-618
  • Legacy Issue Number: 8089
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    The association package:Package[0..1] is listed as being an association of Classifier. However, the only figure to diagram this association is Figure 14 and the association is from Type not Classifier.

  • Reported: UML 2.0 — Fri, 14 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Stereotypes applying in UML 2.0

  • Key: UML22-623
  • Legacy Issue Number: 8094
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    I have some questions regarding stereotypes using in UML 2.0.

    1. How to declare user defined stereotype in the model? Should class with stereotype <<metaclass>> and metaclass name be created in the model? How to declare stereotype <<metaclass>>?

    2. Is some relationship between stereotyped model element and stereotype instance exist? Where stereotype instance should be created (contained) and how model element can collect all applied stereotypes?

  • Reported: UML 1.4.2 — Mon, 17 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 7.3.3

  • Key: UML22-617
  • Legacy Issue Number: 8088
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Clarification of subsetting is still confusing to me. The Note has an incomplete sentence for the last "sentence." I believe you need to remove the starting word "If."

  • Reported: UML 2.0 — Fri, 14 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.20

  • Key: UML22-678
  • Legacy Issue Number: 8164
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Superclass generalization is not written on fig. 144. Association argument:InputPin[0..*] multiplicity does not agree with fig. 144. Association argument:InputPin[0..*]in fig. 144 says it is ordered and subsets input. Add statements to the definition of the association. Under Constraints say none.

  • Reported: UML 2.0 — Thu, 27 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.19

  • Key: UML22-677
  • Legacy Issue Number: 8163
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Bold the heading Associations. Delete the heading Examples as there are none. Constraint [2] of 11.3.18 says that input pin has no type but there is no such constraint mentioned for 11.3.19 (which is the section describing inputPin.

  • Reported: UML 2.0 — Thu, 27 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.22 -- significant revision?

  • Key: UML22-680
  • Legacy Issue Number: 8166
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    If LinkEndCreationData is not an action, should it be in this part? Wouldn't the action be to read data from this element or write data to this element? LinkEndCreationData is found in two packages but the discussion/text only addresses its use from the IntermediateActions with no mention of its use in CompleteActions. If this section is to stay in this part then rewrite introduction, description, associations, constraints and semantics to address its use/application in CompleteActions. OCL notation for Constraint[2] does not say that the UnlimitedNatural must be >0 as is stated in the definition of the association insertAt:InputPin. Too many closing ")" for the number of opening "(" in Constraint [2] OCL notation Delete the Examples header as there are none.

  • Reported: UML 2.0 — Fri, 28 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.21

  • Key: UML22-679
  • Legacy Issue Number: 8165
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Associated figures 148 & 150 do not diagram an direct association between LinkAction and InputPin. Please clarify, add to figures, or delete the association from the section. Constraint [2] OCL notation has an extra ending ) Semantics need to be rewritten clarifying how LinkAction and inputPin are associated. None of the figures containing the classifier LinkAction show an association with a multiplicity of 1..1. Delete heading Examples as there are none.

  • Reported: UML 2.0 — Thu, 27 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.40

  • Key: UML22-696
  • Legacy Issue Number: 8185
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Typo - removeAt:InputPin [0..1] Unlimitednatural needs correcting. Add specialization to association removeAt:InputPin [0..1] as shown in fig. 147. Constraint [1] needs OCL notation. Add that the Unlimited Natural number must be >0 to the constraint definition. Delete Examples header as there are none. Last statement in the Changes from previous UML is not supported by fig. 147. There is no other mention of RemoveAttributeValusAction in this version of the Superstructure

  • Reported: UML 2.0 — Mon, 31 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    Example header is duplicate of 8155. OCL is duplicate of 6346.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.38

  • Key: UML22-695
  • Legacy Issue Number: 8183
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Delete the Examples header as there are none

  • Reported: UML 2.0 — Mon, 31 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    See issue 8155 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.23 -- significant revision?

  • Key: UML22-681
  • Legacy Issue Number: 8167
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    I read and understand little difference between LinkEndData and LinkEndCreationData or LinkEndDestructionData. If none of these elements are actions what are they doing in Actions? Wouldn't the action be to read to or write from these elements? Add the package CompleteActions name to the Description and mention that LinkEndData identifies one end of a link to be destroyed. Add "(IntermediateActions)" to the first Constraint header. I'm not certain that constraint (IntermediateActions) [3] multiplicity agrees with the association value:InputPin[0..1] mulitplicity The instruction under semantics to see LinkAction and its children needs to be rewritten. Through following all of the instructions to see different sections, I finally found semantics information in ReadLinkAction, CreateLinkAction, and DestroyLinkAction. Delete header Examples as there are none.

  • Reported: UML 2.0 — Fri, 28 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.14

  • Key: UML22-672
  • Legacy Issue Number: 8158
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    In description, change "positive integer" to "unlimitedNumber greater than 0" Delete Examples hearder as there are none

  • Reported: UML 2.0 — Thu, 27 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    Example header is duplicate of 8155.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.18

  • Key: UML22-676
  • Legacy Issue Number: 8162
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    I am confused by the request of issue 7179 to replace 'input' by 'target' in both constraints and then seeing 'input' replaced by 'target' only in the OCL notation. Please clarify. I am also confused by constraint [2] since part 11.3.19 InputPin says nothing about the type of inputPin. Delete the header Examples as there are none.

  • Reported: UML 2.0 — Thu, 27 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.16

  • Key: UML22-674
  • Legacy Issue Number: 8160
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Constraint 1 says that the classifier cannot be abstract but fig. 146 shows the Classifier name in italics. Delete header Examples as there are none

  • Reported: UML 2.0 — Thu, 27 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.17

  • Key: UML22-675
  • Legacy Issue Number: 8161
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Change "positive integer" in the Description section to "unlimitedNatural >0" Delete the header Example as there are none

  • Reported: UML 2.0 — Thu, 27 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.15

  • Key: UML22-673
  • Legacy Issue Number: 8159
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Delete the header Examples as there are non

  • Reported: UML 2.0 — Thu, 27 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    See issue 8155 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.53

  • Key: UML22-709
  • Legacy Issue Number: 8198
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Put a line feed before Notation header. Delete Examples header as there are none

  • Reported: UML 2.0 — Mon, 31 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.42

  • Key: UML22-708
  • Legacy Issue Number: 8197
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    The text does not agree with fig. 152. Correct either the figure or the text. Fig shows that ReplyAction generalizes Actions (from BasicActions), that the association replyToCall is to CallEvent not Trigger, that the association replyValue is to InputPin not OutputPin and that this association subsets input from Actions, that the association returnInformation:InputPin subsets input from Actions. Constraint [1] uses the word "trigger" but figure would indicate that "call event" would be more correct. This constraint needs OCL notation. Semantics really don't agree with figure. [2] needs the word "to" added after meaning and the word trigger is still used when the figure would indicate call even is mor appropriate.

  • Reported: UML 2.0 — Mon, 31 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    OCL is duplicate with 6346. Figure 152 should use Trigger instead of CallEvent.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.43

  • Key: UML22-698
  • Legacy Issue Number: 8187
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Association target:inputPin[1] subsets input from BasicActions according to figure 145

  • Reported: UML 2.0 — Mon, 31 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.41

  • Key: UML22-697
  • Legacy Issue Number: 8186
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    The association removeAt:InputPin[0..1] is subsets input from Actions according to fig. 157. Correct typo in Constraint [1] "removaeAt". Add OCL notation for the constraint. Constraint also needs to mention that the Unlimited Natural must be >0. Typo - Last line of para 1 of semantics - change "support" to "supports" Delete header Examples as there are none

  • Reported: UML 2.0 — Mon, 31 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.2

  • Key: UML22-660
  • Legacy Issue Number: 8146
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Add the specialization (subsets) statement to result:OutputPin[0..*] as shown in fig. 152. Add OCL statements to Constraints. Constraint [2] needs clarification. Last part of sentence is confusing. Typo - Semantics, para 2, sentence 1 - Change "unmarshall" it "isUnmarshall"

  • Reported: UML 2.0 — Thu, 27 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    Missing OCL is a duplicate of 6452.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.9

  • Key: UML22-667
  • Legacy Issue Number: 8153
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Add OCL notation to Constraints. Delete Examples heading as there are none

  • Reported: UML 2.0 — Thu, 27 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    See issues 8155 and 6346 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.8

  • Key: UML22-666
  • Legacy Issue Number: 8152
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Fig. 144 shows a default for isSynchronous:Boolean = true but this is not indicated in the Attributes section. Associations result:OutputPin[0..*] multiplicity does not match fig. 144; change the description to: "An ordered list of output pins..." and add a statement about the specialization or subsets. Add OCL notation to Constraints.

  • Reported: UML 2.0 — Thu, 27 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    Multiplicity is in proper format. Lists are always ordered. OCL is duplicate with 6346.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.12

  • Key: UML22-670
  • Legacy Issue Number: 8156
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Delete Examples header as there are none

  • Reported: UML 2.0 — Thu, 27 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    See issue 8155 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.11

  • Key: UML22-669
  • Legacy Issue Number: 8155
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Delete Examples header as there are none

  • Reported: UML 2.0 — Thu, 27 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Discussion: Fixed as part of a previous copy-edit pass of the spec. Revised Text: N/A Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.10

  • Key: UML22-668
  • Legacy Issue Number: 8154
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Add OCL notation to Constraints. Typo - place a period at the end of the definition of the operation:Operation[1] association Add a subsets or specialization statement to the association target:InputPin[1] as is shown in fig. 144

  • Reported: UML 2.0 — Thu, 27 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    OCL is duplicate with 6346

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.6

  • Key: UML22-664
  • Legacy Issue Number: 8150
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    It seems to me that the OCL statement does not specify that the UnlimitedNatural needs to be >0. Add "The insertion point is ignored when replacing all values." as last sentence in para 2 of Semantics. Remove the header Examples as there are none.

  • Reported: UML 2.0 — Thu, 27 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.7

  • Key: UML22-665
  • Legacy Issue Number: 8151
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Add OCL statements as appropriate for Constraints. Typo - Need a couple of line feeds before the header Notation

  • Reported: UML 2.0 — Thu, 27 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    Missing OCL is a duplicate of 6452.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.5

  • Key: UML22-663
  • Legacy Issue Number: 8149
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    It seems to me that the OCL statement does not specify that the UnlimitedNatural needs to be >0. Remove the header Examples as there are none

  • Reported: UML 2.0 — Thu, 27 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.13

  • Key: UML22-671
  • Legacy Issue Number: 8157
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Delete Examples header as there are none.

  • Reported: UML 2.0 — Thu, 27 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    See issue 8155 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Connector multiplicity notation

  • Key: UML22-579
  • Legacy Issue Number: 8027
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Connector multiplicity notation The notation section of ConnectorEnd says multiplicities shown on connector lines represent the multiplicities of both the association and the connector: These adornments specify properties of the association typing the connector. The multiplicity indicates the number of instances that may be connected to each instance of the role on the other end. But these multiplicity can be different, and have separate elements in the metamodel.

  • Reported: UML 2.0 — Thu, 30 Dec 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Associations between interfaces

  • Key: UML22-578
  • Legacy Issue Number: 8025
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Associations between interfaces The wording of the caption in Figure 56 implies that association between interfaces have implication on required and provided interfaces. My udisjoinnderstanding from mailing list discussion is that this is only an example, not a semantics. Should be clarified in the caption that this is an example of applying associations to interfaces.

  • Reported: UML 2.0 — Thu, 30 Dec 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

create dependency Figures 103 and 121

  • Key: UML22-580
  • Legacy Issue Number: 8028
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    create dependency 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 2.0 — Thu, 30 Dec 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Transitivity in composition

  • Key: UML22-573
  • Legacy Issue Number: 8015
  • Status: closed  
  • Source: NIST ( Mr. Evan K. Wallace)
  • Summary:

    Transitivity in composition: The semantics of Association say composite associations are transitive. Transitivity violates the single-owner rule for composition mentioned in the same paragraph. It also requires that the association have the same class on both ends.

  • Reported: UML 2.0 — Thu, 30 Dec 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

underlined association name

  • Key: UML22-581
  • Legacy Issue Number: 8029
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    underlined association name Figures 120 and 121 underline the association names, which doesn't seem consistent with the notation for instances in Figure 21.

  • Reported: UML 2.0 — Thu, 30 Dec 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    The notation for instance specification seems clear that if an association name is shown on an instance specification, that this name would be underlined, see p.84: “It is not necessary to show an underlined name where it is clear from its connection to instance specifications that it represents a link and not an association.” (The diagram example in that section does not show the name.) Therefore, the above two figures are consistent with the notation defined for instance specifications. One could eliminate the association name, if so desired. Revised Text: Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Classes

  • Key: UML22-577
  • Legacy Issue Number: 8021
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Specializing one association end Suppose we have a class diagram like this: <pre>
    aend bend
    A ----------------------------- B
    ^ ^

     
     
     
     
    subbend
    {subsets bend}

    SubA -------------------------- SubB

    </pre>
    What metarelation is used between the lower left end and the upper left end (aend)? It is not redefined or subsetted.

  • Reported: UML 2.0 — Thu, 30 Dec 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Add concept "StateInvariant"

  • Key: UML22-572
  • Legacy Issue Number: 7996
  • Status: closed  
  • Source: SINTEF ICT ( Richard Torbjørn Sanders)
  • Summary:

    Add concept "StateInvariant" in figure, with arrows to "mystate" and "

    {Y.p == 15}

    "

  • Reported: UML 2.0 — Sat, 18 Dec 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Pin/parameter matching constraints

  • Key: UML22-574
  • Legacy Issue Number: 8017
  • Status: closed  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    Pin/parameter matching constraints: The wording for CallAction, constraints 2 and 3 should be consistent with the wording of constraint 3 for CallBehaviorAction and CallOperationAction

  • Reported: UML 2.0 — Thu, 30 Dec 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Classes

  • Key: UML22-576
  • Legacy Issue Number: 8019
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Dependency should specialize source/target On Dependency, client and supplier should specialize source and target from DirectedRelationship. Source/target are derived unions, so can't be used otherwise

  • Reported: UML 2.0 — Thu, 30 Dec 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: CB/ACT

  • Key: UML22-575
  • Legacy Issue Number: 8018
  • Status: closed  
  • Source: MEGA International ( Mr. Antoine Lonjon)
  • Summary:

    Matching by order difficult to implement Matching by order of the parameters of methods and operations and pins and parameters is difficult to implement in relation database implementations.

  • Reported: UML 2.0 — Thu, 30 Dec 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.9

  • Key: UML22-723
  • Legacy Issue Number: 8217
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Add the multiplicity [1..] to the association. Reword the description of the association parameter:Parameter. It could be interpreted as "the same object node will accept as well as provide parameter values." If that's not the case, i.e., one node accepts and another not provides (which I think is what is meant) then change the "and" to "or." Add OCL notation to the constraints. Constraint [3] needs rewording to something like "Activity parameter nodes must have neither incoming nor outgoing edges" or "Activity parameter nodes must have only incoming or outgoing edges but not both." Wording depends on meaning of constraint. Please clarify semantics to address the following questions. Are input values placed as tokens on input activity parameter nodes at the beginning of flows? Since this node is at the beginning of the flow is that why it has no incoming edges? If it has no incomind edges, how are the values placed on the node? Para 1 of semantics says to see semantics at ObjectNode, Action, and ActivityParamenterNode. This is the semantics section for ActivityParameterNode. Delete that phrase or correct it to the proper reference semantics section. The package CompleteActivities does not show any diagrams with ActivityParameterNode. Delete those package references on pg. 366 or explain why that package is referenced.

  • Reported: UML 2.0 — Thu, 3 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.1

  • Key: UML22-722
  • Legacy Issue Number: 8216
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    If BasicActivities and StructuralActivities are orthogonal, why does the structural level require the basic level? This concept is not supported by fig. 175. Please forgive me if I've already sent this one in, but I hadn't marked my comment as submitted.

  • Reported: UML 2.0 — Thu, 3 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    See issue 8202 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 8.3.4

  • Key: UML22-641
  • Legacy Issue Number: 8120
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Correct statement under Constraints to read "No additional constraints."

  • Reported: UML 2.0 — Mon, 24 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 9.3.10

  • Key: UML22-640
  • Legacy Issue Number: 8117
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    I can't find appropriate figure for the generalization "Parameter (from Kernel, AssociationClasses)". Add appropriate OCL notation to Constraints

  • Reported: UML 2.0 — Mon, 24 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 10.3.1

  • Key: UML22-647
  • Legacy Issue Number: 8132
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Figure 124 does not show what the Generalizations "Classifier (from Kernel, Dependencies, PowerTypes)" indicates, or the association ownedProperty:Property, or the multiplicity listed for attribute filename:String[0..1]

  • Reported: UML 2.0 — Tue, 25 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 10.3.1

  • Key: UML22-648
  • Legacy Issue Number: 8133
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Typo in 1st line of Notation. In Semantics, clarify which Appendix to see

  • Reported: UML 2.0 — Tue, 25 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    Both matters raised by this issue represent valid editorial clarifications to the text.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.13

  • Key: UML22-644
  • Legacy Issue Number: 8129
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Under Notation change "name of the part" to rolename to differentiate it from the name of the part (as in composition).

  • Reported: UML 2.0 — Tue, 25 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.13

  • Key: UML22-645
  • Legacy Issue Number: 8130
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Fig 121 uses the word "make" for the constructor. Unfortunately, this word could be misconstrued to be a noun and refer to the make of the car (Volvo, Audie, Ford) instead of the verb it is intend to be. Suggest changing "make" to "assemble."

  • Reported: UML 2.0 — Tue, 25 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 9.3.13

  • Key: UML22-643
  • Legacy Issue Number: 8128
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Associations need derived symbol added to role:ConnectableElement and /part:Property (as shown in fig. 95), a statement that role is derived, and multiplicities added to all associations (as shown in fig. 95).

  • Reported: UML 2.0 — Tue, 25 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see ptc/2006-04-01 page 140

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 9.3.9

  • Key: UML22-639
  • Legacy Issue Number: 8116
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Add OCL notation to Constraints. Notation says to see "CallOperationAction" for an example, but no examples are given in that section

  • Reported: UML 2.0 — Mon, 24 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 9.2

  • Key: UML22-646
  • Legacy Issue Number: 8131
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    There is no explanation in the chapter or the section on StrucutredActivities as to why two StructuredActivities packages are drawn, both <<merge>> in fig. 94. Please clarify somewhere

  • Reported: UML 2.0 — Tue, 25 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 9.3.12

  • Key: UML22-642
  • Legacy Issue Number: 8127
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    In Examples, the reference page number to SturcturedClassifier is incorrect

  • Reported: UML 2.0 — Tue, 25 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 7.4.1

  • Key: UML22-615
  • Legacy Issue Number: 8085
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Multiplicity is non-negative so shouldn't the lower bound be typed as an unlimited natural (a non-negative number) instead of an integer which can be negative? The upper bound is typed as an unlimited natural. This question also applies to Infrastructure (ptc/03-09-15, sections 9.11 and 9.12).

  • Reported: UML 2.0 — Wed, 12 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 7.3.6

  • Key: UML22-614
  • Legacy Issue Number: 8084
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    There appears to be a conflict between the Superstructure VisibilityKind and the Infrastructure VisibilityKind (ptc/03-09-15, section 9.20.2, pg 93). Superstructure lists the four found in vers 1.5 of UML but Infrastructure lists only public and private. What is the correct enumeration for VisibilityKind? Has the Superstructure refined the Infrastructure? If so, a clarification that Superstructure VisibilityKind is refining that from Infrastructure would be helpful.

  • Reported: UML 2.0 — Wed, 12 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.8.3

  • Key: UML22-610
  • Legacy Issue Number: 8080
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Figure 98 shows an merged package P::A in the source package S. I do not see how P::A got merged when Figure 97 shows no merge between target P and source S or between source R and source S. The text says that packages P and Q are being merged by package R while package S merges on package Q (with the open ended arrow indicating Q as the target but the keyword <<merge>> at the end nearest S. The statement above Figure 98 says the transformed packages R and Q are shown but the figure has the packages labeled R and S. There appears to be no merge connection between P and S but a subpackage from P appears in S. The text and figures are very confusing and need clarification

  • Reported: UML 2.0 — Fri, 7 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.6.1

  • Key: UML22-609
  • Legacy Issue Number: 8079
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    The each sentence in the third paragraph under semantics appears to have an incorrect "and" in them. I believe the and should be replaced by the word "or" in each sentence. The second paragraph seems to have a couple of misplaced hyphens.

  • Reported: UML 2.0 — Thu, 6 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 7.3.3

  • Key: UML22-613
  • Legacy Issue Number: 8083
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Second sentence in second paragraph under description is somewhat confusing. "The constraint does not necessilarily apply to the namespace itself, but may also apply to the elements in the namespace." The use of the word "also" bothers me. Do you mean "instead" rather than also. Wouldn't it make more sense, in the context of the first part of the sentence, that the constraint could instead apply to the elements in the namespace rather than the namespace. If you mean that a constraint could apply to both or the namespace or the element in the namespace then the statement needs to be reworded

  • Reported: UML 2.0 — Wed, 12 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    The text does need to be reworded to eliminate such confusion.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 13.1.5

  • Key: UML22-612
  • Legacy Issue Number: 8082
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Figure 115 shows the <<enumeration>> Color, but shouldn't that be labeled as ColorKind as shown in Figure 88 and specified in Conventions and Typography in 8.5?

  • Reported: UML 2.0 — Mon, 10 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.5

  • Key: UML22-607
  • Legacy Issue Number: 8076
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    The phrase that starts "These constructs that are used..." is not a complete sentence and confusing. I believe that the word "that" needs to be deleted

  • Reported: UML 2.0 — Wed, 5 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

search for referenced item -- Section: 11.3.4

  • Key: UML22-606
  • Legacy Issue Number: 8075
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    A reference is made to the Operations Diagram in the Description section but no figure number (93) or page number (146) is given. It would save time and greatly decrease the frustration factor for this reader if I didn't have to search for the referenced item.

  • Reported: UML 2.0 — Wed, 5 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Figure 68

  • Key: UML22-603
  • Legacy Issue Number: 8072
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Figure 68 does not show the

    {composite}

    notation for the attribute ownedType: Type

  • Reported: UML 2.0 — Tue, 4 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

methods not defined under attributes

  • Key: UML22-602
  • Legacy Issue Number: 8070
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    In all previous sections when a diagram shows a named association, the text defines these under the heading Associations. All of a sudden you've changed methods and are not defining these under attributes. A clarification as to why this is done would help those of us who are not UML experts.

  • Reported: UML 2.0 — Tue, 4 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 13.1.2

  • Key: UML22-611
  • Legacy Issue Number: 8081
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Additional option [1] says that the query lowerBound () returns the lower bound of the multiplicity as an Integer. Why is the type Interger used instead of the type UnlimitedNatural? An integer can be a negative number but not so with naturals. My understanding is that multipliticity is not allowed to be less than 0.

  • Reported: UML 2.0 — Mon, 10 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.3

  • Key: UML22-605
  • Legacy Issue Number: 8074
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    The description refers to the Classifiers Diagram but no figure number (Figure 84) or page number (page 127) is given. It would greatly facilitate the reading if the user did not have to search for this. In section 6.3 on How to Read this Specification, it is stated that extensive cross-references are given. This specification would be better if more cross-references were given, especially when a figure or section that is found elsewhere in the document is referenced. I sent in a request to clarify Chapter/Section 10.2. I have since found that an excellent clarification exists in Chapter 11.3. If this had be referenced in Chapter 10.2 it would have saved this reader several hours of confusion and frustration

  • Reported: UML 2.0 — Wed, 5 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.1

  • Key: UML22-604
  • Legacy Issue Number: 8073
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    The last phrase in the sixth paragraph from the top which starts with "For n-ary associations..." is an incomplete prepositional phrase and the meaning is unclear

  • Reported: UML 2.0 — Tue, 4 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Actor is a specialized Classifier and not BehavioredClassifier

  • Key: UML22-608
  • Legacy Issue Number: 8078
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Actor is a specialized Classifier and not BehavioredClassifier. Therefore an actor is not allowed to realize an interface. I propose to inherit Actor from BehavioredClassifier. It is useful to model actors with interfaces. The actor/subject communication requires the definition of signals/messages that can be sent from the subject to an actor.

  • Reported: UML 2.0 — Thu, 6 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see ptc/2006-04-01 p 108/109

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.1

  • Key: UML22-711
  • Legacy Issue Number: 8202
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Italicize activity as well as execution in sent 2 of para 1 under Actions and activities. Basic Activities describes basic and structured levels as orthogonal where either can be used without the other or both can be used to support modeling... . Yet StructuredActivities says that this level requires the basic level. Fig. 175 does not support this statement. Please clarify and fix.

  • Reported: UML 2.0 — Mon, 31 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.54

  • Key: UML22-710
  • Legacy Issue Number: 8199
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Delete header Examples as there are none

  • Reported: UML 2.0 — Mon, 31 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    See issue 8155 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

{redefined } should be named {redefines }

  • Key: UML22-713
  • Legacy Issue Number: 8204
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary: {redefined <end-name>}

    should be named

    {redefines <end-name>}
  • Reported: UML 2.0 — Tue, 1 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    Typo in the Superstructure spec; it does not occur in the Infrastructure.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Property string {bag} is redundant

  • Key: UML22-712
  • Legacy Issue Number: 8203
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Property string

    {bag}

    is redundant. Use property string

    {nonunique}

    defined for MultiplicityElement instead

  • Reported: UML 2.0 — Tue, 1 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.5

  • Key: UML22-718
  • Legacy Issue Number: 8210
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Add subsets (or specializes) or redefines statements to associations as indicated by the associated figures. Correct either the association multiplicity or the associated diagram multiplicity so that they agree. Italicize ActivityEdge in fig. 196. Add OCL notation to constraints. In Semantics (CompleteActivities) change "Edges" beginning paragraphs 3 and 4 to "ActivityEdges". In notation change stick-arrowhead to open arrowhead

  • Reported: UML 2.0 — Tue, 1 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.4

  • Key: UML22-717
  • Legacy Issue Number: 8209
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Add OCL notation to constraints

  • Reported: UML 2.0 — Tue, 1 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    See issue 6452 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.48

  • Key: UML22-703
  • Legacy Issue Number: 8192
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Fig. 241 shows the generalization of UnmarshallAction to be Actions (from Basic). Correct either figure or text. Association object:inputPin[1..1] subsets nput from Input and association result:OutputPin[1..1] subsets output from Output according to fig 241. Add OCL notation to constraints

  • Reported: UML 2.0 — Mon, 31 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    OCL is duplicate with 6346.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.46

  • Key: UML22-701
  • Legacy Issue Number: 8190
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Add OCL notation to constraint [2]. My guess would be self.object.type=self.classifier.type (That's pure guess since I know very little OCL.) Delete header Examples as there are none

  • Reported: UML 2.0 — Mon, 31 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    See issue 6452, 8155 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.45

  • Key: UML22-700
  • Legacy Issue Number: 8189
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Add OCL Notation to Constraints

  • Reported: UML 2.0 — Mon, 31 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    See issue 6452 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.52

  • Key: UML22-707
  • Legacy Issue Number: 8196
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Delete Examples header as there are none

  • Reported: UML 2.0 — Mon, 31 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    See issue 8155 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.51

  • Key: UML22-706
  • Legacy Issue Number: 8195
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Delete Examples header as there are none

  • Reported: UML 2.0 — Sun, 9 Jan 2000 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    See issue 8155 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.50

  • Key: UML22-705
  • Legacy Issue Number: 8194
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Association value:ValueSpecification[1] does not express a specialization in the figure. Please correct either text or figure. Add OCL notation to constraints

  • Reported: UML 2.0 — Mon, 31 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    OCL request is duplicate of 6346.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.44

  • Key: UML22-699
  • Legacy Issue Number: 8188
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Association target:inputPin[1] subsets input from Input according to fig 144. Add OCL notation to the constraints. Semantics [1] change "his" to "the".

  • Reported: UML 2.0 — Mon, 31 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    OCL is duplicate with 6346.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.49

  • Key: UML22-704
  • Legacy Issue Number: 8193
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Add OCL notation to constraints. Delete Examples header as there are none

  • Reported: UML 2.0 — Mon, 31 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    See issue 6452, 8155 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.47

  • Key: UML22-702
  • Legacy Issue Number: 8191
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Delete header Example as there are none

  • Reported: UML 2.0 — Mon, 31 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    See issue 8155 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

unclear statement

  • Key: UML22-596
  • Legacy Issue Number: 8064
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    The last part of the following statement makes no sense to me: "Understandability. While increasing the precision and conciseness, the specification techniques should also improve the readability of the specification. For this reason a less than strict formalism is applied, since a strict formalism formal technigues" It appears that part of the sentence got left out as there is no period

  • Reported: UML 2.0 — Tue, 4 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    There is a word missing in this text.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Text references Figure 8 and the correct figure number is 6

  • Key: UML22-595
  • Legacy Issue Number: 8063
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Text references Figure 8 and the correct figure number is 6

  • Reported: UML 2.0 — Tue, 4 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    This is indeed an incorrect figure reference.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section is badly worded and does not make a lot of sense

  • Key: UML22-599
  • Legacy Issue Number: 8067
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Section is badly worded and does not make a lot of sense. I interpreted it as "Often an informal convention is used to show (a part of) a construct, e.g., the name of a class should be centered and in bold."

  • Reported: UML 2.0 — Tue, 4 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

clarify what a directed association is

  • Key: UML22-598
  • Legacy Issue Number: 8066
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    am not an expert on UML and am reading this to learn about it. Could you please clarify what a directed association is. A search of the document does not yield any other reference to this term.

  • Reported: UML 2.0 — Tue, 4 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Terminology Issue

  • Key: UML22-593
  • Legacy Issue Number: 8042
  • Status: closed  
  • Source: Object Management Group ( Stephen Mellor)
  • Summary:

    When we build a state machine (nee State chart diagram) to define the behavior of a Dog, say, each dog instance has its own state.

    In other words, each copy of the state machine diagram has it's own state. What is the official term for each-copy-of-the-state-machine, the entity that has state. We need to be able to say "The <state machine thing> for Fido is in the state 'Barking'" and "The <state machine thing> for Rover is in the state Sleeping".

  • Reported: UML 1.4.2 — Thu, 30 Dec 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Resolution: The submitter does not raise an issue against the specification, but asks a question for clarification. Such terminology might be useful in explaining the semantics, but is not required for the specification. Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

typing error in the statement :unrestricted ?

  • Key: UML22-600
  • Legacy Issue Number: 8068
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    believe there is a typing error in the statement :unrestricted: Indicated that there is no restriction no [should be to?] adding new values, changing a value, or removing values to an occurrence of a StructuralFeature

  • Reported: UML 2.0 — Tue, 4 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

extra word in the last sentence of the paragraph under Attributes

  • Key: UML22-597
  • Legacy Issue Number: 8065
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    believe that there is an extra word in the last sentence of the paragraph under Attributes. "If the mulitplicity of the attribute is supressed if it is '1' (default in UML)." I believe the sentence should read "The multipliticy of the attribute is supressed if is is '1' (default in UML)."

  • Reported: UML 2.0 — Tue, 4 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

section 9.20.2 VisibilityKind lists two types of visibility

  • Key: UML22-594
  • Legacy Issue Number: 8062
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    In section 9.20.2 VisibilityKind lists two types of visibility-Public and Private. Yet the glossary (page 19) and Figure 80 on page 119 (and many other figures) list threePublic, Private, and Protected. Version 1.5 also defined a fourth type of visibility-Package. Please clarify and or enhance the definition of VisibilityKind in 9.20.2 to explain the differences between the glossary and the Figure.

  • Reported: UML 2.0 — Tue, 4 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

StructuredActivityNode specialized multiplicity

  • Key: UML22-592
  • Legacy Issue Number: 8041
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The semantics of StructuredActivityNode still says "This constraint is modeled as a specialized multiplicity from ActivityNode and ActivityEdge to StructuredActivityNode". The FTF changed the metamodel for this to not use specialized multiplicity.

  • Reported: UML 2.0 — Thu, 30 Dec 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

What happened to real numbers

  • Key: UML22-601
  • Legacy Issue Number: 8069
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    The elements for numbers you define in the Literals package are LiteralInteger and LiteralUnlimitedNatural. What happened to real numbers? Natural numbers do no include decimals.

  • Reported: UML 2.0 — Tue, 4 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12

  • Key: UML22-724
  • Legacy Issue Number: 8218
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Use of the term edge(s)is confusing without the appropriate qualifier - "Control" or "Object." Suggest changing edge or edges to ControlEdge(s) and/or ObjectEdge(s) as appropriate

  • Reported: UML 2.0 — Thu, 3 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.4

  • Key: UML22-662
  • Legacy Issue Number: 8148
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Association fromAction:Action[1] missing the specialization or subsets statement shown in fig. 159. Add OCL statements to constraints. Fig. 161 shows the association +action between i2:ActionInputPin and s1:ReadSetAction and between i4:ActionInputPin and s2:ReadSetAction but this is not an association defined for ActionInputPin in the text or shown on fig. 159. Either correct +action association to +fromAction or add +action as an association of ActionInputPin. I may be totally incorrect but shouldn't there be some link or association from the classifier bar:Signal?

  • Reported: UML 2.0 — Thu, 27 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    See revised text. The rest is duplicate with 6452.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.3

  • Key: UML22-661
  • Legacy Issue Number: 8147
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Fig. 142 does not list Dependencies as a generalization. Associations /input:InputPin[*] and /output:OutputPin[*] need the specialization or subset statement as shown in fig. 143 Association /context:Classifier[1] does not agree with multiplicity in fig. 142 Delete headers Examples and Rationale as these sections are blank

  • Reported: UML 2.0 — Thu, 27 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 10.3.10

  • Key: UML22-655
  • Legacy Issue Number: 8140
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Fig 124 shows that the Association utilizedElement:PackageableElement also subsets target

  • Reported: UML 2.0 — Tue, 25 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 10.3.9

  • Key: UML22-654
  • Legacy Issue Number: 8139
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Constraints are not shown on fig 126 as other constraints have been shown on other figures. Under Notation, should "instance" be "instance specification?"

  • Reported: UML 2.0 — Tue, 25 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 10.4

  • Key: UML22-657
  • Legacy Issue Number: 8143
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Table 8 Node Reference says Node has keyword options <<device>> and <<execution environment>> but these are not mentioned in the Node section nor are they diagrammed anywhere.

  • Reported: UML 1.4.2 — Wed, 26 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 10.3.6

  • Key: UML22-652
  • Legacy Issue Number: 8137
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Fig 126 does not show all generalizations listed; text for the Association deployment:Deployment[*] does not mention that the association specializes ownedElement as shown in the figure

  • Reported: UML 2.0 — Tue, 25 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 10.3.11

  • Key: UML22-656
  • Legacy Issue Number: 8141
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    The specialization of the association nestedNode:Node is not shown in fig. 125

  • Reported: UML 2.0 — Wed, 26 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    There is no nestedClassifier association end that applies to this case.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 10.3.4

  • Key: UML22-650
  • Legacy Issue Number: 8135
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    The Associations for the Nodes Package text do not agree with Fig. 126.

  • Reported: UML 2.0 — Tue, 25 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 10.3.8

  • Key: UML22-653
  • Legacy Issue Number: 8138
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    I don't believe that fig 125 shows the composite association between nodes and ExecutionEnvironment as expressed in Semantics. Typo - add ending guillemets to <<J2EE container.

  • Reported: UML 2.0 — Tue, 25 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 10.3.3

  • Key: UML22-649
  • Legacy Issue Number: 8134
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Kernel generalization is not shown in fig. 126

  • Reported: UML 2.0 — Tue, 25 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 10.3.5

  • Key: UML22-651
  • Legacy Issue Number: 8136
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Generalization, Association, and Constraints in text don't agree with fig. 127

  • Reported: UML 2.0 — Tue, 25 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see ptc/2006-04-01 page148/149

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ReduceAction

  • Key: UML22-565
  • Legacy Issue Number: 7977
  • Status: closed  
  • Source: Object Management Group ( Stephen Mellor)
  • Summary:

    It has come to my attention that the removal of the ReduceAction (fair
    enough) requires the use of a variable (a very bad idea) to construct an
    alternative specification.

    To do something like Reduce(<data expression>, Add) in UML 1.5, you
    would have to say:

    • An activity/structure node with variable Sum.
    • The expansion region takes the collection as input and has no
      output. In this case, the output collection will have only one
      element in it.
    • In the region, edges coming from/going to the inputs/outputs take
      elements from the input collections and put elements in the output
      collections.
    • The region uses CallOperationAction with operation timeofLastCall to
      get the time and CallBehaviorAction on the (primitive)
      FunctionBehavior for addition and updates the variable.
    • After the region is complete, the variable has the sum in it.

    The 1.5 Action Model included variables so that those who "needed" them
    could have them. However, the introduction of variables changes the
    static-single-assignemnt nature of the language and would now require
    data-flow analysis of a developer model to work out what is happening.
    Before all we had to do was scan for Variable Actions and reject the
    developer model so proposed.

    In other words, those of us in the translation business did not need
    variables, and we could ignore those models that used them. Now we're
    stuck.

    Topic: ReduceAction

    UML 1.5 had ReduceAction, which repeatedly applied a function pairwise
    to elements of a collection until only only element is left. It did not
    constrain order or concurrency of application. It was replaced with
    ExpansionRegion UML 2, which requires commitment to order and
    concurrency.

  • Reported: UML 1.4.2 — Tue, 14 Dec 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    Corrections to issue description:

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / Incorrect statement on port visibility

  • Key: UML22-564
  • Legacy Issue Number: 7973
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The updated UML spec p162 states:

    "UML Superstructure 2.0 Draft Adopted Specification

    A port of a classifier is shown as a small square symbol. The name of the port is placed near the square symbol. If the port
    symbol is placed overlapping the boundary of the rectangle symbol denoting that classifier this port is exposed (i.e., its
    visibility is public). If the port is shown inside the rectangle symbol, then the port is hidden and its visibility is as specified (it
    is protected by default)."

    This text was supposed to be removed by the FTF – the placement of the port is independent of its visibility. Port placement is merely a question of graphical convenience. Their visibility is indicated by the usual means as for all other properties (+, -, and #).

  • Reported: UML 1.4.2 — Fri, 10 Dec 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 14.3.7

  • Key: UML22-566
  • Legacy Issue Number: 7986
  • Status: closed  
  • Source: SINTEF ( Richard Sanders)
  • Summary:

    ... of an object. (missing period) ... destruction of the instance -> of the object ... that this instanceowns -> instance owns

  • Reported: UML 2.0 — Sat, 18 Dec 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Minor error in BNF of an message argument

  • Key: UML22-563
  • Legacy Issue Number: 7970
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Minor error in BNF of an message argument: Instead <argument> ::= (<[parameter-name> ‘=’] write <argument> ::= ([<parameter-name> ‘=’]

  • Reported: UML 2.0 — Tue, 7 Dec 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 14.3.14

  • Key: UML22-568
  • Legacy Issue Number: 7988
  • Status: closed  
  • Source: SINTEF ( Richard Sanders)
  • Summary:

    ... <interactionconstraint> -> <InteractionConstraint> ... in Figure 335 -> Figure 335 or 352

  • Reported: UML 2.0 — Sat, 18 Dec 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 14.3.16

  • Key: UML22-569
  • Legacy Issue Number: 7989
  • Status: closed  
  • Source: SINTEF ( Richard Sanders)
  • Summary:

    ... and InteractionOperand represent -> represents

  • Reported: UML 2.0 — Sat, 18 Dec 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

StateInvariants/Continuations

  • Key: UML22-571
  • Legacy Issue Number: 7995
  • Status: closed  
  • Source: SINTEF ICT ( Richard Torbjørn Sanders)
  • Summary:

    StateInvariants/Continuations: add to figure a Continuation (e.g. Idle) that spans :Y and an additional lifeline :X

  • Reported: UML 2.0 — Sat, 18 Dec 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Table 14

  • Key: UML22-570
  • Legacy Issue Number: 7990
  • Status: closed  
  • Source: SINTEF ( Richard Sanders)
  • Summary:

    Bottom of page: Node type "Stop" should be "Destruction event"

  • Reported: UML 2.0 — Sat, 18 Dec 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 14.3.13

  • Key: UML22-567
  • Legacy Issue Number: 7987
  • Status: closed  
  • Source: SINTEF ( Richard Sanders)
  • Summary:

    ... needs not be the whole -> need not be

  • Reported: UML 2.0 — Sat, 18 Dec 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

DataType attributes UML 2 Super (ptc/04-10-02)

  • Key: UML22-553
  • Legacy Issue Number: 7939
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    On Figure 13, DataType::ownedAttribute is specified as ordered but in the
    associations section on page 59, it is not specified as ordered.

  • Reported: UML 1.4.2 — Fri, 19 Nov 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2.2 superstructure section 9.3.11 page 184: Port.isService

  • Key: UML22-458
  • Legacy Issue Number: 13083
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    The definition of Port.isService appears to be redundant with the concept of public/private visibility. Is it valid for an isService=true Port to be private, or for an isService=false Port to be public? What about protected and package visibility for Ports?

  • Reported: UML 2.1.2 — Mon, 17 Nov 2008 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Resolution:
    From Bran Selic:
    Please note that isService=false is intended for modeling so-called SPPs (service provision points) in UML-RT. SPPs are ports that are used by the implementation of a structured class to access run-time services of the underlying support layers. In contrast to ports for which isService=true, SPPs are implementation specific – in other words, they are not part of the services that a component publishes to its clients. On the other hand, they must be public ports or you will not be able to connect to them from the outside.

    It is a subtle distinction but an important one. The notion of implementation-specific interfaces is one that has, unfortunately, been generally missed in programming languages. It is a key element of layering.

    If you remove this capability, you will certainly invalidate a lot of models based on this notion.

    Revised Text:
    None.

    Disposition: Closed, no change.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Could you please clarify what does the UML2 specifications intend for "provided port" and "required port"?

  • Key: UML22-456
  • Legacy Issue Number: 12985
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Could you please clarify what does the UML2 specifications intend for "provided port" and "required port"? Intuitively, it seems that a port could provide (respectively require) the interface which types it. This is in contradiction with the UML2 definition of port. Nevertheless, I belive a port should be able to require the interface tpeing it: the type of a port and its role (provide/require) should be decoupled. This is basically what the graphical front-end of Rhapsody does. It is also the same approach used for SysML ports, where direction is decoupled from the type of the port.

  • Reported: UML 2.1.2 — Thu, 23 Oct 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    The idea of decoupling the type from the interface is addressed by 13080. The clarification is addressed here by the text revisions below.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Inconsistency in Superstructure 2.2 p. 550

  • Key: UML22-455
  • Legacy Issue Number: 12915
  • Status: closed  
  • Source: International Business Machines ( James Bruck)
  • Summary:

    There seems to be an inconsistency in the spec.

    Supersturcture v2.2 ptc/2008-05-xx
    p 550

    The spec mentions:
    A state with isSimple=true is said to be a simple state. A simple state does not have any regions **and it does not refer to any submachine state machine.**

    It also says in the constraints section ( constraint [4] ) :
    A simple state is a state without any regions. isSimple = region.isEmpty()

    The constraint seems to be missing the part about not refering to any submachine state machine.

  • Reported: UML 2.1.2 — Tue, 7 Oct 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    The submitter is correct. Add the missing constraint to the isSimple() operation of State by adding that the
    isSubmachineState attribute has to be false

  • Updated: Fri, 6 Mar 2015 20:58 GMT

InstanceSpecifications

  • Key: UML22-454
  • Legacy Issue Number: 12912
  • Status: closed  
  • Source: University of Kassel ( Carsten Reckord)
  • Summary:

    To better express links with InstanceSpecifications, InstanceSpecification should be able to reference Slots owned by other InstanceSpecifications similar to an Association's memberEnd. Currently, when modelling an object diagram with a link like the one in fig. 7.54 on p.85, the specification is unclear on which of the involved InstanceSpecifications (Don, Josh, assoc) should own which Slots (father, son). Assuming that the involved association ends are ownedAttributes of the respective classes (Person), one would expect the object specifications (Don, Josh) to have Slots for these ends. Similarly one would expect the link InstanceSpecification to somehow reference its ends. Since a Slot can only belong to one InstanceSpecification, this is currently only possible by duplicating Slots and InstanceValues between object and link InstanceSpecifications (at least that is how e.g. Rational does it). This leads to two problems. First there is of course a lot of redundancy and chances for inconsistency. Second, and more importantly, there is no easy way to navigate from an object InstanceSpecification to the "connected" link InstanceSpecifications. On type level, an association can reference member ends that are owned by other classifiers. For the sake of consistency and simplicity, we would suggest something similar on the instance level for the InstanceSpecification-Slot relationship, i.e. a memberSlot referencing Slots owned by other InstanceSpecifications (maybe in a specialized LinkSpecification). I have created some diagrams to better illustrate the problem, albeit for a different example: - The example: http://www.reckord.de/uml/example.png - What it currently looks like on the meta level: http://www.reckord.de/uml/example-metaobjects.png - What it could look like: http://www.reckord.de/uml/example-meta-fixed.png

  • Reported: UML 2.1.2 — Mon, 6 Oct 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Merged with 9961

  • Updated: Fri, 6 Mar 2015 20:58 GMT

specificMachine association should be changed to be type StateMachine

  • Key: UML22-453
  • Legacy Issue Number: 12855
  • Status: closed  
  • Source: NASA ( Alexander Murray)
  • Summary:

    The specificMachine association of metaclass ProtocolConformance is of type ProtocolStateMachine, which would seem to prohibit the specificMachine from being a BehaviorStateMachines::StateMachine. However, the text sections of section 15.3.5, including the Description and Semantics sections, are very clear that the conforming StateMachine may be a BehavioralStateMachine::StateMachine, which make sense. So the specificMachine association should be changed to be type StateMachine. Also, Figure 15.5 should be similarly changed.

  • Reported: UML 2.1.2 — Wed, 17 Sep 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    The protocol conformance relationship was explicitly intended to model relationships between protocol state machines
    (this is clearly stated in the spec). It is unclear what would be the precise meaning of that type of relationship between
    different kinds of state machines, but, whatever it might be, it is likely to be complex, dealing with issues such as
    behavioral equivalence. This is still an open research topic with many different approaches and not something one
    should standardize as yet.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

p269-p270 Constraint

  • Key: UML22-452
  • Legacy Issue Number: 12851
  • Status: closed  
  • Source: Architecture Technology Institute ( Hiroshi Miyazaki)
  • Summary:

    [2] The type and ordering of the result output pin are the same as the type and ordering of the open association end.
    let openend : AssociationEnd = self.endData->select(ed | ed.value->size() = 0)>asSequence()>first().end in

    "AssociationEnd" -> "Propertye"

    [3] The multiplicity of the open association end must be compatible with the multiplicity of the result output pin.
    270 UML Superstructure Specification, v2.2
    let openend : AssociationEnd = self.endData->select(ed | ed.value->size() = 0)>asSequence()>first().end in

    "AssociationEnd" -> "Propertye"

    [4] The open end must be navigable.
    let openend : AssociationEnd = self.endData->select(ed | ed.value->size() = 0)>asSequence()>first().end in

    "AssociationEnd" -> "Propertye"

    [5] Visibility of the open end must allow access to the object performing the action.
    let host : Classifier = self.context in
    let openend : AssociationEnd = self.endData->select(ed | ed.value->size() = 0)>asSequence()>first().end in

    "AssociationEnd" -> "Propertye"

  • Reported: UML 2.1.2 — Fri, 12 Sep 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    See issue 6462 (resolved in UML 2.3) for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

operation allConnections

  • Key: UML22-451
  • Legacy Issue Number: 12850
  • Status: closed  
  • Source: Architecture Technology Institute ( Hiroshi Miyazaki)
  • Summary:

    1)>[1] The operation allConnections results in the set of all AssociationEnds of the Association.

    "AssociationEnds" is "Properties", isn't it?

  • Reported: UML 2.1.2 — Fri, 12 Sep 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • 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:58 GMT

TYPO p.54 Additional Operations

  • Key: UML22-450
  • Legacy Issue Number: 12848
  • Status: closed  
  • Source: Architecture Technology Institute ( Hiroshi Miyazaki)
  • Summary:

    [3] The query allParents() gives all of the direct and indirect
    ancestors of a generalized Classifier.
    Classifier::allParents(): Set(Classifier);
    allParents = self.parents()>union(self.parents()>collect(p |
    p.allParents())

    It seems to be lack of the last parenthesis.

  • Reported: UML 2.1.2 — Wed, 10 Sep 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Indeed, there is a missing closing parenthesis.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Classifier has association end "attribute"

  • Key: UML22-446
  • Legacy Issue Number: 12844
  • Status: closed  
  • Source: Architecture Technology Institute ( Hiroshi Miyazaki)
  • Summary:

    Classifier has association end "attribute". The association should have the opposite
    side of "attribute". Such association end should be "Classifier::attribute".
    In the case of "Class", "Datatype", "StructuredClassider" (however, there is a typo),
    "Signal", such element have "Classifier::attribute" association end.
    However, Interface and Artifact don't have such association end.

  • Reported: UML 2.1.2 — Mon, 8 Sep 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • 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:58 GMT

Typo 9.3.13 p190

  • Key: UML22-445
  • Legacy Issue Number: 12843
  • Status: closed  
  • Source: Architecture Technology Institute ( Hiroshi Miyazaki)
  • Summary:

    ownedAttribute : Property[0..*]
    References the properties owned by the classifier. (Substes StructuredClassifier:: role,
    Classifier.attribute...
    ~~~~~~~~~~~~~~~~~~~~
    Classifier::attribute?

  • Reported: UML 2.1.2 — Mon, 8 Sep 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Metaclass Property is denoted in Interfaces Package on p.36

  • Key: UML22-449
  • Legacy Issue Number: 12847
  • Status: closed  
  • Source: Architecture Technology Institute ( Hiroshi Miyazaki)
  • Summary:

    However, according to the class description for Property,
    Property is "from Kernel and AssociationClass".
    Property is defined in Interfaces Package.
    Therefore, it seems Property is "from Kernel, Interfaces and AssociationClass".

  • Reported: UML 2.1.2 — Wed, 10 Sep 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • 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:58 GMT

7.3.33 p100

  • Key: UML22-448
  • Legacy Issue Number: 12846
  • Status: closed  
  • Source: Architecture Technology Institute ( Hiroshi Miyazaki)
  • Summary:

    "clientDependency: Dependency[*]
    Indicates the dependencies that reference the client."

    This explanations is described in "Attribute" clause, not Associations" of NemedElment.
    It seems to be in incorrect clause.

  • Reported: UML 2.1.2 — Mon, 8 Sep 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • 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:58 GMT

Property 7.3.44 p125

  • Key: UML22-447
  • Legacy Issue Number: 12845
  • Status: closed  
  • Source: Architecture Technology Institute ( Hiroshi Miyazaki)
  • Summary:

    "A property related to a classifier by ownedAttribute represents an attribute..."
    and in its semantics
    "When a property is owned by a classifier other than an association via ownedAttribute, then it represents an attribute of
    the class or data type."

    However, in the case of "StructuredClassifier", "Signal", "Artifact",
    "Interface".
    "attribute" is not necessary

    The specification should modified as followings.

    p125 L7:
    "A property related to a classifier by attribute represents an attribute,"

    and

    p128 L17
    "When a property is owned by a classifier other than an association, then it represents an attribute of the classifier."

  • Reported: UML 2.1.2 — Mon, 8 Sep 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    The issue is not correct. All attributes are in fact owned via a property called ownedAttribute, different in each case,
    but this is true for all subclasses of Classifier including Interface, Signal, Artifact, etc. So the text is correct.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

7.3.44 additional operation P128

  • Key: UML22-444
  • Legacy Issue Number: 12842
  • Status: closed  
  • Source: Architecture Technology Institute ( Hiroshi Miyazaki)
  • Summary:

    [4]The query isAttribute() is true if the Property is defined as an attribute of
    some classifier.
    context Property::isAttribute(p : Property) : Boolean
    post : result = Classifier.allInstances->exists(C|c.attribute->includes(p))

    This OCL means there is at least one element of Property.
    Then, it is better to represent as "not classifier->isEmpty, not "Classifer.allinstances"
    like opertation [3]. It is better to represent similar style in a same block.

    This issue relates to aleady mentioned issue(Issue 11120). However, it is not exactly same.

  • Reported: UML 2.1.2 — Mon, 8 Sep 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Merged with 11120

  • Updated: Fri, 6 Mar 2015 20:58 GMT

first paragraph of section 7.8 UML kernel

  • Key: UML22-399
  • Legacy Issue Number: 12436
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    The first paragraph of section 7.8 suggests that the UML kernel is the merge of Core::Abstractions packages. To obtain Classifier in the UML kernel, we would have to merge Classifiers, Super and Generalizations from Core::Abstractions. How is this possible given that: a) there are no generalization relationships among Classifier metaclasses in these Abstractions packages b) there are two matching operations:

    {Super,Generalizations}

    ::Classifier::parents (a) means that Generalizations::Classifier::parents cannot redefine Super::Classifier::parents. Even if there were a generalization, the resulting merged model would be ill-formed because it would include a generalization self-loop. (b) means that the merge is ill-formed because it violates constraint #4 defined in the general package merge rules in 11.9.3 (p. 164) POSSIBLE WORKAROUND: - split Core::Abstractions::Super in two packages: Super and SuperParents which only defines Classifier::parents - ditto for Core::Abstractions::Generalizations - if Super is to be merged but Generalizations isn't, then merge SuperParents as well. - if both Super and Generalizations are to be merged, then merge GeneralizationsParent but not SuperParents This is a kludge but that's the only short-term workaround I can find for this bug at this time.

  • Reported: UML 2.1.2 — Sun, 11 May 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • 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:58 GMT

Section: 7.3.7 and 8.3.1

  • Key: UML22-398
  • Legacy Issue Number: 12432
  • Status: closed  
  • Source: THALES ( Sebastien Madelenat)
  • Summary:

    page 50, the "nestedClassifier" association of Class is described like this: "References all the Classifiers that are defined (nested) within the Class. Subsets Element::ownedMember" page 148, the "packagedElement" association of Component is described like this: packagedElement: PackageableElement [*] "The set of PackageableElements that a Component owns. In the namespace of a component, all model elements that are involved in or related to its definition may be owned or imported explicitly. These may include e.g., Classes, Interfaces, Components, Packages, Use cases, Dependencies (e.g., mappings), and Artifacts. Subsets Namespace::ownedMember." This means a Class may own a Component and this Component may own a Package. I wonder what a Class owning (transitively) a Package could mean.

  • Reported: UML 2.1.2 — Fri, 9 May 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    This is one example of the unintended consequences of Component inheriting from Class. We may observe a related consequence, that it is possible for a Component to own another Component in two ways: as a nestedClassifier, and as a packagedElement. There is no distinction, notationally or otherwise, between these two modes of ownership.
    We can resolve these by adding two constraints to Component:
    · A Component's nestedClassifier collection is always empty.
    · If a Component is nested in a Class, then its packagedElement collection is empty.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Port

  • Key: UML22-401
  • Legacy Issue Number: 12492
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Sebastien Gerard)
  • Summary:

    for Port, there is a constraint that say :

    [1] The required interfaces of a port must be provided by elements to which the port is connected.

    I believe that ports are connected by delegation connector, this constraint may not be checked!

    Am I right?

  • Reported: UML 2.1.2 — Thu, 15 May 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    You are right, and this constraint is more correctly covered by a revised constraint [1] in chapter 8.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 14 Interaction

  • Key: UML22-400
  • Legacy Issue Number: 12455
  • Status: closed  
  • Source: Research Group Software Construction, RWTH Aachen ( Alexander Nyßen)
  • Summary:

    As it is intended by the current specification, an Interaction may be modeled independent of any BehavioredClassifier, which owns it. This would e.g. allow to use Interactions to model communication between analysis objects at a very early analysis stage, where no classes have been designed yet. The intention is manifested in the specification by allowing that a Lifeline or Messages does not have to specify a Property (Multiplicity of 0..1 of Lifelines->represents) or a Connector (Multiplicity of 0..1 of Message->connector) respectively (and that an Interaction does not have to be owned by a BehavioredClassifier). However, the restriction that every OccurrenceSpecification, and as such also every MessageOccurenceSpecification has to be associated with an event (compare Figure 14.5 on page 462) prevents that an Interaction may be used in above described manner. The reason for this is is as follows: 1) As the absense of a MessageEnd has another semantics (the MessageKind is inferred from it), in above described scenario, MessageEnds should indeed be specified (a complete message would be the only appropriate kind to model communication between objects as in above described scenario) 2) Because of above described multiplicity constraint, the MessageOccurenceSpecifications serving as sendEvent and receiveEvent of the message have to refer to some SendSignalEvent/ReceiveSignalEvent or SendOperationEvent/ReceiveOperationEvent respectively. 3) Those events in turn require to specify a Signal or Operation (see Figure 14.2 on page 459). 4) The Signal or Operation would have to be owned by some Classifier. There is however no Classifier in above described scenario, with exception of the Interaction itself (adding the Signals or Operations to the Interaction itself, would however require that all Signals and Operations are named unique, which is inappropriate). I would thus propose to change the specification, so that MessageOccurenceSpecifications (or OccurenceSpecifications) may, but do not have to specify an event (i.e. change multiplicity from 1 to 0..1).

  • Reported: UML 2.1.2 — Wed, 14 May 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Changing this cardinality in the metamodel is a breaking change, and is unnessary.
    It seems that, if you are modeling the sending of a message, then you are modeling that something is being sent. This
    .something. can be modeled as a signal, even if, at an early stage of analysis, this is just a placeholder for more detail
    to be added later.
    There are no constraints requiring that a message signature refer to an operation or signal reception defined for the
    type of the ConnectableElement associated with a Lifeline.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 15.3.11/Notation

  • Key: UML22-389
  • Legacy Issue Number: 12380
  • Status: closed  
  • Source: Steria Mummert Consulting AG ( Torsten Binias)
  • Summary:

    In chapter 15.3.12 (p. 568) the keyword "final" is informally introduced for states: "the states VerifyCard, OutOfService, and VerifyTransaction in the ATM state machine in Figure 15.42 have been specified as

    {final}" This should be mentioned in capter 15.3.11 (State (from BehaviorStateMachines, ProtocolStateMachines)) in section "Notation". Suggestion: "A state that is a leaf (i.e. isLeaf=TURE) can be shown using the keyword {final}

    after or below the name of the State."

  • Reported: UML 2.1.2 — Wed, 16 Apr 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Agreed. The “final” keyword should be explained in the section describing the notation for state machines
    and not in the examples paragraph, it should also be added to the list of keywords in Table C.1 in the
    appendix

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 11.3.25 gives the definition of MultiplicityExpression::isConsisten

  • Key: UML22-388
  • Legacy Issue Number: 12379
  • Status: closed  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    Section 11.3.25 gives the definition of MultiplicityElement::compatibleWith as: compatibleWith(other) = Integer.allInstances()-> forAll(i : Integer | self.includesCardinality implies other.includesCardinality) While technically correct, this may be a little impractical for any OCL interpreting tool. I think an alternative, that simply uses the upper and lower bounds, would be: compatibleWith(other) = other.includesMultiplicity(self)

  • Reported: UML 2.1.2 — Tue, 15 Apr 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • 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:58 GMT

interpreting InstanceSpecification

  • Key: UML22-396
  • Legacy Issue Number: 12427
  • Status: closed  
  • Source: Dell Technologies ( Mr. George Ericson)
  • Summary:

    Various readers are interpreting InstanceSpecification differently. One interpretation is that a particular InstanceSpecification specifies a particular instance. A second interpretation is that a particular InstanceSpecification may be used to specify more than one instance. I prefer the second interpretation. This is supported by the Note at the bottom of page 83 that refers to "... such structures."

  • Reported: UML 2.1.2 — Fri, 2 May 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    It is clear from this sentence: “As an InstanceSpecification may only partially determine the properties of an
    individual, there may actually be multiple individuals in the modeled system that satisfy the requirements
    of the InstanceSpecification.”
    But some of the earlier text seems to imply different - this text is changed.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Figure showing an AssociationClass as a ternary association

  • Key: UML22-395
  • Legacy Issue Number: 12406
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Please insert a figure showing an AssociationClass that is a ternary association to make clear whether the dashed line is to be connected to a line or the diamond. (Use can re-use figure 7.21 on page 44).

  • Reported: UML 2.1.2 — Wed, 23 Apr 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Merged with 8974

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 7.3.10/Associations

  • Key: UML22-391
  • Legacy Issue Number: 12382
  • Status: closed  
  • Source: Steria Mummert Consulting AG ( Torsten Binias)
  • Summary:

    Please explain constrainedElement has to be an ordered set and not a set.

  • Reported: UML 2.1.2 — Wed, 16 Apr 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    The order of the constrainedElements may make a significant difference on the meaning of the constraint. For instance,
    a constraint on two numeric elementsmay require that one is less than the other, or a constraint on two sets may require
    one to be a subset of the other.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 13.3.3/ Changes from previous UML

  • Key: UML22-390
  • Legacy Issue Number: 12381
  • Status: closed  
  • Source: Steria Mummert Consulting AG ( Torsten Binias)
  • Summary:

    Chapter 13.3.3, section “Changes from previous UML“: “The metaattributes isLeaf and isRoot have been replaced by properties inherited from RedefinableElement.” RedefinableElement does not have the property isRoot.

  • Reported: UML 2.1.2 — Wed, 16 Apr 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • 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:58 GMT

Car dependency example

  • Key: UML22-394
  • Legacy Issue Number: 12405
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The car dependency example on page 63 of the UML Super Structure Specification appears wrong to me. The description indicates to me that the arrow should be going from the car to the carfactory not the other way around as depicted.

  • Reported: UML 2.1.2 — Wed, 23 Apr 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Merged with 11489

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.8/Generalizations

  • Key: UML22-393
  • Legacy Issue Number: 12385
  • Status: closed  
  • Source: Anonymous
  • Summary:

    ActivityNode need not specialize “NamedElement (from Kernel, Dependencies)” because is specializes ““RedefinableElement (from Kernel)” which in turn specializes “NamedElement (from Kernel, Dependencies)”.

  • Reported: UML 2.1.2 — Wed, 16 Apr 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

qualifiers

  • Key: UML22-387
  • Legacy Issue Number: 12369
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    Are qualifiers displayed at opposite end of association than role name (or multiplicity) or near the role name (or multiplicity)?

    E.g. composition diamond is displayed at opposite end, multiplicity value – at the same end. How about qualifiers?

    UML 2.1.2 page 124:

    qualifier : Property [*] An optional list of ordered qualifier attributes for the end.

    Notation (page 128):

    The qualifier is attached to the source end of the association.

    What is the “source of the association” ???

    Look at figure from UML spec (first sample):

    Are these qualifiers owned in association end typed by Bank or Person?

  • Reported: UML 2.1.2 — Thu, 20 Mar 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • 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:58 GMT

Section: 15 StateMachines: doActivity and internal transitions

  • Key: UML22-397
  • Legacy Issue Number: 12431
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    What happens with the do activity if a internal transition fires? It is not mentioned in the specification.

  • Reported: UML 2.1.2 — Wed, 7 May 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Since the state is not exited, the do activity is unaffected by the firing of the internal transition.
    Add a clarifying statement to make this point explicit

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 7.3.10/Associations - insert reference

  • Key: UML22-392
  • Legacy Issue Number: 12384
  • Status: closed  
  • Source: Steria Mummert Consulting AG ( Torsten Binias)
  • Summary:

    “Certain kinds of constraints (such as an association “xor” constraint) are predefined in UML” Please insert a reference to the document containing the predefined constraints

  • Reported: UML 2.1.2 — Wed, 16 Apr 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    See issue 9617 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Unspecified constraint [1] on ActivityNode

  • Key: UML22-432
  • Legacy Issue Number: 12790
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    Source: UML 2.2 Superstructure document and XMI

    http://www.omg.org/cgi-bin/doc?ptc/08-05-05
    http://www.omg.org/cgi-bin/doc?ptc/08-05-12

    Nature: Unspecified OCL constraint

    Summary:

    The following constraint on ActivityNode (12.3.8) is unspecified:

    [1] Activity nodes can only be owned by activities or groups.

    Discussion:

    OCL 101.

    Revised Text:

    Change the specification of the constraint to the following:

    [1] Activity nodes can only be owned by activities or groups.
    self.activity=self.owner xor self.inGroup->includes(self.owner.oclAsType(ActivityGroup))

    Change the Superstructure XMI accordingly.

  • Reported: UML 2.1.2 — Fri, 15 Aug 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    This issue is obsolete. All constraints have been specified in UML 2.5.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

constraint [4] on AcceptEventAction and unordered result:OutputPin property

  • Key: UML22-431
  • Legacy Issue Number: 12789
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    Source: UML 2.2 Superstructure document and XMI

    http://www.omg.org/cgi-bin/doc?ptc/08-05-05
    http://www.omg.org/cgi-bin/doc?ptc/08-05-12

    Nature: Unspecified OCL constraint

    Summary:

    The following constraint on AcceptEventAction (11.3.2) is unspecified:

    [4] If isUnmarshalled is true, there must be exactly one trigger for events of type SignalEvent. The number of result output
    pins must be the same as the number of attributes of the signal. The type and ordering of each result output pin must be the
    same as the corresponding attribute of the signal. The multiplicity of each result output pin must be compatible with the
    multiplicity of the corresponding attribute.

    This constraint implicitly requires that the AcceptEventAction.result property should be ordered to enable order-sensitive comparison with corresponding properties in Signal.ownedAttribute.

    • result: OutputPin [0..*]
    Pins holding the received event objects or their attributes. Event objects may be copied in transmission, so identity
    might not be preserved.

    {Subsets Action::output}

    The
    [4a] If isUnmarshalled is true, there must be exactly one trigger for events of type SignalEvent.
    [4b] The number of result output pins must be the same as the number of attributes of the signal.
    [4c] The type and ordering of each result output pin must be the same as the corresponding attribute of the signal.
    [4d] The multiplicity of each result output pin must be compatible with the multiplicity of the corresponding attribute.
    self.isUnmarshall implies
    (self.trigger->size() = 1 and let e:Event = self.trigger.event->asSequence()->first() in
    e.oclIsKindOf(SignalEvent) and
    let s:Signal = e.oclAsType(SignalEvent).signal in
    Set

    {1..s.ownedAttribute->size()}->forAll(i|
    let ai:Property=s.ownedAttribute->at in
    let ri:OutputPin= self.result->asOrderedSet()->at in
    ai.type = ri.type and ri.lower <= ai.lower and ri.upper >= ri.upper))


    Discussion:

    OCL 101.

    Revised Text:

    Change the specification of the result property to the following:

    • result: OutputPin [0..*]
    Pins holding the received event objects or their attributes. Event objects may be copied in transmission, so identity
    might not be preserved. This association end is ordered. {Subsets Action::output}

    Change the specification of the constraint to the following:

    [4] If isUnmarshalled is true, there must be exactly one trigger for events of type SignalEvent. The number of result output
    pins must be the same as the number of attributes of the signal. The type and ordering of each result output pin must be the
    same as the corresponding attribute of the signal. The multiplicity of each result output pin must be compatible with the
    multiplicity of the corresponding attribute.

    (self.trigger->size() = 1 and let e:Event = self.trigger.event->asSequence()->first() in
    e.oclIsKindOf(SignalEvent) and
    let s:Signal = e.oclAsType(SignalEvent).signal in
    Set{1..s.ownedAttribute->size()}

    ->forAll(i|
    let ai:Property=s.ownedAttribute->at in
    let ri:OutputPin= self.result->at in
    ai.type = ri.type and ri.lower <= ai.lower and ri.upper >= ri.upper))

    Note: if the result property is not ordered, this constraint can be approximated in the following manner:

    (self.trigger->size() = 1 and let e:Event = self.trigger.event->asSequence()->first() in
    e.oclIsKindOf(SignalEvent) and
    let s:Signal = e.oclAsType(SignalEvent).signal in
    Set

    {1..s.ownedAttribute->size()}

    ->forAll(i|
    let ai:Property=s.ownedAttribute->at in
    let ri:OutputPin= self.result->asOrderedSet()->at in
    ai.type = ri.type and ri.lower <= ai.lower and ri.upper >= ri.upper))

    Change the Superstructure XMI accordingly.

  • Reported: UML 2.1.2 — Fri, 15 Aug 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Merged with 8702

  • Updated: Fri, 6 Mar 2015 20:58 GMT

figure 13.12

  • Key: UML22-434
  • Legacy Issue Number: 12792
  • Status: closed  
  • Source: International Business Machines ( James Bruck)
  • Summary:

    In the latest 2.2 version of the UML spec, there was a change for issue : 11409 - redirect TimeEvent::when to TimeExpression (from ValueSpecification).
    In the resolution to that issue, figure 13.13 (p427) was properly updated but it looks like figure 13.12 has a problem in that the association from TimeEvent should go to TimeExpression

  • Reported: UML 2.1.2 — Tue, 19 Aug 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    At first it seems like this would be any easy resolution - just update Figure 13.12. The problem is that the Event classes in Figure 13.12, including TimeEvent, are in the CommonBehaviors::Communications package, which is merged in at L1, while TimeExpression is in CommonBehaviors::SimpleTime, which is merged in at L2. Thus, having TimeEvent associated with TimeExpression - which is actually the case in the metamodel - causes a problem in the construction of L1 (which causes issues with the generation of XMI for L1).
    Now, one possibility would be to make the TimeEvent class in SimpleTime a merge increment. But the merging of typed elements has the constraint (see 7.3.40):
    "Matching typed elements (e.g., Properties, Parameters) must have conforming types. For types that are classes or data types, a conforming type is either the same type or a common supertype. For all other cases, conformance means that the types must be the same."
    While not entirely clear, the implication is that the resulting type is the common supertype. In this case, TimeEvent::when has type ValueSpecification in Communications and type TimeExpression, a subclass of ValueSpecification, in SimpleTime. The common superclass is thus ValueSpecification - but if you end up with TimeEvent::when having type ValueSpecification in the merged L2, then there isn't much point in typing it as TimeExpression in SimpleTime!
    Another possibility would be to leave the type of TimeEvent::when as ValueSpecification, which would allow a TimeExpression to be used when SimpleTime is included at L3. But this was explicitly changed in the UML 2.2 RTF, indicating a strong desire that the type of TimeEvent::when be TimeExpression (which does make some sense).
    It also doesn't seem to be a good idea to merge SimpleTime into L1 instead of L2, just to be able to have TimeExpression available for TimeEvent.
    So, the proposed resolution is that TimeEvent be moved into SimpleTime. This means that time events would only be allowed at L2, not L1. But since state machines aren't included until L2 and accept event actions not until L3, it seems unlikely that this would be a real problem.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Unspecified constraint [1] on ActivityNode (StructuredActivities)

  • Key: UML22-433
  • Legacy Issue Number: 12791
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    Source: UML 2.2 Superstructure document and XMI

    http://www.omg.org/cgi-bin/doc?ptc/08-05-05
    http://www.omg.org/cgi-bin/doc?ptc/08-05-12

    Nature: Unspecified OCL constraint

    Summary:

    The following constraint on Activity (12.3.8) is unspecified:

    [1] Activity nodes may be owned by at most one structured node.

    Discussion:

    OCL 101.

    Revised Text:

    Change the specification of the constraint to the following:

    [1] Activity nodes may be owned by at most one structured node.
    self.inStructuredNode->notEmpty() implies (self.inStructuredNode.oclAsType(ActivityGroup)->includesAll(self.inGroup)
    and self.inStructuredNode.oclAsType(Element)->includes(self.owner))

    Change the Superstructure XMI accordingly.

  • Reported: UML 2.1.2 — Fri, 15 Aug 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    This issue is obsolete. All constraints have been specified in UML 2.5.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Clarification on use of Profiles.

  • Key: UML22-436
  • Legacy Issue Number: 12833
  • Status: closed  
  • Source: International Business Machines ( James Bruck)
  • Summary:

    would like to get some clarification on the use of Profiles.

    Although it does not explicitly state this in the UML superstructure specification, there seems to be an implication that only Profiles should actually own Stereotype. The fact that Stereotype can be owned by any Package seems to be an unintended side effect of inheritance. Is it true that the only feature intended to own a Stereotype is Profile::ownedStereotype ?

    If it is true that only Profile can own a Stereotype, then it makes working with profiles with many stereotypes somewhat unruly (consider having 50 stereotypes). It would be nice to be able to group stereotypes within nested packages under a profile.

    Nesting profiles within profiles does not seem like an appropriate solution since: in order to satisfy constraint [2] in 18.3.6 the nested profile would also have to reference a metamodel; inconvenient. And, how would users use such a profile? Would they apply each nested profile separately? This seems to raise more problems than it solves.

    Either way, I would suggest that the spec. should provide some rules or guidelines in this area.

  • Reported: UML 2.1.2 — Thu, 4 Sep 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Property – Additional Operations, page 127.

  • Key: UML22-435
  • Legacy Issue Number: 12794
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    Property – Additional Operations, page 127.

    In the description of “isConsistentWith” –

    [1] The query isConsistentWith() specifies, for any two Properties in a context in which redefinition is possible, whether redefinition would be logically consistent. A redefining property is consistent with a redefined property if the type of the redefining property conforms to the type of the redefined property, the multiplicity of the redefining property (if specified) is contained in the multiplicity of the redefined property, and the redefining property is derived if the redefined attribute is property.”

    The last word, “property”, should be “derived”.

  • Reported: UML 2.1.2 — Thu, 21 Aug 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

7.3.44 Property P128

  • Key: UML22-443
  • Legacy Issue Number: 12841
  • Status: closed  
  • Source: Architecture Technology Institute ( Hiroshi Miyazaki)
  • Summary:

    [3] The query isNavigable() indicates whether it is possible to navigate across the property.
    Propery::isNavigable():Boolean
    isNavigable = not classifier->isEmpty() or
    association.owningAssociation.navigableOwnedEnd->includes(self)
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    "association", and "owningAssociation" are also associationend on Property.
    Then, expression "association.owningAssociation" is not appropriate.
    It seems "association" in the expression should be suppressed.

  • Reported: UML 2.1.2 — Mon, 8 Sep 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • 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:58 GMT

18.3.8 Stereotype

  • Key: UML22-442
  • Legacy Issue Number: 12840
  • Status: closed  
  • Source: Architecture Technology Institute ( Hiroshi Miyazaki)
  • Summary:

    For example in UML, States, Transitions, Activities,
    Use cases, Components, Attributes, Dependencies, etc.
    ~~~~~~~~~~
    In UML2.2, Attribute isn't model element.
    This seems incorrect.
    This explanation is example, then, it seems term "Attributes" should be suppressed.

  • Reported: UML 2.1.2 — Mon, 8 Sep 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Problem is now out of date.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Unspecified constraint [3] on Activity

  • Key: UML22-430
  • Legacy Issue Number: 12788
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    Source: UML 2.2 Superstructure document and XMI

    http://www.omg.org/cgi-bin/doc?ptc/08-05-05
    http://www.omg.org/cgi-bin/doc?ptc/08-05-12

    Nature: Unspecified OCL constraint

    Summary:

    The following constraint on Activity (12.3.4) is unspecified:

    [3] The groups of an activity have no supergroups.

    Discussion:

    OCL 101.

    Revised Text:

    Change the specification of the constraint to the following:

    [3] The groups of an activity have no supergroups.
    self.group->forAll(superGroup->isEmpty())

    Change the Superstructure XMI accordingly.

  • Reported: UML 2.1.2 — Fri, 15 Aug 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    This issue is obsolete. All constraints have been specified in UML 2.5.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Typo P205 10.3.4

  • Key: UML22-440
  • Legacy Issue Number: 12838
  • Status: closed  
  • Source: Architecture Technology Institute ( Hiroshi Miyazaki)
  • Summary:


    Attribute -> Attributes

  • Reported: UML 2.1.2 — Mon, 8 Sep 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • 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:58 GMT

On the table 2.3, page 8

  • Key: UML22-439
  • Legacy Issue Number: 12836
  • Status: closed  
  • Source: Architecture Technology Institute ( Hiroshi Miyazaki)
  • Summary:

    Sturcute CompositeStructure::InternalStructure.
    Is it correct?
    It seems typo. "CompositeStructures"

  • Reported: UML 2.1.2 — Mon, 8 Sep 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • 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:58 GMT

On the communication diagram in Fig 6.2 (second issue)

  • Key: UML22-438
  • Legacy Issue Number: 12835
  • Status: closed  
  • Source: Architecture Technology Institute ( Hiroshi Miyazaki)
  • Summary:

    The sequence expression is denoted as "A1", "B1", "A3".
    According to the specification, those messages means
    asynchronous messages.
    If so, the diagram doesn't show original intention.

  • Reported: UML 2.1.2 — Mon, 8 Sep 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • 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:58 GMT

On the communication diagram in Fig 6.2 (P12)

  • Key: UML22-437
  • Legacy Issue Number: 12834
  • Status: closed  
  • Source: Architecture Technology Institute ( Hiroshi Miyazaki)
  • Summary:

    There are underlined lifeline.
    According to UML 2.2 specfication (chapter 14),
    lifeline label refrains from underlined notation.
    It seems these are not appropriate

  • Reported: UML 2.1.2 — Mon, 8 Sep 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • 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:58 GMT

7.3.11 DataType, P61

  • Key: UML22-441
  • Legacy Issue Number: 12839
  • Status: closed  
  • Source: Architecture Technology Institute ( Hiroshi Miyazaki)
  • Summary:

    "The Attributes owned by the Data Type. This is an ordered collection.
    ~~~~~~~~~~
    Subsets Classifier::attribute and Element::ownedMember."

    Attributes->attributes

  • Reported: UML 2.1.2 — Mon, 8 Sep 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Well spotted.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2.1.2:18.3.5 Package (from Profiles)

  • Key: UML22-383
  • Legacy Issue Number: 12278
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    18.3.5 Package (from Profiles)

    Description

    A package can have one or more ProfileApplications to indicate which profiles have been applied.

    Because a profile is a package, it is possible to apply a profile not only to packages, but also to profiles.”

    A Profile is a subclass of InfrastructureLibrary::Constructs::Package, which cannot own ProfileApplications and so you can’t apply a profile to a profile.

  • Reported: UML 2.1.2 — Fri, 14 Mar 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Profiles does subclass Constructs::Package, but when Profiles is merged with Kernel::Classes::Package in UML compliance level L3, Package gets the ability to have applied profiles, as does its subclass, Profile. So whether a profile can be applied to a profile depends on what Profiles is merged with.

    Note that Profiles cannot stand alone, with just an import of Constructs since it defines Class as a merge increment (in order to add extensions). Profiles::Class has no ownedAttributes, so without a merge, Stereotypes would not be able to have Properties.

    However, applying a profile to a profile would extend the extensibility mechanisms of UML in non-standard ways that would not be supported by most tools. This would limit interoperability and break model interchange. So it should not be possible to apply a profile to another profile.
    Disposition: Closed, no change.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML Super 2.1.2:Feature

  • Key: UML22-382
  • Legacy Issue Number: 12275
  • Status: closed  
  • Source: Mathworks ( Alan Moore)
  • Summary:

    The Semantics section for Feature says:

    “A feature represents some characteristic for its featuring classifiers; this characteristic may be of the classifier’s instances considered individually (not static), or of the classifier itself (static).

    A Feature can be a feature of multiple classifiers. The same feature cannot be static in one context but not another.”

    It seems to me that the second sentence is simply a reiteration of the description of property “/ featuringClassifier: Classifier [0..*]

    The third sentence could be expressed more usefully as a constraint.

    I’m also puzzled by the 0..* multiplicity on featuringClassifier. It would be useful if the description of Feature explained when a feature can have more than one featuring classifier.

  • Reported: UML 2.1.2 — Wed, 12 Mar 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Much of this issue refers to obsolete text. This resolution addresses its final paragraph. We discussed
    this in our face-to-face meeting in Reston in March 2013 and decided to change the multiplicity of Feature::
    featuringClassifier to 0..1 (because this is a logical consequence of the remainder of the UML spec and
    does not affect serialization), and change the wording accordingly, pointing out the special case of Properties
    used as qualifiers which have no featuringClassifier.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

A final node that returns to the caller but leaves alive any parallel flow

  • Key: UML22-384
  • Legacy Issue Number: 12284
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    The regular ActivityFinalNode stops all possible parallel flows in the activity before
    returning to the caller.
    There are some cases where it would be interesting to have a variant of this behavior
    which would allow returning immediately but without affecting the execution of any
    parallel flow.

    A use case for this "soft return" construct: An application process a user "search" request.
    When it founds a first set of results it returns immediately the response to the user but it
    the meantime continues looking for another set of requests to anticipate possible additional
    request from the user, without loosing the context of the user request.

    For this use case we will use the "soft return" final node to return when finding the first
    set of responses and will use a FlowFinalNode at the end of a parallel branch looking for
    additional responses.
    For sure, it is always possible to encode this use case differently, but such new kind of
    final node would allow to model the intended behavior more directly.

    Rq: What would happen if a "soft return" is reached after a "soft return" already happened:
    I guess the semantics would be to behave as a FlowFinalNode (cannot return twice).
    And what if a "regular" ActivityFinalNode is reached after a "soft return": I guess all
    existing parallel are stopped but there is no return to the caller (since already returned).

  • Reported: UML 2.1.2 — Tue, 18 Mar 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    A behavior that is initially invoked via a synchronous call does not have its own thread of control, so it would be a fundamental semantics change to somehow allow it to continue executing after returning from the call. Fortunately, however, the functionality desired by the submitter can be easily achieved using existing UML mechanisms, by first starting the activity asynchronously, either as a classifier behavior or as a standalone behavior execution. Such an executing activity can then accept client requests using an accept event action and respond to them without terminating, as the submitter envisions. The activity can even accept a synchronous call via an accept call action and reply using a reply action, without terminating. In this case, the reply action acts, in effect, as the "soft return" suggested by the submitter.
    Revised Text:
    None
    Disposition: Closed No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

section '10.3.12 Property (from Nodes)'

  • Key: UML22-380
  • Legacy Issue Number: 12271
  • Status: closed  
  • Source: OFFIS e.V. ( Christian Mrugalla)
  • Summary:

    In section '10.3.12 Property (from Nodes)', the Description states "In the metamodel, Property is a specialization of DeploymentTarget", but a corresponding generalization is not defined under 'Generalization'. Proposed resolution: Add '"DeploymentTarget (From Nodes)" on page 205' to the Generalization section of 10.3.12.

  • Reported: UML 2.1.2 — Wed, 12 Mar 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • 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:58 GMT

PackageableElement (from Kernel), subsection: "Attribute"

  • Key: UML22-379
  • Legacy Issue Number: 12266
  • Status: closed  
  • Source: System ( Mehran Touhidi)
  • Summary:

    section: PackageableElement (from Kernel), subsection: "Attribute" is writen "Default value is false." that it cannt has that value because its type is VibilityKind and can only has one of its enumerated value.

  • Reported: UML 2.1.2 — Sat, 8 Mar 2008 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    See issue 10379 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CMOF file for UML2 does not have derived Associations marked as such

  • Key: UML22-386
  • Legacy Issue Number: 12357
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    For example A_ownedMember_namespace

    Has both its ends marked with isDerived=”true” but not the Association itself.

  • Reported: UML 2.1.2 — Thu, 27 Mar 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • 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:58 GMT

Section: 8.3.3

  • Key: UML22-385
  • Legacy Issue Number: 12356
  • Status: closed  
  • Source: University Karlsruhe ( Conny Kuehne)
  • Summary:

    On Page 23 of the UML Infrastructure Spec. it is stated, that "The multiplicity of an association end is suppressed if it is ‘*’ (default in UML).". This implies that omitting to define the multipl. of an association end A means that the multiplicity of A is * (between zero and infinity). However this contradicts most books I know and some examples in the specification itself.

  • Reported: UML 2.1.2 — Wed, 26 Mar 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • 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:58 GMT

description of MessageOccurenceSpecification

  • Key: UML22-378
  • Legacy Issue Number: 12263
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Sebastien Gerard)
  • Summary:

    The description of MessageOccurenceSpecification defines a property called event. It is useless, because MessageOccurenceSpecification inherits from OccurenceSpecification that already owns this property, as denoted in the figure 14.5.

  • Reported: UML 2.1.2 — Wed, 5 Mar 2008 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    See issue 14629 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

The list of literal described for the ennumeration MessageSort is not compl

  • Key: UML22-377
  • Legacy Issue Number: 12259
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Sebastien Gerard)
  • Summary:

    The list of literal described for the ennumeration MessageSort is not complete according to it sdescription as shown in figure 14.5.

  • Reported: UML 2.1.2 — Tue, 4 Mar 2008 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

undefined term 'Element::redefinedElement' occurs three times in standard

  • Key: UML22-381
  • Legacy Issue Number: 12273
  • Status: closed  
  • Source: OFFIS e.V. ( Christian Mrugalla)
  • Summary:

    The undefined term 'Element::redefinedElement' occurs three times in the standard where 'RedefinableElement::redefinedElement' is expected.

  • Reported: UML 2.1.2 — Thu, 13 Mar 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • 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:58 GMT

Section: 7.4 figure 7.1 missing dependency

  • Key: UML22-419
  • Legacy Issue Number: 12749
  • Status: closed  
  • Source: YTCA ( Trent Lillehaugen)
  • Summary:

    The first sentence of 7.4 states: As was depicted in Figure 7.1, the Profiles package depends on the Core package, .... Figure 7.1 does not shown any dependency between the Profiles package and the Core package

  • Reported: UML 2.1.2 — Tue, 5 Aug 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • 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:58 GMT

UML2: Need a better mechanism for integrating UML2 Profiles

  • Key: UML22-418
  • Legacy Issue Number: 12587
  • Status: closed  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    UML2 Superstructure specifies how to define a Profile, how Profiles can reference other Profiles through PackageImport and ElementImport, and how one stereotype could extend another through generalization/specialization. However, this is insufficient for profile integration as it results in too much coupling between profiles. What is needed is a more flexible mechanism for integrating UML2 profiles.

    For example, both UPDM and SysML are UML2 profiles. UPDM would like to reuse certain stereotypes from SysML in order to provide effective integration in cases where consumers want to use both. However, UPDM would also like to be able to stand alone in cases where SysML isn't needed. The problem is how to model the overlapping stereotypes and classes without creating coupling that would require all applications of the UPDM profile to also require an application of SysML.

    Consider a concrete example of overlap between the profiles, the stereotype ViewPoint. Both UPDM and SysML have a similar concept of ViewPoint, for similar purposes. However, each has its own specializations of ViewPoint, and possibly associations between ViewPoint and other stereotypes. There are a number of approaches for handling this overlap, but none are adequate or practical.

    1. Profile refactoring: Each profile could factor its stereotypes into packages, and arrange the navigability of its associations to decouple its stereotypes in order to support anticipated reuse. This is what UML2 did, quite unsuccessfully, with the Abstractions packages. This isn't practical because 1) no existing profiles do it, 2) it is impossible to anticipate all the possible reuse opportunities and to design a profile to support them, and 3) it is sometimes impossible to define the associations between stereotypes to ensure the necessary decoupling.

    2. Use ElementImport to select only the stereotypes you need, then subclass to minimize the coupling: This can work, but it results in complex profiles with possibly a lot of subclasses simply to integrate with other profiles. For example, UPDM couldn't use ViewPoint directly, it would have to create a subclass, either coming up with a new name, or putting its ViewPoint in a different Package so that it wouldn't collide with SysML. This is confusing, and results in stereotypes with either the same meaning but different names, or two stereotypes with the same name in different packages. This also requires both profiles to exist, even though the both don't need to be applied. This is again an undesirable side-effect of too much coupling.

    Both of these approaches end up inhibiting profile integration and reuse resulting in limited integration between OMG submissions. UPMS had wanted to include integrations with many other submissions including RAS, BPDM, BPMN, ODM, QoS, and BMM. However we could not determine a practical way to do this with current technologies and did not include many of these integrations because of the resulting risk, complexity and coupling. This is a particular problem when we consider the OMG specifications, profiles, and metamodels in an enterprise architecture context where the relationships between the parts are critical to delivering value.

    UML2 provides a solution to this problem for extensions created using MOF metamodels to model capabilities. PackageMerge can be used to merge metaclasses with the same name from different capabilities in order to mixin their capabilities. What is needed is a similar capability for UML2 profiles.

    A proposed solution would be to extend UML2 Profiles to include similar merge semantics when multiple profiles containing the same classes or stereotypes are applied to the same model. When a Profile is applied to a Package, the Classes and Stereotypes in the Profile would be merged with Classes and Stereotypes of other Profiles that have already been applied. The rules for PackageMerge can be used to define how this merge is done as they already apply to Class, and can equally apply to Stereotype which is a specialization of Class. Conflicts resulting from the merge could be considered defects against the profiles that could be handled in an RTF.

    Consider the same example above; both UPDM and SysML define ViewPoint.

    3. Profile Merge: The UPDM submitters would be careful to use ViewPoint is a manner that is semantically consistent with SysML since SysML already existed. However UPDM conuld extend ViewPoint with additional properties and associations for its purposes. The UPDM submission could note to users that ViewPoint is a stereotype in UPDM that represents a "placeholder" to ViewPoint in SysML. Users could then apply UPDM to a model, and get UPDM's ViewPoint capabilities without any coupling or need for SysML. Later on, another user could decide to apply SysML to the same model in order to use its modeling capabilities. The SysML::ViewPoint would be merged with the UPDM::ViewPoint allowing the shared semantics to be supported without making any changes to the existing model. Similarly, users could have started with SysML and later applied UPDM to achieve the same effect.

    This is a significant change to UML2, but may be an urgent issue due to the number of other profiles and submissions looking for a solution to this problem.

  • Reported: UML 2.1.2 — Thu, 24 Jul 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Regression in XMI from UML 2.1.2 to UML 2.2

  • Key: UML22-421
  • Legacy Issue Number: 12774
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    At 03:12 PM 8/13/2008, Pete Rivett wrote:

    Well-spotted Nicolas: though from your example fragments you’re wrong to say that at 2.2 the ends are given a generic name – they are given a generic xmi:id and no name at all!
    Both the change of name and (to a lesser extent) xmi:id, without being mandated by an issue resolution are IMHO serious bugs.
    The xmi:id case is more controversial, since xmi:ids do not in general have to be stable. However, since they are frequently used for referencing the elements from outside the file (e.g. using XMI hrefs) then for standard metamodels I think we should keep them stable.

    In fact I’d say that we should probably treat this as an urgent issue and produce a new XMI file ASAP.

    >From the difference between the 2 fragments I spotted another discrepancy/bug in UML 2.2 – there is an incorrect owningAssociation attribute on the Property. This must not be serialized since it’s the opposite of the composite owner of the Property (Association.ownedEnd) and so redundant.

    Clearly we should do more to perform diffs between the different versions of XMI files in order to catch inadvertent changes such as this.

    Pete

    From: Nicolas Rouquette [ nicolas.rouquette@jpl.nasa.gov]
    Sent: 13 August 2008 19:15
    To: uml2-rtf@omg.org; executableUMLFoundation@omg.org; Conrad Bock; Bran Selic; Ed Seidewitz; Stephen Mellor
    Subject: unalabelled association-owned memberEnd property names affect the name of an association

    I noticed strange differences between the XMI serialization of the UML superstructure in:

    UML 2.1.2, i.e: http://www.omg.org/spec/UML/20061001/Superstructure.cmof
    UML 2.2 beta1, i.e: http://www.omg.org/cgi-bin/doc?ptc/08-05-12

    For example, in UML 2.1.2, we have:

    <ownedMember xmi:type="cmof:Association" xmi:id="Actions-CompleteActions-A_result_readExtentAction" name="A_result_readExtentAction" memberEnd="Actions-CompleteActions-ReadExtentAction-result Actions-CompleteActions-A_result_readExtentAction-readExtentAction">
    <ownedEnd xmi:type="cmof:Property" xmi:id="Actions-CompleteActions-A_result_readExtentAction-readExtentAction" name="readExtentAction" lower="0" type="Actions-CompleteActions-ReadExtentAction" association="Actions-CompleteActions-A_result_readExtentAction"/>
    </ownedMember>

    whereas in UML 2.2beta1, we have:

    <ownedMember xmi:type="cmof:Association" xmi:id="Actions-CompleteActions-A_result_readExtentAction" name="A_result_readExtentAction" memberEnd="Actions-CompleteActions-ReadExtentAction-result Actions-CompleteActions-A_result_readExtentAction-_ownedEnd.0">
    <ownedEnd xmi:type="cmof:Property" xmi:id="Actions-CompleteActions-A_result_readExtentAction-_ownedEnd.0" type="Actions-CompleteActions-ReadExtentAction" lower="0" owningAssociation="Actions-CompleteActions-A_result_readExtentAction" association="Actions-CompleteActions-A_result_readExtentAction"/>
    </ownedMember>

    In both cases, this association is described in Fig. 11.13 Object Actions (CompleteActions) in a way where the name of an association-owned memberEnd property isn't shown whereas the name of a class-owned memberEnd property is shown according to the conventions specified in clause 6.4.2 of the UML superstructure spec.

    http://www.omg.org/cgi-bin/doc?ptc/08-05-05
    http://www.omg.org/spec/UML/2.1.2/Superstructure/PDF/

    The problem here is that the unlabelled association-owned memberEnd properties have been given generic names such as ownedEnd.0 instead of the convention defined in clause 6.4.2 – i.e., the name of the class with a lowercase initial.

    Is it OK for association names to change in this manner from one rev to another or is this a bug?

    Regardless of whether it is a bug or not w.r.t. current OMG specs, there is certainly a very undesirable consequence in name-level changes between revisions for a given concept when these revisions have not changed the semantics of that concept. Such incidental name-level changes create a lot of problems w.r.t. a stable notion of identity across revisions for detecting semantically-relevant changes from semantically irrelevant changes.

  • Reported: UML 2.1.2 — Wed, 13 Aug 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • 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:58 GMT

Section: 2.2-2.4 compliance level clarifiction needed

  • Key: UML22-420
  • Legacy Issue Number: 12750
  • Status: closed  
  • Source: YTCA ( Trent Lillehaugen)
  • Summary:

    Section 2.2 introduces two compliance levels: L0 and LM. Section 2.3 states: "Compliance to a given level entails full realization of all language units that are defined for that compliance level. This also implies full realization of all language units in all the levels below that level. “Full realization” for a language unit at a given level means supporting the complete set of modeling concepts defined for that language unit at that level. Thus, it is not meaningful to claim compliance to, say, Level 2 without also being compliant with the Level 0 and Level 1." This is confusing as there is no such thing as Level 1 or Level 2 defined. This concept is repeated in section 2.4: "(as a rule, Level (N) includes all the packages supported by Level (N-1))" It may be worth mentioning that the superstructure document will introduce further levels on top of the infrastructure level L0. Also, if I understand it correctly: LM builds on L0, and so does L1. So we have two parallel paths of compliance: L0 <- LM and L0 <- L1 <- L2 <- L3 So how does LM fit in with the L(N) compliant is also L(N-1) compliant scheme? Do you need to specify L2 and LM compliance?

  • Reported: UML 2.1.2 — Tue, 5 Aug 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • 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:58 GMT

Unspecified constraint [1] on AcceptEventAction

  • Key: UML22-424
  • Legacy Issue Number: 12782
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    Source: UML 2.2 Superstructure document and XMI

    http://www.omg.org/cgi-bin/doc?ptc/08-05-05
    http://www.omg.org/cgi-bin/doc?ptc/08-05-12

    Nature: Unspecified OCL constraint

    Summary:

    The following constraint on AcceptEventAction (11.3.2) is unspecified:

    [1] AcceptEventActions may have no input pins.

    Discussion:

    OCL 101.

    Revised Text:

    Change the specification of the constraint to the following:

    [1] AcceptEventActions may have no input pins.
    self.input->isEmpty()

  • Reported: UML 2.1.2 — Fri, 15 Aug 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Merged with 8702

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Incorrect OCL expression for constraint [1] on BehavioredClassifier

  • Key: UML22-423
  • Legacy Issue Number: 12781
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    Source: UML 2.2 Superstructure document and XMI

    http://www.omg.org/cgi-bin/doc?ptc/08-05-05
    http://www.omg.org/cgi-bin/doc?ptc/08-05-12

    Nature: incorrect OCL constraint

    Summary:

    The following constraint on BehavioredClassifier (13.3.4) is incorrectly specified:

    [1] If a behavior is classifier behavior, it does not have a specification.
    self.classifierBehavior->notEmpty() implies self.specification->isEmpty()

    Discussion:

    self.specification does not resolve to any attribute of BehavioredClassifier.
    self.classifierBehavior resolves to a Behavior which can have 0 or 1 BehavioralFeature specification.
    Hence, the correct OCL navigation expression should be self.classifierBehavior.specification instead of self.specification.

    Revised Text:

    Change the specification of the constraint to the following:

    [1] If a behavior is classifier behavior, it does not have a specification.
    self.classifierBehavior->notEmpty() implies self.classifierBehavior.specification->isEmpty()

    Change the Superstructure XMI accordingly.

  • Reported: UML 2.1.2 — Fri, 15 Aug 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

OCL 2.0 8.2 Real

  • Key: UML22-415
  • Legacy Issue Number: 12583
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    OCL reuses Boolean, Integer, String, UnlimitedNatural from UML Infrastructure.

    OCL uses Real in a very similar fashion, but there is no corresponding
    definition of Real in either OCL or UML Infrastructure.

  • Reported: UML 2.1.2 — Sat, 19 Jul 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    The primitive type “Real” needs to be added to the PrimitiveTypes package for consistency with the OCL Real type. “Real” has also been defined separately by SysML and MARTE specifications and the new Diagram Definition Submission, so adding it to the PrimitiveTypes package will encourage reuse.
    Another argument for adding a primitive type “Real” is that there is currently no normative way to notate real numerals in UML models. So, even if some model library adds a “Real” primitive type, there is technically still no normative way to write a literal for that type in a UML model. This suggests the need for a Real Literal definition as well.
    (Note that the revised text below presumes the resolution to Issue 13993.)

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML2 issue regarding RedefinableTemplateSignature

  • Key: UML22-414
  • Legacy Issue Number: 12580
  • Status: closed  
  • Source: International Business Machines ( James Bruck)
  • Summary:

    UML Superstructure V2.2, Section 17.5.9 RedefinableTemplateSignature.

    The paragraph in the "Semantics" section RedefinableTemplateSignature mentions the following:
    All the formal template parameters of the extended signatures are included as formal template parameters of the extending signature, along with any parameters locally specified for the extending signature.

    I beleive this would imply that the "parameter" feature would need to be derived which it is currently not.

  • Reported: UML 2.1.2 — Fri, 18 Jul 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    /inheritedParameter is indeed derived and is a subset of parameter, which corresponds to the semantics.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Unspecified constraint [1] on ActivityEdge (CompleteStructuredActivities)

  • Key: UML22-427
  • Legacy Issue Number: 12785
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    Source: UML 2.2 Superstructure document and XMI

    http://www.omg.org/cgi-bin/doc?ptc/08-05-05
    http://www.omg.org/cgi-bin/doc?ptc/08-05-12

    Nature: Unspecified OCL constraint

    Summary:

    The following constraint on ActivityEdge (12.3.5) is unspecified:

    Package CompleteStructuredActivities
    [1] Activity edges may be owned by at most one structured node.

    Discussion:

    OCL 101.

    Revised Text:

    Change the specification of the constraint to the following:

    Package CompleteStructuredActivities
    [1] Activity edges may be owned by at most one structured node.
    self.inStructuredNode->notEmpty() implies
    (self.inStructuredNode.oclAsType(ActivityGroup)->includesAll(self.inGroup)
    and self.inStructuredNode.oclAsType(Element)->includes(self.owner))

    Change the Superstructure XMI accordingly.

  • Reported: UML 2.1.2 — Fri, 15 Aug 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    This issue is obsolete. All constraints have been specified in UML 2.5.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Unspecified constraint [2] on ActivityEdge

  • Key: UML22-426
  • Legacy Issue Number: 12784
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    Source: UML 2.2 Superstructure document and XMI

    http://www.omg.org/cgi-bin/doc?ptc/08-05-05
    http://www.omg.org/cgi-bin/doc?ptc/08-05-12

    Nature: Unspecified OCL constraint

    Summary:

    The following constraint on ActivityEdge (12.3.5) is unspecified:

    [2] Activity edges may be owned only by activities or groups.

    Discussion:

    OCL 101.

    Revised Text:

    Change the specification of the constraint to the following:

    [2] Activity edges may be owned only by activities or groups.
    self.source.activity = self.activity and self.target.activity = self.activity

    Change the Superstructure XMI accordingly.

  • Reported: UML 2.1.2 — Fri, 15 Aug 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    This issue is obsolete. All constraints have been specified in UML 2.5.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Unspecified constraint [2] on Activity

  • Key: UML22-429
  • Legacy Issue Number: 12787
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    Source: UML 2.2 Superstructure document and XMI

    http://www.omg.org/cgi-bin/doc?ptc/08-05-05
    http://www.omg.org/cgi-bin/doc?ptc/08-05-12

    Nature: Unspecified OCL constraint

    Summary:

    The following constraint on Activity (12.3.4) is unspecified:

    [2] An activity cannot be autonomous and have a classifier or behavioral feature context at the same time.

    Discussion:

    OCL 101.

    Revised Text:

    Change the specification of the constraint to the following:

    [2] An activity cannot be autonomous and have a classifier or behavioral feature context at the same time.
    self.isActive implies (self.getContext()>isEmpty() and self.classifierBehavior>isEmpty())

    Change the Superstructure XMI accordingly.

  • Reported: UML 2.1.2 — Fri, 15 Aug 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    This issue is obsolete. All constraints have been specified in UML 2.5.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Unspecified constraint [1 on Activity

  • Key: UML22-428
  • Legacy Issue Number: 12786
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    Source: UML 2.2 Superstructure document and XMI

    http://www.omg.org/cgi-bin/doc?ptc/08-05-05
    http://www.omg.org/cgi-bin/doc?ptc/08-05-12

    Nature: Unspecified OCL constraint

    Summary:

    The following constraint on Activity (12.3.4) is unspecified:

    [1] The nodes of the activity must include one ActivityParameterNode for each parameter.

    Discussion:

    OCL 101.

    Revised Text:

    Change the specification of the constraint to the following:

    [1] The nodes of the activity must include one ActivityParameterNode for each parameter.
    self.node->select(oclIsKindOf(ActivityParameterNode)).oclAsType(ActivityParameterNode).parameter->asSet()>symmetricDifference(self.ownedParameter>asSet())->isEmpty()

    Change the Superstructure XMI accordingly.

  • Reported: UML 2.1.2 — Fri, 15 Aug 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    This issue is obsolete. All constraints have been specified in UML 2.5.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 7.3.50 "substitution"

  • Key: UML22-417
  • Legacy Issue Number: 12586
  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    As describe, a "Substitution" looks more like a derived property than like a relationship, except if it must be interpreted as an explicit inheritence restricted to the external contracts (with possible redefinition). The point is that is not clear with the current description

  • Reported: UML 2.1.2 — Thu, 24 Jul 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    The revised text in UML 2.5 is clearer.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Keyword ambiguity for DataType Section

  • Key: UML22-416
  • Legacy Issue Number: 12584
  • Status: closed  
  • Source: ModelFoundry ( Sam Mancarella [X] (Inactive))
  • Summary:

    Keyword ambiguity for DataType Section 7.3.11 Describes the use of the 'dataType' keyword (along with Figure 7.36). Whereas, the example depicted in Figure 7.39 shows a DataType with the 'datatype' keyword.

  • Reported: UML 2.1.2 — Wed, 23 Jul 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • 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:58 GMT

Unspecified constraint [1] on ActivityEdge

  • Key: UML22-425
  • Legacy Issue Number: 12783
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    Source: UML 2.2 Superstructure document and XMI

    http://www.omg.org/cgi-bin/doc?ptc/08-05-05
    http://www.omg.org/cgi-bin/doc?ptc/08-05-12

    Nature: Unspecified OCL constraint

    Summary:

    The following constraint on ActivityEdge (12.3.5) is unspecified:

    [1] The source and target of an edge must be in the same activity as the edge.

    Discussion:

    OCL 101.

    Revised Text:

    Change the specification of the constraint to the following:

    [1] The source and target of an edge must be in the same activity as the edge.
    self.source.activity = self.activity and self.target.activity = self.activity

    Change the Superstructure XMI accordingly

  • Reported: UML 2.1.2 — Fri, 15 Aug 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Change the specification of the constraint to the following:

    [1] The source and target of an edge must be in the same activity as the edge.
    let edgeActivity:Set(Activity) = self.inGroup->closure(inGroup).inActivity->asSet()>union(self.activity>asSet()) in
    let sourceActivity:Set(Activity) = self.source.inGroup->closure(inGroup).inActivity->asSet() in
    let targetActivity:Set(Activity) = self.source.inGroup->closure(inGroup).inActivity->asSet() in
    edgeActivity->symmetricDifference(sourceActivity)->isEmpty() and
    edgeActivity->symmetricDifference(targetActivity)->isEmpty()

    Change the Superstructure XMI accordingly.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 9.3.8

  • Key: UML22-422
  • Legacy Issue Number: 12775
  • Status: closed  
  • Source: YTCA ( Trent Lillehaugen)
  • Summary:

    There is an association of EncapsulatedClassifier (9.3.8) ownedPort which is derived and subsets Class::ownedAttribute. The problem I have is that I don't see how ownedPort can subset Class::ownedAttribute. I don't see an inheritance path from EncapsulatedClassifier to Class. Also, which Class is it referring to? Class (from Kernel), Class (from StructuredClasses), etc. This problem exists for all "subsets" statements in the specification. Thank you.

  • Reported: UML 2.1.2 — Thu, 14 Aug 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    It should in fact refer to StructuredClassifier::ownedAttribute

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 10.3.10

  • Key: UML22-406
  • Legacy Issue Number: 12545
  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    Shouldn't be a constraint or a redefinition in order to specify that the client of a manisfestation is its owning artefact?

  • Reported: UML 2.1.1 — Mon, 23 Jun 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    The requested logic is already provided because artifact subsets owner. Since artifact also subset client, the artifact is
    clearly identified as the client. No additional constraints are required.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

definition of RedefinableElement::isLeaf

  • Key: UML22-405
  • Legacy Issue Number: 12532
  • Status: closed  
  • Source: International Business Machines ( James Bruck)
  • Summary:

    Version of Spec: 2.1.1 2007--2-05, Section 7.3.46 p.130

    The definition of RedefinableElement::isLeaf indicates that "If the value is true, then it is not possible to further specialize the RedefinableElement". However there is no explicit constraint that actually enforces this (at least none that I could find). I believe that a constraint should be created to address this.

  • Reported: UML 2.1.2 — Tue, 17 Jun 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    This issue is not a duplicate of issue 9831 which is closely related to issue 10515.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Behavior's parameter list

  • Key: UML22-404
  • Legacy Issue Number: 12530
  • Status: closed  
  • Source: International Business Machines ( James Bruck)
  • Summary:

    We are concerned with the UML specification forcing an Behavior's parameter list to be in sync with its behavioral feature.

    >From the UML 2.1.1 07-02-03, page 431 (or 445/732) it states in the 13.3.2 Behaviors section the following constraint:
    [1] The parameters of the behavior must match the parameters of the implemented behavioral feature

    We feel that this constraint is unnecessary. The parameter list of a Behavior element can be derived from its behavioral feature. Forcing the Behavior to have its own list of parameters has practical implementation problems such as needlessly increasing the size of the UML model, and worse, forcing one to preform the tedious task (or the tool to preform the extra overhead) of keeping the parameter lists of the Behavior and its behavioral feature in sync.

    We would like to request that this constraint is removed from the specification.

  • Reported: UML 2.1.2 — Fri, 13 Jun 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Merged with 7626

  • Updated: Fri, 6 Mar 2015 20:58 GMT

PackageMerge relationships

  • Key: UML22-403
  • Legacy Issue Number: 12528
  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    The way the PackageMerge relatrionships are used in the specification doesn't seem to be rigorous or, at least, are not clear. For instance: * §7.3.7 indicates that the "Class" from Kernel metaclass is a specialization of “Classifier (from Kernel, Dependencies, PowerTypes)”. That is not correct if you refere to the corresponding package diagram: "Class" from Kernel doesn't inherit from Dependencies and PowerType merge increment of "Classifier" * §7.3.6 "BehavioredClassifier" from Interfaces) is a merge increment of "BehavioredClassifier" from BasicBehavior) but not for "BehavioredClassifier" from Communications (it's the opposite). * etc... Then, i suggest to define PackageMerge relationships of the metamodele in a more formal way than simple diagrams and to validate that metaclass definition are consistent with these relationships.

  • Reported: UML 2.1.2 — Tue, 10 Jun 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • 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:58 GMT

Section: 7.3.36

  • Key: UML22-413
  • Legacy Issue Number: 12569
  • Status: closed  
  • Source: Motorola ( Andrzej Zielinski)
  • Summary:

    Problem 6. 6.1 Operation is having very wide type (Type) as an exception instance (raisedException). Theoretically it is possible that Association may be thrown as an exception. ++++++++++++++++++++++++++++++++++++++++++ from Bran Selic <bran.selic@gmail.com> hide details Jun 9 to Andrzej Zielinski <072404@gmail.com> date Jun 9, 2008 7:46 PM subject Re: UML 2.x issues mailed-by gmail.com Bran Selic: Agreed. I wish that this was the only place where the metamodel suffers from overgeneralization. Unfortunately, this is almost endemic in how things are done in UML.

  • Reported: UML 2.1.2 — Thu, 10 Jul 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    If we were to constrain the type of exceptions, we might invalidate user models. There seems no reason to make a
    change here.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.30,12.3.23

  • Key: UML22-412
  • Legacy Issue Number: 12567
  • Status: closed  
  • Source: Motorola ( Andrzej Zielinski)
  • Summary:

    Problem 4 4.1. Exceptions raising is provided on L2 compliance level (RaiseExceptionAction from Actions/StructuredActions) while handling is provided on L3 (ExceptionHandler from Activities/ExtraStructerdActivities). That functionality is an integrated part and raising and handling exceptions should be provided on the same compliance level. ++++++++++++++++++++++++++++++++++++++++++++ from Bran Selic <bran.selic@gmail.com> hide details Jun 9 to Andrzej Zielinski <072404@gmail.com> date Jun 9, 2008 7:46 PM subject Re: UML 2.x issues mailed-by gmail.com Bran Selic: Agreed. We did not focus too much on the modeling of exceptions – it was not a priority item at the time. It should probably be so now. Your work is definitely timely. Andrzej Zielinski: That is about my Ph.D thesis

  • Reported: UML 2.1.2 — Thu, 10 Jul 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    This issue is obsolete. There are no compliance levels in UML 2.5.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 13.3.3

  • Key: UML22-410
  • Legacy Issue Number: 12564
  • Status: closed  
  • Source: Motorola ( Andrzej Zielinski)
  • Summary:

    Problem 2 2.1 Relation raisedException of Operation and BehavioralFeature classes not consistently set (CommonBehaviors/Communications) (L2 compliance). Operation (Classes/Kernel) (L1 compliance level ) inherits from BehavioralFeature (Classes/Kernel) (L1) and redefines raisedException to Type. On that level there is no problem. But in CommonBehaviors/Communications BehavioralFeature redefines raisedExceptions to point to Classifier. As a result Operation points to Type, while BehavioralFeature to Classifier. Classifier is more specific than Type (Classifier inherits from Type) +++++++++++++++++++++++++++++++++++++++++++ from Bran Selic <bran.selic@gmail.com> hide details Jun 9 to Andrzej Zielinski <072404@gmail.com> date Jun 9, 2008 7:46 PM subject Re: UML 2.x issues mailed-by gmail.com Bran Selic: Yes, that is a problem. I will relay it on to the OMG to be officially registered.

  • Reported: UML 2.1.2 — Thu, 10 Jul 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    There does not seem to be any reason for Communications::BehavioralFeature to have a raisedException attribute. It is not used anywhere in Communications. Kernel::BehavioalrFeature already has a raisedException property that will be included when the BehavioralFeature merge increments are actually merged.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.2

  • Key: UML22-411
  • Legacy Issue Number: 12565
  • Status: closed  
  • Source: Motorola ( Andrzej Zielinski)
  • Summary:

    Problem 1 Some classes in certain packages are abstract, while they are not in packages that are on a higher (or the same) compliance level. 1.3. Pin in Activities/BasicActivities (L1 compliance level) (Fig. 12.4 p.299 ) and Activities/CompleteActivities (L3) (Fig.12.16 p. 305) are not abstract, while in they are in package ActionsBasicActions (L1) (Fig. 11.3 p. 221) ++++++++++++++++++++++++++++++++++++++++++ from Bran Selic <bran.selic@gmail.com> hide details Jun 9 to Andrzej Zielinski <072404@gmail.com> date Jun 9, 2008 7:46 PM subject Re: UML 2.x issues mailed-by gmail.com Bran Selic: Yes, that is a problem. I will relay it on to the OMG to be officially registered.

  • Reported: UML 2.1.2 — Thu, 10 Jul 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

The behavior of an OpaqueExpression should itself be opaque

  • Key: UML22-408
  • Legacy Issue Number: 12557
  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    The behavior of an OpaqueExpression should itself be opaque

  • Reported: UML 2.1.2 — Wed, 25 Jun 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Under Subclause 13.3.21, it says that the extension to OpaqueExpression "Provides a mechanism for precisely defining the behavior of an opaque expression." It is hard to see how one can precisely define behavior, if the behavior is itself opaque. Indeed, specifying the behavior of an OpaqueExpression with, say, an activity is the only way to model an expression in UML in terms of executable actions, so this should not be precluded.
    Revised Text:
    None.
    Disposition: Closed No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 13.3.23

  • Key: UML22-409
  • Legacy Issue Number: 12558
  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    The multiplicity of the "signal" property of a Reception is [0..1]. What's the semantic of a Reception that would be associated with no signal?

  • Reported: UML 2.1.2 — Wed, 25 Jun 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Areception should be required to specify a signal.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Classifiers

  • Key: UML22-402
  • Legacy Issue Number: 12516
  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    Classifiers are specialized to hold useCase properties in the UseCases package but this package is not merged/imported by any other ones. Does it formally mean that - for instance - no version of the metaclass "Class" should be able to hold use cases?

  • Reported: UML 2.1.2 — Wed, 4 Jun 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • 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:58 GMT

Section: 7.3.35

  • Key: UML22-407
  • Legacy Issue Number: 12556
  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    In order to be complinat with the semantics, "body" and "language" properties of an OpaqueExpression shall be ordered

  • Reported: UML 2.1.2 — Wed, 25 Jun 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Packaging Issues with Stereotype Extension

  • Key: UML22-468
  • Legacy Issue Number: 13306
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    Section: 18.3.2 (Extension)

    Extension::metaclass has the type Class. When the Profiles package is merged into L2, Profiles::Class is merged into L2::Class. This means that the metaclass for an extension has to be represented as a UML Class (at L2 or, after further merging, at L3).

    However, the UML abstract syntax metamodel is not actually a UML model, but a CMOF model. This means that UML metaclasses are instances of CMOF::Class, not UML::Class (at L2 or L3). This means that it is not possible to actually construct a stereotype extension that points to a metaclass representation of the correct type.

    UML tools currently get around this my referencing metaclasses from a version of the UML abstract syntax metamodel that is expressed in terms of UML L3, rather than CMOF. Or they just don't worry about the type checking. But that is not technically correct, and it means that stereotypes in each tool are referencing non-normative representations of the UML metamodel, rather than standard metaclass object IDs.

  • Reported: UML 2.1.2 — Tue, 20 Jan 2009 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    The problem is resolved by shipping a normative version of the UML metamodel expressed in terms of UML, and changing the text accordingly.
    A couple of decisions need making about this metamodel, which we?ve discussed extensively in email:
    1. Which compliance level of UML is used to create it? We?ll use the lowest compliance level that we can, which is L1. This means we cannot use Model, so the root of the metamodel will be a uml:Package.
    2. Do we apply any stereotypes such as «metamodel» or «metaclass» in the normative UML model? The answer is no and follows from (1): since we don?t use Model, we cannot use «metamodel». Also, using stereotypes in order to specify stereotypes (see 14092) might give circularity or fixed-point issues. We are justified in omitting these by the wording of PresentationOptions in 18.3.1: “A Class that is extended by a Stereotype may be extended by the optional stereotype «metaclass» …”

  • Updated: Fri, 6 Mar 2015 20:58 GMT

inconsistency with how constraints are specified in UML and OCL

  • Key: UML22-467
  • Legacy Issue Number: 13258
  • Status: closed  
  • Source: International Business Machines ( James Bruck)
  • Summary:

    In OCL 2.0 specification, section Operation Body Expression, it specifies that
    expression must conform to the result type of the operation.

    However, in UML 2.1.2 specificaiton, it is specified that bodyCondition of an
    operation is a constratin which must evaluates to a boolean expression.

    The problem is that UML equates the term "constraint" with "boolean-valued
    expression that holds true at some time." The OCL usage of the term is not so
    narrow. A constraint is a model element that specifies more precise semantics
    for another model element than what its structure alone can achieve.

    So, for example, an attribute constrains its values to conform to some type,
    but a derivation expression (whose value conforms to the attribute type) more
    precisely constrains its values. Likewise the operation body expression
    constrains the value of an operation by computing it from the parameters and
    the context object. Note that OCL actually calls this constraint a "body
    expression," not a "body condition" as UML does. OCL's notion of "constraint"
    even extends to definition of helper operations and attributes.

    Consider what it means to require boolean values for operation body
    constraints. They must be formulated like postconditions, as boolean
    expressions on the "result" variable. In OCL, the body condition does not have
    a "result" variable; only post-conditions have it. Furthermore, consider an
    example: an operation phi() defined in the Real primitive type. According to
    UML's rules, it could be defined like this:

    context Real::phi() : Real
    body: result = (1.0 + 5.0.sqrt()) / 2.0

    or like this:

    context Real::phi() : Real
    body: (result - 1.0) = (1.0 / result)

    These are isomorphic constraints, but neither is friendly to OCL tool
    implementations (certainly not the second). According to OCL, the constraint
    would by formulated like this:

    context Real::phi() : Real
    body: (1.0 + 5.0.sqrt()) / 2.0

    and there really is no other kind of formulation. IMO, this is much more
    practical for all concerned.

    Consider an operation that has parameters, for which I write an ineffectual
    body constraint like this:

    context Foo::doSomething(bar1 : Bar, bar2 : Bar) : Baz
    body: bar1 <> bar2

    What does this mean?

    All in all, it is far mare useful to have an OCL expression that can readily be
    evaluated to compute the value of the operation. This leaves no room for
    ambiguity.

    The UML stipulation that Constraints in all contexts must be boolean
    expressions, as in operation precondition and classifier invariant context, is
    unnecessary. What is the benefit? It would be nice to see it removed in UML
    2.3.

  • Reported: UML 2.1.2 — Wed, 14 Jan 2009 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    merged with 15259

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Allowing multiple Associations in a Package with the same name

  • Key: UML22-470
  • Legacy Issue Number: 13330
  • Status: closed  
  • Source: Anonymous
  • Summary:

    I had a recent ‘argument’ with Steve Cook on his blog. There is a lot of confusion with regards to whether there can be multiple Associations with the same name in a Package. Steve made the valid point that Association does not redefine “isDistinguishableFrom”, which it gets from being a NamedElement. This is overridden for BehavioralFeature, but not for Association, thus based on that rule from NamedElement, I assume that there may not be multiple Associations with the same name (including empty) in a Package.

    However, I came across the following cases that seem to ignore this notion:

    1) In the rules for PackageMerge (7.3.40), they allow for the ability to have multiple Associations with the same name by taking into account their member ends: “Elements that are a kind of Association match by name (including if they have no name) and by their association ends where those match by name and type (i.e., the same rule as properties).”

    2) The MOF 2.0 XMI file almost never names its’ Associations, thus having many Associations with the same name.

    3) The UML 2.1.1 Superstructure XMI file also has multiple associations with the same name. As an example, see the package with id “AuxiliaryConstructs-Templates”. It owns 3 associations with the name “A_templateParameter_parameteredElement” (ids “A_templateParameter_parameteredElement”, “A_templateParameter_parameteredElement.1” and “A_templateParameter_parameteredElement.2”).

    Is it intended that multiple Associations with the same name be allowed in a Package or not? If not, then we need to fix Superstructure, MOF, and we can also relax the PackageMerge rule for Associations. If we do allow it, then we should add a new redefinition of “isDistinguishableFrom” for Association that specifies a similar rule to the one described in PackageMerge, that an Association type is distinguishable from another Association if the set of its name and the names of all its member ends is not equal to the corresponding set of the other Association.

  • Reported: UML 2.1.2 — Thu, 27 Nov 2008 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    A redefine of isDistinguishableFrom for Association is not desired. As such, the PackageMerge rule for Association, which implies the possibility of multiple Associations in a Package with the same name, including if they have no name, provided their member ends differ in some way, is to be amended as it can result in ill-formed merged Packages. This is supported by the following 2 constraints:

    1. MOF 2.0 Specification, under section "12.4 EMOF Constraints" there is the following constraint (which would be violated if the Associations have no name):
    "[3] Names are required for all Types and Properties (though there is nothing to prevent these names being automatically generated by a tool)."

    2. In "9.14.2 Namespace" of the UML 2.1.2 Infrastructure Specification there is the following constraint (which would be violated if the Associations have the same name):
    "[1] All the members of a Namespace are distinguishable within it."

    As such, explicit rules are also to be added to PackageMerge requiring well-formedness of the merged Package.

    The XMI elements cited as examples of clashing Association names are to be renamed.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

P479L.14 Section "Notation" in 14.3.10 ExecutionOccurences - Typo

  • Key: UML22-469
  • Legacy Issue Number: 13327
  • Status: closed  
  • Source: Architecture Technology Institute ( Hiroshi Miyazaki)
  • Summary:

    Regarding UML 2.2 Superstructure

    P479L.14 Section "Notation" in 14.3.10 ExecutionOccurences

    ExecutionOccurences
    ~~

  • Reported: UML 2.1.2 — Fri, 23 Jan 2009 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Figure 18.2 (which describes the contents of the Profiles package) is currently misleading

  • Key: UML22-472
  • Legacy Issue Number: 13844
  • Status: closed  
  • Source: PTC ( Phillip Astle)
  • Summary:

    Figure 18.2 (which describes the contents of the Profiles package) is currently misleading. On this diagram the majority of the elements have their specializations to infrastructure elements shown (either directly or indirectly). However, Class and Package (which are also infrastructure specializations) do not have their specializations shown. This makes them appear to be the superstructure Class and Package when they aren't (as the diagram is being shown in the context of the superstructure specification). I suggest that you add the missing specializations to make the diagram clearer. Due to the differences between infrastructure Class and superstructure Class, you wouldn't want to confuse them.

  • Reported: UML 2.1.2 — Mon, 30 Mar 2009 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • 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:58 GMT

ParameterableElement as a formal template parameter

  • Key: UML22-466
  • Legacy Issue Number: 13257
  • Status: closed  
  • Source: International Business Machines ( James Bruck)
  • Summary:

    Say we want to expose a ParameterableElement as a formal template parameter.
    If we want to create the following List<E>, then the template parameter would refer to some parameterable element E whose type we would have to choose (say uml:Class).
    Now, say we wanted to create List< Interface >, or List < Class >, or List < DataType >. I don't think we would be able to then create TemplateParameterSubstitution for all these elements since the type of formal and actual parameters are inconsistent.

    The problem is that we must pick a concrete type for that ParameterableElement - we can't for example use Classifier as the template parameter because it's abstract.

  • Reported: UML 2.1.2 — Wed, 14 Jan 2009 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    This is a general issue with the way TemplateParameters are handled in the UML abstract syntax, and it would require
    a major change in the approach to templates to resolve it in general. However, the specific (and most common) case
    mentioned in the issue, that of a template for which it is desired to expose a Classifier as a parameter, is actually
    covered by a special case in the specification.
    In the UML 2.5 specification, subclause 9.3.3 describes the semantics of ClassifierTemplateParameters, which are
    TemplateParameters where the parameteredElement is a Classifier, optionally constrained by a set of constraining-
    Classifiers. Toward the end of this section, it says “if the constrainingClassifier property is empty, there are no constraints
    on the Classifier that can be used as an argument.” Thus, in defining a template List<E>, it is possible for the
    parameteredElement of the formal TemplateParameter E to be a Class, but to still, in a binding for List, substitute for
    E with an argument that is any kind of Classifer (including Interface, DataType, etc.).
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML. Clarify relationship of Substitution and InterfaceRealization

  • Key: UML22-465
  • Legacy Issue Number: 13164
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    The specification of ClassifierTemplateParameter has a flag allowSubstitutable. The definition of ClassifierTemplateParameter::constrainingClassifier says “If the allowSubstitutable attribute is true, then any classifier that is compatible with this constraining classifier can be substituted”. What does “compatible” mean? If we look in Templates::Classifier we find this:

    Semantic Variation Points If template parameter constraints apply, then the actual classifier is constrained as follows. If the classifier template parameter:

    • has a generalization, then an actual classifier must have generalization with the same general classifier.

    • has a substitution, then an actual classifier must have a substitution with the same contract.

    • has neither a generalization nor a substitution, then an actual classifier can be any classifier.

    If template parameter constraints do not apply, then an actual classifier can be any classifier.

    Firstly, the spec for classifier template parameters needs to clarify what compatible means; and this clarification must surely include the possibility that the relationship between the constrainingClassifier and the template parameter can be an InterfaceRealization as well as a Substitution.

    Secondly, this text for Semantic Variation Points is weird. Presumably it means that the constraints on substitutability of ClassifierTemplateParameter are a SVP. If so it should say so, and the SVP text should be under ClassifierTemplateParameter.

    Finally, it appears that given the existence of Substitution, InterfaceRealization is completely redundant. A good simplification would be to eliminate InterfaceRealization altogether; failing that to make it a subclass of Substitution to clarify that it has contract compatibility semantics.

  • Reported: UML 2.1.2 — Wed, 17 Dec 2008 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Most of this issue is obsolete: these semantic variation points have been clarified in the text. Changing the metamodel
    as suggested in the final point would be too disruptive.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML2 section 8.3.1 OCL derivations on Component.provided and Component.required are still invalid

  • Key: UML22-462
  • Legacy Issue Number: 13146
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    The OCL definitions of how Component.provided and Component.required are still invalid, even though they were altered in 2.2. The subexpressions self.implementation and self.realizingClassifier, which appear in both derivations, are not valid: there are no such properties on Component.

  • Reported: UML 2.1.2 — Fri, 5 Dec 2008 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    It seems that the first "let" clause of each constraint is supposed to do what the second "let" actually does. So we'll delete the first one.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

transitionkind Constraints

  • Key: UML22-464
  • Legacy Issue Number: 13163
  • Status: closed  
  • Source: Individual ( Jerry Wang)
  • Summary:

    In transitionkind Constraints, the document said: [1] The source state of a transition with transition kind local must be a composite state. [2] The source state of a transition with transition kind external must be a composite state. Does these two constraint means that simple state can not have a outgoing transition?

  • Reported: UML 2.1.2 — Mon, 15 Dec 2008 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    The cited constraints are not present in the UML 2.5 version of the spec.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2.2 figure 8.10 has arrows the wrong way around

  • Key: UML22-463
  • Legacy Issue Number: 13147
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    The dependencies in 8.10 should surely point from the Component (the client) to the realizing Classifiers (the suppliers). Also there is a redundant sentence “Alternatively, they may be nested within the component shape” above that figure which is repeated below.

  • Reported: UML 2.1.2 — Fri, 5 Dec 2008 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    The first part of this issue is wrong (see resolution to 11008 for explanation). The notation for the diagram is wrong which will be fixed by 10651.
    The second part is correct.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML2.2 Section 9.3.1 Presentation Options section

  • Key: UML22-461
  • Legacy Issue Number: 13142
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    The Presentation Options section of 9.3.1 seems both inappropriately named and in entirely the wrong place. It is about usage dependencies, constructors and instance specifications and should appear somewhere in chapter 7.

  • Reported: UML 2.1.2 — Thu, 4 Dec 2008 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • 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:58 GMT

UML 2.2 Section 9.3.1 nested classes paragrpah in wrong chapter

  • Key: UML22-460
  • Legacy Issue Number: 13141
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    In Section 9.3.1 the second paragraph starts “A class acts as the namespace ...”. This semantic about nested classes is part of normal classes and should be moved to 7.3.7.

  • Reported: UML 2.1.2 — Thu, 4 Dec 2008 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • 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:58 GMT

Figure 2.2 contains more than four packages, description referes to four packages

  • Key: UML22-471
  • Legacy Issue Number: 13665
  • Status: closed  
  • Source: Institute for Defense Analyses ( Steven Wartik)
  • Summary:

    In the paragraph describing Figure 2.2, the text refers to "four packages". Figure 2.2 contains more than four packages. The corresponding figure in Version 2.0 of the Superstructure displayed four packages; presumably the text wasn't updated along with the figure.

  • Reported: UML 2.1.2 — Mon, 9 Mar 2009 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • 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:58 GMT

In normative XMI file for the metamodel, no Associations have a name.

  • Key: UML22-534
  • Legacy Issue Number: 7105
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    In the normative XMI file for the metamodel, no Associations have a
    name.
    The name is needed for generating APIs and (in some cases) XMI elements;
    and their absence actually makes UML2 an invalid MOF2 metamodel: MOF2
    Core has the following constraint for CMOF:
    [6] Names are required for all classifiers and features (though there is
    nothing to prevent these names being automatically generated by a tool).

    (Association is a classifier)

    We could get by with not having a name in the MDL and auto-generating a
    name into the XMI. This is in fact what the Unisys XMI plug-in did when
    no Association name was provided - and this was hence reflected in the
    normative XMI for UML 1.x (the names were of the form A_<end1>_<end2>).

  • Reported: XMI 2.0 — Mon, 8 Mar 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/Interactions/Constraints for create messages

  • Key: UML22-533
  • Legacy Issue Number: 6989
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    page 429 Constraints for message need to include "no EventOccurences before receiving the create message". In the graphic notation this is handled by defining the create graphic path as flowing into the Lifeline head symbol, but since we do not want to introduce the concept of a Lifeline head in the meta-model, we need an additional constraint.

    Constraints need to be updated as new sorts of messages are added.

  • Reported: XMI 2.0 — Mon, 16 Feb 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML2 Infra/11.5.1/Invalid reference to Attribute class

  • Key: UML22-536
  • Legacy Issue Number: 7274
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    In section 11.5.1 (DataType) the first association is specified as:

    ownedAttribute: Attribute[*] The Attributes owned by the DataType.

    This is out of date: the class Attribute has been replaced by Property,
    though the association name is OK referring to 'Attribute'. This is
    reflected in the diagram above that text (Fig 86).

    Proposed resolution:
    Replace the above text with:
    ownedAttribute: Property[*] The Properties owned by the DataType.

  • Reported: XMI 2.0 — Wed, 28 Apr 2004 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Figure 78

  • Key: UML22-535
  • Legacy Issue Number: 7246
  • Status: closed  
  • Source: PostFinance ( Karl Guggisberg)
  • Summary:

    Figure 78 - inconsistencies with Class Descriptions Figure 78 shows an enumeration ConnectorKind which is not defined in this chapter, however (see also Issue #7001). Suggestion: define ConnectorKind in section 8.3 - Class Descriptions. Figure 78 shows an association between Connector and Behavior with association end "+contract". This association is not defined in Section 8.3.2 - Connector, however.

  • Reported: UML 2.0 — Thu, 15 Apr 2004 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Discussion: Fixed by the resolution to issue 8976 in UML 2.1. Revised Text: N/A Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Class InfrastructureLibrary::Core::Basic::Property

  • Key: UML22-532
  • Legacy Issue Number: 6923
  • Status: closed  
  • Source: Fraunhofer FOKUS, Germany ( Michael Soden)
  • Summary:

    Class InfrastructureLibrary::Core::Basic::Property contains an attribute named 'default' of type 'String'. If initial values should be provided for a Property instance, then there is no possibility to evaluate the string without a schema. I'm not sure about the intension of this default property, especially for MOF (it seems to be useable only for visualization in UML).

    Proposed resolution: If evaluation should be processable by tools (e.g. code generators), then the type of 'default' must be changed to class "Type" or a schema for evaluation should be provided.

  • Reported: UML 2.0 — Mon, 19 Jan 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

In 2.13.3, the first sub-section about ActivityGraph is not numbered

  • Key: UML22-531
  • Legacy Issue Number: 6727
  • Status: closed  
  • Source: Condris Technologies ( Valentin Crettaz)
  • Summary:

    In 2.13.3, the first sub-section about ActivityGraph is not numbered, it should be 2.13.3.1. Subsequent sub-sections should be renumbered

  • Reported: UML 1.5 — Thu, 18 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

missing closing parenthesis

  • Key: UML22-529
  • Legacy Issue Number: 6725
  • Status: closed  
  • Source: Condris Technologies ( Valentin Crettaz)
  • Summary:

    In the second additional operation of the model element StateMachine, there is a missing closing parenthesis in the last else branch, i.e. the last else branch should read

  • Reported: UML 1.5 — Thu, 18 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    Indeed so.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

The Composition section does not follow the usual conventions

  • Key: UML22-528
  • Legacy Issue Number: 6724
  • Status: closed  
  • Source: Condris Technologies ( Valentin Crettaz)
  • Summary:

    The Composition section does not follow the usual conventions of first presenting the attributes and then the associations of the model element.

  • Reported: UML 1.5 — Thu, 18 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

In "2.9.3.5 Instance", numbering of different well-formedness rules wrong

  • Key: UML22-526
  • Legacy Issue Number: 6703
  • Status: closed  
  • Source: Condris Technologies ( Valentin Crettaz)
  • Summary:

    In "2.9.3.5 Instance", the numbering of the different well-formedness rules is wrong. Below rule [2], there are two rule [3], one of which is not left-aligned properly.

  • Reported: UML 1.5 — Wed, 17 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

The numbering of the sub-sections in 2.7.2 is wrong

  • Key: UML22-525
  • Legacy Issue Number: 6702
  • Status: closed  
  • Source: Condris Technologies ( Valentin Crettaz)
  • Summary:

    The numbering of the sub-sections in 2.7.2 is wrong. In "2.7 Data Types", we have "2.7.1 Overview" and "2.7.2 Abstract Syntax". Below that, the numbering starts with "2.7.3.1 AggregationKind" instead of "2.7.2.1 AggregationKind".

  • Reported: UML 1.5 — Wed, 17 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Associations section of element JumpHandler

  • Key: UML22-523
  • Legacy Issue Number: 6697
  • Status: closed  
  • Source: Condris Technologies ( Valentin Crettaz)
  • Summary:

    In the Associations section of element JumpHandler, the protectedAction association misses appropriate type information.

    The line should read:

    protectedAction: Action [0..*]

  • Reported: UML 1.5 — Mon, 15 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Remove one of the dots between protectedAction and availableOutput

  • Key: UML22-522
  • Legacy Issue Number: 6696
  • Status: closed  
  • Source: Condris Technologies ( Valentin Crettaz)
  • Summary:

    In the Outputs listing, "self.jumpHandler.protectedAction..availableOutput.type" should read "self.jumpHandler.protectedAction.availableOutput.type"

    Remove one of the dots between protectedAction and availableOutput

  • Reported: UML 1.5 — Mon, 15 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2.0 infra and super Constraints Diagram of the Kernel

  • Key: UML22-524
  • Legacy Issue Number: 6699
  • Status: closed  
  • Source: TimeWarp Engineering Ltd. ( Steven Cramer)
  • Summary:

    The Constraint:namespace to Namespace:ownedRule association depicted in the super structure spec on page (31) should be made navigable on both ends and the namespace property should be renamed to owningNamespace and this should subset context and subset namespace.

  • Reported: UML 1.5 — Tue, 16 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

The section about Procedure does not contain any well-formedness rules

  • Key: UML22-527
  • Legacy Issue Number: 6704
  • Status: closed  
  • Source: Condris Technologies ( Valentin Crettaz)
  • Summary:

    The section about Procedure does not contain any well-formedness rules. Instead, the section repeats the content (copy-paste!!) of section 2.9.2.11 about attributes and associations.

  • Reported: UML 1.5 — Wed, 17 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

At the bottom of the page, the characters "antics." should be removed

  • Key: UML22-530
  • Legacy Issue Number: 6726
  • Status: closed  
  • Source: Condris Technologies ( Valentin Crettaz)
  • Summary:

    At the bottom of the page, the characters "antics." should be removed

  • Reported: UML 1.5 — Thu, 18 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Inconsistent use of 'Element' between MOF and UML

  • Key: UML22-549
  • Legacy Issue Number: 7889
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    UML uses Element to mean any Element in a Model, which is inherently something that has an identity separate from its value: this even includes elements such as ValueSpecification.
    MOF uses Object for such a thing, and uses Element to represent any value: specifically when used to declare parameters in Reflection then Element is used to represent both 'Objects' and plain data values (such as integers or strings) used as property or parameter values. Object inherits from Element.

    Proposed resolution:

    MOF should swap the names of Object and Element: this makes it consistent with UML and with languages such as Java where java.lang.object can represent data values.

  • Reported: UML 1.4.2 — Mon, 1 Nov 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Missing XMI tags in spec and XMI rendition of metamodel

  • Key: UML22-548
  • Legacy Issue Number: 7783
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    This issue applies to Infrastructure, Superstructure and MOF

    In the XMI for Superstructure for example (in OMG document ad/03-04-02),
    while this does use the nsuri for MOF (using the correct form
    xmlns:cmof="http:///schema.omg.org/spec/mof/2.0/cmof.xmi) it does not
    contain any XMI tags to define for UML what its nsuri and prefix should
    be: which are needed in order to generate the UML xsd.
    Neither does the XMI for the MOF Core itself contain an XMI tag to
    define that the nsuri and prefix should be as just quoted.

    In any case these important values should be included in the
    specification documents as well as being buried in tags in the XMI
    files.

  • Reported: UML 1.4.2 — Fri, 24 Sep 2004 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ptc-03-09-15/Constructs::Class superClass property

  • Key: UML22-504
  • Legacy Issue Number: 6493
  • Status: closed  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    Issue: Constructs::Class has a superClass property that redefines general,
    which is from Constructs::Classifier (section 11.3, figure 73, p. 111); but
    Constructs::Class also inherits from Basic::Class, which has superClass as a
    property (section 10.2, 66, p. 97). What does this mean? Is this a bug?
    Is it something correct having to do with package merge?

    Recommendation: Determine whether this is intended or an oversight. If it
    is an oversight, correct it. If not, explain the meaning of having these
    both of these properties.

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ptc-03-09-15/Non-navigable ends with no role names nor multiplicities

  • Key: UML22-503
  • Legacy Issue Number: 6492
  • Status: closed  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    Issue: It appears that associations with neither end names nor
    multiplicities on non-navigable ends are used in parts of the UML Core that
    are defined via CMOF. See, for example, section 9.9, figure 35, p. 62, for
    example. I understand that for elements defined via EMOF, this signifies a
    simple property. But is it appropriate for elements defined with CMOF.

    Recommendation: Either correct this by adding multiplicities and end names
    or explain in the specification why it is alright to omit them in these
    cases

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    The meaning of this convention should be explained in the document.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Issue: Message notation

  • Key: UML22-502
  • Legacy Issue Number: 6463
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    PROBLEM STATEMENT
    According to Superstructure, p. 430, the notation for messages in
    interaction diagrams is as follows (we put assumptions between parenthesis):

    asynchronous message - (solid line) open arrowhead
    synchronous message - (solid line) filled arrowhead
    reply message - dashed line (filled or open arrowhead?)
    object creation - dashed line open arrowhead

    However, the example given in Figure 333, p. 414, shows a different
    notation:

    asynchronous message - solid line open arrowhead (not shown in this diagram,
    but in others)
    synchronous message - solid line filled arrowhead
    reply message - dashed line OPEN arrowhead
    object creation - SOLID line open arrowhead

    Another confusing aspect of the notation is that in a reply message, which
    is not a true message, the message name is the name of the operation invoked
    on the callee (same as in the corresponding synchronous call), but it
    suggests instead that there is an operation with this name in the caller. In
    Figure 333, the reply labeled as "foo(_)" visually suggests that there is an
    operation named foo in class C1, which is wrong: foo is defined in C2, not
    in C1. It would make more sense to label a reply message with the name of
    the value returned.

    PROPOSED SOLUTION
    The simplest solution would be to fix Figure 333 using a dashed arrow to
    represent object creation, although this would yield the same notation for
    object creation and reply message. Therefore, beyond this simplest solution,
    we propose something more advanced: First, state explicitly the notation for
    all kinds of messages, leaving no place for assumptions. Second, use a
    filled arrowhead for reply messages, since this emphasizes the conceptual
    proximity to the synchronous message it is a reply from. Third, use the
    notation for object creation also for object deletion, which currently is
    not mentioned. That is:

    asynchronous message - SOLID LINE open arrowhead
    synchronous message - SOLID LINE filled arrowhead
    reply message - dashed line FILLED ARROWHEAD
    object creation OR DELETION - dashed line open arrowhead

    Or better, simply drop object creation as an special kind of message. Object
    creation (and deletion) was not considered a special kind of message in UML
    1, and it is not at all clear why it should be in UML 2. Probably, an object
    creation is either synchronous or asynchronous, but not "something else" in
    the same meta-specialization row. In fact, the constraints and semantics of
    Message (Superstructure, p. 429) do not consider object creation as
    messages: "The signature must either refer an Operation (...) or a Signal",
    "A Message reflects either an Operation call (...) or a sending and
    reception of a Signal". Neither does the meta-attribute Message.messageSort,
    which has the following permitted values: synchCall, synchSignal,
    asynchCall, asynchSignal. By the way, what do synchSignal and asynchCall
    mean? The "sorts" of message are not defined in the Spec. Although calls are
    considered in other places to be either synchronous or asynchronous, signals
    are explicitly defined to be asynchronous (Superstructure, pp. 15, 371, 394
    and 395), therefore at least synchSignal is banned.

    Finally, we also propose to label reply messages with the name of the value
    returned by the operation call, not the operation name itself. In Figure
    333, this would leave the replies foo() and doit() without label, and the
    last reply would be labeled simply as "x".

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Why not using the UML1 activity symbol for UML2 actions?

  • Key: UML22-508
  • Legacy Issue Number: 6503
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    I didn't recognize it before, but now I am surprised that the action
    symbol
    is not the same as the UML1 activity symbol ("shape with straight top
    and bottom
    and with convex arcs on the two sides").
    Actions are no activities, but the semantic is similar for
    the "normal" UML user.
    In UML1 the user has to distinguish between the activity symbol and
    the state symbol ("round-cornered rectangle"), especially if states
    and activities
    are shown within the same diagram.
    Now you has to use the UML1 state symbol for actions. I think that
    this is confusing
    for the normal UML user.
    Another point is that the action symbol is the same as the state
    symbol. There will
    be no chance for a misunderstanding, because both symbols are not
    allowed within the same
    diagram. But it would be much clearer if the action symbol has a
    different notation and
    looks like the UML1 activity symbol.

    So, why not using the UML1 activity symbol for UML2 actions?

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Multiplicity seems to be broken - UML2 Infra & Super

  • Key: UML22-507
  • Legacy Issue Number: 6502
  • Status: closed  
  • Source: Daimler AG ( Mario Jeckle)
  • Summary:

    The current Infastructure document defines it at page 54 as (line
    numbers have been added by me):
    (1) multiplicity ::= multiplicity_range
    (2) multiplicity_range ::= [lower '..'] upper
    (3) lower ::= integer
    (4) upper ::= unlimited_natural | '*'

    But at page 56 (also page 20 of the Superstructure document which
    copies
    the definition) it says:

    (5) multiplicity ::= multiplicty_range [

    {order_designator}

    ]
    (6) multiplicity_range ::= [lower '..'] upper
    (7) lower ::= integer | value_specification
    (8) upper ::= unlimited_natural | '*' | value_specification
    (9) order_designator ::= ordered | unordered
    (10) uniqueness_designator ::= unique | nonunique

    There are several problems arising from this definition:

    (P1) (9) and (10) are never used
    (P2) Defining the lower bound as "integer" (according to page 142 of
    the
    Infrastructure document) allows it to specify multiplicities with
    lower bounds below 0 (e.g. [-5..7], [-42..0])
    (P3) (4) and (8) include the asterisk symbol to denote an
    infinite
    upper bound. Though, this is redundant since the symbol is already
    there
    as part of the lexical representation of unlimited_natural (according
    to
    page 144 of the Infrastructure document)
    (P3) (4) and (8) define the upper bound using the datatype
    "unlimited_natural" which comprimises all integer numbers starting
    from
    zero. Thus multiplicities like [0..0] would be legal.
    (P4) It should be mentioned that the lower part is lower or equal to
    the
    value given for the upper part (where '*' is geater than any other
    element of the set named integer). Otherwise multiplicities like
    [8..2]
    would be considered legal.
    (P5) What is the role of the value_specification mentioned at (8) and
    (9) isn't it redundant there?

    Or am I just misreading the spec?

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / Dependency / ownership of dependencies

  • Key: UML22-499
  • Legacy Issue Number: 6451
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    At present, a dependency is not owned by any other element except a package. It seems to make sense for a dependency to be owned by its source. For example, the client of a usage should own it, since that would mean that the usage would be deleted along whenever its client is deleted – it makes no sense to have a dependency independently of the depending (source) element.

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Clarification of Information Flow semantics

  • Key: UML22-498
  • Legacy Issue Number: 6446
  • Status: closed  
  • Source: Pivot Point ( Cris Kobryn)
  • Summary:

    Description: Consider the following recommendations to improve Information
    Flow semantics:
    b) Allow Information Flow to be specialized and decomposed using
    aggregation.
    c) Allow Information Flow between classifiers with ports and interfaces.
    Make provisions for relating the information flow to a port, such that an
    Information Flow can flow through a port.
    d) Allow Information Flows between classifiers with object flows across
    activity partitions.
    e) Change the name from Information Flow to Item Flow (or something similar)
    to allow for the flow of non-information, such as physical items specified
    in systems engineering applications.

  • Reported: UML 1.5 — Thu, 6 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Activity diagram problems

  • Key: UML22-497
  • Legacy Issue Number: 6444
  • Status: closed  
  • Source: Pivot Point ( Cris Kobryn)
  • Summary:

    Description: The following are some recommendations to improve Activity
    diagrams for systems engineering applications:
    a) Generalize pins so that they can be applied to control as well as data.
    b) Clarify how activity diagrams can be used to represent continuous
    behavior (e.g., streaming input).
    c) Clarify how an object node to represent a role.

  • Reported: UML 1.5 — Thu, 6 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Infra/Metamodel::Constructs/invalid OCL constraint for "opposite"

  • Key: UML22-490
  • Legacy Issue Number: 6201
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Is OCL for InfrastructureLibrary::Core::Constructs::Property::opposite() incorrect? Should it be:
    opposite =
    if owningAssociation->empty() and association.memberEnd->size() = 2 then
    let otherEnd = (association.memberEnd - self)->any() in
    if otherEnd.owningAssociation->empty() then otherEnd else Set{} endif
    else Set {}
    endif

  • Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    See issue 8451 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/Metamodel::Kernel/missing merges

  • Key: UML22-489
  • Legacy Issue Number: 6197
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Kernel does not merge Abstractions::Namespaces, Abstractions, Multiplicities, Ownerships, and Visibilities

  • Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/Package merge/redefinitions issue - lost association ends

  • Key: UML22-488
  • Legacy Issue Number: 6194
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    There is a subtle problem with redefinitions resulting from package merge. Property names have to match by name or the merging property has to redefine the merged property, AND the property types have the same name. Otherwise association ends are lost. For example, consider package Communications which is merged into BehaivorStateMachines. Communications has association ownedBehavior:Behavior <--> context:BehavioredClassifier (ignoring multiplicities to keep the text simpler). BehaviorStateMachines has class StateMachine which specializes Behavior, and has association ownedStateMachine:StateMachine

    {redefines ownedBehavior}

    <--> context:BehavioredClassifier. After the merge, merging BehavioredClassifier must contain two properties for ownedBehavior:Behavior and ownedStatemachine:StateMachine. Otherwise the association to the superclass is lost. This is a case where a class ends up redefining one of its own properties, and where ! the redefined and redefining properties both appear in the merged result.

  • Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/Metamodel::Super/missing merge

  • Key: UML22-487
  • Legacy Issue Number: 6187
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Package Super isn't merged anywhere, so the constraints it adds to Classifier are never included in L3

  • Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

raisedException

  • Key: UML22-493
  • Legacy Issue Number: 6275
  • Status: closed  
  • Source: TimeWarp Engineering Ltd. ( Steven Cramer)
  • Summary:

    Reviewing of the Rose MDL file the diagram Constructs::Operations (Class Diagram) displays raisedException as a reference from both BehavioralFeature as well as Operation. Operation inherits from BehavioralFeature as well.

    I believe this violates a well-formedness rule that all structural features must be distinguishable.

  • Reported: UML 1.5 — Thu, 18 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    See issue 8461 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / Templates / TemplateParameter not named

  • Key: UML22-492
  • Legacy Issue Number: 6262
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    TemplateParameters do not appear to be namable. They inherit from Element and not NamedElement. In UML 1.5 they inherited from ModelElement (i.e. were namable). They need to be named to be referred to in the implementation of the template.

  • Reported: UML 1.5 — Tue, 23 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/pg.75/kinds of changeability

  • Key: UML22-491
  • Legacy Issue Number: 6216
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    pg. 75: StructuralFeature::isReadOnly
    Limits severely limits previous capabilities to define various kinds of changeability. Even if some people think that the varieties of changeablity are not right, we should make this an enumerated value to provide extensibility for profiles. Call it "changeablity" as before. Should have enum values:

    Changeable (unrestricted)

    readOnly (no changes after initialization)

    [Note that the meaning and semantics of "initialization" are completely undefined, so this isn't all that useful.]

    The following additional choices were available in UML1:

    CreateOnly (add a set any time after initialization but no further changes)

    addOnly (may add members to the set but not change or remove any)

    Both of these occur in practice often enough.

  • Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 9.3.4 page 161, Presentation Option

  • Key: UML22-496
  • Legacy Issue Number: 6423
  • Status: closed  
  • Source: Sparx Systems Pty Ltd ( Mr. J.D. Baker)
  • Summary:

    The statement "A dashed arrow with a stick arrowhead may be used to show that a collaboration is used in a classifier, optionally labelled with
    the keyword «represents»." and the accompanying example are confusing. Please clarify what this presentation option is trying to accomplish.

  • Reported: UML 1.5 — Tue, 4 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / Kernel features / cannot exclude superclass properties

  • Key: UML22-495
  • Legacy Issue Number: 6398
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    In practice it is not always possible to refactor class hierarchies to ensure that all attributes are defined in the appropraite classes in that hierarchy. For example, a class hierarchy may be supplied by a third party or may be used by multiple products whereas the refactoring may only be required in a subset of them. In such cases, it is extremely useful to be able to exclude undesirable features inherited from a superclass. This einently practical technique should be supported in UML to allow those systems that use that feature to be properly modeled.

  • Reported: UML 1.5 — Fri, 31 Oct 2003 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Syntax of names

  • Key: UML22-494
  • Legacy Issue Number: 6389
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Issue: The UML infrastructure specification does not specify the syntax for names. This prevents model interchange.

    Proposal: Specify the syntax for the string in Name. At least, the characters that may be used in names, and any rules about where in the name certain characters may not (or may) appear.

    Include in the syntax specification a list of characters used in (or excluded from) names using (seven and) eight bit characters and a list of characters used in (or excluded from) names using sixteen bit characters.

    [After a quick glance, the rules sent to the UML 2 Superstructure FTF mail list looks like it will do the job. Or, in any event, get us started.]

  • Reported: UML 1.5 — Wed, 22 Oct 2003 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Issue: definition of navigability

  • Key: UML22-501
  • Legacy Issue Number: 6460
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    PROBLEM STATEMENT
    There is no definition for navigability or navigation in the Spec. Other
    concepts of similar importance, such as visibility, multiplicity, etc., are
    defined in the Spec, so it is not clear why it should be assumed that this
    concept does not require a definition.

    PROPOSED SOLUTION
    Add definition in Section 4 (Terms and definitions): The navigability of a
    binary association specifies the ability of an instance of the source
    classifier to access the instances of the target classifier by means of the
    association instances (links) that connect them. Navigability is closely
    related to the possibility of sending messages through associations (a
    message cannot be sent through an association instance against its
    navigability, that is, navigability is required for sending messages through
    associations), but they remain nonetheless different concepts.

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Discussion: This issue was resolved in UML 2.1 where an explanation of navigability was provided (see page 41 top in formal/07-02/05) Revised Text: N/A Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Use 'represent' for the relationship of a model

  • Key: UML22-500
  • Legacy Issue Number: 6456
  • Status: closed  
  • Source: Anonymous
  • Summary:

    "An instance specification is a model element that represents an instance in a modeled system." [7.7.1] That is, the relationship of the instanceSpecification with a class to an object of that class is the representation relationship.

    At the same time, a lifeline represents a connectable element. [14.2]

    This is an example of a recurrent problem in the specification: model elements that represent other model elements.

    At the same time, "attributes of a class are represented by instances of Propert[ies]..."

    This is an example of an occassional and quite striking problem in the specification: items in the modeled system that represent model elements.

    The theory of representation needs to be settled. That done, the specification needs to be reviewed with this in mind and all improper uses of representation corrected.

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Rose Model of UML 2.0 spec

  • Key: UML22-506
  • Legacy Issue Number: 6501
  • Status: closed  
  • Source: Pivot Point ( Cris Kobryn)
  • Summary:

    Class Diagram:Constructs/Packages in the Rose file shows the
    nestedPackage/package association the spec shows
    nestedPackage/nestingpackage

    I believe the spec to be in error...

    I am not sure where to report this and or who keeps this model up to
    date. Any recommendations would be appreciated

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ptc-03-09-15/Relationships among Core packages

  • Key: UML22-505
  • Legacy Issue Number: 6496
  • Status: closed  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    Issue: The superficial impression that Core::Abstractions is the lowest
    layer in the U2P Core does not stand up under close examination.
    Core::Basic is closer to being the fundamental layer because it uses none of
    the new association modeling constructs (such as derived unions and subsets)
    to define itself; but is not entirely so because it imports two packages
    from Abstractions.

    Recommendation: It would be worth considering whether the two packages that
    Basic imports from Abstractions can be placed in Basic, so that Basic is
    unambiguously the lowest layer in Core. This would also make EMOF
    unambiguously the lowest-—i.e. the most fundamental—-layer of MOF, since
    EMOF is based on Core::Basic while CMOF is based on Core::Constructs.

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Move Comment into Basic and add Kind

  • Key: UML22-547
  • Legacy Issue Number: 7782
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    Move Comment into Basic and add Kind
    The ability to annotate and describe elements and diagrams is pretty
    fundamental so should be included in Basic.
    There should also be the recognition that there are different kinds of
    comment: for example most tools have a dialog allowing people to enter a
    Description for an Element; and separately may allow the element to be
    annotated on diagrams in a particular context. At the moment there is no
    way to distinguish these.
    The UML Metamodel itself is an example of the need for different kinds
    of Comment: each Class has a number of distinct sections (e.g.
    Description, Semantics, Notation).
    Hence there should be a 'kind' attribute on Comment to reflect this.

  • Reported: UML 1.4.2 — Fri, 24 Sep 2004 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Unconsistent Profile extension description (02)

  • Key: UML22-546
  • Legacy Issue Number: 7757
  • Status: closed  
  • Source: Softeam ( Philippe Desfray)
  • Summary:

    18.3.5 says that "A profile by definition extends a reference metamodel or another profile."
    While in theory I could see how it might be modeled, I don't see how the latter could work in practice with real tools. Let's extend the current example and define a new Profile called ClockTechnology with Stereotype AtomicClock with baseClass Clock and property radioactiveElement:String..."

    Import between profiles is supported, and stereotype generalization is the usual way to achieve what has been called "extending a profile".

    The reference to profile extension should be simply discarded. A profile extends a reference metamodel.
    .

    Discussion

    In Profiles:Profile:semantics, change the first sentence

    A profile by definition extends a reference metamodel or another profile.

    Into

    A profile by definition extends a reference metamodel.

  • Reported: UML 1.4.2 — Fri, 3 Sep 2004 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Unconsistent association extension description

  • Key: UML22-545
  • Legacy Issue Number: 7756
  • Status: closed  
  • Source: Softeam ( Philippe Desfray)
  • Summary:

    b) More worryingly, 18.3.5 Semantics also says "As part of a profile, it is not possible to have an association between two stereotypes or between a stereotype and a metaclass unless they are subsets of existing associations in the reference metamodel." I fail to see how a profile could in fact could cause an association between 2 stereotypes to subset an existing association in a reference metamodel since the stereotypes do not at all inherit from the baseClasses so do not inherit any of its properties or associations in order to be able to subset them: this is emphasized by the MOF representation shown in the new Figure 447.

    Indeed profiles do not support association subsetting. This should be made clear in the spec to avoid any confusion while using profiles.
    .

    Discussion

    In Profiles:Profile:semantics, change the paragraph

    As part of a profile, it is not possible to have an association between two stereotypes or between a stereotype and a metaclass unless they are subsets of existing associations in the reference metamodel.

    Into

    As part of a profile, it is not possible to have an association between two stereotypes or between a stereotype and a metaclass.

  • Reported: UML 1.4.2 — Fri, 3 Sep 2004 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 11.7

  • Key: UML22-538
  • Legacy Issue Number: 7343
  • Status: closed  
  • Source: Missouri University of Science and Technology ( Thomas Weigert)
  • Summary:

    In the manner of representing the relationship between BehavioralFeature and Parameter the infrastructure imposes either a limit on the nature of parameters on modeling languages reusing the infrastructure or forces them to duplicate this mechanism. The infrastructure decided to represent as concrete associations the kinds of parameters, and distinguishes two: returnResult and formalParameter. The parameter association is then derived as a union of these. However, there may be a large number of parameter kinds. For example, the superstructure defines four, and one can easily imagine additional ones. To be more reusable and expandable, parameter should be characterized by its kind (does it return a result, is it a formal parameter). Note that this is, in reality, a property of the parameter, not of the relation between BehavioralFeature and Parameter and thus is modeled better this way anyway. Define an attribute "direction" on Parameter of type "ParameterDirectionKind". In infrastructure give it two values: in, and returnResult. This type can be extended in other languages, e.g., the UML uses also out, and inout). Make BehavioralFeature.parameter concrete. Make the formalParameter and returnResult associations derived from the direction attribute of each parameter. The result is the identical model, but much more reusable. Note that the superstructure was forced to introduce both mechanisms, thus running into the risk of inconsistencies, if the two mechanisms do not match up. There is no negative impact on the infrastructure of relying on the more reusable option proposed here. The number of model elements stored in the repository is identical for infrastructure, and lower for superstructure.

  • Reported: UML 2.0 — Sun, 16 May 2004 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

simple time model" in CommonBehavior

  • Key: UML22-537
  • Legacy Issue Number: 7303
  • Status: closed  
  • Source: Missouri University of Science and Technology ( Thomas Weigert)
  • Summary:

    For the "simple time model" in CommonBehavior, it is unclear when the DurationObservationAction and TimeObservationAction would be executed. For one, it is not stated when these actions are executed. I assume that when the execution of the model reaches the point of the attached model elements, then these actions are executed. Several problems: It is unclear what determines when these actions are executed. If the actions are embedded in a sequence of actions, where control flow indicates when they execute, what is the meaning of the association to a named element? If that named element is reached later in the execution, does the execution wait? If it is reached earlier, does that element have to wait until the action sequence is enabled? (ii) There should be some constraint on the "NamedElements" associated with TimeExpression that limits those to elements that can be enountered during execution, as these elements appear to determine when these actions are evaluated. There is a tension between these actions being embedded in a sequence of actions where their execution is determined by the control and data flow, and the associated "NamedElements" that would determine the observation of time also. Normally, actions are used within a sequence of actions (an activity). These two actions are different in that they seem to make no sense within an activity due to that they have very special invocation points. They seem to only make sense as stand-alone elements. Maybe it should not be an action, but some other model element, that should dictate how time and duration are observed.

  • Reported: UML 2.0 — Wed, 5 May 2004 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Discussion: Fixed as part of the resolution to issue 8894 in UML 2.1 Revised Text: N/A Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Problem with diagram references in Profiles section

  • Key: UML22-551
  • Legacy Issue Number: 7909
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    2nd paragraph in Stereotype Semantics does not have proper cross-references to the figures and hence they have not been updated as other figures have been inserted. The para currently reads:
    An instance "S" of Stereotype is a kind of (meta) class. Relating it to a metaclass "C" from the reference metamodel (typically UML) using an "Extension" (which is a specific kind of association), signifies that model elements of type C can be extended by an instance of "S" (see example Figure 454). At the model level (such as in Figure 457) instances of "S" are related to "C" model elements (instances of "C") by links (occurrences of the association/extension from "S’ to "C").

    But the 2 references should be to Figure 456 and Figure 461 respectively.

  • Reported: UML 1.4.2 — Sun, 14 Nov 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Design principles

  • Key: UML22-550
  • Legacy Issue Number: 7908
  • Status: closed  
  • Source: none ( Markus Flueckiger)
  • Summary:

    have a general problem with the UML 2.0 specification. A graphical modelling language is essential for succesful software development. However the more I read about UML 2.0 the more I had the impression that UML 2.0 has not been developed with actual real-world software development in mind. Just to give one highlight of UML 2.0 is the merge relation between packages: The relation leads to bad designs and incomprehensible software systems, e.g. like like badly designed inheritance hierarchies etc. Especially consider the following case: a trifle change in the diagram (change the merge relationship into e.g. an access relationship) causes a tremendous amount of changes on the code and the configuration level. The only way to handle this is to forbid the merge relationship and to hope that nobody is blind enough to actually use it. Reading the manual, I stumbled over numerous similar issues. I'm sorry to say but I'm very disappointed with UML 2.0 as it is

  • Reported: UML 1.4.2 — Wed, 10 Nov 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

The specification is fond of using 'typically.'

  • Key: UML22-544
  • Legacy Issue Number: 7407
  • Status: closed  
  • Source: X-Change Technologies ( Joaquin Miller)
  • Summary:

    The specification is fond of using 'typically.' The term should be use with care in a specification. Typically, 'must' or 'may' are better choices. For example, at 7.4.1 p.42: The multiplicity bounds are typically shown in the format: lower-bound..upper-bound It will be better to write: The multiplicity bounds are shown in the format: lower-bound..upper-bound simply deleting 'typically.' (In this case, the syntax specification should show the case when the two bounds are equal.)

  • Reported: UML 2.0 — Mon, 31 May 2004 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

TimeObservationAction and DurationObservationAction

  • Key: UML22-543
  • Legacy Issue Number: 7406
  • Status: closed  
  • Source: Missouri University of Science and Technology ( Thomas Weigert)
  • Summary:

    TimeObservationAction and DurationObservationAction are described as actions, but are not really actions like the actions of the action chapter. They would never be used when defining a behavior, but are part of a metalanguage to define temporal constraints and to refer to measured times and durations in formulating such constraints. However, these two elements are the only aspects of this language, everything else is left to be defined later (see TimeExpression). Putting these two mechanisms into the specifications unduly constrains any profile that would want to define a notation for expressing temporal constraints. Such a language might not see a need to use the actions described in this chapter. My recommendation is to find a different way of expressing time observations and duration observations in the metamodel. The syntax examples clearly show that they are not meant to be used within an activity as actions. Note that the only way to use these observations is to create a "fake" activity attached to the interaction (e.g., as a nestedClassifier) which contains only this action. A rather convoluted and heavy-weight means of expressing the simple concept of "NOW" (as the point in time when some model element is executed). A simpler mechanism is clearly needed.

  • Reported: UML 2.0 — Sat, 29 May 2004 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Discussion: Fixed as part of the resolution to issue 8894 in UML 2.1 Revised Text: N/A Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

add an interaction fragment

  • Key: UML22-541
  • Legacy Issue Number: 7397
  • Status: closed  
  • Source: Missouri University of Science and Technology ( Thomas Weigert)
  • Summary:

    Sequence diagrams are often used to describe abstract system behavior in the form of the interaction of the system with its environment. Experience has shown that systems have normal behavior and exceptional behavior (in response to unusual or unexpected events). UML2 has introduced a mechanism of representing exceptions. However, interactions do not give us a vehicle of showing exceptional behavior. Recommendation: add an interaction fragment indicating exceptional handling similar to the way this is done in the activity chapter.

  • Reported: UML 2.0 — Sun, 30 May 2004 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Interactions model sequences of events

  • Key: UML22-540
  • Legacy Issue Number: 7392
  • Status: closed  
  • Source: Missouri University of Science and Technology ( Thomas Weigert)
  • Summary:

    Interactions model sequences of events. The metaclass EventOccurrence represents the occurrence of an event. Currently, there are the following kinds of events known: i. sending of a message ii. receiving of a message iii. start of the execution of a behavior iv. finish of the execution of a behavior v. stop First, clearly, there could be many more events that one might want to represent on a lifeline. In particular, the invocation of an action is a possible event, and should be allowed to be represented. Secondly, event occurrence is modeled poorly. It is shown as a kind of message end, which means that every event occurrence inherits the notion of being a message end point, even if the event has nothing to do with a message (such as a stop event). Clearly the inheritance hierarchy is inverted. A message end can represent an event occurrence (such as the sending or receiving of a message). But not every event occurrence is a message event.

  • Reported: UML 2.0 — Sat, 29 May 2004 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Discussion: This was fixed in UML 2.1 Revised Text: N/A Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Clarify example in figure 133

  • Key: UML22-539
  • Legacy Issue Number: 7362
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Sebastien Gerard)
  • Summary:

    Could you describe in details the meaning of the example described in Figure 133, because it could very useful to understand the deployment specification concept. Moreover, is there anything lacking in figure 134? It contains no model element with the <<deployment specification>> stereotype.

  • Reported: UML 2.0 — Wed, 19 May 2004 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

XMI schema

  • Key: UML22-542
  • Legacy Issue Number: 7401
  • Status: closed  
  • Source: X-Change Technologies ( Joaquin Miller)
  • Summary:

    "[C]omplying with a package requires complying with its abstract syntax, well-formedness rules, semantics, notation and XMI schema," [2] but there is no XMI schema. "It is expected that the normative XMI for this specification will be generated by a Finalization Task Force, which will architectually align and finalize the relevant specifications." [Appendix F] That is consistent with the OMG Document Archives, which show: ad/03-04-02: XMI for U2 Partners' UML 2.0: Superstructure, 3rd. revision (Contact: Mr. Cris Kobryn) No description of this document is available. Formats: Note: Not yet available. An XMI schema should be supplied, or the requirement to comply with an XMI schema should be removed.

  • Reported: RAS 2.0b1 — Mon, 31 May 2004 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

DataType attributes UML 2 Super (ptc/04-10-02)

  • Key: UML22-552
  • Legacy Issue Number: 7938
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    On Figure 13, DataType::ownedAttribute is specified as ordered but in the
    associations section on page 59, it is not specified as ordered.

  • Reported: UML 1.4.2 — Fri, 19 Nov 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    See issue 7939 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/Metamodel::Constructs/owningComment

  • Key: UML22-486
  • Legacy Issue Number: 6176
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Constructs association owningCommet:Element[0..1] c-> ownedCommet:Comment[0..*] should have been owningElement:Element[0..1] c-> ownedCommet:Comment[0..*] as defined in Kernel/Root.

  • Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Classes diagram of the Core::Constructs package

  • Key: UML22-485
  • Legacy Issue Number: 6006
  • Status: closed  
  • Source: Honeywell ( Steven Hickman)
  • Summary:

    In the Classes diagram of the Core::Constructs package, the references to StructuralFeature, Relationship, Type, and Classifier have no cross-reference to the package where they were originally defined, whereas other concepts in this diagram do. It is clear from the fact that some of these concepts are involved in derived roles or relationships, that they MUST have been defined somewhere else.

    The document needs to be fixed so that it is self consistent and so that proper cross-references are indicated.

  • Reported: UML 2.0 — Sat, 19 Jul 2003 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

cross-reference missing

  • Key: UML22-484
  • Legacy Issue Number: 6005
  • Status: closed  
  • Source: Honeywell ( Steven Hickman)
  • Summary:

    The reference to TypedElement in the Expressions diagram for Core::Constructs makes no cross-reference to the definition of TypedElement in Core::Abstractions::TypedElements or Core::Basic.

    Is it a reference to either of these or is it yet another definition of a concept with the same name?

  • Reported: UML 2.0 — Sat, 19 Jul 2003 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Relationship and DirectedRelationship in Core::Constructs

  • Key: UML22-483
  • Legacy Issue Number: 6004
  • Status: closed  
  • Source: Honeywell ( Steven Hickman)
  • Summary:

    There doesn't seem to be any value in the specialization of Relationship and DirectedRelationship in Core::Constructs from their definitions in Core::Abstractions::Relationships. The documentation clearly states that the specializations don't add anything to the either concept. In fact, it appears that this can be said for everything in the Core::Constructs Root Diagram.

    If this is the case, why do these specializations exist? The UML spec is big enough - there is no point in adding things that don't need to be there. If the goal is to merely create a single diagram that includes concepts and relationships that were previously spread across multiple diagrams, then why not simply create the diagram and have every contained concept refer to the package where it was originally defined?

    If there is a compelling reason for these specializations, then that reason needs to be spelled out in the spec - because it isn't obvious to me.

  • Reported: UML 2.0 — Sat, 19 Jul 2003 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

document appears to be inconsistent in how it handles concepts

  • Key: UML22-482
  • Legacy Issue Number: 6003
  • Status: closed  
  • Source: Honeywell ( Steven Hickman)
  • Summary:

    This document appears to be inconsistent in how it handles concepts with the same name. In some cases, the class diagrams make it clear that a concept is being imported from one package to another by reference. However, there are a lot of cases where the same concept name is used in separate packages but it is not clear if it is the same concept, a parallel concept, or a refinement of the concept.

    In many cases the documentation of the concepts is the same (or nearly so) everywhere it appears. This tends to imply that it is, in fact, the same concept. However, if this were the case, then it should be defined in one package and imported by reference in other packages. On the other hand, since the import by reference is actually done in some cases, that tends to imply that, where the import by reference is not done, something else significant is going on. What that significant thing "is" is never made clear - at least not as far as I can tell.

    I suspect the same problem exists in the UML 2.0 Superstructure submission because they were both written by the same group.

    Proper understanding of the metamodel becomes impossible without this issue getting resolved. Someone needs to go through both of these documents and locate every place the same concept name is used in multiple packages and make sure it is clear how the concepts with the same name in different packages relate to each other.

  • Reported: UML 2.0 — Sat, 19 Jul 2003 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Designates a Generalization

  • Key: UML22-477
  • Legacy Issue Number: 5794
  • Status: closed  
  • Source: yahoo.com ( Jeff Barnes)
  • Summary:

    The text:

    Designates a Generalization whose parent GeneralizableElement is the immediate ancestor of the current GeneralizableElement.

    disagrees in plurality with the * cardinality of the generalization association end between GeneralizableElement and Generalization in the Core Package - Relationships diagram (Figure 2-6) on page 2-14.

  • Reported: UML 1.4 — Sun, 15 Dec 2002 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    closed no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Namespace issue (UML 1.4 formal/2002-09-67, 2.5.3.26 Namespace )

  • Key: UML22-476
  • Legacy Issue Number: 5593
  • Status: closed  
  • Source: blomesystem ??????? ( Michael Zavyalov)
  • Summary:

    The Namespace has the following definition constraint (p. 2-64): [1] The operation contents results in a Set containing all ModelElements contained by the Namespace. contents : Set(ModelElement) contents = self.ownedElement -> union(self.namespace, contents)

    The errors: 1. Syntax error in the union operation. According to Object Constraint Language Specification set has operation (p. 6-38) set->union(set2 : Set(T)) : Set(T) with the single parameter !

    2. The functions contents and allContents are used to receive all composite and aggregate elements of namespace according to specification of these functions (Is that right ?). For example all overriden functions in the descedent elements (Package, DataType) release these functions in this manner. In this case function contents must be realized as: contents = self.ownedElement 3.The functions contents and allContents is sometimes used to receive list of «accessable» objects ! For example: definition constraint #2 for BehavioralFeature (p. 2-54): [2] The type of the Parameters should be included in the Namespace of the Classifier. self.parameter->forAll( p | self.owner.namespace.allContents->includes (p.type) ) Why parameter can't use imported DataType ? Why parameter can't use DataType located in the Namespace binded with the namespace of classifier by «friend» Permission ? Note that DataType may be included in the namespace of namespace of owner. It also may be included directly into owner ! I may send the collection of such errors («contents» instead of «acessable»).

  • Reported: UML 1.4 — Sun, 25 Aug 2002 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Discussion: This is an issue raised against the UML 1 metamodel, which is no longer valid. Revised Text: N/A Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Sending a signal after a delay

  • Key: UML22-475
  • Legacy Issue Number: 4937
  • Status: closed  
  • Source: Object Management Group ( Stephen Mellor)
  • Summary:

    Sending a signal after a delay

  • Reported: XMI 1.3 — Tue, 5 Mar 2002 05:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    The feature requested is already supported in UML 2.1: Precede an action by an AcceptEventAction, where the latter references a trigger that refers to a TimeEvent. Thus, for example, if you have a sequence of an AcceptEventAction with a TimeEvent specifyinig the desired delay and a SendSignalAction, then the signal will not be sent until the delay has passed. Note that this feature is extremely generic, probably giving the user even too much support (you can define a statemachine purely with actions, if there are not proper constraint placed on the events allowed in the AcceptEventAction).

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Does visibility apply to creating an destroying links?

  • Key: UML22-474
  • Legacy Issue Number: 4448
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    It isn't clear whether visibility of association ends applies to
    creating and destroying links. If it does, then what if one end is
    private and the other public, can the private end create or destroy
    a link?

  • Reported: XMI 1.2 — Fri, 3 Aug 2001 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

relationship should just be a cross-reference

  • Key: UML22-481
  • Legacy Issue Number: 6002
  • Status: closed  
  • Source: self ( Steve Hickman)
  • Summary:

    There is no clear relationship between NamedElement, TypedElement and Type as defined in Core::Basic and items by the same name in Core::Abstractions::Namespaces and Core::Abstractions::TypedElements. There is no reference between the two although the concepts seem identical.

    It seems like the relationship should just be a cross-reference. However, is it a type-instance relationship? Or is a refinement relationship (as can be seen in other parts of the spec)? Or is it something else? What is going on here?

  • Reported: UML 1.5 — Sat, 19 Jul 2003 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    closed no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

formal/03-03-01 : Omission of definition of Class "Action"

  • Key: UML22-480
  • Legacy Issue Number: 5907
  • Status: closed  
  • Source: Anonymous
  • Summary:

    I believe I found an omission from the UML 1.5 Specification formal/03-03-01:

    p. 2-112, Fig. 2-18: Association between "Message" and "Action (from Common Behavior)"

    In Sec. 2.9 Common Behavior; none of the diagrams or text specify Class "Action".

    p. Index-1 cites "Action" p 2-103.

    p. 2-103 has no mention of "Action".

    The first item in Sec. 2.9.3 is "2.9.3.1 AttributeLink", not "2.9.3.1 Action" as would be alphabetized.

    My question is what is definition of the "Action" Class in Fig. 2-18?

  • Reported: UML 1.5 — Mon, 21 Apr 2003 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    closed no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Specify XMI parameters for the UML / XMI interchange format

  • Key: UML22-473
  • Legacy Issue Number: 3898
  • Status: closed  
  • Source: DSTC ( Stephen Crawley)
  • Summary:

    When the UML spec standardises an XMI-generated interchange format for
    UML
    models, it should include:

    • the "input" MOF meta-model for UML that was used to generate the
      interchange format, and
    • a formal statement of the other XMI "parameters" used to generate
      the interchange format.

    If possible, the UML spec should include a definitive meta-model for
    UML
    expressed as a MOF / XMI document. This is a MOF alignment issue.

  • Reported: UML 1.3 — Fri, 22 Sep 2000 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

logic upperbound is the same as the lower bound.

  • Key: UML22-479
  • Legacy Issue Number: 5896
  • Status: closed  
  • Source: Anonymous
  • Summary:

    3] The operation lowerbound returns the lowest lower bound of the ranges in a multiplicity. lowerbound( ) : Integer; lowerbound = self.range->exists(r : MultiplicityRange |r.lower = result) and self.range->forall(r : MultiplicityRange |r.lower <= result) [4] The operation upperbound returns the highest upper bound of the ranges in a multiplicity. upperbound( ) : UnlimitedInteger; upperbound = self.range->exists(r : MultiplicityRange |r.upper = result) and self.range->forall(r : MultiplicityRange |r.upper <= result) =============================================

    according to the logic upperbound is the same as the lower bound.

    should the upperbound read as r.upper >= result instead of r.upper <= result on the last line?

  • Reported: UML 1.5 — Fri, 4 Apr 2003 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    closed no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

2.5.2.27 ModelElement

  • Key: UML22-478
  • Legacy Issue Number: 5804
  • Status: closed  
  • Source: yahoo.com ( Jeff Barnes)
  • Summary:

    The text "deploymentLocation The set of locations may differ. Often it is more restrictive on the child." has no corresponding association in any diagram. The closest match is documented in 2.5.2.12 Component on pages 2-31 and 2-32. If this is the non-inherited feature discussed on page 2-44 is it not redundant and doesn't it cloud the meaning of the feature?

  • Reported: UML 1.4 — Thu, 19 Dec 2002 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    closed no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / Classes / dependencies should be unidirectional

  • Key: UML22-511
  • Legacy Issue Number: 6630
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    In the metamodel, UML::Classes::Dependencies::NamedElement::supplierDependency should not be navigable, as it does not make sense for the supplier of a dependency to know about its dependencies

  • Reported: UML 1.5 — Wed, 26 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

two classes "NamedElement

  • Key: UML22-510
  • Legacy Issue Number: 6525
  • Status: closed  
  • Source: Pivot Point ( Cris Kobryn)
  • Summary:

    Secondly, there are two classes "NamedElement" holding un-redefined
    attribute "name", one is in the
    package "InfrastructureLibrary.Core.Basic", and the other is in the
    package "InfrastructureLibrary.Core.Abstractions.Namespaces". The
    problem is that there are a lot of classes directly or indirectly
    inheriting both of them e.g. class "InstanceSpecification" in package
    uml.classes.kernel, and it causes problem of duplicated parameters in
    class creation in the generated JMI interfaces. e.g.
    "
    public InstanceSpecification createInstanceSpecification
    (java.lang.String name,
    infrastructurelibrary.core.abstractions.visibilities.VisibilityKind
    visibility, java.lang.String name, java.util.Collection classifier);
    "
    Similiar cases happen to attribute "type", "isAbstract" etc.

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

well-formedness rules are not numbered correctly

  • Key: UML22-515
  • Legacy Issue Number: 6641
  • Status: closed  
  • Source: Condris Technologies ( Valentin Crettaz)
  • Summary:

    The well-formedness rules are not numbered correctly. After the note in the middle of the page, the numbering scheme starts over at [1] instead of going on to [10].

  • Reported: UML 1.5 — Wed, 26 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

number of the figure is wrong

  • Key: UML22-514
  • Legacy Issue Number: 6640
  • Status: closed  
  • Source: Anonymous
  • Summary:

    At the bottom of page 2-216, the paragraph "This life cycle may be depicted informally using a statechart diagram, as shown in Figure 2-39." should actually read "This life cycle may be depicted informally using a statechart diagram, as shown in Figure 2-40." The number of the figure is wrong.

  • Reported: UML 1.5 — Tue, 25 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 1.5 table of contents

  • Key: UML22-520
  • Legacy Issue Number: 6665
  • Status: closed  
  • Source: EWSolutions ( Patrick Cross)
  • Summary:

    The example text <Company xmi:id="Company_1" name="Acme"> <HQAddress xmi:id="Address_1" Street="Side Street" </Company>City="Hometown"/> should be <Company xmi:id="Company_1" name="Acme"> <HQAddress xmi:id="Address_1" Street="Side Street" City="Hometown"/> </Company>

  • Reported: XMI 2.0 — Wed, 3 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

In the last paragraph, the period after the word "collections" on the secon

  • Key: UML22-519
  • Legacy Issue Number: 6662
  • Status: closed  
  • Source: Condris Technologies ( Valentin Crettaz)
  • Summary:

    In the last paragraph, the period after the word "collections" on the second line should be removed

  • Reported: UML 1.5 — Tue, 2 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

In paragraph 5, the addition of 2, 5, 7 and -3 does not yield 9 but 11

  • Key: UML22-518
  • Legacy Issue Number: 6661
  • Status: closed  
  • Source: Condris Technologies ( Valentin Crettaz)
  • Summary:

    In paragraph 5, the addition of 2, 5, 7 and -3 does not yield 9 but 11. That's why "...subaction Addition is the scalar 9." should read "...subaction Addition is the scalar 11."

  • Reported: UML 1.5 — Tue, 2 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

The multiplicity of association named subaction of type Action ill formed

  • Key: UML22-517
  • Legacy Issue Number: 6660
  • Status: closed  
  • Source: Condris Technologies ( Valentin Crettaz)
  • Summary:

    The multiplicity of the association named subaction of type Action is ill formed. Instead of [1..] it should read [1..1].

  • Reported: UML 1.5 — Mon, 1 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Operations and derived attributes

  • Key: UML22-521
  • Legacy Issue Number: 6692
  • Status: closed  
  • Source: TimeWarp Engineering Ltd. ( Steven Cramer)
  • Summary:

    I am looking at ValueSpecification which introduces Additional Operations, such as integerValue(). My question is : What is the reasoning behind making these Operations vs. Derived attributes?

    In MultiplicityElement we have a derived attribute lower which is equal to lowerBound(). What logic is used to determine whether an Operation has a corresponding Attribute?

    Also the spec seems to indicate that all derived values will be implemented via some operation. Is this a requirement or an assumption of implementation?

    Why can’t lower in MultiplicityElement simple be defined as if lowerValue->notEmpty() then 1 else lowerValue.integerValue()… what makes the lowerBound() operation required?

  • Reported: UML 1.5 — Wed, 10 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

class "InfrastructureLibrary.core.constructs.Association",

  • Key: UML22-509
  • Legacy Issue Number: 6524
  • Status: closed  
  • Source: Pivot Point ( Cris Kobryn)
  • Summary:

    found something strange in the specification of UML 2.0.
    First of all, in the
    class "InfrastructureLibrary.core.constructs.Association", there is
    an attribute "ownedEnd" with return type
    of "InfrastructureLibrary.Core.Constructs.Property" and 0...*; and it
    its direct subclass "infrastructurelibrary.profiles.Extension", there
    is an attribute "ownedEnd" which redefines ownedEnd in
    class "Association", but with return
    type "infrastructurelibrary.profiles.ExtensionEnd" and multiplicity
    of 1. It causes conflicts of generated JMI interface.

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

remove paragraph

  • Key: UML22-513
  • Legacy Issue Number: 6639
  • Status: closed  
  • Source: Condris Technologies ( Valentin Crettaz)
  • Summary:

    The paragraph starting at the bottom of page 2-200 with "A user model uses instances..." and finishing at the top of page 2-201 describes figure 2-37 which has been removed from the specification 1.4 when transiting to 1.5. Thus, the paragraph should be either adapted to reflect the change or removed.

  • Reported: UML 1.5 — Tue, 25 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Infra/Metamodel/missing derivation indicators

  • Key: UML22-512
  • Legacy Issue Number: 6637
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Package::nestedPackage and Profile::ownedStereotype should be derived, just as Package::ownedType is (all three subset Package::ownedMember). In general, if the contents of a subset are determined soley by type (and the superset property is not derived), the subset property should be derived.

  • Reported: UML 1.5 — Fri, 21 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Discussion: This was fixed in release 2.1. Revised Text: N/A Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

multiplicity of the association named "type" of type DataType

  • Key: UML22-516
  • Legacy Issue Number: 6659
  • Status: closed  
  • Source: Condris Technologies ( Valentin Crettaz)
  • Summary:

    The multiplicity of the association named "type" of type DataType is given as [1..1}. It should be [1..1], i.e. with square brackets instead of curly braces

  • Reported: UML 1.5 — Tue, 2 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Behaviors Owned by State Machines

  • Key: UML22-327
  • Legacy Issue Number: 11076
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    State and Transition currently own the behaviors that they invoke. This is very restrictive because it makes it impossible to reuse Behaviors across state machines, or even across transitions and states.

    Consider allowing States and Transitions to merely reference behaviors rather than owning them.

  • Reported: UML 2.1 — Fri, 25 May 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Interesting idea, but it's too large a change to be considered for the current RTF. This therefore needs to be postponed to a more major revision, when we will have time to investigate this proposal and see if and how it can be accommodated.

    Revised Text:
    N/A
    Disposition: Closed, out of scope

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.41 Streaming parameters for actions

  • Key: UML22-326
  • Legacy Issue Number: 11069
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Semantics, 2nd paragraph about streaming: "Streaming parameters give an action access to tokens passed from its invoker while the action is executing. Values for streaming parameters may arrive anytime during the execution of the action, not just at the beginning." Since an action represents a single step and is atomic. I think it is not possible that an atomic action comsumes further parameters during execution.

  • Reported: UML 2.1.1 — Fri, 25 May 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    The stated issue presumes that action execution is atomic, which is not necessarily the case, and is certainly not the case for a call action to a behavior with streaming parameters. The whole point of streaming parameters is the semantics given in the quoted sentence, and they would be useless if this was not possible.
    However, the quoted sentence is poorly worded, since it is behaviors that have parameters and are invoked, not actions. This may be causing the confusion and should be corrected.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 13.3.24

  • Key: UML22-316
  • Legacy Issue Number: 10960
  • Status: closed  
  • Source: International Business Machines ( Mr. Anders Ek)
  • Summary:

    There is an association defined for the Signal metaclass as follows: signal: Signal [1] The signal that is associated with this event. It is unclear what this associaiton is intended to represent. Should this association really be there?

  • Reported: UML 2.1.1 — Thu, 19 Apr 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Disucssion: Duplicate of 9576. Disposition: Duplicate

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 15.3.14

  • Key: UML22-315
  • Legacy Issue Number: 10959
  • Status: closed  
  • Source: International Business Machines ( Mr. Adam Neal)
  • Summary:

    On page 569 in section 15.3.4 (Transitions), constaint # 5 identifies which outgoing transitions, given their source pseudostates, may not have triggers: [5] Transitions outgoing pseudostates may not have a trigger. source.oclIsKindOf(Pseudostate) and ((source.kind <> #junction) and (source.kind <> #join) and (source.kind <> #initial)) implies trigger->isEmpty() This OCL is incorrect since transitions leaving either a Junction Point, Initial State or a Join should not have triggers. The given OCL specifies the inverse - that only those pseudostates may have triggers. One contradiction to the above OCL exists on page 537 in section 15.3.8 (Pseudostates), constraint #9: [9] The outgoing transition from an initial vertex may have a behavior, but not a trigger or guard. (self.kind = PseudostateKind::initial) implies (self.outgoing.guard->isEmpty() and self.outgoing.trigger->isEmpty()) Furthermore, transitions leaving a fork are also not allowed triggers (constraint #1), so this could also be contained in the transition's OCL constraint (#5). Therefore the OCL for constraint #5 should be written as: [5] Transitions outgoing pseudostates may not have a trigger. source.oclIsKindOf(Pseudostate) and ((source.kind = #junction) or (source.kind = #join) or (source.kind = #initial) or (source.kind = #fork)) implies trigger->isEmpty()

  • Reported: UML 2.1.1 — Wed, 18 Apr 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Text has already been fixed in the UML 2.2 specification to be
    [5] Transitions outgoing pseudostates may not have a trigger (except for those coming out of the initial pseudostate).
    (source.oclIsKindOf(Pseudostate) and
    (source.kind <> #initial)) implies trigger->isEmpty()
    which resolves the above issue

    Revised Text:
    N/A

    Disposition: ClosedNoChange

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Wrong subsets

  • Key: UML22-321
  • Legacy Issue Number: 11008
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    Realization is a specialized abstraction relationship between two sets of model elements, one representing a specification (the supplier) and the other represents an implementation of the latter (the client).

    ComponentRealization incorrectly subsets supplier to define realizing Classifiers (implementation).

    Required changes:

    "abstraction" must subset "supplier" and "realizingClassifier" must subset "client".

  • Reported: UML 2.1 — Wed, 16 May 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Section 7.3.45 does indeed make it clear that the specification is the supplier and the implementation is the client. The implementation depends upon the specification; the specification does not depend upon the implementation.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 15.3.11

  • Key: UML22-320
  • Legacy Issue Number: 10976
  • Status: closed  
  • Source: Paranor AG ( Earl Waldin)
  • Summary:

    State.stateInvariant should subset ownedRule The stateInvariant property of State currently subsets Element.ownedElement. Given that a State is a Namespace and a stateInvariant is a Constraint, the stateInvariant property of State should subset ownedRule. Likewise, the opposite end of this association should subset Constraint.context instead of Element.owner. This change is needed so that a state invariant has a context and, thus, can be specified using OCL.

  • Reported: UML 2.1.1 — Mon, 30 Apr 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

information flow source and target

  • Key: UML22-328
  • Legacy Issue Number: 11090
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    UML 2.1.1 includes fix - "source" and "target" of InformationFlow are renamed to "informationSource" and "informationTarget".
    These changes are made in diagrams, but not in text under InformationFlow chapter (17.2.1).

  • Reported: UML 2.1 — Wed, 6 Jun 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

description of 14.3.24 MessageSort (from BasicInteractions) - typo

  • Key: UML22-318
  • Legacy Issue Number: 10967
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    On page 495, in the description of 14.3.24 MessageSort (from BasicInteractions) , the definition of createMessage seems not to start on a new line, instead following straight on from the definition of asynchSignal

  • Reported: UML 2.1 — Sun, 22 Apr 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

drawing a frame to represent Combined Fragment or an Interaction Occurrence

  • Key: UML22-317
  • Legacy Issue Number: 10966
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    I seem to remember that when drawing a frame to represent a Combined Fragment or an Interaction Occurrence there is a notation that indicates whether a given lifeline overlapped by the frame is actually covered by the fragment/occurrence or not. I believe that it hinged on whether the frame obscured the lifeline or not. However, I can't find reference to it in the spec. It would be good to have this notation described with an example, to avoid different vendors inventing their own notations.

  • Reported: UML 2.1 — Sun, 22 Apr 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion: It is correct that there is no such notation suggested in the standard. The ITU standard Z.120 has a specific notation for lifelines that are not covered by a combined fragment, but we have not included that in UML 2. The reason, I believe, is that it is basically a matter of taste whether you want to include as covered in a combined fragment a lifeline that has no internal fragments (such as occurrence specifications). Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 14 Interactions: Lifeline representing an actor

  • Key: UML22-325
  • Legacy Issue Number: 11068
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    It is common usage to model a lifeline in a interaction that represents an actor. I can't see how that could be done formally correct. A lifeline represents a connectable element, e.g. a property. It is not allowed to define a property that is typed by an actor.

  • Reported: UML 2.1.1 — Fri, 25 May 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 9 Composite Structures / Port notation

  • Key: UML22-324
  • Legacy Issue Number: 11067
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    It is unclear if it is allowed to show the provided and required interfaces of a port in a composite structure diagram (ball and socket notation). That notation is already used for example in SysML. However I can't find the definition of it.

  • Reported: UML 2.1.1 — Fri, 25 May 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Ball and socket notation is only allowed for Components.

    Revised Text:

    Disposition: Closed, no change.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 16.3.2 Classifier (from UseCases)

  • Key: UML22-323
  • Legacy Issue Number: 11055
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The notation section of the classifier refers to the standard notation for nested classifiers. 1. I can't find that standard notation in the spec. 2. Nested classifiers are a feature of classes and not of classifiers. It seems that nesting and owning of classifiers is mixed up here

  • Reported: UML 2.1.1 — Wed, 23 May 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 18.3.1

  • Key: UML22-322
  • Legacy Issue Number: 11054
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    18.3.1 – Class claims that it is a merge increment on InfrastructureLibrary::Constructs::Class, when in fig 18.1 it seems that Profile merely imports Constructs rather than merging it.

  • Reported: UML 2.1 — Thu, 24 May 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Duplicate of 9830

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Common Behavior - isReentrant should default to true

  • Key: UML22-247
  • Legacy Issue Number: 9873
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    isReentrant should default to true

  • Reported: UML 2.1.1 — Tue, 27 Jun 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Having isReentrant default to false, as it currently does, means that, by default, there can be no concurrent invocations of a behavior, nor can a behavior be recursive. This does not seem to be the normal expectation of modelers when they model the invocation of behavior. Rather, the expected default it that behaviors are reentrant-with the ability to declare them not to be if that makes sense.
    On the other hand, it is often the case that, within an activity modeling, for example, a business or manufacturing process, an action invoking a behavior may be locally non-reentrant, in the sense that one invocation must complete before a new one can begin, because there is only a single performer to carry out the action. However, this case is more specifically addressed by Issue 6111. Once this is resolved at the local level, the default for the "global" isReentrant property on Behavior can be allowed to default to true, while "local" reentrancy for actions defaults to false.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Actions on non-unique properties with location specified

  • Key: UML22-246
  • Legacy Issue Number: 9870
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    Actions on non-unique properties with location specified. Clarify what happens in the actions applying to non-unique features / association ends when they specify location and an existing value (eg, RemoveStructuralFeature and Destroy actions) if the value to be acted on is not at the position specified.

  • Reported: UML 2.1.1 — Tue, 27 Jun 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Currently, the WriteStructuralFeatureAction and WriteVariableAction superclasses specify a required value input pin, so all kinds of write structural feature actions must have such a pin in all cases. However, when a removeAt pin is required for a RemoveStructuralFeatureValueAction or RemoveVariableValueAction (that is, when the feature or variable is ordered and non-unique and isRemoveDuplicates is false), the expectation is that whatever value is at the given position is removed. Having to provide any value at all is counterintuitive. If the value is ignored, then it is pointless. If the value has to be the same as the value at the given position, then it is extremely inconvenient and redundant to have to read the value at that position just to remove it!
    Therefore, the remove value actions should not have a value input pin in the case they are required to have a removeAt pin. This means that the value input pin should be optional in the write action superclasses, but should then be constrained to be required for the add value actions.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Actions - Output of read actions for no values

  • Key: UML22-243
  • Legacy Issue Number: 9863
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    Output of read actions for no values. In the various read actions (links, structural features, variables), what is the output when there are no values read? Is it a null token or no tokens at all?

  • Reported: UML 2.1.1 — Tue, 27 Jun 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Suppose the result output pin of a read action is connected by an object flow to an action with an input pin with a multiplicity lower bound of zero. Assuming the second action has no other inputs or incoming control flows, it still will not fire unless it receives some token on its input pin (note that this semantic interpretation of enabled actions is explicit in the Foundational UML specification). Thus, if the read action produces no token in the case that no values are read, then the second action will not fire, even though its input is optional. In order to ensure that the second action can actually fire with no input values, it would be necessary to also model an explicit control flow from the read action to the second action, which is inconvenient and can lead to ordering and sequencing issues between control and object tokens in the case when the read action does produce values.
    On the other hand, if the read action produces a null token when no values are read, then this will be offered to the second action, which can accept it, since its input multiplicity allows the case of no values. The second action will thus fire with an empty input, as would be intuitively expected. Note that if the second action's input pin had a multiplicity lower bound greater than zero, the semantics would not be effected by the offering of a null token, since this still would not provide the minimum number of values required for the action to fire.
    Therefore, in the framework of the token offer semantics of activities, it makes the most sense for a read action to produce a null token when there are no values to read. Note that this is also consistent with the semantics for call actions implied by the statement in Subclause 12.3.41 that if, at the time an activity finishes execution, "some output parameter nodes are empty…they are assigned null tokens", in which case one would expect the null tokens to be offered by the corresponding output pins of a call action for the activity. That is, call actions should also offer null tokens in the case that an output has no values.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Actions - InputPin semantics wording

  • Key: UML22-242
  • Legacy Issue Number: 9862
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    InputPin semantics wording. In Actions, InputPin, Semantic, second sentence, replace "how many values" with "the maximum number of values that can be".

  • Reported: UML 2.1.1 — Tue, 27 Jun 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    accepted

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Activities - Output pin semantics clarification

  • Key: UML22-245
  • Legacy Issue Number: 9869
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    Output pin semantics clarification. The current semantics for Action says it won't complete without the output pins having the minimum number of tokens, as specified by the minimum multiplicity. It should be clarified that the output values are not put in the output pins until it the action completes, so the tokens already in the output pins are not included in meeting the minimum multiplicity.

  • Reported: UML 2.1.1 — Tue, 27 Jun 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Activities - ForkNode semantics wording

  • Key: UML22-244
  • Legacy Issue Number: 9868
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    ForkNode semantics wording. In semantics of ForkNode, the phrase "keep their copy in an implicit FIFO queue until it can be accepted by the target" should not be different from other situations of ordered offers to refusing targets. In particular, it should be refined to clarify that the acceptance of offers by a fork is the same as acceptance by object nodes in the sense that they can't be revoked once accepted, and that for the edges leading to refusing targets, the offers are standing along those edges in the order they were received.

  • Reported: UML 2.1.1 — Tue, 27 Jun 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    In general, the ForkNode semantics needs to be more carefully worded in terms of offers of tokens, rather than just the tokens themselves "arriving" at a fork node.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Activities - Preserving order of multiple tokens offered.

  • Key: UML22-241
  • Legacy Issue Number: 9861
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    Preserving order of multiple tokens offered. In Activities, ActivityEdge, when tokens are offered in groups, for example for weight greater than 1, if the source and target are pins, the multiplicity ordering of the source node, if any, should be preserved in the target node.

  • Reported: UML 2.1.1 — Tue, 27 Jun 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    The real issue is preserving the ordering of offers as made by the source, whether the source is a pin or not. The relationship of multiplicity ordering on pins to the ordering of offers is handled by the resolution to Issue 9860.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Bad cross reference for InterfaceRealization Notation

  • Key: UML22-250
  • Legacy Issue Number: 9881
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    The notation part of Section 7.3.25 says "See Interface(from
    Interfaces)". However this has nothing to do with Realization. The
    cross-reference should in fact be to Realization - section 7.3.45 -
    which does have the notation needed.

  • Reported: UML 2.0 — Mon, 3 Jul 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

PrimitiveTypes access by UML (M1) models

  • Key: UML22-249
  • Legacy Issue Number: 9878
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    UML allows M1-level models to reuse the primitive types defined in the PrimitiveTypes package in the UML Infrastructure (e.g., Integer, String, etc.). Currently, this package is merged into L0 and is not separately accessible and should have its own URI so that it can be imported by M1 models without having to import the UML metamodel.

    This may also mean that instead of merging the package PrimitiveTypes into L0, the package should be imported

  • Reported: UML 2.0 — Thu, 29 Jun 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Unclear which Property has aggregation

  • Key: UML22-253
  • Legacy Issue Number: 9889
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    Where a diagram has a diamond it is not clear which end has the aggregation metaproperty. This can be discovered but only with a lot of detecetive work. For example 7.3.3 states "An association with aggregationKind = shared differs in notation from binary associations in adding a hollow diamond as a terminal adornment at the aggregate end of the association line. ". Nothing makes sufficiently clear that, for an aggregate property, that the diamond is depicted at the opposite end to the multiplicity and other annotations for that property.

  • Reported: UML 2.0 — Thu, 6 Jul 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Move Property::isId from MOF to UML

  • Key: UML22-252
  • Legacy Issue Number: 9888
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    It is a general requirement to be able to indicate candidate keys in UML models. This should be in Infrastructure (s still usable by MOF) and merged into Superstructure.

  • Reported: UML 2.0 — Thu, 6 Jul 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Notation for stereotypes on Comments and other elements

  • Key: UML22-248
  • Legacy Issue Number: 9877
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    Section 18.3.8, Notation, states "When a stereotype is applied to a model element (an instance of a stereotype is linked to an instance of a metaclass), the name of the stereotype is shown within a pair of guillemets above or before the name of the model element. " However several elements do not have names - for example Comment and LiteralString (the ODM Profile does define stereotypes on the latter).

    SysML contains the following.
    A comment note box may contain stereotype keywords or icons even though Comment is not a named element. UML specifies placement of a stereotype keyword relative to the name of the element. SysML makes explicit that they may appear inside a comment box as well. The stereotype keywords, if present, should appear prior to the comment text. The stereotype properties, if present, should appear after the comment text. The typical placement of stereotype icons is in the upper-right-hand corner of the containing graphical node.
    This approach should be used by UML and generalized for other non-named elements

  • Reported: UML 2.0 — Thu, 29 Jun 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Duplicate of 9706

  • Updated: Fri, 6 Mar 2015 20:58 GMT

text-diagram out of synch in Infrastructure 11.4.1

  • Key: UML22-251
  • Legacy Issue Number: 9885
  • Status: closed  
  • Source: Capability Measurement ( Karl Frank)
  • Summary:

    Bran at the Boston meeting remarked on the practical difficulty of keeping the Infrastructure doc up to date and in synch, text to diagrams and diagrams to underlying xmi.

    This is a report of a place where the text is out of synch with metamodel diagrams in doc.

    reference is to 06-04-03 Infrastructrue v2.1 doc.

    11.4.1 Classifier

    Associations • feature : Feature [*] Redefines the corresponding association in Abstractions. Subsets Namespace::member and is a derived union. Note that there may be members of the Classifier that are of the type Feature but are not included in this association (e.g., inherited features). Constraints No additional constraints Semantics No additional semantics

    Problem here is that Figure 11.16, the Constructs classifier diagram, shows the important general association, Classifier to Classifier, which is not mentioned in the text, needs to be documented under 11.4.1 Associations and probably also Semantics

  • Reported: UML 2.0 — Thu, 6 Jul 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Clarify isRequired

  • Key: UML22-254
  • Legacy Issue Number: 9890
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    18.3.2 the description for isRequired, while technically correct, is somewhat terse and does not make clear that the references to 'multiplicity are to the lower and upper properties of ExtensionEnd

  • Reported: UML 2.0 — Thu, 6 Jul 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

definition of 'isCompatibleWith' for ValueSpecification

  • Key: UML22-375
  • Legacy Issue Number: 12251
  • Status: closed  
  • Source: OFFIS e.V. ( Christian Mrugalla)
  • Summary:

    The definition of 'isCompatibleWith' for ValueSpecification starts with 'Property::isCompatibleWith[...]', instead it has to start with 'ValueSpecification::isCompatibleWith[...]'.

  • Reported: UML 2.1.2 — Thu, 28 Feb 2008 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • 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:58 GMT

formal definitions of 'isCompatibleWith' (pages 622, 647, 649)

  • Key: UML22-374
  • Legacy Issue Number: 12250
  • Status: closed  
  • Source: OFFIS e.V. ( Christian Mrugalla)
  • Summary:

    The three formal definitions of 'isCompatibleWith' start with: 'isCompatibleWith = p->oclIsKindOf(self.oclType) and [...]'. This is wrong, p and self have to be swapped, that is: 'isCompatibleWith = self.oclIsKindOf(p.oclType) and [...]'. Rationale: As defined in the OCL-specification formal/06-05-01, the function 'oclIsKindOf(t)' determines if t is either the direct type or one of the supertypes of the object, on which this function is called. That is, if the function returns true, the type t is a generalization or equal to the type of the current object. The corresponding has to be valid for 'isCompatibleWith(p)': If the function returns true, the type of p has to be the same or a generalization of the type of the object, on which this function is called (otherwise, the constraints [1] of 17.5.4 and 17.5.5 would make no sense).

  • Reported: UML 2.1.2 — Thu, 28 Feb 2008 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Agreed. (The operations in question are ParameterableElement::isCompatibleWith, ValueSpecification::
    isCompatibleWith and Property::isCompatibleWith.)
    This also resolves Issue 17870.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

association 'ownedTemplateSignature' of a Classifier

  • Key: UML22-373
  • Legacy Issue Number: 12244
  • Status: closed  
  • Source: OFFIS e.V. ( Christian Mrugalla)
  • Summary:

    For the association 'ownedTemplateSignature' of a Classifier, 'Subsets Element::ownedElement' is specified. This should be replaced by 'Redefines TemplateableElement::ownedTemplateSignature' (because a Classifier inherits 'ownedTemplateSignature' from its superclass TemplateableElement). Correspondingly, in figure 17.18 '

    {subsets ownedElement}

    ' should be replaced by '

    {redefines ownedTemplateSignature}

    '.

  • Reported: UML 2.1.2 — Wed, 27 Feb 2008 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • 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:58 GMT

term 'templatedElement' not defined

  • Key: UML22-376
  • Legacy Issue Number: 12252
  • Status: closed  
  • Source: OFFIS e.V. ( Christian Mrugalla)
  • Summary:

    There are two occurrences of the term 'templatedElement' in the Standard (both in an OCL-expression), but this term is nowhere defined. I propose to replace 'templatedElement' by 'template' on page 629 respectively 'Template::templatedElement' by 'TemplateSignature::template' on page 636.

  • Reported: UML 2.1.2 — Fri, 29 Feb 2008 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • 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:58 GMT

Usage of "Element::ownedMember"

  • Key: UML22-309
  • Legacy Issue Number: 10829
  • Status: closed  
  • Source: International Business Machines ( Andreas Maier)
  • Summary:

    In the Superstructure spec 2.1.1, there are a few occurences where an
    association end "ownedMember" in metaclass "Element" is referenced.
    This should be changed to reference the end "ownedElement" instead.

    The places I found, are:
    "Class::nestedClassifier"
    "Enumeration::ownedLiteral"
    "DataType::ownedAttribute"
    "DataType::ownedOperation"

  • Reported: UML 2.1 — Sat, 17 Mar 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    According to the metamodel diagrams,

    {subsets ownedMember}

    would refer to the closest inherited ownedMember attribute which would be Namespace, not Element. For example, see figure 7.12.
    Change all references of Element::ownedMember to Namespace::ownedMember.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Consistency in description of ends owned by associations

  • Key: UML22-308
  • Legacy Issue Number: 10827
  • Status: closed  
  • Source: International Business Machines ( Andreas Maier)
  • Summary:

    In the Superstructure spec 2.1.1, association ends owned by
    associations between UML metaclasses are not currently described in
    the descriptions of the metaclasses. Only ends owned by the
    associated classes are. In the abstract syntax diagrams, in a few
    cases, ends owned by the associations have labels and/or other
    specifications.

    It is quite confusing to not mention those association ends in some
    places, but to mention them in others. If the end is important enough
    to be described, this should be done consistently. If the end is
    irrelevant enough not to be described, it should consistently not be
    described (and thus be subject to the default naming rules).

    I suggest to establish consistency by determining for each such end,
    whether it is relevant or not to describe it. If it is relevant to
    describe it, then the end should be labeled in the diagrams, and it
    should be described in the metaclass descriptions. Otherwise, the end
    should be unlabeled and have no specifications in the diagrams and
    should not be described in the metaclass descriptions.

    Here is the set of ends owned by associations that is labeled in
    diagrams:
    Figure 7.5: "ValueSpecification::owningUpper"
    Figure 7.5: "ValueSpecification::owningLower"
    Figure 7.6: "ValueSpecification::expression"
    Figure 7.7: "ValueSpecification::owningConstraint"
    Figure 7.8: "ValueSpecification::owningSlot"
    Figure 7.8: "ValueSpecification::owningInstanceSpec"
    Figure 7.10: "ValueSpecification::owningParameter"
    Figure 7.10: "Parameter::ownerFormalParam"
    Figure 7.11: "Constraint::preContext"
    Figure 7.11: "Constraint::postContext"
    Figure 7.11: "Constraint::bodyContext"
    Figure 7.12: "ValueSpecification::owningProperty"
    Figure 7.12: "Classifier::class"
    Figure 7.14: "PackageableElement::owningPackage"
    Figure 7.15: "NamedElement::supplierDependency"

    Here is the set of ends owned by associations that is unlabeled but
    has specifications in diagrams:
    Figure 7.16: The right end of the aggregation between "Property"
    and "Interface" has a "

    {subsets ...}

    " specification.

  • Reported: UML 2.1 — Sat, 17 Mar 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.30

  • Key: UML22-306
  • Legacy Issue Number: 10818
  • Status: closed  
  • Source: ELIOP ( Ignacio Gonzalez)
  • Summary:

    Figur 12.95 - Fork node example has an error. Instead of: |-> Fill Order Fill Order -->| |> Send Invoice It should be: |> Ship Order Fill Order -->| |-> Send Invoice

  • Reported: UML 2.1.1 — Tue, 13 Mar 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 15.3.12

  • Key: UML22-312
  • Legacy Issue Number: 10832
  • Status: closed  
  • Source: Delphi ( Kirk Bailey)
  • Summary:

    The problem is with the definition of the ancestor query on page 559. I believe that the algorithm, as stated, determines whether s1 is an ancestor of s2, not whether s2 is an ancestor of s1.

  • Reported: UML 2.1 — Fri, 16 Mar 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    This method is testing that s2 is nested within s1, and such s1 would be the ancestor. The method description is therefore wrong and needs to be fixed as suggested.
    Furthermore, the check that s1 has a container has no bearing on whether s2 is contained within it. And the parameters of the function accept states but we are passing the container which will be a region.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

"PackageableElement::visibility" uses "false" as default value

  • Key: UML22-311
  • Legacy Issue Number: 10831
  • Status: closed  
  • Source: International Business Machines ( Andreas Maier)
  • Summary:

    In the Superstructure spec 2.1.1, the description of
    "PackageableElement::visibility" says: "Default value is false."
    However, "false" is not a valid value for the type "VisibilityKind".

    I suggest that the default visibility be defined as "public". While
    it may make sense for properties in a class to be private by default,
    this is not the case for packageable elements, here it makes way more
    sense to have a public default. The description should be changed
    accordingly.

    Second, the UML Metamodel CMOF files define metaclass
    "PackageableElement" to be a specialization of metaclass
    "NamedElement" without redefining "visibility". However, the
    metaclass description in the superstructure spec does redefine
    "visibility". The CMOF files should be adjusted to make the same
    redefinitions the description makes.

  • Reported: UML 2.1 — Sat, 17 Mar 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Regarding the first point,.PackageableElement::visibility already has „public? as a default value in the normative CMOF models, so the description in the spec text needs to be corrected as suggested in the issue.
    Regarding the second point, PackageableElement::visibility in the CMOF models already redefines NamedElement::visibility, matching the spec doc, so no change is needed.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Mismatch between Superstructure ptc/06-04-02 and XML Schema ptc/06-04-05

  • Key: UML22-302
  • Legacy Issue Number: 10778
  • Status: closed  
  • Source: MID GmbH ( Mr. Detlef Peters)
  • Summary:

    Possible Mismatch between Superstructure ptc/06-04-02 and XML Schema ptc/06-04-05

    Please clarify the effects of the merge increments of 'Class' on its descendants, esp. on the 'Behavior' subtypes. IMHO the fact that 'behavior' inherits from 'Class (from Kernel)' implies that in turn it does NOT inherit features from 'BehavioredClassifier' or 'EncapsulatedClassifier' even on Compliance level L1. This would mean that e.g. an interaction may not have ownedPorts or ownedBehaviors, but nestedClassifier.

    If this is not the case, please clarify the precedence between the merge and inheritance constructs.
    Example:
    L1 (as seen in Fig. 2.2) merges Kernel, BasicBehaviors and InternalStructures and thus provides the 'Class', 'BehavioredClassifier' and 'EncapsulatedClassifier' constructs simultanously.

    • If inheritance comes before merging (which is what the diagrams suggest), 'Behavior' will have neither ownedPorts nor ownedBehaviors.
    • If merging comes before inheritance (which is what the XSD suggests), 'Behavior' will both have ownedPorts and ownedBehaviors.

    In the second case, the question arises that if even in L1 the three constructs mentioned above are provided, why does 'Behavior' not simply inherit from 'Class (from StructuredClasses)', directly being an EncapsulatedClassifier?

  • Reported: UML 2.1 — Fri, 16 Feb 2007 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page: 155, 162

  • Key: UML22-301
  • Legacy Issue Number: 10651
  • Status: closed  
  • Source: DMR Consulting ( Jasmin Bouchard)
  • Summary:

    In the notation for ComponentRealization on section 8.3.4 (page 162), it is stated that a ComponentRealization is notated in the same way as a realization dependency, "i.e., as a general dashed line with an open arrow-head". This contradicts the notation presented for Realization in section 7.3.45 (page 133), where it is stated that "A Realization dependency is shown as a dashed line with a triangular arrowhead at the end". If the notation of section 8.3.4 is indeed in error, Figure 8.10 (page 155) should be corrected to use triangular arrowheads, since it is a representation of the realization of a complex component.

  • Reported: UML 2.1 — Tue, 6 Feb 2007 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Resolution:
    This is a duplicate of 11007 (incorrect arrowhead in text) and 8705 (incorrect fig 8.10).

    Revised Text:
    None.
    Disposition: Duplicate of 8705 and 11007

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 17/17.5.7

  • Key: UML22-305
  • Legacy Issue Number: 10802
  • Status: closed  
  • Source: CNAM ( Jean-Frederic Etienne)
  • Summary:

    Missing constraint for template binding in classifier context There seems to be an omitted constraint for template binding in the context of the classifier metaclass on page 667. Indeed, there is no restriction to the kind of template element to which a classifier can be bound. For example, nothing forbids a class to be bound to a data type or association or even an operation defined as template. There is a need for a constraint similar to the one defined on page 57, where it is stated that a classifier can only specialize classifiers of a valid type. Something like, self.templateBinding -> forAll(tb | self.oclIsKindOf(tb.signature.template.oclType)) Note that the variable oclType is not a valid OCL expression, even though it is referenced more than once in the UML Superstructure document (e.g definition of maySpecializeType on page 58). We therefore here assume that the oclType expression returns the associated metatype of the uml element to which it is applied. Thanks in advance for any feedback Jean-Frédéric Etienne

  • Reported: UML 2.1.1 — Mon, 5 Mar 2007 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    This is covered in constraint [1] of TemplateParameterSubstitution, section 17.5.5.
    Revised Text:
    Disposition: Closed, no Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Port.provided:Interface

  • Key: UML22-304
  • Legacy Issue Number: 10789
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    ptc/2006-04-02/p187.

    The spec for Port.provided:Interface says: “References the interfaces specifying the set of operations and receptions that the classifier offers to its environment, and which it will handle either directly or by forwarding it to a part of its internal structure. This association is derived from the interfaces realized by the type of the port or by the type of the port, if the port was typed by an interface.”

    This would seem to indicate that a Port typed by an Interface cannot have more than one provided interface. Clarify that this was the intention, or fix if not.

  • Reported: UML 2.1 — Tue, 27 Feb 2007 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    I cannot see how it can mean anything else. This specification was modified in the resolution to 13080 and the meaning is clear there.

    Revised Text:

    Disposition: Closed, no change.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 14.3.28 ReceiveSignalEvent (from BasicInteractions)

  • Key: UML22-300
  • Legacy Issue Number: 10650
  • Status: closed  
  • Source: Softeam ( Cédric MARIN)
  • Summary:

    About "8784 - add ReceiveOperationEvent and ReceiveSignalEvent metaclasses" issue, the "ReceiveSignalEvent" (14.3.28 p522) metaclass seems to have the same meaning as "SignalEvent" (13.3.25 p468) and is then redundant. This issue should be resolved by either: - detailing the differences between ReceiveSignalEvent and SignalEvent - removing the ReceiveSignalEvent metaclass

  • Reported: UML 2.1 — Tue, 6 Feb 2007 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    See issue 14629 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.38

  • Key: UML22-299
  • Legacy Issue Number: 10637
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Is "Set of <name>" a keyword? Or is it allowed to write for example "<name>List" or "<name>Container"?

  • Reported: UML 2.1.1 — Fri, 2 Feb 2007 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    This issue applies to Figure 15.49 in Subclause 15.4.4 of the UML 2.5 beta specification. Since ObjectNodes
    are not MultiplicityElements, the only way that an ObjectNode can contain a set or other collection is if its
    type is a collection type. Since UML does not provide any standard such types, the notation cannot be fully
    standardized

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML2: Actor cannot have ownedAttributes

  • Key: UML22-303
  • Legacy Issue Number: 10780
  • Status: closed  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    Constraint [1] in section 16.3.1 is incorrect.
    [1] An actor can only have associations to use cases, components, and classes. Furthermore these associations must be binary.
    self.ownedAttribute->forAll ( a |
    (a.association->notEmpty()) implies
    ((a.association.memberEnd.size() = 2) and
    (a.opposite.class.oclIsKindOf(UseCase) or
    (a.opposite.class.oclIsKindOf(Class) and not a.opposite.class.oclIsKindOf(Behavior))))

    An Actor is a BehavioredClassifier and therefore cannot have ownedAttributes. The constraint above would have to iterate over all the associations in the model and insure that if one ownedEnd is an Actor or UseCase, the other ownedEnd must be a UseCase or Actor respectively.

  • Reported: UML 2.1 — Tue, 20 Feb 2007 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Agreed. This also resolves issues 13948 and 14875

  • Updated: Fri, 6 Mar 2015 20:58 GMT

State Machines

  • Key: UML22-314
  • Legacy Issue Number: 10931
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Execution semantics of deferrable triggers. The execution semantics of deferrable triggers in the notation section of Transition, under Figure 15.44, conflicts with the semantics given in State. The description of deferrable trigger in the State attribute and semantics sections say a deferred event remains deferred until the machine reaches a state where it is consumed. The notation section of Trigger says the deferred event is lost when the machine reaches a state where the event is not consumed and not deferred

  • Reported: UML 2.1.1 — Sun, 25 Mar 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 18.3.8

  • Key: UML22-313
  • Legacy Issue Number: 10930
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The description how values of a stereotyped element can be shown offers three ways. But all of them requires a graphical node. There is no description how to show the values of a stereotyped element that has no graphical notation, e.g. an attribute

  • Reported: UML 2.1.1 — Tue, 20 Mar 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Resolution: Duplicate of 9877

  • Updated: Fri, 6 Mar 2015 20:58 GMT

"Constraint::context" is marked as derived in the metaclass description

  • Key: UML22-310
  • Legacy Issue Number: 10830
  • Status: closed  
  • Source: International Business Machines ( Andreas Maier)
  • Summary:

    In the Superstructure spec 2.1.1, the description of the "context"
    association end in metaclass "Constraint" has the leading slash,
    marking it as derived. This is probably wrong. Besides not making
    much sense for this end to be derived, the following places support
    the view that "context" is meant to be non-derived:

    • The text in the description of the "context" end does not state
      from what or how the end would be derived.
    • In the UML Metamodel CMOF files, the end is not defined to be
      derived.
    • In figure 7.7, the "context" end is shown as non-derived.

    The description of the "context" end in the Superstructure spec
    should be changed to remove the derived-mark (leading slash) from it.

  • Reported: UML 2.1 — Sat, 17 Mar 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Constraint::context is not derived in the metamodel. See figure 7.7. This is already correct in InfrastructureLibrary.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

discrepancies between package dependencies and XMI file for Superstructure

  • Key: UML22-222
  • Legacy Issue Number: 9818
  • Status: closed  
  • Source: Technolution ( Mick Baggen)
  • Summary:

    I verified the alignment between the package dependencies (packageImport and packageMerge) in the XMI file Superstructure.cmof (contained in ptc-06-01-04) and the package dependency diagrams in the convenience document, and noticed some discrepancies. Assuming the XMI file is correct, these discrepancies are: - Part I, Figure 1 (p.19): the packageImports from Classes to CommonBehaviors and AuxiliaryConstructs are missing. - Figure 7.2 (p.22): the packageImport from Dependencies to Kernel is missing. - Figure 9.1 (p.168): the packageImports from Ports to Kernel and Interfaces are missing. - Figure 10.1 (p.202): the packageImport from Nodes to Kernel is missing. - Part II, Figure 1 (p.225): the packageImports from StatesMachines, Activities and Interactions to CompositeStructures are missing. - Part II, Figure 1 (p.225): the packageImport from Activities to StateMachines is missing. - Part II, Figure 1 (p.225): the packageImport from CommonBehaviors to Actions is missing. - Part II, Figure 1 (p.225): the packageImport from UseCases to CommonBehaviors is not correct: it is not present in the XMI file. There only exists a packageMerge relation from UseCases to BasicBehaviors. - Figure 11.1 (p.230): the packageImports from CompleteActions to Kernel and BasicBehaviors are missing. - Figure 11.1 (p.230): the packageImport from IntermediateActions to Kernel is missing. - Figure 11.1 (p.230): the packageMerge from IntermediateActions to BasicBehaviors is missing. - Figure 12.1 (p.309): the packageImports from CompleteActivities to Kernel and BasicBehaviors are missing. - Figure 12.1 (p.309): the packageImports from IntermediateActivities to Kernel and BasicBehaviors are missing. - Figure 12.1 (p.309): the packageMerge from BasicActivities to BasicBehaviors is missing. - Figure 15.1 (p.546): the packageMerge from BehaviorStateMachines to Communications is missing. - Part III, Figure 1 (p.631): the packageImport from AuxiliaryConstructs to Classes is missing.

  • Reported: UML 2.1 — Sat, 10 Jun 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Figure 14.5

  • Key: UML22-224
  • Legacy Issue Number: 9820
  • Status: closed  
  • Source: Technolution ( Mick Baggen)
  • Summary:

    The editorial fix in Figures 14.5 is not carried out: OccurenceSpecification is still abstract, not concrete. Please note that there is no editorial fix planned for, or applied to Figures 14.3 and 14.4. However, in these figures OccurenceSpecification is also shown as abstract. All of the figures pertaining to the package BasicInteractions should at least show the same view of OccurenceSpecification

  • Reported: UML 2.1 — Sat, 10 Jun 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Appendix F

  • Key: UML22-223
  • Legacy Issue Number: 9819
  • Status: closed  
  • Source: Technolution ( Mick Baggen)
  • Summary:

    The Classifier taxonomy in Appendix F shows a Generalization from Collaborations::Collaboration (child) to Collaborations::Classifier (parent). This Generalization is not present in the metamodel in Figure 9.6 (p. 172), and I therefore believe it to be in error.

  • Reported: UML 2.1 — Sat, 10 Jun 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 8.3.1

  • Key: UML22-218
  • Legacy Issue Number: 9807
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Fig. 8.12 shows delegate connectors that are directly connected with an interface. According to the metamodell that's not possible. A connector end can only be connected with connectable elements.

  • Reported: UML 2.1.1 — Wed, 7 Jun 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Resolution:
    Resolved by the changes specified in 8168.

    Revised Text:
    None.
    Disposition: Duplicate of 8168.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

General ordering cycles

  • Key: UML22-217
  • Legacy Issue Number: 9806
  • Status: closed  
  • Source: Eclipse Foundation ( Mr. Kenneth Hussey)
  • Summary:

    There should be a constraint preventing the definition of general ordering cycles (involving occurrence specifications), as there is with generalizations

  • Reported: UML 2.0 — Tue, 6 Jun 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

What exactly is a state list?

  • Key: UML22-215
  • Legacy Issue Number: 9800
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The UML2.1 specification defines a state list:

    The special case of the transition from the junction having a history as
    target may optionally be presented as the target
    being the state list state symbol. See Figure 15.27 and Figure 15.28 for
    examples.

    I couldn't map that definition to the example. There is no junction and
    no history state. Can someone
    provide fig. 15.27 in another notation without state list?

    I'm not the first one who's asking this. Probably we should provide such
    an example in the spec.

  • Reported: UML 2.0 — Tue, 30 May 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 9.14.2

  • Key: UML22-214
  • Legacy Issue Number: 9760
  • Status: closed  
  • Source: Self-Employed ( Steven Coco)
  • Summary:

    The definition of Namespace lists as a generalization, Namespace. This appears to be an error: it appears this is intented to refer to NamedElement.

  • Reported: UML 2.0 — Wed, 24 May 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.1.3

  • Key: UML22-213
  • Legacy Issue Number: 9752
  • Status: closed  
  • Source: Watt Systems Technologies ( Kenneth Lloyd)
  • Summary:

    Element reads "Constructs::Element reuses the definition of Element from Abstractions::Comments." Since this element has been removed should this read "Constructs::Element reuses the definition of Element from Abstractions::Ownerships." as reflected in the merge?

  • Reported: UML 2.0 — Wed, 17 May 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Action inputs/outputs

  • Key: UML22-212
  • Legacy Issue Number: 9720
  • Status: closed  
  • Source: Eclipse Foundation ( Mr. Kenneth Hussey)
  • Summary:

    Seeing as Action::input and Action::output are derived compositions that subset Element::ownedElement, all subsets of them should be compositions (I thought Karl had added a constraint to this effect?). In particular, OpaqueAction::inputValue, OpaqueAction::outputValue, AcceptEventAction::result, AcceptCallAction::returnInformation, UnmarshallAction::result should be composite

  • Reported: UML 2.0 — Mon, 15 May 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 7.3.44

  • Key: UML22-225
  • Legacy Issue Number: 9822
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Sebastien Gerard)
  • Summary:

    In the defintion of the Property concept, the type of the default attribute is a String. I believe it would be more powerful to type default with ValueSpecification

  • Reported: UML 2.1.1 — Mon, 12 Jun 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Actually, Property::defaultValue is a ValueSpecification, which gives what is required. Property::/default is
    a derived string, although its current documentation—“A String that is evaluated to give a default value for
    the Property when an instance of the owning Classifier is instantiated” — is misleading. Property::/default
    only exists at all because of earlier efforts to align superstructure and infrastructure through package merge.
    Its derivation makes no sense for default values that are not strings. Since it is derived, removing it would
    not affect model serialization. Delete it.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 7.2

  • Key: UML22-221
  • Legacy Issue Number: 9817
  • Status: closed  
  • Source: Technolution ( Mick Baggen)
  • Summary:

    In paragraph 7.2 it says: "Figure 7.2 shows the package dependencies of the Kernel packages". However, this should read "...dependencies of the Classes packages." The caption of figure 7.2 is correct.

  • Reported: UML 2.1 — Sat, 10 Jun 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page: 64 & 112

  • Key: UML22-220
  • Legacy Issue Number: 9812
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Sebastien Gerard)
  • Summary:

    The section 7 contains two concepts, ElementImport and PackageImport, that seems to quite redundant. I believe that the semantics of ElementImport covers the semantics of PackageImport. SO, either clarify the difference (if there are?), or delete the PackageImport or make PackageImport a specialization of ElementImport.

  • Reported: UML 2.1.1 — Fri, 9 Jun 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Completion event modeling

  • Key: UML22-219
  • Legacy Issue Number: 9808
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Completion events are an explicit concept in UML statecharts. However, there is no corresponding metaclass either in the Common Behavior section or in Statecharts. Since completion events trigger transitions, it may be necessary to have an explicit CompletionEvent metaclass. For instance, we may want to model an interaction in which execution occurrences are initiated by completion events.

  • Reported: UML 2.0 — Wed, 7 Jun 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Requires the addition of a new meta class. This needs to be postponed to a later revision when we will have more time to investigate this proposal and its impacts.

    Revised Text:
    N/A
    Disposition: Closed, out of scope

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Editorial bug in 2.1 Superstructure Convenience document

  • Key: UML22-216
  • Legacy Issue Number: 9803
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    The Convenience document is inconsistent with the resolution with 9087 and itself: the spec shows Package::packagedElement as derived in the Associations section of 7.3.37 whereas it's clearly not in the resolution. Figure 7.14 is actually OK as is the metamodel.

  • Reported: UML 2.0 — Mon, 5 Jun 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

7.3.4 Association Class

  • Key: UML22-183
  • Legacy Issue Number: 9249
  • Status: closed  
  • Source: Paranor AG ( Earl Waldin)
  • Summary:

    The specification should state when navigation between an association class and the endpoints of that association class are allowed. When there is an association class between two classes, OCL allows navigation between these classes and the association class itself (see Sections 7.5.4 and 7.5.5 of the OCL 2.0 specification ptc/2005-06-06). However, navigability in UML2 is defined with respect to the metaclass Property and the semantics describe navigability in terms of navigating across an association via a property, i.e., from one endpoint to the other (see the definition of isNavigable() in Section 7.3.44, subsection Additional Operations, and descriptions of navigability in sections 7.3.3 - Association, 7.3.7 - Class, and 7.3.44 – Property.) No mention of navigability to and from association classes is found in section 7.3.4 – Association Class, nor any place else in the specification. One simple possibility would be for navigation involving association classes to respect navigation between its endpoints. For example, if classes C1 and C2 are connected by an association class A, then if one can navigate from C1 to C2 (C1->C2), then one can navigate from C1 to A (C1->A) and from A to C2 (A->C2). Another simple possibility would be to always allow navigation from an association class to its endpoints while requiring navigation from an endpoint to the association class to respect navigability. For example, if the association is one-way navigable from C1 to C2 (C1->C2) then one could navigate from C1 to A (C1->A) and from A to C2 (A->C2) as above and, in addition, from A to C1 (A->C1). Anything more complex than these two simple alternatives requires deeper investigation into the semantics of the UML metamodel or even changing the metamodel. For example, the association ownedEnd: Property for Association in section 7.3.3 could subset Classifier::attribute instead of Classifier::feature. Or in the definition of Association Class in 7.3.4 one could allow the inherited associations ownedAttribute: Property and ownedEnd: Property to overlap, i.e., be non-disjoint, although this may have technical difficulties because these two associations are compositions.

  • Reported: UML 2.0 — Thu, 19 Jan 2006 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2.2 scope statement

  • Key: UML22-334
  • Legacy Issue Number: 11152
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Current Scope section in UML 2.1.1 Infrastructure
    =================================================

    This UML 2.1.1: Infrastructure is the first of two complementary
    specifications that represent a major revision to the Object Management
    Group's Unified Modeling Language (UML), for which the previous current
    version was UML v1.5. The second specification, which uses the
    architectural foundation provided by this specification, is the UML 2.1.1:
    Superstructure. The UML 2.1.1: Infrastructure defines the foundational
    language constructs required for UML 2.1.1. It is complemented by UML
    2.1.1: Superstructure, which defines the user level constructs required for
    UML 2.1.1.

    Current Scope section in UML 2.1.1 Superstructure
    =================================================

    This Unified Modeling Language: Superstructure is the second of two
    complementary specifications that represent a major revision to the Object
    Management Group's Unified Modeling Language (UML), for which the most
    current version is UML v2.0. The first specification, which serves as the
    architectural foundation for this specification, is the Unified Modeling
    Language: Infrastructure.

    This Unified Modeling Language: Superstructure defines the user level
    constructs required for UML 2. It is complemented by Unified Modeling
    Language: Infrastructure which defines the foundational language constructs
    required for UML 2. The two complementary specifications constitute a
    complete specification for the UML 2 modeling language.

    Proposed Scope section
    ======================

    This specification defines the Unified Modeling Language (UML), revision 2.
    The objective of UML is to provide system architects, software engineers,
    and software developers with tools for analysis, design, and implementation
    of software-based systems as well as for modelling business and similar
    processes.

    The initial versions of UML (UML 1) originated with three leading
    object-oriented methods (Booch, OMT, and OOSE), and incorporated a number
    of best practices from modelling language design, object-oriented
    programming and architectural description languages. Relative to UML 1,
    this revision of UML has been enhanced with significantly more precise
    definitions of its abstract syntax rules and semantics, a more modular
    language structure, and a greatly improved capability for modelling
    large-scale systems.

    One of the primary goals of UML is to advance the state of the industry by
    enabling object visual modeling tool interoperability. However, to enable
    meaningful exchange of model information between tools, agreement on
    semantics and notation is required. UML meets the following requirements:

    • A formal definition of a common MOF-based metamodel that specifies the
      abstract syntax of the UML. The abstract syntax defines the set of UML
      modelling concepts, their attributes and their relationships, as well as
      the rules for combining these concepts to construct partial or complete UML
      models.
    • A detailed explanation of the semantics of each UML modelling concept.
      The semantics define, in a technology-independent manner, how the UML
      concepts are to be realised by computers.
    • A specification of the human-readable notation elements for representing
      the individual UML modelling concepts as well as rules for combining them
      into a variety of different diagram types corresponding to different
      aspects of modelled systems.
    • A detailed definition of ways in which UML tools can be made compliant
      with this specification. This is supported (in a separate specification)
      with an XML-based specification of corresponding model interchange formats
      (XMI) that must be realised by compliant tools.
  • Reported: UML 2.1 — Thu, 12 Jul 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Property::isAttribute() query needs no argument

  • Key: UML22-333
  • Legacy Issue Number: 11120
  • Status: closed  
  • Source: Eclipse Foundation ( Mr. Kenneth Hussey)
  • Summary:

    The Property::isAttribute() OCL query (see p. 133 of 07-02-03) is currently defined to take an argument:

    [4] The query isAttribute() is true if the Property is defined as an
    attribute of some classifier
    context Property::isAttribute(p : Property) : Boolean
    post: result = Classifier.allInstances->exists(c|
    c.attribute->includes(p))

    This argument (p) is not necessary, as the query should be based on the context property. Note that the OCL body for this query does not appear to be correct either.

  • Reported: UML 2.1 — Wed, 4 Jul 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Yes, this is wrong. Fix it. This also resolves issue 12842.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.4

  • Key: UML22-330
  • Legacy Issue Number: 11114
  • Status: closed  
  • Source: NIST ( Mr. Peter Denno)
  • Summary:

    The derivation of Classifier.inheritedMember is incorrect: self.inheritedMember->includesAll(self.inherit(self.parents()->collect(p | p.inheritableMembers(self))) The "collect" in that should be "select". I'd also appreciate it if someone could tell me why the spec does not match the l3-merged.cmof here, and particularly, whether the transformation of the above into a query/derivation (by removal of the includesAll) was intentional in the l3-merged.cmof, or just some accident which suggests that the l3-merged.cmof is not up-to-date with the specification .pdf.

  • Reported: UML 2.1 — Fri, 29 Jun 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    See issue 15267 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.4 Classifiers Diagram

  • Key: UML22-329
  • Legacy Issue Number: 11109
  • Status: closed  
  • Source: Department of Computer Science and Technology, Nanjing University ( Zhang, Tian)
  • Summary:

    In "Figure 11.16 - The Classifiers diagram of the Constructs package", the end of the association between Classifier and Feature are named as "/featuringClassifier" and "/feature". But in "11.4.1 Classifier" the Assciations part illustrates the feature without slash. Also, in "11.4.2 Feature" the featuringClassifier is demonstrated without slash neither. According to UML series specifications, "/featuringClassifier" and "/feature" are different from "featuringClassifier" and "feature".

  • Reported: UML 2.1 — Fri, 22 Jun 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Figure 7.10 indicates that Classifier::/feature and Feature::/featuringClassifier are both derived unions. Classifier:: /feature is shown as derived in section 7.3.8 where it is described. Feature::/featuringClassifier is shown as derived in section 7.3.19 where it is described. So there are no issues for Superstructure

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Actor concept was indeed changed

  • Key: UML22-340
  • Legacy Issue Number: 11200
  • Status: closed  
  • Source: Capability Measurement ( Karl Frank)
  • Summary:

    The constraints on associations include a condition that an Actor not be associated with a Behavior, which blocks the owned behavior and classifier behavior, but in that case, it is a mystery to me why Actors were made to be BehavioredClassifiers.

    This is not an issue with the consistency or clarity of the spec.
    It is an issue with understanding the use of UML 2 as contrasted with UML 1.n

    The 2.1.1 spec, section 16.3.1, says:

    Changes from previous UML There are no changes to the Actor concept except for the addition of a constraint that requires that all actors must have names.

    But a very important change was introducing BehavioredClassifier (there was no BehavioredClassifier in UML 1) , and then making it the generalization of Actor, which gives Actors

    1. ability to own behaviors
    2. ability to have a unique classifier behavior
    3. and own triggers.

    some remarks on the intended pragmatics of this change would make UML spec better.

    Merely citing the change in the "Changes.." section provide accuracy without value, but explaining what use is foreseen for this change, would provide value.

  • Reported: UML 2.1 — Tue, 24 Jul 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 13.3.3

  • Key: UML22-339
  • Legacy Issue Number: 11162
  • Status: closed  
  • Source: Patterndigm ( Ben Bovee)
  • Summary:

    In, "Table 12.1 - Graphic nodes included in activity diagrams," the 'Notation' entry for 'ActivityNode' should exclude "ExecutableNode" (unless such an entry is added--or found elsewhere).

  • Reported: UML 2.1 — Wed, 18 Jul 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

composite subsets

  • Key: UML22-343
  • Legacy Issue Number: 11238
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    There are several places in metamodel where non-derived composite property is subset of other non-derived composite property.
    In this case element is owned in two collections, so how it should be reflected in XMI where element could appear just once?
    We can leave element just in subset, and merge collections after load, but is this correct?

    Below are these occurrences:

    classes::mdKernel::Operation::bodyCondition subsets ownedRule

    statemachines::mdBehaviorStateMachines::Transition::guard subsets ownedRule

    classes::mdKernel::Operation::postcondition subsets ownedRule

    statemachines::mdProtocolStateMachines::ProtocolTransition::postCondition
    subsets ownedRule

    classes::mdKernel::Operation::precondition subsets ownedRule

    statemachines::mdProtocolStateMachines::ProtocolTransition::preCondition
    subsets ownedRule

    Profile::metaclassReference subsets elementImport

    uml2.1.1::mdProfiles::Profile::metaclassReference subsets packageImport

  • Reported: UML 2.1 — Wed, 1 Aug 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2.1.2: Path names for CMOF files

  • Key: UML22-342
  • Legacy Issue Number: 11234
  • Status: closed  
  • Source: Eclipse Foundation ( Mr. Kenneth Hussey)
  • Summary:

    The (new) path names for the CMOF files, based on the naming proposal that was presented in Brussels, need to be listed next to the bullet points in Appendix H of the UML specification. This change should be made as part of the urgent ballot for UML 2.1.2.

  • Reported: UML 2.1 — Wed, 25 Jul 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 7.3.21 figure 7.47

  • Key: UML22-332
  • Legacy Issue Number: 11116
  • Status: closed  
  • Source: myself ( jonathan tanner)
  • Summary:

    Figure 7.47 - Power type notation Specific classifier-2 has powertype 'classifier-1' but inherits from PowerType Classifier-2. Should the inheritance lines not point to the 'General Classifier'?

  • Reported: UML 2.1.1 — Tue, 3 Jul 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 7.3.21

  • Key: UML22-331
  • Legacy Issue Number: 11115
  • Status: closed  
  • Source: myself ( jonathan tanner)
  • Summary:

    Inconsistancy between background fill colouring. Default colour preferences are normally white background, black text, and this issue is then not visible. Changing to a custom colouring to green backgrond, black text, one sees that that some boxes are filled white, whereas others are the same as the selected background colour. Is this intentional? Does this have any semantic meaning? Example in Figure 7.47 (b) Power type notation. The PowerType classifiers use the page background

  • Reported: UML 2.1.1 — Tue, 3 Jul 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Abstractions (02)

  • Key: UML22-337
  • Legacy Issue Number: 11156
  • Status: closed  
  • Source: MEGA International ( Mr. Antoine Lonjon)
  • Summary:

    Generalization of Parameter to NamedElement in redundant in Abstractions. Would be easier on serialization to remove the multiple inheritance.

  • Reported: UML 2.1 — Mon, 16 Jul 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Constructs

  • Key: UML22-336
  • Legacy Issue Number: 11155
  • Status: closed  
  • Source: MEGA International ( Mr. Antoine Lonjon)
  • Summary:

    Package import is defined in the context of Namespace. This has two consequences: 1. Namespaces such as Classe, Node, and UseCase can import Packages. This does not seem to be a good design goal. 2. There is a circular definition between Package and Namespace: Package is a sub-type of Namespace and Namespace requires the definition of Package and PackagedElement.

  • Reported: UML 2.1 — Mon, 16 Jul 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Namespace URI for Standard Profile(s)

  • Key: UML22-338
  • Legacy Issue Number: 11160
  • Status: closed  
  • Source: Eclipse Foundation ( Mr. Kenneth Hussey)
  • Summary:

    The UML (Superstructure) specification does not define the namespace URI for the standard profile(s) - it should. Note that the currently recommended convention (from p. 703, section 18.3.6 of 07-02-03) for such URIs is

    nsURI = http://<profileParentQualifiedName>/schemas/<profileName>.xmi

  • Reported: UML 2.1 — Wed, 18 Jul 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Abstractions

  • Key: UML22-335
  • Legacy Issue Number: 11154
  • Status: closed  
  • Source: MEGA International ( Mr. Antoine Lonjon)
  • Summary:

    Abstractions should support serialization by itself and interoperably with serialization of Constructs. In particular: - Package and Property should be available in Abstractions, to enable Abstractions to be used for serialization of typical models by itself. - There should be no circular dependencies between packages in Abstractions. - Constructs should only use imports from Abstractions, to enable models using Constructs to interoperate with models using only Abstractions. Package merge produces noninteroperable XSDs

  • Reported: UML 2.1 — Mon, 16 Jul 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 14.3.3

  • Key: UML22-341
  • Legacy Issue Number: 11201
  • Status: closed  
  • Source: mit.bme.hu ( Zoltan Micskei)
  • Summary:

    In the Notation part of CombinedFragment, in the part 'Presentation Options for “coregion area"' the text refers to Figure 14.12 for an example of a coregion. However, on Figure 14.12 there is no coregion. The reference should be changed to Figure 14.22

  • Reported: UML 2.1.1 — Thu, 26 Jul 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Invalid mandatory compositions and associations

  • Key: UML22-264
  • Legacy Issue Number: 10074
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    I initially thought this just affected chapter 11 and compositions, but the more I looked the wider the impact: this seems quite a systemic problem.

    There are several significant metamodel errors that would prevent population of models in repositories that enforce association semantics. These affect both the diagrams and the metamodel (though I have not checked every association in the metamodel XMI).
    The common problem is metaclasses being shown with multiple mandatory composite owners (i.e. a multiplicity of 1 as opposed to 0..1) next to the black diamond. In some cases this is implicit (the default multiplicity being 1..1, in others explicitly '1'). Since any instance can have at most one composite owner, to have more than one such owner mandatory makes for an 'impossible' (to be valid) metamodel.

    There are non-composition cases where it also does not make sense to have associations mandatory. Often the mandatory nature is implicit (there is not explicit multiplicity shown on the diagrams).

    Here is the list of diagrams and the problematic classes:
    Figure 7.7 Element (not every Element will be constrained)
    Figure 7.8 StructuralFeature (not every StructuralFeature will have a Slot defined for it in some instance model) and Classifier (again not every Classifier will have at least one InstanceSpecification)
    Figure 7.9 NamedElement, Classifier (for redefinedElement, general), RedefinableElement (for redefinedElement, redefinitionContext)
    Figure 7.10 Type
    Figure 7.12 Type (via endType), Class(via superClass), and Property (via opposite, redefinedProperty, subsettedProperty)

    Figure 8.2 Classifier (not every Classifier will realize a Component) and Interface (not every Interface will be both provided and required by at least one Component)

    Figure 10.2 Artifact (inverse of nestedArtifact is mandatory - not every Artifact will be nested in another)
    Figure 10.3 Node (ditto for nestedNode)

    Figure 11.3 InputPin and OutputPin
    Figure 11.4 InputPin and OutputPin
    Figure 11.5 InputPin
    Figure 11.8 InputPin
    Figure 11.13 InputPin
    Figure 11.17 InputPin and OutputPin.

    Figure 11.2 does not have mandatory composition but requires each InputPin (and OutputPin) to be the inputValue of an OpaqueAction which seems quite wrong.

    Figure 12.10 ValueSpecification
    Figure 12.11 ValueSpecification
    Figure 12.13 Constraint
    Figure 12.14 ValueSpecification
    Figure 12.19 ValueSpecification

    Figure 13.12 ValueSpecification
    Figure 13.13 ValueSpecification and Observation (the latter is not a composition error but it seems wrong)

    Figure 14.3 Constraint
    Figure 14.5 NamedElement (again not composition but not every NamedElement should be the signature of a Message)
    Figure 14.7 ValueSpecification

    Figure 15.2 Trigger (there is only one mandatory composition but it makes the optional composition useless since the latter could never be set)

    Figure 17.16 ParameterableElement (not a composition but each ParameterableElement will not be the default of a TemplateParameter)

    Proposed Resolution: mark all the above association ends as 0..1 and update the metamodel accordingly

  • Reported: UML 2.0 — Mon, 31 Jul 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

11.3.47 on StructuralFeatureAction (and related sections on subclasses)

  • Key: UML22-263
  • Legacy Issue Number: 10045
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    Consider a link object that is an instance of an association
    > class that owns its ends. In this case, according to the
    > metamodel, it is the association class that is the
    > featuring classifier of the end properties (owningAssociation
    > subsets featuringClassifier). The properties of the object
    > input pin of a StructuralFeatureAction are determined by the
    > featuring classifier of the feature, which would imply that
    > the object being accessed in the case of an owned feature of
    > an association class is the link object that is the instance
    > of that association class.
    >
    > BUT, the semantics of StructuralFeatureAction say that "If
    > the structural feature is an association end, then actions on
    > the feature have the same semantics as actions on the links
    > that have the feature as an end. See specializations of
    > StructuralFeatureAction" – which is consistent with your
    > claims. This is an inconsistency in the spec. For the
    > semantics to work correctly, the syntactic constraints (on
    > typing of the object, visibility,
    > etc.) would have to be adjusted for the case of an
    > association end owned by an association class.

  • Reported: UML 2.0 — Tue, 25 Jul 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    (Note that the StructuralFeatureAction subclause is numbered 11.3.48 in Version 2.2.)
    The issue summary states that "the properties of the object input pin of a StructuralFeatureAction are determined by the featuring classifier of the feature." However, the specification does not actually formally require this. Rather, Subclause 11.3.48 includes instead the following constraint:
    [2] The type of the object input pin is the same as the classifier of the object passed on this pin.
    This statement is actually tautological if the normal typing rules are enforced, and does not place any constraint on the relationship of the type of the object input pin and the featuring classifier of the feature.
    The intent really is that a StructuralFeatureAction for a structural feature that is an association end have the same semantics as for the appropriate link action. The ownership of the association end should not matter. For example, this allows a ReadStructuralFeatureAction to be used to read the navigable opposite end of a binary association, whether that end is owned by the opposite end type or owned by the association itself (in which case the ReadStructuralFeatureAction acts like a ReadLinkAction). This way, the action does not have to be changed just because the model may be updated to change the end ownership - the ability to read the end depends only on its navigability.
    If this is clarified and formalized in the specification, then the above issue becomes moot.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 9.16.1

  • Key: UML22-262
  • Legacy Issue Number: 10007
  • Status: closed  
  • Source: ISP ( Leonid Dvoryansky)
  • Summary:

    Double declaration: RedefinableElement::isRedefinitionContexValid(redefinable: RedefinableElement): Boolean; RedefinableElement::isRedefinitionContextValid (redefined:RedefinableElement):Boolean; isRedifinitionContextValid = redefinitionContext->exists(c | c.allparents()-> includes (redefined.redefinitionContext)) ) Is the "isRedefinitionContexValid" declaration redundant?

  • Reported: UML 2.0 — Fri, 28 Jul 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Appears to have already been fixed. See Additional Operation [2] in section 7.3.46. Editorial note: However the fix has not been applied to Infrastructure.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 9.19.1

  • Key: UML22-261
  • Legacy Issue Number: 10006
  • Status: closed  
  • Source: ISP ( Leonid Dvoryansky)
  • Summary:

    Wrong definition of hasVisibilityOf() Classifier::hasVisibilityOf(n: NamedElement) : Boolean; pre: self.allParents()>collect(c | c.member)>includes ... if (self.inheritedMember->includes ) then hasVisibilityOf = (n.visibility <> #private) else hasVisibilityOf = true ... should be: if (not self.inheritedMember->includes ) then hasVisibilityOf = (n.visibility <> #private) else hasVisibilityOf = true

  • Reported: UML 2.0 — Fri, 28 Jul 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    There is more wrong than suggested in the issue. If you work through the logic of hasVisbilityOf, you end up with a tautology as demonstrated by Ed with the following argument:
    To determine if a.hasVisibilityOf is true, assuming n is private, we need to be able to deduce that (including the proposed change)
    if (not a.inheritedMember->includes) then false else true
    is true, under the constraint that
    a.inheritedMember->includesAll(a.inherit(a.parents()->collect(p | p.inheritableMembers(a)))
    where
    p.inheritableMembers(a) = p.member->select(m | a.hasVisibilityOf(m))
    Clearly, given the above constraint, not a.inheritedMember->includes is true if
    not (a.inherit(a.parents()>collect(p | p.member>select(m | a.hasVisibilityOf(m)))->includes)
    This, in turn, is equivalent to
    not (a.parents().member->includes and a.hasVisibilityOf and a.inherit)
    The conclusion so far is, therefore, that a.hasVisibilityOf is true if the above expression is false, that is, if
    a.parents().member->includes and a.hasVisibilityOf and a.inherit implies a.hasVisibilityOf
    Now, if either a.parents().member->includes or a.inherit are false, then the antecedent in the above implication is false, which means that a.hasVisibilityOf must be false. On the other hand, if both a.parents().member->includes and a.inherit are true, then the implication reduces to the tautology
    a.hasVisibilityOf implies a.hasVisibilityOf
    which is true whether or not a.hasVisibilityOf is true.
    However, it is not apparent why if (not a.inheritedMember->includes) is needed at all. If we simply define hasVisibilityOf as n.visibility <> private, i.e. members are visible in a child if they are not private, we remove the tautology and simplify the logic.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 9.12.1

  • Key: UML22-258
  • Legacy Issue Number: 10003
  • Status: closed  
  • Source: ISP ( Leonid Dvoryansky)
  • Summary:

    In UML Infrastructure version 2.0 formal/05-07-05 p.67 I've found that nonterminal <upper> has the alternative '', but <unlimited_natural> nonterminal range already contains '' as a possible deducible terminal sequence. <multiplicity> ::= <multiplicity-range> <multiplicity-range> ::= [ <lower> ‘..’ ] <upper> <lower> ::= <integer> <upper> ::= ‘*’ | <unlimited_natural>

  • Reported: UML 2.0 — Thu, 27 Jul 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Merged Metam.:Property::class with redefinition of non-inherited property

  • Key: UML22-257
  • Legacy Issue Number: 10001
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    Merged metamodel has Property::class with redefinition of a non-inherited property
    ----------------------------------------------------------------------------------------------------------------------

    In UML 2.1 we have the following:
    Kernel defines Class which inherits from Classifier, and has Class::ownedAttribute of type Kernel::Property.

    Composite Structures also defines Class which inherits from EncapsulatedClassifier which inherits from StructuredClassifier which inherits from Kernel::Classifier (curiously not Collaborations::Classifier in the same section).
    Now StructuredClassifier also defines property StructuredClassifier::ownedAttribute of type InternalStructures::Property

    So in the Merge, we have:
    L3::Class with property L3::Class::ownedAttribute of type L3::Property
    this will inherit from:
    L3::Classifier and L3::EncapsulatedClassifier, with the latter inheriting from L3::StructuredClassifier.
    And L3::StructuredClassifier will continue to have a property L3::StructuredClassifier::ownedAttribute.
    This would be inherited by L3::Class which has its own ownedAttribute.

    Hence there must be a redefinition L3::Class::ownedAttribute redefines L3::StructuredClassifier::ownedAttribute (there is).
    Likewise there must also be a generalization between the 2 associations (there is).

    However there is a change of the property ownership: at the subclass Property::class is owned by Property, and L3::A_ownedAttribute_structuredClassifier::structuredClassifier is owned by the Association.
    And there is no redefinition (or subsetting) between the two.

    Note that Figure 9.2 of ptc/06-04-02 does show a redefinition - but of "_structuredClassifier" with an underscore (not sure what that is supposed to mean).

    Proposed resolution:

    The Property::class property should be owned by the association (but still be navigable), and a redefinition needs to be added in section 9.3.12

    {redefines structuredClassifier}

    .

    Add Property::classifier as a derived union and have all opposites of ?::ownedAttribute subset it.
    This way, access to a property's (owning) classifier can be obtained uniformly - note that a number of the OCL expressions are currently written (incorrectly) with this assumption.

  • Reported: UML 2.0 — Wed, 26 Jul 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Invalid redefinitions introduced into metamodel

  • Key: UML22-265
  • Legacy Issue Number: 10079
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    There seem to be cases where redefinitions have appeared in the metamodel that were not in the spec. I think something is needed but overall I think subsetting is probably more appropriate for these cases.

    It appears that these redefinitions between non-navigable properties (owned by associations) may have been inadvertently introduced by the tool processing the metamodel before the ends were assigned names. In the first example I suspect that the opposites of DirectedRelationship::target and Generalization::general were detected as being involved in an implicit redefinition because their names were empty (the same). The tool can probably be tweaked to produce a complete list of such redefinitions which we can then itemize and remove to resolve this issue..

    The cause of the second example is the same, but was likely introduced before Package::ownedMember was renamed to Package::packagedElement and never cleaned up.

    For example, in Fig 7.9, the Classifiers diagram, the end opposite to Generalization::general is completely unlabeled. But in the metamodel we have
    <ownedEnd xmi:type="cmof:Property" xmi:id="A_general_generalization-generalization" name="generalization" type="Generalization" association="A_general_generalization" redefinedProperty="A_target_directedRelationship-directedRelationship"/>

    I'm not sure I see the need for a redefinition here - especially when its sibling (Classifier-generalization) is as follows and has no such redefinition:

    <ownedAttribute xmi:type="cmof:Property" xmi:id="Classifier-generalization" name="generalization" lower="0" upper="*" type="Generalization" association="A_generalization_specific" subsettedProperty="Element-ownedElement" isComposite="true">

    This has no reference at all to the general Association A_source_directedRelationship - to be consistent I would have expected redefinedProperty="A_source_directedRelationship-directedRelationship. As I mentioned at the start though a subsets seems more appropriate - since the other ends use

    {subsets source}

    etc.

    One that has an additional problem is the following:

    <ownedMember xmi:type="cmof:Association" xmi:id="A_ownedStereotype_profile" name="A_ownedStereotype_profile" general="A_packagedElement_owningPackage" memberEnd="Profile-ownedStereotype A_ownedStereotype_profile-profile">
    <ownedEnd xmi:type="cmof:Property" xmi:id="A_ownedStereotype_profile-profile" name="profile" type="Profile" association="A_ownedStereotype_profile" redefinedProperty="A_member_namespace-namespace"/>

    Here the Association inherits from A_packagedElement_owningPackage but the End redefines A_member_namespace-namespace which is not even a direct member of the specialized Association - and furthermore is a derivedUnion - so we have no real Slot to base the end on. If anything I would have expected a redefine of A_packagedElement_owningPackage-owningPackage

  • Reported: UML 2.1 — Wed, 2 Aug 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 13.2

  • Key: UML22-267
  • Legacy Issue Number: 10081
  • Status: closed  
  • Source: International Business Machines ( Mr. Adam Neal)
  • Summary:

    The body property of OpaqueBehavior (as well as OpaqueExpression and OpaqueAction) should be declared not unique. The OpaqueBehavior can be used to store user code and the given language that it was written in. The specifiction identifies the lists of languages and bodies to be ordered (and by default unique). It makes sense for the list of languages to be uniuqe, but not the bodies. For example, consider the user has written the same code but in 2 different languages (say c and c+, or written an identical comment in c and c+ and java). Currently the UML specification disallows one to have the same body even though it may semantically make sense in both languages

  • Reported: UML 2.1.1 — Wed, 2 Aug 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Agreed. In addition, the body and language attributes should be ordered

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.5

  • Key: UML22-266
  • Legacy Issue Number: 10080
  • Status: closed  
  • Source: ISP ( Leonid)
  • Summary:

    The grammar below is wrong, because there is no rule for the non-terminal <prop-property>. <prop-modifier> should be used instead. <property> ::= [<visibility>] [‘/’] <name> [‘:’ <prop-type>] [‘[‘ <multiplicity> ‘]’] [‘=’ <default>] [‘

    {‘ <prop-property > [‘,’ <prop-property >]* ’}

    ’]

  • Reported: UML 2.1 — Wed, 2 Aug 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

navigating from link to link ends

  • Key: UML22-256
  • Legacy Issue Number: 9961
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    It is not possible to navigate from link to connected instances if slots are not created or Association is not assigned as type.
    Is it possible to create slots in instance of Association even if properties are owned in connected Classes? Are they required? Are they for navigating?

  • Reported: UML 2.0 — Tue, 25 Jul 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    An InstanceSpecification can have slots for a Classifier corresponding to any of the members that are StructuralFeatures.
    This is deducable from the OCL but not at all clear in the text.
    See also the resolution to 18177 which allows slots to be created for private members and clarifies further
    which features are slottable.
    This also resolves 12912.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ExtensionEnd description refers to old use of navigability

  • Key: UML22-255
  • Legacy Issue Number: 9891
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    18.3.3 second paragraph of description uses the old definition of navigability as implying property ownership

  • Reported: UML 2.0 — Thu, 6 Jul 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 9.10.3

  • Key: UML22-260
  • Legacy Issue Number: 10005
  • Status: closed  
  • Source: ISP ( Leonid Dvoryansky)
  • Summary:

    Wrong definition of value association: value : InstanceSpecification [*] should be: value : ValueSpecification [*]

  • Reported: UML 2.0 — Fri, 28 Jul 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    This appears to have been fixedin Superstructure, The text “value: InstanceSpecification” does not appear in the specification. The property value is typed by ValueSpecification in Superstructure.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 9.13

  • Key: UML22-259
  • Legacy Issue Number: 10004
  • Status: closed  
  • Source: ISP ( Leonid Dvoryansky)
  • Summary:

    MultiplicityElement is derived from itself

  • Reported: UML 2.0 — Thu, 27 Jul 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 7.3.3

  • Key: UML22-270
  • Legacy Issue Number: 10140
  • Status: closed  
  • Source: Thought, Systems Consulting & Engineering, Inc. ( Marc W George)
  • Summary:

    Use of only the link name as the default for the association name limits the use of both namespace::membersAreDistinguishable() and nameElement::isDistinguishableFrom() operations. The full association name for creating the signature of the element should be at least the concatenation of "memberEndA name - link name - memberEndB name".

  • Reported: UML 2.1.1 — Thu, 24 Aug 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Figure 7.31

  • Key: UML22-269
  • Legacy Issue Number: 10087
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    Figure 7.31 shows the association-like notation for attributes. However this still sues the navigability arrow in the 'old' way. It would be consistent to use the new 'dot' notation to show the class owning the property representing the attribute.

  • Reported: UML 2.1 — Mon, 7 Aug 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Annex C.1

  • Key: UML22-268
  • Legacy Issue Number: 10086
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Language unit for stereotype create should be named Classes::Dependencies instead of just Dependencies

  • Reported: UML 2.1.1 — Fri, 4 Aug 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

StructuredActivityNode [UML 2.1.1]

  • Key: UML22-355
  • Legacy Issue Number: 11646
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    StructuredActivityNode, based on both common sense and its semantics, requires input and output pins. However StructuredActivityNode::input and StructuredActivityNode::output, both inherited from Action are derived unions and so cannot be used directly. StructuredActivityNode::result is a concrete property but has a special meaning.

    What is needed is some solution that subsets StructuredActivityNode::input and StructuredActivityNode::output but can be used to describe input and output pins of StructuredActivityNode.

  • Reported: UML 2.1.2 — Thu, 8 Nov 2007 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    The semantics of StructuredActivityNode does, indeed, talk specifically about pins on such nodes. Further, having pins on StructuredActivityNodes is assumed as being allowed in and is required by the Java to UML activity model mapping in the Foundational UML specification. The submitter is correct, however, that the abstract syntax model itself does not seem to explicitly support this.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML2 Issue - 'abstract' not listed in keyword Annex

  • Key: UML22-357
  • Legacy Issue Number: 11683
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    I just noticed that in formal/07-02-05 section 7.3.8, Classifier, includes:

    An abstract Classifier can be shown using the keyword

    {abstract}

    after or below the name of the Classifier.

    However this is not listed in Annex B of keywords.

  • Reported: UML 2.1.2 — Wed, 21 Nov 2007 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Merged with 18454

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML2 issue: ProfileApplication treated as Import

  • Key: UML22-356
  • Legacy Issue Number: 11657
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    Section 13.1.6, figure 13.11 (of Infra) and 18.2.7, figure 18.11 (of Super) show an example of a profile containing Types which are available for use when the profile is applied. This rests on the statement “(since profile application is a kind of import)”. However this is not the case: ProfileApplication only inherits from DirectedRelationship.

    To achieve the end effect of the example there seem to be two alternatives:

    a) Alter the metamodel to make ProfileApplication inherit from PackageImport, with appropriate redefinitions.

    b) Explicitly state that ProfileApplication has exactly the same semantics as PackageImport without inheriting from it. More awkward but lower impact. And will mean that generic processing that works off Imports will not pick up ProfileApplications.

    This area is causing significant consternation for groups such as UPDM trying to define sophisticated profiles that make use of common elements or other profiles.

  • Reported: UML 2.1.2 — Tue, 20 Nov 2007 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    ProfileApplication makes stereotype names visible to the referenced metamodel, not the model the profile is applied to. ProfileApplication is not a kind of PackageImport because of this crossing of metamodel levels. As with package import, profile application does not expose the names of nested profiles. Therefore alternative b) is the appropriate choice.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

context of Constraint

  • Key: UML22-348
  • Legacy Issue Number: 11407
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    Context of the Constraint is described as derived property

    • / context: Namespace [0..1] Specifies the Namespace that is the context for evaluating this constraint. Subsets NamedElement::namespace.

    However it is not derived in Figure 7.7 - Constraints diagram of the Kernel package.

    So should it be derived or not? One of these places shall be fixed.

  • Reported: UML 2.1.1 — Fri, 14 Sep 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    See issue 10830 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 18.3.6 Profile (from Profiles)

  • Key: UML22-347
  • Legacy Issue Number: 11343
  • Status: closed  
  • Source: Mid GmbH ( Joachim Back)
  • Summary:

    In the first serialization example, the memberEnd refers to property 'id4' and 'id5'. This would lead to 2 inconsistencies: 1. the 'id7' is in ownedEnd, but not in memberEnd. This contradicts the subset defined in chapter 7.3.3. 2. there are two candidates for the derived 'metaclass' attribute of 'Extension': id4.type and id5.type. This contradicts the definition in chapter 18.3.2. Instead it should refer to id7 and id5. The correct XMI file excerpt looks like that: <ownedMember xmi:type="uml:Extension" xmi:id="id6" name="A_Interface_Home" memberEnd="id7 id5"> <ownedEnd xmi:type="uml:ExtensionEnd" xmi:id="id7" name="extension_Home" type="id3" isComposite="true" lower="0" upper="1"> </ownedEnd> </ownedMember>

  • Reported: UML 2.1.1 — Wed, 12 Sep 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 7.3.33

  • Key: UML22-354
  • Legacy Issue Number: 11630
  • Status: closed  
  • Source: Volvo Technology Corporation ( Hans Blom)
  • Summary:

    Figure 7.15 - Contents of Dependencies package There is a rolename supplierDependency that it not defined in §7.3.33 for NamedElement.

  • Reported: UML 2.1.1 — Tue, 23 Oct 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    supplierDependency is a non-navigable end and, therefore, cannot be owned by NamedElement. Per the usual style in the UML specification document, non-owned ends are not listed in the documentation for a class.
    Revised Text:
    None.
    Disposition: Closed No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

In section 7.3.12 Figure 7.38

  • Key: UML22-353
  • Legacy Issue Number: 11489
  • Status: closed  
  • Source: Anonymous
  • Summary:

    As described above the Figure 7.38 I think the arrow should point from Car to CarFactory.

  • Reported: UML 2.1.1 — Wed, 19 Sep 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    In the UML 2.5 specification, the corresponding figure is 7.19 in subclause 7.7.5. The direction of the
    dependency in the diagram is correct: the CarFactory instantiates Cars and so depends on the Car class, but
    the Car class does not need to depend on CarFactory specifically instantiating it.
    However, the text above the diagram says “the Car Class has a Dependency on the CarFactory Class”, which
    is incorrect.
    This also resolves duplicate issues 12405, 13136, 13947 and 17804.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Incorrect word renders sentence meaningless: Chap. 12.3.41

  • Key: UML22-351
  • Legacy Issue Number: 11414
  • Status: closed  
  • Source: Kratzer Automation AG ( Tom Riedl)
  • Summary:

    Incorrect word renders sentence meaningless: Chap. 12.3.41, "Parameter (from CompleteActivities)" Section "Semantics", 1st paragraph, Beginning of last sentence: Suggestion: Replace: "Arrange for separate executions of the activity to use separate executions of the activity..." by: "Arrange for separate invocations of the activity to use separate executions of the activity..."

  • Reported: UML 2.1.1 — Mon, 17 Sep 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

The section titled "Changes from previous UML" is not complete

  • Key: UML22-350
  • Legacy Issue Number: 11413
  • Status: closed  
  • Source: n/a ( Brian Arbuckle)
  • Summary:

    The section titled "Changes from previous UML" is not complete "The following changes from UML 1.x have been made: to be written."

  • Reported: UML 2.1.1 — Mon, 17 Sep 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • 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:58 GMT

first constraint for CombinedFragment

  • Key: UML22-346
  • Legacy Issue Number: 11286
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    The first constraint for CombinedFragment:

    [1] If the interactionOperator is opt, loop, break, or neg, there must be exactly one operand.” ..

    should also include the assert operator.

  • Reported: UML 2.1.1 — Tue, 21 Aug 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.1 AcceptEventAction

  • Key: UML22-345
  • Legacy Issue Number: 11268
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Figures 12.25-27 show examples of the AcceptEventAction. The actions have an outpin pin which can be omitted in the diagram. But the target actions should show the input pins, e.g. action "Cancel order" needs an input pin "Cancel order request".

  • Reported: UML 2.1.1 — Fri, 10 Aug 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    The referenced diagrams are correct as drawn when the edges are interpreted as control flows rather than data flows.
    Revised Text:
    None
    Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

RedefinableTemplateSignature

  • Key: UML22-344
  • Legacy Issue Number: 11244
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    RedefinableTemplateSignature::classifier owns this template signature, so it shall redefine inherited TemplateSignature::template, because it is used for the same purpose and subsets Element::owner.

  • Reported: UML 2.1.1 — Tue, 7 Aug 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ElementImport

  • Key: UML22-352
  • Legacy Issue Number: 11488
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    Element is restricted to be imported only once (not possible to import the same element into different namespaces).
    I think this is clear bug in Figure 7.4 - Namespaces diagram of the Kernel package
    ElementImport multiplicity (on association between ElementImport and PackageableElement) shall be changed from [1] to [*] (as multiplicity of PackageImport).

  • Reported: UML 2.1.1 — Wed, 19 Sep 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • 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:58 GMT

UML 2.1.1 - fig 7.14

  • Key: UML22-349
  • Legacy Issue Number: 11408
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    This seems odd to me. The ‘owningPackage’ role of PackageableElement is non-navigable, whereas I would expect it to be navigable so that it is possible from a Packageable Element to find its owner. Interestingly Type, which is a PackageableElement does have a navigable role to its parent, but InstanceSpecification, for example doesn’t.

  • Reported: UML 2.1.1 — Fri, 14 Sep 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 7

  • Key: UML22-287
  • Legacy Issue Number: 10515
  • Status: closed  
  • Source: Paranor AG ( Earl Waldin)
  • Summary:

    The property isLeaf as inherited by Class from RedefinableElement deals with the concept of redefinition in the context of a classifier. The concept of "this class cannot be subclassed" is missing from UML 2.0 and the current version of UML 2.1. In UML 1.4, the isLeaf property is present in two contexts: Operation and GeneralizableElement. The former refers to the concept of redefinition while the later refers to the concept of subclassing. In UML 2.1, isLeaf from RedefinableElement corresponds to the former. There is nothing corressponding to the later. It is clear from the UML 2.1 specification that redefinition of Classes is related to nesting. In the association class->nestedClassifier between Class and Classifier in Figure 7.12, the source end subsets redefinitionContext. The current constraints for RedefinableElement, Classifier and Class give the following interpretation. Let A be a class with nested class A1, B a class with nested class B1, and B be a subclass of A. Then B1 can redefine A1 as long as A1 has isLeaf = false and A1's visibility is not private. B1 can subclass A1 regardless of the the value of isLeaf on A1. In short, subclassing and redefinition are two separate, orthogonal concepts. The concept of isLeaf for subclassing is not present in UML 2.1.

  • Reported: UML 2.1.1 — Tue, 19 Dec 2006 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    In UML 1.5, isLeaf is used in 3 contexts, not two:
    UML 1.5's Operation::isLeaf and Reception::isLeaf in UML 2 correspond to the concept of a redefinable element that cannot be further redefined.
    UML 1.5's GeneralizableElement::isLeaf in UML 2 corresponds to the concept of a classifier that cannot be further specialized in a generalization hierarchy. There are several options to add this capability in UML 2 and the two that are least disruptive to the UML 2 specification are:
    a) Rename RedefinableElement::isLeaf to RedefinableElement::isFinal
    Add Classifier::isLeaf
    b) Keep RedefinableElement::isLeaf
    Add Classifier::isFinal
    c) Keep RedefinableElement::isLeaf
    Add Classifier::isFinalSpecialization
    Option (a) would break compatibility with UML 2.2 in a really bad way because the original meaning of "isLeaf" is now "isFinal" and there is a completely different meaning assigned to "isLeaf".
    Option (b) preserves the UML 2 meaning of "isLeaf" but adds support for the UML 1.x notion of a classifier that cannot be specialized in a generalization hierarchy. However, option (b) creates possible confusion for end users in distinguishing the purpose of isLeaf vs. isFinal.
    Option (c) provides the same advantages as option (b) in addition to providing end users a clue about the role of isLeaf vs. isFinalSpecialization.
    Since option (b,c) represent an upwardly compatible change w.r.t. UML2.2, it is preferred to option (a) which would not only break compatibility with UML 2.2 but also create a lot of confusion in comparing UML 2.2 vs. UML 2.3 models. The rest of this resolution follows option (c).
    Add a property 'isFinalSpecialization' to a Classifier which is the basis for expressing taxonomic relationships among general and specific classifiers.
    Specify a package merge transformation for merging Classifier::isFinalSpecialization according to the principle that a resulting classifier is final if either matching classifier is final.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 15

  • Key: UML22-286
  • Legacy Issue Number: 10512
  • Status: closed  
  • Source: fht-esslingen.de ( Dirk)
  • Summary:

    state machines: --------------- I can find a BNF for an behavioral transition but not for a protocol transition. Theres is no explanation why a protocol transition needs the "/" following the trigger. What for is the "/" ? The figure 15.15 on page 521 just shows a protocol trigger but there is no explanation. Wouldn't it be sufficient to write: [pre condition] trigger [post condition] Because of this everyone uses different notations...

  • Reported: UML 2.1 — Fri, 15 Dec 2006 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 15

  • Key: UML22-285
  • Legacy Issue Number: 10498
  • Status: closed  
  • Source: Université de Mons-Hainaut ( Alessandro Folli)
  • Summary:

    The subject of my thesis is "UML MODEL REFACTORING USING GRAPH TRANSFORMATION" and I'm trying to represent UML models using graphs. I have read the "UML 2.0 Superstructure Specification" document and I can't exactly understand which is the region the transitions belong to. On page 553 it defines the container association as "Designates the region that owns this transition.". On page 529 it defines the transition association as "The set of transitions owned by the region. Note that internal transitions are owned by a region, but applies to the source state." I have taken a look to the previous UML specification version. Regions were not present and it defined the relationship between StateMachine and Transition as "Associates the StateMachine with its Transitions. Note that internal Transitions are owned by the State and not by the StateMachine. All other Transitions which are essentially relationships between States are owned by the StateMachine. Multiplicity is '0..*'. " Is it correct if I suppose that all the transitions, excluded internal transitions, are contained by the top-level region? Thank you.

  • Reported: UML 2.0 — Thu, 30 Nov 2006 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    The owner of a transition does not imply any semantics; therefore a specific owner will not be defined. It is suggested that the LCA of the source and target is used, but it can really be any region that is directly or indirectly owned by the state machine context.
    This resolution also affects the constraint on internal transitions sourcing a composite state. Because the internal transition can be owned by any region (and not necessarily a region that belongs to the source state) the restriction that a state must be composite to have internal transitions is unnecessary. Therefore this needs to be corrected as well.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2.1 Spec, Interactions: 14.3.18

  • Key: UML22-295
  • Legacy Issue Number: 10591
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    I don’t understand why the type of the property ‘InteractionUse.argument’ is Action; I think that there at least needs to be some explanation.

    Also, looking at the syntax for ‘InteractionUse’ in the Notation section:

    “<name> ::=[<attribute-name> ‘=’ ] [<collaboration-use> ‘.’] <interaction-name> [‘(‘ <io-argument> [‘,’ <io-oargument>]* ‘)’] [‘:’ <return-value> <io-argument> ::= <in-argument> | ‘out’ <out-argument>]

    The <attribute-name> refers to an attribute of one of the lifelines in the Interaction.”

    How does the reference to the attribute get stored in the model?

    Finally in Fig 14.18, I don’t see how the notation for the described InteractionUse can be produced from the syntax above, particularly the first part: “:xx.xc=”

  • Reported: UML 2.1 — Fri, 12 Jan 2007 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Arguments of InteractionUse shall be ValueSpecifications, as arguments of Message.
    Furthermore introduce a couple of extra attributes/associations to cover the information not easily found today.
    Finally fix the BNF of the concrete textual syntax by a concluding „]?

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2.1 Spec, Interactions: 14.3.18 - InteractionUse

  • Key: UML22-294
  • Legacy Issue Number: 10590
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    One of the constraints for this element is:

    [2] The InteractionUse must cover all Lifelines of the enclosing Interaction that appear within the referred Interaction.”

    This needs to be rephrased I think – I don’t see how Lifelines can “appear” in more than one Interaction.

  • Reported: UML 2.1 — Fri, 12 Jan 2007 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

A_outgoing_source and A_incoming_target should not be bidirectional

  • Key: UML22-293
  • Legacy Issue Number: 10537
  • Status: closed  
  • Source: Eclipse Foundation ( Mr. Kenneth Hussey)
  • Summary:

    The A_outgoing_source and A_incoming_target associations between Vertex and Transition should not be bidirectional - it's unreasonable to expect that a vertex be changed in order to create a transition to another vertex, considering that the vertices could be in a different model from the transition (especially in the context of state machine refinement). Note that since pseudostates are not redefinable, there is currently no way to redefine a transition that has a pseudostate as its source/target. There should perhaps be separate, derived Vertex::outgoing and Vertex::incoming properties instead.

  • Reported: UML 2.1 — Thu, 21 Dec 2006 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Superstructure/Components/overly stringent constraints

  • Key: UML22-289
  • Legacy Issue Number: 10526
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The constraints defined for Connectors in the components chapter should be removed: they refer to "provided" and "required" ports (categories no longer supported in UML) but also force very stringent connection rules that get in the way of informal sketching type usage, since they require the explicit declartion of interfaces when doing structure modeling. These types of constraints should only be enforced through a profile.

  • Reported: UML 2.1 — Wed, 13 Dec 2006 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Resolution:
    Resolved by 7248-7251.

    Revised Text:
    None
    Disposition: Duplicate of 7248 - 7251

  • Updated: Fri, 6 Mar 2015 20:58 GMT

AcceptCallAction has not operation

  • Key: UML22-288
  • Legacy Issue Number: 10521
  • Status: closed  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    In UML2, AcceptCallAction isA AcceptEventAction --> trigger: Trigger --> event: CallEvent --> operation: Operation. In the notation, there's the accept call action in an activity which has a name, and an operation provided by the performer. In the metamodel, this would mean that a Trigger and Event would have to be created to connect an operation to an AcceptCallAction. This is overkill resulting in a complex metamodel and extra work for modelers to create Trigger and Event model elements that are not needed.

    AcceptCallAction should have an operation: Operation property directly. Then a <<trigger>> keyword should be used to indicate the operation is implemented with an AcceptCallAction rather than a method Behavior

  • Reported: UML 2.1 — Mon, 11 Dec 2006 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    The proposed change would, indeed, simplify the model, but it would be inconsistent with AcceptCallAction being, syntactically and semantically, a subclass of AcceptEventAction. AcceptCallAction is just a special case of triggering based on a call event, with some syntactic conveniences. Any complexity of the metamodel should be hidden by proper tool support.
    Revised Text:
    None.
    Disposition: Closed, no change.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 14.3.10

  • Key: UML22-291
  • Legacy Issue Number: 10530
  • Status: closed  
  • Source: Hitachi INS Sosftware ( Toru Arakaki)
  • Summary:

    Old name, "ExecutionOccurences", of "ExecutionSpecification" is still used in the document. Line 14 of the page 465: "ExecutionOccurences are represented ..." Line 22 of the page 465: "Overlapping execution occurrences on the same lifeline ..." Description of Figure 14.15 of the page 465: "Overlapping execution occurrences" Line 18 of the page 463: "An ExecutionEvent models the start or finish of an execution occurrence."

  • Reported: UML 2.0 — Tue, 19 Dec 2006 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 14.3.14

  • Key: UML22-290
  • Legacy Issue Number: 10529
  • Status: closed  
  • Source: Hitachi INS Software ( Toru Arakaki)
  • Summary:

    The Notation of the InteractionConstraint is incorrect. A character after "Boolean-expression" should be > not ’. AS-IS: <interactionconstraint> ::= [‘[‘ (<Boolean-expression’ | ‘else‘) ‘]’] TO-BE: <interactionconstraint> ::= [‘[‘ (<Boolean-expression> | ‘else‘) ‘]’]

  • Reported: UML 2.0 — Tue, 19 Dec 2006 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    See issue 9598 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML2: notation issue

  • Key: UML22-297
  • Legacy Issue Number: 10634
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Sebastien Gerard)
  • Summary:

    In the spec, some elements have a notation which contain a keyword put in quote like for Abstraction or for Interface. But this keywork does not match the stereotype notation.

    So if I applied a stereotype on such elemen, what is the right notation (see both following examples):

    EX1:

    Ex2:

  • Reported: UML 2.1 — Mon, 29 Jan 2007 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: e. g. 12.2. page 287

  • Key: UML22-296
  • Legacy Issue Number: 10594
  • Status: closed  
  • Source: Jens Kuttig - Computer und Medien ( Jens Kuttig)
  • Summary:

    Some elements are black outlined with a white background, some are red outlined with yellow background. Some edges are black, some are red, some are purple. What does the diffrent colors in the diagramms mean? I cannot find any explanation within the document.

  • Reported: UML 2.0 — Mon, 15 Jan 2007 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

A_end_role should not be bidirectional

  • Key: UML22-292
  • Legacy Issue Number: 10536
  • Status: closed  
  • Source: Eclipse Foundation ( Mr. Kenneth Hussey)
  • Summary:

    The A_end_role association between ConnectableElement and ConnectorEnd should not be bidirectional - it's unreasonable to expect that a connectable element be changed in order to connect it to another connectable element, considering that the connectable element(s) could be in a different model from the connector. There should perhaps be a separate, derived ConnectableElement::end property instead

  • Reported: UML 2.1 — Thu, 21 Dec 2006 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ReplyAction::replyValue type is incorrct

  • Key: UML22-298
  • Legacy Issue Number: 10636
  • Status: closed  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    Section 11.3.43 shows the replyValue attribute of ReplyAction is of type OutputPin. It is shown as InputPin in figure 11.12. The type should be InputPin in section 11.3.43

  • Reported: UML 2.1 — Tue, 30 Jan 2007 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Resolution:
    This was editorially corrected in UML 2.1.
    Revised Text:
    None.
    Disposition: Closed, no change.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

assembly connectors

  • Key: UML22-201
  • Legacy Issue Number: 9578
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    Chapter 8.3.2
    An assembly connector is a connector between two components that defines

    that one component provides the services that another component
    requires. An
    assembly connector is a connector that is defined from a required
    interface
    or port to a provided interface or port.

    All constraints are using terms "connector between Interface and Port"
    also.
    I suggest to change or remove this misleading text.

    Agreed. This text is highly misleading in a number of ways:

    (1) It suggests that connectors connect components. They actually connect
    parts typed by components.

    (2) It suggests that connectors connect interfaces – which they do not
    (because only connectable elements can be connected and interfaces are not
    connectable elements).

  • Reported: UML 2.0 — Thu, 20 Apr 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    This complaint is handled by other resolutions, primarily 8900 and 9464.

    Revised Text:
    None.
    Disposition: Duplicate of 8900 and 9464.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

New Issue on multiple guillemot pairs for same element

  • Key: UML22-200
  • Legacy Issue Number: 9577
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Section 18.3.8 has the following paragraph:

    Presentation Options If multiple stereotypes are applied to an element,
    it is possible to show this by enclosing each stereotype name within a
    pair of
    guillemets and listing them after each other. A tool can choose whether it
    will
    display stereotypes or not. In particular, some tools can choose not to
    display
    “required stereotypes,” but to display only their attributes (tagged
    values) if
    any.

    Annex B has the following paragraph:

    If multiple keywords and/or stereotype names apply to the same model element,
    they all appear between the same pair of guillemets, separated by commas:
    “«” <label> [“,” <label>]* “»”

    These two paragraphs seem to contradict each other, since the annex B does
    not
    allow multiple guillemet pairs for the same element, while 18.3.8 does.

    Proposed Solution:
    Add clarification that Both presentation options should be allowed.

  • Reported: UML 2.0 — Wed, 19 Apr 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

11.3.26 OpaqueAction

  • Key: UML22-210
  • Legacy Issue Number: 9710
  • Status: closed  
  • Source: IBM ( Brent Nicolle)
  • Summary:

    11.3.26 OpaqueAction states it has a Generalization: "Pin (from BasicActions) on page 256." This doesn't make sense; pins and actions are very different things. I think figure 11.2 shows the intended Generalization: "Action (from BasicActions) on page 230."

  • Reported: UML 2.0 — Fri, 12 May 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    This was editorially resolved in UML 2.2.
    Revised Text:
    None.
    Disposition: Closed, no change.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Definition of stereotype placement requires a name

  • Key: UML22-209
  • Legacy Issue Number: 9706
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    Section 18.3.8, Notation states: "When a stereotype is applied to a model element (an instance of a stereotype is linked to an instance of a metaclass), the name of the stereotype is shown within a pair of guillemets above or before the name of the model element."
    This is too specific and does not state how to notate an element which is unnamed (which could be addressed by referring to where the name would be) or has no name property defined: for example Comment (here a more creative approach is needed).

  • Reported: UML 2.0 — Thu, 4 May 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

the default for a Property should not be inconsistent with its type

  • Key: UML22-206
  • Legacy Issue Number: 9622
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    There should be a constraint on Property that the ValueSpecification used for its default should not conflict with its type.
    In some cases, for example if an OpaqueExpression is used, then the type of the value cannot be determined. However if it can then it should not be inconsistent.
    This would, for example require the default for a Integer-typed Property to be an instance of LiteralInteger and not LiteralString or any other LiteralX.

  • Reported: UML 2.0 — Tue, 2 May 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    resolved

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 7.3.10

  • Key: UML22-205
  • Legacy Issue Number: 9617
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The description of Constraint mentions the xor-association that is predefined in UML. There's no place in the superstructure (and infrastructure) where that constraint is defined.

  • Reported: UML 2.1.1 — Tue, 2 May 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Figure 7.34 shows an

    {xor}

    constraint attached to two associations, indicating an Account can be a property of Person or Corporation, but not at the same time. Section 7.3.10 Constraint references “xor” constraint as an example of a UML predefined constraint.
    The xor constraint is not explicitly defined in UML. Rather it is used as an example of a constraint between associations as in figure 7.34, and as an example of an expression in section 7.3.18. So the parenthetical remark about xor being an example of a UML predefined constraint in section 7.3.10 should be removed.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

packagedElement

  • Key: UML22-204
  • Legacy Issue Number: 9605
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    In 06-01-02, I note that in Fig 7.14, packagedElement is not marked as derived but in section 7.3.37 it is – can you clarify which it is?

  • Reported: UML 2.0 — Mon, 24 Apr 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ptc/06-01-02:14.3.14, Notation

  • Key: UML22-203
  • Legacy Issue Number: 9598
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    The following notation expression isn’t well formed:

    <interactionconstraint> ::= [‘[‘ (<Boolean-expression’ | ‘else‘) ‘]’]

  • Reported: UML 2.0 — Mon, 24 Apr 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML's support for null values and semantics is unclear

  • Key: UML22-207
  • Legacy Issue Number: 9700
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    UML's support for null values and semantics is unclear.
    For example if a Property is defined [1..1] then is a value of null (represented by LiteralNull) permitted? (LiteralNull is defined as "LiteralNull is intended to be used to explicitly model the lack of a value.")
    Can null values be used to create a sparse array? If not how is a fixed length sparse array to be modeled?
    Can a unique multivalued property contain multiple nulls?
    How do the StructuralFeatureActions react in the presence of null?
    [Note that the issue is NOT related to the "null token"]

  • Reported: UML 2.0 — Thu, 4 May 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2/ Super / SendSignalEvent erratum

  • Key: UML22-211
  • Legacy Issue Number: 9718
  • Status: closed  
  • Source: Anonymous
  • Summary:

    A minor issue I stumbled over in UML Superstructure ptc/06-04-02.

    SendSignalEvent [14.3.28] specialises MessageEvent [13.3.18], which
    "specifies the RECEIPT ..." Perhaps that should be reworded?

  • Reported: UML 2.0 — Sat, 13 May 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Question on InfrastrucutreLibrary::BehavioralFeatures::Parameter

  • Key: UML22-199
  • Legacy Issue Number: 9556
  • Status: closed  
  • Source: Dell Technologies ( Mr. George Ericson)
  • Summary:

    In Infrastructures, since TypedElements::TypedElement is subclassed from Namespaces::NamedElement, is it necessary that BehavioralFeatures::Parameter be subclassed from both TypedElements::TypedElement and Namespaces::NamedElement?

  • Reported: UML 2.0 — Mon, 10 Apr 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

"Property::lowerValue" is not a good name

  • Key: UML22-208
  • Legacy Issue Number: 9704
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    It could easily be taken to mean a constraint on the value not the multiplicity, e.g. for an 'temperature' property, that its value is not allowed to be below -273. Would be better named "lowerBoundValue" or similar.

  • Reported: UML 2.0 — Thu, 4 May 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Fig 7.14

  • Key: UML22-202
  • Legacy Issue Number: 9597
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    In 06-01-02, I note that in Fig 7.14, packagedElement is not marked as derived but in section 7.3.37 it is – can you clarify which it is?

  • Reported: UML 2.0 — Mon, 24 Apr 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Table 8.2 must be named "Graphic paths..." instead of "Graphic nodes..."

  • Key: UML22-370
  • Legacy Issue Number: 12235
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Table 8.2 must be named "Graphic paths..." instead of "Graphic nodes..."

  • Reported: UML 2.1.1 — Tue, 19 Feb 2008 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • 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:58 GMT

Datatypes in UML profiles

  • Key: UML22-369
  • Legacy Issue Number: 12224
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Tomas Juknevicius)
  • Summary:

    The UML Superstructure section on profiling (18, 18.3) is vague about the datatype usage in profiles.
    In particular, it is not clear what (if any) datatypes can the user define and use in his profile as types of the tags.

    --------------------------------------------------------------------------------
    Datatypes used in profiles (e.g. as types of the tags) are not ordinary UML datatypes, but MOF datatypes (if I am not mistaken).
    Hence it is not obvious if all of the various datatype possibilities, defined in CMOF, can be used by a profile creator.

    It would be nice to have some clarifying statement in the Semantics section of the 18.3.6 Profile paragraph
    In the same manner as the possible associations between stereotypes is clarified there (page 663, at the bottom):

    Stereotypes can participate in 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. For these associations there must be a property owned by
    the Stereotype to navigate to the opposite class. The opposite property must be owned by the Association itself rather than
    the other class/metaclass
    (a little side note - I am not sure if this passage is correct - ?metalevel mixing? but this is irrelevant for the issue I am describing)

    --------------------------------------------------------------------------------
    I can think of the 4 distinct cases of datatypes that the modeler might use in his profile:

    #1 Enumerations
    #2 New primitive types, narrowing the existing primitive types - String, Integer, Boolean, UnlimitedNatural.
    e.g.

    #3 Completely new primitive types, e.g. Double
    #4 Complex datatypes, defined by the user, composed of fields of primitive types and other complex types.
    e.g.

    #1 and #2 are the least problematic. #1 is widely supported even in the current crop of modeling tools and
    #2 is conceptually simple (handling is the same as existing primitive types + additional constraints)

    What I am worried about is #3 and #4.
    #3 is problematic; the question arises about how the values of this type are then handled in the model and how they are
    serialized into the XMI.
    Maybe we could state here that if the tool allows the user to define his own primitive types, then the user is responsible for
    extending the tool (through some kind of plugin mechanism) - providing at least the rules of how to serialize such datatypes into the string,
    to be written into the XMI.

    #4 Is theoretically non problematic (supposedly, it is described how to serialize such complex datatype values - XMI 2.1.2 spec, 07-12-01.pdf, 4.8.7 paragraph).
    However I haven't seen live implementations of this. Is the usage of such datatypes in the profile legal?

    --------------------------------------------------------------------------------
    So, to summarize, we should clarify here, if all of these cases must be supported by the UML tool. Are there any
    semantic variation points or compliance levels here?

  • Reported: UML 2.1.2 — Thu, 14 Feb 2008 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

TemplateSignature / TemplateParameter / StructuredClassifier

  • Key: UML22-364
  • Legacy Issue Number: 12168
  • Status: closed  
  • Source: International Business Machines ( James Bruck)
  • Summary:

    Version 2.1.1 2007-02-05 of the spec.

    TemplateSignature p. 625
    parameter : TemplateParameter[] Should mention that it is a derived union of TemplateSignature::ownedParameter ( or show ‘/’ )

    ownedParameter: TemplateParameter[] Should mention that it subsets TemplateSignature::parameter.

    TemplateParameter p. 623

    default : ParameterableElement should mention that it is a derived union of TemplateParameter::ownedDefault ( or show ‘/’ )

    parameteredElement::ParameterableElement[] should mention it is a derived union of TemplateParameter::ownedParameteredElement

    StructuredClassifier p. 186

    There seems to be some discrepency in the spec in regards to Role : ConnectableElement[]. The spec mentions that it is a derived union (it uses the term Abstract union which is inconsistent ) that subsets Classifier::feature. I believe we should have StructuredClassifier::ownedAttribute subsetting StructuredClassifier::role.

  • Reported: UML 2.1.2 — Tue, 8 Jan 2008 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • 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:58 GMT

inability to specify ordering of messages connected to gates is problematic

  • Key: UML22-363
  • Legacy Issue Number: 12167
  • Status: closed  
  • Source: International Business Machines ( James Bruck)
  • Summary:

    In the 2.1.1 specification (070205):

    Gates are simply MessageEnds and not some form of OccurrenceSpecification. This makes relative ordering of messages between gates on different InteractionUse within an interaction impossible.
    In addition to gates on InteractionUse, gates on Interaction that have outgoing messages cannot specify any relative ordering.

    The inability to specify ordering of messages connected to gates is problematic.
    __________________________________

  • Reported: UML 2.1.2 — Tue, 8 Jan 2008 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Add clarification that Gates are messageEnds which are ordered by the occurrences at the opposite ends of
    the two messages linked by the gate. UML 2.5 already added several clarification on semantics of Gates.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

The semantics of an assembly connector remains unspecified

  • Key: UML22-372
  • Legacy Issue Number: 12241
  • Status: closed  
  • Source: AdaCore ( Matteo Bordin)
  • Summary:

    The semantics of an assembly connector remains unspecified: it is not possible to understand which port is the source and which port is the target of the data that are meant to "flow" at run-time on the assembly. The specification indeed refer to "required port" to express the semantics of a connector, but the concept of "required port" doesn't exist in UML. The real problem is the following: it is not possible to specify which interfaces provided/required by a port are involved in an assembly. A possible solution could be: - Have a port typed to an interface - Specify if the interface is provided or required using a tag (in a way similar for the direction of SysML FlowPort)

  • Reported: UML 2.1.2 — Wed, 20 Feb 2008 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    I am not sure that this is really a semantics question. If the semantics are in doubt, that is an issue about connectors in general. I believe this is actually the issue about the ball and socket notation, which is resolved by the changes specified in 8168 and 8900, by restricting the notation to parts with simple ports.

    Revised Text:
    None.

    Disposition: Duplicate of 8168 and 8900.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Table 8.2

  • Key: UML22-371
  • Legacy Issue Number: 12236
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Table 8.2 should contain graphic paths for - delegate connector - component realization

  • Reported: UML 2.1.1 — Tue, 19 Feb 2008 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Table 8.2 shows the assembly connector which is an element of a composite structure diagram. But table 8.2 denotes elements of a structure diagram. A table for composite structure diagram elements that are specific for components is missing.
    The heading of table 8.2 is incorrect. The table doesn't show nodes, but paths.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML2: Missing ActionOutputPin

  • Key: UML22-362
  • Legacy Issue Number: 12161
  • Status: closed  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    UML2 Activities support two different approaches for exchanging data between actions: "push semantics" of token passing over ObjectFlows and "pull semantics" of typical programming languages using ActionInputPins or ValuePin. The fromAction of an ActionInputPin could be a ValueExpression that references a Variable of the Activity or StructuralFeature of the context Classifier. However, support for pull semantics is incomplete. The first issues is 9247 where there is no ReadParameterAction or WriteParameterAction to support pull semantics for Activity Parameters. These Actions should be provided so that ActivityParameterNodes are only needed for ObjectFlows allowing the Activity Parameters to be directly referenced for pull semantics. This would also allow Parameters, Variables and StructuralFeatures to be all handled the same way.

  • Reported: UML 2.1.2 — Mon, 7 Jan 2008 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Despite the misleading title, this issue appears to be essentially a duplicate of issues 9247 and 8470. It looks like the text in this issue was just introductory to that of issue 12162, and was incorrectly made an issue of its own.
    Revised Text:
    None.
    Disposition: Duplicate

  • Updated: Fri, 6 Mar 2015 20:58 GMT

The spec needs to clarify the isConsistentWith() method for transitions

  • Key: UML22-361
  • Legacy Issue Number: 12158
  • Status: closed  
  • Source: International Business Machines ( James Bruck)
  • Summary:

    In the 2.1.1 specification (070203) states on page 583/732 (or pg.569), it states:
    [1] The query isConsistentWith() specifies that a redefining transition is consistent with a redefined transition provided that
    the redefining transition has the following relation to the redefined transition: A redefining transition redefines all
    properties of the corresponding redefined transition, except the source state and the trigger.

    This restriction seems a little harsh. Consider the use case:
    1) a user has a state machine, in a top level abstract class, and there exists a transition between two states with no triggers.
    2) the users expect to add triggers to the transition in the concrete sub class state machines. (i.e. redefine in the sub class context and add a trigger)

    The way the above constraint is written does not allow new triggers to be added to redefined transitions. I am requesting a clarification point that will state that new triggers can be added to the redefined transition.

  • Reported: UML 2.1.2 — Fri, 4 Jan 2008 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Merged with 6395

  • Updated: Fri, 6 Mar 2015 20:58 GMT

paragraph on "deferred events" on page 552

  • Key: UML22-367
  • Legacy Issue Number: 12204
  • Status: closed  
  • Source: Missouri University of Science and Technology ( Thomas Weigert)
  • Summary:

    Towards the bottom of the page there is a paragraph on "deferred events". This appears to be a holdover from UML 1.x, as the current specification speaks of "deferred triggers" (see p.550). Adjust this paragraph to match the current abstract syntax. Similar changes must be made to the corresponding paragraph on p.554.

  • Reported: UML 2.1.2 — Wed, 31 Dec 2008 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • 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:58 GMT

Section 14.3.19

  • Key: UML22-366
  • Legacy Issue Number: 12195
  • Status: closed  
  • Source: mit.bme.hu ( Zoltan Micskei)
  • Summary:

    In the description of Lifeline the coveredBy association has a multiplicity of [0..1]. However, in Figure 14.4 the multiplicity is *, in the XMI it has also * as upper bound, and the text talks also about multiple InteractionFragments ("References the InteractionFragments in which this Lifeline takes part").

  • Reported: UML 2.1.2 — Thu, 24 Jan 2008 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • 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:58 GMT

Figure 7.6

  • Key: UML22-360
  • Legacy Issue Number: 11828
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    Figure 7.6 should show properties body and language of OpaqueExpression as multivalued i.e. [0..*].

  • Reported: UML 2.1.2 — Mon, 17 Dec 2007 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12

  • Key: UML22-359
  • Legacy Issue Number: 11763
  • Status: closed  
  • Source: Student at Technische Universität Braunschweig ( Stefan Schulze)
  • Summary:

    The constraint [2] in section 12.3.5 on page 325 ("Activity edges may be owned only by activities or groups") of class ActivityEdge seems to be contrary to the fact that inGroup - the only reference between edge and group - is a simple association but no composition or aggregation. According to figures 12.5 and 12.6 I would think, that edges are always owned by activities (composition) and referenced by groups. There is no composition or aggregation that specifies, that edges can be owned by groups. (http://groups.google.de/group/UMLforum/browse_thread/thread/bdd07d113676a41f/20b33a18f90db3d9?#20b33a18f90db3d9

  • Reported: UML 2.1.1 — Thu, 6 Dec 2007 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • 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:58 GMT

15.3.14: This paragraph refers to signal and change events

  • Key: UML22-368
  • Legacy Issue Number: 12218
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Axel Scheithauer)
  • Summary:

    This paragraph refers to signal and change events, but should refer to signal and call events: >>However, relative to its use for signal events (see “SignalEvent (from Communications)” on page 449) and change events (see “ChangeEvent (from Communications)” on page 435), the <assignment-specification> ... Instead it should read: >>However, relative to its use for signal events (see “SignalEvent (from Communications)” on page 449) and call events (see “CallEvent (from Communications)” on page 434), the <assignment-specification> ... ChangeEvents don't even have an assignment specification, but signal an call events do.

  • Reported: UML 2.1.2 — Fri, 8 Feb 2008 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • 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:58 GMT

Section: 8.3.2 Connector

  • Key: UML22-358
  • Legacy Issue Number: 11762
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    In fig. 8.12 on page 153 the delegate connector points directly to an interface or from an interface on the right side. According to the connector definition in 9.3.6 and 8.3.2 it is not allowed to do that. In addition such a notational variant is nowhere described.

  • Reported: UML 2.1.1 — Thu, 6 Dec 2007 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • 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:58 GMT

UML 2.1.1 Issue: Invalid association end in Figure 7.20

  • Key: UML22-365
  • Legacy Issue Number: 12193
  • Status: closed  
  • Source: Eclipse Foundation ( Mr. Kenneth Hussey)
  • Summary:

    The non-navigable (as indicated by the X) association end typed by classifier ‘B’ in figure 7.20 of 07-02-05 is invalid, since the classifier – not the association – owns that end (as indicated by the dot notation as described on page 42)… recall that an association end owned by a classifier (and not the association) is implicitly navigable.

  • Reported: UML 2.1.2 — Tue, 22 Jan 2008 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • 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:58 GMT

Section: 17.5

  • Key: UML22-275
  • Legacy Issue Number: 10347
  • Status: closed  
  • Source: CNAM ( Jean-Frederic Etienne)
  • Summary:

    Is it possible in UML 2.0 specification to define a formal template parameter, for which the actual parameter to be given during parameter substitution is not a classifier but an instance of a specific classifier (more precisely, an instance of a specific class). If this is possible, what should be the type of the parameterable element exposed by the formal template parameter?? Does it have to be of type InstanceSpecification (or even ValueSpecification) to indicate that we are expecting an Object as actual parameter?? Moreover, what should be the type of the parameterable element to be exposed as actual parameter to indicate that we are providing a specific instance or value?? Finally what should be the proper notation for such template parameter to make the distinction with classifier template parameter??

  • Reported: UML 2.0 — Fri, 15 Sep 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    InstanceSpecification is not a ParameterableElement, so it cannot be used as a TemplateParameter. Providing a specific instance to a part would be done by assignment, not template bindings. See WriteStructuralFeatureAction.
    Revised Text:
    Disposition: Closed, no Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 state machines / entry point outgoing transitions

  • Key: UML22-274
  • Legacy Issue Number: 10147
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    In section 15.3.8 of the of the UML spec 06-04-02.pdf on page 563 it says:

    An entry point pseudostate is an entry point of a state machine or composite state. In each region of the state machine or composite state it has a single transition to a vertex within the same region.

    I believe that the intent was to say "at most a single transition", since it is possible that no transition exists as well as having multiple outgoing transitions (with guards) in each region.

  • Reported: UML 2.1 — Wed, 30 Aug 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    It is correct that entry points do not 'have' to have an outgoing transition. Updating the text is appropriate.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page 60 of the pdf

  • Key: UML22-278
  • Legacy Issue Number: 10356
  • Status: closed  
  • Source: Queen's Unioversity ( Juergen Dingel)
  • Summary:

    Page 60 of the pdf (41 in the doc), right above Figure 7.19:

    • replace "also shows umambiguously that end B is owned by BinaryAssociationAB"
      by "also shows umambiguously that endB is owned by BinaryAssociationAB"
  • Reported: UML 2.1 — Wed, 20 Sep 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    The is a space between end and B. end B should be endB.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML2: Parameter::isException overlaps with Operation::raisedException

  • Key: UML22-277
  • Legacy Issue Number: 10353
  • Status: closed  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    Section 12.3.41 in CompleteActivites extends Parameter with an isException property. Operation also has property raisedException. The relationship between parameters with isException true and the operation's raisedExceptions is unclear. Is it the intention that Parameter::isException is a notation for indicating the exceptions raised by an operation. If so, then it should be in Basic where raisedException is introduced and constraints need to be added to ensure these parameters are not included in the operation's ownedParameters, and are include in the operation's raisedException. See also Issue 9406: UML2: No notation for indicating Operation::raisedException. Hopefully this is not the case because it mixes parameter and exceptions together and results in redundancy in the metamodel.

    It is possible isException was added so Activities could have an ActivityParameterNode to output exceptions. But this did not get completely integrated with the rest of UML2. I will raise an issue for this too. Perhaps there should be ActivityExceptionNodes that correspond to an operation's raisedExceptions instead of mixing parameters with exceptions.

  • Reported: UML 2.1 — Tue, 19 Sep 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

uml.xsd schema file in ptc/2006-04-05 is not correctly generated

  • Key: UML22-279
  • Legacy Issue Number: 10376
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    New ISSUE on UML 2.1 Schema File

    Source: Tom Rutt (Fujitsu)

    Criticality: URGENT

    Problem Description:

    The UML 2.1 RTF Final report cites the following supporting
    documents:

    ptc/2006-04-02 Unified Modeling Language: Superstructure
    ptc/2006-04-03 Unified Modeling Language: Infrastructure
    ptc/2006-04-04 Unified Modeling Language: XMI specifications
    ptc/2006-04-05 Unified Modeling Language: XSD specifications

    The uml.xsd schema file in ptc/2006-04-05 (which is an
    informative document) is not correctly generated.

    In particular, several of the enum values specified in this
    schema have prefixes attached, which are not specified in the
    Meta Model. For example, the visibilityKind enumeration has its
    values improperly prefixed by the string “vis_” ( vis_public, vis_private …).

    This has caused interoperability problems with existing tools,
    since some of them have used the incorrectly generated xsd file for
    uml There is a need to post a corrected uml 2.1 schema on the document server.

    Also, the OMG document references for the supporting xmi and
    schema files are not up to date in the superstructure specification.

    Proposed Solution:

    Post properly generated schemas in a new UML 2.1 XSD Specification
    file on the server.

    Post an updated version of the UML 2.1 RTF report which refers to
    the correctly generated UML XSD specification file.

    The Document references cited in Annex G of the UML 2.1
    superstructure spec should be corrected to point at the most up
    to date and correct specifications.

  • Reported: UML 2.1 — Thu, 28 Sep 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML2: ReadSelfAction with a context cannot access behavior owned attributes

  • Key: UML22-284
  • Legacy Issue Number: 10441
  • Status: closed  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    Section 11.3.36 ReadSelfAction, Semantics indicates ReadSelfAction returns the context classifier for a behavior if the behavior has a context, otherwise it returns the behavior itself. This special case should be removed. ReadSelfAction should always result in the behavior. Otherwise if a behavior has a context classifier, there is no action available to access the structural features of the behavior. Having ReadSelfAction always result in the Behavior provides access to both the Behavior's ownedAttributes as well as those of the context classifier. If ReadSelfAction is the context classifier, then only its properties can be accessed.

  • Reported: UML 2.1 — Sun, 5 Nov 2006 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Resolution:
    Duplicate of issue 8016.
    Revised Text:
    None.
    Disposition: Duplicate

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Activity shape

  • Key: UML22-283
  • Legacy Issue Number: 10388
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    would like to shed some light on Activity notation (symbol) as such (Figure 12.33 in ptc/2006-04-02).
    Is it just alternative notation of Activity Diagram Frame or this symbol is intended to use in Activity diagrams as sub parts of other Activity?

  • Reported: UML 2.0 — Wed, 12 Jul 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

12.3.27 ExpansionRegion

  • Key: UML22-273
  • Legacy Issue Number: 10146
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Typo in paragraph Presentation options on page 385: insert blank between "12.85" and "maps".

  • Reported: UML 2.1.1 — Mon, 28 Aug 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    This seems to have already been corrected in UML 2.2 as an editorial change.
    Revised Text:
    None
    Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

12.3.26 ExpansionNode

  • Key: UML22-272
  • Legacy Issue Number: 10145
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Specify constraint that a expansion node can have a regionAsInput and a regionAsOutput, but not both at the same time.

  • Reported: UML 2.1.1 — Tue, 1 Aug 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Meaning of Constraint visibility

  • Key: UML22-281
  • Legacy Issue Number: 10382
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    Constraint inherits visibility from PackageableElement but there is no
    description of what it might mean for a Constraint to be more or less
    visible.
    One option would be to constrain Constraint::visibility to be a specific
    value

  • Reported: UML 2.1 — Thu, 5 Oct 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 7.3.38

  • Key: UML22-280
  • Legacy Issue Number: 10379
  • Status: closed  
  • Source: St. Petersburg State University ( Iskander Absalyamov)
  • Summary:

    visibility default value cannot be false

  • Reported: UML 2.1.1 — Mon, 30 Oct 2006 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    See issue 10831 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.2 Action

  • Key: UML22-276
  • Legacy Issue Number: 10351
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Semantics, rule [2] "If multiple control tokens are available on a single edge, they are all consumed." How does this rule fit to the rule that the default weight of an edge is 1. If multiple control tokens are available only one of them can traverse the edge to the target node

  • Reported: UML 2.1.1 — Tue, 19 Sep 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

redefined properties

  • Key: UML22-271
  • Legacy Issue Number: 10144
  • Status: closed  
  • Source: International Business Machines ( James Bruck)
  • Summary:

    I believe that Port should subset Property::redefinedProperty to include Ports since Ports are Properties

  • Reported: UML 2.1 — Mon, 28 Aug 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Change references in Infra- and Superstructure to UML 2.1.1- URGENT ISSUE-

  • Key: UML22-282
  • Legacy Issue Number: 10386
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Change all references to UML 2.1 in the Infrastructure and Superstructure documents to UML 2.1.1

  • Reported: UML 2.1 — Thu, 12 Oct 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Activities - Pin ordering semantics

  • Key: UML22-240
  • Legacy Issue Number: 9860
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    Pin ordering semantics. In Activities, InputPin, OutputPin, the semantics of ordering inherited from ObjectNode should be related to multiplicity ordering inherited from MultiplicityElement. For example, if an output pin of ReadStructuralFeatureAction has an object node ordering of FIFO, and the structural feature is ordered (which means the multiplicity ordering of the pin is also), then perhaps the multiple values posted by a single execution of the action should be drawn from the pin in the same order as in the structural feature. Since the action will post the values to the output pin at the same time, currently FIFO ordering on the pin will be indeterminant

  • Reported: UML 2.1.1 — Tue, 27 Jun 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Add text below.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section Activities: Default weight

  • Key: UML22-239
  • Legacy Issue Number: 9858
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    Default weight. In Activities, ActivityEdge, Assocations, the default weight should be unlimited . For example, a ReadStructuralFeatureAction of a mult-valued attribute might produce multiple tokens, which flow to the input of an AddStructuralFeatureAction. Do not want the values to be input to separate executions of AddStructuralFeatureAction

  • Reported: UML 2.1.1 — Tue, 27 Jun 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    The spec says weight determines the minimum number of tokens that must traverse the edge (offers accepted by target) at the same time. And it requires any tokens offered above the minimum to be taken at the same time:
    When the minimum number of tokens are offered, all the tokens at the source are offered to the target all at once.
    So the default can remain 1 for the example.
    Revised Text:
    None.
    Disposition: Closed No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

text of specs and corresponding XMI specs should be clarified

  • Key: UML22-235
  • Legacy Issue Number: 9833
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The relationship between the text of the specs and the corresponding XMI specifications should be clarified to explicitly state that, in cases of disagreement between the text and the XMI, the latter takes precedence.

  • Reported: UML 2.0 — Thu, 22 Jun 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Put a paragraph into clause 2 to clarify this

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2: "isLeaf"

  • Key: UML22-234
  • Legacy Issue Number: 9831
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The "isLeaf" attribute of Class implies that there cannot be any subclasses of a class, but there is no corresponding OCL constraint that enforces that.

    Also, "isLeaf" is only defined in the Superstructure and not in the Infrastructure – should it be defined in the Infrastructure as well?

  • Reported: UML 2.0 — Tue, 20 Jun 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    The meaning of the 'isLeaf' attribute changed from UML 1.x to UML 2.x
    In UML 1.5 (formal/03-03-01), 'isLeaf' is a property defined in two contexts:

    • In GeneralizableElement (see 2.5.2.23) where it "specifies whether the GeneralizableElement is a GeneralizableElement with no descendents. True indicates that it may not have descendents, false indicates that it may have descendents (whether or not it actuallyhas any descendents at the moment)"
      The fact that the UML 1.5 concept of a leaf in a generalization hierarchy has no equivalent in UML 2.2 has been raised as a separate issue from this - see issue 10515.
    • In Operation (2.5.2.30) where "if true, then the implementation of the operation may not be overriden by a descendant class. If false, then the implementation of the operation may be overridden by a descendant class (but it need not be overridden)."
      The UML 1.5 concept of a non-overridable operation corresponds to the UML 2.2 of RedefinableElement::isLeaf (see 7.3.46)
      The second part of this issue, i.e., whether the UML 2.2 infrastructure (formal/09-02-04) needs a capability for modeling a specialization leaf in a redefinition hierarchy is a strategic issue out of scope for the UML2 RTF.
      See resolution to issue 12532 for the OCL constraint enforcing the meaning of isLeaf in the context of redefinitions.
      Disposition: Closed No Change
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 15.3.14 Transition

  • Key: UML22-227
  • Legacy Issue Number: 9824
  • Status: closed  
  • Source: Paranor AG ( Earl Waldin)
  • Summary:

    In section 15.3.14, Transition, subsection Constraints you will find the following constraint: [6] An initial transition at the topmost level (region of a statemachine) either has no trigger or it has a trigger with the stereotype “create”. ... OCL body for constraint ... The element to be stereotyped in this constraint is a Trigger. If you look in Appendix C: Standard Stereotypes you will not find this stereotype. It appears that this constraint is left over from UML1.4/1.5. In UML 1.4 the corresponding stereotyped element in this constraint was an Event. In particular it was a CallEvent. The corresponding <<create>> stereotype is listed in Appendix C as a retired stereotype. So, either the constraint should be deleted or the stereotype must be brought out of retirement.

  • Reported: UML 2.0 — Wed, 14 Jun 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 7

  • Key: UML22-226
  • Legacy Issue Number: 9823
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Sebastien Gerard)
  • Summary:

    In UML2, it is possible to describe user defined datatypes and propertis may typed by this typed. But, nothing has been defined in the UML2 specifcation to be abble to describe values (of slots for example) which has to be conform to a datatype. One could add a new metaclass (for example, DataTypeValueSpecification inheriting from ValueSpecification) in the Expression package to be abble to denote datatype values. And to define the underlying notation.

  • Reported: UML 2.1.1 — Mon, 12 Jun 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Merged with 15248

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Figure 7.4 invalid redefines

  • Key: UML22-238
  • Legacy Issue Number: 9843
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    This contains an unnamed property that

    {redefines _namespace}

    . There is
    no property _namespace and the redefining property should be should be
    named.
    In Infra there is no such redefinition in Figure 11.21- is it actually
    needed?

  • Reported: UML 2.0 — Tue, 27 Jun 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

EnumerationLiteral should constrain InstanceSpecification

  • Key: UML22-237
  • Legacy Issue Number: 9841
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    EnumerationLiteral currently inherits from InstanceSpecification.
    However it does not make sense for it to have all the capabilities of
    the latter, for example Slots.
    Therefore a constraint should be added to EnumerationLiteral as follows:
    slot.isEmpty
    Furthermore it does not make sense for EnumerationLiteral to have a
    separate classifier than its Enumeration. So the following redefinition
    should be added:
    enumeration

    {redefines classifier}

    (alternatively if this is felt too complex there should be a constraint
    {classifier.isEmpty)

    Another option would be for EnumerationLiteral to inherit from
    ValueSpecification - as suggested by the name of the class (other
    Literal classes are subtypes of ValueSpecification). However this would
    probably be too major a change to justify the benefit.

  • Reported: UML 2.0 — Tue, 27 Jun 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Stereotype attributes inherited from Class

  • Key: UML22-233
  • Legacy Issue Number: 9830
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    What is the interpretation of the various atttributes that Stereotype inherits from Class, such as "isLeaf" and "isAbstract"? Do they mean the same thing, or are they inapplicable, or subtly different?

  • Reported: UML 2.0 — Tue, 20 Jun 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.8

  • Key: UML22-232
  • Legacy Issue Number: 9829
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Section Associations of ActivityNode: /inGroup:Group[0..*] Groups containing the node. should be /inGroup:ActivityGroup[0..*] Activity groups containing the node.

  • Reported: UML 2.1.1 — Mon, 19 Jun 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 11.4.1 "Classifier" (in Constructs)

  • Key: UML22-231
  • Legacy Issue Number: 9828
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The description says: "Constructs::Classifier merges the definitions of Classifier from Basic and Abstractions."
    a) The "Abstractions"package is not supposed to be merged by Constructs.
    b) There is no Basic::Classifier, so this reference is probably in error. There is Basic::Class, though.

  • Reported: UML 2.0 — Fri, 16 Jun 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Notation (p 154, formal/05-07-04 )

  • Key: UML22-228
  • Legacy Issue Number: 9825
  • Status: closed  
  • Source: Anonymous
  • Summary:

    I observed some minor errors on Document formal/05-07-04 while reading it, but
    there is an aparent inconsistence that must be checked. I will explain it
    below.

    On page 154 we can read:
    "Notation
    A component realization is notated in the same way as the realization dependency
    (i.e., as a general dashed line with an open arrow-head)."

    But on page 125 we can read:
    "A Realization dependency is shown as a dashed line with a triangular arrowhead
    at the end that corresponds to the realized element."

    It's clear that the error is on page 154 definition

  • Reported: UML 2.0 — Tue, 13 Jun 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 11.4.1 "Classifier" (in Constructs)

  • Key: UML22-230
  • Legacy Issue Number: 9827
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The association "feature" is not marked as a derived element, but probably should be.

  • Reported: UML 2.0 — Fri, 16 Jun 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 10.2.1 "Class" (in Basic)

  • Key: UML22-229
  • Legacy Issue Number: 9826
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    "ownedAttribute", "ownedOperation" and "superClass" are listed as attributes, but they probably should be listed as associations

  • Reported: UML 2.0 — Fri, 16 Jun 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 15.3.12

  • Key: UML22-236
  • Legacy Issue Number: 9839
  • Status: closed  
  • Source: Engenuity Technologies, Inc. ( Mikon Dosogne)
  • Summary:

    If there are multiple enabled internal transitions within the active state, should they all be fired? The standard suggests that they should all be fired, but is this done in practice? For example, consider the case of two internal transitions within the same state, triggered by the same event, with no guard condition. If that event occurs, will both transitions fire?

  • Reported: UML 2.1.1 — Mon, 26 Jun 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Merged with 9840

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 7.3.7

  • Key: UML22-192
  • Legacy Issue Number: 9375
  • Status: closed  
  • Source: Paranor AG ( Earl Waldin)
  • Summary:

    Incorrect specification of association Class::nestedClassifier. The specification of the association Class::nestedClassifier, section 7.3.7, page 46 states that it subsets Element::ownedMember. The Class Element does not have an association ownedMember. Element does have an association ownedElement, but that is not likely correct because a nested classifier is really a namedElement. Most likely, Class::nestedClassifier should subset Namespace::ownedMember.

  • Reported: UML 2.0 — Thu, 23 Feb 2006 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    See issue 10829 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

AssociationClass is severely underspecified

  • Key: UML22-191
  • Legacy Issue Number: 9374
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    It is not at all clear which Properties will result on both the AssociationClass and the end Classes. The Semantics section of 7.3.4 says nothing more specific than "The semantics of an association class is a combination of the semantics of an ordinary association and of a class." - without saying anything about how they are combined. neither is there any indication as to how to access the attributes of the AssociationClass.
    One specific issue is that the composition property is inherited twice: ownedEnd and ownedAttribute - with no redefinition or subsets relationship between them.
    Neither is anything said about the effect of navigability.

    Proposed resolution:

    AssociationClass should redefine ownedNavigableEnd

    In the example in 7.3.4 the following properties will result. C: indicates here that C owns P via the Class:ownedAttribute property. In this case both ends are owned by the class not the association (though the absence of dots at the line ends would imply otherwise - the example should be redrawn).
    Several extra properties are implied by the diagram and have to be implicitly created by the tool. These are marked !! below.

    Person::company: Company[1..*] association=Job
    !!Person::job: Job[1..*] // This then allows access to the properties of Job such as Salary. Note that Person::job.association isEmpty

    Company::person: Person[*] association=Job
    !!Company::job: Job[*]

    Job::salary: Integer[1]
    !!Job::person: Person[1]
    !!Job::company: Company[1]
    Job.memberEnd=(Person::company, Company::person)
    Job.ownedEnd->isEmpty=true

    There needs to be a discussion and clear rules for the invented names for the new properties and constraints to avoid clashes. Also need to address issues related to unions/subsets/redefines/navigability and their effect on the implicit properties.

    Also there is a complication if the Association class itself has further associations: how in the metamodel are these Properties on t he AssociationClass distinguished from the 'main' Ends representing the line to which the AC is attached.

  • Reported: UML 2.0 — Thu, 23 Feb 2006 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    For explanations, see "Changes from previous UML" below. The OCL in this resolution is written according to OCL 2.1 ptc-09-05-02. Where the changes in the revised text pertain to metaclasses in the superstructure merged from InfrastructureLibrary::Core::Constructs which is the resulting package of merging several package increments from InfrastructureLibrary::Core::Abstractions as specified in clause 11.2 of the UML 2.2 Infrastructure, then the revisions described below have to be similarly reflected in InfrastructureLibrary::Core::Constructs (i.e. the resulting metaclass) and in the metaclass increments merged from the sub-packages of InfrastructureLibrary::Core::Abstractions.
    The revised text clarifies that owned ends of an association class, as an association, are disjoint from owned attributes of that same association class.. Navigability for association classes is the same as associations. Navigation from instances of association classes to their end objects, and any other unaddressed aspects of the issue, will be refiled as a separate issue.
    This resolution includes an OCL constraint which depends on the OCL 2.1 revision:
    context AssociationClass
    self.A_general_classifier::classifier
    ->forAll(oclIsKindOf(AssociationClass))
    The meaning of this constraint is as follows:
    self.A_general_classifier::classifier
    This expression navigates the association A_general_classifier in the inverse direction of the navigability of the property /Classifier::general : Classifier[*].
    That is, it provides the set of classifiers that specialize 'self'.
    See 7.5.3 (Properties: AssociationEnds and Navigability), p. 18-19 in OCL 2.1 http://www.omg.org/cgi-bin/doc?ptc/09-05-02

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Show an example of correct notation for the metamodel

  • Key: UML22-190
  • Legacy Issue Number: 9372
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    Though section 6.5.2 explains and justifies the convention (in the UML2 spec only) for use of navigability arrows to represent property ownership, it would be worth showing a non-normative example of one of the metamodel diagrams with the correct 'dot at line end' notation used. This depends on the resolution to issue A) above.

    C) Use the new 'dot' notation in examples
    Currently there is only one example of its use. However most of the examples have taken an unadorned line to indicate that both ends are owned by the respective classes: now the same diagram indicates both ends are owned by the association. Though tools may be at liberty to hid the adornments the spec itself should be extremely precise in the examples and show the adornments explicitly since otherwise the diagrams are ambiguous.
    Note that the conventions in 6.5.2 explicitly apply only to the diagrams for the metamodel itself (see line 1 of 6.5.2).

  • Reported: UML 2.0 — Thu, 23 Feb 2006 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page: 338, 339

  • Key: UML22-185
  • Legacy Issue Number: 9330
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The fork node does not provide tokens to outgoing edges with a guard that evaluates to false. Actions with more than one outgoing edge have a implicit fork semantic. It is unclear if a token is provided to edges with false-guards. The specification defines on page 339: "The guard must evaluate to true for every token that is offered to pass along the edge." Does the token exist if the guard evaluates to false? Does the token wait until it evaluates to true? The evaluation is done at runtime. At which time exactly? While offering tokens or all the time during activity runtime?

  • Reported: UML 2.1 — Mon, 30 Jan 2006 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    In the UML 2.5 beta specification, in Subclause 15.2.3, under “Activity Edges”, it states: “An ActivityEdge may have
    a guard, which is a ValueSpecification that is evaluated for each token offered to the edge.” In 15.3.3, under “Fork
    Nodes”, it further states: “Tokens offered to a ForkNode are offered to all outgoing ActivityEdges of the node.” Thus,
    the guards on outgoing edges are evaluated when the tokens offered to the ForkNode are offered to them. Finally, the
    specification notes: “Any outgoing ActivityEdges that fail to accept an offer due to the failure of their guard, rather
    than their target, shall not receive copies of those tokens.” So, outgoing edgeswith guards that evaluate to false do not
    receive tokens and therefore do not offer them downstream.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Optional name attribute in NamedElement is misleading and insufficient

  • Key: UML22-184
  • Legacy Issue Number: 9256
  • Status: closed  
  • Source: Borland Software Corporation ( Stephen Palmer)
  • Summary:

    find it very unintuitive that the name attribute of a NamedElement is optional and If specified may be any valid string, including the empty string. A more accurate name for an element that has the capacity to have a name but does not necessarily have one would be, NameableElement instead of the misleading NamedElement.
    However, elements that do not have a name (or that have a name comprising solely of the empty string or white space characters) have no means through which a human can precisely reference them other than through their physical location on a diagram. This leaves open an opportunity for ambiguity in referencing elements and possible mis-communication. For this reason, the name attribute of NamedElement should be required, should not be allowed to contain just the empty string or just white space characters and should be unique within the element's package. In practise, even an artificially generated name for an element is preferable to no name at all.

    The question of whether the name of an element should be displayed on a particular diagram is a completely different subject and should, in general, be a decision made on a case-by-case basis by the modeller. However, even when the name is not displayed on a diagram, requiring elements to have a readable name provides tool-makers with opportunities to show the name of the element in tool tips, status bars, model navigation panes, etc so that the element can still be readily identified and precisely distinguished from others by human users of the model.

    It is very common in many organizations to have both a short name for an element and a longer more descriptive name for an element. For example, a use case may have the short name UC-OP0001 and a longer name 'Place Order'. The current NamedElement has no provision for such a scheme. In practise, it would be frequently very useful NamedElements had an optional longer name as well as a required short name attribute. Whether the short or long name (when provided) are used on a particular diagram or in any other context is again a matter for the modeller and tool-makers.

  • Reported: UML 2.0 — Fri, 20 Jan 2006 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    The use of NamedElements with no names is well established in a number of cases in UML. Tools can provide all the
    advantages described by the issue author if the modeler gives a NamedElement a name, but it is more convenient to
    allow the modeler the choice of whether to do that.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / Components / connectors to interfaces

  • Key: UML22-197
  • Legacy Issue Number: 9464
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    In chapter 8 there are several references that indicate that a connector can be drawn between two or more interfaces. This is not possible, since an interface is not a connectable element.

  • Reported: UML 2.0 — Tue, 21 Mar 2006 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Indeed so. The revised text below corrects this.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

reference to Figure 12.87 missing

  • Key: UML22-187
  • Legacy Issue Number: 9341
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    Last para on p385 starts: "Figure 12.86 shows a fragment of a Fast Fourier Transform (FFT) computation containing an expansion region. Outside the region, there are operations" - the reference should be to Figure 12.87

  • Reported: UML 2.0 — Tue, 24 Jan 2006 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 14.4

  • Key: UML22-186
  • Legacy Issue Number: 9340
  • Status: closed  
  • Source: Digital River ( Mark Mendel)
  • Summary:

    The comment in figure 14.2 in the top right cell identifies the last message as a reply, but it is in fact a creation message. See 14.3.20 Message, Notation, pg. 478: Synchronous Messages typically represent method calls and are shown with a filled arrow head. The reply message from a method has a dashed line. Object creation Message has a dashed line with an open arrow.

  • Reported: UML 2.0 — Tue, 31 Jan 2006 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    The only indication of the notation for reply messages in 2.4.1 was table 14.2 and some examples, all of
    which showed a dashed line with open arrowhead. So we assume this was normative even though it was not
    very explicit.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

No ObjectEvent corresponding to SendObjectAction

  • Key: UML22-194
  • Legacy Issue Number: 9403
  • Status: closed  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    SendObjectAction sends the object on its request InputPin the object at its target InputPin.

    AcceptEventAction can have a trigger that is a SignalEvent or CallEvent, but there is no Event type for ObjectEvent to represent the receipt of an object from a SendObjectAction. SignalEvent cannot be the trigger because it is not a Class and is not general enough.

  • Reported: UML 2.0 — Tue, 28 Feb 2006 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    This issue is obsolete. The UML 2.5 specification, in subclause 16.3.3, under “Send Actions”, now includes the
    following text in the description of the semantics of SendObjectAction: “If the object [sent by the action] is a Signal
    instance, then it may be handled by the target object in the same way as an instance sent from a SendSignalAction
    or BroadcastSignalAction. Otherwise, the reception of the object can only be handled using an AnyReceiveEvent (as
    described under Message Events in sub clause 13.3.3).”
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Fig 12.10

  • Key: UML22-193
  • Legacy Issue Number: 9395
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    Fig 12.10 shows Activity.partition with multiplicity 1 but the text on page 329 shows [0..*].I suspect that the former is correct.

  • Reported: UML 2.0 — Thu, 23 Feb 2006 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    This was resolved in the final resolution of issue 8208 in UML 2.1. (It was actually 0..* that was correct.)
    Revised Text:
    None
    Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page: 625

  • Key: UML22-189
  • Legacy Issue Number: 9362
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Extend (with condition) entry in diagram table: The comment anchor line has a small circle at the end. That's not UML notation, but Pavel Hruby notation

  • Reported: UML 2.1 — Wed, 15 Feb 2006 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Merged with 18084

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2.1/Superstructure/ call triggers vs signal triggers

  • Key: UML22-188
  • Legacy Issue Number: 9351
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    P. 603 makes reference to "CallTriggers" and "SignalTriggers". I believe the wording on that whole paragraph under "Example" should be changed slightly.
    P. 246 makes reference to "SignalTrigger"
    P. 453 makes reference to "call trigger" ( I believe the wording should be modified slightly. )

  • Reported: UML 2.0 — Wed, 1 Feb 2006 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.48

  • Key: UML22-196
  • Legacy Issue Number: 9416
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    I've found a implicit constraint: Imagine - for example - a LoopNode. It's part of an activity partition called component1. Within the body of the loop node an action should be called that's part of another activity partition called component2 (It's a common scenario: a component calls another component from within a loop). However that's not allowed: the loop node is in partition component1 while a contained action is in partition component2. Is that right? If yes, I believe it should be allowed.

  • Reported: UML 2.1 — Tue, 14 Mar 2006 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    It is not clear what the submitter means by a loop node "calling" an action. As a structured activity node, a loop node owns the actions within it. However, an activity partition references contained nodes and edges, but it does not own them. Therefore, it is allowable for the actions contained in a loop node to be in different partitions, if this is what is desired.
    Revised Text:
    None
    Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2.2 RTF issue - line styles for profiles

  • Key: UML22-198
  • Legacy Issue Number: 9513
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    UML stereotypes can have an associated icon. For shapes there are 2 options for applying the icon: display the icon in the top right of the standard UML shape, or completely replace the standard shape with the icon.
    However for lines there is only the option of displaying the icon 'near' the standard UML representation of the line. This is somewhat clunky at best and limits the flexibility of profiles.

    The equivalent of using the icon to replace the original UML shape would be to allow the specification of a new line style: the icon could be used to represent both ends and the middle - and the tool would repeat the middle section in order to create an actual line.

  • Reported: UML 2.0 — Wed, 5 Apr 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / Composite Structure / ambiguous constraint

  • Key: UML22-195
  • Legacy Issue Number: 9413
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    There is a constraint on page 159.:

    [5] An assembly connector must only be defined from a required Interface or Ports to a provided Interface or Port.

    The wording is quite unclear. Interfaces are not by themselves required or provided but relative to a port or a classifier. Also, it implies that it should be possible to draw a connector from an Interface to a Port. This constraint needs to be clarified and made more precise.

  • Reported: UML 2.0 — Wed, 8 Mar 2006 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Resolution:
    This is a duplicate of 7251

    Revised Text:
    None.

    Disposition: Duplicate of 7251

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 15.3.12

  • Key: UML22-132
  • Legacy Issue Number: 8890
  • Status: closed  
  • Source: IBM ( Jaroslav Gergic)
  • Summary:

    The UML 2.0 Specification states at 15.1 that "The state machine formalism described in this section is an object-based variant of Harel statecharts." However, there is a big semantical discrepancy between the Harel statecharts as described in D. Harel and M. Politi, Modeling Reactive Systems with Statecharts: The STATEMATE Approach, (with M. Politi), McGraw-Hill, 1998 and the UML 2.0 specification. The major difference is in the priority of transitions when multiple transitions are enabled in case of a nested (hierarchical) state machine. Harel states (6.3.1 (pages 99-100)): "The criterion for priority of transitions prefers the transition whose source and target have a higher common ancestor state, if possible. If the common ancestors of both transitions are identical, then non-determinism indeed occurs." (i.e. it prefers global, higher-level transitions over local ones) UML 2.0 (15.3.12 page 618) imposes almost a reveres-ed order on the priority of the transitions, by looking up from the current nested leaf state and taking the first enabled transition. The impact of the UML definition is that the author can not only "refine" a high-level state in its descendants, he/she can override the global transitions thus violating the global (high-level) contract of the state machine. This becomes even more dangerous when using submachine state, i.e. the nested state is actually drawn in a separate diagram. Example: imagine an electrical device, which can be in one of 2 top-level states: ON, OFF and having two transitions power_on, power_off. The ON state can have multiple sub-states describing a particular state of the operation. Using the UML 2.0 semantics, one can effectively override the global power_off transition locally in on of the ON's children, forcing the electrical device to keep working, even if the power has been shut down - ignoring the signal using e.g. a self-transition.

  • Reported: UML 2.0 — Wed, 29 Jun 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    To avoid confusion, add a clarification

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.5.1 DataType (as specialized)

  • Key: UML22-131
  • Legacy Issue Number: 8889
  • Status: closed  
  • Source: University of Kassel, Germany ( Thomas Weise)
  • Summary:

    In section 11.5.1 DataType (as specialized) you write "• ownedAttribute: Attribute[*] The Attributes owned by the DataType. Subsets Classifier::attribute and Element::ownedMember." The type "Attribute" does not exist. You mean Property, which is also shown correctly in the diagramm at page 133

  • Reported: UML 2.0 — Wed, 29 Jun 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

event parameters

  • Key: UML22-141
  • Legacy Issue Number: 8936
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    Event was able to own set of parameters in UML 1.4 .

    "Any parameter values associated with the current event are available to all actions directly caused by that event
    (transition actions, entry actions, etc.)."

    In UML 2.0 Parameters are removed from Event metaclass, but in chapter "Changes from UML 1.x" there is no comment about that ("None").

    Could you please comment how Parameters from UML 1.4 Event should be mapped into UML 2.0 model?

    I see a big problem, because some MDA tools (like AndroMDA) are based on information stored in Event parameters, hundreds of users have lot of projects, they can't be lost on migration.

  • Reported: UML 2.0 — Thu, 21 Jul 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    This issue is obsolete. Tools have long since adapted to this change in UML 2.0 and the UML 2.5 specification no
    longer lists “changes from UML 1.x”.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Meaning of navigability

  • Key: UML22-140
  • Legacy Issue Number: 8921
  • Status: closed  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    The resolution to issue 6460 in the InfrastructureLibrary specification indicates "Implementation can support traversal across non-navigable ends, but it is not required. Once an object is found by traversal, messages can be sent to it like any other object." This statement may lead to interoperability problems between implementations, is not included in the adopted Superstructure specification, and contradicts constraint [4] for ReadLinkAction which states the end must be navigable. Infrastructure also does not define what it means to send messages to an object so it is not clear what these statements actually mean.

    It is possible that the resolution to issue 6243 traded coupling between navigability and property ownership for coupling between navigability and tool implementations. Navigability no longer has any well-defined semantics and becomes simply a hint to tool implementors that the traversal should be efficient.

    I believe this is quite unfortunate and can be avoided by decoupling tool implementations that manipulate models from the meaning of the models themselves. Navigability should continue to mean semantically traversable as specified by ReadLinkAction. This will establish an interoperable meaning across all tools and preserve an important and commonly used semantic. If tools wish to support efficient traversal to non-navigable ends for their purposes, they should feel free to do so. This can be done by maintaining additional information in associations for the non-navigable ends for the tools purpose, or by using crawlers that examine the model and cache information for specific tool purposes. This is manipulating the model for very different purposes than the meaning of the model itself. If it is desired to have some standard means of indicating to tool vendors where non-navigable association ends should be efficiently traversable, this should be done by a separate property perhaps available through the standard profile. It should not be coupled with the semantic meaning of navigability.

  • Reported: UML 1.4.2 — Fri, 1 Jul 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.13 TypedElement (as specialized)

  • Key: UML22-130
  • Legacy Issue Number: 8888
  • Status: closed  
  • Source: University of Kassel, Germany ( Thomas Weise)
  • Summary:

    In section 11.3.13 TypedElement (as specialized) you write: Attributes • type: Classifier[1] Redefines the corresponding attributes in both Basic and Abstractions. Neither has InfrastructureLibrary::Core::Abstractions::TypedElements::TypedElement such a property, nor does InfrastructureLibrary::Core::Basic::Type::TypedElement, even through inheritance.

  • Reported: UML 2.0 — Wed, 29 Jun 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.6 Classifiers diagram

  • Key: UML22-129
  • Legacy Issue Number: 8887
  • Status: closed  
  • Source: University of Kassel, Germany ( Thomas Weise)
  • Summary:

    Issue for: UML 2.0 Infrastructure Specification Section: 11.3.6 Classifiers diagram Document: ptc/03-09-15 URL: http://www.omg.org/cgi-bin/doc?ptc/2003-09-15 Pages: 90,91,95,96,127,130 With this submission I report an serious error in your specification. On Page 127, Section 11.3.6 Classifiers diagram, you show that the type InfrastructureLibrary::Core::Constructs::TypedElement is a generalization of both, InfrastructureLibrary::Core::Abstractions::TypedElements::TypedElement (section 9.19.2, page 91) and InfrastructureLibrary::Core::Basic::TypedElement (section 10.1.3, page 96). This leads to a collission of properties, since both of these defined a property called "type", where the one is of the sort InfrastructureLibrary::Core::Abstractions::TypedElements::Type (section 9.19.1, page 90) and the other is of the sort InfrastructureLibrary::Core::Basic::Type (section 10.1.1, page 95). Both Type-types are incompatible, since none is a generalization of the other. Please help and clarify, because I want to implement your standard for a project and cannot proceed correctly. Thanks, Thomas Weise. tweise@gmx.de University of Kassel Germany

  • Reported: UML 2.0 — Wed, 29 Jun 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page: 62

  • Key: UML22-139
  • Legacy Issue Number: 8920
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. James J. Odell)
  • Summary:

    Description

    Figure 36 was not changed to conform to example description. Here, the example indicates that “the dependency is an instantiate dependency, where the Car class is an instance of the Vehicle Type class. However, Fig. 36 illustrates that Car class is an instance of the CarFactory class

    The page indicates issue 6159 addressed this same problem, but apparently it went unchanged.

  • Reported: UML 2.0 — Tue, 5 Jul 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

page 134, Chapter 11.4.1

  • Key: UML22-138
  • Legacy Issue Number: 8904
  • Status: closed  
  • Source: Anonymous
  • Summary:

    on page 134, Chapter 11.4.1, you write:

    "Constructs::Classifier merges the definitions of Classifier from Basic and
    Abstractions. It adds specializations from Constructs::Namespace and
    Constructs::Type."

    In Basic there is no definition for "Classifier".

  • Reported: UML 1.4.2 — Thu, 30 Jun 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

page 97, Chapter 10.2.2. MultiplicityElement

  • Key: UML22-137
  • Legacy Issue Number: 8903
  • Status: closed  
  • Source: Anonymous
  • Summary:

    On page 97, Chapter 10.2.2. MultiplicityElement, you write

    "Constructs::Relationship reuses the definition of Relationship from
    Abstractions::Relationships. It adds a specialization to
    Constructs::Element."

    which seems to be a little mislead copy-paste-action.

  • Reported: UML 1.4.2 — Thu, 30 Jun 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page: 129

  • Key: UML22-125
  • Legacy Issue Number: 8877
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    BNF for property notation states that the name of the property is mandatory. There is no appropriate constraint for that. If it is mandatory there are some wrong diagrams in the specification, e.g. Fig 334.

  • Reported: UML 2.0 — Thu, 23 Jun 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Not exactly. The BNF states that the <name> terminal is mandatory. Clarify in the text that where there is
    no property, <name> is empty.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page: 369/370

  • Key: UML22-124
  • Legacy Issue Number: 8876
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The notation for activity partition allows to notate the specification of the dimension next to the appropriate dimension set. Dimension is a boolean property of an ActivityPartition. It is not clear where the specification of a dimension is stored in the model.

  • Reported: UML 2.0 — Thu, 23 Jun 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    An ActivityPartition with isDimension = true is the specification of the dimension, and the partions contained within it are the partitions in that dimension. The dimension name in the notation is the name of an ActivityPartition with isDimension = true. This can be clarified in the text.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page: 157,162,163

  • Key: UML22-136
  • Legacy Issue Number: 8900
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Fig. 87, fig. 92, and fig.93 show composite structure diagrams with interfaces. For example fig 87; delegation connector from port to interface OrderEntry. How can a connector be linked to an interface?

  • Reported: UML 2.0 — Thu, 30 Jun 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Figure 87 is now 8.12. Figure 92 is now 8.17. Figure 93 is now 8.18. I include figure 8.15 in this resolution to get a consistent overall picture.
    The solution is to allow connector lines to connect lollipops and sockets, and ball and socket notation, only when the interfaces are on a simple port. Then the connectors become a notational shorthand for actually connecting to the ports.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ObjectNode

  • Key: UML22-135
  • Legacy Issue Number: 8895
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    ObjectNode is abstract, so CentralBuffer or DataStore should be always used in Activity diagram. It is normal?
    CentralBuffer and DataStore are described as "special cases of ObjectNodes", but simple ObjectNode can't exist.

  • Reported: UML 1.4.2 — Mon, 20 Jun 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Yes, this is correct. ObjectNode is a general abstraction. Only its subclasses (which include ActivityParameterNode, InputPin and OutputPin, in addition to CentralBufferNode and DataStore) have concrete syntax and semantics.
    Revised Text:
    None
    Disposition: Close, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

9.1 BehavioralFeature package

  • Key: UML22-127
  • Legacy Issue Number: 8880
  • Status: closed  
  • Source: University of Kassel, Germany ( Thomas Weise)
  • Summary:

    The element "Parameter" is shown to generalize both, TypedElement and NamedElement. However, TypedElement is already a generalization of NamedElement (see chapter 9.19). Thus, the second generalization is redundant and can be removed.

  • Reported: UML 2.0 — Mon, 27 Jun 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page: 532

  • Key: UML22-126
  • Legacy Issue Number: 8878
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Associations section: Type of argument is InputPin. In fig. 333 the type is Action

  • Reported: UML 2.0 — Thu, 23 Jun 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    This seems to refer to the argument association of InteractionUse, as of the UML 2.0 Draft Adopted Specification (ptc-04-10-02). It was corrected as an editorial change in UML 2.1.
    Revised Text:
    None
    Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UseCase and Actors

  • Key: UML22-134
  • Legacy Issue Number: 8893
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    UseCase can be connected with Actors using Association, but neither UseCase nor Actor can't own Properties (there are no subsets), so Association is always non-navigable, properties are owned by Association.

  • Reported: UML 1.4.2 — Mon, 20 Jun 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page: 423

  • Key: UML22-133
  • Legacy Issue Number: 8891
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Second constraint of ObjectNode refers to property isUnique. ObjectNode has no such property. It's not a specialized MultiplicityElement

  • Reported: UML 2.0 — Wed, 29 Jun 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    this is correct

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 10.1 Types Diagram

  • Key: UML22-128
  • Legacy Issue Number: 8882
  • Status: closed  
  • Source: University of Kassel, Germany ( Thomas Weise)
  • Summary:

    The Elements Type, NamedElement and TypedElement of the package Core::Basic are (ambiguous and redundant) redefinitions of the types Type, TypedElement (Core::Abstractions::TypedElements), and NamedElement (Core::Abstractions::Namespaces). Why is that?

  • Reported: UML 1.4.2 — Tue, 28 Jun 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Figure 179 (Control nodes)

  • Key: UML22-93
  • Legacy Issue Number: 8673
  • Status: closed  
  • Source: FUNDP ( Pierre Yves Schobbens)
  • Summary:

    Figure 179 (Control nodes) is not a complete partition of ControlNode: ForkNode, JoinNode, etc. are missing.

  • Reported: UML 1.4.2 — Tue, 5 Apr 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Resolution:
    This was resolved by the resolution to issue 7319 (during the UML 2.0 FTF), which added the FundamentalActivities package and resulted in changes to related diagrams.
    Revised Text:
    None
    Disposition: Duplicate

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: D.4

  • Key: UML22-92
  • Legacy Issue Number: 8616
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    In Description for CCMService, either add the ending or remove the opening quotation mark for the last word. The stereotype name for CCMProcess is not the same as that within the guillemets. Complete the Tag cell in CCMHome. Complete the Tag cell in CCMManages. Capitalize and correct spelling of "Always in the Constraints cell of CCMManages. The Description for CCMFactory really doesn't make a lot of sense to me but I'm not at all familiar with CCM Components. However the stereotype name doesn't relate to a create function for me.

  • Reported: UML 2.0 — Mon, 21 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 15.3.8 (second issue)

  • Key: UML22-91
  • Legacy Issue Number: 8612
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    "Entry actions of states entered on the path to the state represented by a deep history are performed." It's open which path is taken if there are more than one paths to the state.

  • Reported: UML 2.0 — Sat, 19 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    The word 'Path' has raised ambiguity with respect to how the history state will restore the active state configuration. There is only one way that the history will restore the active state, and that is through an implicit direct path from the history state to the innermost active states being reactivated (almost as though a transition is drawn directly from H* to the last active state). It in no way implies a state-by-state approach. (e.g. a path from the initial state to the last active state)

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 18.3.6

  • Key: UML22-90
  • Legacy Issue Number: 8601
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    ypos - Opening "(" dont agree with ")" for either constraint. Clarify the illustration of the first approach (examples in Fig. 450 and 451). It is still confusing. Typo - Under "Using XMI to exchange Profiles" last sentence of first para on pg 724, change "purpose" to "purposes." Last sentence on pg 726, change "and need to be...." to "and these constraints need to be..."

  • Reported: UML 2.0 — Fri, 18 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    It is unclear what approaches are being referred to in the second sentence. There are no figures 450 and 451.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 17

  • Key: UML22-89
  • Legacy Issue Number: 8594
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Add OCL notation to constraints or a note that OCL notation is not available for this constraint. In the figures show all sub-package names or ellipses associated with the direct generalizations. Use of the words subclass and subclasses is often confusing and inappropriate as these are not shown in associated figures or mentioned in text. Whenever subclasses are mentioned, please clarify by giving examples as was done on page 690. Orgainzation of this Part is confusing after becomming accustomed to the organization used in parts I and II. Placement of all abstract syntax figures in one place helps clarify relationships of figures to each other and makes it easier to see/verify consistency. Names of classifiers and packages in the text often don't agree with the names shown on associated figure.

  • Reported: UML 2.0 — Thu, 17 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 8.3.1

  • Key: UML22-102
  • Legacy Issue Number: 8705
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Notation section of component states that the relationship between realizing classifiers and the component is displayed by general dependencies. The specialized Realization states that it's notation is similar to the realization dependency. Change fig. 85: Replace dependency arrows by realization arrows (with triangular arrowhead).

  • Reported: UML 2.0 — Thu, 28 Apr 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    see page 50 of ptc/2009-09-07 for details

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Actions

  • Key: UML22-101
  • Legacy Issue Number: 8702
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Add OCL to constraints in Actions chapter

  • Reported: UML 1.4.2 — Tue, 26 Apr 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    This issue is obsolete. All constraints that can be specified in OCL have been in UML 2.5.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CombinedFragment Loop notation

  • Key: UML22-100
  • Legacy Issue Number: 8698
  • Status: closed  
  • Source: TMNA Services ( Jim Schardt)
  • Summary:

    There seems to be some confusion about how to show the notation for the loop combinedFragment. Some tools show only the minint and maxint for the loop InteractionOperator but do not allow you to show the full specification in the InteractionOperand. This is a limitation that allows for the modeling of simple for loops without an additional guard to model do while and do until types of loop constructs. I would suggest the UML Superstructure 2.0 be updated with the following:

    In Section 14.3.3 in Notation with header Loop:
    Place a simple example of a loop combined fragment with a InteractionOperand guard as well as a minint and maxint
    Add a paragraph that says something like, "In those cases where more control over the number of passes through the CombinedFragment is necessary use a separate InteractionConstraint. This InteractionConstraint is shown in square brackets covering the lifeline where the first event occurrence will occur, positioned above that event, in the containing Loop InteractionOperand. If this separate InteractionConstraint is true, the loop continues, otherwise the loop terminates."

  • Reported: UML 1.4.2 — Thu, 21 Apr 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 7.3.36

  • Key: UML22-99
  • Legacy Issue Number: 8692
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    According to fig. 13 an operation is associated with a Datatype. That's not shown in the association section of the class description.

  • Reported: UML 2.0 — Sun, 10 Apr 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

editorial in section 12

  • Key: UML22-98
  • Legacy Issue Number: 8689
  • Status: closed  
  • Source: FUNDP ( Pierre Yves Schobbens)
  • Summary:

    "... is eligible for execution when it receives control tokens from each of its predecessor clauses. " Should read ``a control token''

  • Reported: UML 1.4.2 — Tue, 5 Apr 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Different constraints for Property in Super and Infra

  • Key: UML22-97
  • Legacy Issue Number: 8688
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The Infrastructure has an additional constraint on Constructs::Property (pg. 128):

    [2] A specialization of a composite aggregation is also a composite aggregation.

    that does not exist in the Superstructure. These two should be made consistent; either the constraint appears in both places or in neither.

  • Reported: UML 1.4.2 — Tue, 5 Apr 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    It appears a sentence was removed from superstructure but not InfrastructureLibarary.
    Revised Text:
    In section 11.3.5, subsection Constraints, change:
    [2] A specialization of a composite aggregation is also a composite aggregation.A multiplicity of a composite aggregation must not have an upper bound greater than 1.
    To:
    [2] A multiplicity of a composite aggregation must not have an upper bound greater than 1.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Activities

  • Key: UML22-107
  • Legacy Issue Number: 8731
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    In LoopNode, SetupPart/bodyPart should be setup/body to be consistent with Clause

  • Reported: UML 2.0 — Sun, 1 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Revised Text:
    This is covered in the resolution to Issue 8686.
    Disposition: Merged

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Clarify multiple inputs to expansion regions

  • Key: UML22-106
  • Legacy Issue Number: 8725
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Clarify multiple inputs to expansion regions. Clarify whether expansion regions with multiple input expansion nodes require all values to be present to start execution. If not, how is it indicated which are optional? ExpansionNodes do not have multiplicity.

  • Reported: UML 2.0 — Sun, 1 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    This issue is obsolete. The requested semantics for ExpansionRegions are now covered in UML 2.5 in Subclause
    16.12.3.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

DataStoreNode has uniqueness, reverse constraint inherited from ObjectNode

  • Key: UML22-105
  • Legacy Issue Number: 8724
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    DataStoreNode has uniqueness, reverse constraint inherited from ObjectNode

  • Reported: UML 2.0 — Sun, 1 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    An ObjectNode is not a MultiplicityElement, and, therefore, it can have no uniqueness constraint to reverse. (There actually is such a constraint given for ObjectNode, but this is an error that should be corrected. See Issue 8891.)
    Revised Text:
    None
    Disposition: Close, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Add constraints on conditional, loop, sequence to rule out node contents

  • Key: UML22-87
  • Legacy Issue Number: 8494
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Add constraints on conditional, loop, sequence to rule out node contents that are not in the sequence, or clause, setup/body part

  • Reported: UML 2.0 — Sun, 6 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Activities, LoopNode

  • Key: UML22-86
  • Legacy Issue Number: 8492
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    In LoopNode, setup, test, and body parts should be owned by the loop node (they were owned by clauses of loop node, which were owned by the loop node).

  • Reported: UML 2.0 — Sun, 6 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    The setup, test and body parts of a loop node should all identify nodes that are contained within the loop node. Such nodes are already owned by the loop node via the node association inherited from StructuredActivityNode. However, a constraint needs to be added to ensure this containment, and to ensure that any all executable nodes contained in the loop node are, indeed, in the setup, test or body parts.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

rewording isuse?

  • Key: UML22-96
  • Legacy Issue Number: 8687
  • Status: closed  
  • Source: FUNDP ( Pierre Yves Schobbens)
  • Summary:

    "When an execution of an activity makes a token available to the input of an expansion region, the expansion region consumes the token and begins execution." ``the input'' is ill-defined, since an expansion region has several inputs, see Examples in the same subsection. It should read: "When an execution of an activity makes a token available to each of the inputs of an expansion region (implicit join), the expansion region consumes these tokens and begins execution."

  • Reported: UML 1.4.2 — Tue, 5 Apr 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Resolution:
    This should be merged with Issue 8725.
    Revised Text:
    None
    Disposition: Duplicate/merged

  • Updated: Fri, 6 Mar 2015 20:58 GMT

reword sentence

  • Key: UML22-95
  • Legacy Issue Number: 8686
  • Status: closed  
  • Source: FUNDP ( Pierre Yves Schobbens)
  • Summary:

    " Any test section with a predecessorClause " Should be: " Any test section whose parent clause has a predecessorClause "

  • Reported: UML 1.4.2 — Tue, 5 Apr 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

A test cannot be empty

  • Key: UML22-94
  • Legacy Issue Number: 8682
  • Status: closed  
  • Source: FUNDP ( Pierre Yves Schobbens)
  • Summary:

    A test cannot be empty since it has at least a decider: 0..* should be changed to 1..*.

  • Reported: UML 1.4.2 — Tue, 5 Apr 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Misleading statement about multiplicity in AssociationClass

  • Key: UML22-104
  • Legacy Issue Number: 8722
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Misleading statement about multiplicity in AssociationClass. In the semantics of AssociationClass, the following is misleading: " Note: It should be noted that in an instance of an association class, there is only one instance of the associated classifiers at each end, i.e. from the instance point of view, the multiplicity of the associations ends are 1." The part after "i,e." is confusing, since it refers to multiplicity of association ends, which has a different meaning that intended above. I'd say just delete it.

  • Reported: UML 2.0 — Sun, 1 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Client/supplier on dependencies

  • Key: UML22-103
  • Legacy Issue Number: 8721
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Client/supplier on dependencies should specialize source/target inherited from directed relationship

  • Reported: UML 2.0 — Sun, 1 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Resolution:
    Duplicate of 6405.
    Revised Text:
    None.
    Disposition: Duplicate

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Constrain conditional node to have body pins if there is a result pin.

  • Key: UML22-88
  • Legacy Issue Number: 8498
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Constrain conditional node to have body pins if there is a result pin. Constrain to be of the same number and compatible types

  • Reported: UML 2.0 — Sun, 6 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Starting state machine

  • Key: UML22-2
  • Legacy Issue Number: 4932
  • Status: closed  
  • Source: Object Management Group ( Stephen Mellor)
  • Summary:

    [Steve Mellor] The action semantics has an action that starts a state
    machine. The state machine starts in some known initial (pseudo-)state.

    There are many cases where one wants to initialize a state
    machine so that starts in a specified (non-initial) state.

    Therefore the StartStateMachineAction needs to accept a state
    (possibly multi-leveled) as an input. The state machine will
    not execute any procedures or actions until after the state
    machine is in the target state and then detects an event.

  • Reported: UML 1.4 — Tue, 5 Mar 2002 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Disposition: Deferred to UML 2.4 RTF

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Starting a state machine

  • Key: UML22-3
  • Legacy Issue Number: 5107
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    Description:
    The State Machines chapter (Section 2.12) does not provide a clear description of what it means to "start" a state machine.

    Syntactically, we have the following:

    o Well-formedness rule [1] for Pseudostate (p. 2-157) says "An initial vertex [i.e., a initial pseudostate] can have at most one outgoing transition and no incoming transitions". Presumably, it is the single transition from the initial pseudostate at the top level that is taken when the state machine starts.

    o Well-formedness rule [6] for Transition (p. 2-160) says "An initial transition at the topmost level either has no trigger [i.e., event] or it has a trigger with the stereotype 'create'." Thus, the ONLY kind of event allowed on an initial transition is a "creation event".

    o The definition of the stereotype <<create>> is (p. 2-149):

    "Create is a stereotyped call event denoting that the instance receiving
    that event has just been created. For state machines, it triggers the
    initial transition at the topmost level of the state machine (and is the
    only kind of trigger that may be applied to an initial transition)."

    Thus, a "creation event" MUST be a call event.

    o However, well-formedness rule [5] for Transition (p. 2-160) states without qualification, that "Transitions outgoing pseudostates may not have a trigger"! This prohibits all together the "creation events" allowed by rule [6].

    Semantically, there is no specific discussion of how a state machine "starts". Section 2.12.4.3 describes "Entering a non-concurrent composite state" on p. 2-162 and "Entering a concurrent composite state" on p. 2-163. Since the top state of a state machine must be a composite state, one could assume that "starting" a state machine has the semantics of entering the composite top state. However, this does not provide an explanation of the "creation events" allowed (or at least seem intended to be allowed) in the special case of the initial transition at the top level.

    Now, well-formedness rule [5] of StateMachine says "If a StateMachine describes a behavioral feature, it contains no triggers of type CallEvent, apart from the trigger on the initial transition (see OCL for Transition [8])" (this is probably intended to refer to Transition rule [6]). Presumably, then, the call event on the initial transition is suppose to be the call event for the behavioral feature described by the state machine, at least in this case, but this is not described in the semantics (and it doesn't make sense for this event to be a "creation" event, anyway).

    This issue came out during the finalization of the Action Semantics. In the Action Semantics, when an object is created, any state machine associated with the object (via its classifiers) are NOT started automatically. Instead, there is an explicit "StartStateMachineAction" which is supposed to "start the execution of the state machines." However, it is not clear from the current state machine semantics what it really means to do this.

    Recommendation:

    1. Describe the "start" of the execution of a state machine as an RTC step from an implicit "not started" state (that is, not explicitly modeled in the state machine) to the target of the initial transition of the state machine (that is, the single transition with the top-level initial pseudo-state as its source). This RTC step includes the execution of any relevant transition actions and entry actions, per the usual state machine semantics.

    2. Define that, if no other explicit specification is given in a model, a state machine associated with a classifier is assumed to start when an instance of the classifier is created and a state machine associated with a behavioral feature is assumed to start when that feature is invoked. (When the action semantics is included, a formal specification of the start of a state machine can be given with the StartStateMachineAction.)

    3. Change well-formedness rule [5] to exclude the top initial pseudo-state.

    4. Change well-formedness rule [6] to allow, if the state machine describes a behavioral feature, a trigger (call event or signal event) on the initial transition that corresponds to that behavioral feature.

    5. If the state machine describes a classifier, then, in the absence of the action semantics, it is unclear whether a "creation event" is really useful at all (particularly since it would only allow for a single creation operation). With the action semantics, such an event is probably unnecessary, since the procedure for a creation operation will then be able to explicitly create an instance (using CreateObjectAction), start the state machine of that instance (using a StartStateMachineAction), which will get the state machine into a "real" state, and then send the instance a message (using an ExplicitInvocationAction), which can be handled by an event on the state machine, with any additional data required for initialization.

  • Reported: UML 1.4 — Thu, 4 Apr 2002 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Disposition: Deferred to UML 2.4 RTF

  • Updated: Fri, 6 Mar 2015 20:58 GMT

saying {nonunique} on one end of a binary association is meaningless

  • Key: UML22-5
  • Legacy Issue Number: 5977
  • Status: closed  
  • Source: Google ( Don Baisley)
  • Summary:

    Also, saying

    {nonunique}

    on one end of a binary association is
    meaningless by the current rules, because the other end remains

    {unique}

    by
    default, so no duplicate links would be allowed

  • Reported: UML 1.5 — Thu, 19 Jun 2003 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Also, saying

    {nonunique}

    on one end of a binary association is meaningless by the current rules, because the other
    end remains

    {unique}

    by default, so no duplicate links would be allowed
    Disposition: Merged with 6464

  • Updated: Fri, 6 Mar 2015 20:58 GMT

behaviour of the shallow history state and deep history state

  • Key: UML22-4
  • Legacy Issue Number: 5886
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    In the UML specification the behaviour of the shallow history state and deep history state are described (added below). The final state is seen as a real state in UML which can have entry actions and in which can be stayed. When a child composite state is in its final state and at a higher level a transition is taken to an other state and then to the deep history state we expect that the final state is set active again, instead that then default history state is made active. For example we have a composite state that does the setup of a piece of hardware and it is in the final state, but it doesn't leave the composite state because another condition is not true yet. When now the composite state is left at a higher level (for example emergency), then we go back according to the spec to the default history state, so we do the complete setup again, but we expect to return in the final state.

    Shallow history entry: If the transition terminates on a shallow history pseudostate, the active substate becomes the most recently active substate prior to this entry, unless the most recently active substate is the final state or if this is the first entry into this state. In the latter two cases, the default history state is entered. This is the substate that is target of the transition originating from the history pseudostate. (If no such transition is specified, the situation is illegal and its handling is not defined.) If the active substate determined by history is a composite state, then it proceeds with its default entry. • Deep history entry: The rule here is the same as for shallow history except that the rule is applied recursively to all levels in the active state configuration below this one.

  • Reported: UML 1.5 — Fri, 21 Mar 2003 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Disposition: Deferred to UML 2.4 RTF

  • Updated: Fri, 6 Mar 2015 20:58 GMT

On page 26, Figure 7.9

  • Key: UML22-173
  • Legacy Issue Number: 9233
  • Status: closed  
  • Source: LIANTIS GmbH ( Constantin Szallies)
  • Summary:

    On page 26, Figure 7.9 there an association between 'Property' and 'Classifier'. The end 'classifier' is non-navigable. 'classifier' subsets 'redefinitionContext'. This means the following constraint of 'Property' is violated: subsettedProperty->exists(sp | sp.isNavigable()) implies isNavigable())

  • Reported: UML 2.0 — Mon, 12 Dec 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    The noted Property constraint is no longer present in the UML 2.2 specification.
    Revised Text:
    None.
    Disposition: Closed No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

choice of terminolgy for TransitionKind is non-intuitive

  • Key: UML22-172
  • Legacy Issue Number: 9230
  • Status: closed  
  • Source: Parata Systems ( Mark Uebel)
  • Summary:

    The choice of terminolgy for TransitionKind is non-intuitive for many of us, and therefore leads to misuse. Specifically, one would expect the antonym pair "Internal" and "External" be applied to a conceptual pair such as "Exits the composite state" and "Does not exit the composite state". Instead the terms "External" and "Local" refer to these behaviors, respectively. Further, the term "Internal" is then used to describe a concept that has nothing to do with state transitions, but rather, is a reaction to a trigger. It appears to us that the transition and reaction concepts were generalized based on their members (trigger, guard, effect) and not on their behavior. We have found this approach to be a bad practice. Behavioral generalization is more intuitive, and therefore more appropriate. We suggest the following changes: "Internal implies that the transition, if triggered, will not exit the composite (source) state, but it will apply to any state within the composite state, and these will be exited and entered." "External implies that the transition, if triggered, will exit the composite (source) state." Move what is currently described as an "Internal Transition" to a separate concept named "Reaction".

  • Reported: UML 2.0 — Thu, 8 Dec 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    Although terminology is almost always contentious and a matter of taste, the submitter has a solid point that this
    particular case can be particularly confusing. However, it has been around since UML 2.0, and changing it at this
    point would likely lead to more confusion and have an impact existing implementations and texts. It seems better to
    leave it unchanged at this point.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 15.3.15

  • Key: UML22-171
  • Legacy Issue Number: 9172
  • Status: closed  
  • Source: Paranor AG ( Knut Wannheden)
  • Summary:

    Given the current wording in the Constraints, Semantics, and Notation sections the "external" and "local" transition kind only applies to transitions with composite states as the source. This does then not leave any transition kind, except "internal", over for transitions with simple states or pseudostates as the source. As I understand it the "external" transition kind should also be available for transitions with simple states and pseudostates as the source. Thus, I think the constraint [2] should be removed and the wording in the Semantics and Notation sections should be changed to make it clear that the "external" transition kind is not reserved for transitions with composite states as the source.

  • Reported: UML 2.0 — Tue, 15 Nov 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    External transitions should be available for all vertices except entry points. Local transitions should be allowed for either composite states or entry points. Internal transitions must source/target a composite state, where source=target.

    The semantics and notation will need to be updated to slightly to reflect this change.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 8.3.2 sub-section "Notation" starting on page 149

  • Key: UML22-170
  • Legacy Issue Number: 9141
  • Status: closed  
  • Source: Cutter Information ( Oliver Sims)
  • Summary:

    Issue:
    The use of the keyword <<component>> on all diagrams in this section is inconsistent with standards used elsewhere in the spec (for example the notation shown in the Interfaces package). When a shape has the small component icon showing, the keyword is not required and arguably should not be shown.

    Rationale:
    The diagrams imply that both the icon and the keyword should always be shown. This is of course not the case. As it is, some tools vendors not only accept this incorrect implication but some have also mistaken the keyword for a stereotype. It would be much clearer if the keyword were only shown on component boxes that did NOT have the plug icon in them.

    Note that the notation shown on Page 152 (first page of section 8.4) is "correct" - i.e. much more appropriate, and less likely to mislead. On the other hand that shown on page 153 is "incorrect".

  • Reported: UML 2.0 — Sat, 10 Sep 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    The classifier notation of a component is defined showing the keyword "component" and optionally the component icon in the upper right corner. All examples in the component chapter of the UML 2.2. (ptc/2008-05-05) show the component with keyword and icon. However table 8.1 shows a component with an icon and without the keyword. This presentation option must be added to the component definition.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

inconsistency wrt UML2 classifier behavior

  • Key: UML22-169
  • Legacy Issue Number: 9138
  • Status: closed  
  • Source: Capability Measurement ( Karl Frank)
  • Summary:

    Figure 13.6 - Common Behavior (page 412 of formal/05-07-04) shows BehavioredClassifier's ownedBehavior as a composition (black diamond) and it shows classifierBehavior as a directed association (no diamond).

    no problem so far.

    But then the figure also shows classifierBehavior subsets ownedBehavior, and the text says (page 420, section 13.3.4 BehavioredClassifer|Associations) that classifierBehavior specializes BehavioredClassifier.ownedBehavior).

    If classifierBehavior is a specialization and the set of its instances is a subset, then the metaassociation denoting classifierBehavior should have the same association type as the superset, in other words for conssitency, both or neither should be black diamond.

    My assumption here is a form of the covariance thesis, a subset and specialization of a composition must also be a composition.

  • Reported: UML 2.0 — Wed, 2 Nov 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    In the UML 2.2 Specification, Behaviored::classifierBehavior is no longer specified in the text as "specializes BehavioredClassifier.ownedBehavior". Instead, it simply notes "subsets BehavioredClassifier::ownedBehavior", which is consistent with the diagram.
    The subset classifierBehavior association doesn't need to be composite, because it implies the superset ownedBehavior one (for the same behavior instance), which is composite, so composite semantics will apply anyway. Deleting an M1 classifier instance will delete the M1 behavior instance linked by the subset association, because that M1 classifier is also linked by the superset composite association.
    Revised Text:
    None.
    Disposition: Closed No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

keyword, "buildcomponent", and a stereotype, "buildComponent"

  • Key: UML22-168
  • Legacy Issue Number: 9125
  • Status: closed  
  • Source: Profound Rational Organization ( Pae Choi)
  • Summary:

    A keyword, "buildcomponent", and a stereotype, "buildComponent", are
    listed in Annex B, "UML Keywords" and Annex C, "Standard Stereotypes",
    but not consistent. The letters, 'c' of the "buildcomponent" keyword and
    'C' of the "buildComponent."

    Also, there are stereotypes mentioned throughout the document such as:

    o decisionInput
    o multireceive
    o parallel
    o iterative
    o stream

    but not listed in the Annex C, Standard Stereotypes. The stereotypes
    mentioned above may not reflect the entire document.

  • Reported: UML 2.0 — Mon, 31 Oct 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Merged with 18454

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Element and Comment in Basic

  • Key: UML22-182
  • Legacy Issue Number: 9246
  • Status: closed  
  • Source: Capgemini ( Anneke Kleppe)
  • Summary:

    The definition of the classes Element and Comment in the Basic package is ambiguous. The Basic package
    imports Abstractions::Elements::Element and Abstractions::Comments::Comment. An inheritance
    relationship and an Association called ownedComment is introduced between Element and Comment in the
    package Basic. However, these relationships were already defined for these classes in the package
    Abstractions (see the top two diagrams in Figure 4). Therefore, the complete model of Element and
    Comment in the Basic package is the model shown in Figure 4, clearly showing a redundant association
    called ownedComment, and a redundant inheritance relationship between Abstractions::Elements::Element
    and Comment.
    Abstractions
    Element
    (from Elements)
    Element
    (from Comments)
    Comment
    (from Comments)
    Element
    (from Ownerships)
    +owningElement
    0..1

    {subsets owner}
    ownedComment
    * {subsets ownedElement}
    annotatedElement
    *
    Basic (after import abstractions)
    Element
    (from Comments)
    Element
    (from Ownerships)
    Element
    (from Elements)
    Comment
    (from Comments)
    +owningElement
    0..1{subsets owner}

    annotatedElement
    *
    0..1
    ownedComment
    *

    {subsets ownedElement}

    +ownedComment
    0..n
    Basic
    Comment
    (from Comments)
    Element
    (from Elements)
    +ownedComment
    0..n
    0..1
    <<import>>
    <<import>>
    Figure 4

  • Reported: UML 2.0 — Wed, 18 Jan 2006 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Description of Element

  • Key: UML22-181
  • Legacy Issue Number: 9245
  • Status: closed  
  • Source: Capgemini ( Anneke Kleppe)
  • Summary:

    The infrastructure specification [1] described the metaclass Element as followes:
    “Element is an abstract metaclass with no superclass. It is used as the common superclass for all
    metaclasses in the infrastructure library.” [1, page 45 and page 93]
    Both packages, Abstraction and Basic, are using the same definition for Element. Therefore, it is logical to
    assume that both packages will contain their own class Element, as shown in Figure 2.
    InfrastructureLibrary
    Abstractions Basic
    Element Element
    Figure 2
    The Rose Model [2] specifies one single class Element, a metaclass that is part of Abstractions. The exact
    name is Abstractions::Elements::Element. The Basic package imports this metaclass. (see Figure 3). We
    assume this is the correct interpretation, therefore the text on page 93 should be changed accordingly.
    InfrastructureLibrary
    Basic
    Abstractions
    Element
    (from Elements)
    <<import>>
    Figure 3

  • Reported: UML 2.0 — Wed, 18 Jan 2006 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Unclear relationship between the Basic and Abstractions packages

  • Key: UML22-180
  • Legacy Issue Number: 9244
  • Status: closed  
  • Source: Capgemini ( Anneke Kleppe)
  • Summary:

    1) According to the infrastructure specification [1] the Basic package is using metaclasses from the
    Abstractions package, as indicated by the following text.
    “Basic also contains metaclasses derived from shared metaclasses defined in packages contained in
    Abstractions. These shared metaclasses are included in Basic by copy.”[1 page 91]
    First, the mentioned copy construction is not defined in the infrastructure. Second, in contrary to the copy
    definition, the Rose Model [2] of the infrastructure defines the deriving of metaclasses as import on the
    package Abstractions::Elements and Abstractions::Multiplicity. (see Figure 1)
    2) Furthermore, the infrastructure specification described the reuse of the package Abstractions::Comments
    as followes.
    “Basic::Comment reuses the definition of Comment from Abstractions::Comments.” [1 page 92]
    The Rose Model [2] does not contain this import.
    Abstractions
    Elements
    Comments
    Ownerships
    <<import>>
    <<import>>
    Multiplicities
    <<import>>
    Basic
    <<import>>
    <<import>>
    Figure 1
    3) The infrastructure specification described the Basic::MultiplicityElement as the reuse of
    Abstractions::MultiplicityElement:
    “Basic::MultiplicityElement reuses the definition from Abstractions::MultiplicityElement”[1 page 97]
    The Abstractions package does not contain an Abstractions::MultiplicityElement. Instead of, the
    Abstractions package does contain an Abstractions::Multiplicities::MultiplicityElement and an
    Abstractions::MultiplicityExpressions::MultiplicityElement. Owing to the import of
    Abstractions::Multiplicities the Abstractions::MultiplicityElement

  • Reported: UML 2.0 — Wed, 18 Jan 2006 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

XMI file: Core::Constructs::Operation::bodyCondition should have upper boun

  • Key: UML22-179
  • Legacy Issue Number: 9243
  • Status: closed  
  • Source: Fulcrum Analytics, Inc. ( Richard Vermillion)
  • Summary:

    In the XMI file sent out with Ballot 12, the bodyCondition attribute
    of Core::Constructs::Operation has upper="*" when it should be
    upper="1".

    See line 3009 of Infrastructure.cmof:

    <ownedAttribute xmi:type="cmof:Property" xmi:id="Core- Constructs-Operation-bodyCondition" name="bodyCondition" lower="0"
    upper="*" type="Core-Constructs-Constraint" association="Core- Constructs-A_bodyCondition_bodyContext" subsettedProperty="Core- Constructs-Namespace-ownedRule" isComposite="true"/>

    In Superstructure, Classes::Kernel::Operation seems to correctly have
    an upper bound of 1 for bodyCondition.

    Again, apologies for the late notice on this issues. If there is a
    better way to report these, please let me know. I'm sending them to
    the list because I assume some can be made as editorial changes by
    Bran, while others should be opened as new issues for UML 2.2.

  • Reported: UML 2.0 — Mon, 16 Jan 2006 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Infra::Core::Constructs::Operation::bodyCondition : Constraint[0..1] in UML 2.2 CMOF.
    Revised Text:
    None.
    Disposition: Closed No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

/qualifiedName attribute missing on Core::Constructs::NamedElement

  • Key: UML22-178
  • Legacy Issue Number: 9242
  • Status: closed  
  • Source: Fulcrum Analytics, Inc. ( Richard Vermillion)
  • Summary:

    In the Infrastructure.cmof file distributed as part of ballot 12, the
    Core::Constructs::NamedElement class is missing the qualifiedName
    derived property. The operation qualifiedName() exists, but the
    corresponding derived attribute is missing.

    Core::Abstractions::Namespaces::NamedElement does correctly include
    the qualifiedName derived property and all of the OCL constraints in
    Constructs correctly references a qualifiedName attribute (rather
    than the operation).

    Presumably this is an error in the metamodel.

  • Reported: UML 2.0 — Mon, 16 Jan 2006 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Operation::ownedParameter should be ordered in XMI?

  • Key: UML22-177
  • Legacy Issue Number: 9241
  • Status: closed  
  • Source: Fulcrum Analytics, Inc. ( Richard Vermillion)
  • Summary:

    In the latest XMI file (included as part of Ballot 12) the
    ownedParameter attribute of Core::Constructs::Operation redefines
    Core::Constructs::BehavioralFeature::ownedParameter – I'm assuming
    that this redefinition is a result of the merge of Basic.

    However, in Operation, the ownedParameter attribute is not ordered.

    Since both BehavioralFeature::ownedParameter and
    Core::Basic::Operation::ownedParameter are ordered, it seems strange
    for Core::Constructs::Operation's not to be ordered. A check of the
    drafts and ballots does not seem to address this issue or explain why
    it would be the case. Is it a mistake?

  • Reported: UML 2.0 — Sun, 15 Jan 2006 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Infra::Core::

    {Basic,Constructs}

    ::Operation::ownedParameter

    {isOrdered=true}

    in UML 2.2 CMOF.
    Revised Text:
    None.
    Disposition: Closed No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Classes

  • Key: UML22-176
  • Legacy Issue Number: 9237
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Can an instance specification for a classifier specify instances of subtypes of the classifier? For example, if Fido is an instance specification for Class Dog, can the runtime object it specifies be an instance of Terrier?

  • Reported: UML 2.0 — Mon, 2 Jan 2006 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    An InstanceSpecification can be partial. The spec is quite clear about this. It is also clear that every slot
    must correspond to a feature of one of the classifiers. If the InstanceSpecification is classified as a Dog, it
    might be a Terrier at runtime but you have no way to know that. Insert some text to make this clear.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

constraints owned by these properties have no context

  • Key: UML22-175
  • Legacy Issue Number: 9236
  • Status: closed  
  • Source: Anonymous
  • Summary:

    A similar issue exists with ParameterSet::condition, State::stateInvariant, Extend::condition, Action::localPrecondition, Action::localPostcondition, StateInvariant::invariant, i.e. constraints owned by these properties have no context. This raises the question of whether a constraint must always have a context (note that some of these owners are not namespaces)...

  • Reported: UML 2.0 — Thu, 22 Dec 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    As shown in Figure 7.13 in the UML 2.5 specification, the context of a Constraint is optional. Constraints that are
    required to be owned in some way other than using the context/ownedRule association do not have a context.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Operation should be a specialization of TypedElement and MultiplicityElemen

  • Key: UML22-174
  • Legacy Issue Number: 9234
  • Status: closed  
  • Source: Eclipse Foundation ( Mr. Kenneth Hussey)
  • Summary:

    Operation should be a specialization of TypedElement and MultiplicityElement. Currently it is in InfrastructureLibrary::Core::Basic (L0), but isn't in other packages (LM - L3).

  • Reported: UML 2.0 — Wed, 14 Dec 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

section, 12.3.27 ExpansionRegion(from ExtarStructureActivities

  • Key: UML22-167
  • Legacy Issue Number: 9120
  • Status: closed  
  • Source: Profound Rational Organization ( Pae Choi)
  • Summary:

    Under the section, "12.3.27 ExpansionRegion(from ExtarStructureActivities)", it states as

    Attributes

    • mode : ExpansionKind - The way in which the executions interact:

    parallel - all interactions are independent.

    iterative - the interactions occur in order of the elements.

    stream - a stream of values flows into a single execution.

    Notation

    An expansion region is shown as a dashed rounded box with one of the keywords parallel, iterative, or streaming in the

    upper left corner.

    However, in "Figure 12.87 Expansion region" the keyword used is <<concurrent>>. Could you
    please verify this and let me know. Thank you.

  • Reported: UML 2.0 — Tue, 11 Oct 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

(merged) compliance levels L2 and L3

  • Key: UML22-166
  • Legacy Issue Number: 9102
  • Status: closed  
  • Source: Eclipse Foundation ( Mr. Kenneth Hussey)
  • Summary:

    In (merged) compliance levels L2 and L3, derived union property ActivityGroup::subgroup has no subsets.

    -> Rename ActivityPartition::subgroup to subpartition, replace

    {redefines subgroup}

    with

    {subsets subgroup}

    . Also add properties to StructuredActivityNode and InterruptibleActivityRegion that subset ActivityGroup::subgroup?

  • Reported: UML 2.0 — Wed, 19 Oct 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    This issue is obsolete. UML 2.5 no longer defines compliance levels using a merged package structure. Further,
    the suggested change to ActivityPartition::subgroup has already been made. StructuredActivityNodes and InterruptibleAtivityRegions
    do not have subgroups.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

(merged) compliance level L1

  • Key: UML22-165
  • Legacy Issue Number: 9101
  • Status: closed  
  • Source: Eclipse Foundation ( Mr. Kenneth Hussey)
  • Summary:

    In (merged) compliance level L1, derived union properties ActivityNode::inGroup, ActivityEdge::inGroup, ActivityGroup::subgroup, ActivityGroup::superGroup and have no subsets. Note that ActivityGroup, an abstract metaclass, has no concrete subclasses.

    -> Should ActivityGroup not be originally defined in BasicActivities (nor in Fundamental Activities), but perhaps in IntermediateActivities?

  • Reported: UML 2.0 — Wed, 19 Oct 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    This issue is obsolete. UML 2.5 no longer defines compliance levels using a merged package structure.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 14.3.20 Message (from BasicInteractions)

  • Key: UML22-164
  • Legacy Issue Number: 9081
  • Status: closed  
  • Source: Edin Pezerovic ( Edin Pezerovic)
  • Summary:

    in 14.3.20 Message (from BasicInteractions) is described: "Object creation Message has a dashed line with an open arrow." the referenced example 14.11 on page 458 shows an object creation Message with a solid line and an open arrow.

  • Reported: UML 2.0 — Mon, 17 Oct 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion:
    The figure is all right, but dashed lines are sometimes printed as solid lines. The illustrations use Visio and sometimes the dashed lines are not easily distinguished.
    Disposition: ClosedNoChange

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Activities

  • Key: UML22-163
  • Legacy Issue Number: 9078
  • Status: closed  
  • Source: juno.com ( Pae Choi)
  • Summary:

    In Activities, ExpansionRegion, Notation, first sentence, replace "stream" with "streaming".

  • Reported: UML 2.0 — Fri, 14 Oct 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    The sentence already has "streaming" (and has since UML 2.0). However, the literal in ExpansionKind is "stream", so perhaps the submitter intended to suggest replacing "streaming" by "stream". This would be consistent with using the literals from EnumerationKind for "parallel" and "iterative".

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Issue: Qualified pathnames

  • Key: UML22-22
  • Legacy Issue Number: 6466
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    PROBLEM STATEMENT
    The notation for qualified names is double-colon ('::'). However, the Spec
    always and everywhere uses a different notation: instead of
    "Kernel::Comment", "Comment (from Kernel)".

    PROPOSED SOLUTION
    Use the standard notation for qualified names.

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

show object flow or interactions

  • Key: UML22-35
  • Legacy Issue Number: 7166
  • Status: closed  
  • Source: Boeing ( David Hickerson)
  • Summary:

    There needs to be a way to show object flow or interactions between multiply concurrent threads or processes in Activity Diagrams. Example: In TCP sockets, the interaction between a client and server should be able to be shown with two separate start points, one for the client and one for the server. The connection sequence and packet flow should be able to be shown. With a single start point, the diagrams imply that one action starts both processes. I would like to illustrate multiple concurrent threads or processes and their interactions in an Activity Diagram and be able to distinguish between the flowing threads. I would also like to show access to objects shared by the threads or processes.

  • Reported: UML 1.5 — Fri, 19 Mar 2004 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    This issue has already been discussed in previous F/RTFs and considered out of scope:
    FTF: Activity diagrams only show task dependency, which can be achieved by multiple implemented processes. An activity can have more than one initial node. These are all started when the activity is. The initial nodes can be used in separate partitions to indicate which actions are taken on the client and server. If the two processes are completely independent, then this is a request is for a hybrid diagram, especially when trying to show shared objects. This is too much for an FTF to address.
    RTF: Hybrid diagrams are too complicated a topic for an RTF to address. There are many combinations and not enough experience to choose among them.
    Revised Text:
    None
    Disposition: Closed Out of Scope

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/Interactions/Need constraints that cover multiple Lifelines

  • Key: UML22-34
  • Legacy Issue Number: 7161
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Consider an Interaction that describes collaboration of several parts of a classifier that owns some attributes.
    None of the parts own this attribute. I need to be able to describe a constraint, involving these attributes.

    Or when the overall classifier has a State Machine describing its overall behavior, and we want to refer to these states in an Interaction.

    In order to achieve this, it would be desirable to use:
    1. A guard that covers more than one lifeline (represents a guard involving the attributes, "global" to the set of Lifelines)
    2. A state symbol that covers more than one lifeline (represents a state invariant refering to the state of some state machine "global" to the set of Lifelines)
    3. A state invariant covering more than one lifeline (represents an invariant involving the attributes, "global" to the set of Lifelines)

  • Reported: UML 1.5 — Mon, 15 Mar 2004 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion:
    Although this is a reasonable feature to request, it is an enhancement that exceeds the scope of the RTF. One of the main issues with it is that the semantics of defining such constraints in a distributed environment are not simple and require some serious consideration. The issue here is that Interactions consider all lifelines as potentially concurrent, and the restrictions on guards reflect this to prevent specifying distributed decisions that would imply implicit synchronization. The fact is, however, that many systems are such that it is known that the lifelines are not concurrent and checking remotely or on enclosing objects is not really hazardous. The problem is that we do not have a good way to define this in the specification. This is of course not dependent upon Interactions, but is a feature of all of UML. There seems to be a need to define object groups that share the same "thread" and are only pseudo-concurrent. If we had had such a construct, the guard could cover any subset of such a "same-thread-set-of-objects".
    Disposition: Closed Out Of Scope

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ptc-03-09-15/Separate classification and generalization in Core::Basic

  • Key: UML22-24
  • Legacy Issue Number: 6495
  • Status: closed  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    Issue: One of the main requirements for a core that can be reused by CWM
    hinges on whether it is possible to reuse the abstract syntax that supports
    classification and supports having properties (or features), without pulling
    in generalization constructs. U2P’s Core::Basic package, upon which EMOF is
    based, does not appear to adequately separate these concerns.

    The most abstract level of Core::Basic's inheritance hierarchy at which the
    ability to have properties appears is in the Class metaclass. But Class
    also carries the “baggage” of a definition of superclass.

    The Core::Abstractions package does appear to adequately separate these
    concerns. It does so by defining a simple Classifier in the
    Core::Abstractions::Classifiers package that supports features but not
    generalization. The Core::Abstractions::Super package defines another
    Classifier metaclass that subclasses
    Core::Abstractions::Classifiers::Classifier and adds support for
    generalization.

    Presumably, then, the intent is that CWM metamodels that support
    classification and properties but not generalization can reuse
    Core::Abstractions::Classifiers::Classifier. However, Core::Basic does not
    reuse either of these basic definitions of Classifier from
    Core::Abstractions, and EMOF is based on Core::Basic. Thus, if a CWM
    metamodel reuses Core::Abstractions::Classifiers::Classifier, it will not
    share a common definition of Classifier with EMOF. That could mean that a
    metamodel expressed solely via EMOF will not be able to be the source or
    target in a unified approach to transformations. This is not a problem for
    CMOF, though, because CMOF is based on Core::Constructs, whose Classifiers
    are based on Core::Abstractions.

    Recommendation: Solving the problem for EMOF would require some refactoring
    of Core::Basic to separate concerns between classification and
    generalization.

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ports in Protocol State Machines

  • Key: UML22-23
  • Legacy Issue Number: 6489
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Protocol machines should not have ports in them. It should be an
    extension in the ports package. Otherwise there is a backwards
    dependency onto composite structure.

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    Statemachines already depend on ports via triggers, so the proposed change will not remove the dependency.
    Furthermore, creating a dependency from composite structures to statemachines would create a more serious
    layering problem. Therefore, resolving this dependency requires a non-trivial restructuring that shall be done
    by an RTF at this point.
    UML 2.5 has a different modular structure than UML 2.4 and earlier versions, with a single-level “flat”
    structure in which inter-module dependency concerns, which are at the core of this issue, are no longer
    relevant.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

StateMachine - Constraints

  • Key: UML22-33
  • Legacy Issue Number: 7051
  • Status: closed  
  • Source: PostFinance ( Karl Guggisberg)
  • Summary:

    "[1] The classifier context of a state machine cannot be an interface"

    should be:

    [1] The context classifier of a state machine cannot be an interface. not redefinitionContext.oclIsKindOf(Interface)

    "[2] The context classifier of the method state machine of a behavioral feature must be the classifier that owns the behavioral feature."

    should be:

    [2] The context classifier of the method state machine of a behavioral feature must be one of the classifier that features the behavioral feature

    – note that a behavorial feature can be associated with 1..* – classifiers if self.specification->notEmpty() then self.specification.featuringClassifier->includes(redefinitionContext) endif

    "[3] The connection points of a state machine are pseudostates of kind entry point or exit point."

    should be:

    [3] The connection points of a state machine are pseudostates of kind entry point or exit point. connectionPoint->forAll(cp | cp.kind = #entryPoint or cp.kind = #exitPoint )

    "[4] A state machine as the method for a behavioral feature cannot have entry/exit connection points."

    should be:

    [4] A state machine as the method for a behavioral feature cannot have entry/exit connection points. self.specification->notEmpty() implies ( self.connectionPoint->forAll(cp | not (cp.kind = #entryPoint or cp.kind = #exitPoint) ) )

  • Reported: UML 2.0 — Sun, 29 Feb 2004 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    In UML 2.5, all of the above have been rewritten and corresponding OCL inserted.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

transtion

  • Key: UML22-32
  • Legacy Issue Number: 6991
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Sebastien Gerard)
  • Summary:

    Issue 2: In the same spirit, we would like also to specifiy that a transtion is fired

    only if an event is not available at a given instant. We need the concepts of instant

    and event absence. Note that the absence combined with "and" and "or" can express kinds of

    priorities (e.g., "a and not b").

  • Reported: UML 2.0 — Tue, 17 Feb 2004 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Triggering a transition with the absence of an event seems to make sense only under a synchronous semantics which defines slices of time where that event might occur or not. It require a major modification or enhancement to the current, asynchronous Run-To-Completion semantics, where events are handled one by one in a timeless sequence. This therefore needs to be postponed to a more major revision, when we will have time to investigate this proposal and see if and how it can be accommodated.

    Revised Text:
    N/A

    Disposition: Closed, out of scope

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML2 Super/Kernel Classes

  • Key: UML22-27
  • Legacy Issue Number: 6681
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    section 7.11 Does Property.aggregation have meaning for properties typed by
    value types, (Data Type and subtypes)?

  • Reported: UML 1.5 — Mon, 8 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    The spec now says under the semantics of Property “The semantics of composite aggregation when the
    container or part is typed by a DataType are intentionally not specified.”
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML Superstructure FTF : isRoot property disappeared

  • Key: UML22-26
  • Legacy Issue Number: 6616
  • Status: closed  
  • Source: gmail.com ( Guus Ramackers)
  • Summary:

    The property isRoot has disappeared from Classifier. INtention was to move it to RedefinableElement but it seems to have dropped through the cracks.

    On page 399 FAS: section 13.3.4

    The metaattributes isLeaf and isRoot have been replaced by properties inherited from RedefinableElement.

    On page 86 FAS section 7.8.3 RedefinableElement:

    isLeaf: Boolean Indicates whether it is possible to further specialize a RedefinableElement. If the value is
    true, then it is not possible to further specialize the RedefinableElement. Default value is
    false.

    But no mention of isRoot....

  • Reported: UML 1.5 — Fri, 14 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Inheritance of 'Enumerations' is not detailed

  • Key: UML22-30
  • Legacy Issue Number: 6921
  • Status: closed  
  • Source: Fraunhofer FOKUS, Germany ( Michael Soden)
  • Summary:

    Inheritance of 'Enumerations' is not detailed with repsect to their (ordered) owned 'EnumerationLiteral's.

    Proposed resolution: Add a constraint to restrict Enumerations to be unable to inherit from each other (at least favored in MOF) or specify how Literals are ordered.

  • Reported: UML 2.0 — Mon, 19 Jan 2004 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    The issue is obsolete. The spec defines what generalization means for Enumerations.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Part subtype

  • Key: UML22-29
  • Legacy Issue Number: 6866
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Would be useful to be able to assign a subtype for objects that fill a
    part, to add additional characteristics. For example, a person fills
    the Employee part of a company, and is reclassified under a subtype of
    person that has an office. It is not sufficient to use the subtype as
    the type of the part, because the model wouldn't record what objects are
    allowed to fill the parts. The object is reclassified under the subtype
    after filling the part.

  • Reported: UML 1.5 — Wed, 5 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    The issue suggests a new feature of UML. This is strategic and outside the scope of the RTF.

    Revised Text:
    None.

    Disposition: Closed, out of scope

  • Updated: Fri, 6 Mar 2015 20:58 GMT

manage simultaneity of events

  • Key: UML22-31
  • Legacy Issue Number: 6990
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Sebastien Gerard)
  • Summary:

    Issue 1: to have the possibility to manage simultaneity of events, and be able to

    trigger a transition by a condition on several events. By this way, the triggering

    condition of a transition may be specified through an event formula such as: (e1 and e2) or e3

    This point we then involve to relax a constraint on the semantics of RTC and to introduce then

    the possiblity to dequeue several events of the queue at the same time. May it be just an

    additional open variation semantics point?

  • Reported: UML 2.0 — Tue, 17 Feb 2004 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Simultaneous events and transitions triggered by a logical combination of events require a major modification or enhancement to the current Run-To-Completion semantics, where events are handled one at a time. This therefore needs to be postponed to a more major revision, when we will have time to investigate this proposal and see if and how it can be accommodated.

    Revised Text:
    N/A

    Disposition: Closed, out of scope

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Federated models - UML2 issue

  • Key: UML22-25
  • Legacy Issue Number: 6500
  • Status: closed  
  • Source: Pivot Point ( Cris Kobryn)
  • Summary:

    When creating a complete environment for agreements and BCF we need
    to
    work with ModelElements, classes, package, models etc created and
    managed by many unrelated person and organisations. This means that
    we
    need to support loosely coupled models (federated models) where an
    association starts in one model (stored in doc A) and ends in another
    model (stored in document B).

    This may mean that we need to add references to an external
    modelelement
    so the assoication that references "out" to external ME need to be
    annotated with for example UUID of remote modelelement, name of model
    where the remote/external model , physicial location of remote model
    (URL) etc.
    We may also want to attach constraints to the remote modelement that
    restricts "incomming" associations.

    The question is how are loosely coupled model handled in UML 2 ?

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    closed no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2.0 Kernel Operations Diagram and Features Diagram and mdl

  • Key: UML22-28
  • Legacy Issue Number: 6700
  • Status: closed  
  • Source: TimeWarp Engineering Ltd. ( Steven Cramer)
  • Summary:

    The operations diagram redefines the formalParameter Property and removes the

    {ordered subsets parameter subsets ownedMember}

    .

    The mdl file has an added associtation between Operation: ownedparameter and Parameter:operation that isn’t defined in the spec.

    I believe the intent was to specialize the property Parameter:operation but I do not find the Operation:formalParameter Parameter:operation association required at all and would recommend its removal.

    This would require the ownerformalParam be made navigable. But I feel that this change is already required to sync the OCL and Superstructure specs.

    An alternative would be to add a unidirectional derived Property to the Parameter Class named operation and the derivation simply being operation=ownerFormalParam

  • Reported: UML 1.5 — Tue, 16 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No longer applicable closed no chnage

  • Updated: Fri, 6 Mar 2015 20:58 GMT

External exceptions.

  • Key: UML22-112
  • Legacy Issue Number: 8750
  • Status: closed  
  • Source: International Business Machines ( James Rumbaugh)
  • Summary:

    External exceptions. We need an interrupt message that asynchonously causes an exception for some other process/object. In examining real-world examples at IBM, I find we need that concept. And we need interrupts that allow the target process to clean itself up, not just die. This occurs in lots of real problems

  • Reported: UML 2.0 — Sun, 1 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    This can already be handled, at least for an asynchronously executing activity or state machine, by sending a signal to the behavior. A concurrent part of the activity or state machine can then receive the signal and interrupt the ongoing behavior, transitioning, if necessary, to some clean up behavior before terminating. In an activity this can be done using an interruptible region. In a state machine it can be used with a orthogonal region.
    Revised Text:
    None.
    Disposition: Closed No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Clarify which classifier or operation this is referring to

  • Key: UML22-111
  • Legacy Issue Number: 8743
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    CollaborationUse, Constraint 2: Clarify which classifier or operation this is referring to.

  • Reported: UML 2.0 — Sun, 1 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    There are several places in chapter 9 where the text refers to the possibility of a CollaborationUse being associated with an Operation. But there is nothing in the metamodel to support this. This issue is resolved by removing these statements from the text, and by clarifying the offending constraint.
    In 9.3.3, there is a paragraph that reads as follows:
    "A collaboration may be attached to an operation or a classifier through a CollaborationUse. A collaboration used in this way describes how this operation or this classifier is realized by a set of cooperating instances. The connectors defined within the collaboration specify links between the instances when they perform the behavior specified in the classifier. The collaboration specifies the context in which behavior is performed. Such a collaboration may constrain the set of valid interactions that may occur between the instances that are connected by a link."
    The placement of this paragraph is peculiar, because it appears under Collaboration, not CollaborationUse. The first two sentences of this paragraph are false, because they talk about attaching a CollaborationUse to an operation. The remainder of the paragraph appears to add no value to what has been already stated in the semantics of Collaboration. I propose to delete this paragraph.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

represents and occurrence keywords are switched

  • Key: UML22-110
  • Legacy Issue Number: 8742
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    CollaborationUse, Presentation Options, first paragraph, the represents and occurrence keywords are switched

  • Reported: UML 2.0 — Sun, 1 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    This does not appear in 2.2.

    Revised Text:
    None.

    Disposition: Closed, no change.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Events in Sequence diagram

  • Key: UML22-114
  • Legacy Issue Number: 8760
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    MessageEnd are MessageOccurrenceSpecification that redefines "event"
    > as MessageEvent.
    > DestructionEvent and CreationEvent are not subclasses of
    > MessageEvent, so can't be on message end, so how to map "create
    > message" and "destroy message"?

    This is an open item. The one thing that was highly contested in the FTF was that there be explicit create and destroy messages. So, they are no longer in MessageKind.

    > Also unclear how to map Reply
    > message, what kind of events should be in reply message ends?

    You should check with Oystein.

    > Events are owned by package, it's very uncomfortable (at least two
    > nesting levels from Interaction), it think they should be owned by
    > Interaction.

    No, because the whole idea of events is that they have to be shared by the sender's and reciever's behaviors. It makes little sense to define them in an Interaction.

  • Reported: UML 1.4.2 — Tue, 3 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    See issue 14629 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

1. Deployment

  • Key: UML22-113
  • Legacy Issue Number: 8757
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    1. Deployment
    > What is client and what is supplier for this relationship?
    > Why DeploymentTARGET has word "target" in name but subsets "source"
    > for Dependency?

    The meaning of "client" and "supplier" in Dependency is pretty arbitrary and depends on one's point of view. I don't recall the reasoning behind this particular choice, but it may have to do with the direction of the arrow more than anything else. Guus probably wanted the arrow to go from the artifact to the node because it looked more natural to him. Perhaps Guus can explain – I've copied him on this reply.

    However, there is definitely a bug here since "client" and "supplier" are not derived unions, hence, they cannot be subset as shown in figure 126. This may have already been raised as an issue. I'll have to check. I suggest that you raise a formal issue in any case.

    > And why notation examples are from Artifact to Node (arrow near
    > Node, but Node is "client" in model).

    Ostensibly, this is explained by what I wrote above. However, there seems to be a deeper problem here: note that Dependency::supplier and Dependency::client are not specializations of DirectedRelationship::target and DirectedRelationship::source respectively, as I would have expected (otherwise it does not seem to make sense to subclass DirectedRelationship at all). I do not understand why this is so, it does not seem to make sense. It may have to do with the constraints that Dependency did not want to impose on supplier and client, but I am not sure. This needs further study and, likely, an issue to be raised.

    > "Location" attribute of Deployment should be DeploymentTarget, not Node.

    You are correct. Please raise an official issue on this through issues@omg.org

  • Reported: UML 1.4.2 — Tue, 3 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Questions about the appropriateness of the use of Dependency and the directionality of theway its ends are connected
    are covered by other issues, such as 10781. In any case, such changes require modifications to the metamodel and are
    thereby out of scope for the UML 2.5 FTF.
    There no requirement that client and supplier must be, or must subset, derived unions. In Clause 19.5, the location
    attribute of Deployment is clearly identified as type DeploymentTarget.
    Disposition: Merged with 10781

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Action/Activity

  • Key: UML22-116
  • Legacy Issue Number: 8771
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    In the actions and activities chapters default values for attributes that are typed by ValueSpecifications use primitives for the default value. For example: 12.3.5 ActivityEdge, p. 352 Attribute weight has default value "1". Is that correct? What if the ValueSpecification is not computable or the value isn't typed by an Integer?

  • Reported: UML 2.0 — Mon, 9 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Yes, this is correct. ValueSpecifications are used in these cases, because it is often desirable for the given value to be specified in the model as computed.
    The default values are to be interpreted as the corresponding LiteralValue for the given value (e.g., a LiteralUnlimitedNatural, in the case of weight). The type of value to which such a ValueSpecification must evaluate (e.g., UnlimitedNatural for weight) is given in the semantics for the construct. If the ValueSpecification is not computable or evaluates to a value of the incorrect type, then the model is ill-formed and has no meaning.
    Revised Text:
    None.
    Disposition: Closed, no change.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Nested Nodes

  • Key: UML22-115
  • Legacy Issue Number: 8763
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    Node has nestedNodes collection that redefines "nestedClassifier",
    > but Node have Generalizations to Class from StructuredClasses that
    > has no Generalization to Class from Core package, so Nodes don't
    > inherits "nestedClassifier".

  • Reported: UML 1.4.2 — Tue, 3 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Input tokens to LoopNodes should be destroyed when the loop is done

  • Key: UML22-119
  • Legacy Issue Number: 8780
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Input tokens to LoopNodes should be destroyed when the loop is done

  • Reported: UML 2.0 — Sun, 15 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    This issue is obsolete. This is covered by the current semantics for loopVariableInputs, which are the only InputPins a
    LoopNode may have.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 8.3.1

  • Key: UML22-118
  • Legacy Issue Number: 8777
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    There is a notational conflict in the white box view of a component. If a part is typed by a component the component symbol is shown in the upper right corner of the part rectangle. The same position is used to show the multiplicity of the part.

  • Reported: UML 2.0 — Thu, 12 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    The upper right corner of a connectable element could be used to denote the multiplicity. The same position is used to show the component symbol if the connectable element is typed by a component. It is also used by stereotype symbols. The presentation option for the multiplicity is in conflict with other standard UML notations. However it is only an option and not a mandatory presentation.

    Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Classes

  • Key: UML22-123
  • Legacy Issue Number: 8866
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Figure 28 (Examples of attributes) has a read-only, derived attribute. Read only attributes can't be changed after initialization, whereas the example implies this particular one can be changed due to derivation.

  • Reported: UML 2.0 — Fri, 10 Jun 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    close no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.2 Action

  • Key: UML22-122
  • Legacy Issue Number: 8861
  • Status: closed  
  • Source: Sapiens Deutschland GmbH ( Helmut Barthel)
  • Summary:

    Object token flow semantics with input pins seems to be incompletely defined. In section Semantics on page 337 you write: "... an action can only begin execution when all incoming control edges have tokens, and all input pins have object tokens." You didn't explain how and when the object tokens come to the input pins. Further, for step [2], you write: "An action consumes the input control and object tokens and removes them from the sources of control edges and from input pins." Again, you didn't explain how and when the object tokens came to the input pins, from source object nodes.

  • Reported: UML 2.0 — Wed, 8 Jun 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

In Figure 12, ownedAttribute is bidirectional, in Figure 95, it is unidirec

  • Key: UML22-109
  • Legacy Issue Number: 8741
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    In Figure 12, ownedAttribute is bidirectional, in Figure 95, it is unidirectional. What happens when these are merged in Figure 98?

  • Reported: UML 2.0 — Sun, 1 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    see pages 21 - 22 of ptc/2011-01-19

  • Updated: Fri, 6 Mar 2015 20:58 GMT

StructuredActivityNode, Semantics, third paragraph, first sentence,

  • Key: UML22-108
  • Legacy Issue Number: 8738
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    StructuredActivityNode, Semantics, third paragraph, first sentence, clarify that "attached" means input pin, output, or expansion nodes

  • Reported: UML 2.0 — Sun, 1 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Resolution:
    The wording of this sentence has already been changed by the resolution to Issue 9855 to refer specifically to pins on a structured activity node. Expansion nodes only apply to expansion regions and are covered in that section.
    Revised Text:
    None.
    Disposition: Duplicate

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 9.3.7

  • Key: UML22-117
  • Legacy Issue Number: 8776
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Second constraint: "If a connector end references both a role and a partWithPort, then the role must be a port that is defined by the type of the partWithPort." Since role has multiplicity 1..1 and partWithPort 0..1 the if condition is always true if a connector has a partWithPort. It'S sufficient to say "If a connector references a partWithPort,..."

  • Reported: UML 2.0 — Wed, 11 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Agreed, this will make it easier to read.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Return message

  • Key: UML22-120
  • Legacy Issue Number: 8785
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    How return message should be mapped into model? What kind of events are on message ends, how return values should be mapped? Should return values be arguments of message? How return message can be recognized in the model?
    How variable assignment should be mapped and related with message?

  • Reported: UML 1.4.2 — Wed, 18 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    There has never been anything called a "return message", but the issue is probably about "reply message" which we had forgotten to give a messageSort, but that has been fixed. The other issues are related, but are also asking for clarification of metamodel encoding. This should eventually be picked up again if necessary during a major revision.
    Disposition: ClosedOutOfScope

  • Updated: Fri, 6 Mar 2015 20:58 GMT

multiplicity should not be used/shown in an communicates association

  • Key: UML22-121
  • Legacy Issue Number: 8854
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Figure 404 - Example of the use cases and actors for an ATM system
    (The ATM example is repeated in Figure 410.)

    If you think multiplicity gives value to this diagram, please add additional text and explain the usage of multiplicity (1, 0..1, 0..*) in this diagram.

  • Reported: UML 1.4.2 — Fri, 3 Jun 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Merged with 18072

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 14

  • Key: UML22-76
  • Legacy Issue Number: 8353
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Add Ocl notation to constraints where possible or note that OCL notation is not possible. Page numbers of odd numbered pages are not in the same place as the are for other chapters. Move them to the lower right corner. Delete sub-section headings where the sub-section contains no information or state "None." If a concept is not "(as specialized)" and there are no atttributes, associations, etc. write "None" instead of "No additional xxx." Not all of the figures contain package names for the generalized parents. Add as many of these as possible or use the ellipses as appropriate.

  • Reported: UML 2.0 — Thu, 24 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 14.3.18

  • Key: UML22-75
  • Legacy Issue Number: 8342
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Second sentence in sub-section Description is missing a word. "...the contents of the referred Interaction xxx [from?? to??] where the InteractionUse is." Change the class name of the association argument:InputPin[*] either on fig 333 to InputPin or to Action in the text. Class name in fig. 333 is Action. This association is also shown in the figure as ordered. Association actualGate:Gate[*] subsets ownedElement. Mention specialization in definition of the association. I'm confused between the BNF use of io-argument and your use of argument. If the name of the association is "io-argument" as indicated by BNF and Issue 1751, should the name on the diagram and in the sub-section Associations be changed to io-argument? Also, para 2 on og 534 italizes argument instead of io-argument. Typo - Second sent. on pg. 534 needs a space between "explained" and "in."

  • Reported: UML 2.0 — Thu, 24 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

RemoveStructuralFeatureValueAction specification

  • Key: UML22-74
  • Legacy Issue Number: 8336
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Chokri Mraidha)
  • Summary:

    According to the RemoveStructuralFeatureValueAction specification we always have to specify the value to remove. It is not possible to remove an element from a multi-valued structural feature just by specifying its number in the set and without specifying its value. It would be interesting to have this option.

  • Reported: UML 2.0 — Thu, 24 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    This is resolved by the resolution to Issue 9870.
    Disposition: Duplicate

  • Updated: Fri, 6 Mar 2015 20:58 GMT

inconsistent description

  • Key: UML22-73
  • Legacy Issue Number: 8332
  • Status: closed  
  • Source: none ( Rui Xu)
  • Summary:

    There is an inconsistent description about determining conflicting transitions of a internal transition. According to sector Conflicting transitions, p.492: "Two transitions are said to conflict if they both exit the same state", two internal transitions in the same configration won't be conflict, However, P.492 says "Each orthogonal region in the active state configuration that is not decomposed into orthogonal regions can fire at most one transition as a result of the current event" There are two possible explanation: 1.Internal transition is treated orthogonal to the container region: thus, any two internal transitions in different state won't be confilict. 2.Internal transition is treated as self-transition without entry/exit action: thus, internal transition will be conflict with transitions which are conflict with corresponding self-transition. And a orthogonal region fires at most one transition(either internal or non-internal) an example: A and B are two states of top state. A is superState of AA AA is superState of AAA and AAB t1 is an internal transition of A t2 is an internal transition of AA t3 is an external transition from AAA to AAB t4 is an external transition from AA to B does t1 and t2 conflict? t2 and t3? which should be chosen for firing?

  • Reported: UML 1.4.2 — Thu, 24 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    An internal transition IS a self-transition. It does not exit or enter the state to which it is attached. Internal transitions
    belong to states and not to regions, as seemed to be implied by the issue summary. This is explicitly stated in the
    specification. From the point of view of firing rules, they are no different than for any other transition. If there are
    conflicts (and, there CAN be conflicts between two internal transitions), they are resolved the same way as all other
    conflicts based on the firing rules for such cases. Hence, the ambiguity discussed in the summary of the issue does not
    exist.
    (However, after reading the text, it seems that there is no explicit statement on how the issue of conflicting transitions
    of the same priority is resolved. Presumably, this is one of those “intentionally left unspecified” cases; i.e., it is an
    implementation choice. But, this is a different and more general issue that needs to be dealt with separately.)
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Decision node

  • Key: UML22-82
  • Legacy Issue Number: 8471
  • Status: closed  
  • Source: sabetta.com ( Antonino Sabetta)
  • Summary:

    Decision node should be able to take decision based on input separate from the flow being routed

  • Reported: UML 2.0 — Sun, 6 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Resolution:
    This issue is already resolved in UML 2.2 (see Issue 10815).
    Revised Text:
    None
    Disposition: Duplicate

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Actions

  • Key: UML22-81
  • Legacy Issue Number: 8470
  • Status: closed  
  • Source: International Business Machines ( Eran Gery [X] (Inactive))
  • Summary:

    Add actions for reading and writing parameter values, so flows are not required in structured activities

  • Reported: UML 2.0 — Fri, 25 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Duplicate of issue 9247.
    Revised Text:
    None.
    Disposition: Duplicate

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / Kernel / invalid restriction in isConsistentWith()

  • Key: UML22-80
  • Legacy Issue Number: 8460
  • Status: closed  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    A derived union association end represents a union of all of its subsets. The leaf subsets clearly have to be non-derived. However, in operation Property::isConsistentWith(), defined on page 127 of ptc/-04-10-02, it is stated that a derived property cannot be redefined by a non-derived property. This means that all such subsets of derived unions will be incorrect. Clearly, this restriction should be removed.

    Recommendation:

    Remove the constraint:

    (prop.isDerived implies isDerived)

    from the operation Property::isConsistentWith() (on pg. 127)

  • Reported: UML 1.4.2 — Fri, 4 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

namespace

  • Key: UML22-67
  • Legacy Issue Number: 8246
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    The namespace is xmlns:Model="omg.org.mof.Model" Surely it should be xmlns:Model="org.omg.mof.Model" " The official/latest version of this file: omg.org/models/MOF1.4/XMI1.1/Model1.4/Model.xml" does not exist on the OMG web site.

  • Reported: UML 1.4.2 — Sat, 5 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Figure 89 on page 158 is incorrect

  • Key: UML22-66
  • Legacy Issue Number: 8168
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    ptc/04-10-02: Figure 89 on page 158 is incorrect: the delegation connector on the left seems to be pointing the wrong way.

    More generally, it is not clear why an arrow is required on delegation connectors, since they are automatically implied when a port is connected to a part or a port on a part. The arrow can be misleading since some may interpret incorrectly it as a restriction on the direction of data flow. Note that the table 5 on page 166 does not show the arrow notation nor does table 7.

    Finally, the title of table 5 should say: "graphic paths" instead of "graphic nodes"

  • Reported: UML 1.4.2 — Fri, 28 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    The first part refers to figure 8.12. The "more generally" part applies to figure 8.16 and the associated text.
    Delegation connectors do not need any special notation other than that defined for connectors in general in table 9.2.
    The third aspect of this issue is a duplicate of 12236, already resolved.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 13.3.17

  • Key: UML22-72
  • Legacy Issue Number: 8310
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Figure 318 shows the association specification:Interfal[1] that redefines specification. Add this to sub-section Associations in the concept since the concept is not as specialized

  • Reported: UML 2.0 — Tue, 22 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    This has already been resolved in UML 2.2.
    Revised Text:
    None.
    Disposition: Closed No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 13.3.11

  • Key: UML22-71
  • Legacy Issue Number: 8306
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Describe more fully that DurationInterval defines the range between the minimum and maximum duration times allowed. To be consistent with other mutliplicities, show the multiplicities of the associations on fir. 318. Add comment that the associations redefine minimum and maximum as indicated by fig. 318. Sub-section Notation mentions DurationExpression but this concept is not defined. Add this as a concept.

  • Reported: UML 2.0 — Tue, 22 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    In the UML 2.2 specification, the diagram is now Figure 13.13. Multiplicities for min and max are shown on both the diagram and in the text. The redefinitions should be shown in the text. In the Notation section, DurationExpression should be Duration.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML2/Infra section 11.6.2/ Enumerations should not have attributes

  • Key: UML22-70
  • Legacy Issue Number: 8274
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    11.6.2 of Infra and 7.3.16 of Super refer to the possibility of Enumerations having attributes: "A compartment listing the attributes for the enumeration is placed
    below the name compartment." This concept does not make sense to me: an enumeration inherently represents a single value-set modeled through owned EnumerationLiterals.
    The only type of attribute that might ever make sense is a derived attribute (e.g. Color.isPrimary).

    Proposed resolution:
    Add constraint to above sections on Enumeration to state that only attributes permitted are derived ones. Also that any Operation must have isQuery=true.

  • Reported: UML 1.4.2 — Mon, 14 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Enumeration literals are immutable, so writeable attributes do not make sense. But read-only attributes do
    make sense: they don’t need to be derived. The current description of equality of EnumerationLiterals needs
    improvement. Operations on enumerations are allowed.
    This also resolves 17933

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Default values for ValueSpecification are not specified properly

  • Key: UML22-79
  • Legacy Issue Number: 8450
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    There are a few cases when the default is documented as a ValueExpression, as follows:

    • JoinNode.joinSpec = {default value is" and"}
    • ActivityEdge.guard= {default value is "true"}

    These defaults are currently just plain text in the Rose Model displayed under the ValueSpecification as shown in figure 185 in the superstructure specification.

    They should be included formally in the model. However it is not clear that the UML2 notation text allows defaults for association ends, and that those defaults can include expressions that construct instances of classes such as ValueSpecification. For example, the notation for ActivityEdge::guard in figure 185 could be:

    +guard = LiteralBoolean(true)

    The default value for guard is set to a newly constructed LiteralBoolean (a ValueSpecification) with value true.

    Recommendation:

    Ensure the text notation for default values includes the ability to construct InstanceSpecifications, and that the notation supports defaults for properties on association ends.

  • Reported: UML 1.4.2 — Fri, 4 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 15

  • Key: UML22-78
  • Legacy Issue Number: 8447
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    General comments - Delete sub-sections tat are empty or state "None." If class is not "as specialized' do not say "No additional xxxx" but rather "None" or delete the sub-section. Add OCL notation or a note that OCL notation is not available for constraints and/or additional operations and/or derived attributes where appropriate.

  • Reported: UML 2.0 — Thu, 3 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 14

  • Key: UML22-77
  • Legacy Issue Number: 8414
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    How to show class operation calls in interaction diagrams? A discussion in the umlforum list came to the conclusion that the name in the lifeline header should be the class name. In that case it is not possible to differentiate between "ClassName" only and "RoleName" only. Besides the notational problem I can't see how a class operation call could fit into the interaction meta-model. However it is necessary to show such a call. It's a typical part of an interaction.

  • Reported: UML 2.0 — Tue, 1 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Merged with 18697

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.40

  • Key: UML22-69
  • Legacy Issue Number: 8260
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Add package names "(CompleteStructuredActivities, StructuredActivities)" Add OCL notation

  • Reported: UML 2.0 — Tue, 8 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Within the Activities package, OutputPin appears under StructuredActivities and CompleteStructuredActivities. However, Figures 12.21 and 12.22 (of the UML 2.2 Specification, ptc/08-05-05), explicitly referencesUML::Actions::BasicActions::OutputPin. This is not correct, because StructuredActivities (indirectly) merges BasicActions, it does not import it - and, since it merges it, cannot reference elements from it.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.33

  • Key: UML22-68
  • Legacy Issue Number: 8249
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Add OCL notation to constraint. Correct multiplicity of association interrutingEdge:ActivityEdge[0..*] so that fig. 194 and text agree. Typos - Change 2nd sent. of 2nd para in sub-section Semantics to "...and the token arrives at the target even is an interruption occurs... . " - Under sub-section Presentation Option, spell zigzag as one word, not two.

  • Reported: UML 2.0 — Mon, 7 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Classes

  • Key: UML22-84
  • Legacy Issue Number: 8474
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Enumeration should have a constraint that the classifier of its literals is the enumeration

  • Reported: UML 2.0 — Sun, 6 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Activities

  • Key: UML22-83
  • Legacy Issue Number: 8472
  • Status: closed  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    Object node should be a multiplicity element, and use multiplicity upper for upperbound

  • Reported: UML 2.0 — Sun, 6 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Though seemingly small, this would actually be a significant change to the metamodel for activities and it would fundamentally change the current semantics for multiplicity of pins, which now only effect the execution of actions. If object node in general were made a multiplicity element, one would not only have to reconcile the current semantics of object node upper bound with the semantics of the multiplicity upper bound of a pin, one would also need to consider what the general semantics are for the multiplicity lower bound of an object node.
    This issue is thus considered strategic and out of scope for an RTF.
    Revised Text:
    None
    Disposition: Closed Out of Scope

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 10.3.11

  • Key: UML22-65
  • Legacy Issue Number: 8142
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Need to write the info for the Changes from previous UML section or remove it

  • Reported: UML 2.0 — Wed, 26 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Interactions

  • Key: UML22-85
  • Legacy Issue Number: 8475
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Interactions: What object receives SendEvent, etc? Affects how AcceptEventAction is used

  • Reported: UML 2.0 — Sun, 6 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    Not a problem in UML 2.5.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Common Behavior

  • Key: UML22-155
  • Legacy Issue Number: 9005
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Second paragraph of Semantics section of Trigger in Common Behavior is inconsistent with the first paragraph of p 605 in semantics of State. The semantics of Trigger does not accomodate deferred events.

  • Reported: UML 2.0 — Sun, 25 Sep 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    The noted paragraph in Trigger is not actually in conflict with deferred events. The semantics of Trigger states that once "an event is dispatched" it is "considered consumed" and is then "no longer available for processing". However, the semantics for deferred event under State says that "an event that does not trigger any transitions in the current state, will not be dispatched" if it is deferred. Therefore, there is no conflict with it being consumed only if it is actually dispatched.
    However, it would probably be helpful to clarify this under Trigger. Also, the semantic variation point on discarding an event if there is no appropriate trigger is not correct, since, for a transition even, at least, if the event is deferred it is not discarded, and if it is not deferred it is.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Classes (02)

  • Key: UML22-154
  • Legacy Issue Number: 9004
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    raisedException in Figure 10, reused without specialization by Operation in Figure 11 (the entry for it in Operation says it is redefined), but redefined in Figure 315. Should it be a derived union in Figure 10?

  • Reported: UML 2.0 — Sun, 25 Sep 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    The specialization from A_raisedException_operation to A_raisedException_behavioralFeature comes as a result of L3 package merge. Derived union would make sense if raisedException had a subsetting relationship instead of a specialization refinement.
    (Note also that the redefinition of raisedException is now noted on the diagram for Operation. Also, the resolution of Issue 12558 removed the later BasicBehaviors::BehavioralFeature::raisedException.)
    Revised Text:
    None.
    Disposition: Closed No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Common Behavior (02)

  • Key: UML22-153
  • Legacy Issue Number: 9002
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The semantics of TimeEvent uses undefined term "active". State machines uses the term for states, not triggers. Need definition independent of state machines in any case.

  • Reported: UML 2.0 — Sun, 25 Sep 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    The UML 2.5 beta specification still uses the phrase “time at which the Trigger becomes active” in 13.3.3
    under “Time Events”. The intended idea seems to be what is now discussed earlier in 13.3.3 under “Even
    Dispatching”: a Behavior may come to a “wait point” at which it has a number of “outstanding Triggers”.
    For any such Triggers with a relative TimeEvent, the starting point should be the time at which the Behavior
    comes to the wait point.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Common Behavior

  • Key: UML22-152
  • Legacy Issue Number: 9001
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Semantics of AnyReceiveEvent. The semantics of AnyReceiveEvent is in terms of state machines even though it is in Common Behavior. Should be defined independently of the kind of behavior using it.

  • Reported: UML 2.0 — Sun, 25 Sep 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Property ownership must be consistent across association redefinitions

  • Key: UML22-151
  • Legacy Issue Number: 8977
  • Status: closed  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    When an association generalizes another association and redefines its ends, the redefined end must be accessible through the generalization. This means redefining and redefined properties must be ownedEnds of the association or ownedAttributes of the participating classes. Redefining ownership (either directly or indirectly by changing navigability with default ownership) resulting in the redefined property no longer being a member of the general class should not be allowed. UML2 needs to include a constraint capturing this rule

  • Reported: UML 2.0 — Fri, 26 Aug 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    This is already covered by RedefinableElement::isRedefinitionContextValid() and
    RedefinableElement::redefinition_consistent.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Missing notation for association classes

  • Key: UML22-150
  • Legacy Issue Number: 8974
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    The notation for Associations allows them to be depicted as a diamond (even binary associations).
    However the Notation for AssociationClasses assumes the Association is depicted as a line only, and does not describe an option for attaching an AssociationClass to an Association shown as a diamond. This should be fairly obvious - just have the dotted line attached to the diamond instead of the Association's line.

  • Reported: UML 2.0 — Tue, 23 Aug 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    This is an omission in the text.
    This also resolves issue 12406

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page: 346-347

  • Key: UML22-149
  • Legacy Issue Number: 8973
  • Status: closed  
  • Source: Systemvaruhuset ( Andreas Hägglund)
  • Summary:

    Figure 207 on page 346 depicts the symbol for an activity as a number of rectangle with rounded corners surrounding a number of action nodes which also are depticed as rectangles with rounded corner. The example (figure 209 on page 347) however, depicts the action nodes not as rectangles with rounded corners but more lika ovals (or rectangles with noticabely more rounded corners than previously). Which symbol is the correct one?

  • Reported: UML 2.0 — Mon, 22 Aug 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    The referenced figure is 12.33 in Section 12.3.4 of the UML 2.2 specification (ptc/08-05-05). The graphical variation in the action shape in subsequent diagrams does not seem unreasonable and the notation of an action within an activity is clearly given in Section 12.3.2.
    Revised Text:
    None
    Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page: 255

  • Key: UML22-148
  • Legacy Issue Number: 8972
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The specification says: "If isReplaceAll is false and the variable is unordered and nonunique, then adding an existing value has no effect." This should be replaced by: "If isReplaceAll is false and the variable is unordered and UNIQUE, then adding an existing value has no effect."

  • Reported: UML 2.0 — Mon, 22 Aug 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Behavior

  • Key: UML22-147
  • Legacy Issue Number: 8970
  • Status: closed  
  • Source: MID GmbH ( Mr. Detlef Peters)
  • Summary:

    1) As a specialization of Class, Behavior (and its subclasses) may have properties (+ownedAttribute) and operations (+ownedOperation). Especially for operations, I can't see any use for it.
    I propose to change the Superclass of Behavior from 'Class' to 'Classifier' and to add an explicit ownership of Properties, as already done for Signals.
    2) The description and semantics of Behavior immediately refer to a context classifier. As a consequence, the composite relation to 'BehavioredClassifier' should be of multiplicity 1 instead of 0..1 so that a Behavior must always be owned by a BehavioredClassifier.

  • Reported: UML 2.0 — Fri, 19 Aug 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    1) The rationale for allowing attributes and operations on behaviors is actually provided in Subclause 12.3.4 for activities. In part: "An activity execution, as a reflective object, can support operations for managing execution, such as starting, stopping, aborting, and so on; attributes, such as how long the process has been executing or how much it costs; and links to objects, such as the performer of the execution, who to report completion to, or resources being used, and states of execution such as started, suspended, and so on." The submitter may not agree with the need for this capability, or desire to use it, but it was specifically included in UML because there are some who do wish to use it.
    2) A behavior may standalone without being owned by any other behaviored classifier. In this case the behavior is implicitly considered to be its own context when executed. Per the Semantics in Subclause 13.3.2: "When a behavior is instantiated as an object, it is its own context."
    Revised Text:
    None
    Disposition: Closed No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 - Invalid subsetting of composition ends

  • Key: UML22-144
  • Legacy Issue Number: 8952
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    In figure 3, the association end Element::owner is shown as navigable and as a union of all its subsets. According to the following convention defined in section 6.5.2, this end is owned by the class and not the composition association:

    " • An association with neither end marked by navigability arrows means that:
    • the association is navigable in both directions
    • each association end is owned by the classifier at the opposite end (i.e., neither end is owned by the association)"

    Throughout the spec, there are many places where this association end is specialized into a non-navigable association end (e.g., figures 4, 5, ...). But, according to the following additional rule in 6.5.2:

    " • An association with one end marked by a navigability arrow means that:
    • the association is navigable in the direction of that end,
    • the marked association end is owned by the classifier, and
    • the opposite (unmarked) association end is owned by the association"

    this means that such non-navigable association ends are owned by the association and not by the class.

    Consequently, such ends cannot be valid specializations of Element::owner (as stated in the spec) since they are owned by a classifier (the association) that is not related by generalization to the classifier (i.e., metaclass) that owns the original attribute.

    Recommendation:

    (1) Define Element::owner such that it is owned by the composition association and not by the Element class. This will make all the currently invalid subsettings of this type valid.

    (2) Do this for all other cases of invalid subsets of this type in the spec, if they exist.

    (3) Make it explicit in the spec that these are exceptions to the convention described in 6.5.2

  • Reported: UML 2.0 — Mon, 8 Aug 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / Actions / Compliance Levels of Actions

  • Key: UML22-143
  • Legacy Issue Number: 8951
  • Status: closed  
  • Source: MID GmbH ( Mr. Detlef Peters)
  • Summary:

    Actions for sending events and for calling operations and behavior are part of the "BasicActions" package which is part of Compliance Level 1. Their 'partner' actions for accepting a call or an event, however, are part of the "CompleteActions" package which is part of Compliance Level 3.
    Since there is not much sense in creating events without ever accepting them later, I recommend one of the following:
    a) Accept the first item of Issue 8459 from Mr. Amsden and move "AcceptEventAction" and "AcceptCallAction", too, to a package of L1, preferrably "BasicActions"
    b) Otherwise (if "Communications" remains an L2 package) move these two Actions together with all "InvocationAction" specializations, too, to a package of L2. In this case, maybe a new L2 package like "CommunicationActions" could be created.

  • Reported: UML 2.0 — Thu, 4 Aug 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    This issue is obsolete. There are no compliance levels in UML 2.5.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page: 53-55

  • Key: UML22-162
  • Legacy Issue Number: 9076
  • Status: closed  
  • Source: ZeT ( Jose A. Rodrigues Nt.)
  • Summary:

    In UML v. 2.0, formal/05-07-04: IF 7.3.9 Comment -> Semantics -> "A Comment adds no semantics to the annotated elements,..." AND 7.3.10 Constraint -> "A constraint is a condition or restriction expressed in natural language text or in a machine readable language for the purpose of declaring some of the semantics of an element." AND 7.3.10 Constraint -> Semantics -> "A Constraint represents additional semantic information attached to the constrained elements." AND 7.3.10 Constraint -> Presentation Options -> "The constraint string may be placed in a note symbol and attached to each of the symbols for the constrained elements by a dashed line." THEN Either the constrained element is the "note symbol", the "note symbol" represents a Comment and so a Comment adds semantics to another element or I missed something.

  • Reported: UML 2.0 — Thu, 6 Oct 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    Just because both a Comment and a Constraint can both be notated using a similar “note symbol” does not mean
    they are the same thing. A Constraint notated using a note symbol in the concrete syntax of a model still maps to a
    Constraint in the abstract syntax representation, not a Comment.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

"ownedType" is not a valid element

  • Key: UML22-161
  • Legacy Issue Number: 9024
  • Status: closed  
  • Source: Adaptive ( Mr. Gene Mutschler)
  • Summary:

    Having implemented a UML 2 L0 addin for Rational Rose, I exported a sample model to XMI. When this XMI file was imported into another UML2 tool, the tool failed, indicating that "ownedType" is not a valid element. Examination of the Infrastructure Library reveals why this is so. In the InfrastructureLibrary's Basic package (the basis for UML2 L0), the sole means by which a Package owns items is the "ownedType" reference. However, in The Constructs package (the basis for UML 2 L1 and beyond), this reference is now indicated as derived, meaning that it will not be handled by most UML 2 tools. It has been replaced by the "ownedMember" reference, which is unknown to UML 2 L0.

    This is a showstopper issue with respect to UML2 XMI interoperability, since it means that a UML2 tool operating at Level 0 cannot interchange models with UML2 tools operating at any other level.

  • Reported: UML 2.0 — Tue, 4 Oct 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Classes

  • Key: UML22-158
  • Legacy Issue Number: 9012
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Associations can have static ends, but this violates the semantics of static (that they are properties of the class or subclasses, not instances). If we are following programming languages, the semantics of isStatic should be that it is properties of instances, but is the same on all instances. The current semantics would be the right one if isStatic identifies "metaproperties".

  • Reported: UML 2.0 — Sun, 25 Sep 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    This is now covered by the text that says “Where semantics are not explicitly specified for static Features, those
    semantics are undefined” in clause 9.4.3, and also “The semantics are undefined for Associations that have an end
    with isStatic = true” in 16.6.3.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Classes

  • Key: UML22-157
  • Legacy Issue Number: 9011
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Figure 13, what is the classifier of EnumerationLiteral (inherited from InstanceSpecification)? Presumably it should be the enumeration, with the enumeration end of the association to Enumeration redefining the classifier end from InstanceSpecification in Figure 8. Programs accessing classifiers in the repository should find the enumeration literals as instances of their enumerations.

  • Reported: UML 2.0 — Tue, 14 Nov 2000 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Activities

  • Key: UML22-156
  • Legacy Issue Number: 9009
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    In LoopNode, the frontend, backend node description is redundant with the semantics of StructuredActivityNode

  • Reported: UML 2.0 — Sun, 25 Sep 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    This issue is obsolete. The UML 2.5 description of structured node semantics no longer uses the “frontend, backend
    node” terminology, and is no longer redundant.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML SuperStructure - Inconsistency re State Machine terms

  • Key: UML22-146
  • Legacy Issue Number: 8967
  • Status: closed  
  • Source: Anonymous
  • Summary:

    think there is some inconsistency in your usage of terms
    in chapter 15 State Machines.

    It isn't really clear (I think) what you mean sometimes when
    you use the terms "state machine" "behavioral state machines"
    and "protocol state machines".

    In my (humble) opinion you should never use only the term
    "state machine" when you do not mean both "behavioral state
    machine" and "protocol state machine".

    15.3.12 is a perfect example where I think there is confusion,
    or at least lack of clarity, since you talk about "state machines" executing "activities". Clearly, not all state machines do--
    more precisely--protocol state machines don't.

  • Reported: UML 2.0 — Tue, 16 Aug 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    This issue was resolved by the UML 2.5 convention of using explicit meta-class names (e.g., StateMachine and ProtocolStateMachine)
    and by isloating the two types of state machines into distinct sections of the spec.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 14.3.20

  • Key: UML22-145
  • Legacy Issue Number: 8965
  • Status: closed  
  • Source: ACTL Systems ltd. ( Dani Mannes)
  • Summary:

    In the UML 1.5 you could specifiy on messages in the collaboration diagram the predesessor. This was very convenient for modeling threads. this has been removed from the UML 2.0. It should be added to the communication diagram message specification.

  • Reported: UML 2.0 — Mon, 15 Aug 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    In sequence diagram messages are not totally ordered.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 16.3.3

  • Key: UML22-160
  • Legacy Issue Number: 9017
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Fig 16.3. uses note symbol notation of the Hruby Vision template. That's not conform to UML 2.0 at this point. The end of the note anchor line doesn't have a circle in UML 2.0.

  • Reported: UML 2.0 — Mon, 26 Sep 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Merged with 18084

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Activities

  • Key: UML22-159
  • Legacy Issue Number: 9014
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Add constraint that incoming edges to input pins on structured activities must have sources outside the structured node. Add constraint that incoming edges to output pins on structured activities must have sources inside the structured node.

  • Reported: UML 2.0 — Sun, 25 Sep 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page: 420

  • Key: UML22-142
  • Legacy Issue Number: 8945
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    In addition to the elided pins presentation add presentation option that pins can be omitted without a little box above the line.

  • Reported: UML 2.0 — Tue, 2 Aug 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Without the little box, the object flow would look identical to a control flow between actions, which would be confusing.
    Revised Text:
    None
    Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Connector - "provided Port" and "required Port" not defined Constraint 1

  • Key: UML22-36
  • Legacy Issue Number: 7247
  • Status: closed  
  • Source: PostFinance ( Karl Guggisberg)
  • Summary:

    Connector - "provided Port" and "required Port" not defined Constraint 1, "[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." uses the concepts "provided Port" and "required Port". Neither of them is defined in the spec. Furthermore, a Connector is not expected to be defined between Interfaces, but an Association is. A Connector is defined between ConnectableElements whose specializations are Property, Port, Parameter, and Variable, but not Interface. I suggest to replace Constraint [1] with "[1] A delegation connector must only be defined between a ConnectableElement (i.e. a Port) of the component and a ConnectableElement (i.e. a Property or a Port) of one of its internal parts."

  • Reported: UML 2.0 — Thu, 15 Apr 2004 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    The proposed resolution is still incorrect because a connector in general is n-ary not binary. Also the need for such a constraint is altered because of the resolution of 7364 which makes Connector::kind derived. Instead we need a constraint that ensures that a delegation connector only delegates from one port: it would make no sense to have an n-ary connector that delegated from more than one port. Furthermore the entire Semantics section for Connector in this chapter needs rewriting because of this issue.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

isComposite inconsistency in UML 2.0 and MOF 2.0

  • Key: UML22-46
  • Legacy Issue Number: 7910
  • Status: closed  
  • Source: N/A ( Rob Grainger)
  • Summary:

    The usage of isComposite varies in these two specs as detailed below. Hope this proves useful. Rob ------- UML 2.0 ------- The UML 2.0 Infrastructure spec (03-09-15) section 10.2.4 defines Basic::Property::isComposite as follows: – isComposite : Boolean If isComposite is true, the object containing the attribute is a container for the object or value contained in the attribute. The default value is false. i.e. an attribute marked "isComposite" is the container for the value. – However, Constructs::Property (which inherits Basic::Property) has the following constraint: [3] A multiplicity of a composite aggregation must not have an upper bound greater than 1. isComposite implies (upperBound()>isEmpty() or upperBound() <= 1) This is surely intended to mean that an object can have [0..1] containers, rather than (as defined by the two definitions above) that a container can store [0..1] instances in each composite property. The difficulty seems to be one of terminology - from the perspective of a property, being composite implies the property is composite, ie. contains zero or more objects, while from the perspective of an object, the composite of an object could be viewed as a container. The problem can be fixed by redefining the constraint something like: [3] If a property has isComposite==true, than if the property has an opposite, that opposite property must have an upper bound greater than 1. isComposite implies (opposite == null) or (opposite.upperBound()>isEmpty() or opposite.upperBound() <= 1). In 11.3.1 - Association, "Composition is represented by the isComposite attribute on the part end of the association being set to true." - again this is the opposite sense. This is also indicates that there is a degree of complexity implementing MOF::Reflection::Object::container() - there is actually no property for which this is a simple test. Instead, it is necessary to find a property of the object such that the opposite property is marked isComposite, there is no guarantee such a property is accessible, hence an implementation must, in some cases, store a separate (hidden) reference to the object's container. This is an implementation property however. The other alternative I can see would be to replace isComposite on the container object with isContainer on the contained object, or even to have both (with an appropriate constraint to guarantee that the two properties are consistent). --------- MOF 2.0 --------- The same problem manifests in the definition of CMOF abstract semantics. In section 15.2, ClassInstance includes the following definition: 2. At most one Slot for an isComposite property may have a value. (this needs more work if the owner reference is not navigable) Using the current definition of isComposite, this needs to be restated to the effect that at most one slot for a property that is the opposite of an isComposite property may have a value. And again, in the specification of DataType... For all properties, isReadOnly is true, isComposite is false, isDerivedUnion is false Surely this is not correct - a data type may contain other datatypes, which by definition are stored by value, implying strong ownership, and hence a composition relationship. Indeed, any classifier containing a property whose value is a data type should always have isComposite set to true. In 15.4, Object::delete() seems to use isComposite correctly given the definition. Later, however, Object::owningProperty() uses the other approach - using isComposite() to identify the container of the current object.

  • Reported: UML 1.4.2 — Mon, 15 Nov 2004 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 9.14.1

  • Key: UML22-48
  • Legacy Issue Number: 7969
  • Status: closed  
  • Source: N/A ( Paul Berry)
  • Summary:

    The allOwnedElements query (defined in Core::Abstractions::Ownerships) operates by recursing downward through the ownership hierarchy. Its OCL implementation looks like this: Element::allOwnedElements(): Set(Element); allOwnedElements = ownedElement->union(ownedElement->collect(e | e.allOwnedElements())) In the absence of sophisticated optimization, this query is only guaranteed to terminate if the ownership hierarchy is non-circular. The ownership hierarchy is guaranteed to be circular by constraint [1] (An element may not directly or indirectly own itself). But the OCL description of constraint [1] is written in terms of the allOwnedElements() query: not self.allOwnedElements()>includes(self) If a modeling tool were to be written based on these rules in a straightforward way, it would never be able to detect a violation of constraint [1]. Instead it would go into infinite recursion while trying to check the constraint. Proposed solution: Add the following operation to 9.14.1: [3] The query isCircularlyOwned walks the chain of direct and indirect owners of an element, checking whether the chain contains any circularities, or any of the elements in the set prohibitedElements. Element::isCircularlyOwned(prohibitedElements: Set(Element)): Boolean; isCircularlyOwned = if owner>isEmpty() then false else if prohibitedElements->including(self)>includes(owner) then true else owner.isCircularlyOwned(prohibitedElements>including(self)) And change constraint [1] to: [1] An element may not be directly or indirectly owned by itself. not self.isCircularlyOwned(Set{})

  • Reported: UML 2.0 — Sun, 5 Dec 2004 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    It is not necessary for the OCL in the specification to be implementable in some “straightforward way”. It is only
    necessary that the OCL have the proper meaning according to OCL semantics, which the identified expressions do.
    An implementation is free to implement them in the manner that the issue author suggests. It is not necessary to
    complicate the specification by adopting a specific implementation approach.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

should retain Comment and its associations to Element

  • Key: UML22-47
  • Legacy Issue Number: 7958
  • Status: closed  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    The resolution to Issue 7782 (Move Comment from Constructs to Basic) removed Comment from Constructs. For consistency with the rest of Constructs (which included everything else reused from Basic), the resolution should not have removed Comment from Constructs, it should have just copied Comment into Basic.

  • Reported: UML 1.4.2 — Wed, 1 Dec 2004 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    This is resolved in the UML 2.2 specification.
    Revised Text:
    None.
    Disposition: Closed No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Notation sections for TimeObservation and DurationObservation

  • Key: UML22-42
  • Legacy Issue Number: 7304
  • Status: closed  
  • Source: Missouri University of Science and Technology ( Thomas Weigert)
  • Summary:

    The Notation sections for TimeObservation and DurationObservation seem inadequate: 1. The syntax for TimeObservation only allows "now" as a TimeExpression, but indicates in the previous sentence that more complex expressions are possible. 2. The syntax for DurationObservation includes the unexplained non-terminal symbol "duration". 3. In the example, figure 321, there are no associations to named elements shown. I assume that these refer to the begin and end of the arrow, but that is not indicated.

  • Reported: UML 2.0 — Wed, 5 May 2004 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    This issue has already been considered by prior RTFs and deemed out of scope, per the following discussion previously recorded for this issue:
    A proper resolution of this issue depends on changes in progress with respect to the action and activity model. In addition, a more encompassing improvement of the "simple time model" and related concepts is required.
    Thus, the resolution of this issue is best considered to be strategic.
    Revised Text:
    None
    Disposition: Closed Out of Scope

  • Updated: Fri, 6 Mar 2015 20:58 GMT

completion transitions

  • Key: UML22-41
  • Legacy Issue Number: 7254
  • Status: closed  
  • Source: ISTI-CNR ( Franco Mazzanti)
  • Summary:

    Suppose that we have two composite states, nested within to two concurrent regions, which both become "complete" as part of the same "run-to-completion" step, and each of the composite states is the source for a completion transition. I.e. within this "run-to-completion" step two completion events are generated. How should these two completion events be dispatched? - Sequentially, in the same sequential order in which they have been generated. - Sequentially, but any ordering is allowed, - Concurrently. I.e. both completion transitions are considered enabled. - other ??? or any of the above Notice that completion transition may have guards, and activity, hence the firing of one of them may cause the other to become no more "enabled". Hence the above three cases may really cause different system behaviors.

  • Reported: UML 1.5 — Wed, 21 Apr 2004 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Add a clarification for this case based on the above discussion

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Connector - inconsistencies in Constraint[3]

  • Key: UML22-38
  • Legacy Issue Number: 7249
  • Status: closed  
  • Source: PostFinance ( Karl Guggisberg)
  • Summary:

    Connector - inconsistencies in Constraint[3] Constraint [3] says: "[3] If a delegation connector is defined between a source Interface or Port and a target Interface or Port, then the target Interface must support a signature compatible subset of Operations of the source Interface or Port." There are two problems with this constraint: 1. An Interface cannot be the source or the target of a connector, because Interface is not a ConnectableElement. 2. If a connector is defined between a source Port and a target Port (which is possible, because Port is a ConnectableElement) - what is the "target Interface"? One of the Interfaces port.type is implementing? Or one of the Interfaces in port.provided? - what are the Operations of the source Port? The Operations of the Classifier given by port.type? Or the union of all Operations of all Interfaces given by port.required and port.provided? - what does "signature compatible" mean for Interfaces?

  • Reported: UML 2.0 — Thu, 15 Apr 2004 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    See 7248 for the discussion.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Connector - inconsistencies in Constraint [2]

  • Key: UML22-37
  • Legacy Issue Number: 7248
  • Status: closed  
  • Source: PostFinance ( Karl Guggisberg)
  • Summary:

    Connector - inconsistencies in Constraint [2] Constraint [2] says: "[2] If a delegation connector is defined between a used Interface or Port and an internal Part Classifier, then that Classifier must have an “implements” relationship to the Interface type of that Port." There are two problems with this constraint: 1. A connector cannot be defined between a used Interface and an internal Part, because Interface is not a ConnectableElement. 2. What is "the Interface type of that Port" ? The Classifier given by port.type? This Classifier can be but does not have to be an Interface. Or one of the Interfaces given by port.required? Which one?

  • Reported: UML 2.0 — Thu, 15 Apr 2004 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    This constraint and the following two are currently incomprehensible (see 7249 and 7250). According to Internal Structures, "What makes connectable elements compatible is a semantic variation point." I see no particular reason to change this for components, and given that connectors are n-ary, it would be hard to do so. So I propose simply to delete the constraints. Profiles are free to restrict connectors to binary and to impose signature compatibility, based on type or contract compatibility, if they wish to.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Connector - inconsistencies in Constraint[5]

  • Key: UML22-40
  • Legacy Issue Number: 7251
  • Status: closed  
  • Source: PostFinance ( Karl Guggisberg)
  • Summary:

    Connector - inconsistencies in Constraint[5] Constraint [5] says: "[5] An assembly connector must only be defined from a required Interface or Ports to a provided Interface or Port." There are two problems with this constraint: 1. A connector cannot be defined from or to an Interface, because Interface is not a ConnectableElement. 2. It is not clear what a "required Port" or a "provided Port" is.

  • Reported: UML 2.0 — Thu, 15 Apr 2004 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    See 7248 for the discussion.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Connector - inconsistencies in Constraint[4]

  • Key: UML22-39
  • Legacy Issue Number: 7250
  • Status: closed  
  • Source: PostFinance ( Karl Guggisberg)
  • Summary:

    Connector - inconsistencies in Constraint[4] Constraint [4] says: "[4] In a complete model, if a source Port has delegation connectors to a set of delegated target Ports, then the union of the Interfaces of these target Ports must be signature compatible with the Interface that types the source Port." There are two problems with this constraint: 1. What is "the union of the Interfaces of these target Ports"? First, it is not clear, what a "union of interfaces" is. A "union of a set of interfaces" could be an anonymous Interface which specializes all the interfaces in the set of interfaces, but this should be made clear, because "union of interfaces" is not defined somewhere else in the spec. Second, it is not clear what the Interfaces of a target Ports are. All Interfaces provided by the Classifier port.type including the Classifier port.type itself, if port.type is an Interface? Union the Interfaces in port.provided? Do we have to include the Interfaces in port.required as well? 2. What does "signature compatible" mean?

  • Reported: UML 2.0 — Thu, 15 Apr 2004 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    See 7248 for the discussion.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Presentation Options

  • Key: UML22-50
  • Legacy Issue Number: 7994
  • Status: closed  
  • Source: SINTEF ICT ( Richard Torbjørn Sanders)
  • Summary:

    Presentation Options: Add after first sentence: "State symbols may optionally be used to describe a Constraint" "The regions represent the orthogonal regions of states" - delete this. The identifier need -> The name of the state need

  • Reported: UML 2.0 — Sat, 18 Dec 2004 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    The text referred in this issue does no longer exist.
    Disposition: ClosedNoChange

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Use case extension inconsistencies

  • Key: UML22-49
  • Legacy Issue Number: 7993
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    According to Figure 401, an Extend object references at least one ExtensionPoint which itself must be owned by exactly one UseCase.
    Therefore it seems that the Extend.extendedCase property is redundant and should be derived.

    Also the section for ExtensionPoint does not include the useCase property shown in Figure 401, which itself does not show the

    {subset}

    .

    Proposed resolution
    -----------------------------

    1) Update Figure 401 to replace +extendedCase by +/extendedCase

    2) Update Figure 401 to replace +useCase by +useCase

    {subsets owner}

    .

    3) Section 16.3.3 Extend: update the Associations section to replace:
    extendedCase : UseCase [1] References the use case that is being extended. (Specializes DirectedRelationship.target.)

    by

    /extendedCase : UseCase [1] References the use case that is being extended: this is derived as the Use case that owns the ExtensionPoint(s). (Specializes DirectedRelationship.target.) in OCL: extendedCase = self.extensionLocation->useCase

    4) Section 16.3.4 ExtensionPoint update the Associations section to replace:
    No additional associations

    by

    useCase: UseCase [1] References the use case that owns the ExtensionPoint. (subsets owner.)

  • Reported: UML 1.4.2 — Mon, 20 Dec 2004 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

AssociationClass

  • Key: UML22-45
  • Legacy Issue Number: 7400
  • Status: closed  
  • Source: X-Change Technologies ( Joaquin Miller)
  • Summary:

    The text says that a non-navigable end of an association class is an attribute of that association class. "When a property is owned by a class it represents an attribute." [7.11.4] "AssociationClass is both an Association and a Class." [7.16.1] "When a property is owned by an association it represents a non-navigable end of the association." [7.11.2] This is good, is as expected, and is consistent with both the object and the relational theories of modelling. It is said that the drawings tell a different story. If so, they should be corrected. There is no practical advantage to requiring that the non-navigable ends of an association class are not attributes of that class. On the contrary, such a requirement is unexpected and will be confusing.

  • Reported: UML 1.5 — Mon, 31 May 2004 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    The issue is obsolete. The text in 11.5.3 clearly states that the ownedEnds of an AssociationClass are not
    attributes.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

useless example on p.330, Figure 247

  • Key: UML22-44
  • Legacy Issue Number: 7375
  • Status: closed  
  • Source: Missouri University of Science and Technology ( Thomas Weigert)
  • Summary:

    p.330, Figure 247. This example is useless, as it canot be understood without much detail on the FFT computation. It would be better to use examples that readers can readily understand.

  • Reported: UML 2.0 — Thu, 20 May 2004 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    The issue is subjective. Some readers might find the example helpful. The example is useful as a depiction of a realistic computation.
    Revised Text:
    None
    Disposition: Closed, no Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Property defines an association "datatype" which is redundant

  • Key: UML22-43
  • Legacy Issue Number: 7339
  • Status: closed  
  • Source: Missouri University of Science and Technology ( Thomas Weigert)
  • Summary:

    Property defines an association "datatype". This association is redundant for the following reasons: A DataType is a kind of classifier, so saying that a property can be owned by a DataType adds nothing new. (ii) as feature, one can navigate from the property to the featuringClassifier, and so the navigability to an owning data type is already given. Moreover, an association to a data type would be incorrect if the property would otherwise be owned by a different Classifier. Moreover, if this property is owned by a classifier, there is no guarantee that the datatype association references the same DataType. There are no consistency constraints. Anyway, this association is redundant, can possibly lead to inconsistent models, and should be deleted. The last sentence on p.92 "A property may be owned by and in the namespace of a datatype." is correct even if the association is deleted. However, this sentence adds no new information either and is best deleted also.

  • Reported: UML 2.0 — Sat, 15 May 2004 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    see pages 14 - 17 of ptc/2011-01-19

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Multiple typos in ptc/04-10-02

  • Key: UML22-57
  • Legacy Issue Number: 8102
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Multiple typos (If you don't want them submitted this way, I'll complete an issue for each.) section 6.34 page 11 Delete word “to” in “The read/write actions can also be used to by one…” section 7.3.3 page 38 Delete word “If’ in the Note “If the lower multiplicity for an end of…” Section 7.3.5 page 46 Correct typo “pr” to “or” in ownedParameter:Parameter[*] Section 7.3.11 page 60 Change “has” to “have” in 2nd para 2nd sentence “Instances of a data type that “has”…” Instances is the subject of the sentence Section 7.3.11 page 61 Add word “to” to Notation sentence 6 “In this case, cone or more arrows with their tails on the clients are connected “to” the tails…” Section 7.3.20 page 71 Change “is” to are in generalizationSet “Designates a set in which instances of Generalization “are” considered members.” The verb refers to the subject of the which clause (instances). Section 7.3.21 page 83 Change “is” to “if” in last sentence of section “Or, “if” a new subclass…” Section 7.3.32 page 97 Change “These constraint” to “These constraints” Section 7.3.32 page 98 Delete word “is” in 2nd sentence of Notation “In general, the notation will include a multiplicity specification shown as…” Section 7.3.37 page 111 Change “is” to “are” in 4th paragraph of Semantics “The public contents of a package are…” Subject of the sentence is contents not package. Section 7.3.49 page 135 and page 136 (Description) Change verb “specify” to “specifies” in “A structureal feature is a typed feature of a classifier that specifies the structure…” Section 7.3.49 page 137 Change verb from “signifies” to signifying” in 1st sentence of Decsription Section 7.3.53 page 139 Delete word “of” in 1st sentence of Semantics

  • Reported: UML 2.0 — Fri, 21 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Clarify the differences between redefining element and redefined element.

  • Key: UML22-56
  • Legacy Issue Number: 8101
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Clarify the differences between redefining element and redefined element.

  • Reported: UML 2.0 — Thu, 20 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

All sections

  • Key: UML22-55
  • Legacy Issue Number: 8087
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    With the new format of putting all of the diagrams at the beginning of the chapters, I am finding it very difficult to determine which diagram goes with what sub-section. Add references in the text to the diagram most applicable to the descriptions/definitions

  • Reported: UML 2.0 — Fri, 14 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ClassifierInState not supported in UML2.0 ?

  • Key: UML22-54
  • Legacy Issue Number: 8071
  • Status: closed  
  • Source: GOO Tech ( Birol Berkem)
  • Summary:

    In the UML 1.x, we have the notion of ClassifierInState. We used them for representing associations and methods of classes that are valid when instances of these classes are in the corresponding states.

    Could you let me know how to do that using UML 2 ? If class-in-states are not supported in UML 2.0, I am afraid, we cannot represent these valuable information particularly for reifying business processes. For example Order[Delivery] , Order[Billing], etc.. with their operations and session attributes !

  • Reported: UML 1.4.2 — Tue, 4 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    This is really a question of clarification of a misunderstanding of the submitter. The equivalent of ClassifierInState for activity modeling is supported in UML 2 by the ObjectNode inState association. UML 1 also allowed ClassifierInState to be used in instance and collaboration modeling. While there is no direct equivalent for this in UML 2, the same effect can be achieved by using an OCL constraint on an instance.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 9.3.11

  • Key: UML22-64
  • Legacy Issue Number: 8126
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    According to fig. 97, Associations need multiplicities added to all and derived symbol to required:Interface and provided:Interface. Add OCL notation to Constraints

  • Reported: UML 2.0 — Tue, 25 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 8.3.2

  • Key: UML22-63
  • Legacy Issue Number: 8119
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    "In a system context where there are multople components that provide or require a particular interface, a notation abstraction can be used that combines by joining the multiple connectors." Combines what? Client keyword missing from fig. 93.

  • Reported: UML 2.0 — Mon, 24 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    I cannot find any such text in section 8.3.2, or indeed anywhere in the current specification.

    Revised Text:
    None.

    Disposition: Closed, no change.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

constrainedElement direction

  • Key: UML22-51
  • Legacy Issue Number: 8020
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    constrainedElement direction The association between Constraint and Element named "constrainedElement" is unidirectional from Constraint to Element. This means implementations are not required to provide efficient navigation from an element to the constraints on it. Since the constraints of a model element are part of the definition of that element, the required navigation should at least be from the element to the constraint.

  • Reported: UML 2.0 — Thu, 30 Dec 2004 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    A Constraint can constrain multiple constrainedElements and, thus, is not necessarily owned by any one of them. In
    this sense, the Constraint is not, in general, part of the formal “definition” of the constrainedElements. Rather, if
    the Constraint has a context (which may or may not be a constrainedElement), then it is more proper to think of the
    constraint as part of the definition of that context, and the context association end is navigable.
    Further, one wants to be able to add constraints to elements of the model without having tomodify an owned property
    of the elements being constrained, but making the association from Element to Constraint would imply (by the usual
    UML abstract syntax metamodel conventions) that the “constraint” association end would become owned by Element.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Association specialization semantics

  • Key: UML22-53
  • Legacy Issue Number: 8023
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Association specialization semantics The semantics of Association addresses specialization. Some of this paragraph is applicable to Generalization and should be moved there. The discussion specific to association could be clearer, for example, what does "correlates positively" mean?

  • Reported: UML 1.4.2 — Thu, 30 Dec 2004 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Derived union notation

  • Key: UML22-52
  • Legacy Issue Number: 8022
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Derived union notation Why is the semantics and notation for subsetting/redefinition in Association, while derived union is in Property?

  • Reported: UML 2.0 — Thu, 30 Dec 2004 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 9.3.7

  • Key: UML22-61
  • Legacy Issue Number: 8114
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Correct multiplicity of role:ConnectableElement[1] so that fig. 96 agrees with that defined in Associations. Add OCL notation for Constraints. Ports under Notation also reads to me like it could be expressed in OCL notation somewhere--like a constraint which would need to be added.

  • Reported: UML 2.0 — Mon, 24 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 9.3.6

  • Key: UML22-60
  • Legacy Issue Number: 8113
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Need OCL notation for Constraints. Correct page reference number for StructuredClassifier

  • Reported: UML 2.0 — Mon, 24 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 8.3.2

  • Key: UML22-62
  • Legacy Issue Number: 8118
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Reword/rewrite the last two paragraphs of Semantics. Many grammatical mistakes between sentence subject and verb plurality (because of intervening phrases), hard to understand sentences, and an incomplete sentence (last one).

  • Reported: UML 2.0 — Mon, 24 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    I cannot find any such problem in section 8.3.2. However I do find the following, which has duplicated text:
    "A component's behavior may typically be realized (or implemented) by a number of Classifiers. In effect, it forms an abstraction for a collection of model elements. In that case, a component owns a set of Component Realization Dependencies to these Classifiers. In effect, it forms an abstraction for a collection of model elements. In that case, a component owns a set of Realization Dependencies to these Classifiers"

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 8.3.2

  • Key: UML22-58
  • Legacy Issue Number: 8106
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Constraints have no OCL syntax or mention that constraints are not definable in OCL. Type in constraint [5] - delete "s" from first "Ports".

  • Reported: UML 2.0 — Mon, 24 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Resolution:
    This actually refers to 8.3.3. The constraints have been fixed or deleted by other resolutions (7247-7251).

    Revised Text:
    None.
    Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 9.3.4

  • Key: UML22-59
  • Legacy Issue Number: 8111
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    OCL notation is missing from Constraints. Please add or add note that OCL notation is not able to express constraints

  • Reported: UML 2.0 — Mon, 24 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Reentrancy 1

  • Key: UML22-7
  • Legacy Issue Number: 6111
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    How is the effect if isReentrant achieved for actions other than call
    actions? isReentrant is only on behaviors. Perhaps it should also be
    available on actions and operations

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    The current semantics of isReentrant on behaviors leads to unexpected global mutual exclusion of invocation of a behavior if isReentrant=false, the default (see Issue 9873). However, at the level of the invocation of a behavior in an activity, it is often the case that one execution of such an invocation action should complete before a second can begin (for example, if the activity is modeling a business process with the invoked behavior assigned to a single person, or a manufacturing process with the behavior carried out by a single piece of equipment). Thus, it is reasonable to have "local" non-reentrancy as the default.
    In this case, however, it makes as much sense to allow the specification of reentrancy or non-reentrancy on any action, not just on the invocation of a behavior, as requested by the issue submitter. This also allows locally non-reentrant semantics, without the unexpected consequences of global non-reentrancy.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Suspension Region

  • Key: UML22-6
  • Legacy Issue Number: 6082
  • Status: closed  
  • Source: Ostfold University College ( Dr. Oystein Haugen)
  • Summary:

    “Supspension region” is a concept from MSC-2000 that occurred in earlier drafts of UML 2.0. It was removed since the metamodel had not been properly updated. A suspension region is an area of a lifeline where no events should occur since the lifeline is waiting for reply from an operation call.

    This has been flagged as a potential FTF issue before.

  • Reported: UML 1.5 — Fri, 29 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion:
    This is a concept that highlights a syntactic requirement. Often users think that suspension is always the case between call and reply, but since lifelines may be decomposed into independent sub-parts, this is not necessarily the case. That is why it is useful to clarify a synchronization situation. Still it is a new concept, and cannot be considered critical for the use of Interactions. Let us bring this up again at a larger revision.
    Disposition: ClosedOutOfScope

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / Missing OCL constraints

  • Key: UML22-18
  • Legacy Issue Number: 6452
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    In the final adopted spec, there are numerous constraints associated with the various metaclasses that do not have corresponding OCL written. This should be fixed.

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

03-04-01 Chap 2 p. 112/Components: Different ways to wire components

  • Key: UML22-17
  • Legacy Issue Number: 6433
  • Status: closed  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    Issue: Re Chapter 2, Components, Figure 2-15, p. 112: The text of the fifth
    paragraph says: “A component has a number of provided and required
    Interfaces, that form the basis for wiring components together, either using
    Dependencies, or by using Connectors.” Is this really an either or choice?
    What is the real semantic distinction? And what is the semantic distinction
    between wiring via connectors without ports vs. wiring via connectors with
    ports?

    Recommendation: Clearly specify the semantic distinctions among the three
    ways of wiring components together:

    1) Via Dependencies
    2) Via Connectors without Ports
    3) Via Connectors with Ports.

    If there are no semantic distinctions--that is, if the distinctions are
    purely mechanical--then the specification should probably changed such that
    there is one way to wire components together.

  • Reported: UML 1.5 — Tue, 4 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Dependencies are used for wiring components at the type level, and indicate some policies about how components might be wired. Connectors are used for wiring component internals and show how parts and ports are actually wired.
    We will not resolve the issue about distinguishing between the presence and absence of ports: this is fundamental to composite structures and too big a change for the RTF.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Issue: AssociationEnd

  • Key: UML22-20
  • Legacy Issue Number: 6462
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    PROBLEM STATEMENT
    In UML 1 the navigability of an association end was specified by the
    meta-attribute AssociationEnd.isNavigable. In UML 2 apparently this
    meta-attribute dissapears, and AssociationEnd is substituted by Property. We
    know whether an association end is navigable by the following rule: if the
    property is owned by a class, it represents a navigable end; if the property
    is owned by an association, it represents a non-navigable end (see
    Superstructure, p. 89). However, references to old metaclass AssociationEnd
    and old meta-attribute isNavigable still appear in the Spec in several
    places and OCL expressions (AssociationEnd appears in: Infrastructure, p.
    33; Superstructure, pp. 119, 245; isNavigable appears in: Superstructure, p.
    245).

    PROPOSED SOLUTION
    Add derived meta-attribute /isNavigable to metaclass Property.
    Eliminate references to AssociationEnd.

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

instantiations of Classifiers

  • Key: UML22-19
  • Legacy Issue Number: 6455
  • Status: closed  
  • Source: Anonymous
  • Summary:

    7 and 14: "An instance specification is a model element that represents an instance in a modeled system." [7.7.1] There are no objects in a UML 2 model, but only models of objects, that is, instance specifications. The instantiation of a UML class is not in the model, but in the modeled system. At the same time, "an ExecutionOccurrence is an instantiation of a unit of behavior ..." [14.3.4] Suggested resolution: Abandon the idea that there are no objects in a model. Specify that an instanceSpecification with a class is an object in the model, the instiantiation of a class is an object in the model. Likewise for an association and its links, and so on.

    This brings the theory of classifiers and their instances and instantiations into alignment with the theory of behaviors and their occurrences.

    It is consistent with the existence of power types in the language.

    It is consistent with the MOF specification of meta-layers.

    It removes the conflation of the type conformance and instatiation relationships with the representation relationship. It reduces the meanings conflated into 'instance of' by one.

    Thus, the UML places instantiations of Classifiers in the modeled system (not in the UML model) and, at the same time, places instantiations of Behaviors in the UML model (not in the modeled system).

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    The change proposed in the issue is fundamentally different than the basic interpretation of models in UML.
    Further, the assertion that UML “places instantiations of Behaviors in the UML model (not in the modeled
    system)” is not correct. An instance of a Behavior is an execution (in the modeled system), while an
    ExecutionOccurrence is a model of such an instance. This is quite similar to the difference between an
    instance and an InstanceSpecification. The UML 2.5 specification is now clearer on this.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 9.3.3

  • Key: UML22-15
  • Legacy Issue Number: 6422
  • Status: closed  
  • Source: Sparx Systems Pty Ltd ( Mr. J.D. Baker)
  • Summary:

    The Collaboration example on page 159 appears to be a CollaborationOccurrence rather than a Collaboration. I recommend that the Collaboration example be revised to a description of the Observer pattern (or some other collaboration) and the example be continued in the CollaborationOccurrence section. In addition to fixing the example, I believe it is important to make the Collaboration and CollaborationOccurrence examples cohesive

  • Reported: UML 1.5 — Tue, 4 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Original discussion:
    The submitter is incorrect in believing that the example (Figures 104 and 105) represent a collaboration occurrence. They are indeed collaborations. However, the submitter makes a good point on having a single example between the collaboration and the collaboration occurrence section. To this effect, it would be possible to update this example by replacing Figures 104 and 105 by an updated version of the example in Figure 107 (albeit one would have to add types to the parts in that example) and make it a little more interesting. The current example in Figures 104 and 105 was adapted from UML 1.4.
    New comments (March 2009):
    This issue dates back to 2003. I propose we close it on the grounds of cost/benefit.

    Revised Text:
    None.

    Disposition: Closed, no change.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/Interactions/missing OCL constraints

  • Key: UML22-14
  • Legacy Issue Number: 6409
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Not all the constraints in the Interactions section (14.3). They should be added

  • Reported: UML 1.5 — Mon, 3 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/Metamodel/redefinition and substitutability

  • Key: UML22-10
  • Legacy Issue Number: 6200
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Redefinition, as used in UML2, sometimes violates superclass substituitability rules. For example, redefining multiplicity from many to 1 breaks some OCL constraints. For example, Statemachines changed a multiplicity from many to 1. Statemachines redefines association to OwnedBehaviors to OwnedStateMachines which does not allow other types of owned behaviors.

  • Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    The specific issue with state machines no longer applies, having been resolved in an earlier RTF. The general
    issue about redefinition is a complaint about a fundamental characteristic of UML semantics which are by
    now quite well understood. Changing these semantics would be very fundamental and disruptive.
    This also resolves issue 14929.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Target pin notation

  • Key: UML22-9
  • Legacy Issue Number: 6126
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    On CallOperationAction, etc, how do you tell graphically which pin is
    the target?

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Disposition: Deferred to UML 2.4 RTF

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Notes versus curly braces

  • Key: UML22-12
  • Legacy Issue Number: 6372
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Why do decision input behaviors use the note notation and join
    specification use curly braces?

  • Reported: UML 1.5 — Mon, 20 Oct 2003 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    A decision input behavior is a behavior, and it could potentially involve a lengthy computation. A join specification is a value specification and will typically be very short, perhaps even just a single operator (the default is "and").
    Revised Text:
    None
    Disposition: Closed, no Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Activity OCL

  • Key: UML22-11
  • Legacy Issue Number: 6346
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Not all the constraints in the Activities section have corresponding OCL
    specifications. These should be added

  • Reported: UML 1.5 — Mon, 20 Oct 2003 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    This issue is obsolete. All constraints related to Activities that can be given OCL now have OCL in UML
    2.5.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML2 super/ad-03-04-01/Derived attributes and associations

  • Key: UML22-16
  • Legacy Issue Number: 6430
  • Status: closed  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    Issue: There are many places where the specification indicates that an
    attribute or association is derived, but does not state how it is derived;
    that is, the specification does not state, in English or in OCL, how to
    compute the derivation.

    Recommendation: Specify, in English and OCL, how to compute the derivations
    of all derived attributes and associations.

  • Reported: UML 1.5 — Tue, 4 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 super / Dependencies / improper subsetting?

  • Key: UML22-13
  • Legacy Issue Number: 6405
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Should Dependency::supplier subset DirectedRelationship::target and Dependency::client subset DirectedRelationship::source? Otherwise, the source and target properties of specializations that add no additional properties (e.g. Usage) will be empty...

  • Reported: UML 1.5 — Fri, 31 Oct 2003 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

State extension

  • Key: UML22-8
  • Legacy Issue Number: 6114
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    State should be an extension of type rather than object node.

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Disposition: Deferred to UML 2.4 RTF

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Semantics of firing compound transitions still appears to be circular

  • Key: UML22-1
  • Legacy Issue Number: 4110
  • Status: closed  
  • Source: Anonymous
  • Summary:

    In UML 1.4 beta R1, the semantics of firing compound transitions still appears to be circular and therefore incorrect. At any rate I am confused by the text so it may be confusing to others.

    As far as I can see the "Least Common Ancestor" is needed to determine the "main source", but actions following exit from the "main source" must be performed before the targets following a choice point are known, so without known targets there is no known LCA and therefore no specified "main source".

    On page 2-173 of 2.12:

        • The least common ancestor (LCA) state of a transition is the lowest composite state that contains all the explicit source states and explicit target states of the compound transition. In case of junction segments, only the states related to the dynamically selected path are considered explicit targets (bypassed branches are not considered).

    If the LCA is not a concurrent state, the main source is a direct substate of the least common ancestor that contains the explicit source states, and the main target is a substate of the least common ancestor that contains the explicit target states. In case where the LCA is a concurrent state, the main source and main target are the concurrent state itself. The reason is that if a concurrent region is exited, it forces exit of the entire concurrent state.

    [...]

    Once a transition is enabled and is selected to fire, the following steps are carried out in order:

    • The main source state is properly exited.

    • Actions are executed in sequence following their linear order along the segments of the transition: The closer the action to the source state, the earlier it is executed.

    • If a choice point is encountered, the guards following that choice point are evaluated dynamically and a path whose guards are true is selected.

    • The main target state is properly entered. ***

    This is certainly much better than 1.3. But I still find it difficult to follow:

    Since guards following a choice point are evaluated dynamically, the targets are still unknown when the "main source" is exited. Therefore the LCA is still unknown. How then does one determine the "main source" as a "direct substate" of the (unknown) LCA?

    The (target) "states related to the dynamically selected path" referred to above for determining the LCA cannot be determined in the case of choice points, without having first determined which branches will be taken from the choice points. That requires performing exit actions for the "main source", then additional actions along the path to the choice point, in order to determine which branch will be taken. So the "main source" must be already known in order to determine the targets.

    If one defined the "initial source" as the LCA of the source states then the "main source" might be any superstate of that "initial source".

    With different targets, there might be additional actions to "properly exit" from enclosing superstates of the "initial source" before actions along the transition to a choice point. These could affect which branch is taken and therefore which enclosing superstate of the "initial source" must be "properly exited", which would affect which actions are performed before reaching the choice, and therefore affect the branch taken from the choice.

  • Reported: UML 1.3 — Thu, 7 Dec 2000 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Remove the paragraph explaining the LCA from the “Transition execution sequence” section and add an
    explanation of LCA to the “Transition ownership” section

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2.5: UML redefinition mechanism insufficiently granular

  • Key: UMLR-616
  • Legacy Issue Number: 19732
  • Status: open  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The current mechanism for redefining the elements of a classifier is not refined enough for cases where the redefined elements are complex hierarchical namespaces. As presently defined, in those situations, the mechanism results in needless duplication that creates maintenance difficulties and excessive memory overhead.

    To illustrate the problem, take, for example, the perfectly reasonable scenario where we have a high-level (e.g., abstract) state machine (which is a kind of Class), which we would like to refine in a subclass by adding a new state to one of its nested regions. This is achieved via the state machine redefinition mechanism as specified in section 14.3 of the 2.5 spec, which is based on the standard UML::RedefinableElement abstraction. In UML, a State is part of the namespace of a Region, which is either part of the namespace of a containing hierarchical State or, in case of the topmost Region, of the StateMachine itself. To add a State using this mechanism, it is necessary to redefine (i.e., “extend”) the Region defined in the superclass to which we wish to add the new State. Unfortunately, because of the all-or-nothing nature of the current redefinition mechanism, it is not sufficient to simply define a new redefining Region and include the new State within it. Because of the insufficient granularity of UML redefinition, it is also necessary to clone all the other elements that currently exist in the redefined region (i.e., all States, Pseudostates, Transitions, etc.). Furthermore, because the redefined Region is part of a higher-level namespace (State or StateMachine), that namespace must also be redefined, since it now contains a different Region than the original one. Which, in turn, requires redefinition of the next higher namespace (with all the requisite cloning), and so on. This chain of cloning redefinitions must necessarily continue all the way up to the topmost Region of the StateMachine, terminating in an almost complete clone the original StateMachine, even though we only wanted to add a single State to the original StateMachine.

    Needless to say, cloning presents a maintenance issue, since any changes in a superclass have to be propagated to all the affected clones in all the subclasses. Even worse, this approach results in potentially large and completely unnecessary memory overheads.

    It seems that redefinition should be based on an incremental approach, just like inheritance. That is, only the differences from the redefined element should be explicitly specified in the redefining element, while everything else existing in the namespace of the redefined element should be implicitly “inherited”.

  • Reported: UML 2.5 — Tue, 3 Mar 2015 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT


Missing Example of TemplateBinding with model element "Class"

  • Key: UMLR-421
  • Legacy Issue Number: 19723
  • Status: open  
  • Source: gmail.com ( Jose Asdrubal Asencio)
  • Summary:

    I've been reviewing template binding where specifies substitution of Parameters in a Template Class and I found that:

    1- UML 2.5 haven't provided an example using class element model with binding relationship.

    2- UML 2.5 haven't provided an example, and example in code in whatever language programming or a note where explain what does it mean binding in code.

    I 've reviewed examples at Internet and there are not good examples relate with binding. Just very basic examples.

  • Reported: UML 2.5b1 — Mon, 16 Feb 2015 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Object Flow arrow heads are inconsistent: V-shaped vs triangular

  • Key: UMLR-415
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    in Figure 15.53, the object flow use solid arrow heads, though it the rest of the activity diagram material, the arrow heads are v-shaped. Please correct or clarify.

  • Reported: UML 2.5 — Wed, 28 Jan 2015 20:29 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

More on SateMachines

  • Key: UMLR-410
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    "An internal Transition can be taken even if the SateMachine is in one or more Regions nested within the associated State."

    Please correct spelling error

  • Reported: UML 2.5 — Thu, 15 Jan 2015 02:19 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Figure 14.5 State with Compartments does not show all the compartments that it should

  • Key: UMLR-409
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Before Figure 14.6. the text says:

    A State may be subdivided into multiple compartments separated from each other by a horizontal line (Figure 14.6).

    Immediately after Figure 14.6, the four compartments of a state are defined.

    • name
    • internal Behaviors
    • internal Transitions
    • decomposition

      However, in the Figure, the internal Behaviors and internal Transitions are in the same compartment. It appears that the line between the name compartment and the remaining compartments is required but the line between the internal Behaviors and Transition is not required.

    This should be made clear.

    Also, the example has the items in the state in the order that the compartments would be defined. Is this required? Can I mix them if no separate compartment is used?

  • Reported: UML 2.5 — Wed, 14 Jan 2015 22:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

BNF notation as given and used is unclear about italics

  • Key: UMLR-408
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    In the description of our BNF format page 9.

    Bullet 1.
    All non-terminals are in italics and enclosed between angle brackets (e.g., <non-terminal>).

    The Angle brackets are given in Roman (non-italic) font, however (almost) all uses have italic angle brackets. See example, indicated below for multiplicity_range

    Bullet 2.
    All terminals (keywords, strings, etc.), are enclosed between single quotes (e.g., ‘or’).
    The example uses Roman font, but almost all uses have the terminals in italic anyway. The quotes are also in Roman

    Bullet 3
    Non-terminal production rule definitions are signified with the ‘::=’ operator.
    The ::= operator is always used in italics.

    Bullet 4
    Repetition of an item is signified by an asterisk placed after that item: ‘*’.
    The * is roman, but it (always?) appears in italic

    Bullet 5
    Alternative choices in a production are separated by the ‘|’ symbol (e.g., <alternative-A> | <alternative-B>).
    The | is in roman, but it is used in italic

    Bullet 6
    Items that are optional are enclosed in square brackets (e.g., [<item-x>]).
    This is in italics, and coincidently, it is always used in italics. However, based on bullet 1, the angle brackets should be in roman.

    This confusion is throughout the spec and makes implementation harder.

    For example in 7.5.4, where the BNF definition of multiplicity range is given at
    <multiplicity-range> ::= [ <lower> ‘..’ ] <upper>

    Bullet 1 rules. The < and > are given in italics violating Bullet 1

    Bullet 2 rules
    In this case, the ".." is given as italics (both the .. and the quotes).
    Does this mean that all multiplicities that use the .. should have them in italics?
    Bullet 3 rules. The ::= is given in italics

    Using the example also on the 7.5.4 for the definition of order-designator
    <order-designator> ::= ‘ordered’ | ‘unordered’
    Bullet 2, As ordered and unordered are terminals this indicates that the terms ordered and unordered should be shown in italics. IN the figure below 7.11 they are shown in roman.
    Rules from Bullet 3 and 5 are also violated.

  • Reported: UML 2.5 — Wed, 14 Jan 2015 21:48 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Figure 14.14 includes a "Submachine Sate"

  • Key: UMLR-407
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Spelling Error in Figure title

  • Reported: UML 2.5 — Wed, 14 Jan 2015 20:56 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

InformatonFlows are constrained to be Classes or Classifiers -- which one?

  • Key: UMLR-418
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    "20.1.3 InformationItems may be decomposed into more specific InformationItems or Classifiers

    InformationItems may only be realized by Classes (of all kinds, including Components, AssociationClasses, Behaviors, etc.), Interfaces, Signals, and other InformationItems"
    ..
    Shoun't the word "Classes" in the 2nd paragraph above be changed to "Classifiers" This whole section seems to be unclear about this.

  • Reported: UML 2.5 — Mon, 9 Feb 2015 20:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Are DeploymentSpecification execution-time input to components -- meaning they are somehow read by the component while they are running/executng?

  • Key: UMLR-417
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    in 19.2.3 [Deployments] Semantics there is the following claim:
    "DeploymentSpecification information becomes execution-time input to components associated with DeploymentTargets via their deployedElements links."

    Is this saying something about the deployed system must work, that it must have accessibility to the model?

    Please clafiry

  • Reported: UML 2.5 — Mon, 9 Feb 2015 19:53 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Can be performed their instances --> missing "by"

  • Key: UMLR-416
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    that can be performed by their instances

    missing word

  • Reported: UML 2.5 — Mon, 9 Feb 2015 19:41 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

A State can only have one Do/ behavior, but example shows more than one.

  • Key: UMLR-413
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Figure 14.1 Behavior StateMachines indicates only 0..1 Entry, Do and Exit behavior for a state.

    However, Figure 14.10 has an exit behavior as
    exit / exit/ turn off main light; turn off secondary

    It is unclear whether list of behaviors (separated by are to be executed serially or in parallel.

    I suggest that both serial and parallel syntax be supplied and Figure 14.1 (and elsewhere) be modified to indicate more than one behavior is allowed.

    Else (and less useful) Figure 14.10 has to be fixed

  • Reported: UML 2.5 — Wed, 21 Jan 2015 05:53 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Some hyperlinks are underlined and some are not. This is inconsistent

  • Key: UMLR-412
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    For example, see 15.2.3 Semantics
    On this page there are
    references to sub clause 15.4 (2x)
    sub clause 7,4
    and sub clause 13.2
    They are all hyperlinks, but only the last two are blue and underlined. The first two are in normal text font.

  • Reported: UML 2.5 — Wed, 21 Jan 2015 05:37 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML 2.5: Property::isConsistentWith() error

  • Key: UMLR-424
  • Legacy Issue Number: 19726
  • Status: open  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    There appears to be an error in the Property::isConsistentWith() operation (page 155 of the 2.5 spec). As written, it looks like this (with a bit of my editing for readability) :

    isConsistentWith(redefiningElement : RedefinableElement) : Boolean

    {redefines RedefinableElement::isConsistentWith()}

    // The query isConsistentWith() specifies, for any two Properties in a context in which
    // redefinition is possible, whether redefinition would be logically consistent. A redefining
    // Property is consistent with a redefined Property if the type of the redefining Property
    // conforms to the type of the redefined Property, and the multiplicity of the redefining
    // Property (if specified) is contained in the multiplicity of the redefined Property.

    pre: redefiningElement.isRedefinitionContextValid(self)
    body: redefiningElement.oclIsKindOf(Property) and
    let prop : Property = redefiningElement.oclAsType(Property) in
    (prop.type.conformsTo(self.type) and
    ((prop.lowerBound()>notEmpty() and self.lowerBound()>notEmpty()) implies
    prop.lowerBound() >= self.lowerBound()) and
    ((prop.upperBound()>notEmpty() and self.upperBound()>notEmpty()) implies
    prop.lowerBound() <= self.lowerBound()) and
    (self.isComposite implies prop.isComposite))

    The problem is with the second last line, which should read:

    prop.upperBound() <= self.upperBound())

    Seems like a copy-paste error.

  • Reported: UML 2.5 — Fri, 20 Feb 2015 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML 2.5 beta issue - Operation notation is wrong

  • Key: UMLR-423
  • Legacy Issue Number: 18611
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    There is a paragraph in Operation notation 9.6.4 that says this:

    “The return result of the Operation may be expressed as a return parameter, or as the type of the Operation. For example toString(return: String) …”

    This is wrong. If it means anything, it means an in parameter called return. The BNF does not allow return as a term for <direction>, but if it did, then the correct example would be this:

    toString(return result : String)

  • Reported: UML 2.5b1 — Tue, 2 Apr 2013 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML2::Constraint

  • Key: UMLR-422
  • Legacy Issue Number: 14430
  • Status: open  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Sebastien Gerard)
  • Summary:

    When modelling a constraint in UML on several constrained elements, how is itpossible to know which constrained element is the context of the constraint?

    In the spec, the metaattribute context of Constraint is derived, but the spec does not define how it is derived.

  • Reported: UML 2.2 — Tue, 22 Sep 2009 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

These are typographical errors

  • Key: UMLR-411
  • Legacy Issue Number: 19710
  • Status: open  
  • Source: Anonymous
  • Summary:

    Page 97, Line 16: The parameters to the operation -> The parameters of the operation

    Page 173, Line 11: profile?s -> profile's

    Page 190, Figure 12.11: volume; JavaInteger -> volume: JavaInteger

    Page 194, Line 27: stereotype?s -> stereotype's

  • Reported: UML 2.5 — Fri, 16 Jan 2015 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Shouldn't it be possible to make the state of an object be private to support encapsulation/information hiding?.

  • Key: UMLR-403
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    From the following
    "A guard constraint may involve tests of orthogonal States of the current StateMachine, or explicitly designated States of some reachable object"

    it appears, that no matter how reachable object is defined (see UMLR-402), if it is reachable, the state is accessible. This seems to go against the principles of encapsulation and information hiding. We can make all the attribute of an object private, but the state, which is a often defined by the values of the attributes can't be made private

    My age may be private, but the fact that I'm in the state of being a teenage must be public? <wishful thinking perhaps>

    There should be some way of making an object's state private.

  • Reported: UML 2.5 — Tue, 13 Jan 2015 14:19 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

States of Reachable objects may be used in guard constraints, but reachable is not defined

  • Key: UMLR-402
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    "A guard constraint may involve tests of orthogonal States of the current StateMachine, or explicitly designated States of some reachable object."

    Unfortunately, reachable is only used in one other spot in the specification where it is also of no help.

    Are all objects reachable? Does it depend on whether there is a chain of relationships, does it depend if the object is in a publicly available package...

  • Reported: UML 2.5 — Tue, 13 Jan 2015 14:12 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Any Activity parameter is steaming. It must be too hot to handle

  • Key: UMLR-414
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    under Activity Parameter Nodes, when describing Figure 15.52, the text indicates a "steaming Parameter"

    Please correct

  • Reported: UML 2.5 — Tue, 27 Jan 2015 19:59 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

adding error

  • Key: UMLR-405
  • Legacy Issue Number: 19696
  • Status: open  
  • Source: gmx.de ( Dr. Götz Wankelmuth)
  • Summary:

    There seems to be an error in the latest UML 2.5 spec:
    16.13.5 Examples
    A ReduceAction can be used to reduce a list of numbers to the sum of the numbers. Such a ReduceAction has one InputPin for a collection of numbers, one OutputPin for a number and an addition function as the reducer Behavior. For example, suppose the input collection has four integers: (2, 7, 5, 3). The result of applying the ReduceAction to this collection with an addition function is 11. With the default of isOrdered=false, this can be computed in a number of ways, for example, ( ( (2+7) + 5) + 3), (2 + (7 + (5 + 3))), ((2 + 7) + (5 + 3)).
    If I understand the text correctly, the result must be 17.
    Please reply to this mail because I use the Beta 2 spec in my courses.
    Sicerely yours,
    Mit freundlichen Grüßen,
    Götz Wankelmuth

  • Reported: UML 2.5 — Mon, 22 Dec 2014 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

orthogonal State missing on bullet point list

  • Key: UMLR-401
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Axel Scheithauer)
  • Summary:

    On page 322 there is a bullet point list

    • simple State (isSimple = true)
    • composite State (isComposite = true)
    • submachine State (isSubmachineState = true)

    The entry

    • orthogonal State (isOrthogonal = true)
      is missing (but mentioned in the following paragraph).
      It is a special kind of composite State, so this could be a reason to leave it out from the list. However, I think it is distinct enough from the other three, and is even given a derived property, so it probably should also be in the list.
  • Reported: UML 2.5 — Thu, 8 Jan 2015 19:53 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Use of Qualifier and Qualified in same section of UML 2.5 spec should be more clearly disambiguated

  • Key: UMLR-391
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    In Section 9.5, there are several statements mentioning "qualifiers"
    e.g.,
    A Property that is a memberEnd may itself have other Properties that serve as qualifiers.
    and
    The notation for qualifiers is defined in 11.5 Associations.

    However, there are several statements mentioning "qualified"
    e.g.,

    • 'subsets’ <property-name> means that the Property is a proper subset of the Property identified by <property-name>, where <property-name> may be qualified.
    • ‘redefines’ <property-name> means that the Property redefines an inherited Property identified by <property-name>, where <property-name> may be qualified.

    I suspect they are discussing different things. A qualified name vs an association end qualifier.

    Please have mercy on us and make the usages clearer.
    Thanks

  • Reported: UML 2.5 — Thu, 20 Nov 2014 18:42 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML needs standardized default package (or Model)

  • Key: UMLR-386
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    All elements in UML, except for some top-level packages, must be owned by some other element. This means that people who create models without specifying the owning element chain are creating invalid models, that are incapable of being exchanged.

    Some tools automatically supply a default owning package, which makes the model valid. However, the tools do not agree on the owning package name or whether it a <<model>>> (stereotyped package)

  • Reported: UML 2.5 — Tue, 11 Nov 2014 04:18 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

shoes-->shows

  • Key: UMLR-387
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    In section 7.6.5 the statement under figure 7.14 says:

    Figure 7.15 shoes a constraint string attached to an attribute

    I assume that shoes->shows

  • Reported: UML 2.5 — Thu, 13 Nov 2014 08:28 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

In Sequence diagrams it is unclear if the name of the Gate can be different from the name of the message

  • Key: UMLR-380
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Formal Gate
    A formal Gate is just a point on the inside of the frame, as the end of a message. They may have an explicit name (see Figure 17.4).

    1) The word "they" should probably be "it".
    2) However, the gate and the message are different nameable items. The examples, in Figure 17.3,4, and 5 all have one name which appears to be the name of the message.

    All three examples,should be clarified, and at least one having both the message and gate named differently.

    In the description of Figure 17.3, the gate is given the implicit name of out_Unlock. In an almost identical Figure 17.5, the description says the gate name is Unlock. Which is it?

  • Reported: UML 2.5 — Wed, 29 Oct 2014 23:07 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Inconsistent use of Oxford comma in "Behavior, Event, and Trigger"

  • Key: UMLR-361
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    In 13.1
    paragraph 2
    "UML provides Behavior, Event, and Trigger"
    but in paragraph 6.
    "UML Modeling mechanisms of Behaviors, Events and Triggers"

    They should be the same format, preferably using the Oxford comma as is done in most other places.

  • Reported: UML 2.5 — Wed, 15 Oct 2014 18:37 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

AcceptEventActions where the triggers are all for ChangeEvents or CallEvents should allow output ControlPins

  • Key: UMLR-358
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    AcceptEventActions that wait on ChangeEvents are prohibited from having result OutputPins.

    Why can't they have control output pins?

  • Reported: UML 2.5 — Wed, 8 Oct 2014 20:22 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Minor error in ptc-13-09-05

  • Key: UMLR-360
  • Legacy Issue Number: 19637
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    In ptc-13-09-05.pdf on page 9 it says:

    Where items need to be grouped they are enclosed in simple parenthesis; for example:

    (<item-1> | <item-2>) *

    signifies a sequence of one zero or more items, each of which is <item-1> or <item-2>.

    I think the word one must be replaces by zero because on page 28 it says:

    If the lower bound is equal to the upper bound, then an alternate notation is to use a string containing just the upper bound. For example, “1” is semantically equivalent to “1..1” multiplicity. A multiplicity with zero as the lower bound and an unspecified upper bound may use the alternative notation containing a single star “” instead of “0..” multiplicity.

  • Reported: UML 2.5 — Fri, 10 Oct 2014 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Pin multiplicity and token upper bound

  • Key: UMLR-352
  • Legacy Issue Number: 19564
  • Status: open  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    I'm a little confused about the relationship between the multiplicity
    of a Pin and its token upper bound. What does it mean for the token
    upper bound to be less than the multiplicity upper bound, or even
    the multiplicity lower bound?

  • Reported: UML 2.5 — Fri, 25 Jul 2014 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Classifier::ownedTemplateSignature needs to subset Element::ownedElement

  • Key: UMLR-346
  • Legacy Issue Number: 19511
  • Status: open  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    UML composite properties must subset Element::ownedElement.
    Classifier::ownedTemplateSignature doesn't.

    Note that issue 12244 suggested making a change to replace
    the ownedElement subset with a redefinition of another
    property. By 2.5 the change had already been made, so
    the issue was closed no change in ballot 1. However it was
    never the correct thing to do as the previously resolved
    general composite issue 14926 pointed out.

  • Reported: UML 2.5 — Mon, 7 Jul 2014 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Issue against UML: implementation of OCL constraint containingProfile

  • Key: UMLR-345
  • Legacy Issue Number: 19488
  • Status: open  
  • Source: NIST ( Mr. Peter Denno)
  • Summary:

    Problem: Recursion in calls to the OCL operation containingProfile() does not properly terminate.

    Current OCL in the spec for Stereotype.containingProfile():
    self.namespace.oclAsType(Package).containingProfile()
    The problem with this is that the argument won't be seen as a Profile after oclAsType(Package).

    I suggest instead this OCL for Stereotype.containingProfile():
    if self.namespace.oclIsKindOf(Profile)
    then self.namespace
    else self.namespace.containingProfile()
    endif

    Current OCL in the spec for Package.containingProfile():
    if self.oclIsKindOf(Profile)
    then self.oclAsType(Profile)
    else self.namespace.oclAsType(Package).containingProfile()
    endif

    I suggest instead this OCL for Package.containingProfile():
    if self.oclIsKindOf(Profile)
    then self
    else self.namespace.containingProfile()
    endif

    There still may be problems if, for example, a Classifier (or other subtypes of Namespace) were a namespace for a Package. In those cases (which I assume don't really happen), we would need additional containingProfile() methods like the one on Package.

  • Reported: UML 2.5 — Wed, 25 Jun 2014 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

No specification of which visibility marking corresponds to which VisibilityKind value

  • Key: UMLR-344
  • Legacy Issue Number: 19472
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    Nowhere does the spec say which visibility marking corresponds to which value. There is no specification that # means protected, for example. This would best live in 7.4.4.

  • Reported: UML 2.5 — Mon, 16 Jun 2014 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

ExpansionNodes owned by ExpansionRegions?

  • Key: UMLR-340
  • Legacy Issue Number: 19438
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Are ExpansionNodes owned by their ExpansionRegions? ENs are pin-like, so it seems like they should be, but then I would have expected ER::in/outputElement and EN::regionAsIn/Output to be subsetted from StructuredActivityNode::node and ActivityNode::inStructuredNode, respectively. ENs could still be owned by ERs as SANs without the subsetting, but I couldn't find what the spec says about it. Is there a MIWG test for this case?

    Ed S's response:http://www.omg.org/archives/model-interchange/msg02614.html

  • Reported: UML 2.5 — Fri, 30 May 2014 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Incorrect sentence

  • Key: UMLR-339
  • Legacy Issue Number: 19430
  • Status: open  
  • Source: toshiba-tsip.com ( VIRESH MOHAN)
  • Summary:

    v=mymsg(w=myout:16):96 // this is a reply message assigning the return value 69 to ‘v’ and // the value 16 for the out parameter ‘myout to ‘w’.

    The return value is 96 but the comment suggests 69 is getting assigned to v.

  • Reported: UML 2.5b1 — Thu, 22 May 2014 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

BehavioralParameter should be BehavioralFeature

  • Key: UMLR-342
  • Legacy Issue Number: 19455
  • Status: open  
  • Source: Fraunhofer FOKUS ( Mr. Marc-Florian Wendland)
  • Summary:

    In Section 13.4, Subsection Behavior, Subsubsection Constraints, the Constraint parameters_match says in the second sentence:

    “The Behavior Parameters must also "match" the BehavioralParameter Parameters, but the exact requirements for this matching are not formalized.”

    BehavioralParameter is not correct and should say BehavioralFeature.

  • Reported: UML 2.5 — Sat, 7 Jun 2014 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML wording in Superstructure 2.4.1

  • Key: UMLR-341
  • Legacy Issue Number: 19454
  • Status: open  
  • Source: Anonymous
  • Summary:

    I have a comment concerning wording in the UML 2.4.1 Superstructure document
    you are using both "classifier rectangle" and "class rectangle" for describing
    presentation options. Is this really appropriate?
    I'd like to suggest to use "classifier rectangle" consistently since
    there is no
    special representation shape of a class, and class is a specialization
    of classifier.
    Additionally, at page 152, you give "Classifier rectangle" with
    capital letter.
    I think that, in terms of consistency, it should be "classifier
    rectangle" there as well.

  • Reported: UML 2.5 — Thu, 5 Jun 2014 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Message should extend Namespace

  • Key: UMLR-337
  • Legacy Issue Number: 19422
  • Status: open  
  • Source: Fraunhofer FOKUS ( Mr. Marc-Florian Wendland)
  • Summary:

    Messages in Interactions should extend Namespace similarly as Transition extends Namespace. Being a Namespace (would be backwards compatible) would make it possible to specify Constraints among Parameter of the Signature merely in the context of the particular Message and in addition to the Constraints already applied on the signature itself. This would enable testers to specify fine-grained interdependencies among Parameter (and for argument generation) in that particular situation. Such a feature on Messages would be actually quite handy for test generation purposes – also, similar to what is currently already possible and being done with Transitions.

    Any thoughts on that?

  • Reported: UML 2.5 — Mon, 14 Apr 2014 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Semantics of static features

  • Key: UMLR-343
  • Legacy Issue Number: 19468
  • Status: open  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    “In §9.4.3, the following sentence: “The isStatic property specifies whether the characteristic relates to the Classifier’s instances considered individually (isStatic=false), or to the Classifier itself (isStatic=true)” may suggest that a static feature cannot relates to the instances of this classifier. This does not seem to be the intent. If so, improve the sentence. Otherwise explain how the semantics of a property which have the same value for all the instances of a classifier shall be modeled.”

  • Reported: UML 2.5 — Fri, 27 Jun 2014 11:17 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Incomplete sentence

  • Key: UMLR-338
  • Legacy Issue Number: 19427
  • Status: open  
  • Source: toshiba-tsip.com ( VIRESH MOHAN)
  • Summary:

    In the explanation for "Entering a State" concept w.r.t. alternate entry points for a composite state, it appears that the description for "Entry point entry" is not a complete sentence.

    Entry point entry:

  • Reported: UML 2.5b1 — Wed, 21 May 2014 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Rg. Reception.ownedParameter

  • Key: UMLR-305
  • Legacy Issue Number: 19194
  • Status: open  
  • Source: Fraunhofer FOKUS ( Mr. Marc-Florian Wendland)
  • Summary:

    in conjunction with the Message signature issue, I was wondering whether Reception should redefine BehavioralFeature.ownedParameter. In contrast to Operation.ownedParameter (that already redefines BehavioralFeature.ownedParameter), Reception.ownedParameter would have to be derived an read-only, since the number and characteristics of the parameters are completely derived from the Properties of the Signal referenced by the Reception.

    As a matter of fact, with the invariant ‘same_structure_as_signal’ there is already an explicit derivation algorithm given. This one could be the basis for developing the body expression of the derived, read-only Reception.ownedParameter.

    In my opinion, everything that can be expressed by means of the metamodel, should be expressed in the metamodel and not with additional Constraints.

  • Reported: UML 2.5 — Thu, 16 Jan 2014 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Generalization should be limited to relate similar UML-elements

  • Key: UMLR-308
  • Legacy Issue Number: 19209
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Axel Scheithauer)
  • Summary:

    The Generalization relationship can be used between instances of all subclasses of the metaclass Classifier. At least in the chapter on Generalization there is no constraint given. Thus it is allowed to have a generalization between an Activity and a signal. This definitely makes no sense. Does it make sense to have a generalization between an Activity and a Class? What does that mean for the instances?

    The only Metaclass that defines a constraint for Generalizations seems to be Stereotype (page 293).

    Tools seem to enforce, that only instances of Metaclasses, that are in a Generalization relationship on the meta level may have Generalization relationships on the model level. I'm not sure, whether this makes sense. Anyway, I couldn't find anything in the specification supporting this view.

    Suggestion:
    Add a constraint to Generalization, that limits the related elements to be of the same or compatible Metaclasses.

  • Reported: UML 2.5 — Mon, 10 Feb 2014 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Type conformance for classifiers

  • Key: UMLR-307
  • Legacy Issue Number: 19202
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Subclause 9.2.3 (Semantics), Generalization, sixth paragraph, last sentence ("A Classifier is a Type, and conforms to itself and to all of its generalizations.") contradicts the previous sentences. Classifiers conform to their metaclassifiers, not necessarily themselves or their generalizations. This sentence might have been intended to refer to the instances of a classifier.

  • Reported: UML 2.5 — Mon, 3 Feb 2014 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Notation for PrimitiveTypes

  • Key: UMLR-300
  • Legacy Issue Number: 19188
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Latest UML 2.5 spec has

    In 21 Primitive Types 21.3 Notation

    “There is no notation for PrimitiveTypes. There is notation for literal values of PrimitiveTypes; this notation is covered in Clause 8.2.”

    However, in Figure 21.1 Primitive Types, there appears to be notation for PrimtitveTypes. And explicitly in 10.2.5 Examples

    “Figure 10.2 illustrates the notation for defining a PrimitiveType”

    Similarly in 10.2.4, a notation for PrimitiveType is described.

    So which is it? Is there notation for PrimitiveType or not? This needs to be made clear.

    Perhaps what is meant is “There is no notation for defining literals of any new (modeler-defined) PrimitiveType.” And replace the 2nd sentence with “There is notation for literal values of the UML-supplied PrimitiveTypes; this notation is covered in Clause 8.2.”

  • Reported: UML 2.5 — Fri, 17 Jan 2014 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Problems with normative UML 2.5 Beta 2 Standard profile


Descriptions missing for PseudostateKind literals

  • Key: UMLR-304
  • Legacy Issue Number: 19193
  • Status: open  
  • Source: Eclipse Foundation ( Mr. Kenneth Hussey)
  • Summary:

    Descriptions are missing for PseudostateKind enumeration literals, as are comments for those elements in the normative machine consumable file for UML, available at http://www.omg.org/spec/UML/20131001/UML.xmi (see related issue 17978).

  • Reported: UML 2.5 — Wed, 22 Jan 2014 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Clause 21 Primitive Types is misnamed

  • Key: UMLR-303
  • Legacy Issue Number: 19191
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Clause 21 is titled Primitive Types. However the content describes only the predefined types of UML that are located in the PrimitiveTypes package. The section should be titled, Primitive Types Package (or similar.

  • Reported: UML 2.5 — Fri, 17 Jan 2014 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Problem with NamedElement::clientDependency subsets in UML 2.5 Beta 2

  • Key: UMLR-298
  • Legacy Issue Number: 19186
  • Status: open  
  • Source: Eclipse Foundation ( Mr. Kenneth Hussey)
  • Summary:

    NamedElement::clientDependency is derived (see issue 15056) but the following subsets are not:

    Artifact::manifestation
    BehavioredClassifier::interfaceRealization
    Classifier::substitution
    DeploymentTarget::deployment

    IMHO, this defeats the intent of the resolution since one still has to "modify the model" in order to set up these special kinds of dependency. Besides, I don't know what it means for a non-derived property to subset a derived property which is not a union...

  • Reported: UML 2.5 — Fri, 17 Jan 2014 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Can PrimitiveTypes be user-defined and where?

  • Key: UMLR-301
  • Legacy Issue Number: 19189
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    In 10.2.3 it says that

    “A PrimitiveType defines a predefined DataType, without any substructure.”

    What does it mean to be “predefined” If a PrimitiveType is predefined, then how can it be defined by a modeler? I recommend that the word “predefined” be deleted from this sentence. In addition, the general impression is that the PrimitiveTypes are only located in the PrimitiveType package and cannot be anywhere else

    Though based on a statement in Profile a PrimitiveType could be in a profile, though it couldn’t be used in a model «grin».

  • Reported: UML 2.5 — Fri, 17 Jan 2014 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

A PrimitiveType can/cannot have owned attributes.

  • Key: UMLR-302
  • Legacy Issue Number: 19190
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    A datatype can have ownedAttributes. A primitivetype is a subclass of Datatype, so it can have owned attributes. However a primitive type cannot have any substructure. Unfortunately “substructure” is not defined.

    This is repeated by the by the classifier definition for PrimitiveType[Class] however there is no OCL that enforces any restriction.

    Either eliminate the restriction or define substructure and write some OCL.

  • Reported: UML 2.5 — Fri, 17 Jan 2014 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

InstanceSpecification validity is not modelable

  • Key: UMLR-310
  • Legacy Issue Number: 19254
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    InstanceSpecifications may be used to indicate intermediate states in a transaction and so may not necessarily be valid.

    InstanceSpecification may be used to create test models and so should necessarily be valid.

    It is not easy for tooling to detect which is the design intent.

    Suggest adding an InstanceSpecification::isValidatable property to enable tools to behave usefully.

  • Reported: UML 2.5 — Fri, 21 Feb 2014 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Missing OpaqueXXX body constraint

  • Key: UMLR-309
  • Legacy Issue Number: 19253
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    Presumably a well-formed UML model should have well-formed content, so surely there should be an OpaqueAction/Behavior/Expression constraint that requires the body to be well-formed in its corresponding language?

  • Reported: UML 2.5 — Fri, 21 Feb 2014 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML Appendix A: After Figure A.4

  • Key: UMLR-259
  • Legacy Issue Number: 16484
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    There is a list of possible namespaces that are suitable for appearing in the package header (containing • activity • class • component • deployment • interaction • package • state machine • use case)

    It seems to me that there are other possible namespaces that could be diagramed. For example

    Model, Node, Datatype, etc.

  • Reported: UML 2.5 — Tue, 2 Aug 2011 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML: unification of OCL declarations

  • Key: UMLR-258
  • Legacy Issue Number: 16357
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    UML supports declarations of elements with multiplicity bounds; OCL does not
    OCL supports declarations of nested collections; UML does not

    A possible unification of the capabilities/syntaxes could be achieved by UML introducing Bag/OrderedSet/Sequence/Set as alternatives for

    {ordered,unique}

    etc and OCL adopting <> brackets and multiplicity qualification.

    Concrete Syntax
    -----------------------

    The syntax is not obvious

    All of Set<Type[0..5]> or Set<Type>[0..5] or Set<Type : 0..5> or Set[0..5]<Type> could be a bounded Set.

    All of Set<Set<Type[0..5]>[0..5]> or Set<Set<Type>[0..5]>[0..5] or Set<Set<Type : 0..5>: 0..5> or Set[0..5]<Set[0..5]<Type>> could be a 2D bounded Set.

    Set[0..5]<Set[0..5]<Type>> seems to best localize the multiplicity for the collection-type.

    Abstract Syntax
    ----------------------

    UML embeds its 'collection' declaration in a MultiplicityElement, which doesn't scale to nested collections. MultiplicityElement is a nuisance for OCL since it provides an alternate form of collection declaration to the CollectionType type constructor. A unified behaviour could deprecate MultiplicityElement and introduce a CollectionType type constructor with ordered, unique, lower, upper in addition to signature attributes.

    Nullable Unit Collection Semantics
    -----------------------------------------------

    So far so good, but there is an OCL semantic issue that is exposed by a compatibility conversion of MultiplicityElement.

    Currently MyType[0..1] is a nullable non-collection, so an OCL navigation of an unspecified value gives a null, which crashes any navigated collect iteration such as a->collect(b)->collect(c). A crash on a null object is confusing with respect to an empty collection for which iterations just skip the empty. Deprecating MultiplicityElement would convert MyType[0..1] to Set[0..1]<MyType>; clearly a collection not an object, which avoids the value-dependence that a MultiplicityElement that happens to have a unit upper bound is not a Collection. There is now no way to express a nullable object, so perhaps a

    { nullable }

    constraint can be supported. This restores the semantic coverage and conversion compatibility: [1] is ignored, [0..1] is treated as

    {nullable} and other multiplicities become correspondingly bounded collections. This also has the benefit that ordered and unique would cease to have any relevant semantics for non-collection objects thereby eliminating OCL's dilemma as to whether a [1] { ordered, unique } should be converted to a unit OrderedSet rather than a unit Set by the -> operator.


    However, we can now wonder what the difference is between MyType{nullable}

    and Bag[0..1]<MyType> and why modelers should prefer one or the other. A difference is that in OCL a->collect(b)->collect(c) will crash if b is a null MyType

    {nullable} whereas it will skip over a null for the empty collection. This seems really bad; a collect over a structurally valid model crashes. But is this OCL just throwing a problem over the fence to UML? Perhaps the problem is that OCL 2.3 has still not resolved the distinct semantics of null and invalid. Perhaps, since OclVoid conforms to all types, null has null/empty values of all properties with a 0 lower bound. Therefore null.oclAsType(NamedElement).name could be null rather than invalid, and so a->collect(b)->collect(c) should crash on invalid structures, but return a result including interspersed nulls for intermediate collects at null nullable elements.


    So the difference between MyType{nullable}

    and Bag[0..1]<MyType> is that:

    MyType

    {nullable}

    is what modelers will normally use. It is an object that may be null and always participates in an iteration as exactly one value, which may be null which may in turn participate in strucyurally valid iterations.

    Bag[0..1]<MyType> is a clumsy but consistent alternative. It is a unit collection that may be empty and only participates in an iteration when not empty.

  • Reported: UML 2.5 — Fri, 8 Jul 2011 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Clarification about serializing the application of SysML 1.3 to a UML2.4.1 model

  • Key: UMLR-260
  • Legacy Issue Number: 16567
  • Status: open  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    SysML 1.3 – http://www.omg.org/cgi-bin/doc?ptc/2011-08-10 – is defined as an extension of UML 2.4.1
    What is the XMI serialization of applying the profile to a UML 2.4.1 Package?

    The XMI serialization of the application of a profile in UML 2.4.1, section 18.3.7, was written at a time when UML2.0 required Stereotypes to be directly contained in a Profile. UML 2.3 relaxed this. According to the Stereotype semantics defined in UML 2.4.1 (18.3.9), a Stereotype may be contained in a Profile or a Package which defines the namespace for the Stereotype.

    The XMI serialization in 18.3.7 is defined by a contrived example where a Stereotype is directly contained in its Profile (see Figs. 18.8, 18.9). SysML 1.3 has several nested packages (see Fig 4.3 in SysML 1.3) Neither UML 2.4.1 nor XMI 2.4.1 clearly address how the serialization of the application of Package-nested Stereotypes works.

    For SysML 1.3, the XMI published for the SysML profile itself looks like this:

    <?xml version="1.0" encoding="UTF-8"?>
    <xmi:XMI xmlns:xmi="http://www.omg.org/spec/XMI/20110701"
    xmlns:mofext="http://www.omg.org/spec/MOF/20110701"
    xmlns:uml="http://www.omg.org/spec/UML/20110701">
    <uml:Profile URI="http://www.omg.org/spec/SysML/20110919/SysML" xmi:type="uml:Profile"
    xmi:id="OMG_SysML_20110919_SysML_0"
    name="SysML"
    visibility="public">
    ...
    <packagedElement xmi:type="uml:Package" xmi:id="_OMG_SysML_20110919_SysML_Blocks" name="Blocks">
    ...
    <packagedElement xmi:type="uml:Stereotype" xmi:id="_OMG_SysML_20110919_SysML_Blocks-Block"
    name="Block">
    ...
    </packagedElement>
    ...
    </packagedElement>
    </uml:Profile>
    <mofext:Tag xmi:type="mofext:Tag" xmi:id="OMG_SysML_20110919_SysML_2"
    name="org.omg.xmi.nsPrefix"
    value="SysML"
    element="OMG_SysML_20110919_SysML_0"/>
    </xmi:XMI>

    Given the fact that, per the MOF/XMI 2.4.1 specification, only the toplevel UML Package Namespace maps to an XMI Document Namespace,
    it follows that nested UML Package Namespaces have no corresponding XML Namespace declaration.

    This means that SysML's Blocks Package cannot have any XML Namespace declaration per current MOF/XMI 2.4.1 rules.
    Therefore, the only possible serialization for this example is the following:

    <xmi:XMI
    ....
    xmlns:SysML="http://www.omg.org/spec/SysML/20110919/SysML"
    ....
    >
    <uml:Package name="A" ........>
    ....
    <packagedElement xmi:type="uml:Class" xmi:id="123" name="B"
    ....
    </uml:Package>
    ....
    <SysML:_OMG_SysML_20110919_SysML_Blocks-Block base_Class="123" xmi:id="456" ... />
    ....
    </xmi:XMI>

    This particular serialization may be surprising to some who might have expected:

    <xmi:XMI
    ....
    xmlns:SysML="http://www.omg.org/spec/SysML/20110919/SysML"
    ....
    >
    <uml:Package name="A" ........>
    ....
    <packagedElement xmi:type="uml:Class" xmi:id="123" name="B"
    ....
    </uml:Package>
    ....
    <SysML:Block base_Class="123" xmi:id="456" ... />
    ....
    </xmi:XMI>

    The familiar-looking XMI serialization assumes that all UML CLassifiers in scope of a Profile have unique XMI:id values. The reason is very subtle but it is a consequence of the fact that the MOF/XMI specification maps only the toplevel UML Namespace into a corresponding XML Namespace declaration – i.e., a toplevel UML::Model/Package/Profile has a corresponding XML Namespace declaration & prefix; nested UML Namespaces do not!

    This means that the UML Namespace distinguishability criteria that suffices for ensuring UML NamedElements are distinguishable within the same UML Namespace
    is insufficient to guarantee that the XMI encoding of such UML NamedElements will be also distinguishable in the scope of their containing XML Namespace!

    For SysML 1.3, I specifically used an unconventional XMI:id generation algorithm that encodes the fully qualified path (name/metatype/linearized collection order) of each UML Element so as to ensure that each XMI:id Element in the scope of an XMI document is distinguishable within that document.

  • Reported: UML 2.5 — Tue, 27 Sep 2011 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

OccurrenceSpecification should have at least an optional notation

  • Key: UMLR-264
  • Legacy Issue Number: 16572
  • Status: open  
  • Source: Fraunhofer FOKUS ( Mr. Marc-Florian Wendland)
  • Summary:

    Until UML 2.3, OccurrenceSpecification (OS) was an abstract superclass for the concrete occurrence specifications MessageOccurrenceSpecificatio (MOS) and ExecutionOccurrenceSpecification (EOS). In UML 2.3 OS became concrete. This apparently subtle change has a significant impact of the usage of domain-specific events in Interaction. A user can now place an OS along a lifeline directly, instead of using using the already existent ActionExecutionSpecification or BehaviorExecutionSpecification. This eases the definition of domain-specific occurrence specifications (let's call it events from henceforth) by defining stereotypes directly for an OS.

    For example, in the UML Testing Profile, there are some test-specific events (e.g. ValidationAction, a sterotype for CallOperationAction) which can be used inside Interaction. Until UML 2.3 the steps for including such a domain-specific actions in Interactions have been the following:

    1. Create an Action and let it being contained by the Interaction
    2. Configure that Action and apply the corresponding stereotype
    3. Create the ActionExecutionSpecification
    4. Create the EOS as the start EOS and link the ActionExecutionSpecification with the EOS
    5.Create the EOS as the finish EOS and link the ActionExecutionSpecification with the EOS
    6. Link the ActionExecutionSpecification with the Action

    The whole procedure involved a lot of very fine-grained and subtled concepts and requires an advanced knowledge of the Interactions metamodel (frankly, only few tools support this complex procedure).

    Since UML 2.4, the steps are reduced to the following one:
    1. Create an OccurrenceSpecification on a lifeline
    2. Apply a stereotype to the OS and configurethe OS

    The stereotyped OS assumes the semantics provided by the domain-specific OS (in UTP ValidationOccurrenceSpecification). This reduces the complexity of integrating such domain-specific events, reduces the memory foorprint and eases the handling and creation of interactions containing such stereotyped OS.

    The problem is that OS does not declare a national representation, and we doubt that this concept will be provided by tools if there is not standardized representation.

    Therefore, we suggest to define a (at least optional) notation for OS as a rectangle or rounded rectangle with a compartment for stereotype visualization and a compartment for an optional label (name of the OS or an expression within the stereotype).

    This change would not affect the XMI or metamodel, but has a significant impact of the way interaction are perceived and created.

  • Reported: UML 2.4 — Thu, 29 Sep 2011 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Message arguments for a Signal signature too restrictive

  • Key: UMLR-262
  • Legacy Issue Number: 16570
  • Status: open  
  • Source: Fraunhofer FOKUS ( Mr. Marc-Florian Wendland)
  • Summary:

    Constraint 4 of Message in section 14.3.18 requires that in case of a Signal signature, the arguments of the message must correspond to the properties of the Signal.

    We found this constraint too restrictive. A Signal is a classifier, hence it is possible to create an InstanceSpecification for the Signal. A InstanceSpecification can be referenced by an InstanceValue (ValueSpecification) from within the message argument list.

    We suggest to weaken the first sentence of constraint 4 a little from :

    In the case when the Message signature is a Signal, the arguments of the Message must correspond to the attributes of the
    Signal.

    to

    In the case when the Message signature is a Signal, the arguments of the Message must correspond to the attributes of the
    Signal, or to the Signal itself.

  • Reported: UML 2.4 — Thu, 29 Sep 2011 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Relation of message arguments to signature parameters ambiguous

  • Key: UMLR-261
  • Legacy Issue Number: 16569
  • Status: open  
  • Source: Fraunhofer FOKUS ( Mr. Marc-Florian Wendland)
  • Summary:

    In section 14.3.18, the constraints 3 and 4 say that the arguments of message must correspond to the parameters/properties of the signature (operation/signal). This leads to an ambiguous siuation in some situations. For example:

    Let's assume there is an operation with the following signatur op1(x:String[*], y:String[*]) or a Signal S with two properties
    S::p1 : String[0..1]
    S::p2 : String[0..1]

    Since there is no direct relationship between an argument and a parameter/property it is not possible to determine what argument belongs to the first parameter/property (list in case opf operation example) and what to the second one.

    This problem always occurrs when two parameters/properties of the same type are specified in a sequence and the first one has either an optional multiplicity or an upper bound equals *.

    A possible solution is to introduce an additional metaclass MessageArgumentSpecification, which should be contained by Message instead of ValueSpecification directly, with the following structure:

    MessageArgumentSpecification{
    refersTo: TypedElement [1]

    {where the referenced TypedElement is either an instance of parameter or property}

    arguments : ValueSpecification [1..*]

    {ordered}

    }

    It might be also considerable to keep the association between a referenced element and an argument bilateral. In this case, the association between Message and MessageArgumentSpecification should be ordered.

  • Reported: UML 2.4 — Thu, 29 Sep 2011 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

The included use case is always required for the including use case to execute correctly

  • Key: UMLR-265
  • Legacy Issue Number: 16658
  • Status: open  
  • Source: ivmx.pl ( Michal Kasprzyk)
  • Summary:

    In the 'Descriiption' section of chapter '16.3.5 Include (from UseCases)' there is a sentence:
    'Note that the included use case is not optional, and is always required for the including use case to execute correctly.'

    Interpretation of ‘include’ relationship, implying that it’s usage is valid only if included UC is obligatory for including UC to execute correctly,
    is probably the source of opinion, that the only way to model conditional parts of UC scenario using external UC, is by using ‘extend’ relationship.

    I find such conclusion in many books dealing with analysis/UML, for instance: ' Business Analysis’, page 188 (ISBN-10: 1906124612,ISBN-13: 978-1906124618).

    As a result the difference in aplicability between ‘include’ and ‘extend’ relationship is stressed almost only based on conditionallity of relationship between UC.

    In my opinion it’s valid to use ‘include’ relationship when pointing to another UC, that won’t be executed every time the base UC does.
    It’s just the internal logic of base UC scenario, that decides if it’s appropriate to call external UC or not.
    And if we depend only on result of an external UC, we should use ‘include’ relationship (so most of the time), while when there is a need to introduce its logic we should use ‘extend’ relationship.

    I think, that the sentencje:
    'Note that the included use case is not optional, and is always required for the including use case to execute correctly'
    should be removed or clarified, because if forces analysts to use mostly (if not only) an ‘extend’ relationship, that is far more complicated to use and time consuming to document than ‘include’.

  • Reported: UML 2.4.1 — Thu, 10 Nov 2011 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Concerning Transition and its owned elements

  • Key: UMLR-268
  • Legacy Issue Number: 17096
  • Status: open  
  • Source: Fraunhofer FOKUS ( Mr. Marc-Florian Wendland)
  • Summary:

    is there a reason why a transition's effect and triggers of a state machine transition (section 15.3.14 in UML 2.4, respectively section 14.5, subsection Transition in UML 2.5 initial submission) do not belong to the transition's namespace as members? Both simply subset ownedElement. In contrast, a transition's guard subsets Namespace:ownedRule, which made me think the former ones ought to subset Namespace:onwedMember in lieu of Element:ownedElement as well.

    I roughly flicked through the open issues of UML, but did not find anything related to this question. So, if there was not decided deliberately, I would open an issue for that

  • Reported: UML 2.5 — Sat, 4 Feb 2012 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Abstraction::mapping should be of type ValueSpecification or OpaqueExpression

  • Key: UMLR-266
  • Legacy Issue Number: 16897
  • Status: open  
  • Source: Fraunhofer FOKUS ( Mr. Marc-Florian Wendland)
  • Summary:

    In many cases, modeler would like to specify the mapping of an Abstraction on an informal level by just providing a LiteralString or OpaqueExpression describing the mapping in a natural language.

    The necessity to use an Expression is for this kind of usage of this feature cumbersome and clunky.

    The resolution could be to use a more common metaclass of Expression, i.e. ValueSpecification, to provide the highest level of flexibility to the modeler, how mappings can be specified.

  • Reported: UML 2.4 — Wed, 14 Dec 2011 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Message arguments should not be contained in a message

  • Key: UMLR-263
  • Legacy Issue Number: 16571
  • Status: open  
  • Source: Fraunhofer FOKUS ( Mr. Marc-Florian Wendland)
  • Summary:

    Figure 14.4 - Messages in the spec depicts that arguments of a message are contained in that message. This containmentship is not necessary and in many cases counterproductive.

    The containment prevents ValueSpecifications for being reused in multiple messages. Instead, the very same ValueSpecification must be created in each message.

    Since ValueSpecification is a PackageableElement, there is no problem in making the association between Message and ValueSpecification a non-containment association.

  • Reported: UML 2.4 — Thu, 29 Sep 2011 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML 2.4/2.5 Aliases

  • Key: UMLR-267
  • Legacy Issue Number: 16999
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    There is no capability in UML for giving an element an alternate name (an alias) within the package that defines it.

  • Reported: UML 2.5 — Tue, 17 Jan 2012 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Under-specified associations in UML2.4 & the need for clarifying the semantic directionality for all UML associations

  • Key: UMLR-236
  • Legacy Issue Number: 15449
  • Status: open  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    Resolution 14977 cleaned up many association end subsets/redefinitions; in particular, this resolution ensures that if an association end subsets/redefines another, then there is a symmetric subsetting/redefinition of the other end and that the subsetted/redefined ends belong to the same association.

    Two group of proposed changes were removed from 14977.

    The first group involves generalization relationships among associations: http://www.omg.org/issues/uml2-rtf.open.html#Issue15274
    Generalization relationships are needed when the semantics of an association whose ends subset/redefine the ends of another association is that the set of links of the former association are necessarily a subset of the links of the latter. Since this isn't necessarily the case, it implies that generalization relationships are needed to clarify this semantic intent as shown in slide 31 of the following UML2.0 presentation: http://www.omg.org/members/cgi-bin/doc?omg/04-05-01.pdf

    The second group involves associations that are under-specified in the sense that each association:

    • does not own any end (i.e., both ends are navigable according to 7.3.45)
    • none of the ends subset/redefine ends of another association that has semantic directionality

    The criteria for an association to have semantic directionality is:
    a) one end is navigable; the other isn't
    b) one end is composite; the other isn't
    c) one end subsets/redefines another end of an association that is semantically directed; the other doesn't
    d) one end has required multiplicity (i.e., lower>0); the other is optional (i.e., lower=0)
    e) one end has bounded multiplicity (i.e., upper>0); the other has unbounded multiplicity (i.e., upper<0)

    Without semantic directionality, an association owns neither of its member ends and there is no objective criteria to determine what effect changing one association end can/should/may have on changes to the other end, if any.

    In UML2.4, there are 9 associations that fail all of (a) through (e):
    [qvto:transformation] A_containedEdge_inGroup
    [qvto:transformation] A_containedNode_inGroup
    [qvto:transformation] A_covered_coveredBy
    [qvto:transformation] A_edge_inPartition
    [qvto:transformation] A_generalizationSet_generalization
    [qvto:transformation] A_inInterruptibleRegion_node
    [qvto:transformation] A_inPartition_node
    [qvto:transformation] A_predecessorClause_successorClause
    [qvto:transformation] A_subject_useCase

    19 associations satisfy (a), (b), (c) but fail either (d) and (e):

    [qvto:transformation] A_before_toAfter
    [qvto:transformation] A_classifier_templateParameter_parameteredElement
    [qvto:transformation] A_connectableElement_templateParameter_parameteredElement
    [qvto:transformation] A_end_role
    [qvto:transformation] A_extension_metaclass
    [qvto:transformation] A_incoming_target_node
    [qvto:transformation] A_incoming_target_vertex
    [qvto:transformation] A_inputElement_regionAsInput
    [qvto:transformation] A_interruptingEdge_interrupts
    [qvto:transformation] A_method_specification
    [qvto:transformation] A_operation_templateParameter_parameteredElement
    [qvto:transformation] A_outgoing_source_node
    [qvto:transformation] A_outgoing_source_vertex
    [qvto:transformation] A_outputElement_regionAsOutput
    [qvto:transformation] A_parameterSet_parameter
    [qvto:transformation] A_parameteredElement_templateParameter
    [qvto:transformation] A_powertypeExtent_powertype
    [qvto:transformation] A_submachineState_submachine
    [qvto:transformation] A_toBefore_after

    All 28 cases above correspond to associations that, while well-formed in the metamodel according to 14977 & other applicable resolutions, are under-specified in the specification in the sense that there is a reasonable interpretation where each association has a natural direction, either because of cardinality restrictions (i.e., (d) or (e) would suffice to give direction to the 19 associations above) or because there is insufficient application of the architecture principles for OMG metamodels (e.g., incomplete modeling of ownership in most of the cases for the first group of 9 association).

    The consequence for end users is that each of the 28 associations represents a source of modeling errors unless tool implementations choose to implement these associations in a non-standard way, e.g., by ascribing a sensible semantics to these associations that removes the ambiguity about which end can be changed independently of the other end – i.e., the association is semantically directed in that one end can be logically derived from the other end.

  • Reported: UML 2.5 — Wed, 8 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Issue on UML 2.4 - notation for Component::provided

  • Key: UMLR-235
  • Legacy Issue Number: 15440
  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    In section 8.3.1 and Table 8.4 there are several examples of nation claiming to show ‘provided interface’ for a Component.

    However Component::provided is a derived property – with many base properties on which it is based.

    Hence it seems completely un-obvious what a tool is supposed to store/export if a user draws one of these diagrams. Or is it intended that users not be allowed to draw them at all, but invoke a query (in some manner rightly not covered by the UML spec) to cause the ‘provided’ line (and possibly related elements) to be displayed?

    A further problem is that the ‘provided’ notation is identical to the ‘provided interface’ notation documented in section 7.3.24. And Table 8.1 makes reference to 7.3.24 for the notation although it uses the different term ‘implements’.

    Therefore it seems that the notation should be separated from the derived property, with the notation retained for simple realizedInterfaces – either by removing the term ‘provided’ from the description of the diagrams or renaming the property to be more descriptive

  • Reported: UML 2.5 — Mon, 30 Aug 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Nasty UML 2.x Issue - /qualifiedName is not unambiguous

  • Key: UMLR-233
  • Legacy Issue Number: 15400
  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    qualifiedName is not unambiguous

    Section 7.3.33 states:

    “A named element also has a qualified name that allows it to be unambiguously identified within a hierarchy of nested namespaces.” And the description of the property has: “A name that allows the NamedElement to be identified within a hierarchy of nested Namespaces.”

    Constraint [2] describes the derivation of /qualifiedName which makes use of the names of the containing namespaces.

    However the use of isDistinguishableFrom in the constraint for Namespace, which allows the names to be the same but the types different, means that the name alone may not unambiguously identify either the element or its namespaces.

    It seems that we have the following options:

    • Remove the notion of type from isDistinguishableFrom and insist on the names being different
    • Somehow include the type/metaclass in the qualified name (which I think we can do without needing a qualified name for the type itself – since UML has a flat namespace – but it could cause problems for profiles or other metamodels)
    • Drop the idea that the qualified name allows unambiguous identification. Which would be a shame. And might affect it being marked as {id}

      as per the recent issue resolution

    BTW the OCL for the derivation of /qualifiedName uses union() to construct it: however AFAIK this will not result in a String.

  • Reported: UML 2.5 — Fri, 27 Jun 2014 11:17 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Creation of an expansion node under an activity is allowed by UML and SysML specifications

  • Key: UMLR-242
  • Legacy Issue Number: 15849
  • Status: open  
  • Source: Safran Engineering Services/Airbus ( gautreault fabien)
  • Summary:

    Which semantic for an expansion node owned by an activity (instead an expansion region)?

    According OMG Unified Modeling LanguageTM (OMG UML), Superstructure, Chapter 12.3.26

    An expansion node is an object node used to indicate a flow across the boundary of an expansion region.

    An expansion region is a structured activity region that executes multiple times corresponding to elements of an input collection. This specific structured activity node is using expansion node as input and output. From outside the expansions regions the elements of expansion nodes only appear as a collections, the elements of collection are only accessible from "inside the collection".

    Semantic of an expansion node owned by an expansion region is then well defined. However, in abstract syntax nothing prevents to create an expansion node owned by an activity instead of an expansion region. In this case semantic is questionable.
    If this kind of construction is not expected, a specific constraint should be added in UML specification in order to prevent an activity to owned expansion nodes. On the contrary, if this construction allowed, associates semantic should be defined.

  • Reported: UML 2.3 — Mon, 29 Nov 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Part document structures in Superstructure need to conform to ISO standard Document Template Conventions

  • Key: UMLR-241
  • Legacy Issue Number: 15823
  • Status: open  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Title: Part document structures in Superstructure need to conform to
    ISO standard Document Template Conventions
    Category: Editorial

    Nature of Problem

    UML 2.3 RTF resolved ISSUE 14296 as follows:


    Summary:
    This is a multipart standard, use of "Part I, II, III" make confusion.
    Delete Part III and Make others rewrite as clauses. 7. General
    Introduction, 10 Infrastructure Library, and renumber other clauses.
    Also, delete Part III page.
    Resolution:
    Agree to change word “Part” to “Sub Part” throughout document.

    PTC/9-9-08 , the UML 2.3 Superstructure convenience document has the changes of the
    tem “Part” to “Subpart”, as per the resolution to ISSUE

    However the published UML 2.3 Infrastructure reverted to the use of the term “Part”.

    Also, ISO document templates do not allow hanging text.

    The introductory text for each is not in any numbered clause.

    Proposed Resolution:

    Change term “Part” to “Subpart”, as in PTC/9-9-8.

    Add a new section

    6.4.3 Contents of Subparts

    6.4.3.1 Contents of Subpart I ­ Structure

    <move the hanging intro from Part I into this subclause, with minor edits to fix pointers
    to sections>

    6.4.3.2 Contents of Subpart II ­ Behaviour

    <move the hanging intro from Part II into this subclause, with minor edits to fix pointers
    to sections>

    6.4.3.3 Contents of Subpart III- Supplement

    <move the hanging intro from Part III into this subclause,>

    6.4.3.4 Contents of Subpart IV - Annexes

    <move the hanging intro from Part IV into this subclause,>

  • Reported: UML 2.5 — Mon, 22 Nov 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

How to specify actual parameters to pass to parameterized submachine StateMachine

  • Key: UMLR-230
  • Legacy Issue Number: 15303
  • Status: open  
  • Source: PTC ( Mr. Simon Moore)
  • Summary:

    A State Machine can have parameters. How can values for these parameters be passed from a submachine State which references a State Machine with parameters?

  • Reported: UML 2.5 — Fri, 25 Jun 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Ports

  • Key: UMLR-229
  • Legacy Issue Number: 15290
  • Status: open  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    We have a debate about the concept of Port in the SysML RTF and I would like to get your opinion about some points because we have divergent interpretations of the UML specification.

    Since a port can be typed by a class, what about the properties and the owned behavior(s) defined for that class?

    Does the interaction point that instantiates the port has slots to hold runtime values of the properties defined by its type or does it only refer to values held by the instance of its owner (or by a instance of its environment)?

    How ownedbehaviors defined by the type of the port may impact the way interactions at that port are managed?

  • Reported: UML 2.5 — Tue, 15 Jun 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Initialization of complex fields

  • Key: UMLR-228
  • Legacy Issue Number: 15248
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Is there a standard UML way of initializing complex fields. Several examples below

    A: Integer (3,2) = (1,2,3,4,5,6)

    A: Integer (3,2) = ((1,2,3), (4,5,6))

    A: Integer (3,2) = ((1,2), (3,4), (5,6))

    And are they all the same?

    A: Integer (2,3) = (1,2,3,4,5,6)

    A: Integer (2,3) = ((1,2,3), (4,5,6))

    A: Integer (2,3) = ((1,2), (3,4), (5,6))

    And are these the same?

    And what’s the difference.

    And here another set

    Measurement (a Type)

    Value: Real

    Unit : String

    Experiment:Measurement(3) = (1.0, “ft”, 2.0,”ft”,3,”ft”)

    = ((1.0,”ft”), (2.0,”ft”), (3,”ft”))

    Experiment:Measurement(3,2)) = (1.0, “ft”, 2.0,”ft”,3,”ft”, 4,”ft”, 5,”ft”,6,”ft”)

    ((1.0,”ft”), (2.0,”ft”), (3,”ft”), (4,”ft”), (5,”ft”), (6,”ft”))

    (((1.0,”ft”), (2.0,”ft”), (3,”ft”)), ((4.0,”ft”), (5.0,”ft”), (6,”ft”)))

    My preferences are for the last one above (the one with the extra set of parenthesis), because is better support composition

    e.g.

    NullResults:Measurement = (0.0,”ft”)

    StartingResults:Measurement(3) = (NullResults, NullResults, NullResults)

    Experiment:Measurement(3,2) = (StartingResults, ((4.0,”ft”),(5.0,”ft”),(6.0,”ft”)))

    The UML spec is silent about the correct way of doing this. I’d like to have a language independent way of doing this.

  • Reported: UML 2.5 — Tue, 6 Apr 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML 2 issue: connectors typed by Association Class

  • Key: UMLR-238
  • Legacy Issue Number: 15485
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    Multiple tool vendors have failed to implement support for a Connector that has a type of an AssociationClass. This may be partly due to the fact that Connector (9.3.6) doesn’t explicitly describe this variation under type. Nor does any example show this use. I would expect that the properties/methods of Connector that has a type of an AssociationClass to be represented similarly to representation of an AssociationClass between Classes.

  • Reported: UML 2.5 — Fri, 10 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Clarifying the support for and semantics of subsetting/redefinition for a pair of properties defined in different contex

  • Key: UMLR-237
  • Legacy Issue Number: 15451
  • Status: open  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    Currently, the prevalent use of property subsetting/redefinition mechanism has been confined to a pairs of properties defined within a single artifact (e.g., metamodel, user model, ....) In principle, the specification allows using this mechanism even for a pair of properties where the subsetted/redefined property is defined in one artifact (e.g., a metamodel) and the subsetting/redefining property is defined in another artifact (e.g., a profile extending the metamodel). This flexibility could be useful in practice – e.g., see some of the proposed changes for SysML1.3 here: http://www.omg.org/members/sysml-rtf-wiki/doku.php?id=rtf3:groups:9_ports_and_flows.

    The specification does not explicitly discuss what is the semantics of subsetting/redefinition when the subsetted/redefined property is in a different artifact, potentially at a different level than the artifact where the subsetting/redefining property is defined.

    Combinations of subsetted/redefined property vs. subsetting/redefining property could include:

    • metamodel/profile
    • profile/profile
    • library/profile
  • Reported: UML 2.5 — Wed, 8 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML 2.3 Infra 12 Incomplete conformance for infinity

  • Key: UMLR-240
  • Legacy Issue Number: 15788
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    Issue 15780 for OCL suggests resolving the inconsistent definition of
    UnlimitedNatural
    by defining '' infinity (and '-' minus infinity) as valid Integer and Real
    values.

    This is appropriate to resolve the anomally that

    Integer conformsTo Real so any Integer is a valid Real,
    UnlimitedNatural conformsTo Integer so any UnlimitedNatural is a valid
    Integer

    except that at present '*' is a valid UnlimitedNatural without a valid
    Integer
    or Real counterpart.

    The resolution of Issue 14196, introducing UnlimitedNatural to the OCL
    specification, indicates that any use of UnlimitedNatural '*' as an Integer
    or Real requires a conversion to invalid. This imposes an undesirable
    implementation burden in addition to the anomalous conformance behaviour.

    Therefore please add '' (and '-') to Integer and Real.

  • Reported: UML 2.5 — Wed, 27 Oct 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

No Constraint for multiple associations

  • Key: UMLR-239
  • Legacy Issue Number: 15763
  • Status: open  
  • Source: Oracle ( Antonio Petri)
  • Summary:

    There isn't a constraint that prevents multiple associations from being specified between the same Actor and Use Case. Multiplicity is handled already by the multiplicity at the association's ends, so having two or more different associations seems to be redundant.

  • Reported: UML 2.3b1 — Tue, 19 Oct 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Aggregation missing from Property string syntax

  • Key: UMLR-232
  • Legacy Issue Number: 15315
  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    The syntax for property strings (defined using BNF in Notation section of 7.3.44) does not include the ability to specify aggregation of shared or composite.

  • Reported: UML 2.5 — Tue, 29 Jun 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Issue on UML 2.3 - Use of isAbstract for Interfaces

  • Key: UMLR-231
  • Legacy Issue Number: 15312
  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    Use of isAbstract for Interfaces

    -------------------------------------

    Section 7.3.24 of Superstructure states: “Because an interface is merely a declaration it is not an instantiable model element; that is, there are no instances of

    interfaces at run time.”

    And also: “An interface cannot be directly instantiated. Instantiable classifiers, such as classes, must implement an interface”

    .

    This would imply that isAbstract (inherited from Classifier) must be true. However there is no constraint to this effect on Interface. Furthermore none of the notation examples show the Interface name in italics.

    This is an issue for the Model Interchange Working Group

  • Reported: UML 2.5 — Mon, 28 Jun 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Retationships and composite structures

  • Key: UMLR-244
  • Legacy Issue Number: 15889
  • Status: open  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    UML Relationships, Comments and Constraints are unable to deal properly with composite structures that have more than one nested level. For instance: assume a class “A” with two properties “b1” and “b2” both typed by a class B with only one property “p”. A relationship, a comment or a constraint cannot target specifically A.b1.p and not A.b2.p.

  • Reported: UML 2.5 — Fri, 10 Dec 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

How is an attribute that is not a part, a role?

  • Key: UMLR-394
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    11.2.3. says

    Property is a kind of ConnectableElement. All of the ownedAttributes of a StructuredClassifier are roles and can be connected using Connectors.

    Those ownedAttributes of a StructuredClassifier that have isComposite = true (see 9.5.3) are called its parts. Hence parts constitute a subset of roles

    So how are non composite properties (attributes) roles?

    A justification, example, and/or an excuse is needed.

  • Reported: UML 2.5 — Fri, 21 Nov 2014 06:47 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Lack of clarify of attribute vs attribute value.

  • Key: UMLR-393
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    In the discussion of Figure 9.25a, the following appears:

    In diagram (a), each instance of Checking Account could have its own attributes (including those inherited from Account), such as account number and balance. Additionally, the equivalent instance for Checking Account may have attributes, such as interest rate and maximum delay for withdrawal.

    The text is unclear, but I assume that instances have their own attribute values, not attributes.

    The paragraphs below may have similar problems

  • Reported: UML 2.5 — Fri, 21 Nov 2014 04:59 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Generalizations should allow enumeration types as PowerTypes.

  • Key: UMLR-392
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    A powerful and common modeling situation is the need to have a subclass for every value of an enumeration type. This is similar to the need for using PowerTypes, but without the capability of dynamically creating new specific instances (subclasses).

    Some uses:
    For example, on a project there may be 100 commandKinds. I'd make an enumeration type of the commands, and want a simple way of declaring that for possible enumeration type there is subclass of command.

    This use is similar to what was once possible with discriminators in UML 1.x

    This can be tied to the use of qualifiers to make some powerful idioms. A Team can have an association to TeamPlayer, that is qualified by PositionKind. The team can be said to have at least one TeamPlay for each PositionKind. And if the same PositionKind is used as the PowerType for a specialization of TeamPlayer, we have a subclass of TeamPlayer per PositionKind.

    An enumeration type powerType can be also be powerfully used in some model transformations. A class containing an enumeration attribute can be converted to a class w/o the attribute but with a set of specialized subclasses, each with value of the enumeration type. Of vice versa. This sort of transformation is common when moving from analysis to design.

  • Reported: UML 2.5 — Fri, 21 Nov 2014 04:51 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Caption for Table 9.1 on wrong page

  • Key: UMLR-396
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Make sure that Table captions are on the same page as their table.

    This is similar to the problem with the Table caption 1.5
    Issue UMLR-375

  • Reported: UML 2.5 — Fri, 21 Nov 2014 07:09 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Making the default for Generalization isDisjoint=False is contrary to modelers' expectations.

  • Key: UMLR-395
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Almost all UML modelers assume that default semantics for Generalization is isDisjoint=True. The justification for making the isDisjoint=False (overlapping) the default escapes me.

    Most real-world semantics are disjoint, and I believe most programming languages are also disjoint.

    Please change the default for isDisjoint=True

  • Reported: UML 2.5 — Fri, 21 Nov 2014 06:55 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Continuation examples are missing InteractionConstraints for the Alternative CombinedFragment

  • Key: UMLR-390
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    In Figure 17.15 an example of a sequence diagram continuation is given. To make sense of this example, the interaction constraints for the alt operands should be shown. Without the constraints being shown, the two operands are both considered true.
    In Figure 17.16, the continuation is "rolled out", but the interaction constraints are still missing.

    To fix, in Figure 17.15, add the interaction constraints of "True" on the first of the alt operands (in both left and right diagrams), and add the the constraint of Else (or False) on the lower operands.

    In Figure 17.16 apply the interaction constraints in the same manner.

  • Reported: UML 2.5 — Tue, 18 Nov 2014 09:02 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Extraneous " (double quote) in 17.6.3 Semantics

  • Key: UMLR-389
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    17.6.3 has the following sentence:

    The seq operator is described in “17.6.3 (Combined Fragment).

    Please remove the unneeded ".

    This is similar to UMLR-371

  • Reported: UML 2.5 — Tue, 18 Nov 2014 07:34 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

As no UML operators are defined, it is not possible to write a UML Expression

  • Key: UMLR-388
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    An Expression requires the evaluation of one or more operator symbols. A tool, according to 8.3.3, can treat all Expressions as uninterpreted. There are no UML specified operators.

    However, the definition of an Opaque Expression is given as,
    An OpaqueExpression specifies the computation of a set of values either in terms of a UML Behavior or based on a textual statement in a language other than UML.

    As UML does not have a language of specified operators, all Expressions in a UML tool are OpaqueExpressions.

    Even if a tool gave a list of operators it would interpret, these operators would not be part of UML, and the expression would be an opaque expression given in a tool-specified language.

  • Reported: UML 2.5 — Thu, 13 Nov 2014 22:14 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

As Events are Packageable Elements, how is their Package known?

  • Key: UMLR-364
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Though an Event is a Packageable element (Figure 13.2 Events), it is unclear which Package owns it.
    One possibility would be the Trigger that refers to it. However, more than one Trigger can refer to the same Event, and these Triggers may be in different Packages (e.g., BroadCast Events)
    Another possibility would be the Package of the element that issues the Event. However, some Events have no clear originator. A SignalEvent may be issued from multiple places. More complexly, a change event may have multiple originators at the same time, from different Packages, such as on[Package1:A >Package2:B].

    The purpose of being Packageable is usually to imports and the ability to have unqualified names. As events seem not to have names (other than usage within a trigger), it does not appear that they could be the target of an import.
    If events don't and can't have names, they seem to be incorrectly identified as PackageablElements.

    So solutions.
    1) Stop them from being PackageableElements.
    2) Give them names and make them classifiers.
    ....

  • Reported: UML 2.5 — Fri, 17 Oct 2014 05:54 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Use Cases both can and cannot have BehavioralFeatures

  • Key: UMLR-365
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    on page 673 it says:
    "Attributes and operations may be shown in compartments within the UseCase oval, with the same content as though they were in a normal Classifier rectangle."

    However, on page 302, it says
    "There are two kinds of BehavioralFeatures: Operations (see sub clause 9.6) and Receptions (see sub clause 10.3). Of the different kinds of BehavioredClassifiers in UML, only Classes may have BehavioralFeatures and only active Classes may have Receptions (see sub clause 11.4). Calling an Operation on or sending a Signal instance to an object of a Class is a request for the object to carry out an identified BehavioralFeature."

    So can Use Cases have operations or not?

    I believe that Use Cases should (in the sense of following modeling trends) allow for operations.

    I also don't see any reason why most Use Cases woudn't be active, and therefor allow for Receptions.

  • Reported: UML 2.5 — Wed, 22 Oct 2014 04:27 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Semantics of Executable Nodes does not cover Control Flows on Control Pins

  • Key: UMLR-363
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    15.5.3 Semantics
    The Executable Nodes discussion requires all ControlFlows to be implicitly joined (effectively made mandatory). It should be possible to have optional ControlFlows if they arrive on pins (e.g., as part of a ParameterSet). It may also be possible to have optional ControlFlows if the implicit join could have a joinSpec by the use of constraint.
    Similarly, it should be possible to use a ParameterSet to have some controlPins w/o output control tokens.

  • Reported: UML 2.5 — Fri, 17 Oct 2014 05:23 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

A type defines a set member (not a set)

  • Key: UMLR-362
  • Legacy Issue Number: 19640
  • Status: open  
  • Source: Anonymous
  • Summary:

    CURRENT
    1) “A Type specifies a set of allowed values known as the instances of the Type.
    2) “Depending on the kind of Type, instances of the Type may be created or destroyed over time.
    3) “However, the rules for what constitutes an instance of the Type remain fixed by the definition of that Type.”

    COMMENTS
    1) “A Type specifies a set of allowed values known as the instances of the Type.
    Surely a type does not specify a set?
    Rather it specifies what it takes to one (any) member in the afore-mentioned set?
    It defines each individual in a collection of instances.
    Surely the sentence should be changed, perhaps along these lines?
    “A Type specifies each value in the set of values known as instances of the Type.”
    “A Type specifies the rules for what constitutes an instance of the Type.”
    "A Type specifies features shared by things that are instances of the Type.”
    "A Type specifies each member of a set by defining one or more characteristics shared by all the members of the set.”
    "The set members are instances of the Type."

    2) “Depending on the kind of Type, instances of the Type may be created or destroyed over time.
    So there are two kinds of Type? What are they are called?

    3) “However, the rules for what constitutes an instance of the Type remain fixed by the definition of that Type.”
    Surely “the definition of the type” is tautologous?
    The Type is the definition ­ the definition of the rules for what constitutes an instance.
    Surely should be changed thus?
    “The rules for what constitutes an instance of the Type remain fixed by the Type.

  • Reported: UML 2.5 — Tue, 14 Oct 2014 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

2 Conformance: Missing Oxford comma in Item #2.

  • Key: UMLR-353
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    First sentence says "....to be created, read, updated, and deleted."
    However second sentence says "..to create, read, update and delete"

    This is an minor, but annoying inconsistency. Generally, the UML spec does (correctly) use the serial/Oxford comma. this one was missing.

  • Reported: UML 2.5 — Wed, 20 Aug 2014 04:20 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML 2.5 Mandatory but suppressible compartments

  • Key: UMLR-333
  • Legacy Issue Number: 19365
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    In 11.4.4 (Classes) Notation

    “A Class has four mandatory compartments: attributes, operations, receptions (see 9.2.4) and internal structure (see 11.2.4).”

    However, a bit later in 11.4.5 Examples

    “Figure 11.16 shows three ways of displaying the Class Window, according to the options set out for Classifier notation in 9.2.4. The top left symbol shows all compartments suppressed.”

    It’s a bit confusing to have mandatory but suppressible compartments.

    And in 9.2.4 (Classifier) Notation

    Some compartments in Classifier shapes are mandatory and shall be supported by tools that exhibit concrete syntax conformance. Others are optional, in the sense that a conforming tool may not support such compartments.

    Any compartment may be suppressed. A separator line is not drawn for a suppressed compartment. If a compartment is suppressed, no inference may be drawn about the presence or absence of elements in it.

    Many readers have been confused by this use of mandatory. Apparently “mandatory” means mandatory for the tool vendor to support, but not mandatory to display.

    In 11.2.4 Notation, it is clarified. E.g.,

    This compartment is mandatory: all tools that conform to the concrete syntax of UML must implement it.

    I’m requesting a similar clarification in 11.4.4

  • Reported: UML 2.5 — Fri, 18 Apr 2014 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML 2.6 Issue --- SignalEvent Triggers

  • Key: UMLR-332
  • Legacy Issue Number: 19364
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    On p 345 under the details of Transition it says:

    SignalEvent triggers and CallEvent triggers are not distinguishable by syntax and must be discriminated by their declaration elsewhere.

    However, on the next page under Signal receipt signal it says:

    The Signal receipt symbol is shown as a five-pointed polygon that looks like a rectangle with a triangular notch in one of its sides (either one). It maps to the trigger of the Transition and does not map to an Action of the Activity that specifies the effect Behavior. The names of the Signals of the Trigger as well as any guard are contained within the symbol as follows:

    <trigger> [‘,’ <trigger>]* [‘[‘ <guard> ‘]’]

    Where <trigger> is specified as described in sub clause 13.3.4 with the restriction that only Signal and change Event types are allowed. The trigger symbol is always first in the path of symbols and a compound transition can only have at most one such symbol.

    This means, that when the Signal Receipt symbol is used, and the trigger syntax is <name>[‘(‘[<assignment-specification>]’])’] is unambiguously a SignalEvent trigger and not a CallEvent trigger

  • Reported: UML 2.5 — Fri, 25 Apr 2014 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Incorrectly drawn ParameterableElement.owningTemplateParameterSubstitution multiplicity

  • Key: UMLR-327
  • Legacy Issue Number: 19346
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    Fig 7.4 is drawn with ParameterableElement.owningTemplateParameterSubstitution as * rather than the 0..1 that appears in the text and model.

  • Reported: UML 2.5 — Sat, 19 Apr 2014 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Incorrect drawing of non-navigable redefined opposites

  • Key: UMLR-326
  • Legacy Issue Number: 19345
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    Fig 9.10 shows three navigable Property.property

    Fig 9.13 shows Operation.operation as navigable

    The textual descriptions and the XMI consistently have redefined/subsetted opposites as unnavigable, so the diagrams are at fault.

    [From an OCL perspective three different Property.property makes OCL navigation troublesome.]

  • Reported: UML 2.5 — Sat, 19 Apr 2014 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Incorrect OrderedSet returns

  • Key: UMLR-330
  • Legacy Issue Number: 19351
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    The OCL for

    StructuredClassifier::part() and Operation::results()

    retuirns a projection of an OrderedSet and so itself returns an OrderedSet. However the operations are declared to return Sets.

    Suggest adding ->asSet() to discard the ordering prior to return.

  • Reported: UML 2.5 — Tue, 22 Apr 2014 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Figures 15.45 and 15.46 in the spec are bad examples as they are of malformed activity diagrams

  • Key: UMLR-335
  • Legacy Issue Number: 19409
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Figures 15.45 and 15.46 in the spec are bad examples as they are of malformed activity diagrams, which can never execute. The first behavior is a successor of the first behavior, and, as such, can never execute.

    The figures can be fixed by preceding the first behavior with a start node which has as its successor a merge node, which has as its successor the first behavior. Then the loop back from the downstream decision node must be connected to the merge node.

  • Reported: UML 2.5 — Fri, 9 May 2014 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

meaning is not clear

  • Key: UMLR-336
  • Legacy Issue Number: 19420
  • Status: open  
  • Source: toshiba-tsip.com ( VIRESH MOHAN)
  • Summary:

    In the part where the adornments on Association symbol are explained, the third bullet point seems to be confusing.

    A property string may be placed near the Association symbol, but far enough from any end to not be confused with a property string on an end.

    Though I am not in a position to say whether it's incorrect or not but I think it's bit convoluted as in "property string is placed so that it's not confused with a property string"?

  • Reported: UML 2.5b1 — Tue, 20 May 2014 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Incorrect Result in ReduceAction Example

  • Key: UMLR-334
  • Legacy Issue Number: 19406
  • Status: open  
  • Source: gmail.com ( Pete Karousos)
  • Summary:

    Unless my understanding of the ReduceAction is way off, the example says that with an input collection of four integers (2,7,5,3) the result of applying the ReduceAction to this collection with an addition function is 11. I believe the result should be 17 since 2+7+5+3 = 17 regardless of order.

  • Reported: UML 2.5 — Sun, 4 May 2014 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Specification should not contain any methodology

  • Key: UMLR-331
  • Legacy Issue Number: 19353
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The statement "Such instances are often described by Interactions." is about methodology and not the language. For example I have a different opinion about that and would write "Such instances are often described by Activities."

    I propose to discard the sentence or to change it to

    "Such instances are described by concrete Behaviors."

  • Reported: UML 2.5 — Wed, 23 Apr 2014 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Improving the association direction notation

  • Key: UMLR-290
  • Legacy Issue Number: 19017
  • Status: open  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    The UML 2.5 notation for associations in section 11.5.4 states (4th paragraph):

    On a binary Association drawn as a solid line, a solid triangular arrowhead next to or in place of the name of the Association and pointing along the line in the direction of one end indicates that end to be the last in the order of the ends of the Association. The arrow indicates that the Association is to be read as associating the end away from the direction of the arrow with the end to which the arrow is pointing (see Figure 11.27). This notation is for documentation purposes only and has no general semantic interpretation. It is used to capture some application-specific detail of the relationship between the associated Classifiers.

    In practice, the order of association ends is not very useful. Deriving the direction of an association based on association end cardinality, aggregation type and navigability, which is a function of ownership (see Property::isNavigable()) would be more useful.

    I propose the following criteria (written in QVT Operational):

    modeltype uml uses 'http://www.nomagic.com/magicdraw/UML/2.4.1';

    /**

    • @author nicolas.f.rouquette@jpl.nasa.gov
    • October 2013 - UML2.6 Improving the association direction notation.
      */
      transformation AssociationDirectionCheck(in selectedAssociations:uml);
      property associations : Set(uml::Association) = selectedAssociations.rootObjects()[uml::Association];

    main() {
    log('Analyzing ' + associations->size().repr() + ' associations');
    associations->sortedBy(qualifiedName)->forEach(a)

    { var p := a.memberEnd![name='p']; var q := a.memberEnd![name='q']; log('Association ' + a.name + ' : ' + p.type.name + ' -- ' + q.type.name); p.describe('end1'); q.describe('end2'); }

    }

    helper uml::Property::describe(in prefix:String) {
    var a := self.association;
    assert fatal (a.oclIsKindOf(uml::Association));
    var other := a.memberEnd->excluding(self)->any(true);
    var dir := 'n/a';
    if (self.isMemberEndLogicallyDirectedToOtherEnd()) then dir := self.name + '>>' + other.name endif;
    if (other.isMemberEndLogicallyDirectedToOtherEnd()) then dir := other.name + '>>' + self.name endif;
    log(prefix + ': ' + self.namespace.name + '::' + self.name + ' : ' + self.type.name
    + '[' + self.lower.repr() + '..' + (if self.upper < 0 then '*' else self.upper.repr() endif) + ']'
    + '

    {memberEnd#' + a.memberEnd->indexOf(self).repr() + ', aggregation=' + self.aggregation.repr() + ', isNavigable=' + self.isNavigable().toString() + ', direction=' + dir + '}

    ');
    }

    helper uml::Property::isMemberEndLogicallyDirectedToOtherEnd() : Boolean

    { var a := self.association; assert fatal (a.oclIsKindOf(uml::Association)); var other := a.memberEnd->excluding(self)->any(true); var fwdDirByClassOrNav := ((self.owner = a) and (other.owner <> a)) or (not self.isNavigable()) and other.isNavigable(); var fwdDirByComposition := (not self.isComposite) and other.isComposite; var fwdDirByCardinality := (not self.isComposite) and (not other.isComposite) and (self.upper <= 1) and (other.upper < 0 or other.upper > 1); return fwdDirByClassOrNav or ((not fwdDirByClassOrNav) and (fwdDirByComposition or fwdDirByCardinality)); }

    query Boolean::toString() : String

    { if (self) then return 'Y' endif; return 'F'; }

    For a representative set of test cases varying all combinations of association end aggregation type, cardinality, ownership, navigability, member end order,
    the above criteria suffices to determine whether an association with ends p and q is in the forward direction (p>>q) or reverse (q>>p):

    [10/13/13 2:03 PM] Analyzing 22 associations
    [10/13/13 2:03 PM] Association AB'0 : A'0 – B'0
    [10/13/13 2:03 PM] end1: AB'0: : A'0[1..1]

    {memberEnd#1, aggregation=none, isNavigable=F, direction=p>>q}
    [10/13/13 2:03 PM] end2: A'0::q : B'0[1..1] {memberEnd#2, aggregation=none, isNavigable=Y, direction=p>>q}
    [10/13/13 2:03 PM] Association AB'1 : A'1 – B'1
    [10/13/13 2:03 PM] end1: AB'1: : A'1[1..1] {memberEnd#1, aggregation=none, isNavigable=F, direction=p>>q}

    [10/13/13 2:03 PM] end2: AB'1::q : B'1[1..1]

    {memberEnd#2, aggregation=none, isNavigable=Y, direction=p>>q}
    [10/13/13 2:03 PM] Association AB0 : A0 – B0
    [10/13/13 2:03 PM] end1: AB0: : A0[1..1] {memberEnd#2, aggregation=none, isNavigable=F, direction=p>>q}
    [10/13/13 2:03 PM] end2: A0::q : B0[1..1] {memberEnd#1, aggregation=none, isNavigable=Y, direction=p>>q}
    [10/13/13 2:03 PM] Association AB1 : A1 – B1
    [10/13/13 2:03 PM] end1: AB1: : A1[1..1] {memberEnd#2, aggregation=none, isNavigable=F, direction=p>>q}
    [10/13/13 2:03 PM] end2: AB1::q : B1[1..1] {memberEnd#1, aggregation=none, isNavigable=Y, direction=p>>q}
    [10/13/13 2:03 PM] Association CD'0 : C'0 – D'0
    [10/13/13 2:03 PM] end1: CD'0: : C'0[0..1] {memberEnd#1, aggregation=none, isNavigable=F, direction=p>>q}
    [10/13/13 2:03 PM] end2: C'0::q : D'0[1..1] {memberEnd#2, aggregation=composite, isNavigable=Y, direction=p>>q}
    [10/13/13 2:03 PM] Association CD'1 : C'1 – D'1
    [10/13/13 2:03 PM] end1: CD'1: : C'1[0..1] {memberEnd#1, aggregation=none, isNavigable=F, direction=p>>q}
    [10/13/13 2:03 PM] end2: CD'1::q : D'1[1..1] {memberEnd#2, aggregation=composite, isNavigable=Y, direction=p>>q}
    [10/13/13 2:03 PM] Association CD0 : C0 – D0
    [10/13/13 2:03 PM] end1: CD0: : C0[0..1] {memberEnd#2, aggregation=none, isNavigable=F, direction=p>>q}
    [10/13/13 2:03 PM] end2: C0::q : D0[1..1] {memberEnd#1, aggregation=composite, isNavigable=Y, direction=p>>q}
    [10/13/13 2:03 PM] Association CD1 : C1 – D1
    [10/13/13 2:03 PM] end1: CD1: : C1[0..1] {memberEnd#2, aggregation=none, isNavigable=F, direction=p>>q}
    [10/13/13 2:03 PM] end2: CD1::q : D1[1..1] {memberEnd#1, aggregation=composite, isNavigable=Y, direction=p>>q}
    [10/13/13 2:03 PM] Association EF'0 : E'0 – F'0
    [10/13/13 2:03 PM] end1: EF'0: : E'0[1..1] {memberEnd#1, aggregation=composite, isNavigable=F, direction=q>>p}
    [10/13/13 2:03 PM] end2: E'0::q : F'0[0..1] {memberEnd#2, aggregation=none, isNavigable=Y, direction=p>>q}

    [10/13/13 2:03 PM] Association EF'1 : E'1 – F'1
    [10/13/13 2:03 PM] end1: EF'1: : E'1[1..1]

    {memberEnd#1, aggregation=composite, isNavigable=F, direction=q>>p}

    [10/13/13 2:03 PM] end2: EF'1::q : F'1[0..1]

    {memberEnd#2, aggregation=none, isNavigable=Y, direction=p>>q}
    [10/13/13 2:03 PM] Association EF0 : E0 – F0
    [10/13/13 2:03 PM] end1: EF0: : E0[1..1] {memberEnd#2, aggregation=composite, isNavigable=F, direction=q>>p}
    [10/13/13 2:03 PM] end2: E0::q : F0[0..1] {memberEnd#1, aggregation=none, isNavigable=Y, direction=p>>q}
    [10/13/13 2:03 PM] Association EF1 : E1 – F1
    [10/13/13 2:03 PM] end1: EF1: : E1[1..1] {memberEnd#2, aggregation=composite, isNavigable=F, direction=q>>p}
    [10/13/13 2:03 PM] end2: EF1::q : F1[0..1] {memberEnd#1, aggregation=none, isNavigable=Y, direction=p>>q}
    [10/13/13 2:03 PM] Association GH'0 : G'0 – H'0
    [10/13/13 2:03 PM] end1: GH'0: : G'0[1..1] {memberEnd#1, aggregation=none, isNavigable=Y, direction=p>>q}
    [10/13/13 2:03 PM] end2: G'0::q : H'0[1..1] {memberEnd#2, aggregation=none, isNavigable=Y, direction=p>>q}

    [10/13/13 2:03 PM] Association GH'1 : G'1 – H'1
    [10/13/13 2:03 PM] end1: GH'1: : G'1[0..1]

    {memberEnd#1, aggregation=none, isNavigable=Y, direction=p>>q}
    [10/13/13 2:03 PM] end2: GH'1::q : H'1[0..*] {memberEnd#2, aggregation=none, isNavigable=Y, direction=p>>q}
    [10/13/13 2:03 PM] Association GH'2 : G'2 – H'2
    [10/13/13 2:03 PM] end1: H'2: : G'2[0..1] {memberEnd#1, aggregation=none, isNavigable=Y, direction=p>>q}

    [10/13/13 2:03 PM] end2: G'2::q : H'2[0..*]

    {memberEnd#2, aggregation=none, isNavigable=Y, direction=p>>q}
    [10/13/13 2:03 PM] Association GH0 : G0 – H0
    [10/13/13 2:03 PM] end1: GH0: : G0[1..1] {memberEnd#2, aggregation=none, isNavigable=Y, direction=p>>q}

    [10/13/13 2:03 PM] end2: G0::q : H0[1..1]

    {memberEnd#1, aggregation=none, isNavigable=Y, direction=p>>q}
    [10/13/13 2:03 PM] Association GH1 : G1 – H1
    [10/13/13 2:03 PM] end1: GH1: : G1[0..1] {memberEnd#2, aggregation=none, isNavigable=Y, direction=p>>q}
    [10/13/13 2:03 PM] end2: GH1::q : H1[0..*] {memberEnd#1, aggregation=none, isNavigable=Y, direction=p>>q}

    [10/13/13 2:03 PM] Association GH2 : G2 – H2
    [10/13/13 2:03 PM] end1: H2: : G2[0..1]

    {memberEnd#2, aggregation=none, isNavigable=Y, direction=p>>q}
    [10/13/13 2:03 PM] end2: G2::q : H2[0..*] {memberEnd#1, aggregation=none, isNavigable=Y, direction=p>>q}
    [10/13/13 2:03 PM] Association IJ'0 : I'0 – J'0
    [10/13/13 2:03 PM] end1: J'0: : I'0[0..1] {memberEnd#1, aggregation=none, isNavigable=Y, direction=p>>q}
    [10/13/13 2:03 PM] end2: I'0::q : J'0[1..1] {memberEnd#2, aggregation=composite, isNavigable=Y, direction=p>>q}
    [10/13/13 2:03 PM] Association IJ'1 : I'1 – J'1
    [10/13/13 2:03 PM] end1: J'1: : I'1[0..1] {memberEnd#1, aggregation=none, isNavigable=Y, direction=p>>q}
    [10/13/13 2:03 PM] end2: I'1::q : J'1[0..*] {memberEnd#2, aggregation=none, isNavigable=Y, direction=p>>q}

    [10/13/13 2:03 PM] Association IJ0 : I0 – J0
    [10/13/13 2:03 PM] end1: J0: : I0[0..1]

    {memberEnd#2, aggregation=none, isNavigable=Y, direction=p>>q}
    [10/13/13 2:03 PM] end2: I0::q : J0[1..1] {memberEnd#1, aggregation=composite, isNavigable=Y, direction=p>>q}
    [10/13/13 2:03 PM] Association IJ1 : I1 – J1
    [10/13/13 2:03 PM] end1: J1: : I1[0..1] {memberEnd#2, aggregation=none, isNavigable=Y, direction=p>>q}

    [10/13/13 2:03 PM] end2: I1::q : J1[0..*]

    {memberEnd#1, aggregation=none, isNavigable=Y, direction=p>>q}

    To facilitate reviewing this criteria, these associations are shown in the attached class diagram.

  • Reported: UML 2.5 — Sun, 13 Oct 2013 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Sequence Diagram: Message limitation

  • Key: UMLR-291
  • Legacy Issue Number: 19024
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    In several places in the UML 2.5 spec the message line (that goes from lifeline to lifeline) is restricted to have the destination end no higher than the source end.

    While this sounds reasonable, it’s not really logically required in the general case.

    No, I’m not talking about faster-than-light messages.

    When a sequence diagram / fragment is “weak” (not strict) ordering, the individual life-lines can have their own time scale, and as long as causality is followed. And as each life-line’s time scale need not be uniform, a message going from one location on one lifeline to another lifeline but physically higher need not violate any logical or physical limitations.

    Please eliminate the restriction preventing upward aiming message lines when the ordering is weak. This will allow the modelers to have better use of the diagram real-estate.

    Michael

  • Reported: UML 2.5 — Sat, 19 Oct 2013 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Use cases and use of arrows

  • Key: UMLR-287
  • Legacy Issue Number: 19012
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Modelers often use arrows on the relationships between use cases and their actors. This is never explained/allowed/disallowed in the spec. One would think that if arrows are allowed, then qualifiers, ownership balls,

    {ordered}

    ,

    {unique}

    , etc. would also be allowed. Almost no one uses those arrows as true navigability. Perhaps some mention of the arrows is required and to allow for user determined semantics.

  • Reported: UML 2.5 — Fri, 11 Oct 2013 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Even if Use Cases need not have an actor, there is some ambiguity when there is an «include»d or «extension» use case

  • Key: UMLR-286
  • Legacy Issue Number: 19011
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Even if Use Cases need not have an actor, there is some ambiguity when there is an «include»d or «extension» use case. Much of the use case literature says, that the actors of the base use case are automatically actors of the extension or inclusion. They also say that duplicating the actors, that is, connecting the base’s actors to the extension or inclusion, implies that these actors may be needed twice for the extension/inclusion. This approach of assuming that the base’s actors are actors of the extension/inclusion is natural when the use cases are detailed out in sequence diagrams, and is almost a necessity when the extension/included use case can be used by many base use cases (where their actors could be different in each case). If an explicit actor is added to the extension/inclusion, is it added to the base’s actor or replace it?

  • Reported: UML 2.5 — Fri, 11 Oct 2013 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Information flow instantiation

  • Key: UMLR-295
  • Legacy Issue Number: 19167
  • Status: open  
  • Source: MITRE ( Dr. Fatma Dandashi)
  • Summary:

    Information flow instantiation. There is no UML construct to define flow and then to instantiate flows to use flow types and then flow instances that flow between two instances of two things.

  • Reported: UML 2.5 — Thu, 26 Dec 2013 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Cannot set an activity as the source or target of an information flow

  • Key: UMLR-294
  • Legacy Issue Number: 19133
  • Status: open  
  • Source: Alstom Transport ( Wagner Schalch Mendes)
  • Summary:

    According to the constraints specified for an InformationFlow, its sources and targets can be only 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.

    In my opinion, Activity should also be included in the list.

  • Reported: UML 2.4.1 — Wed, 4 Dec 2013 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Description of the OCL on Actor does not match OCL and both are obsolete.

  • Key: UMLR-289
  • Legacy Issue Number: 19014
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    The description of the OCL on an Actor limits associations to Use Cases, Components, and Classes. However, the OCL limits it to Use Cases and Classes, forbids behavior, and doesn’t explicitly mention Components.

    a. I assume that Components are types of Classes, but Behavior is generally not a class (it’s a classifier), so I wonder why the limitation on behavior is needed?

    b. Wouldn’t this allow an Actor to have an attribute/part that is typed by a class?

    c. Isn’t this entire restriction obsolete? We don’t seem to be insisting that actors are outside of the subject anymore, almost all modeling approaches, allow for actors to be full design elements within a system. This is necessary to support multiple layers of system analysis, so that at one level some of the parts of a system become actors to other parts when modeled at the level. Requiring the modeling to introduce redundant elements to represent actors that are part of the higher-level system seems inappropriate.

  • Reported: UML 2.5 — Fri, 11 Oct 2013 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

About prescribed port implementation

  • Key: UMLR-293
  • Legacy Issue Number: 19122
  • Status: open  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    Description:

    The prescription made in the §11.3.3 about the implementation of Port seems to be overly restrictive:

    “When an instance of an EncapsulatedClassifier is created, instances corresponding to each of its Ports are created and held in the slots specified by each Port, in accordance with its type and multiplicity. These instances are referred to as “interaction points” and provide unique references.”

    As long as port is defined as “a distinct interaction point”, of which the primary purpose is: “enabling different communications to be distinguished based on the Port through which they occur”, the implementation described by the text quoted above, and which based on the instantiation of a separate object, is actually a possible implementation but it is not the only one.

    An alternative valuable implementation is to make them pure routing information that does not required any structural part instance (cf. SDL port semantics). UML should not prevent implementations of that kind.

  • Reported: UML 2.5 — Fri, 22 Nov 2013 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Problem with MultiplicityELement::lower redefinition in UML 2.5 Beta 2

  • Key: UMLR-297
  • Legacy Issue Number: 19185
  • Status: open  
  • Source: Eclipse Foundation ( Mr. Kenneth Hussey)
  • Summary:

    ExtensionEnd::lower invalidly redefines MultiplicityELement::lower (see issue 13992) - the multiplicity of ExtensionEnd::lower doesn't fall within that of MultiplicityELement::lower.

  • Reported: UML 2.5 — Fri, 17 Jan 2014 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

BehavioredClassifier should redefine Classifier::conformsTo to include interfaceRealization

  • Key: UMLR-296
  • Legacy Issue Number: 19179
  • Status: open  
  • Source: riseup.net ( Pieter Martin)
  • Summary:

    Currently interface realizations are not included in the conformance specification on BehavioredClassifier. In particular this is a problem for subsetting semantics when the subsetted property resides on an Interface.

  • Reported: UML 2.5 — Sat, 11 Jan 2014 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

No rules on Extension Pts governing differences between Use Case definitions & «extend» relationships usage

  • Key: UMLR-288
  • Legacy Issue Number: 19013
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Extension points appear to be documented in the properties of a use case. However, extension points are also allowed to be referred to in the condition note attached to the «extend» relationship. Is it legal to refer to an extension point that is not defined in the use case? Does this automatically add the extension point to the base use case. An example of this is in figures 18.3 and 18.11

  • Reported: UML 2.5 — Fri, 11 Oct 2013 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Abstract Syntax diagram for Use Cases

  • Key: UMLR-285
  • Legacy Issue Number: 19010
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    The Abstract Syntax diagram for Use Cases should show that there is some intended relationship between an Actor and a Use Case. This should have the correct multiplicities as determined in the issue above. It can be a subset of existing relationships in the metamodel

  • Reported: UML 2.5 — Fri, 11 Oct 2013 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Navigability orthogonal to end ownership or not?

  • Key: UMLR-257
  • Legacy Issue Number: 16350
  • Status: open  
  • Source: gmail.com ( Adam Ci&#261;&#380;y&#324;ski)
  • Summary:

    At one point (page 42) the specification reads:
    "Navigability notation was often used in the past according to an informal convention, whereby non-navigable ends were assumed to be owned by the association whereas navigable ends were assumed to be owned by the classifier at the opposite end. This convention is now deprecated. Aggregation type, navigability, and end ownership are orthogonal concepts, each with their own explicit notation."

    The same thought can be found here: http://www.omg.org/issues/issue15128.txt :
    "... an old constraint from UML 1.x when navigability meant the same as ownership of property"

    However at another place (page 38) the specification reads:
    "An end property of an association that is owned by an end class or that is a navigable owned end of the association indicates that the association is navigable from the opposite ends; otherwise, the association is not navigable from the opposite ends."

    So is navigability orthogonal to end ownership or not? I think that the specification is somewhat unclear concerning these issues.

    The descriptions of ownedEnd and navigableOwnedEnd don't clarify much and seem to be too brief.

  • Reported: UML 2.3 — Tue, 28 Jun 2011 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Ambiguous stereotype notation

  • Key: UMLR-256
  • Legacy Issue Number: 16342
  • Status: open  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    Suppose we have a stereotype S extending UML::Class.
    We can apply S to a UML::Class, UML::Activity, UML::StateMachine and any other element whose metaclass is a kind of UML::Class.

    The UML notation for stereotype allows showing applications of S as <<S>> but this notation does not clearly show what kind of element the element is.
    In cases where distinct metaclasses (e.g., UML::Class, UML::Activity, UML::StateMachine) use the same notation (i.e. a box), the overall notation is ambiguous.

    The UML notation could be extended to show optionally the metaclass of an element, e.g., <<S>> [Class] vs. <<S>> [Activity] vs. <<S>> [StateMachine].

    Proposed resolution:

    in clause 18.3.9, Stereotype, under notation, change:

    When a stereotype is applied to a model element (an instance of a stereotype is linked to an instance of a metaclass),
    the name of the stereotype is shown within a pair of guillemets above or before the name of the model
    element, or where the name would appear if the name is omitted or not displayed. For model elements
    that do not have names but do have a graphical representation, unless specifically stated elsewhere, the stereotypes
    can be displayed within a pair of guillemets near the upper right corner of the graphical representation.
    If multiple stereotypes are applied, the names of the applied stereotypes are shown as a comma-separated list
    with a pair of guillemets. When the extended model element has a keyword, then the stereotype name will be displayed close to the keyword,
    within separate guillemets (example: «interface» «Clock»).

    to:

    When a stereotype is applied to a model element (an instance of a stereotype is linked to an instance of a metaclass),
    the name of the stereotype is shown within a pair of guillemets above or before the name of the model
    element, or where the name would appear if the name is omitted or not displayed optionally followed by the name of the
    model element's metaclass within a pair of square brackets. For model elements
    that do not have names but do have a graphical representation, unless specifically stated elsewhere, the stereotypes
    can be displayed within a pair of guillemets near the upper right corner of the graphical representation optionally
    followed by the name of the model element's metaclass within a pair of square brackets.
    If multiple stereotypes are applied, the names of the applied stereotypes are shown as a comma-separated list
    with a pair of guillemets. When the extended model element has a keyword, then the stereotype name will be displayed close to the keyword,
    within separate guillemets (example: «interface» [Interface], «Clock» [Class]).

  • Reported: UML 2.5 — Wed, 22 Jun 2011 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Notation of Lifelines

  • Key: UMLR-248
  • Legacy Issue Number: 15991
  • Status: open  
  • Source: International Business Machines ( Mr. Adam Neal)
  • Summary:

    In UML 2.3, section 14.3.19 (Lifelines), the notation of a lifeline is given as follows:

    <lifelineident> ::= ([‘[‘ ‘]’]] [: [decomposition]) | ‘self’ <selector> ::= <expression> <decomposition> ::= ‘ref’ <interactionident> [‘strict’]

    Given a Lifeline has an explicit name, it seems as though its not allowed to be displayed. Does anyone know if there is a specific reason for not showing the name of a Lifeline given it has one?

  • Reported: UML 2.5 — Wed, 26 Jan 2011 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Tags typed by classes/blocks

  • Key: UMLR-247
  • Legacy Issue Number: 15930
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    The UML Superstructure spec states in Subclause 18.3.7 that:

    “A Profile can define Classes, DatatTypes, PrimitiveTypes and Enumerations as well as Stereotypes since Profiles imports Constructs. However, these types can only be used as the type of properties in the profile, they cannot be used as types in models the profile is applied to since they apply at the meta-model level, not the model level. It is however possible to define these types in separate packages and import them as needed in both profiles and models in order to use them for both purposes.

    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. 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.”

    However, the restrictions expressed in this text are not formalized by any constraints. Either OCL should be added to formalize these restrictions, or the restrictions should be removed

  • Reported: UML 2.5 — Wed, 12 Jan 2011 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

XMI representation of stereotype application

  • Key: UMLR-246
  • Legacy Issue Number: 15903
  • Status: open  
  • Source: Universidad Politecnica de Madrid ( Miguel de Miguel)
  • Summary:

    I think that the source of confusion could be the paragraph in page 683 in 10-11-13.pdf

    “The most direct implementation of the Profile mechanism that a tool can provide is by having a metamodel based

    implementation, similar to the Profile metamodel. However, this is not a requirement of the current standard, which

    requires only the support of the specified notions, and the standard XMI based interchange capacities. The profile

    mechanism has been designed to be implementable by tools that do not have a metamodel-based implementation.”

    In this paragraph the “XMI based interchange capacities” are mentioned, but there is not

    a direct reference to page 684, to clarify that these the “XMI interchange capacities” are specified in 684. This paragraph

    gives the impression that the XMI interchange format is not closed.

  • Reported: UML 2.5 — Fri, 17 Dec 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

New notation for attribute

  • Key: UMLR-245
  • Legacy Issue Number: 15890
  • Status: open  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    According to several discussions I had with UML users, it appears that many of them, who have the intent to simply to add an attribute to a class, finally create an association to the type of the required attribute. In all case I faced, the reason was that they prefer the notation UML proposes for association which is much more powerful. Mainly:
    Capability to get a modular diagram thanks to the “link notation”
    Capability to show the aggregation kind

    However attributes and association are not the same and it is a pity to introduce such a drift in the semantics just because of the notation.

    What do you think about adding a notation for the attributes that would offer the capability to represent all their properties and to designate their type using a link?

  • Reported: UML 2.5 — Fri, 10 Dec 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Use cases specifying the same subject cannot be associated: exception

  • Key: UMLR-254
  • Legacy Issue Number: 16292
  • Status: open  
  • Source: London Life Insurance Co. ( Willem Van Galen)
  • Summary:

    The UML Superstructure Specification V2.4 states in 16.3.6 UseCase (from UseCases): “Two use cases specifying the same subject cannot be associated since each of them individually describes a complete usage of the subject.”

    For the longest time, this looked like a common-sense rule. However, it seems to me that in the context of SOA there is at least on exception to this rule.

    Let’s say that:
    1. The subject represents a component (as understood in SOA) and the use cases represent the component’s services.
    2. The initiating actor of all of the component’s services is Another Use Case. This reflects the SOA reality that services are not directly consumed by human actors but by other use cases.
    3. The component offers services A and B, both of which trace back to legitimate uses.
    4. As it happens, when service B is defined in detail it turns out that one of its steps amounts exactly to the functionality represented as service A.

    In such situations, where the subject already has a public service (A) that can actually be reused by one or more of its other public services (B), I think it’s entirely reasonable to allow B to be associated with A. After all, A’s initiating actor is Another Use Case, which is exactly what B is. In object-orientated terms this amounts to an object performing an operation on itself.

    I propose for UML to accommodate this scenario.

  • Reported: UML 2.4 — Sat, 28 May 2011 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Metaclass stereotype notion (02)

  • Key: UMLR-252
  • Legacy Issue Number: 16119
  • Status: open  
  • Source: email.com ( Kirill Fakhroutdinov)
  • Summary:

    Text says: "The names of Profiles are shown using a dashed arrow with an open arrowhead from the package to the applied profile."
    "The names" is not relevant in this context. The arrow is related to profile application.
    The text should say something like: "The applied Profiles are shown ..."

  • Reported: UML 2.4 — Fri, 27 Jun 2014 11:17 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Metaclass stereotype notion

  • Key: UMLR-251
  • Legacy Issue Number: 16118
  • Status: open  
  • Source: email.com ( Kirill Fakhroutdinov)
  • Summary:

    Text says: "A Class that is extended by a Stereotype may be extended by the optional stereotype «Metaclass» ..."
    The second "extended" has no sense.
    It should say something like: "A Class that is extended by a Stereotype may be denoted by the optional stereotype «Metaclass» ..."

  • Reported: UML 2.4 — Sun, 17 Apr 2011 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Profile URI Attribute - Mingled URI Definition and Use in XMI

  • Key: UMLR-250
  • Legacy Issue Number: 16117
  • Status: open  
  • Source: email.com ( Kirill Fakhroutdinov)
  • Summary:

    While describing profile URI attribute for profiles UML specification mingled definition of URI and format used for XMI. URI value as a whole should follow URI specification RFC 2396 and OMG recommended format:
    uri = http://profileParentQualifiedName/version/profileName.xmi
    When URI is used for XMI, the profileParentQualifiedName part should also be (made?) valid XML QName, e.g. with "all other illegal XML QName characters removed". Note, that XML QName usually has namespace prefix followed by ':', e.g. 'taxes:dependent', which contradicts to and has no sense as related to the first URI 2396 requirement.

  • Reported: UML 2.4 — Sun, 17 Apr 2011 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

State::stateInvariant multiplicity too restrictive

  • Key: UMLR-253
  • Legacy Issue Number: 16249
  • Status: open  
  • Source: Northrop Grumman ( Mr. Christopher McClure)
  • Summary:

    The multiplicity of State::stateInvariant is specified as [0..1]. This seems to restrictive, as it common for states to have multiple invariants, especially since this is the most convenient mechanism for specifying the actual values for properties, etc. that define the state. Furthermore, widening the multiplicity to [*] would be in alignment with the multiplicities of pre/postconditions on operations, etc.

  • Reported: UML 2.5 — Mon, 16 May 2011 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Package URI Attribute Uses Obsolete RFC 2396

  • Key: UMLR-249
  • Legacy Issue Number: 16116
  • Status: open  
  • Source: email.com ( Kirill Fakhroutdinov)
  • Summary:

    Specification requires URI package attribute to follow the rules and syntax of the IETF URI specification RFC 2396. RFC 2396 was rendered obsolete by the more recent version of the URI syntax - RFC 3986, released in 2005.

  • Reported: UML 2.4 — Sun, 17 Apr 2011 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

A deferrable trigger may have a guard

  • Key: UMLR-255
  • Legacy Issue Number: 16307
  • Status: open  
  • Source: asu.edu ( Joe Mooney)
  • Summary:

    It is an unfortunate restriction to omit guards from the specification of <trigger>/defer.

    Please explicitly state or reconsider this restriction since using a guard would simplify many scenarios involving event deferral

  • Reported: UML 2.4 — Wed, 1 Jun 2011 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Owning of interaction fragments is ambiguous when InteractionOperands are present

  • Key: UMLR-227
  • Legacy Issue Number: 15240
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    It is not clear from chapter 14 how interaction fragments are supposed to be owned when there are InteractionOperands present.

    It seems to be the case, but is not stated, that everything diagrammatically inside the operand should be owned by the fragment. This would, I think, give rise to the following consequences:

    1. The top and bottom of each fragment and operand must be on the same Lifeline or Execution. A fragment cannot span different executions or have its boundaries cover different levels of execution nesting.

    2. Everything inside of a fragment/operand must be entirely contained by the fragment/operand. This includes both sides of a message, all nested fragments, interaction uses, and the top and bottom of execution specifications.

    However it appears to be a valid instance of the metamodel to parent arbitrary fragments at any level of nesting, which would enable these constraints to be violated.

    The specification should confirm these ownership constraints. This would best be done in conjunction with the sentence “InteractionOperand contains an ordered set of InteractionFragments” in section 14.3.16, which should state exactly which InteractionFragments must be owned by the InteractionOperand.

    Different vendors’ interpretations of this ambiguity can cause interoperability problems.

  • Reported: UML 2.5 — Tue, 4 May 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Chapter 14 is ambiguous and contradictory about how to link up messages and execution specifications

  • Key: UMLR-226
  • Legacy Issue Number: 15239
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    Chapter 14 is ambiguous and contradictory about how to link up messages and execution specifications. This is because in the metamodel the start and finish of an ExecutionSpecification are OccurrenceSpecifications, not ExecutionOccurrenceSpecifications. This means that it appears to be valid for the MessageOccurrenceSpecification that is a Message's receiveEvent to also be the start of an ExecutionSpecification.

    The text is equally ambiguous. The 14.3.10 paragraph "An ExecutionSpecification is a specification of the execution of a unit of behavior or action within the Lifeline. The duration of an ExecutionSpecification is represented by two ExecutionOccurrenceSpecifications, the start ExecutionOccurrenceSpecification and the finish ExecutionOccurrenceSpecification" appears to say unambiguously that the start and finish must be ExecutionOccurrenceSpecifications. However the later sentence "Typically the start occurrence and the finish occurrence will represent OccurrenceSpecifications such as a receive OccurrenceSpecification (of a Message) and the send OccurrenceSpecification (of a reply Message)" both introduces ambiguity through the use of the word "typically", and then proceeds to blatantly contradict the earlier paragraph.

    This causes tool interoperability problems.

    I suggest targeting ExecutionSpecification::start and finish onto ExecutionOccurrenceSpecification, and rewriting the contradictory semantics accordingly.

  • Reported: UML 2.5 — Tue, 4 May 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

issue10087 and association-like notation

  • Key: UMLR-225
  • Legacy Issue Number: 15237
  • Status: open  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    No problem with the issue itself or the proposed resolution. I’m just wondering about the principle of the “association-like notation”.

    My concerns:

    The specification says that “An attribute may also be shown using association notation”. Nevertheless, defining an attribute or using an association as described in figure 7.31 is not the same thing. The definition of one attribute generates only one property while the definition of a binary association generates two properties plus a classifier for the association itself.

    If it’s only a matter of notation, how to distinguish in a diagram between:

    a) an attribute with an association-like notation

    and

    b) a “true” association?

    Yves

  • Reported: UML 2.5 — Tue, 23 Mar 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

not sure it is possible to define a constraint without a context

  • Key: UMLR-224
  • Legacy Issue Number: 15236
  • Status: open  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    According to the semantics sub-clause of the §7.3.10, it seems that the intent is that there is a relationship between the context and the owner of the constraint:

    “In general there are many possible kinds of owners for a Constraint. The only restriction is that the owning element must have access to the constrainedElements.

    The owner of the Constraint will determine when the constraint specification is evaluated. For example, this allows an Operation to specify if a Constraint represents a precondition or a postcondition”

    I not sure it is possible to define a constraint without a context. I believe a constraint always has a context even if it is an implicit one.

    Maybe a convenient solution would be to make the context non-derived but mandatory ([1..1]) with a default value set to the constraint’s owner.

  • Reported: UML 2.5 — Tue, 16 Mar 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Timing Diagram and interchange

  • Key: UMLR-223
  • Legacy Issue Number: 15207
  • Status: open  
  • Source: Anonymous
  • Summary:

    In the more compact version of the Timing diagram (figure 14.30) we can see the change in state of a lifeline as it goes from one state to another.
    In particular, we see how the lifeline moves from the "Idle" state, then to other states, then back to "Idle".

    Some facts:
    If I'm interpreting this correctly, we are seeing StateInvariant on the timing diagram.
    StateInvariant is an InteractionFragment.
    The StateInvariant is kept in the Interaction::Fragment ordered collection.

    Issue:
    The problem is that if we move from the "Idle" state and then back to the same "Idle" state, we would have to create another StateInvariant to place in the Fragment collection - how else could we determine that we have moved back to the "Idle" state?
    StateInvariant also owns its Constraint, so there would be no way for the second StateInvariant to even refer to the same constraint as the first.
    Having to duplicate the StateInvariant and/or Constraint seems incorrect?
    ( As a side note, the spec uses the terminology "State or Condition" when it is refering to StateInvariant - I believe this is ambiguous )

    Am I overlooking something obvious? If not, I think this could not only pose problems for XMI interchange, but also seems to be inefficient.

    Any insight would be appreciated.

  • Reported: UML 2.5 — Fri, 16 Apr 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Missing constraints preventing contradictory GeneralizationSets.

  • Key: UMLR-400
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    It is possible for two Generalizations to be part of GeneralizationSet A and part of GeneralizationSet B, where is A is constrained to be disjoint and B is constrained to be overlapping,

    There should be some discussion and/or OCL preventing this

  • Reported: UML 2.5 — Sat, 6 Dec 2014 07:04 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

What is the default setting for disjoint/overlapping and complete/incomplete for generalizations that are not part of a GeneralizationSet

  • Key: UMLR-399
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Currently, a generalization set has the default (overlapping, incomplete).

    However, as a Generalization does not need to have a GeneralizationSet, there is no default semantics for unnamed Generalization.

    Perhaps an approach that has all unnamed Generalizations with the same generalized Classifier as part of an "unnamed" GeneralizationSet would work. This would allow unnamed generalizations to have default overlapping/disjoint complete/incomplete semantics

  • Reported: UML 2.5 — Fri, 5 Dec 2014 09:22 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

How can a GeneralizationSet not have any Generalizations?

  • Key: UMLR-398
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    9.7.2 Abstract Syntax allows a GeneralizationSet to have no Generalizations. This seems wrong. The GeneralizationSet applies to 1 or more Generalizations. When the last Generalization is deleted, any GeneralizationSet should be deleted.

  • Reported: UML 2.5 — Fri, 5 Dec 2014 09:04 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Ambiguity in description of TransitionKind

  • Key: UMLR-397
  • Legacy Issue Number: 19658
  • Status: open  
  • Source: Zeligsoft ( Ernesto Posse)
  • Summary:

    The spec seems to be contradictory regarding local transitions: in p. 378 is says that a local transition "[...] will not exit the composite (source) State, but it will exit and re-enter any state within the composite state that is in the current state configuration". Since it says "re-enter" it is implying that the current configuration doesn't change.
    However on p.328 it states that "for local Transitions the target Vertex must be different than the source Vertex". The only way I can reconcile the two is if by "source Vertex" and "target Vertex" they mean an exit point and entry point of the same composite state, i.e., being a self-transition.

    In summary, the formal definition in p.378 suggests that local transitions must be self-loops, while the description of p.328 suggests that local transitions cannot be self-loops. Both cases seem to be unnecessary restrictions, and there are no constraints in Transition enforcing those restrictions

  • Reported: UML 2.5 — Tue, 18 Nov 2014 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Two classes can share attributes by use of element import

  • Key: UMLR-385
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    A class, as a namespace, can import attributes of another class. This is not sharing a type, but sharing a slot, creating shared memory.

  • Reported: UML 2.5 — Tue, 4 Nov 2014 03:06 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

History pseudo states in protocol state machines

  • Key: UMLR-383
  • Legacy Issue Number: 19648
  • Status: open  
  • Source: KnowGravity Inc. ( Mr. Markus Schacher)
  • Summary:

    I see no reason why UML prohibits history pseudo states in protocol state machines (constraint at the bottom of page 362). As I understand history states, they are merely a syntactical convenience that may be loss-lessly converted into a semantically equivalent state machine without history states. However, using history states usually greatly simplifies the specification of complex protocol state machines.

  • Reported: UML 2.5 — Wed, 29 Oct 2014 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Message lines can cross without the first being asynchronous

  • Key: UMLR-381
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    In the description of Figure 17.3, where the messages of CardOut and OK cross before they are received, the description says.

    "Such communication may occur when the messages are asynchronous"

    Though this true, it is misleading. It's possible for the messages to cross even if the messages are synchronous. The sending lifeline may have multiple parts (or multiple threads), where each part (or thread) waits synchronously, the overall effect on the composite level is to look asynchronous. This was extensively discussed last year and the conclusion was that this was possible.

    Please eliminate the offending sentence

  • Reported: UML 2.5 — Thu, 30 Oct 2014 03:19 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Justification for messages on differnent sides of a gate being identical is not clear.

  • Key: UMLR-382
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    In the description of matching on gates...
    "Gates are matched by name, with a formal Gate matched with an actual Gate having the same name, and with an inner CombinedFragment Gate matched with an outer CombinedFragment Gate having the same name.

    The Messages for matched Gates must correspond. Messages correspond if they have identical name, messageSort, and signature property values, as well as being in the same direction."

    Matching the Gates makes sense. However, requiring the message details to match invariantly seems to be overly restrictive. For example, a message in the same direction, and messageSort, but perhaps with covariant/contravariant matching of parameters should be acceptable

  • Reported: UML 2.5 — Thu, 30 Oct 2014 04:24 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Tables 17.1, 17.3, 17.5, 17.6 Header Formats

  • Key: UMLR-369
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Header of these tables should be consistently aligned. The middle column header is bottom justified, while the left and right column headers appear top justified. They should all probably be middle justified.

  • Reported: UML 2.5 — Thu, 23 Oct 2014 18:37 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Need clarification between exceptionType and the type of the exceptionInput

  • Key: UMLR-379
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Can we see an example with both specified.

    Can they be different?

    Which can be unspecified?

  • Reported: UML 2.5 — Fri, 24 Oct 2014 07:09 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Does not seem possible to have an exception cause an interrupt (leave the region)

  • Key: UMLR-378
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Because of they use the same notation. an exception handler and the target of a interrupting edge look identical. However, the semantics are quite different. In the exception handler case, tokens are emitted from the protected behavior. In the interrupting edge case, tokens in the region are abandoned, and instead leave from the interrupting edge "handler"

    1) the notation is too similar and confusing to modelers and readers.
    2) It's not possible to have an exception cause a region to be abandoned. This is a common and desirable situation
    3) In some circumstances it would be impossible to distinguish between an exception handler and interruptible region "handler". Imagine an exception handler whose exception edge crosses an interruptible region boundary. The only way to be sure it was an interruptible region handler is if it has outgoing edges. Without them, it could be either.

  • Reported: UML 2.5 — Fri, 24 Oct 2014 06:53 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

What exception type is "any" exceptionType

  • Key: UMLR-377
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    The discussion of exception handlers seems that it is possible ot have an an "any" exception type.

    p 439
    "exceptionType : Classifier [1..*] (opposite A_exceptionType_exceptionHandler::exceptionHandler)
    The Classifiers whose instances the ExceptionHandler catches as exceptions. If an exception occurs whose type is any exceptionType, the ExceptionHandler catches the exception and executes the handlerBody."

    What is "any" and how do you specify it. Please clarify within the specificaiton.

  • Reported: UML 2.5 — Fri, 24 Oct 2014 06:38 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Vertical lines do not always describe the time-line for an interaction diagram

  • Key: UMLR-373
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    In an interaction diagram each vertical line describes the time-line for a process, where time increases down the page.

    This is only true for sequence diagrams. Timing diagram use horizontal ordering. Communication and Interaction Overview diagrams may have incidental non-time ordered vertical lines.

    The following text from the spec should be qualified to only discuss sequence diagrams

    17.1.3 Partial ordering constraints on valid and invalid traces
    ...
    In an interaction diagram each vertical line describes the time-line for a process, where time increases down the page.

    17.3.3 Semantics
    Lifelines
    In an interaction diagram a Lifeline describes the time-line for a process, where time increases down the page

  • Reported: UML 2.5 — Fri, 24 Oct 2014 04:33 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Spelling error in ActivityGoups

  • Key: UMLR-367
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    15.6.1 Summary
    ActivityGoups are a grouping consturcts.

  • Reported: UML 2.5 — Wed, 22 Oct 2014 18:07 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Message wildcards appear to ignore operation default values

  • Key: UMLR-370
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Operations may contain a list of Parameters, which are defined in 9.4.4.

    Parameters may an '= <default>' to specify the default value for that parameter.

    However, in Messages, argument wi/o values are given wildcard values, representing any legal value.

    A wildcard could be representing the default value, but as described, it appears that it need not be – it can be ANY legal value.

    This means that it is impossible to specify a message that uses the default values of a parameter wi/o making them explicit. This makes the specification of default values to operation parameters not applicable to messages. This seems unintended. (If intended, then it is wrong)

    The discussion of message wildcards should indicate that (at least for input arguments), an unspecified value or wildcard will use the parameter default.

    If this is somewho intended the specification needs to be explicit and come up with a way of making the default values useful.

  • Reported: UML 2.5 — Thu, 23 Oct 2014 20:05 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

use of ! instead of + or ∪

  • Key: UMLR-372
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    The semantics of an Interaction are expressed in terms of a pair [P, I], where P is the set of valid traces and I is the set of invalid traces. P ! I need not be the whole universe of traces.

    The ! symbol should be eitther + or ∪

  • Reported: UML 2.5 — Fri, 24 Oct 2014 04:10 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Extraneous " (double quote) in 17.5.4 BehaviorExecutionSpecification

  • Key: UMLR-371
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    See "17.2.4 (ExecutionSpecification).

    Please delete the unneeded doublequote (")

    This is similar to UMLR-389

  • Reported: UML 2.5 — Thu, 23 Oct 2014 20:08 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Coloring and shading on Figure 17.10 should be removed

  • Key: UMLR-376
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Standardize on tool -independence look

  • Reported: UML 2.5 — Fri, 24 Oct 2014 06:29 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Caption for Table 17.5 on wrong page

  • Key: UMLR-375
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Caption is on preceding page.

  • Reported: UML 2.5 — Fri, 24 Oct 2014 06:27 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Mismatch of singular/plural Activity Goups are a grouping constructs

  • Key: UMLR-368
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Probably remove the "a"

  • Reported: UML 2.5 — Wed, 22 Oct 2014 18:10 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

SignalBroadcastAction used where BroadcastSignalAction should be.

  • Key: UMLR-357
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    SignalBroadcastAction used where BroadcastSignalAction should be.

    While each message is targeted at exactly one receiver object and caused by exactly one sending object, an occurrence of a sending event may result in a number of messages being generated (as in SignalBroadcastAction, see sub clause 16.3).

    While each message is targeted at exactly one receiver object and caused by exactly one sending object, an occurrence of a sending event may result in a number of messages being generated (as in SignalBroadcastActionBroadcastSignalAction, see sub clause 16.3).

  • Reported: UML 2.5 — Thu, 2 Oct 2014 02:56 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Spelling error: i-->is

  • Key: UMLR-356
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    The letter "i" is used when I presume that the word "is" should be

    o ActionInputPins with fromActions that are ReadVariableActions may be shown in a shorthand notation that i only the ActionInputPin and nearby the name of the variable of the ReadVariableAction interchanged as a UMLNameLabel with the variable as modelElement.

    o ActionInputPins with fromActions that are ReadVariableActions may be shown in a shorthand notation that i it only the ActionInputPin and nearby the name of the variable of the ReadVariableAction interchanged as a UMLNameLabel with the variable as modelElement.

  • Reported: UML 2.5 — Thu, 2 Oct 2014 02:46 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML 2.5 Section 15.2.3 p392 description for the ActivityEdge weight

  • Key: UMLR-350
  • Legacy Issue Number: 19540
  • Status: open  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    The description for the ActivityEdge weight includes:

    It must evaluate to a positive LiteralUnlimitedNatural
    and may be a constant.

    I think that should be "an UnlimitedNatural value" rather
    than "LiteralUnlimitedNatural". (I'm not sure there's
    any need to specify that it may be a constant either.)

  • Reported: UML 2.5 — Thu, 24 Jul 2014 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Another UML 2.5 Beta 2 XMI invalidity

  • Key: UMLR-349
  • Legacy Issue Number: 19538
  • Status: open  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    For constraint specifications that "Cannot be expressed in OCL",
    there is an invalid language attribute in the XMI. For example:

    <specification xmi:type="uml:OpaqueExpression" xmi:id="ObjectFlow-same_upper_bounds-_specification" language=""/>

    language is a multivalued property with primitive type and these
    can only be represented as elements.

    (In 2.4.1 such unexpressable constraints were represented as
    (OCL,true), it's not clear the above change is intentional.)

  • Reported: UML 2.5 — Tue, 22 Jul 2014 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Unclear statement regarding Lifeline shape

  • Key: UMLR-323
  • Legacy Issue Number: 19337
  • Status: open  
  • Source: gmail.com ( Florian Schneider)
  • Summary:

    Section 17.3.4 states

    "The Lifeline head has a shape that is based on the classifier for the part that this lifeline represents."

    "part" is ambiguous. Its meaning can not be inferred from the specification of the Lifeline class. Can you change the wording of this sentence to clarify what is meant by "part" ?

    Proposed change : The Lifeline head has a shape that is based on the Type of the ConnectableElement that this lifeline represents.

  • Reported: UML 2.5 — Wed, 16 Apr 2014 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML 2.5 Overly strict restriction on message slope in seq diagrams

  • Key: UMLR-322
  • Legacy Issue Number: 19335
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    In UML 2.5 Paragraph 17.4.4. Notation

    Message:
    “..A line must be such that every line fragment is either horizontal or downwards when traversed from send event to receive event.”

    While this restriction appears reasonable when first read, it is really overly strict.

    No, I’m not talking about faster-than-light messages.

    In the default, WEAK, interpretation of sequence diagrams, the time-wise ordering of occurrences within a lifeline is independent of occurrences on other lifelines, subject to cause/effect sequencing (message sending—>message reception). And, of course, the order of occurrences as depicted on the lifeline must be maintained.

    This is practically equivalent to saying that each lifeline has its own clock or timescale, and that ordering by that clock must be maintained and that causality across lifelines must be maintained. It is often thought that one could change the timescale (and not necessarily smoothly) on a lifeline without changing the interpretation or legality of the diagram.

    And as each life-line’s time scale need not be uniform, a message going from one location on one lifeline to another lifeline but physically higher need not violate any logical or physical limitations.

    However, the restriction on messages not taking a non-negative slope, prevents otherwise legal changes in scale and makes invalid some diagrams that do not violate causality or the within-lifeline ordering.

    Please eliminate the restriction preventing upward aiming message lines when the ordering is weak. This will allow the modelers to have better use of the diagram real-estate.

  • Reported: UML 2.5 — Sun, 13 Apr 2014 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Unnamed elements in a namespace

  • Key: UMLR-325
  • Legacy Issue Number: 19342
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    I’ve asked myself what happens when a namespace owns members that have no name. For example two outgoing include relationships from a use case. A include relationship is a named element that typically has no name.

    NamedElement defines the query isDistinguishableFrom():

    isDistinguishableFrom(n : NamedElement, ns : Namespace) : Boolean The query isDistinguishableFrom() determines whether two NamedElements may logically co-exist within a Namespace. By default, two named elements are distinguishable if (a) they have types neither of which is a kind of the other or (b) they have different names.

    body: (self.oclIsKindOf(n.oclType()) or n.oclIsKindOf(self.oclType())) implies

    ns.getNamesOfMember(self)>intersection(ns.getNamesOfMember)>isEmpty()

    If I call that query at a unnamed include relationship with another unnamed include relationship as paramer n and the owning use case as namespace ns, the query returns true. That means two unnamed elements in a namespace are distinguishable which seems to be wrong from my point of view.

    Is that an issue or did I miss something?

  • Reported: UML 2.5 — Tue, 8 Apr 2014 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Including use case depends on included use case but Include is no subclass of Dependency

  • Key: UMLR-324
  • Legacy Issue Number: 19338
  • Status: open  
  • Source: gmail.com ( Florian Schneider)
  • Summary:

    The following sentences of the specification made me wonder why Include is no subclass of Dependency.

    "As the primary use of the Include relationship is for reuse of common parts, what is left in a base UseCase is usually not complete in itself but dependent on the included parts to be meaningful. This is reflected in the direction of the relationship, indicating that the base UseCase depends on the addition but not vice versa."

    Instead of the dependency being reflected in the direction of the relationship, the class could explicitly have Dependency semantics.

  • Reported: UML 2.5 — Wed, 16 Apr 2014 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML 2.5 Visibility of a packagedElement

  • Key: UMLR-318
  • Legacy Issue Number: 19325
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    12.2.4 Notation

    The visibility of a packagedElement may be indicated by preceding the name by a visibility symbol (‘+’ for public and ‘-’ for private). Packages may not have protected or package visibility.

    This is a bit unclear, as the 2nd sentence does not include the first. I think you should say:

    …

    Package and their contained elements may not have protected or package visibility.

  • Reported: UML 2.5 — Mon, 31 Mar 2014 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML 2.5 Issue on DI for reply arrows

  • Key: UMLR-317
  • Legacy Issue Number: 19324
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    In the UML 2.5 spec, the reply arrow on sequence diagrams now has two forms.

    17.4.4 Notation

    Message

    · A reply Message (messageSort equals reply) has a dashed line with either an open or filled arrow head.

    However, the DI section of the specification, p 754.

    Only allows the filled arrow head and does not support an option to specify which.

    This will mean that diagram interchange will not preserve use of the open arrow head (which is the traditional way of doing this)

    Michael Jesse Chonoles

    Change-Vision.

  • Reported: UML 2.5 — Mon, 31 Mar 2014 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Ambiguous Profile::profileApplication

  • Key: UMLR-316
  • Legacy Issue Number: 19323
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    Profile::profileApplication

    {subsets directedRelationship wrt target}

    and occludes Package::profileApplication

    {subsets directedRelationship wrt source}

    .

    This means that

    aProfile.profileApplication <> aProfile.oclAsType(Package).profileApplication

    Since Profile::profileApplication is unnavigable, suggest renaming Profile::profileApplication as Profile::application

  • Reported: UML 2.5 — Mon, 31 Mar 2014 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML transition-centric state machine arrows (01) alternative exit pt vs entry pt notation

  • Key: UMLR-319
  • Legacy Issue Number: 19329
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    In the UML 2.5 spec Figure 14.31 shows and the text describes the alternative exit point notation as a bracketed space

    — (exit point name) —

    The UML 2.5 spec in Figure 14.30 shows and the text describes the alternative entry point notation as a bracketed space with the string “via”.

    — (via entry point name) →

    This leaves the following, albeit pathological case:

    1st state — (via pointName) → 2nd state

    From the notation, you can’t be sure if “pointName” is the name of the entry point or if “via pointName” is the name of the exit point.

    One possible interpretation of the spec goes back to diagram in 14.32 and notices that there is no “leaving arrow head” (→) from the symbol for the exit point, but there is one for the entry point. If this is not accidental, then

    1st state — (via pointName) → 2nd state

    means the entry point pointName

    And the

    1st state — (via pointName) — 2nd state

    means the exit point “via pointName”

    However, this is pretty obscure and if intended should be clarified in the spec. If not intended, either “via” should be explicitly reserved (not allowed) in exit point names or the notation modified to distinguish them.

  • Reported: UML 2.5 — Sat, 5 Apr 2014 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML 2.5 issue on examples in 17.4.5

  • Key: UMLR-321
  • Legacy Issue Number: 19334
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    In 17.4.5, the 3rd example, is

    V=mymsg(w=myout:16):96

    However, the description says

    “This is a reply message assigning the return value 69 to ‘v’

    Choose either 96 or 69 and make consistent.

  • Reported: UML 2.5 — Sun, 13 Apr 2014 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML transition-centric state machine arrows (02) solid vs v-shaped arrow heads

  • Key: UMLR-320
  • Legacy Issue Number: 19330
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    2nd related issue

    All the notation in the alternative transition-centric examples use solid, filled arrow heads. All the notation for the traditional state-centric examples use v-shaped arrow heads. However, the text never mentions this difference. The spec should clarify if this is part of the notation.

  • Reported: UML 2.5 — Sat, 5 Apr 2014 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML 2.5 Figure 10.10 Error

  • Key: UMLR-312
  • Legacy Issue Number: 19285
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    In UML 2.5, Figure 10.10 is entitled

    ISensor is a required Interface of TheftAlarm

    However, the figure only shows an unnamed required Interface.

    The diagram needs to have the Interface named “ISensor” on the diagram.

  • Reported: UML 2.5 — Thu, 20 Mar 2014 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Name of Package in Figure 7.3 should be "Core" rather than "Constructs"

  • Key: UMLR-311
  • Legacy Issue Number: 19282
  • Status: open  
  • Source: lemke24.org ( Andreas Lemke)
  • Summary:

    The subtitle of the Figure 7.3:
    "The Core Packages"
    But the Name of the Package in the figure is "Constructs".

  • Reported: UML 2.4.1 — Mon, 10 Mar 2014 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Multiple Generalization Sets

  • Key: UMLR-313
  • Legacy Issue Number: 19288
  • Status: open  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    A generalization can appear in multiple generalization sets. The notation
    for this isn't completely clear to me as there are no examples of this
    case in the spec and the existing examples would be ambiguous if followed.

    The main problem is that there are multiple labels for the generalization
    set properties, for example the :TreeSpecies and

    {disjoint, incomplete}

    labels in the Tree example. Somehow these need to be visually joined to
    show they are properties of the same set. Additionally there are no
    examples showing the set name and any other properties so it's not clear
    what the full notation is.

    I'd guess the notation should actually be a single label in the form:

    name

    {complete, disjoint} : PowerType


    or

    {complete, disjoint}

    name : PowerType

    Which of those makes most sense?

  • Reported: UML 2.5 — Fri, 21 Mar 2014 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML 2.5 Figure 14.25 Choice Pseudostates

  • Key: UMLR-314
  • Legacy Issue Number: 19320
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Figure 14.25 Choice Pseudostates (and text above/below)

    The description of the figure indicates that the left hand (sub)diagram indicates the empty diamond should be on the right and the one with the operand inside the diamond should be on the left.

    The subdiagrams are backwards.

  • Reported: UML 2.5 — Sun, 30 Mar 2014 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

isReplaceAll=true and lowerBound > 1

  • Key: UMLR-277
  • Legacy Issue Number: 18951
  • Status: open  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    About the AddStructuralFeatureAction the UML 2.5 spec states that, if isReplaceAll is true: “[…]The StructuralFeature always has a single value when the Action completes, even if the lower multiplicity of the StructuralFeature is greater than 1 “( §16.8.3).

    In the other hand, the semantics of the multiplicities states the following (§7.5.3): “If a MultiplicityElement specifies a multivalued multiplicity (i.e., upper bound greater than 1), then an instantiation of this element has a collection of values. The multiplicity is a constraint on the number of values that may validly occur in that set.”.

    Does it mean that executing this action with isReplaceAll=true on a structural feature with a lower multiplicity greater than one will result in an invalid model or, in other words, that such a usage is somehow “illegal”?

  • Reported: UML 2.5 — Fri, 13 Sep 2013 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

test

  • Key: UMLR-276
  • Legacy Issue Number: 18239
  • Status: open  
  • Source: Object Management Group ( Mr. Juergen Boldt)
  • Summary:

    test

  • Reported: UML 2.5 — Fri, 27 Jun 2014 11:17 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

applying and associating stereotypes and explanation of all aspects of their serialization

  • Key: UMLR-275
  • Legacy Issue Number: 17564
  • Status: open  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    UML needs to explain in terms of UML what applying and associating
    stereotypes means and additionally needs to explain all aspects of their
    serialization. The UML specification has yet to explain what it means what "applying a stereotype" and what "stereotypes can participate in associations" mean in terms of UML.

    Since the UML profile mechanism is definitely not a metamodeling extension facility, these explanations must be made in terms of UML directly rather than indirectly via the "MOF2-equivalent semantics".

    Below is a 3-step proposal to explain what "applying a stereotype" and "stereotypes can participate in associations" mean in terms of UML.
    This proposal is illustrated using the SysML profile definition of the ValueType, Unit and QuantityKind stereotypes shown below:

    Point #1) The UML specification only shows how an instance of a stereotype is serialized but it does not say what that serialization is in terms of the UML metamodel.

    For example, we have:

    • 2 serializations of UML::InstanceSpecification

    <packagedElement xmi:type="uml:InstanceSpecification"

    xmi:id="_ISO-80000-1-SysML_mass_PackageableElement"

    name="mass">

    <packagedElement xmi:type="uml:InstanceSpecification"

    xmi:id="_ISO-80000-1-SysML_kilogram_PackageableElement"

    name="kilogram">

    • 2 serializations of instances of stereotypes, QuantityKind and Unit.

    <sysml:QuantityKind xmi:id="ISO-80000-1-SysML_mass_PackageableElement-appliedStereotypeInstance_InstanceSpecification"

    base_InstanceSpecification="_ISO-80000-1-SysML_mass_PackageableElement"/>

    <sysml:Unit xmi:id="ISO-80000-1-SysML_kilogram_PackageableElement-appliedStereotypeInstance_InstanceSpecification"

    base_InstanceSpecification="_ISO-80000-1-SysML_kilogram_PackageableElement"

    quantityKind="_ISO-80000-1-SysML_mass_PackageableElement-appliedStereotypeInstance"

    symbol="kg"/>

    I claim that serializations of instances of stereotypes are in fact just serializations of UML::InstanceSpecifications whose classifiers are stereotypes.

    That is, the above two elements are really a different serialization of the following:

    <packagedElement xmi:id="ISO-80000-1-SysML_mass_PackageableElement-appliedStereotypeInstance_InstanceSpecification"

    xmi:type="uml:InstanceSpecification"

    classifier="_SysML_Blocks_PackageableElement-QuantityKind_PackageableElement"
    base_InstanceSpecification="_ISO-80000-1-SysML_mass_PackageableElement"/>

    <packagedElement xmi:id="ISO-80000-1-SysML_kilogram_PackageableElement-appliedStereotypeInstance_InstanceSpecification"

    xmi:type="uml:InstanceSpecification"

    classifier="_SysML_Blocks_PackageableElement-Unit_PackageableElement"

    base_InstanceSpecification="_ISO-80000-1-SysML_kilogram_PackageableElement"

    quantityKind="_ISO-80000-1-SysML_mass_PackageableElement-appliedStereotypeInstance"

    symbol="kg"/>

    The rationale for this is simply that we must be able to specify constraints in OCL as well as queries/transformations in QVT and actions in any action language (e.g., ALF) where we can operate on instances of stereotypes without having to implement profile-specific tooling.

    Point #2) The UML specification should explicitly say that:

    2.1) an instance of a stereotype is a distinguished instance of UML::InstanceSpecification whose classifier is the stereotype definition

    2.2) what distinguishes an UML::InstanceSpecification whose classifier is a UML::Stereotype is that it is serialized differently than any other UML::InstanceSpecification (whose classifier is not a UML::Stereotype)

    The rationale for (2.1) is that this is the simplest way to address this point without introducing a new metaclass in the UML metamodel.
    The rationale for (2.2) is that we need a way to tell how to serialize any UML::InstanceSpecification, whether it is an instance of a stereotype or something else.

    Point #3) The meaning of "stereotypes can participate in associations" is that it is possible to create link instance of such an association (i.e., a UML::InstanceSpecifications) and that the slots of this link instance refer to the distinguished UML::InstanceSpecifications corresponding to the instances of the stereotypes related via such a link.

    The problem is that the UML specification (2.4 and 2.5) does not say how to serialize such links.

    This is something that caused me a lot of headaches when producing the XMI for SysML 1.3.
    Because the ISO-80000-1-SysML.xmi and ISO-80000-1-QUDV.xmi are libraries, there will be references to elements defined in them.
    Since the SysML profile has associations between Unit & QuantityKind, it means that we should be able to externally refer to particular links between particular instances of Unit & QuantityKind.

    I tried to do this in 1.3 but I realize that I got it wrong, specifically, the slot values refer to the UML elements representing Unit and QuantityKind when in fact they should be referring to the distinguished UML::InstanceSpecifications representing the instances of Unit & QuantityKind (see in bold below):

    <packagedElement xmi:type="uml:InstanceSpecification"

    xmi:id="_ISO-80000-1-SysML_a_kilogram_u00255Bunit_u00255D_mass_u00255BquantityKind_u00255D_PackageableElement"

    name="a_kilogram[unit]_mass[quantityKind]">

    <classifier href="http://www.omg.org/spec/SysML/20120322/SysML.xmi#_SysML_Blocks_PackageableElement-A_unit_quantityKind_PackageableElement"/>

    <slot xmi:type="uml:Slot"

    xmi:id="ISO-80000-1-SysML_a_kilogram_u00255Bunit_u00255D_mass_u00255BquantityKind_u00255D_PackageableElement-slot_Slot._SysML_Blocks_PackageableElement-A_unit_quantityKind_PackageableElement-unit_Property">

    <definingFeature href="http://www.omg.org/spec/SysML/20120322/SysML.xmi#_SysML_Blocks_PackageableElement-A_unit_quantityKind_PackageableElement-unit_Property"/>

    <value xmi:type="uml:InstanceValue"

    xmi:id="ISO-80000-1-SysML_a_kilogram_u00255Bunit_u00255D_mass_u00255BquantityKind_u00255D_PackageableElement-slotSlot._SysML_Blocks_PackageableElement-A_unit_quantityKind_PackageableElement-unit_Property-value_ValueSpecification.0"

    instance="_ISO-80000-1-SysML_kilogram_PackageableElement"/>

    </slot>

    <slot xmi:type="uml:Slot"

    xmi:id="ISO-80000-1-SysML_a_kilogram_u00255Bunit_u00255D_mass_u00255BquantityKind_u00255D_PackageableElement-slot_Slot._SysML_Blocks_PackageableElement-Unit_PackageableElement-quantityKind_Property">

    <definingFeature href="http://www.omg.org/spec/SysML/20120322/SysML.xmi#_SysML_Blocks_PackageableElement-Unit_PackageableElement-quantityKind_Property"/>

    <value xmi:type="uml:InstanceValue"

    xmi:id="ISO-80000-1-SysML_a_kilogram_u00255Bunit_u00255D_mass_u00255BquantityKind_u00255D_PackageableElement-slotSlot._SysML_Blocks_PackageableElement-Unit_PackageableElement-quantityKind_Property-value_ValueSpecification.0"

    instance="_ISO-80000-1-SysML_mass_PackageableElement"/>

    </slot>

    </packagedElement>

    These should have been:

    <packagedElement xmi:type="uml:InstanceSpecification"

    xmi:id="_ISO-80000-1-SysML_a_kilogram_u00255Bunit_u00255D_mass_u00255BquantityKind_u00255D_PackageableElement"

    name="a_kilogram[unit]_mass[quantityKind]">

    <classifier href="http://www.omg.org/spec/SysML/20120322/SysML.xmi#_SysML_Blocks_PackageableElement-A_unit_quantityKind_PackageableElement"/>

    <slot xmi:type="uml:Slot"

    xmi:id="ISO-80000-1-SysML_a_kilogram_u00255Bunit_u00255D_mass_u00255BquantityKind_u00255D_PackageableElement-slot_Slot._SysML_Blocks_PackageableElement-A_unit_quantityKind_PackageableElement-unit_Property">

    <definingFeature href="http://www.omg.org/spec/SysML/20120322/SysML.xmi#_SysML_Blocks_PackageableElement-A_unit_quantityKind_PackageableElement-unit_Property"/>

    <value xmi:type="uml:InstanceValue"

    xmi:id="ISO-80000-1-SysML_a_kilogram_u00255Bunit_u00255D_mass_u00255BquantityKind_u00255D_PackageableElement-slotSlot._SysML_Blocks_PackageableElement-A_unit_quantityKind_PackageableElement-unit_Property-value_ValueSpecification.0"

    instance="ISO-80000-1-SysML_kilogram_PackageableElement-appliedStereotypeInstance_InstanceSpecification"/>

    </slot>

    <slot xmi:type="uml:Slot"

    xmi:id="ISO-80000-1-SysML_a_kilogram_u00255Bunit_u00255D_mass_u00255BquantityKind_u00255D_PackageableElement-slot_Slot._SysML_Blocks_PackageableElement-Unit_PackageableElement-quantityKind_Property">

    <definingFeature href="http://www.omg.org/spec/SysML/20120322/SysML.xmi#_SysML_Blocks_PackageableElement-Unit_PackageableElement-quantityKind_Property"/>

    <value xmi:type="uml:InstanceValue"

    xmi:id="ISO-80000-1-SysML_a_kilogram_u00255Bunit_u00255D_mass_u00255BquantityKind_u00255D_PackageableElement-slotSlot._SysML_Blocks_PackageableElement-Unit_PackageableElement-quantityKind_Property-value_ValueSpecification.0"

    instance="ISO-80000-1-SysML_mass_PackageableElement-appliedStereotypeInstance_InstanceSpecification"/>

    </slot>

    </packagedElement>

    Point #3) There is no crossing of metalevels in SysML's ValueType (extension of UML::DataType) associated to stereotypes extending UML::InstanceSpecification (Unit, QuantityKind)

    In practice, it means that if we defined, say, "MassInKilograms", a UML::DataType and applied SysML::ValueType to it, we would have something like this:

    <packagedElement xmi:type="uml:DataType"

    xmi:id="123"

    name="MassInKilograms"/>

    <sysml:ValueType xmi:id="456" base_DataType="123"

    unit="ISO-80000-1-SysML_kilogram_PackageableElement-appliedStereotypeInstance_InstanceSpecification"

    quantityKind="ISO-80000-1-SysML_mass_PackageableElement-appliedStereotypeInstance_InstanceSpecification"/>

    And we should be able to explicitly create a link instance for the association between ValueType & Unit and its slots would refer to the distinguished UML::InstanceSpecifications corresponding to the stereotype instances thus related, I.e.:

    "456" and "ISO-80000-1-SysML_kilogram_PackageableElement-appliedStereotypeInstance_InstanceSpecification"

    Similarly, the link instance for the association between ValueType & QuantityKind would have as its slots the following:

    "456" and "ISO-80000-1-SysML_mass_PackageableElement-appliedStereotypeInstance_InstanceSpecification"

    The rationale for this point is that since stereotypes can participate in associations, it follows that instances of stereotypes can be linked via instances of such associations.

  • Reported: UML 2.5 — Mon, 27 Aug 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Relax Association::/endType from [1..*] to [0..*]

  • Key: UMLR-279
  • Legacy Issue Number: 18969
  • Status: open  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    An association could be defined with untyped association ends.

    UML2.5 currently prevents defining such associations.
    If it becomes well-formed in 2.6, this capability will be useful for the Precise Semantics of Composite Structures, particularly for untyped connectors.

  • Reported: UML 2.5 — Thu, 26 Sep 2013 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Problems with OCL definition of Package::makesVisible

  • Key: UMLR-278
  • Legacy Issue Number: 18955
  • Status: open  
  • Source: Dassault Systemes ( Mr. Tomas Juknevicius)
  • Summary:

    Looking at the UML2.5 specification draft (I have the document UML25AfterBallot9.pdf - not sure if this is the newest one)
    I see problems with definition of Package::makesVisible - which is expressed in OCL.:

    makesVisible(el : NamedElement) : Boolean
    The query makesVisible() defines whether a Package makes an element visible outside itself. Elements with no visibility and elements with public visibility are made visible.
    pre: member->includes(el)
    body: ownedMember->includes(el) or
    (elementImport->select(ei|ei.importedElement = VisibilityKind::public)>collect(importedElement.oclAsType(NamedElement))>includes(el)) or
    (packageImport->select(visibility = VisibilityKind::public)>collect(importedPackage.member>includes(el))->notEmpty())

    Actually those problems carry on from the previous versions of UML;
    but since in previous versions even the OCL syntax was wrong (carried over from the pre-OCL2.0 times)
    I assumed this section is old/abandoned and did not pay much attention to it.

    But now with UML2.5 somebody took it seriously to update the syntax of the OCLs (kudos for that brave soul ), so we have an updated variant.
    But while the raw syntax problems were fixed, semantic problems were carried form the old revision verbatim.
    If we are updating OCLs anyway, I think it would be a good time to also correct those.

    So here goes:

    --------------------------------------------------------------------------------

    Problem #1

    the following comparison is nonsensical (the case handling ElementImports, line #2 of the body):

    ei.importedElement = VisibilityKind::public

    The OCL here tries to compare the model element (at the end of ElementImport relationship) with the enumeration literal - VisibilityKind::public, which is not what we want
    I think this passage should be restated as follows:

    ei.visibility= VisibilityKind::public

    i.e. we want to test whether element import has visibility set to public, just as in the other case - with package imports - one line below.

    Also the whole case handling element imports could be rewritten to simplify it:
    elementImport->exists(ei|ei.visibility = VisibilityKind::public and ei.importedElement = el)
    This does not change the semantics, but is much better readable/understandable: we are iterating through all (public) element imports
    checking whether imported element matches the element el.

    --------------------------------------------------------------------------------

    Problem #2
    the case handling package imports (line #3 of the body) is also borked:

    packageImport->select(visibility = VisibilityKind::public)>collect(importedPackage.member>includes(el))->notEmpty()

    Here the first part of the expression is OK; we take all package import relationships and filter them - accept only public ones:

    packageImport->select(visibility = VisibilityKind::public)

    But the next part again makes no sense

    ...>collect(importedPackage.member>includes(el))->notEmpty()

    here expression part

    importedPackage.member->includes(el)

    produces a boolean - whether element el is included among the members of the package being imported.
    So the result of the expression part

    ...>collect(importedPackage.member>includes(el))...

    is a collection of booleans (of the form:

    {false, false, true, false, true}

    ),
    where each boolean signifies whether element is among the members of each particular imported package.

    Then it makes no sense to test that for emptiness:

    ->notEmpty()

    this produces true if there is at least one item (does not matter true, or false) in that bag of booleans.
    So that part produces true if there is at least 1 public package import ( it does not matter what package is imported).

    I think this passage should be restated as follows:

    packageImport->select(visibility = VisibilityKind::public)>exists(importedPackage.member>includes(el))

    I.e. we are iterating through all (public) package imports and checking whether element el appears among members
    of at least one of the imported packages.

    --------------------------------------------------------------------------------

    So the final OCL of makesVisible could be (also getting rid of some unnecessary parentheses, and further simplification):

    pre: member->includes(el)
    body:
    ownedMember->includes(el) or
    elementImport->exists(ei|ei.visibility = VisibilityKind::public and ei.importedElement = el) or
    packageImport->exists(pi|pi.visibility = VisibilityKind::public and pi.importedPackage.member->includes(el))

  • Reported: UML 2.5 — Tue, 24 Sep 2013 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Specifying the multiplicity of a part with an attribute

  • Key: UMLR-274
  • Legacy Issue Number: 17536
  • Status: open  
  • Source: Lockheed Martin ( John Watson)
  • Summary:

    This is a request to add a capability in UML to specify the upper and/or lower multiplicity value of a part (composite aggregation relationship) with a class attribute of type integer; typically this attribute is a derived attribute. When derived, a constraint can be used to define the value derivation.

    This capability has been found to be useful in the following applications.
    1. When reference models are re-used in different contexts this capability allows some variants to be specified in the reference model and the value be automatically derived based on its use in the new context.
    2. The value of the multiplicity to be used for a specific configuration may be derived through an analysis performed external to the model.

    A diagram is available that shows an example of the concrete syntax that could be used. In this example a constraint is defined for the attribute “numberOfPedals”. If this diagram would be helpful and I can forward it. I did not see a means of attaching a jpg diagram to this on-line form.
    This capability can be developed in a way that does not impact on code generation or execution, as the values can all be constant at run time (and at code-generation time).
    The primary purpose of this is to allow the ability to have reference models for variations without using the overhead of templates (otherwise the whole model might need to be a template of template, which would certainly be unwieldy and confusing), and to allow for a common way of specifying this for descendant languages like SysML.

  • Reported: UML 2.5 — Thu, 2 Aug 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Link notation for stereotype property value

  • Key: UMLR-273
  • Legacy Issue Number: 17464
  • Status: open  
  • Source: PTC ( Mr. Simon Moore)
  • Summary:

    It would be very useful if a notation was defined to allow a stereotype instance property value which references another instance in the model to be shown as a link on a diagram.

    For example, a stereotype Foo could have a property Bar of type Foo (in order that one Foo can reference another Foo). On a diagram showing two instances of Foo, you could then add and show a link between them labelled Bar rather than only being allowed to use a compartment or callout note.

    This would be useful to many profiles, but I couldn't find an existing issue which covered it.

  • Reported: UML 2.5 — Mon, 2 Jul 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Generalization should be allowed to be cyclic and should no be restricted to be owned by the specialized classifier

  • Key: UMLR-272
  • Legacy Issue Number: 17393
  • Status: open  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    Currently, UML 2.4.1 requires that:
    The graph of classifier generalization relationships must be acyclic
    See 7.3.8 Classifier [2]

    Generalization hierarchies must be directed and acyclical. A classifier cannot be both a transitively general and
    transitively specific classifier of the same classifier.

    This constraint probably came from the influence of programming languages on the design of the UML.
    This constraint is certainly useful in many domain-specific applications of the UML but it is certainly not useful across all domains.
    For example, in ontologies, it is common practice to use circular generalization relationships among classifiers to express their semantic equivalence; see: http://www.w3.org/TR/owl2-syntax/#Equivalent_Classes
    The ODM 1.0 includes this approach as an option for using the UML as a notation for OWL1 ontologies — see 14.2.5.11 in http://www.omg.org/spec/ODM/1.0/
    A generalization must be owned by the specialized classifier
    See 7.3.20:

    specific: Classifier [1]
    References the specializing classifier in the Generalization relationship. Subsets DirectedRelationship::source and
    Element::owner

    This ownership constraint prevents using the UML where a generalization between A and B needs to be added without modifying A or B.

  • Reported: UML 2.5 — Fri, 27 Jun 2014 11:17 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Interaction.action should subset ownedMember in lieu of ownedElement

  • Key: UMLR-270
  • Legacy Issue Number: 17315
  • Status: open  
  • Source: Fraunhofer FOKUS ( Mr. Marc-Florian Wendland)
  • Summary:

    In Figure 14.5 of UML 2.4.1 (and still valid for UML 2.5), the association end 'action' of Interaction subsets Element.ownedElement. Since Interaction is a Namespace and Action a NamedElement, I reckon it ought to subset Namespace.ownedMember instead.

  • Reported: UML 2.4.1 — Thu, 19 Apr 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Message Signature in Interactions and Reception.ownedParameter

  • Key: UMLR-269
  • Legacy Issue Number: 17226
  • Status: open  
  • Source: Fraunhofer FOKUS ( Mr. Marc-Florian Wendland)
  • Summary:

    currently (till 2.5) a message's signature is of type NamedElement that
    resolves either to an Operation or Signal. Apart from the fact that the
    nearest common superclass is Namespace, the use of elements of different
    inheritance hierarchies makes it cumbersome/impractical to work with the
    signatures easily. You always have to check what concrete signature is
    associated, cast it into the appropriate subclass (i.e. either Signal or
    Operation) and use it further.

    Regarding Message::Signature, I was wondering, whether it wouldn't be
    simpler and far more consistent to refer to a BehavioralFeature
    (Operation/Reception which has to have an Signal associated) directly
    instead of NamedElement (which ought to be Namespace)?

    This leads to a situation where I was wondering why a Reception, though
    it is a BehavioralFeature, does not say any word about owned parameters
    at all? However, if Receptions would be able to capture information
    about parameter, too, the treatment of Reception and Operation would be
    pretty much the same with regard to their parameter semantics. So, it
    might be worth to reconsider the relationship between BehavioralFeature,
    Reception and Parameter. We could supplement

    BehavioralFeature::ownedParameter

    {ordered, subsets Namespace::ownedMember}

    containment

    with

    /Reception::ownedParameter [0..1]

    {redefines BehavioralFeature::ownedParameter }

    containment

    The derivation algorithm of Reception::ownedParameter could be similar
    to the following: A Reception declares at most one Parameter. Its type
    and name must exactly the name and type of the Signal, referenced by
    Reception::signal, if present. The direction kind of a Reception's
    Parameter must be set to IN exclusively.

    context Reception
    inv 'parameter':
    if not self.signal.oclIsUndefined then
    not self.ownedParameter.oclIsUndefined and
    self.ownedParameter.type = self.signal and self.ownedParameter.name =
    self.signal.name and self.ownedParameter.directionKind ==
    ParameterDirectionKind::IN
    else
    endif

    This would ease the usage of BehavioralFeatures a lot, I'd say. In case
    of Messages, one would only have to walk over
    Message::signature::parameter instead of casting it down to either an
    Operation or Signal..

  • Reported: UML 2.5 — Mon, 12 Mar 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Migrate UML::Component's ability to own UML::PackageableElements to UML::Class

  • Key: UMLR-271
  • Legacy Issue Number: 17390
  • Status: open  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    UML2.4.1 Superstructure, section 8.3, Figure 8.4 shows that UML::Component has a composite association to UML::PackageElement; that is:

    UML::Component::packagedElement : UML::PackageableElement

    { subsets UML::Namespace::ownedMember }

    This is the only place in the UML metamodel where a kind of UML::Classifier has the capability to own arbitrary kinds of UML::PackageableElements.

    As long as the classifier capabilities needed in practice are within the scope of what UML::Class already provides, then it is practically very useful to use UML::Component in lieu of UML::Class.
    By doing so, a UML::Component-as-an-enhanced-UML::Class gains the capability to own additional kinds of UML::PackageElements that a plain UML::Class cannot; e.g.:

    UML::Package, UML::Dependency, UML::InformationFlow, UML::ValueSpecification, UML::InstanceSpecification, UML::Event, UML::Observation, UML::Profile, UML::Model.

    Unfortunately, other kinds of UML::Class do not get such benefits. For example, a UML::StateMachine is a kind of UML::Class just like UML::Component but unlike UML::Component, it can't own arbitrary UML::PackageableElements.
    In particular, it cannot own any UML::Event even though this would make eminent sense in some cases (e.g., internal events not visible outside of the UML::StateMachine).

    Finally, the well-formedness and semantics of a kind of UML::Class with namespace-nested UML::PackageableElements need to be addressed for unusual combinations including but not necessarily limited to the following cases:

    1) nested UML::Profiles and UML::ProfileApplications
    2) specialization of a general classifier nested within its packagedElements
    3) applying a stereotype defined in a UML::Profile nested within its packagedElements
    4) the target of an elementImport from a UML::Namespace nested within its packagedElements

  • Reported: UML 2.5 — Fri, 27 Jun 2014 11:17 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Semantic error in UMLAssociationOrConnectorOrLinkShape::edge_instancespec invariant

  • Key: UMLR-282
  • Legacy Issue Number: 18973
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    The OCL in UMLDI for UMLAssociationOrConnectorOrLinkShape::edge_instancespec invariant at "memberEnd->includes(e.modelElement))" has a semantic error becuase e is already an Element.

    Suggest change "e.modelElement" to "e".

  • Reported: UML 2.5 — Fri, 27 Jun 2014 11:17 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Semantic error in Lifeline::interaction_uses_share_lifeline

  • Key: UMLR-281
  • Legacy Issue Number: 18972
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    The OCL for Lifeline::interaction_uses_share_lifeline has a semantic error at "... implies usingInteraction.lifeline->select..." the RHS of implies is non-Boolean.

    Changing "select" to "exists" makes the semantic problem go away

  • Reported: UML 2.5 — Tue, 24 Sep 2013 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

XMI.xmi is not merged

  • Key: UMLR-283
  • Legacy Issue Number: 18982
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    In UML 2.4.1 Infrastructure/Superstructure.xmi provided the raw Packages. XMI.xmi provided the merged packages so that in UML 2.4.1 we have uml::Association.

    UML 2.5 abandons the merge and so there is just XMI.xmi. uml::Association exists via an import, but the primary definition is now uml::StructuredClassifiers::Association.

    To preserve compatibility with the UML 2.4.1 metamodel, the unmerged packages could be provided in e.g. UMLPackages.xmi, with XMI.xmi providing the merged packages as before.

  • Reported: UML 2.5 — Tue, 1 Oct 2013 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

In the Use Case section, it is unclear whether a use case requires an actor

  • Key: UMLR-284
  • Legacy Issue Number: 19009
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    In the Use Case section, it is unclear whether a use case requires an actor.

    For example, in 18.1.3 it says:

    “Each UseCase specifies some behavior that a subject can perform in collaboration with one or more Actors.” Which requires at least one actor per Use Case. However, the resolution for 18045 deleted “one or more” from earlier in 18.1.3

  • Reported: UML 2.5 — Fri, 11 Oct 2013 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

ExtensionEnd upper/lower inconsistent with MultiplicityElement

  • Key: UMLR-280
  • Legacy Issue Number: 18971
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    Issue 13992 changes the cardinality of MultiplicityElement lower and upper. This was not tracked by ExtensionEnd, which consequently has validation errors.

  • Reported: UML 2.5 — Tue, 24 Sep 2013 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Lack of clarity about meaning of package shapes containing elements with fully qualified names

  • Key: UMLR-159
  • Legacy Issue Number: 13466
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    The UML specification is not clear what it means for an element with a fully qualified name to appear within a package shape on a package diagram.

    7.3.37 says “The members of the package may be shown within the large rectangle”. So it seems to rest on the definition of members, which is the union of owned members and imported members.

    This is somewhat reinforced by “elements that become available for use in an importing package through a package import or element import may have a distinct color or be dimmed to indicate that they cannot be modified”. Note that the definition of ElementImport says “identifies an element in another package, and allows the element to be referenced using its name without a qualifier”. So we’d expect imported elements to be dimmed, but not have a name qualification (a poor user experience if I may say so).

    Subsidiary issue: Why does it say that they cannot be modified? This is a matter for tool implementers, and has no place in the UML spec.

    But elsewhere it says “The public contents of a package are always accessible outside the package through the use of qualified names”;

    So how should I interpret the appearance of an element shape within a package shape when the element has its fully-qualified name (as frequently appears in the UML spec itself)? Does this imply the existence of an import or not? According to “The public contents of a package are always accessible outside the package through the use of qualified names” no import is necessary; according to “The members of the package may be shown within the large rectangle” an import is necessary. At the very least this should be clarified.

    More deeply perhaps the issue is that the definition of the term “referencing an element” is very dubious. Does appearing on a diagram involve referencing? How about appearing in tool windows, type pickers, etc?

  • Reported: UML 2.5 — Mon, 9 Feb 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section 9.3.4 Collaboration Use, 2nd constraint creates unneces

  • Key: UMLR-158
  • Legacy Issue Number: 13452
  • Status: open  
  • Source: Dell Technologies ( Mr. George Ericson)
  • Summary:

    Assuming one Collaboration represents mandatory features and another Collaboration wants to extend that. It seems natural to express only the differences in the second Collaboration and to use roleBinding to between properties of the extending Collaboration to properties of a CollaborationUse of the first. The implication is that properties of the first collaboration are included as part of the second collaboration, since the CollaborationUse is essentially an instantiation of the first Collaboration in the context of the second. The roleBindings indicate were instances of the properties of first are constrained to be instances of the second Collaboration.

    This usage would require that the 2nd constraint be modified and that properties of the CollaborationUse of the first Collaboration are interpreted as being incorporated into the second Collaboration except when there is a roleBinding between the properties of the first and second Collaborations.

  • Reported: UML 2.5 — Fri, 30 Jan 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML: Standard Techniques to disambiguate crossing lines needed

  • Key: UMLR-153
  • Legacy Issue Number: 13192
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    With the increasing use of UML and descendant languages (e.g.., SysML) for more complex diagramming situations, the occasion for crossing lines becomes increasingly hard to avoid. When such happens, it often becomes difficult to determine the correct start/destination of each line. This is compounded by the use of tree structures for the depicting of generalization and aggregation/composition relationships.

    Whenever two lines cross, there can ambiguity associated with the line path. The UML standard should supply a normative technique to resolve this ambiguity, The introduction of a “jog” - a small curve in one of the intersecting lines – has traditionally be acceptable.

    Proposed solution:

    In the diagram appendix, add a paragraph introducing the problem and recommending a standard graphical solution. A diagram may be useful to convey the intent.

    If a normative solution is not desired, the paragraph can recommend several selected approaches to resolve the disambiguities.

  • Reported: UML 2.5 — Wed, 24 Dec 2008 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

There is no way to specify the behavior of operations which are members of data types

  • Key: UMLR-152
  • Legacy Issue Number: 13165
  • Status: open  
  • Source: Anonymous
  • Summary:

    I would like to bring to your attention (as the contact person for the UML standard) a small bug we found with the UML specification: There is no way to specify the behavior of operations which are members of data types such as enumerations. Such operations can be modeled in UML, since each classifier can have operations, and this is useful to describe, e.g. Java enumeration operations. However, they cannot be assigned method behaviors, since nested behavior can only be added to classes.
    One solution to this would be allowing to nest classifiers in data types - i.e. to copy the association nestedClassifier: Classifier [*] to DataType (just as was done for case for ownedOperation : Operation [*]).

  • Reported: UML 2.5 — Thu, 18 Dec 2008 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML 2 - appearance of Association Ends as members of the related classes

  • Key: UMLR-161
  • Legacy Issue Number: 13656
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    Since the dot notation was introduced to represent ownership of association ends separately from navigability, it appears that the following is the case: a navigable association end that is owned by the association does not appear in the namespace of the class from which it is navigable. How, then, can it be said to be navigable? I believe that all navigable ends should appear in the namespace of the class from which they are navigable, regardless of who owns the ends.

  • Reported: UML 2.5 — Tue, 3 Mar 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML2.2. Contradications in 14.3.10

  • Key: UMLR-160
  • Legacy Issue Number: 13651
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    14.3.10: says “An ExecutionSpecification is a specification of the execution of a unit of behavior or action within the Lifeline. The duration of an ExecutionSpecification is represented by two ExecutionOccurrenceSpecifications, the start ExecutionOccurrenceSpecification and the finish ExecutionOccurrenceSpecification.” However slightly lower down it says “The trace semantics of Interactions merely see an Execution as the trace <start, finish>. There may be occurrences between these. Typically the start occurrence and the finish occurrence will represent OccurrenceSpecifications such as a receive OccurrenceSpecification (of a Message) and the send OccurrenceSpecification (of a reply Message).” These appear to be directly contradictory.

    Is it necessary for the start and finish occurrences of an ExecutionSpecification to be ExecutionOccurrenceSpecifications? Is it valid to have a MessageOccurrenceSpecification at the start and finish of an ExecutionSpecification? Is it valid to have both a MessageOccurrenceSpecification and an ExecutionOccurrenceSpecification representing the start/end of a ExecutionSpecification? Are Message reception and Execution commencement the same or different events?

    Also the multiplicity on the source (non-navigable) end of ExecutionOccurrenceSpecification.Execution is 1, which makes the model clearly invalid. I believe it should either be 2 or 0..2, depending on the answers to the questions above.

  • Reported: UML 2.5 — Mon, 2 Mar 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

we can create an invalid active state configuration

  • Key: UMLR-157
  • Legacy Issue Number: 13449
  • Status: open  
  • Source: International Business Machines ( Mr. Adam Neal)
  • Summary:

    The spec states: "An entry point pseudostate is an entry point of a state machine or composite state. In each region of the state machine or composite state it has a single transition to a vertex within the same region." This is slightly ambiguous as one could take it to mean that the region is the region who owns the target dirctly. This would allow one to create the case where we can create an invalid active state configuration. consider: S1's region1 owns S2 and S3 who both have sub verticies. An entry point on S1 should only be able to target one vertex with region1 (either a direct or deeply nested vertex), but not more then one. If the assumption by a user was made that both the verticies in S2 and S3 could be targeted (since they are owned by different regions) then the tooling would essentially be allowing concurrent entries into a single region. Where as, really we need to specify more along the lines of that the LCA region of the source and target may have at most a single transition. An entry point pseudostate is an entry point of a state machine or state. For each transition that targets a vertex in region R, there may not exist another transition targeting a vertex in region R nor any region contained within R. Also, given the alternate semantics of entering a state (that regions don't have to be entered and the state itself can remain active), entry points should not be required on composite states only. Connecting to an entry point with no outgoing transitions or to the state border itself should be considered semantically the same. One usecase for this is that users may define entry/exit code on the state itself to preform some basic behavior, but in redefined contexts want to enhance the behavior by continuing that transition to a sub vertex.

  • Reported: UML 2.2 — Fri, 6 Feb 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Concrete specialization of the Relationship meta-class are missing

  • Key: UMLR-164
  • Legacy Issue Number: 13841
  • Status: open  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    Concrete specialization of the Relationship meta-class are missing. Except few cases restricted to very specific usages (import/merge, association), and according to the current meta-model, all concrete instaciations of Relationship are Dependencies. This situation has an undesirable side-effect in UML models but also in some UML profiles like SysML and MARTE. Indeed, specialized or extended relationships like Deployment or Allocation generate unexpected dependencies between related elements. A solution might be to add a concrete (Directed)Relationship meta-class in the meta-model. The concept of "Allocation" is very generic and might provides that meta-class. It would be a convenient generalization for Deployment.

  • Reported: UML 2.2 — Fri, 27 Mar 2009 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML 2.2 InteractionOperand abstract syntax

  • Key: UMLR-163
  • Legacy Issue Number: 13664
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    Section 14.3.16 says “An InteractionOperand is contained in a CombinedFragment.” Yet the abstract syntax figure 14.7 shows that an InteractionOperand may be contained by a CombinedFragment, or may (via inheritance) be owned by an InteractionOperand. These are inconsistent and the specification should make clear which is correct.

  • Reported: UML 2.5 — Mon, 9 Mar 2009 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML2: Unclear how to indicate what events a classifier might send

  • Key: UMLR-155
  • Legacy Issue Number: 13395
  • Status: open  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    UML2 has Receptions which can be included in realized/provided Interfaces to indicate what Signal events a Classifier is able to receive. But it isn't clear how a Classifier would indicate in its interfaces what events it might send/generate, and therefore what events a collaborating Classifier connected to this Classifier in some way would need to be prepared to handle.

    UML2 Reception semantics should be updated to indicate Receptions can appear in either Realized/provided or Usage/required Interfaces. A Reception in a required interface would indicate a signal event the owning classifier might send through a SendSignalAction or BroadcastSignalAction. This would provide all the interface information needed on both sides of a connector to know what SignalEvents might be sent and/or received

  • Reported: UML 2.5 — Fri, 30 Jan 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML2.2 RTF: EnumerationLiteral is a DeploymentTarget

  • Key: UMLR-154
  • Legacy Issue Number: 13255
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    EnumerationLiteral is an InstanceSpecification; InstanceSpecification is a DeploymentTarget. This makes EnumerationLiteral a DeploymentTarget, which is clearly nonsense.

    I strongly question both of these inheritance relationships

  • Reported: UML 2.5 — Wed, 14 Jan 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section: 9.3.11 Port

  • Key: UMLR-162
  • Legacy Issue Number: 13657
  • Status: open  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    Specification: UML 2.2 Beta1 (2008/05/01)

    Section: 9.3.11 Port

    Summary:

    Consider the MARTE2 FTF proposal developed in the resolution to MARTE issue 11820 in the scope of the tactical resolutions being developed for clauses 8 and 9 of the UML superstructure specification for the UML 2.3 RTF.

    The MARTE resolution to issue 11820 attached is available in ballot1 of the MARTE2 FTF as “issue11820 resolved.doc” here:

    http://www.omgwiki.org/marte-ftf2/doku.php?id=marte_ftf2_ballot_1

  • Reported: UML 2.5 — Tue, 3 Mar 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section: 7.3.9 Comment should be NamedElement

  • Key: UMLR-156
  • Legacy Issue Number: 13425
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    I propose to define the Comment as a NamedElement instead of Element. The SysML and UPDM working groups identified that it is necessary that comment based model elements have a name, could be packaged and identified.

  • Reported: UML 2.2 — Tue, 3 Feb 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

MARTE/section 7.2.1/ "several labels for the same classifiers in the Metamodel" bug

  • Key: UMLR-151
  • Legacy Issue Number: 13088
  • Status: open  
  • Source: INRIA ( Pierre Boulet)
  • Summary:

    Using the profile, an element can have several stereotypes. However, in
    the metamodel, an element can not have several labels traducing these
    stereotypes. A traduction in the metamodel of this kind of element
    (stereotyped several times) can not be made.

  • Reported: UML 2.5 — Fri, 26 Sep 2008 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section: 16.3.5

  • Key: UMLR-122
  • Legacy Issue Number: 11307
  • Status: open  
  • Source: 4Soft GmbH ( Klaus Bergner)
  • Summary:

    The Description section states: "Note that the included use case is not optional, and is always required for the including use case to execute correctly." This is often understood as stating that the behavior of an included use case has to be executed during every execution of the behavior of the including use case. Example: The following informal use case fragment contains a conditional call of an included use case: Step x: If the user choses to print the reports, <<include>> the use case "Print reports". With the understanding given above, this use case fragment would be invalid (at least if the included use case is not included elsewhere in the including use case). In a similar vein, the Semantics section states: "All of the behavior of the included use case is executed at a single location in the included use case before execution of the including use case is resumed." Besides the obvious error (the sentence should say: "... is executed at a single location in the including use case ..."), this is sometimes understood as stating that the behavior of the included use case must be executed exactly once during the execution of the including use case. Another (equally wrong) interpretation would be that the included use case must be included exactly once in the use case specification (implying, for example, that there must not be two lines in the same textual use case specification containing an <<include>> directive for a certain use case). Both sections should be clarified, clearly stating that: - The behavior specification of the including use case may include an included use case multiply (although this is represented by a single include relationship in the use case diagram). Analogy: A routine that contains multiple calls to a subroutine in its source code. - The including use case is responsible for calling the included use case. It may choose to call it once, repeatedly, or not at all. Analogy: A routine with conditional execution paths or iterative behavior, performing subroutine calls conditionally or iteratively. Proposal for changing the sentence in the Description section: "Note that the included use case is not optional, and is always required for the including use case to be fully specified. The behavior specification of the including use case may include an included use case multiply (although this is represented by a single include relationship in the use case diagram)." Proposal for a change and an addition in the Semantics section: "All of the behavior of the included use case is executed in the including use case before execution of the including use case is resumed. Depending on behavior of the including use case, the included use case may be called once, multiple times or not at all." I would be very pleased to receive a first, quick reply by mail.

  • Reported: UML 2.1.1 — Mon, 27 Aug 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section: 7.3.3

  • Key: UMLR-121
  • Legacy Issue Number: 11287
  • Status: open  
  • Source: Petersen Enterprises ( Sören Petersen)
  • Summary:

    There is actually two closely related issues I would like to report. One is an (as I understand it) error related to figure 7.20 and the other is a humble request to enhance the documentation by more explicitly clarifying the semantics of association ends that are owned by an end class. Starting with the (possible) error. According to the specification (page 39) "An end property of an association that is owned by an end class or [...] is navigable from the opposite ends; [...]" Somewhat further down in the text there is a statement saying (page 43) "Aggregation type, navigability, and end ownership are orthogonal concepts [...]" Although this may be true in terms of notation, it is clear from the first citation (and common sense) that navigability and end ownership cannot be conceptually orthogonal. Moving on to figure 7.20, the first relation demonstrates this supposed orthogonality by showing a relation where the end connected to B is owned by A, but not navigable from A. I understand that this part might have been written with notation in mind; to demonstrate the orthogonality of the notational elements. It might, however, be considered bad practice to show notational examples that are inconsistent with the rest of the specification. The second "issue" is related to the concept of a property that is an association end owned by an end class. It took me quite some time and a lot of re-reading to understand that the "end class" was a of a different type than the type of the property. The only real hint about this was the last statement on a paragraph in on page 42 (in the notation section) stating that "This property is owned by the classifier at the other end." Since the whole concept of ownership seems a little vague, it might be a good idea to include a paragraph detailing this fact in the description of the semantics of associations. I hope this might be of some use.

  • Reported: UML 2.5 — Tue, 21 Aug 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Figure 7.48 and the accompanying discussion under 7.3.21

  • Key: UMLR-126
  • Legacy Issue Number: 11807
  • Status: open  
  • Source: Duke University ( John Madden)
  • Summary:

    Figure 7.48 and the accompanying discussion under 7.3.21 GeneralizationSet>Examples on pp 78-79 uses the example of a generalization set consisting of a single class to explain the proper use of the isCovering and isDisjoint attributes. I believe this example is infelicitous in the context of this exposition because generalization sets consisting of a single class present a special case, and this detracts from the exposition. In what way are they a special case? IF (a generalization set consists of a single class AND it is

    {incomplete}) THEN it can only be {disjoint}. This is because if the complement of an {incomplete}

    generalization set is non-empty, and consists of all instances that are NOT members of the solitary class in the generalization set. In other words, for a generalization set consisting of a single class, the combination

    {incomplete, overlapping}

    is self-contradictory. IF (a generalization set consists of a single class AND it is

    {complete}) THEN it can only be {overlapping}. This is because the complement of a {complete}

    generalization set is the null set, and the null set is a member of every set. In other words, the combination

    {complete, disjoint}

    is self-contradictory. I would recommend pointing out that generalization sets consisting of a single class represent a special case, and I would treat them separately (?footnote). For purposes of the exposition, I would modify Figure 7.48 to include at least two classes (perhaps Employee, Manager) instead of just Employee in the right-hand generalization set.

  • Reported: UML 2.1.1 — Sun, 9 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

simpleTime package problems

  • Key: UMLR-125
  • Legacy Issue Number: 11410
  • Status: open  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    We are experiencing problems with elements of simpleTime Package.
    TimeExpression, Duration, TimeEvent and Observation owners are not defined. The only possible owner becomes Package.
    If TimeConststraints or DurationConstraints are used in SequenceDiagram, these multiple small elements could be added just into nearest Package (second level owner of Interaction). In real world packages could contain hundreds of Classes with defined behaviors, so hundreds of TimeExpression, Duration, TimeEvent and Observation elements appears in the root of such package (together with thousands of events from MessageEnds).

  • Reported: UML 2.5 — Fri, 14 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section: 7.3.37 Package (from Kernel)

  • Key: UMLR-124
  • Legacy Issue Number: 11342
  • Status: open  
  • Source: Mid GmbH ( Joachim Back)
  • Summary:

    The type of association 'packageMerge' is shown as 'Package'. In contradiction to this is the describing text of this association and the Figure 7.14 on p. 34 showing that the association 'packageMerge' is from 'Package' to 'PackageMerge'. Correct in chapter '7.3.37 Package (from Kernel)' the type of association 'packageMerge' from 'Package' to 'PackageMerge'.

  • Reported: UML 2.1.1 — Wed, 12 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML2 Property collaborationRole should be removed

  • Key: UMLR-123
  • Legacy Issue Number: 11323
  • Status: open  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    The collaborationRole property of Collaboration does not appear to be needed and could be removed. A Collaboration's ownedAttributes subsets inherited derived union role, and therefore represent the roles in a Collaboration. Since Property is extended to be a ConnectableElement, collaborationRole is redundant with ownedAttributes. In addition, the description does not seem to make sense. A collaborationRole can't reference connectable elements (possibly contained in another classifier) because the roles of a Collaboration must be parts or ownedAttributes of that Collaboration. The roleBindings of a CollaborationUse bind the roles of its Collaboration type to parts of some other classifier.

    However, there could be another interpretation of collaborationRole. If Collaborations are used to represent patterns, then a Collaboration's ownedAttributes may represent the common part of the pattern while the collaborationRoles represent the variable part. Instantiating the pattern with a CollaborationUse may then mean that the Classifier owning the CollaborationUse would need to directly contain the common parts (copies of them from the collaboration), and require roleBindings to the variable parts. In this case, collaborationRole parts would require bindings (and therefore subclass role) while ownedAttributes don't (and wouldn't subclass role)?

    In any case, the purpose of property collaborationRole is unclear and should be amplified in the specification to distinguish it from ownedAttributes and how it should be used.

  • Reported: UML 2.5 — Thu, 30 Aug 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML2 Issue: notation for Literals does not allow for name

  • Key: UMLR-128
  • Legacy Issue Number: 11827
  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    Literals e.g. LiteralString are NamedElements but the notation does not allow for specifying the name.

  • Reported: UML 2.5 — Mon, 17 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section: 14.4

  • Key: UMLR-127
  • Legacy Issue Number: 11815
  • Status: open  
  • Source: Validas AG ( Reinhard Jeschull)
  • Summary:

    Our company uses UML 2.1 for model driven architecture. We are now at the point, where we need interaction overview diagrams (like the example on figure 14.28 on page 530). So, we searched the UML elements that are used in this diagram: ControlFlow, InteractionUse, InitialNode, ActivityFinalNode, ... Then, we tried to combine them via the metamodel to have a little class diagram which shows us the connections of the elements (for example ControlFlow has source and target to ActivityNode). But there is one problem: We can't find a way to add the InteractionUse in this diagram. It seems, that a ControlFlow isn't able to have an InteractionUse on one of its ends. Can you tell us, how the InteractionUse can be used correctly (so we can use it for XMI-export)? Thank you in advance. We look forward to hearing from you.

  • Reported: UML 2.5 — Thu, 13 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

should be able to show gates on communication diagrams

  • Key: UMLR-130
  • Legacy Issue Number: 12166
  • Status: open  
  • Source: Anonymous
  • Summary:

    In the 2.1.1 specification (070205):

    Although the superstructure specification does not mention it, I believe that we should be able to show gates on communication diagrams.
    Gates are not connectable elements so we cannot attach connectors to them. How then would we show message pathways (connectors) to the represented lifeline on the communication diagram? Gates don't "represent" connectable elements as lifelines do.

    I would like to request clarification on this point.

  • Reported: UML 2.5 — Tue, 8 Jan 2008 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

pull semantics are only supported on Action inputs, not outputs

  • Key: UMLR-129
  • Legacy Issue Number: 12162
  • Status: open  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    pull semantics are only supported on Action inputs, not outputs. There is currently no ActionOutput having a toAction: Action Property allowing action output pins to refer and write to parameters, variables or structural features. Either UML2 should include ActionOutputPin, or remove ActionInputPin and allow a Pin to have an optional action: Action [0..1].

  • Reported: UML 2.5 — Mon, 7 Jan 2008 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

new constraint ?

  • Key: UMLR-135
  • Legacy Issue Number: 12274
  • Status: open  
  • Source: Eclipse Foundation ( Mr. Kenneth Hussey)
  • Summary:

    Should there be a constraint ensuring that named elements with private visibility cannot be accessed outside their owning namespace? For example, the type of a property should not be a private member of a namespace outside of its namespace hierarchy…

  • Reported: UML 2.5 — Tue, 11 Mar 2008 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section 7.3.44

  • Key: UMLR-134
  • Legacy Issue Number: 12272
  • Status: open  
  • Source: OFFIS e.V. ( Christian Mrugalla)
  • Summary:

    The metaclasses 'Attribute' and 'AssociationEnd' (defined in UML 1.x) are merged in the metaclass 'Property' in UML 2.x. But the terms 'attribute' and 'association end' are still used in the standard, based one the two possible Property-containments (Property owned by a 'Class' respectively by an 'Association'). In addition, a semantic for the different values of the meta-property 'aggregation' is only defined for a 'Property' of style 'association end'. I propose to re-introduce the metaclasses 'Attribute' and 'AssociationEnd' as specializations of 'Property', making 'Property' an abstract class (the meta-property 'aggregation' should be then moved to AssociationEnd).

  • Reported: UML 2.1.2 — Wed, 12 Mar 2008 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML 2 has lost cability to represent operations by collaborations

  • Key: UMLR-132
  • Legacy Issue Number: 12203
  • Status: open  
  • Source: Missouri University of Science and Technology ( Thomas Weigert)
  • Summary:

    It appears that UML 2 has lost the ability to represent operations by collaborations. (There the collaboration related the parameters of the operation as roles.) Now a collaboration use can only be owned by a classifier. A behavior could still be explained by an operation, but not an operation. If this is desired, the references to operations owning collaboration uses need to be purged. Otherwise it has to be fixed that operations can own collaboration uses.

  • Reported: UML 2.1.2 — Thu, 31 Jan 2008 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML 2: Need an explicit listing of all semantic variation points

  • Key: UMLR-131
  • Legacy Issue Number: 12197
  • Status: open  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    A readily accessible list of all semantic variation points in the UML superstructure. It should probably be a separate appendix for easy reference and maintenance.

  • Reported: UML 2.5 — Thu, 24 Jan 2008 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section: 7.3.41

  • Key: UMLR-133
  • Legacy Issue Number: 12267
  • Status: open  
  • Source: OFFIS e.V. ( Christian Mrugalla)
  • Summary:

    The last sentence of the Semantics definition for Parameter is: "If the behavioral feature is an operation, then the type and multiplicity of this parameter is the same as the type and multiplicity of the operation itself.". The multiplicity of an operation is not defined in the standard: Operation does neither inherit from MultiplicityElement, nor has it an element called 'multiplicity'. Proposed resolution: Replace this sentence by: "If the behavioral feature is an operation, then the type of this parameter is the same as the type of the operation itself

  • Reported: UML 2.1.2 — Mon, 10 Mar 2008 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

No notation for associating Exceptions with Operations

  • Key: UMLR-76
  • Legacy Issue Number: 9225
  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    In UML2, exceptions are represented as Types associated with an Operation via the multivalued raisedException property. The types have names and possibly structure (e.g. holding details of an error) and may use inheritance. However there is no notation defined for actually modeling Types associated with Operations as raisedExceptions.

  • Reported: UML 2.5 — Thu, 8 Dec 2005 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page: 107

  • Key: UMLR-75
  • Legacy Issue Number: 9145
  • Status: open  
  • Source: University College London ( James Skene)
  • Summary:

    I'm attempting to implement a JMI repository for the UML2 superstructure. This is made more difficult by the use of package merge in the model. The following issues should be clarified in the definition of package merge: 1. Do classifiers in the resulting package extend classifiers in the merged package? If they do: The meta-model must contain all infrastructure packages and extension packages defined in the superstructure spec e.g. 'ProtocolStateMachines', 'PackagingComponents' etc., in order to facilitate reflective access to instances of types defined in these packages. However, these packages are not collected in one or more sensible enclosing namespaces (e.g. root 'infrastructure' and 'superstructure' packages), so the root namespace will be cluttered. Root packages for these elements should therefore be introduced in the infrastructure and superstructure specifications. If they do not: Some infrastructure packages will still be needed in the resulting meta-model, because the infrastructure specification uses import + generalisation rather than merge to establish the relationships between packages, e.g. in core::abstractions. For conformance level 0, instances of types in package UML would therefore not be instances of types in core::basic, because this package is merged into UML. However, they would be instances of types in other infrastructure packages, e.g. core::abstractions::elements::Element, because core::basic imports this type, rather than merging it. This seems illogical. Why should core::abstractions::elements have instances in this case, but not core::basic? This could be corrected by using merge in the infrastructure spec, hence avoiding dragging imports into the UML package. However, using merge in this way means redefining the semantics for each copy of the same type, which is why there is so much unnecessary duplication in the infrastructure and superstructure specs. In both interpretations of merge, infrastructure classes and packages penetrate the UML meta-model, leading to a lack of good namespace organisation. This has an impact on the ease with which reflection can be used in the repository. 2. On page 107 the specification states that the use of explicit merges and pre-applied merges in a meta-model is equivalent with regards to the semantics of the meta-model. This is false when reflection is considered, as the meta-model retreived by reflective methods will be different depending on the approach taken. This is significant: To retrieve all features of a classifier where merge has been used in the meta-model, you need not only to recurse the generalisation hierarchy, but also the package containment hierarchy to determine if any containing package is the recipient of a merge that could modify the features of the classifier. This is highly inconvenient. My recommendation to address these problems is that classifiers in a package that is the recipient of a merge should be defined to generalise matching types in the merged package. The package structure of the infrastructure and superstructure specifications should be revised to reflect the fact that most packages and types defined in the specification will therefore be retained in any UML2 specification. Alternatively, use merge rather than import in the infrastructure specification, with the prescription that meta-models accessed by reflection must have the merges rolled out. Also therefore provide explicit documentation of the rolled out meta-models for the various conformance levels for the superstructure.

  • Reported: UML 2.0 — Thu, 10 Nov 2005 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section: 7.3.9

  • Key: UMLR-79
  • Legacy Issue Number: 9369
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    I propose an optional enhancement of the comment symbol: It is possible to draw a small circle at the end of the anchor line. That way it is easier to read a diagram if the anchor line crosses other dependency lines. The small circle is already used in several diagrams. It is part of the famous Visio stencil of Pavel Hruby.

  • Reported: UML 2.1 — Fri, 27 Jun 2014 11:17 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

consistent ordering of Association::memberEnd and ownedEnd

  • Key: UMLR-78
  • Legacy Issue Number: 9339
  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    Given that these are both

    {ordered}

    , indicating that ordering is important, then it seems only sensible that the ordering should be consistent, i.e. if Property p appears before Property q in memberEnd then that should also be the case for ownedEnd.
    There should therefore be a constraint added to this effect.

    There should probably also be a review of other cases where an ordered Property subsets another ordered property.
    Or should there be a more general constraint defined at the meta-level?

  • Reported: UML 2.5 — Tue, 31 Jan 2006 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

No ReadParameterAction or WriteParameterAction

  • Key: UMLR-77
  • Legacy Issue Number: 9247
  • Status: open  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    One difference between UML activity and BPEL process is that all
    data flows in UML must be explicit through connections between
    activity parameter nodes, pins, central buffer nodes, and/or data
    store nodes. UML activities can also have structural features and
    variables which allow data to be passed between actions without
    object flows, corresponding more like BPEL variable references.

    However, input and output parameters have no such indirect access.
    All actions that need information from parameters have to be
    connected through object flows. This is inconsistent and can lead to
    complex activity models because of the need for a large number of
    ForkNodes and ObjectFlows in order to access Activity parameters.

    UML2 should support actions to read and write parameters similar to
    reading and writing variables. The ActinInputPins can be used to
    simplify parameters in activities.

  • Reported: UML 2.5 — Wed, 18 Jan 2006 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Need more flexible notation for activity partitions

  • Key: UMLR-74
  • Legacy Issue Number: 9124
  • Status: open  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    Activity diagrams currently support two notation styles for denoting membership in a partition: horizontal or vertical, and possibly nested "swimlanes" and a parenthesized list of partition names displayed above an activity node. These notation styles are adequate in many cases, but can result in diagrams that are either difficult to layout or don't sufficiently display relationships between nodes that are in the same partition. In addition, control nodes often shouldn't belong to any partition at all, but may need to be displayed in a partition with adjoining nodes for diagram layout purposes. In this case, apparent inclusion in the partition on the diagram should not necessarily imply membership in the partition.

    One way to address these issues would be to include additional notation styles for partitions. For example, a partitions could be displayed as in concentric, overlapping circles, ovals, or rounded rectangles with activity nodes in the partitions displayed inside the partition shape. The same partition could be displayed many times on the same diagram allowing separation of members in the partition for diagram layout purposes.

    Control nodes often connect activity nodes across partitions and can have a strong influence on diagram layout. Having control nodes treated like other activity nodes in partitions can result in overly restrictive layout constraints, or accidental modification of the activity model for diagram layout purposes. For control nodes, perhaps the default should be that they are not placed in partitions unless explicitly stated by some tool action, and they could have a more restricted notation, such as requiring the parenthesized list only. This would allow control nodes to be freely interspersed between elements in a partition without necessarily belonging to that partition and keep diagram layout concerns from accidentally modifying the underlying activity model.

  • Reported: UML 2.5 — Fri, 28 Oct 2005 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML2 Super / 14.3.13 Interaction

  • Key: UMLR-69
  • Legacy Issue Number: 8975
  • Status: open  
  • Source: MID GmbH ( Mr. Detlef Peters)
  • Summary:

    Chapter 14.3.13 states on p. 526 that "Interactions are units of behavior of an enclosing Classifier. Interactions focus on the passing of information with
    Messages between the ConnectableElements of the Classifier." From chapter 9.3.13, it is obvious that only StructuredClassifiers can have such ConnectableElements. Additionally, chapter 13.3.2 states that the context of a Behavior is a BehavioredClassifier. When looking at the Classifier Hierarchy in Appendix F of the Spec, you will find a single Element which is a BehavioredClassifier, but not a StructuredClassifier: the UseCase.
    This is where the problems start.
    A UseCase is not allowed to have properties at all, but may be the owner of an Interaction. Consequently, with the current version of the Spec, an Interaction owned by a UseCase may never have any Lifeline at all!

    Proposed Resolution:
    Redefine the Association Behavior::context: BehavioredClassifier[0..1] to Interaction::context: StructuredClassifier, replace all occurrences of 'BehavioredClassifier' in the description by 'StructuredClassifier'
    It should still be possible that a UseCase is the owner of the Interation, but the determination of the Interaction's context would be much clearer.

  • Reported: UML 2.5 — Thu, 25 Aug 2005 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section: Classes

  • Key: UMLR-70
  • Legacy Issue Number: 9008
  • Status: open  
  • Source: Thematix Partners LLC ( Mrs. Elisa F. Kendall)
  • Summary:

    In Classes, Association, Semantics says: "Subsetting represents the familiar set-theoretic concept. It is applicable to the collections represented by association ends, not the association itself." and "Specialization is, in contrast to subsetting, a relationship in the domain of intensional semantics, which is to say it characterized the criteria whereby membership in the collection is defined, not by the membership. One classifier may specialize another by adding or redefining features; a set cannot specialize another set. A naive but popular and useful view has it that as the classifier becomes more specialized, the extent of the collection(s) of classified objects narrows. In the case of associations, subsetting ends, according to this view, correlates positively with specializing the association. This view falls down because it ignores the case of classifiers which, for whatever reason, denote the empty set. Adding new criteria for membership does not narrow the extent if the classifier already has a null denotation." ISSUE: It is the semantics of Generalization in UML is that all the instances of the subtype are instances of the supertype, so subtyping in UML implies subsetting. It is not necessarily proper subsetting, however, as the example above shows. Subsetting in UML can be achieved by subtyping (adding attributes, etc), but can only be done by adding constraints to the subtype. Also, for association classes, the user should be able to specialize an association class with another association class with the same semantics as subsetting ends.

  • Reported: UML 2.0 — Sun, 25 Sep 2005 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Syntax of Transition

  • Key: UMLR-67
  • Legacy Issue Number: 8898
  • Status: open  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    Syntax of Transition is described as:
    " <transition> ::= <trigger> [‘,’ <trigger>]* [‘[‘ <guard-constraint>’]’] [‘/’ <activity-expression>]

    The behavior expression may be an action sequence comprising a number of distinct actions including actions that explicitly

    generate events, such as sending signals or invoking operations."

    Information from this expression (operation call for example) can't be mapped and saved into model.

  • Reported: UML 2.5 — Mon, 20 Jun 2005 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

OutputPin

  • Key: UMLR-66
  • Legacy Issue Number: 8897
  • Status: open  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    OutputPin should hold output value, but there is no way to store it. Should be introduced similar metaclass like ValuePin for InputPin

  • Reported: UML 2.5 — Mon, 20 Jun 2005 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page: 492-493

  • Key: UMLR-73
  • Legacy Issue Number: 9111
  • Status: open  
  • Source: Universita di Torino ( Simona)
  • Summary:

    Hello, it is not clear to me whether it is still possible in UML2.0 to specify in interaction diagram (either sequence or communication) broadcast actions and lifeline representing multi-object. Figures Fig.14.22 and 14.23 (Superstructure 05-07-04), actually show the possibility of representing instances of the same type (class B) each one represented by a different lifeline: the selectors in that case are used to identify one specific instance and not a set of instances. Regards, Simona Bernardi

  • Reported: UML 2.5 — Mon, 24 Oct 2005 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section: Classes

  • Key: UMLR-72
  • Legacy Issue Number: 9015
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Classes should be able to support interfaces without being a BehavioredClassier (see figure 16). This introduces an unnecessary dependency of Classes on CommonBehavior

  • Reported: UML 2.0 — Sun, 25 Sep 2005 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section: Activities

  • Key: UMLR-71
  • Legacy Issue Number: 9013
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    What is the effect of unique association ends the actions for creating and deleting links? For example, what if one end is unique and the other not?

  • Reported: UML 2.0 — Sun, 25 Sep 2005 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Properties on Association for end objects

  • Key: UMLR-40
  • Legacy Issue Number: 8077
  • Status: open  
  • Source: Thematix Partners LLC ( Mr. Roger Burkhart)
  • Summary:

    The memberEnd/ownedEnd/NavigableOwnedEnd properties of Association represent the navigations from one end object to other end objects along the association. There are no properties available for navigating from an instance of an association (link) to the end objects. This has a number of negative effects: - The model cannot represent structured associations properly, because association classes that are also structured classifiers cannot have connectors to end objects, because the end objects cannot be reached with StructuredClassifier.role (see constraint 3 on Connector). - An InstanceSpecification for link can use memberEnd properties of association as properties of the link, even though these properties are ownedAttribute of the end classes, rather than the association. This is due to the loose definition of Classifier.allFeatures. - A special action is needed to retrieve (the end objects of links (ReadLinkObjectEndAction), rather than (using the action for attribute values ReadStructuralFeatureAction. The metamodel should have an association for properties that have the end objects of link objects as values.

  • Reported: UML 2.0 — Wed, 5 Jan 2005 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Notation for classifierBehavior

  • Key: UMLR-39
  • Legacy Issue Number: 8034
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Need a notation for instances of the classifierBehavior metaassociation (Figure 311).

  • Reported: UML 2.0 — Thu, 30 Dec 2004 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Contextualized attribute values Figures 121

  • Key: UMLR-38
  • Legacy Issue Number: 8026
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Contextualized attribute values Figures 121 is an unworkable solution to defining contextualized attribute values. It requires restating all the parts and connectors in the composite class, otherwise the constructor would be incomplete. The class-based solution requires separate properties for each contextualized value with connectors to them from the contextualized property. The metamodel should be extended to include contextualized datatype properties, or at least a presentation option for the current cumbersome model (see Figure 12 and discussion in http://www.jot.fm/issues/issue_2004_11/column5

  • Reported: UML 2.0 — Thu, 30 Dec 2004 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

ReadStructuralFeatureAction

  • Key: UMLR-42
  • Legacy Issue Number: 8335
  • Status: open  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Chokri Mraidha)
  • Summary:

    This issue concerns the ReadStructuralFeatureAction. This action reads the values of a structural feature, in order if the structural feature is ordered. According to the sepcification, the multiplicity of the structural feature must be compatible with the multiplicity of the output pin, so the output pin will contain all the values of the structural feature. There is no way to read the value of a single element from a multi-valued structural feature without reading all its values. Adding an input pin (readAt) to ReadStructuralFeatureAction would allow this. This input pin would represent the index of the value we want to read in the structural feature. This issue stands for ReadVariableAction as well.

  • Reported: UML 2.0 — Thu, 24 Feb 2005 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section: Classes, Behavior

  • Key: UMLR-34
  • Legacy Issue Number: 8012
  • Status: open  
  • Source: gmail.com ( Guus Ramackers)
  • Summary:

    There doe snot appear to be a way to model parameters to operations that are multi-dimensional arrays. In general, such arrays can be modeled based on qualifiers. However, this assumes that there is an association between two Classifiers. This doesn't apply to parameters. Note that Parameters are MultiplicityElements, but that only allows the modeling of single dimensions.

  • Reported: UML 2.0 — Wed, 29 Dec 2004 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

End objects of a link In the semantics of AssociationClass

  • Key: UMLR-37
  • Legacy Issue Number: 8024
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    End objects of a link In the semantics of AssociationClass, it says: It should be noted that in an instance of an association class, there is only one instance of the associated classifiers at each end , i.e. from the instance point of view, the multiplicity of the associations ends are "1". Two comments: - This is applicable to Association generally. - The portion after "i.e" is misleding. Instances have no multiplicity.

  • Reported: UML 2.0 — Thu, 30 Dec 2004 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Action for retrieving activity instance

  • Key: UMLR-36
  • Legacy Issue Number: 8016
  • Status: open  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    Action for retrieving activity instance: There should be an action for getting the instance of the activity class currently executing, for reflective applications.

  • Reported: UML 2.0 — Thu, 30 Dec 2004 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Activities section

  • Key: UMLR-44
  • Legacy Issue Number: 8473
  • Status: open  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    Add presentation option for multiple object flows between two actions, shown as one line.

  • Reported: UML 2.0 — Sun, 6 Mar 2005 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section: 16.3.1

  • Key: UMLR-43
  • Legacy Issue Number: 8464
  • Status: open  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Delete sub-sections Attributes and Rationale as there are none. I question, in light of Constraint [1] and the second paragraph in sub-section Semantics, that there are no associations for an actor. Both constraint [1] and Semantics clearly indicate that there are associations and the Semantics paragraph even indicates multiplicity possibilities greater than one. Figure 401 shows no navigability and association between UseCase and Actor although both Constraint [1] and Semantics indicate that there should be some. Typo - There are eleven "(" but only ten ")" in constraint [1]. Personal preference - Restate Changes from previous UML to "The additon of the constraint that requires that all actors must have names has been added."

  • Reported: UML 2.0 — Fri, 4 Mar 2005 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Add constraints on ConditionalNode

  • Key: UMLR-48
  • Legacy Issue Number: 8495
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Add constraints on ConditionalNode to ensure the test and body are owned by the conditional node (or have them owned by the clause with body outputs being referred to by a single clause. This would prevent sharing bodies across clauses It is unclear if this is much of a benefit, since changing the body of one clause will change another, which may not be the intention.).

  • Reported: UML 2.0 — Sun, 6 Mar 2005 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

ExpansionRegion (behavior in the shorthand notation)

  • Key: UMLR-47
  • Legacy Issue Number: 8489
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    In ExpansionRegion, clarify that the behavior in the shorthand notation must have exactly one return parameter

  • Reported: UML 2.0 — Sun, 6 Mar 2005 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section: Activities : Why is exception type needed?

  • Key: UMLR-46
  • Legacy Issue Number: 8480
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Add constraint in ExceptionHandler that exception type must be compatible with the exception handler input. Why is exception type needed?

  • Reported: UML 2.0 — Sun, 6 Mar 2005 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section: Activities - clarification

  • Key: UMLR-45
  • Legacy Issue Number: 8479
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Clarify the constraints on ExceptionHandler, that results must be output pins introduced on structured nodes in CompleteStructuredActivities.

  • Reported: UML 2.0 — Sun, 6 Mar 2005 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML: Cross model dependencies

  • Key: UMLR-212
  • Legacy Issue Number: 14952
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    There seems to be some confusion in the UML spec and by users about the applicability of run-time UML visibility/navigability rules to model time, some of the typical assumptions do not work with distributed models. This needs to be cleared up. For example, can a tool transverse a dependency that crosses models. Can a tool transverse the reverse direction?

    These need to be solved in a way that is internally consistent and consistent with distributed/federated models

  • Reported: UML 2.5 — Mon, 11 Jan 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML: Large Scale Model Support:Federated/Distibuted Models

  • Key: UMLR-211
  • Legacy Issue Number: 14951
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Large Scale, Distributed, and Federated System Support
    Many projects of interest have become so large that for practical reasons more than one “model” may be required. Such models may also be at different locations and supported in different tools. We need features in UML that will support very large distributed heterogeneous models in a standard way.

    While the complete solution to this strong need is not yet known, such features will probably need to include:

    1. higher level concepts than the standard package;

    2. a uniform URL/URI convention for models and model elements;

    3. standard APIs so that the tools can query each other;

    4. a strong ability to support IEEE 1471 views;

    5. ability to synchronize different models;

    6. ability to propose changes across models.

    While some of these solutions components may be considered tool issues, users with large models need a consistent standard solution. This may solved by a separate RFP but any changes to UML for other reasons must be checked to see if it interferes with large model scenarios.

    As a related problem, there seems to be some confusion in the UML spec and by users about the applicability of run-time UML visibility/navigability rules to model time, some of the typical assumptions do not work with distributed models. This needs to be cleared up.

  • Reported: UML 2.5 — Mon, 11 Jan 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML: Add abilities to specifiy intent of Assert, Negate, Consider, Ignore fragments

  • Key: UMLR-214
  • Legacy Issue Number: 14954
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    In sequence diagrams the use of Assert, Negate, Consider, and Ignore fragments often leaves the reader confused about their intent.

    For example, an Assert fragment is intended to mean that this fragment is the only sequence of events to be considered. This could be interpreted as the only sequence

    1) that can occur; so the reader/developer does not need to consider others as they are impossible

    2) that is interesting; so that the reader/developer can ignore the others as being not interesting

    3) that is allowed; so if something else occurs it is an error

    4) that is allowed; so that the reader/developer needs to prevent the others from occurring.

    Similar issues arise with the other fragments

    An Negate Fragment, could be interpreted as

    1) this fragment can never occur, so don’t worry about it

    2) If this fragment occurs this is an error

    3) You need to prevent this fragment from occurring

    These can be solved by adding a parameter to these fragments

    e.g., Fact (this is the way it is); Enforce (this is the way we have to make it); Error (violations are errors); Ignore (don’t worry about violations)

  • Reported: UML 2.5 — Mon, 11 Jan 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML: Improve Sequence Diagram Semantics (3-issues)

  • Key: UMLR-213
  • Legacy Issue Number: 14953
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    UML is missing useful sequence diagram support for.

    1) Information Flows

    2) Continuous or Repeating messages (for example, on the 200th heart beat message)

    3) Improved timing semantics (requirements for min/max timing)

    Without these features, it will not be possible to represent common situations on sequence diagrams or specify realtime behavior. It may also prevent mapping to state diagrams.

  • Reported: UML 2.5 — Mon, 11 Jan 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML: Better Profile Capabilitiy

  • Key: UMLR-216
  • Legacy Issue Number: 14956
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Better Profile Capability
    The profile mechanism needs to better support the general refactoring and reuse of profile elements to allow for compatible language evolution. This can include renaming on import, pulling in partial profiles, suppressing features, etc.

    Profiles should support a more sophisticated ability to add contextual and usage based information, such as consistency rules, formatting rules, model/diagram filters, GUI and presentation options, transformation, documentation, and code generation.

    These desired profile features are similar in nature to features required by viewpoints – the ability to control much of the model presentation based on audience or circumstances.

  • Reported: UML 2.5 — Mon, 11 Jan 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML:Access to standardized ontologies within models

  • Key: UMLR-215
  • Legacy Issue Number: 14955
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    In many situations it is necessary to refer to externally defined ontologies, e.g., for types (esp enumerated types) icons, parts, etc. We need a way to select something from a rich list defined elsewhere.

  • Reported: UML 2.5 — Mon, 11 Jan 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

NamedElements whose owners do not subset Namespace

  • Key: UMLR-220
  • Legacy Issue Number: 14978
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    Action is a kind of NamedElement, but the owners of Actions do not subset the property “namespace”.

    The same is true of ActivityNode, but this was discussed in 8668 and resolved as correct.

    The same is true of CollaborationUse: a CollaborationUse is not in the ownedMembers of its Classifier.

    The same is true of MessageEnd and MessageOccurrenceSpecification and Gate.

    The same is not true of InteractionFragment, i.e. InteractionFragments appear in the namespace of their enclosing interaction.

    Are all of these correct?

  • Reported: UML 2.5 — Thu, 14 Jan 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Sequence diagram and Communication diagrams should support instances as lifelines

  • Key: UMLR-222
  • Legacy Issue Number: 15123
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Sequence diagram and Communication diagrams should support instances as lifelines

  • Reported: UML 2.5 — Tue, 9 Mar 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Parameter

  • Key: UMLR-221
  • Legacy Issue Number: 15050
  • Status: open  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Sebastien Gerard)
  • Summary:

    Who could explain me the following constraint on Parameter within section 9.3.10:

    Constraints [1] A parameter may only be associated with a connector end within the context of a collaboration. self.end->notEmpty() implies self.collaboration->notEmpty()

    I wanted to draw delegation connectors between a port and as for example the Parameters of a behaviour such as an activity. Am I allow to do that?

  • Reported: UML 2.5 — Tue, 16 Feb 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML: Higher-level reusable frameworks

  • Key: UMLR-218
  • Legacy Issue Number: 14958
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Templates, Patterns, and Frameworks
    The current ability to capture software templates need to be expanded or augmented in ways that can be used to depict and utilize system design and architectural patterns, and higher-level reusable frameworks

  • Reported: UML 2.5 — Mon, 11 Jan 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML: Timing semantics for activity diagram

  • Key: UMLR-217
  • Legacy Issue Number: 14957
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Timing semantics for activity diagram
    Enable timing diagrams and associated timing semantics to support activity diagrams.

  • Reported: UML 2.5 — Mon, 11 Jan 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Package merge is missing a rule

  • Key: UMLR-178
  • Legacy Issue Number: 14081
  • Status: open  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    Package merge is missing a rule for when two elements have conflicting values for isLeaf, cf. the rule for abstract elements

  • Reported: UML 2.2 — Thu, 16 Jul 2009 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML 2: notation and concepts for unbound and un-owned template parameters are not clear

  • Key: UMLR-177
  • Legacy Issue Number: 14078
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    When creating classifier templates, it is possible to have template parameters that are not owned by the classifier, in at least the following situations:

    1. When the classifier is a partial binding, i.e. it is bound to a template classifier but not all the parameters are bound

    2. The classifier extends a template classifier and has a redefined signature.

    In these cases, what is the notation for the non-owned parameters? Let’s say, for example, that we define C1[A: Class, B: Class]. Then we create C2<A->G>. Does the notation for C2 show a parameter box with B, indicating that B remains to be bound?

    Indeed, from a metamodel point of view, is it correct for C2 to have a signature that refers to B as one of its non-owned parameters, or is C2’s signature “derived” according to “In a canonical model a bound element does not explicitly contain the model elements implied by expanding the templates it binds to, since those expansions are regarded as derived.”

    Similarly, given C1[A: Class, B: Class], let C3 inherit from C1. Does the notation for C3 show a parameter box with A and B?

    Let C3 inherit from C1 and also be bound to it. Is it possible for the formal parameter A defined in C1 to be substituted by the formal parameter A defined (by inheritance) in C3, according to the statement in 17.5.3: “In case of complete binding, the bound element may have its own formal template parameters, and these template parameters can be provided as actual parameters of the binding”?

  • Reported: UML 2.5 — Wed, 15 Jul 2009 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

semantics of associating a use case with another use case, or indeed anything other than an actor, are unclear

  • Key: UMLR-176
  • Legacy Issue Number: 14045
  • Status: open  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    The semantics of associating a use case with another use case, or indeed anything other than an actor, are unclear. There is a rule specifying that use cases may be only be associated with other use cases with different subjects because they describe a complete usage of the subject. But that doesn't explain what it means to have any association. The only hint is in the notation section that gives some examples as "(e.g., to denote input/output, events, and behaviors)." However these details ought to be part of semantics and expanded on.

  • Reported: UML 2.2 — Wed, 1 Jul 2009 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

authorize a reference to an operation in a realized interface.

  • Key: UMLR-180
  • Legacy Issue Number: 14090
  • Status: open  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Ansgar Radermacher)
  • Summary:

    A common task is to implement the operations of an interface I in a class A. The implementation of an operation has a specification reference to the realized operation. In the current UML specification, the operation must be copied into the class before it can be realized, since only owned behavioral features can be referenced: "(section 13.3.2) ... The behavioral feature must be owned by the classifier that owns the behavior or be inherited by it.". I.e. the standard only allows to reference inherited operations, but not realized operations. This is not very practical, since it implies not only copying the operation but also assuring that it remains synchronized with the operation that is defined in the interface (of course, the modeling tool could do the synchronization, but it would still imply storing redundant information within the model). It would be good to authorize a reference to an operation in a realized interface.

  • Reported: UML 2.2 — Wed, 22 Jul 2009 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Subsets vs. Redefines

  • Key: UMLR-179
  • Legacy Issue Number: 14084
  • Status: open  
  • Source: NASA ( Dr. Maged Elaasar)
  • Summary:

    Although I have read the sections in Infrastructure that talks about the meaning of association redefinition and subsetting, and I understand it for the most part, I find myself not sure sometimes which one to use when modeling associations that need to be specialized further down an inheritance hierarchy. This happened to me as I was modeling some parts of the new Diagram Definition metammodel.

    For some cases, it is obvious what to do like when you have an association with * multipclity that you expect to be populated differently down the hierarchy so you make it "derived union" in anticipation of subclasses subsetting it. However, for an association with 1..1 or 0..1 multipclity that you expect it to be specialized, I am not sure whether to declare it as derived union or as a regular association (in the latter case, I expect it to be redeined).

    These features have very powerful yet not much understood semantics by general practitioners, evident by them mostly being used by metamodelers like ourselves, but not by average users of UML (who understand the difference between is-a and has-a relationships for example and use them extensively). It is unfortunate, since these association semantics do have a good mapping to some popular programming languages (like Java as evident by the Eclipse UML2 implementation) and can help modelers intending to generate code from models had they know how to use them properly.

    Maybe we need some section in the spec giving a practitioner some guidance in when and how to use these concepts based on different situations that go beyond explaining what they are for?

  • Reported: UML 2.5 — Fri, 8 May 2009 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Visibility and Import relationships

  • Key: UMLR-174
  • Legacy Issue Number: 14022
  • Status: open  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    Am I wrong or is there actually something inconsistent in the specification around the concept of "visibility"?

    As I underlined for the ballot 6 vote, the current specification explicitly states that Element/PackageImport has no impact on element visibility. Cf. my comments posted on the 27th of April about issue #11567:

    "According to the current definition of the visibility concept, my understanding is that it's neither necessary nor possible to use Import relationships to make an element "visible" (i.e. available). The specification explicitely states that :

    • an ImportedElement can only have a public visibility or no visiblity at all (cf. ElementImport, constraint #2)
    • (p111) : "The public contents of a package are always accessible outside the package through the use of qualified names. "
    • (p66): "The visibility of the ElementImport may be either the same or more restricted than that of the imported element. "

    Then, the only concrete effect of an Import relationship is to give the ability to refere to an element using its simple name rather than its qualified one."

    Nevertheless, and even if there is no impact on the resolution, I found this sentence in the discussion of issue #12833 (ballot 8) : ". The names of stereotypes or classes in a parent profile are not visible to a profile nested in that parent profile without a PackageImport"

  • Reported: UML 2.5 — Tue, 23 Jun 2009 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML2: Need clarification on circle plus notation for containment

  • Key: UMLR-173
  • Legacy Issue Number: 13936
  • Status: open  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    Section 7.3.37, Notation indicates that "The members of the package may be shown within the large rectangle. Members may also be shown by branching lines to member elements, drawn outside the package. A plus sign within a circle is drawn at the end attached to the namespace (package). ". It is unclear if this is intended to apply to any Element owner/ownedElement relationship (such as nested classes, owned behaviors, etc.) or only to packages. Some vendors do support circle-plus notation to depict metamodel containment, others don't. If it applies only to packages, then what is the notation for these other membership associations?

  • Reported: UML 2.5 — Mon, 18 May 2009 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section: 18.3.8

  • Key: UMLR-169
  • Legacy Issue Number: 13862
  • Status: open  
  • Source: University of Kassel ( Michael Zapf)
  • Summary:

    The reader may be led to believe that the application of the stereotype <<clock>> changed the model by adding an operation "Click" to the class StopWatch. It should be clarified that the operation must be owned by the StopWatch even without applying the stereotype. The stereotype instance may, of course, be associated to this operation, and serves as a pointer, for example, to be used in model transformations. Figure 18.18 does not provide this information; it shows the result of the application and not the state before.

  • Reported: UML 2.2 — Thu, 9 Apr 2009 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

The example in Figure 18.11 is badly designed in multiple ways and is strongly misleading

  • Key: UMLR-168
  • Legacy Issue Number: 13859
  • Status: open  
  • Source: University of Kassel ( Michael Zapf)
  • Summary:

    The example in Figure 18.11 is badly designed in multiple ways and is strongly misleading. Although it serves to explain the package import, it should not suggest an improper application of stereotypes. The stereotype defined here (Device) holds attributes which are not typical for devices as such. For instance, a device is not expected to have a color or volume. It may make sense to apply this stereotype to a class of TVs, but not to a class of dishwashers, for example. A better disctinction would be electrical versus non-electrical devices, or handheld versus non-handheld. Second, the attributes as shown here refer to properties which are significant for instances, not for classes. The example basically shows that we can create a TV class, declaring this to be a device. The Factory package shows an instantiation, setting the volume to some value, but omitting the remaining attributes - which must be set as well. The volume parameter for a class of TVs is questionable - what should it mean? This may lead the reader to believe that the volume parameter is meaningful for instances of the model element, although it is associated to the stereotype instance which is associated to the model element. Basically, the element in the Factory package denotes the class of all TVs whose volume is set to 10. This still does not imply a meaning for the instances.

  • Reported: UML 2.2 — Thu, 9 Apr 2009 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Template Binding Question

  • Key: UMLR-171
  • Legacy Issue Number: 13926
  • Status: open  
  • Source: NASA ( Dr. Maged Elaasar)
  • Summary:

    In the spec, there is a constraint on TemplateParameterSubstitution, as follows:

    actual->forAll(a | a.isCompatibleWith(formal.parameteredElement))

    "actual" and "formal" are TemplatableElement. So looking up "isCompatibleWith" definition in the spec, I find this:

    The query isCompatibleWith() determines if this parameterable element is compatible with the specified parameterable element. By default parameterable element P is compatible with parameterable element Q if the kind of P is the same or a subtype as the kind of Q. Subclasses should override this operation to specify different compatibility constraints.

    ParameterableElement::isCompatibleWith(p : ParameterableElement) : Boolean;
    isCompatibleWith = p->oclIsKindOf(self.oclType)

    This means if I defined a class template with a template parameter linked to Interface A (a ParametrableElement), and I used this interface to type a property inside the class template, that I cannot substite the interface with Class B that realizes Interface A, because Class B and Interface A do not have compatible kinds (metaclasses).

    Is this what the constraint is saying? Is this Valid?

  • Reported: UML 2.5 — Wed, 29 Apr 2009 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

there are numerous places where associations between UML elements have only one, navigable role

  • Key: UMLR-170
  • Legacy Issue Number: 13908
  • Status: open  
  • Source: PTC ( Phillip Astle)
  • Summary:

    In the specification there are numerous places where associations between UML elements have only one, navigable role. This seriously restricts the ability of derived properties that are added as part of a profile. Though most tool vendors implement bi-directional relationships for everything anyway, this doesn't help at all when you're trying to define the implementation of the derived property (i.e. tag), as part of a property. It is my belief that all associations in UML should be bi-directional to support a method of non-ambiguous definition. A couple of obvious examples are: 1. Navigating from a realizing relationship to a realized InformationFlow. 2. Navigating from an ActivityEdge to an Action via a Pin.

  • Reported: UML 2.1.2 — Wed, 29 Apr 2009 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Subsets vs. Redefines

  • Key: UMLR-172
  • Legacy Issue Number: 13927
  • Status: open  
  • Source: NASA ( Dr. Maged Elaasar)
  • Summary:

    Although I have read the sections in Infrastructure that talks about the meaning of association redefinition and subsetting, and I understand it for the most part, I find myself not sure sometimes which one to use when modeling associations that need to be specialized further down an inheritance hierarchy. This happened to me as I was modeling some parts of the new Diagram Definition metammodel.

    For some cases, it is obvious what to do like when you have an association with * multipclity that you expect to be populated differently down the hierarchy so you make it "derived union" in anticipation of subclasses subsetting it. However, for an association with 1..1 or 0..1 multipclity that you expect it to be specialized, I am not sure whether to declare it as derived union or as a regular association (in the latter case, I expect it to be redeined).

    These features have very powerful yet not much understood semantics by general practitioners, evident by them mostly being used by metamodelers like ourselves, but not by average users of UML (who understand the difference between is-a and has-a relationships for example and use them extensively). It is unfortunate, since these association semantics do have a good mapping to some popular programming languages (like Java as evident by the Eclipse UML2 implementation) and can help modelers intending to generate code from models had they know how to use them properly.

    Maybe we need some section in the spec giving a practitioner some guidance in when and how to use these concepts based on different situations that go beyond explaining what they are for?

  • Reported: UML 2.5 — Fri, 8 May 2009 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Figure 18.9 shows a presentation option for an Interface which has not been introduced before (circle within box)

  • Key: UMLR-167
  • Legacy Issue Number: 13858
  • Status: open  
  • Source: University of Kassel ( Michael Zapf)
  • Summary:

    Figure 18.9 shows a presentation option for an Interface which has not been introduced before (circle within box)

  • Reported: UML 2.2 — Thu, 9 Apr 2009 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section: 18.3.6

  • Key: UMLR-166
  • Legacy Issue Number: 13856
  • Status: open  
  • Source: University of Kassel ( Michael Zapf)
  • Summary:

    Figure 18.8 includes a Metamodel formalism which has never been introduced, in particular with respect to customized metamodels. The presentation as a package with a triangle is new at this point. Although the concept of a metamodel is verbally explained in the Infrastructure, there is no abstract syntax. It becomes implicitly clear that a metamodel is a package. I suggest to insert a definition of a Metamodel as a subclass of Package in the Infrastructure document or in the Profiles chapter of this document. This also allows to explain what is meant by "applying a metamodel". Also, the term "a UML2 metamodel" (p. 666) is unclear, taking into account that UML2 itself is a metamodel. This all should be clarified due to the importance of the metamodel concept in this chapter. The same applies to the respective chapter of the Infrastructure document.

  • Reported: UML 2.2 — Thu, 9 Apr 2009 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

issue within UPDM with profile diagrams

  • Key: UMLR-165
  • Legacy Issue Number: 13848
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    there is an issue within UPDM with profile diagrams. As there are multiple stereotypes in the diagrams, showing metaclass and extension clutters the diagrams.
    They become literally unreadable in the spec as they need to fit in the page, since every element takes addition space for extension:

    In MagicDraw, we have such notation:

    It saves time, is intuitive, but this is non standard thing, so we cannot use it in UPDM.

    I would like to raise an issue on the notation of extended metaclass, but I'm open for discussion

  • Reported: UML 2.5 — Tue, 31 Mar 2009 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Should there be a constraint for extends equivalent to 16.3.6 [4]

  • Key: UMLR-175
  • Legacy Issue Number: 14044
  • Status: open  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    Should there be a constraint for extends equivalent to 16.3.6 [4], that extends should be an acylic relationship between use cases?

  • Reported: UML 2.2 — Wed, 1 Jul 2009 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

clarification on Behavior::specification / meaning of InterfaceRealization

  • Key: UMLR-110
  • Legacy Issue Number: 10656
  • Status: open  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    In 7.3.25 InterfaceRealization Semantics the UML2 spec says "For behavioral features, the implementing classifier will
    have an operation or reception for every operation or reception, respectively, defined by the interface. For properties, the
    realizing classifier will provide functionality that maintains the state represented by the property."

    While section 7.3.45 Realization Semantics says "A Realization signifies that the client set of elements are an implementation of the supplier set, which serves as the
    specification. The meaning of ‘implementation’ is not strictly defined, but rather implies a more refined or elaborate form
    in respect to a certain modeling context. It is possible to specify a mapping between the specification and implementation
    elements, although it is not necessarily computable."

    If you interpret this as a literal constraint, then the realizing Classifier would need to copy all of the BehavioralFeatures it realizes. However, it seems unnecessarily redundant to realize an interface and to have to copy all the operations into the realizing classifier too. This means that for an Activity, the "signature" content of an operation could have to be specified up to 6 times:
    1. An Operation in a provided Interface
    2. The same Operation copied into a realizing Class used as the type of a Port
    3. An Operation of a Component containing the Port
    4. The method Behavior whose specification is the Operation owned by the Class
    5. If the Behavior is an Activity, the ActivityParameterNodes
    6. The InputPins and OutputPins of a CallOperationAction that invokes the operation

    In addition, there would be no way for an ownedBehavior's specification to refer to an Operation of an Interface provided through a Port since different ports can realize the same interface but have different implementations.

    There is no explicit constraint that the Classifier has to have a matching Operation, so you could read the above semantics to mean that adding the InterfaceRealization effectively means the Realizing Classifier has the Interface's behavioral features. This seems to be common practice, you don't often see all the realized operations cloned into the realizing classifier as this is redundant and somewhat tedious to do and maintain.

    Consider changing the description of property Behavior::specification in section 13.3.2 from:
    Designates a behavioral feature that the behavior implements. The behavioral
    feature must be owned by the classifier that owns the behavior or be inherited
    by it. The parameters of the behavioral feature and the implementing behavior
    must match. If a behavior does not have a specification, it is directly associated
    with a classifier (i.e., it is the behavior of the classifier as a whole).

    to:

    Designates a behavioral feature that the behavior implements. The behavioral
    feature must be owned by the classifier that owns the behavior or be realized or inherited
    by it. The parameters of the behavioral feature and the implementing behavior
    must match. If a behavior does not have a specification, it is directly associated
    with a classifier (i.e., it is the behavior of the classifier as a whole).

    The possible problems with this change are:
    1 Subclasses cannot redefine realized operations of their superclasses unless the operation is duplicated in the superclass. This is because there would be no redefined element to reference in the superclass. This can be solved by cloning the operations that need to be redefined, or (more likely) redefining an ownedBehavior of the Superclass, not an Operation. So there is no change here.
    2. Setting the specification of an ownedBehavior would result in an update of the realized interface since the opposite of the specification property is the Interface's method property. This is unfortunate coupling between an interface and its method implementations, but there are many other such cases in UML2, and the method property is multi-valued. So this isn't really that much of a problem.

    Some advantages are:
    1. It matches the common understanding or realization
    2. It reduces redundancy in the model
    3. It allows an ownedBehavior's specification to be an Operation of an Interface provided through a Port in an EncapsulatedClassifer. This allows a EncapsulatedClassifier to provide different implementations for the same operation provided through different ports. This would not be possible if the specification operation had to be owned by the containing classifier as there would be no way to distinguish which operation the different behaviors corresponded to.

  • Reported: UML 2.5 — Fri, 9 Feb 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Presentation option for return parameter for operation type are incomplete

  • Key: UMLR-109
  • Legacy Issue Number: 10635
  • Status: open  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    Section 7.3.36 Operation, under Presentation Options explains notation options for expressing the return value of an Operation. The example is:

    toString(): String

    means the same thing as

    toString(return: String)

    This should also be the same as:

    toString(return result: String)

    That is, the default name of the return parameter is "result". This is to be consistent with OCL's reference to the result of an operation in a post condition, and to allow a behavior to be able to refer to a return parameter by name.

  • Reported: UML 2.5 — Mon, 29 Jan 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML 2 Superstructure: Abstractions should be acyclic

  • Key: UMLR-108
  • Legacy Issue Number: 10600
  • Status: open  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The UML Abstractions concept should include a constraint that a graph involving Abstraction relationships should be acyclic; i.e. an <element type> cannot be both a transitively higher level of abstraction and transitively lower level of abstraction of the same <element type>.

    not self.getHigherLevelAbstractions()->includes(self)

  • Reported: UML 2.5 — Fri, 19 Jan 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Constraint.context vs Constraint.constrainedElement

  • Key: UMLR-105
  • Legacy Issue Number: 10413
  • Status: open  
  • Source: Dassault Systemes ( Mr. Tomas Juknevicius)
  • Summary:

    The situation is now more-or-less clear.
    We will use a variant specified OCL spec for evaluating OCL constraints.

    However in my humble opinion, UML spec could also benefit if the descriptions
    of context and constrainedElement were clarrified a bit on how one should use them.
    As Karl correctly notes, when 2 properties can be used to specify the same thing,
    this introduces ambiguities in the model.

    Even if "nothing prevents the context and constrainedElement from beeing the same object",
    on the other hand nothing prevents these 2 from beeing different objects.
    Hence if author produces some UML model with constraints where constrainedElement!=context,
    the readers of this model cannot interpret it unambiguously.
    And I can imagine many cases, where constrainedElement will not be equal to context.
    For example if constraints are placed in a separate package from their constrained elements
    (perhaps constrained elements are in a separate, read-only library and constraints can not
    be added there; or for other packaging reasons). In this case context of these constraints
    will be their owner package (per UML2.1 rules) and constrainedElement will be completely
    unrelated to it.

    PS
    And this applies not only in the narrow case of constraints, specified in OCL.
    Almost all other languages need contextual information.
    For the sake of argument, lets say the constraint is specified in English language.
    Well, it so happens, that English language also needs some context to interpret sentences.
    The pronouns, such as "this", "these" or "such", can play the same role in English as the "self" variable in OCL.

    E.g. Imagine the constraint with specification=OpaqueExpression

    {language=English; body="these must be yellow"}

    placed into the class Box, having property contents:Apple[*] and constrainedElement pointing to this property.
    Now there is an ambiguity.
    If the constraint.context field is used for interpretting the phrase "these must be yellow" then the boxes must be yellow.
    If the constraint.constrainedElement is used, then apples in the box must be yellow.

    > Karl Frank wrote:
    >
    > Agreed. But imo it is a defect for the same thing to be specified in two equivalent ways. EVen if the context is by definition the constrained element, in the case of a
    > constraint, it remains an opening for confusion and doubt to specify it using different terms even when equivalent.
    >
    > But context means something different in regard to a behavior, so I believe constrainedElement is the right term, which is the one used in the OCL spec.
    >
    > - Karl
    >
    > --------------------------------------------------------------------------------------------------------------------------------------------------------------------------
    > From: Branislav Selic bselic@ca.ibm.com
    > Sent: Thursday, May 18, 2006 5:21 PM
    > To: Karl Frank
    > Cc: Juergen Boldt; ocl2-rtf@omg.org; Tomas Juknevicius; uml2-rtf@omg.org
    > Subject: RE: UML/OCL scpec mismatch - Constraint.context vs Constraint.constrainedElement
    >
    > I was indeed raising a separate OCL issue (a major one, I believe), but I was also saying that there is no real issue with the UML 2 spec. In fact, if you think about it,
    > there is nothing to prevent constrainedElement and context from being the same object. There is no real contradiction here.
    >
    > Bran

  • Reported: UML 2.5 — Mon, 22 May 2006 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section: Chapter: 7.3.2.4 View

  • Key: UMLR-104
  • Legacy Issue Number: 10411
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Although it is mentioned in the text it isn't 100% clear that a view has only one conforming viewpoint. Define a constraint for a view that only one conform relationship to a viewpoint is allowed.

  • Reported: SysML 1.0 — Fri, 13 Oct 2006 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section: 7

  • Key: UMLR-103
  • Legacy Issue Number: 10345
  • Status: open  
  • Source: NUI Maynooth ( Jacqueline McQuillan)
  • Summary:

    There is no way to indicate that an Operation is an abstract Operation, perhaps the Operation class should have an isAbstract attribute?( similar to the way the Classifer class has an isAbstract attribute to indicate that its abstract)

  • Reported: UML 2.0 — Tue, 12 Sep 2006 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Connector contract is inflexible

  • Key: UMLR-106
  • Legacy Issue Number: 10474
  • Status: open  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    Connector contract is inflexible and cannot bind connector ends to parts in the contract behavior. A Connector can have a contract which is a Behavior which specifies the valid interaction pattern across the connector. The Behavior could be an Interaction, Activity, StateMachine, ProtocolStateMachine, or OpaqueBehavior. However, the parts in the Behavior (lifeliines. activity partitions, target input pins, variables, etc.) cannot be bound to the ports at the end of the connector. So it is difficult to understand what part participating ports play in the contract beahvior. Another problem is that the may be more than one interaction between the parts at the connector ends representing different conversations between the same parties over the same connector. This would require more than one behavior for the contract in order to describe each interaction.

    Instead, the contract for a connector should be a CollaborationUse. The connectorEnds would then be bound to the roles they play in that contract. The Collaboration of the CollaborationUse can contain multiple ownedBehaviors which represent the interaction protocols between the roles. Parts playing these roles (as indicated by a CollaborationUse) would have to interact in a manner consistent with the corresponding Collaboration ownedBehavior. (These can match by name, but we may want to consider an extension that allowed bindings between operations of the parts and behavior of the collaboration to allow more flexible contracts).

    The interactions between connected consumers and providers instances are initiated by one party or the other (may not be the same for all such interactions). The provider will typically define the protocol consumers must follow in order to use the provided capabilities. One way to model these protocols is to set the type of the Port providing the capability to the Collaboration defining the protocol. Then the type of the CollaborationUse for any Connector connected to that port would be the type of the Port.

  • Reported: UML 2.5 — Wed, 29 Nov 2006 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section: 13 & 14

  • Key: UMLR-100
  • Legacy Issue Number: 9923
  • Status: open  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Sebastien Gerard)
  • Summary:

    Some of the concepts defined in the Interaction chapter (n 14), as for example BehaviorExecutionSpecification, are more general than Interaction and shoul dbe part of the chpater 13 which concern is behavior in general. I suggest to review the chapter 14 in order to extract from this section all the concept that are generic w.r.t. behavior and to put them in the chapter 13.

  • Reported: UML 2.1.1 — Tue, 18 Jul 2006 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Optional values and evaluation of defaults

  • Key: UMLR-99
  • Legacy Issue Number: 9887
  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    7.3.44 says that the defaultValue is "A ValueSpecification that is evaluated to give a default value for the Property when an object of the owning Classifier is instantiated."
    This makes it a bit pointless to have such as property as optional since it will always be set to its default value (though in theory the property could be explicitly unset - in which case it will not use the default value either.
    There is a need for dynamic evaluation of an expression associated with a Property if no value has been explicitly set.

    Proposed resolution:

    • if lower = 1 then defaultValue is assigned to the property when object is instantiated (and when the class is attached to an object using reclassify)
    • if lower = 0 then no assignment is made but the defaultValue (if present) is evaluated each time the property value is read: in effect it is acting as a derived property until a value is explicitly assigned.

    This behavior must also be included in the description of ReadStructurualFeatureAction (11.3.37) which does not mention default values at all.

  • Reported: UML 2.5 — Thu, 6 Jul 2006 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

OCL Syntax in expressions

  • Key: UMLR-98
  • Legacy Issue Number: 9886
  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    When OCL is used in body of OpaqueExpressions it's unclear what syntax should be used - in particular whether keywords like "context:", "inv:", "pre:" should be used or not. Section 7.3.35 should, for OCL, reference the correct concrete syntax element in the OCL spec. Additional material for this issue:

    At the moment in 7.3.35 there is just a 'style guideline' for how OCL constraints/expressions should be expressed using an OpaqueExpression
    For interoperability there should be a stronger statement that OCL constraints must have language = "OCL".
    Also it should be made clearer that such OpaqueExpressions should have type=Boolean

  • Reported: UML 2.5 — Thu, 6 Jul 2006 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Association::isDerived should be derived

  • Key: UMLR-102
  • Legacy Issue Number: 9999
  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    In the L3 metamodel there are only 5 Associations with isDerived=true.
    These are:
    A_context_action
    A_deployedElement_deploymentTarget
    A_state_redefinitionContext
    A_extension_metaclass
    A_containedEdge_inGroup

    However there are clearly many more Associations which are in practice derived - for example anything with an end which is a derivedUnion.
    It seems that an Association should automatically be derived if one or both of its ends are derived.

    Proposed resolution:
    Make Association::isDerived itself a derived property (so it becomes Association::/isDerived)
    The OCL for the derivation would be:
    context Association isDerived = self.memberEnd->exists(isDerived)

  • Reported: UML 2.5 — Wed, 26 Jul 2006 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section: 10.3.4 of formal/2007-02-03

  • Key: UMLR-111
  • Legacy Issue Number: 10781
  • Status: open  
  • Source: Vilnius University, Lithuania ( Donatas Ciuksys)
  • Summary:

    The direction of deployment dependency is wrong in all figures that use this kind of dependency, e.g. figure 10.9 on page 216 (direction is opposite to the one stated in metamodel). The deployment dependency in these figures is being drawn from artifact (client) to target (suplier), though figure 10.4 on page 210 defines Deployment as being dependency with DeploymentTarget as client and DeployedArtifact as supplier, so direction should be opposite - from target to artifact. As an alternative, the metamodel could be adjusted.

  • Reported: UML 2.1.1 — Mon, 19 Feb 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML 2.1.1 - notation for parameter sets

  • Key: UMLR-116
  • Legacy Issue Number: 10957
  • Status: open  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    I note that the notation for parameters sets shown is for invocations of activities, not for activity definitions. Is it intended that there is a similar notation for grouping activity parameter nodes that represent parameter sets?

  • Reported: UML 2.5 — Tue, 27 Mar 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Units and types are still problematic

  • Key: UMLR-115
  • Legacy Issue Number: 10824
  • Status: open  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    Units and types are still problematic. UML notation is not able to show tags of some referenced elements - in case of attributes, they should show tags of type, in case of slots, they should show tags of type of defining feature (secondary reference).

  • Reported: UML 2.5 — Fri, 9 Mar 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

names and namespaces

  • Key: UMLR-114
  • Legacy Issue Number: 10823
  • Status: open  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    Namespace defines derived "member" collection for NamedElements identifiable by name.
    However not all Namespaces subset this collection, so NamedElements are added just to ownedElements.

    Example: Activity and ActivityNodes. Actions and ObjectNodes could have identical names because they are not added into "ownedMember" collection and are not identified by name.
    Is this correct or bug in metamodel? I believe we could find more such Namespaces.

  • Reported: UML 2.5 — Wed, 14 Mar 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section: 14.4 Timing Diagram: Continuous time axis

  • Key: UMLR-118
  • Legacy Issue Number: 11092
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Table 14.6., State or condition timeline: It is unclear how the time information is stored in the interaction model. Especially if it is a continuous timeline. Please clarify the repository model for timing diagrams

  • Reported: UML 2.1.1 — Fri, 8 Jun 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

9.3.9 Invocation Action

  • Key: UMLR-117
  • Legacy Issue Number: 10999
  • Status: open  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    In the semantics, the spec needs to state what happens if there are multiple instances corresponding to the port (which might happen if the multiplicity upper bound of the port is greater than 1)

  • Reported: UML 2.5 — Thu, 10 May 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section: Annex A: Diagrams

  • Key: UMLR-120
  • Legacy Issue Number: 11273
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The abbreviation sd for interaction diagrams should be renamed to id. sd stands for sequence diagram, but there three more interaction diagrams. It is confusing to have a diagram kind sd for a timing diagram.

  • Reported: UML 2.1.1 — Fri, 10 Aug 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Meaning of relationship between iteration clause and Lifeline.selector clau

  • Key: UMLR-53
  • Legacy Issue Number: 8700
  • Status: open  
  • Source: TMNA Services ( Jim Schardt)
  • Summary:

    UML2-rtf issue: Meaning of the relationship between the iteration clause and the Lifeline.selector clause.

    Interactions often involve the invocation of multiple instances of the same class. For example I may want and instance of my Portfolio class to invoke the currentValue method on instances of associated Asset classes that belong to an asset category (Asset.assetCategory = Stock). This way a portfolio may assess its own value by summing up the current value of all its stock assets. To model this I want to show the same message - currentValue() being sent to the selection of assets that have the assetCategory equal to "Stock."

    Does the current UML2 communications diagram notation support the following:

    A portfolio Lifeline labeled theFund : Portfolio
    An asset Lifeline labeled myAssets [assetCategory = Stock] : Asset
    This would have to represent not one but all the asset instances that had an assetCategory of Stock
    A line connecting the two Lifelines
    A message with a sequence expression that looks like:
    1 *[holding := 1..n] : assetValue = currentValue()

    Lifelines are defined to represent only one interacting entity in an interaction. However the interaction syntax for communication diagrams would indicate that the lifeline can be "multivalued."

    The need for a Lifeline to represent multiple instances for the purpose of sending a single message to all of them at some nesting level is very common.

    Suggestion: Allow the Lifeline to have a multiplicity shown within brackets as with parts. Constrain the lifeline to have multiplicity one or greater. Constrain the lifeline with a multiplicity greater than one to have a selector that can, upon applying the selector, result in a single particpant.

  • Reported: UML 2.5 — Thu, 21 Apr 2005 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section: 14.3.3 Page: 508+

  • Key: UMLR-59
  • Legacy Issue Number: 8765
  • Status: open  
  • Source: Ostfold University College ( Dr. Oystein Haugen)
  • Summary:

    Sequence diagrams are often used for early specification of requirements. The distinction between potential and mandatory behavior is not adequately described in UML 2.0 Interactions. To improve this we suggest an additional operator "xalt" that describes alternative operands that are mandatory meaning that any refinement should keep at least some of the behavior of each operand. See paper at <<UML2003>>: Haugen, Stølen: STAIRS - Steps to Analyze Interactions with Refinement Semantics

  • Reported: UML 2.0 — Wed, 4 May 2005 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section: 14.3.3

  • Key: UMLR-58
  • Legacy Issue Number: 8764
  • Status: open  
  • Source: Ostfold University College ( Dr. Oystein Haugen)
  • Summary:

    In sequence diagrams, the neg operator is used to describe invalid behaviours. However, people tend to interpret neg slightly differently depending on the context in which it appears, thus making it difficult to define a precise semantics for it. Two examples: A sequence diagram with a neg fragment is usually taken to describe also positive (valid) behaviours, i.e. the behaviours of the diagram with the neg fragment simply omitted. This implies that the empty trace should be positive for the neg fragment in this context. Another common use of neg is to state that one of the alternatives (operands) of an alt construct describes the invalid behaviour. In this case, the neg fragment has no positive behaviours (not even the empty trace). Recommendation: Consider introducing another operator in addition, due to the different uses of the neg operator.

  • Reported: UML 2.0 — Wed, 4 May 2005 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML 2.0 Super/Use Cases/Subject of a Use Case

  • Key: UMLR-65
  • Legacy Issue Number: 8883
  • Status: open  
  • Source: MID GmbH ( Mr. Detlef Peters)
  • Summary:

    Section 16.3.2 allows "classifiers in general to own use cases". Section 16.3.6 however states that the "subject of a use case could be (...) any other element that may have behavior". These elements are called "BehavioredClassifier" by Section 13 and are a specialization of Classifier.
    Please clarify the consequences of these statements:

    • may all Classifiers be owners of UseCases, but only BehavioredClassifiers be the subject of a UseCase?
    • what is the semantics of Non-BehavioredClassifiers, e.g. an Interaction or OpaqueBehavior, owning a UseCase or being a subject of it? A UseCase "represents a declaration of an offered behavior" (16.3.6), so how can Non-BehavioredClassifiers ever offer a behavior?
  • Reported: UML 2.5 — Tue, 28 Jun 2005 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Issue 7368 - make Classifier::useCase navigable

  • Key: UMLR-64
  • Legacy Issue Number: 8855
  • Status: open  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    To indicate which actor initiates the interaction a communicates association may optionally be adorned with an arrow head to represent navigability.
    (No arrowhead indicates either actor can initiate the interaction.)

    Constraints:
    [1] Only one arrowhead can point towards the use case.
    [2] All other communicates associations have arrow heads pointing towards the other actors.

    Figure 409, page 660 could be modified and used as an example.

  • Reported: UML 2.5 — Thu, 2 Jun 2005 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML2-rtf issue: communication diagram

  • Key: UMLR-52
  • Legacy Issue Number: 8699
  • Status: open  
  • Source: TMNA Services ( Jim Schardt)
  • Summary:

    UML2-rtf issue related to communication diagrams:

    Section 14.4 describes the sequence expression tied to messages on a communications diagram. However, the abstract syntax does not (as far as I can trace the diagram) model the sequence expression. This leaves the sequence expression semantics wide open.

    Some tools implement the sequence express but the concept of threads and nesting implicit in the expression syntax are undefined in the meta model.

    Recommendation: Add a SequenceExpresion element into the model associate it with message, and define it explicitly. Describe the semantics of nesting messages.

  • Reported: UML 2.5 — Thu, 21 Apr 2005 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section: 10.3.1

  • Key: UMLR-51
  • Legacy Issue Number: 8693
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Bidirectional association between artifact and operation required Fig. 124 on page 205 show an unidirectional association from artifact to operation. In the context of the Actions it is necessary to access the owner of an operation. Therefore the association must be bidirectional.

  • Reported: UML 2.0 — Sun, 10 Apr 2005 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Arguments of Message

  • Key: UMLR-61
  • Legacy Issue Number: 8786
  • Status: open  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    3. Arguments of Message
    Variables, members and other "value holders" can be used as arguments of call actions or arguments of message (for example setName(name) where "name" is variable defined in Interaction), but now arguments are simple ValueSpecification, so can't have reference to "real" argument (variable, member, parameter of behavior etc.)
    Maybe Argument should be in metamodel as in UML 1.4, or at least ValueSpecification should be subclassed in Interactions package and introduce reference to Element that value it represents?

  • Reported: UML 2.5 — Wed, 18 May 2005 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

ConditionalNode inputs used by more than one test

  • Key: UMLR-60
  • Legacy Issue Number: 8779
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    ConditionalNode inputs used by more than one test. In ConditionalNode, the tokens in input pins might be consumed by one test body execution and not available to another. They need a similar mechanism to LoopNode that copies the inputs to test body in puts and destroys the original inputs when the loop node is done

  • Reported: UML 2.0 — Sun, 15 May 2005 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Association in UseCase diagram

  • Key: UMLR-56
  • Legacy Issue Number: 8758
  • Status: open  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    Actor and UseCase can't own Properties, this means that associations
    > in UseCase diagram are always non-navigable at both ends.
    > Is this correct?

    ??? I don't have the time at the moment to check whether such a constraint exists, but, if it does, it is certainly an error. For example, in the case of Actors there is an explicit constraint that assumes that actors have properties. Can you tell me where your assumption that Actors and UseCases cannot own Properties comes from?

  • Reported: UML 2.5 — Tue, 3 May 2005 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Possibility to define a Collection as default Value needed

  • Key: UMLR-55
  • Legacy Issue Number: 8756
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Multiple default values. In Figures 10 and 12, the max multiplicity for defaultValue is 1. What if the property or parameter is multivalued? There is no value specification for collections.

  • Reported: UML 2.0 — Tue, 3 May 2005 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Variables

  • Key: UMLR-63
  • Legacy Issue Number: 8788
  • Status: open  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    What namespace should be owner of variables used in sequence diagram?
    If variables are added into Interaction, they conflict, because every execution (method for example, or even loop) can introduce variables with some names, that should be not accessible outside.
    Maybe ExecutionSpecification or InteractionFragment should be NameSpaces and declare collection for storing variables?

  • Reported: UML 2.5 — Wed, 18 May 2005 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Numbering

  • Key: UMLR-62
  • Legacy Issue Number: 8787
  • Status: open  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    Messages in UML 2.0 can't have numbers in the model, but all examples of sequence and communication diagrams are with numbers. How numbers should be mapped into model? How to migrate with old activator, successors, predecessors?

  • Reported: UML 2.5 — Wed, 18 May 2005 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Add a Constraint

  • Key: UMLR-50
  • Legacy Issue Number: 8684
  • Status: open  
  • Source: FUNDP ( Pierre Yves Schobbens)
  • Summary:

    No consistency condition is put between predecessor clauses, for instance two clauses can be the predecessor of each other. Add a Constraint: The transitive closure of predecessorClause must be a strict partial order.

  • Reported: UML 2.5 — Tue, 5 Apr 2005 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

SequenceNode should have way to set output pins in CompleteStructured

  • Key: UMLR-49
  • Legacy Issue Number: 8501
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    SequenceNode should have way to set output pins in CompleteStructured, like ConditionalNode and LoopNode do.

  • Reported: UML 2.0 — Sun, 6 Mar 2005 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Arguments of Message

  • Key: UMLR-57
  • Legacy Issue Number: 8761
  • Status: open  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    arguments of call actions or arguments of message (for example
    > setName(name) where "name" is variable defined in Interaction), but
    > now arguments are simple ValueSpecification, so can't have
    > refference to "real" argument (variable, member, parameter of behavior etc.)
    > Maybe Argument should be in metamodel as in UML 1.4, or at least
    > ValueSpecification should be subclassed in Interactions package and
    > introduce reference to Element that value it represents?

  • Reported: UML 2.5 — Tue, 3 May 2005 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML: Include text description field with model element --- additional information added

  • Key: UMLR-201
  • Legacy Issue Number: 14941
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    While almost every tool supports the concept of a model element specification, they are not consistent on which elements can have them nor are they consistent on the contents/typing of the specification. Please make model element specification available on ALL elements and make the format and content a rich field.

    This capability is required for modelers to incorporate significant amount of explanatory documentation for each element. The ability to include textual descriptions for each model element and other basic metadata should be part of UML. In addition, such text should be augmented with the ability to structure and format the model element descriptions.

    We would like to see support for RTF, PDF, XML, HTML, and XHTML, as well as support for including graphics

    Similarly, a modeler should be able to type any attribute with a string-like type that allows for similar formatting or markup.

  • Reported: UML 2.5 — Mon, 11 Jan 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML: Provide unique URL/URI Reference to/from Model Elements

  • Key: UMLR-200
  • Legacy Issue Number: 14940
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Unique URL/URI Reference to/from Model Elements

    In Model-Driven Development (MDD), the model is the repository of truth on the project. However, we recognize that the complete containment of all information on a project in a single tool repository is not a near-term solution. To this end, we need the ability to support explicit references from model elements to externals (such as documents, other types of models) and similar references back.

    This are not just pointers, we need the ability to incorporate information (e.g., documents, web pages, diagrams, pictures) from elsewhere and to support refreshing with current data, as well as the export of model information into external locations. Some simple examples:

    1. A driving requirements document may contain tables and pictures, a modeler will need direct access to these elements.

    2. A reviewer of a model may need to see diagrams where the appropriate and current icons substitute for the UML graphical elements.

    3. An organization may wish to publish documentation of a particular aspect of the model on the internet and wish that the visitors always obtained the latest information

  • Reported: UML 2.5 — Mon, 11 Jan 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML: A strong ability to support generating Documents

  • Key: UMLR-207
  • Legacy Issue Number: 14947
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    A strong ability to support generating Documents
    On the type of projects that we work on, we find that the project needs the ability to produce standardized documents from the models. While most tools support documentation generation to some extent, the rules used to construct the documents are not standardized. UML needs the ability to create these documents in a standardized way that can support automatic generation from the package structure, the model element descriptions (see above), incorporating diagrams, externals (see URL/URI above), and document models (a UML model of the document by composition of sections).

    The creation of these documents should support rule-based and manually constructed diagrams.

    These could be based on IEEE 1471 views and the use of QVT.

  • Reported: UML 2.5 — Mon, 11 Jan 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML Support for multiple library levels

  • Key: UMLR-206
  • Legacy Issue Number: 14946
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    In large-scale development environments where development may be iterative and/or incremental, it often happens that there are standardized libraries of common or reusable elements, in various levels of completion. These may be type definitions, classes, objects, parts, requirements, etc. While current «import» and «access» are useful to reuse these elements, we need the ability to specify an ordered chain of libraries, where an element usage would obtain the first occurrence of the element in the chain. Note that the libraries may be located remotely or on the web.

  • Reported: UML 2.5 — Mon, 11 Jan 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Provide notational mechanism to represent any group of model elements based on some criteria w/o stealing ownership

  • Key: UMLR-203
  • Legacy Issue Number: 14943
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Non-structural, non-owning Containment
    While packages and stereotypes have their purposes, we need another way of combining and identifying groups of related elements based on specific partitioning criteria. This allows us to categorize and organize system elements – a common task for SEs.

    We could use this to identify those elements that are related to a particular architectural layer, due in a particular delivery, produced by a particular manufacturer, or related to a particular concern (e.g., security).

    Model elements could belong to any number of these containers. These containers should appear on diagrams, tables, and the browsers, but should not confer or change any prior ownership. Populating these containers could be done mechanically and/or by execution of rules. The containers can have value properties and dependencies that are considered to logically apply to the members of the container

  • Reported: UML 2.5 — Mon, 11 Jan 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML: Better Definition of Compliance

  • Key: UMLR-210
  • Legacy Issue Number: 14950
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Diagram / Model Interchange
    The current level of Diagram and Model interchangeability is appalling and is a significant barrier to further penetration of UML/SysML Into the marketplace. With the advent of new test suites (such as by OMG’s Model Interchange Working Group (MIWG)), the UML specification should require demonstrated success in some of these tests before a UML tool can be declared conforming to UML.

    OCL Support
    A minimal required support for OCL should be defined as part of compliance.

    QVT Support
    A minimal required support for QVT should be defined as part of compliance.

  • Reported: UML 2.5 — Mon, 11 Jan 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML: Provide mathematical formalism for UML semantics to provide precise meaning to language constructs

  • Key: UMLR-209
  • Legacy Issue Number: 14949
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Leverage and build upon fUML semantics and associated formalism to provide semantics for behavior and structure

  • Reported: UML 2.5 — Mon, 11 Jan 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML: Support for maintaining what-if models in repository without massive duplication

  • Key: UMLR-205
  • Legacy Issue Number: 14945
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Support for maintaining what-if models in repository without massive duplication

    UML and descendant modeling languages should be able to support multiple solutions within a model without excessive duplication. This could be because of planned system evolution or because we need to compare multiple approaches. One solution might be to support standardized named effectivity/expiration fields for each model element (including dependencies). All diagrams, queries, reports, etc., could be conditioned by a selected date. Instead of dates, a set of version numbers could apply to each model element, with the model filtering work in same way.

  • Reported: UML 2.5 — Fri, 27 Jun 2014 11:17 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML: A strong ability to support reviewing packages

  • Key: UMLR-204
  • Legacy Issue Number: 14944
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    A strong ability to support reviewing packages
    On the large projects, we find that the project needs the ability to present model subsets to reviewers, and allow commenting, proposed corrections, assignment of action items, and red-line comparisons. UML needs the ability to create these review packages in a way that can support the types of changes that reviewers propose – without changing the underlying model.

    The creation of these review packages should support both rule-based and manually constructed packages, including the diagrams and the selection of elements.

    These could be based on IEEE 1471 views and the use of QVT.

  • Reported: UML 2.5 — Mon, 11 Jan 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML: Diagrams as Model Elements

  • Key: UMLR-208
  • Legacy Issue Number: 14948
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Diagrams as Model Elements
    Make diagrams full and equal model elements, tied to the regular model element that the diagram is displaying. Refer to the SysML specification in Annex A.

    All diagrams types should have an unique 2-3 character model element type, and also supporting diagram types.

    As a regular model element is should be able to support attributes, such as ownership, status, purpose, version (possibly operations also) and dependencies. As a model element, it should be referable by any URL/URI scheme that can reference model elements.

  • Reported: UML 2.5 — Mon, 11 Jan 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML Associate an image/icon with each model element

  • Key: UMLR-199
  • Legacy Issue Number: 14939
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    UML should support the ability to associate an image/icon with each model element. Current approaches only allow a stereotype based approach. Each model instance should be able to have its own icon.

  • Reported: UML 2.5 — Mon, 11 Jan 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Reconcile the algebra of collections across OCL & UML’s intentional & extensional semantics

  • Key: UMLR-184
  • Legacy Issue Number: 14356
  • Status: open  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    Reconcile the algebra of collections across OCL & UML’s intentional & extensional semantics & test this statically with OCL & dynamically with OCL & fUML scenarios. Bran,

    Your comments and those from Dave Hawkins & Salman Qadri confirm my
    suspicions that it would be unwise to submit a resolution to 8023 in ballot 10; I won’t.

    Dragan Milicev’s paper is really excellent; I’m really glad you pointed this out.
    I highly recommend this paper for consideration in the UML2 RFI workshop:

    On the Semantics of Associations and Association Ends in UML
    Milicev, D.;
    Software Engineering, IEEE Transactions on
    Volume 33, Issue 4, April 2007 Page(s):238 - 251
    http://ieeexplore.ieee.org/search/wrapper.jsp?arnumber=4123326

    Dragan clearly states that his formalization of association is squarely in
    the domain of intentional semantics; not extensional semantics as stated in
    clause 7.3.3:

    “An association describes a set of tuples whose values refer to typed
    instances. An instance of an association is called a link.”

    This paper points to a fundamental limitation in the way the runtime
    semantics of the UML2 has been specified in clause 6.3.1 in the domain of
    extensional semantics:

    “Classes, events, and behaviors model sets of objects, occurrences, and
    executions with similar properties. Value specifications, occurrence
    specifications, and execution specifications model individual objects,
    occurrences, and executions within a particular context.”

    The real problem here isn’t in the fact that there are two different ways to
    specify the semantics of associations ­ the restrictive interpretation in
    Dragan’s terminology which is really an extensional semantics and the
    intentional semantics Dragan proposes which I believe is fundamentally
    correct (as far as I’ve read it).

    The real problem is in the semantic mismatch between the extensional & intentional semantics of associations (assuming Dragan is right).
    The current extensional semantics of the UML2 is based on an impoverished notion of collections: sets & sequences.
    Dragan’s intentional semantics for associations involves the same categories of collections that OCL uses: sets, sequences & bags (see clause 7.5.11 in ocl2/ocl2.1)

    What this all means is that we need to focus an RTF cycle on reconciling the algebra of collections across OCL & the extensional & intentional semantics of UML2 and of fUML.
    The goal of this reconciliation is twofold:

    we should be able to specify all necessary well-formedness constraints on the relationship between M1 & M0 in OCL
    we should be able to use fUML to exercise relevant scenarios of events starting in one M1/M0 context and finishing in another M1/M0’ context and specify in OCL well-formedness constraints on the relationship between M0/M0’ as a function of the events processed & the behavior that happened as a result of processing by some active object (see clause 6.4.2).

    We can use the fUML subset to scope this reconciliation effort to something manageable as an RTF; learn from this experience and use that to tackle more exotic things like state machines.

  • Reported: UML 2.5 — Tue, 8 Sep 2009 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML: Issue with stereotype icons in a profile

  • Key: UMLR-183
  • Legacy Issue Number: 14227
  • Status: open  
  • Source: International Business Machines ( Mr. Gary Johnston)
  • Summary:

    Currently, a profile can include an icon for a stereotype. This means that a stereotype can have just one icon. If a stereotype extends more than one UML metaclass the profile designer might want to include different icons depending on which of the metaclasses the stereotype is applied to. For example, if I define a stereotype <Foo> that extends both <metaclass> Interface and <metaclass> Class, I will probably want a different icon for the two different usages of <Foo> but there is no way to define more than one icon per stereotype.
    The suggestion is that one should be able to specify an icon for the extension relationship between a stereotype and metaclass instead of (or in addition to, perhaps) on the stereotype itself. Profile authors would then be able to assign distinct icons for different stereotype usages. And UML tools would then be able to display distinct icons in such cases.
    This issue came up during discussions of the in-progress SoaML specification & profile. One of its stereotypes (<ServiceInterface>) extends both Class and Interface and the icons for each should be visually distinct. Currently, profiles don't provide a way to make this happen.

  • Reported: UML 2.5 — Thu, 27 Aug 2009 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

The spec may require some clarification regarding figure 14.16

  • Key: UMLR-182
  • Legacy Issue Number: 14186
  • Status: open  
  • Source: Anonymous
  • Summary:

    The spec may require some clarification regarding figure 14.16 .

    I believe that "PIN" is just an attribute of the interaction "UserAccepted" but it may be unclear from the picture alone.

    In addition, how can the local attribute PIN be passed as a parameter to the operation Code()? On the message "Code" would we specify an attribute of type Opaque Expression and use PIN ? This seems to break the formal link between PIN the attribute and PIN the argument.

  • Reported: UML 2.5 — Tue, 11 Aug 2009 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Need notation option to show type stereotype on typed element

  • Key: UMLR-181
  • Legacy Issue Number: 14183
  • Status: open  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    A part (property, port, etc.) of a class is a TypedElement and can of course have applied stereotypes of its own. However, it is often useful to know not only the Type of a TypedElement, but how that type is stereotyped. This would provide more complete information about the type that helps communicate the meaning of the model.

    Some tools by default show the stereotypes of a type on parts typed by that type. For example, if Interface Purchasing is stereotyped as <<Provider>>, a port typed by that Interface might be displayed as <<Provider>>purchaser: Purchasing. But this is actually incorrect because it shows <<Provider>> extending a Port while the stereotype is defined to extend Inteface, not Property.

    UML2 should provide a notation option to allow Type stereotype names to be displayed in TypedElements. The example above could be more correctly shown as purchaser: <<Provider>> Purchasing - the stereotype for the interface is next to the interface, on the other side of the colon. If the Port is a <<Service>> port, then that would be shown as <<Service>>purchaser: <<Provider>>Purchasing.

  • Reported: UML 2.5 — Thu, 6 Aug 2009 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Stereotyped Constraints in UML

  • Key: UMLR-188
  • Legacy Issue Number: 14544
  • Status: open  
  • Source: Alion Science and Technology ( Jim Logan)
  • Summary:

    The UML 2.2 spec (ptc/2008-05-05) does not allow showing only a constraint name in braces. I have found this non-standard feature very valuable when working with business users and would like to see it allowed.

    The most flexible way to use constraints is to have a short, informal English description as the name, and real OCL as the formal expression. Having the flexibility to show either the name or the expression gives the best of two worlds: business SMEs can read and validate the informal English name while tools can use the OCL expression to actually enforce the constraints. In addition, a diagram can present a view for business SMEs or a view for technical people.

    I recommend changing the notation from this:

    <constraint> ::= '

    {' [ <name> ':' ] <Boolean-expression> '}

    '

    to this:

    <constraint> ::= '

    {' [ <name> ] ':' <Boolean-expression> | <name> '}

    '

    This change would allow:

    the author to choose to show:
    only { : expression } for technical users (a common practice)
    only

    { name }

    for non-technical users (a currently disallowed but important practice)
    both

    { name : body }


    the viewer to tell the difference between the name and the expression when only one is shown
    consistency with the way several other things work in UML, such as:
    action names
    action pin names
    instance specification names (i.e., just shows the name when there's no type)

    attributes (i.e., one can suppress the ": Type")

  • Reported: UML 2.5 — Thu, 8 Oct 2009 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Stereotyped Constraints in UML

  • Key: UMLR-187
  • Legacy Issue Number: 14536
  • Status: open  
  • Source: Alion Science and Technology ( Jim Logan)
  • Summary:

    In the UML 2.2 spec (ptc/2008-05-05), there is no way to show that a constraint on a class has a stereotype or stereotype tags. I would like to see something with nested braces. For example, { <<stereotype>> constraint1: body

    {tag1=value, tag2=value}

    }.

    I recommend changing the notation from this:

    A Constraint is shown as a text string in braces ({}) according to the following BNF:

    <constraint> ::= '

    {' [ <name> ':' ] <Boolean-expression> '}

    '

    to this:

    A Constraint is shown as a text string in braces ({}) according to the following BNF:

    <constraint> ::= '{' [ <stereotypes> ] [ <name> ':' ] <Boolean-expression> [ '

    {' <valuestring> '}

    ' ] '}'

    The <stereotypes> and <valuestring> use the presentation options described in 18.3.8 (Stereotype).

  • Reported: UML 2.5 — Wed, 7 Oct 2009 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Property subsets other regular property, non-derived union

  • Key: UMLR-191
  • Legacy Issue Number: 14928
  • Status: open  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    Property subsets other regular property, non-derived union. I would like to get rid of that as it causes implementation overhead costs, we must manage and synchronize two collections.

    Association::memberEnd is not union but is subsetted
    Class::ownedAttribute is not union but is subsetted
    TemplateSignature::parameter is not union but is subsetted

  • Reported: UML 2.5 — Fri, 8 Jan 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

are Create messages aynch or synch, or doesn't it matter?

  • Key: UMLR-190
  • Legacy Issue Number: 14588
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    In 14.3.24, the textual definition of MessageSort is badly formatted, which needs to be fixed. Then it provides for messages of sorts synchCall, asynchCall, asynchSignal, createMessage, deleteMessage and reply.

    So is a createMessage synchronous, or asynchronous, or can it be either? The semantics of CreateObjectAction say “The new object is returned as the value of the action” - which implies that synchronous ought to be a possibility. But chapter 14 appears silent on this topic.

  • Reported: UML 2.5 — Wed, 28 Oct 2009 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML 2 TemplateParameterSubstitution inconsistency about multiplicity of Actual and OwnedActual

  • Key: UMLR-189
  • Legacy Issue Number: 14555
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    In the model, Actual is shown as 1.* and OwnedActual is shown as *.

    In the text 17.5.5, Actual is shown as 1 and OwnedActual is shown as 0..1.

  • Reported: UML 2.5 — Mon, 12 Oct 2009 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

PrimitiveType has missing constraints

  • Key: UMLR-186
  • Legacy Issue Number: 14449
  • Status: open  
  • Source: gmail.com ( Guus Ramackers)
  • Summary:

    The UML specification text for PrimitiveType states that it has no operationsnor attributes:

    "A primitive type defines a predefined data type, without any relevant substructure (i.e., it has no parts in the context of
    UML). A primitive datatype may have an algebra and operations defined outside of UML, for example, mathematically."

    However, because PrimitiveType is a subtype of DataType in the spec, it inherits the ability have attributes and operations.

    Constraints need to be added to restrict this, or else PrimitiveType should not specialize DataType.

    The current situation is confusing to tool vendors. Potentially any imported XMI might have a PrimitiveType with attributes and operations defined according to the specification.

  • Reported: UML 2.2 — Mon, 5 Oct 2009 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML Issue: Refactor UML to separate SW-Specific Aspects from Foundation Language

  • Key: UMLR-193
  • Legacy Issue Number: 14933
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Refactor UML to separate SW-Specific Aspects from Foundation Language

    One useful refactoring would be to separate UML into a abstract modeling part and a software model part, so that other standards can base themselves on the abstract modeling piece without the baggage of software specific features. We would not want to encourage programming language-specific profiles, but wish to take out things such as components from the base UML profile.

  • Reported: UML 2.5 — Mon, 11 Jan 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

One association end is derived, another is not

  • Key: UMLR-192
  • Legacy Issue Number: 14930
  • Status: open  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    One association end is derived, another is not. It causes implementation issues, as when we set one end, opposite should be automatically set also.

    Vertex::outgoing [0..*] is derived, opposite Transition::source [1] is not
    Activity::structuredNode [0..*] is derived, opposite StructuredActivityNode::activity [0..
    ConnectableElement::end [0..*] is derived, opposite ConnectorEnd::role [1] is not
    Package::ownedType [0..*] is derived, opposite Type::package [0..] is not
    Package::nestedPackage [0..*] is derived, opposite Package::nestingPackage [0..] is not
    Vertex::incoming [0..*] is derived, opposite Transition::target [1] is not

  • Reported: UML 2.5 — Fri, 8 Jan 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Simplify by Making UML More Consistent: Allow States to be model as classes supporting inheritance and composition

  • Key: UMLR-195
  • Legacy Issue Number: 14935
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    In OMT, states could be modeling on the class diagram, which was a powerful alternative approach to capture the structure of a state machine. It made clear the relationships between entry/exit actions of superstates on substates, the ability to override responses to trigger/actions pairs of superstates by a substate, the scope of a defer, what a history node really does, etc. understandable in a way that statemachines don’t do because of their different presentation style. This should also restore the ability to identify state-specific attributes and constraints, and the ability to specify parameters on the state’s possible behaviors – two features that have often been requested. Restoring this ability will make UML treatment of states more like their treatment for classes. Similar ideas have been periodically proposed, see http://www.conradbock.org/statemachine.html.

  • Reported: UML 2.5 — Mon, 11 Jan 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Simplify by Making UML More Consistent: Apply class and composite structure diagram rules to behavior modeling

  • Key: UMLR-194
  • Legacy Issue Number: 14934
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Simplify by Making UML More Consistent: Apply class and composite structure diagram rules to behavior modeling.

    One problem with UML now is that the ability to simplify by applying more consistency is not taken advantage of. By being consistent – eliminating special cases, the specification becomes smaller, the modelers have to learn less, the tools can reuse code, and UML becomes easier to understand and use.

    As behaviors (e.g., operations, activities) are classifiers, there is no good reason why the class and composite structure diagrams cannot be used to model them. This would allow for diagrams showing inheritance, composition, associations, dependencies, etc. While this may not be “OO”, it would support functional decomposition/programming approaches, simplify, and make more regular the specification. See the RFI response ad/2009-08-05.

  • Reported: UML 2.5 — Mon, 11 Jan 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML: Include text description field with model element

  • Key: UMLR-198
  • Legacy Issue Number: 14938
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    While almost every tool supports the concept of a model element specification, they are not consistent on which elements can have them nor are they consistent on the contents/typing of the specification. Please make model element specification available on ALL elements and make the format and content a rich field.

  • Reported: UML 2.5 — Mon, 11 Jan 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML: Incorporate SysML Requirements Model into UML

  • Key: UMLR-197
  • Legacy Issue Number: 14937
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Software Developers, and any people who are using UML as a core language can use the ability to capture /categorize requirements

  • Reported: UML 2.5 — Mon, 11 Jan 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML: Need more robust value model that would enable capture of values vs time

  • Key: UMLR-196
  • Legacy Issue Number: 14936
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Current timing model does not enable useful capture/mapping of values vs time. UML does support initial values and current values, but not evolving values. This is necessary for proper description of the behavior, capture of simulations, requirements development

  • Reported: UML 2.5 — Mon, 11 Jan 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

InterfaceRealization

  • Key: UMLR-148
  • Legacy Issue Number: 12860
  • Status: open  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    InterfaceRealization.contract and InterfaceRealization.implementingClassifier currently subset Dependency.supplier and Dependency.client respectively.

    It seems to be that redefinition is a more appropriate relationship between these attributes, because InterfaceRealization.supplier and InterfaceRealization.client (as inherited) are restricted to the multiplicities of, and will always have the exactly the same values as, InterfaceRealization.contract and InterfaceRealization.implementingClassifier.

  • Reported: UML 2.5 — Fri, 27 Jun 2014 11:17 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

issue to address how problem 11240 was actually addressed in UML 2.2 spec

  • Key: UMLR-147
  • Legacy Issue Number: 12852
  • Status: open  
  • Source: Anonymous
  • Summary:

    believe we need to raise a new issue to address how problem 11240 was actually addressed in the UML 2.2 spec.

    If I'm not mistaken, the fix for issue 11240 should involve redefining TemplateParameter::default and constraining the type to Classifier. However, all that was actually done to address the problem was to remove the offending (redundant) "defaultClassifier" property. The original issue: http://www.omg.org/issues/uml2-rtf.html#Issue11240 , makes mention of the redefinition.

  • Reported: UML 2.5 — Thu, 11 Sep 2008 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Figure 7.65 and its explanation, P115

  • Key: UMLR-146
  • Legacy Issue Number: 12837
  • Status: open  
  • Source: Architecture Technology Institute ( Hiroshi Miyazaki)
  • Summary:

    there is a following description:
    "A in package P3(P3::A) represents the result of the merge of P1::A into
    P2::A and not just the incremnetP2::A."

    According to definition of Package import,
    If the name of an imported element is the same as the name of an element
    owned by the importing namespace, that element is not added to the importing namespace.

    Therefore, if there is same name A on the Pacakge"P3", P2::A is invisible from P3?

  • Reported: UML 2.5 — Mon, 8 Sep 2008 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section: 15.3.7 Constraint [2]

  • Key: UMLR-138
  • Legacy Issue Number: 12354
  • Status: open  
  • Source: Logica ( Tis Veugen)
  • Summary:

    Constraint [2] says: A protocol transition never has associated actions. My problem is that this constraint makes it impossible to specify a consistent pair of a server protocol state machine (PSM) and a client PSM. The server PSM has call events as triggers. It also has internal events causing autonomous state transitions. However, the latter transitions must be notified to the client PSM. This can only be done by actions in which signal events are generated to the client FSM. Such signals are the triggers in the client FSM; and in fact the same problem happens here. Since the call events to the server PSM are caused by internal events at the client PSM, that force call events to the server PSM in the actions. I hope this issue can be solved or at least clarified. Thanks.

  • Reported: UML 2.1.2 — Sun, 23 Mar 2008 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML Super 2.1.2: section 18.3.2

  • Key: UMLR-137
  • Legacy Issue Number: 12285
  • Status: open  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    In the semantics section the spec says

    “When the extension is required, then the cardinality on the extension stereotype is “1.” The role names are provided using the following rule: The name of the role of the extended metaclass is: ‘base_’ extendedMetaclassName The name of the role of the extension stereotype is: ‘extension$_’ stereotypeName.”

    I have two issues with this. This first is that in all example that follows – the extension role names don’t have a dollar in them and so are inconsistent with the spec.

    Secondly, I think this should say that these are the default names if the modeller doesn’t provide any. In fact later on in the Presentation Options section of 18.3.8, the spec says:

    “If the extension end is given a name, this name can be used in lieu of the stereotype name within the pair of guillemets when the stereotype is applied to a model element.”

  • Reported: UML 2.5 — Wed, 19 Mar 2008 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML2 issue regarding Redefinition

  • Key: UMLR-145
  • Legacy Issue Number: 12570
  • Status: open  
  • Source: Anonymous
  • Summary:

    For practical reasons, we would like to consider certain properties of redefinable elements to be inheritable (or possibly derived from the redefined element).

    For example, if one were to redefine a property, then if the type of a redefining property were not explicitly set, it could inherit (or derive) the type from the redefined property. This would save on space in the serialized model and also help keep the model in a consistent state at all times, if for example the type of the redefined property were to change.

    Currently, there are constraints mentioning that the Type of the redefining property must be 'consistent' with that of the redefined property, any resolution would have to consider modifying such constraints to take redefinition into account.

    Other properties that could be considered inherited would be do/entry/exit actions of a state and, target of a transition amongst others.

    I believe this might be a similar argument to issue 12530.

  • Reported: UML 2.5 — Thu, 10 Jul 2008 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section: 14.3.24, 14.3.20

  • Key: UMLR-144
  • Legacy Issue Number: 12568
  • Status: open  
  • Source: Motorola ( Andrzej Zielinski)
  • Summary:

    Problem 5 5.1 Interactions diagrams shows messages that are type of MessageSort (from Interactions/BasicInteractions, level L1). There is no way to express that a message is an exception. Only signals and calls are expressed. Exception is none of them ++++++++++++++++++++++++++++++++++++++++++ from Bran Selic <bran.selic@gmail.com> hide details Jun 9 to Andrzej Zielinski <072404@gmail.com> date Jun 9, 2008 7:46 PM subject Re: UML 2.x issues mailed-by gmail.com Bran Selic: Agreed

  • Reported: UML 2.1.2 — Thu, 10 Jul 2008 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section: Activities

  • Key: UMLR-140
  • Legacy Issue Number: 12434
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Activity regions and their contents should be redefinable

  • Reported: SysML 1.0 — Fri, 9 May 2008 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML 2.1.2 Super: Execution Specification

  • Key: UMLR-139
  • Legacy Issue Number: 12355
  • Status: open  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    The description for Execution Specification says:

    “An ExecutionSpecification is a specification of the execution of a unit of behavior or action within the Lifeline. The

    duration of an ExecutionSpecification is represented by two ExecutionOccurrenceSpecifications, the start

    ExecutionOccurrenceSpecification and the finish ExecutionOccurrenceSpecification.”

    This sounds right to me. However, the association ends ‘start’ and ‘finish’ are to the more general OccurrenceSpecification, thus:

    “Associations

    • start : OccurrenceSpecification[1]

    References the OccurrenceSpecification that designates the start of the Action or Behavior.

    • finish: OccurrenceSpecification[1]

    References the OccurrenceSpecification that designates the finish of the Action or Behavior.”

    The semantics also refer to OccurrenceSpecification.

    “Semantics

    The trace semantics of Interactions merely see an Execution as the trace <start, finish>. There may be occurrences

    between these. Typically the start occurrence and the finish occurrence will represent OccurrenceSpecifications such as a

    receive OccurrenceSpecification (of a Message) and the send OccurrenceSpecification (of a reply Message).”

    The spec should make the description, association and semantics sections consistent.

  • Reported: UML 2.5 — Tue, 25 Mar 2008 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section: 18.3.3

  • Key: UMLR-136
  • Legacy Issue Number: 12279
  • Status: open  
  • Source: OFFIS e.V. ( Christian Mrugalla)
  • Summary:

    Section 18.3.3 states, that "An ExtensionEnd is never navigable. If it was navigable, it would be a property of the extended classifier". Whereas in section 7.3.3 (Association) on page 43, it is stated that: "Navigability notation was often used in the past according to an informal convention, whereby non-navigable ends were assumed to be owned by the association whereas navigable ends were assumed to be owned by the classifier at the opposite end. This convention is now deprecated. Aggregation type, navigability, and end ownership are orthogonal concepts [...]" The mentioned description in ExtensionEnd seems to contradict the definition of an Association. For the UML Profile Extension Mechanism two issues are essential to be clarified: 1) Is it possible, that an ExtensionEnd (which is owned by the Extension instead of the extended Class) is navigable? 2) Is it possible in a UML-Profile to define an Association which relates a Stereotype with a metaclass and which is navigable on both association ends (if the association end which refers to the stereotype is owned by the association itself instead of by the extended class)? [unidirectional Associations navigable from a stereotype to the extended metaclass seem to be allowed, as exemplified in the SysML 1.0 Standard at page 164]

  • Reported: UML 2.1.2 — Fri, 14 Mar 2008 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

role bindings of a CollaborationUse

  • Key: UMLR-142
  • Legacy Issue Number: 12544
  • Status: open  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    Using a simple Dependency to define the role bindings of a CollaborationUse seems too "light". I suggest to change for a Realization relationship which has a stronger - and i think more convenient - semantic.

  • Reported: UML 2.1.1 — Mon, 23 Jun 2008 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Callout notation for many clients/suppliers

  • Key: UMLR-141
  • Legacy Issue Number: 12511
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    It is allowed that for example a trace relationship has more than one client or supplier. It is unclear how the callout notation looks like for such a relationship.

  • Reported: SysML 1.0 — Tue, 27 May 2008 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Actors cannot own Operations - a contradiction

  • Key: UMLR-149
  • Legacy Issue Number: 12942
  • Status: open  
  • Source: Anonymous
  • Summary:

    The ability for an Actor to implement an Interface was added as a result of this issue against the UML2 specification: http://www.omg.org/issues/uml2-rtf.html#Issue8078

    Because an Actor is now a BehavioredClassifier it can implement interfaces, but according to the UML superstructure specification, Actors cannot own Operations. This situation seems to contradict the semantics for InterfaceRealization (UML Superstructure v2.1.2 section 7.3.25):

    "An interface realization relationship between a classifier and an interface implies that the classifier supports the set of
    features owned by the interface, and any of its parent interfaces. For behavioral features, the implementing classifier will
    have an operation or reception for every operation or reception, respectively, defined by the interface."

  • Reported: UML 2.5 — Wed, 8 Oct 2008 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

18.3.8 Generalization of stereotyped model elements

  • Key: UMLR-150
  • Legacy Issue Number: 13058
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    It is not clear whether it is allowed to have a generalization relationship between two model elements that have different stereotypes. Please clarify in the uml specification

  • Reported: UML 2.2 — Thu, 6 Nov 2008 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

3 3.2 Behavior (CommonBehaviors/BasicBehaviors)

  • Key: UMLR-143
  • Legacy Issue Number: 12566
  • Status: open  
  • Source: Motorola ( Andrzej Zielinski)
  • Summary:

    Problem 3 3.2 Behavior (CommonBehaviors/BasicBehaviors) is having relationship redefinedBehavior, that should be derived

  • Reported: UML 2.1.2 — Thu, 10 Jul 2008 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Notation for ordering action input and output pins

  • Key: UMLR-82
  • Legacy Issue Number: 9400
  • Status: open  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    Input and output pins of an action in an activity are ordered, and their order corresponds to the order of the parameters of actions such as CallOperationAction or CallBehaviorAction. This is the only way pins correlate with their corresponding parameters. A Pin has no direct ownedAttribute that refers to its corresponding Parameter.

    Ordering is sufficient for correlating pins with parameters, but it is difficult to visualize on a diagram. An action may have many input and output pins oriented around the action, and there is no way to visually determine which pin is associated with which parameter. In many cases, the pin name may correspond directly to the parameter name providing a visual connection. However, this is not possible for ActionInputPins or ValuePins where the pin name refers to some structural feature or value specification.

    UML2 should consider a presentation option that shows pins ordered starting from the bottom right corner of the action and following clockwise around the action ending at the right bottom side. The first pin is always the target input pin for a CallOperationAction. The last pin corresponds to the return parameter if any.

    This makes pin ordering visible in the diagrams, and establishes an unambiguous correlation between pins and parameters in call actions. However, it may result in some layout restrictions and extra object flow crossings in diagrams. This should not be much of an issue in practice because the pins can be moved around the edge of the action, just not reordered. And ActionInputPins allow reference to inputs without requiring explicit object flows.

  • Reported: UML 2.5 — Tue, 28 Feb 2006 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

All associations ends in the UML2 metamodel itself should be navigable

  • Key: UMLR-81
  • Legacy Issue Number: 9371
  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    A) All associations ends in the UML2 metamodel itself should be navigable
    The top of section 6.5.2 states that "An association with one end marked by a navigability arrow means that:
    • the association is navigable in the direction of that end,"

    This does not make sense now that navigability has nothing to do with property ownership and is used in effect to indicate a requirement for efficient access.
    However there is no justification for non-navigability in the context of the UML metamodel itself (which is in effect an application model/specification of a UML tool). Given that most users of UML tools would reasonably expect to do 'where used' navigations/queries with reasonable efficiency then there seems to be no reason for having ends owned by Associations being non-navigable. Furthermore OCL and QVT engines would also expect efficient traversal.
    An important case in point is that currently the association end from an Element to its applied Stereotypes is marked 'non-navigable' using the old notation. While there is an argument for not having a property on the Element itself, navigating the association from Element to its applied Stereotypes is an important access that any tool would require to be very efficient (e.g. to allow the tool to display the stereotype name/icon on diagrams where the element appears).
    When UML2 was designed, the arrows were used to mean property ownership only. We should honor that design intent.

    Proposed resolution:
    At top of section 6.5.2 replace:
    "An association with one end marked by a navigability arrow means that:
    • the association is navigable in the direction of that end,
    • the marked association end is owned by the classifier, and
    • the opposite (unmarked) association end is owned by the association.
    With:
    "An association with one end marked by a navigability arrow means that:
    • the marked association end is owned by the classifier, and
    • the opposite (unmarked) association end is an owned navigable end of the association.

    Alternative resolution:
    Redraw all diagrams to not show the deprecated notation of using navigability arrows to indicate ownership.

  • Reported: UML 2.5 — Thu, 23 Feb 2006 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section: Sequence diagrams

  • Key: UMLR-80
  • Legacy Issue Number: 9370
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    A "par"-like operator with two concurrent regions where one region is interrupted when the other is completed. According to me, the only way to express the same semantics today is to use many nested "opt" operators, which is not practical. I am under the impression that this should be quite a common need.

  • Reported: UML 2.0 — Tue, 21 Feb 2006 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Unnecessary restriction on aggregations being binary

  • Key: UMLR-88
  • Legacy Issue Number: 9701
  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    There seems to be no reason why n-ary Associations are required to have aggregation=none: there should be a restriction that this is allowed for at most one End but it could reasonably be allowed

  • Reported: UML 2.5 — Thu, 4 May 2006 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

New issue on notation for multiple stereotypes

  • Key: UMLR-87
  • Legacy Issue Number: 9599
  • Status: open  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Description of Problem

    Section 18.3.8 has the following paragraph:

    Presentation Options If multiple stereotypes are applied to an element,
    it is possible to show this by enclosing each stereotype name within a
    pair of guillemets and listing them after each other. A tool can choose whether it
    will display stereotypes or not. In particular, some tools can choose not to
    display “required stereotypes,” but to display only their attributes (tagged
    values) if any.

    Annex B has the following paragraph:

    If multiple keywords and/or stereotype names apply to the same model element,
    they all appear between the same pair of guillemets, separated by commas:
    “«” <label> [“,” <label>]* “»”

    These two paragraphs seem to contradict each other, since the annex B does
    not allow multiple guillemet pairs for the same element, while 18.3.8 does.

    Proposed Solution:
    Add clarification that Both presentation options should be allowed.

  • Reported: UML 2.5 — Mon, 24 Apr 2006 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Link notation for instance diagrams does not cope with multiple classifiers

  • Key: UMLR-86
  • Legacy Issue Number: 9445
  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    Figure 7.54 of ptc/06-01-02 shows an Instance Diagram notation for a
    Link.
    With the accompanying text:
    "An instance specification whose classifier is an association represents
    a link and is shown using the same notation as for
    an association, but the solid path or paths connect instance
    specifications rather than classifiers. It is not necessary to
    show an underlined name where it is clear from its connection to
    instance specifications that it represents a link and not
    an association. End names can adorn the ends. Navigation arrows can be
    shown, but if shown, they must agree with the
    navigation of the association ends."

    However this does not cater for the fact that the metamodel allows an
    InstanceSpecification to be associated with many Classifiers.

    Proposed resolution:
    Extend the metamodel for Instances to explicitly model Links. For a good
    start see the instances model in the MOF2 Core Abstract Semantics
    chapter (it is not part of MOF - it is only there to explain the
    semantics of MOF in terms of metamodel instances).

  • Reported: UML 2.5 — Wed, 15 Mar 2006 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Guidance for Representing Enumeration Values

  • Key: UMLR-97
  • Legacy Issue Number: 9842
  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    Guidance should be given as to how to use the properties of
    EnumerationLiteral to represent the typical scenario of an
    EnumerationLiteral having a distinct value and meaning e.g. the color
    Blue is represented as the code B or the number 5. In this case I would
    expect the name of the EnumerationLiteral to be "Blue" with an
    associated LiteralString (via inherited property
    InstanceSpecification::specification) of "B" or LiteralInteger of 5. The
    notation for this could be that for default values e.g. Blue = "B" in
    the 'attribute' compartment. Or alternatively the InstanceSpecification
    syntax could be used as per Figure 7.52.

  • Reported: UML 2.5 — Tue, 27 Jun 2006 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section: 15.3.12, p 588, 589

  • Key: UMLR-96
  • Legacy Issue Number: 9840
  • Status: open  
  • Source: Engenuity Technologies, Inc. ( Mikon Dosogne)
  • Summary:

    There are 3 kinds (TransitionKind) of transitions: internal, external and local. Are there firing priorities between these? For example, consider the case of an internal transition within a state and an external transition with same state as its source state, triggered by the same event, with no guard conditions. If that event occurs, which transition(s) will fire? The standard states, "An internal transition in a state conflicts only with transitions that cause an exit from that state," but neither the firing priorities nor the transition selection algorithm define how such a conflict should be resolved.

  • Reported: UML 2.1.1 — Mon, 26 Jun 2006 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Relationships

  • Key: UMLR-95
  • Legacy Issue Number: 9834
  • Status: open  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    Why Transition, ActivityEdge, Message, Connector are not Relationships?
    At least Transition and ActivityEdge should be DirectedRelationships in my opinion.

    If this is done intentionally, please explain, otherwise please register an issue.

  • Reported: UML 2.5 — Tue, 20 Jun 2006 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

ControlNodes in ActivityPartitions

  • Key: UMLR-83
  • Legacy Issue Number: 9401
  • Status: open  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    ControlNodes, like any other ActivityNode or ActivityEdge can be contained in an ActivityPartition. Containment in a partition can be designated either using swimlanes or by denoting the partition names in parenthesis above the ActivityNode name.

    This is generally fine, but can result in significant layout problems when swimlanes are used to designate activity partitions. UML2 does not define any semantics for ControlNodes or ActivityEdges belonging to an ActivityPartition, so they generally do not belong to any partition. When swimlanes are used, the nodes that do not belong in any partition have to be displayed someplace. One convention is to create a default swimlane for these nodes that for example could appear as a partition with the same name as the activity. This results in extreme layout issues as all the control nodes end up being in the same partition resulting in very ugly diagrams with flow lines crossing partitions everywhere. If a user attempts to layout the diagram by moving the control nodes, this results in edits to the underlying model, something that the user may not have intended, or many not have permission to do. Some tools allow editing diagrams on read only models as long as the edits don't result in any changes to the model. This is especially common for diagrams that include views of other models in order to establish a context and show referenced elements.

    Another problem is activity edges which cross many swimlanes while connecting their source and target. It is unclear from the notation in which of these partitions the edge should be included: none of them, all of them, or only the partitions at their connection points.

    UML2 should consider a presentation option or notation convention that ControlNodes and ActivityEdges do not belong to ActivityPartitions unless explicitly shown using the partition name in parenthesis above the node or edge name. Putting a control node or edge in a swimlane should not imply that the node or edge is in the corresponding partitions. The notation should require that these element explicitly state the partitions they belong to.

  • Reported: UML 2.5 — Tue, 28 Feb 2006 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML2: No notation for indicating Operation::raisedException

  • Key: UMLR-85
  • Legacy Issue Number: 9406
  • Status: open  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    Section 7.3.36 specifies the notation for Operation, but there is no notation for denoting raisedExceptions. Section 12.3.41 introduces Parameter::isException and suggests exception parameters are indicated out parameters with

    {exception}

    after the parameter type to indicate Parameter::isException=true.

    However, Operation::raisedException is not a Parameter, it is a reference to a Type. So a raisedException is not a TypedElement like parameter, has no multiplicity or ordering, etc. Raised exceptions are quite different than parameters and even in activities, RaiseExceptionAction and ExceptionHandlers do not exchange exception data through parameters.

    Consider adding <oper-property> ::= 'throws' '('<type-list>')' in section 7.3.36 for denoting exceptions that could be raised by an operation. This is a significant part of the specification of an operation indicating information clients must know in order to use the operation and should be clearly visible in the operation's signature.

  • Reported: UML 2.5 — Wed, 1 Mar 2006 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Reception has no notation for its signal

  • Key: UMLR-84
  • Legacy Issue Number: 9402
  • Status: open  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    There doesn't appear to be any notation of indicating the signal of a Reception. Reception may also be missing a constaint similar to SendSignalAction where the parameters of the BehavioralFeature have to match the ownedAttributes of the Signal in number, order, and type.

  • Reported: UML 2.5 — Tue, 28 Feb 2006 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Unclear usage of LiteralExpression::type

  • Key: UMLR-90
  • Legacy Issue Number: 9703
  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    LiteralExpression inherits a type property but its use, semantics and notation are not documented. There should at least be appropriate constraints e.g. that LiteralString.type is a subtype of PrimitiveTypes::String.

  • Reported: UML 2.5 — Thu, 4 May 2006 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Default value types

  • Key: UMLR-94
  • Legacy Issue Number: 9805
  • Status: open  
  • Source: Eclipse Foundation ( Mr. Kenneth Hussey)
  • Summary:

    The type of a default value should conform to the type of the property/parameter that owns it. Constraints to that effect should be added to the UML specification.

  • Reported: UML 2.5 — Tue, 6 Jun 2006 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section: 7.3.33

  • Key: UMLR-93
  • Legacy Issue Number: 9754
  • Status: open  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Sebastien Gerard)
  • Summary:

    I believe it would be interesting formodelling to be abble to add a feature to the coenpt of NamedElement in order to be abble to define a short name (e.g. an acronym). I propose to add the property: - shortName: String [0..1] the abreviation or acronym assocatied to the NamedElement

  • Reported: UML 2.1.1 — Tue, 23 May 2006 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

ValueSpecification::isComputable()

  • Key: UMLR-91
  • Legacy Issue Number: 9705
  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    ValueSpecification::isComputable() introduces conformance requirements not captured in compliance points.
    Section 7.3.54, Additional Operations states : "A conforming implementation is expected to deliver true for this operation for all value specifications that it can compute, and to compute all of those for which the operation is true. A conforming implementation is expected to be able to compute the value of all literals."

  • Reported: UML 2.5 — Thu, 4 May 2006 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Alternative entry and exit point notation is ambiguous

  • Key: UMLR-32
  • Legacy Issue Number: 7952
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Alternative entry and exit point notation is ambiguous. It is not clear if it relates to an entry point or to an exit point.

  • Reported: UML 2.0 — Mon, 29 Nov 2004 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Coupling between StateMachines and Activities

  • Key: UMLR-31
  • Legacy Issue Number: 7620
  • Status: open  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    As I was reading through the text of issue 6114 it dawned on me that there is a needless and problematic coupling between state machines and activities. Namely, in figure 187, there is an association from ObjectNode to State, presumably to deal with the old "object in state" idea. This is similar to the coupling that was attempted but rejected in the Interactions chapter.

    While it may look attractive to have a formal link to the idea of State from state machines, there are two serious problems that make this much more trouble than it's worth:

    (1) The notion of "object state" – as seen by users/manipulators of that object – could be completely different from the implementation state of that object. This is the old principle of hiding implementation. Viewed from the outside, an invoice object may be in the "Paid" state, but this does not necessarily mean that the object has such a state in its implementation. In fact, there is no guarantee that the implementation will be based on state machines at all. Of course, you can say that this is a reference to some kind of external state machine view of an object – which sounds reasonable, but here is where the second problem comes in:

    (2) State in the UML 2.0 spec comes with a sh..load of baggage: in effect, the whole state machine kit and caboodle. It's not very modular, and, unless you use profiles to shear away all the stuff that you don't want (which is about 99% of state machines machinery), you will force vendors who innocently just want to support the simple idea of "object in state" to implement all of state machines.

    Like I say, the feature doesn't look worth it. Let your State concept be a simple name. My guess is that most users who want to use this feature don't even want to know what a state machine is (the concept of states is not necessarily linked to state machines!).

    So, my suggestion is that in figure 187, you simply provide a subclass of ObjectNode called ObjectInState and give it a "stateName" attribute and you will get what 95% of your users want. Tying state machines to activities for that one little feature seems overkill.

  • Reported: UML 2.5 — Wed, 4 Aug 2004 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Too much navigability from Generalizations

  • Key: UMLR-33
  • Legacy Issue Number: 7997
  • Status: open  
  • Source: Capability Measurement ( Karl Frank)
  • Summary:

    his is a significant issue with the Superstructure, Classes chapter, PowerTypes package, impacting implementability and consistency between products at different levels of conformance to UML 2.

    I propose to simplify the abstract syntax to specify a one way arrow navigating a one-many metassociation from GeneralizationSet to Generalizations that belong to that set. The problem here is very much the same as the problem with dependency, but in a different part of the metamodel.

    Figure 18, The contents of PowerTypes package shows a many-many navigable association between GeneralizationSet.generalization and Generalization.generalizationSet.

    Problems with this:

    1. only 1-way navigation is desired. As toolvendor I don't want to update the Generalization to have any info wrt what if any GeneralizationSets it belongs to. As a user, I do not want the generalization relationship itself, which is very simple in a UML Level 1 product, to be muddied with extra info in a UML product that goes beyond Level 1 by adding support for PowerSets.

    2. only 1-many cardinality is desired. Although not navigable, a mapping from generalization to the generalization set is still provided in the metamodel, in a conceptual sense.

    Point 2 is consistent with thinking of the specialization classifier in the generalization as being an instance of more than one powertype, because this classifier is just a participant in the generalization, it is the generalization that we want to have a mapping to at most one powertype. The scope of the required change is limited to the text and diagram specifying this metasssociation of GeneralizationSet.

  • Reported: UML 2.5 — Wed, 22 Dec 2004 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

ptc-03-09-15/Need for examples to include instance models

  • Key: UMLR-14
  • Legacy Issue Number: 6497
  • Status: open  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    Issue and Recommendation: In general the specification of the Core would
    benefit from instance diagrams accompanying example models, especially in
    cases where there is significant change from UML 1.x. An instance diagram
    accompanying an example model would show how the model instantiates the
    elements of metamodel. This will contribute to a greater level of common
    understanding among readers of the specification and thus will help ensure
    interoperability.

    For example, consider Figure 3-23 from the submission document and which
    defines the abstract syntax for the elements of the
    Core::Constructs::Constraints package. Despite the existence of
    accompanying explanatory text, the distinction between the Namespace that
    owns a Constraint and the Namespace that provides the context for a
    Constraint may be difficult for the reader to grasp completely. Figures
    3-24, 3-25, and 3-26 from the submission document, respectively, provide
    example models. An instance diagram for at least one of the examples that
    shows how the elements of the example model instantiate elements of
    Core::Constructs::Constraints would go a long way toward preventing
    misunderstandings. Such misunderstandings would compromise
    interoperability, since there is a high probability (in my opinion) that
    different implementers would render models to XMI differently.

    This example is only one of many that I could cite from the submission where
    examples plus associated instance diagrams would be beneficial.

  • Reported: UML 2.5 — Fri, 7 Nov 2003 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Conditions for parameter sets

  • Key: UMLR-13
  • Legacy Issue Number: 6487
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Selection behavior on object nodes should be changed to allow execution at insertion time, keeping the queue

  • Reported: UML 2.5 — Fri, 7 Nov 2003 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Clarification of use case semantics

  • Key: UMLR-11
  • Legacy Issue Number: 6445
  • Status: open  
  • Source: Anonymous
  • Summary:

    Use cases and associated sequence and activity diagrams are
    widely used by systems engineers to specify the functionality of the system,
    and describe the interaction between the system and the actors. However,
    there is much confusion regarding use case semantics. Consider the following
    recommendations to clarify use case semantics:
    a) Establish an explicit representation to depict the relationship between a
    use case and its realization as a sequence diagram, activity diagram, etc.
    In addition, allow for a similar representation to show the relationship
    between an included/extended use case, and the interaction fragments which
    realize the included/extended use case.
    b) Clarify the relationship between a use case (solid oval) and a
    collaboration (dashed oval), and determine whether they can represent the
    same or a similar concept.

  • Reported: UML 2.5 — Thu, 6 Nov 2003 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Integration between behavioral "sublanguages": Interactions and Activities

  • Key: UMLR-10
  • Legacy Issue Number: 6441
  • Status: open  
  • Source: Anonymous
  • Summary:

    Although both Sequence Diagrams and Activity Diagrams have
    added many advanced features in UML 2, these features appear to have been
    added independently, so that they appear as two separate behavioral
    languages. Consider improving the integration between them by supporting the
    following:
    a) Allow for an activity in an activity diagram to represent an invoked
    operation in a message on a sequence diagram.
    b) Allow for interaction diagram notations to be applied to activity
    diagrams, such as the use of references, alternates, and gates.
    c) Clarify that time and other constraints can be applied to an activity
    diagram in a manner similar to how they are applied to sequence diagrams.

  • Reported: UML 2.5 — Thu, 6 Nov 2003 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

ptc-03-09-15/Explain the new association modeling constructs

  • Key: UMLR-15
  • Legacy Issue Number: 6498
  • Status: open  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    Issue: The Core’s abstract syntax makes heavy use of new association
    modeling constructs. Two of them in particular may be unfamiliar to many
    who read the submission:
    · Subsets
    · Derived unions

    The submission provides only a brief explanation of these two new
    constructs, which I quote below:

    "A navigable property may be marked as a subset of another, as long as the
    owner of the subsetting property is the same as or a specialization of the
    owner of the subsetted property. In this case, the collection associated
    with an
    instance of the subsetting property must be included in (or the same as) the
    collection associated with the corresponding instance of the subsetted
    property.

    A property may be marked as being a derived union. This means that the
    collection of values denoted by the property in some context is derived by
    being the strict union of all of the values denoted, in the same context, by
    properties defined to subset it. If the property has a multiplicity upper
    bound of 1, then this means that the values of
    all the subsets must be null or the same."

    Recommendation: Since these constructs are so heavily used to define the
    Core itself, it would be useful for the submission to provide some overall
    guidance on how to use them. Providing rationale for why specific ones are
    chosen in specific places in the definition of the Core would be an
    effective way of disseminating understanding of these constructs and
    understanding of the Core as well.

  • Reported: UML 2.5 — Fri, 7 Nov 2003 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

More explanation needed on Figure 339

  • Key: UMLR-3
  • Legacy Issue Number: 6086
  • Status: open  
  • Source: Ostfold University College ( Dr. Oystein Haugen)
  • Summary:

    The Figure 339 on page 425 needs more explanation. The use of lifelines to represent return value, and the notation for interaction occurrences with return value should be explained in greater length. Furthermore it should be made clear how the operations put and get are used to set and read values from lifelines representing attributes and parameters.

  • Reported: UML 2.0 — Fri, 29 Aug 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

More examples

  • Key: UMLR-2
  • Legacy Issue Number: 6083
  • Status: open  
  • Source: Thematix Partners LLC ( Mr. James J. Odell)
  • Summary:

    The Interaction chapter contains a number of examples, but there have been requests for even more examples especially on the different kinds of combined fragments (Section 14.3.1)

  • Reported: UML 2.0 — Fri, 29 Aug 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Promote local conditions to ExecutableNode

  • Key: UMLR-5
  • Legacy Issue Number: 6137
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Promote local precondition to ExecutableNode. There might be other
    associations on Action that should be at ExecutableNode

  • Reported: UML 2.5 — Sat, 30 Aug 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Parameterization of lifelines

  • Key: UMLR-4
  • Legacy Issue Number: 6088
  • Status: open  
  • Source: Ostfold University College ( Dr. Oystein Haugen)
  • Summary:

    In general there is a need to have lifelines as formal parameters such that Interactions can be used in slightly different contexts. This may now be partly achieved through templates, but more notation etc. is needed for this to be really practical.

  • Reported: UML 2.0 — Fri, 29 Aug 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML 2 Super / State machines / Transition triggers cannot be redefined

  • Key: UMLR-9
  • Legacy Issue Number: 6395
  • Status: open  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Transition triggers do not appear to be redefinable in the current metamodel. There does not seem to be any reason for this restriction and it should be removed

  • Reported: UML 2.5 — Fri, 31 Oct 2003 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Join nodes that destroy tokens

  • Key: UMLR-8
  • Legacy Issue Number: 6368
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Would be useful if join nodes optionally destroyed tokens not accepted,
    especially when using join expressions.

  • Reported: UML 2.5 — Mon, 20 Oct 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Deployment a dependency?

  • Key: UMLR-7
  • Legacy Issue Number: 6353
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    If Artifact and Node are classifiers, why is deployment a dependency?
    Then runtime artifacts cannot be deployed to runtime nodes.

  • Reported: UML 2.5 — Mon, 20 Oct 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Notation for method

  • Key: UMLR-6
  • Legacy Issue Number: 6150
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Provide a notation for a behavior used as a method of an operation

  • Reported: UML 2.5 — Sat, 30 Aug 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Conditional Node and Loop Node notation missing

  • Key: UMLR-1
  • Legacy Issue Number: 6071
  • Status: open  
  • Source: CA Technologies ( Andrew Haigh)
  • Summary:

    In 03-07-06 there was notation for conditional nodes and loop nodes for activities. These are missing in 03-08-02. Makes taking the certification difficult

  • Reported: UML 2.5 — Thu, 21 Aug 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section 7.11.2 Association

  • Key: UMLR-12
  • Legacy Issue Number: 6470
  • Status: open  
  • Source: Sparx Systems Pty Ltd ( Mr. J.D. Baker)
  • Summary:

    What is the sematics of an association with neither end navigable? Provide an example of when this might be used. (C to D page 85).

  • Reported: UML 2.5 — Fri, 7 Nov 2003 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML2 Super/Deployment/inheritance

  • Key: UMLR-23
  • Legacy Issue Number: 7227
  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    Deployment should not be a Dependency
    Section 10.3.4, figure 126 show the Deployment subclass of Dependency
    with location subsetting client and deployedArtifact subsetting
    supplier.
    This means in effect that a Node is deemed dependent on the Artifacts
    that are deployed to it which seems to me the wrong way round if
    anything.

    Since it is not really true either that an Artifact is dependent on the
    Node it is deployed to, it does not seem sensible for Deployment to
    inherit from Dependency at all: it should inherit directly from
    DirectedRelationship.

    [Aside: Figure 126 shows 'subsets source' and 'subsets target' which is
    not reflected in section 10.3.4. I had assumed that Dependency would
    itself specify client and supplier to subset/redefine source and target
    but this oddly appears not to be the case]

  • Reported: UML 2.5 — Sun, 11 Apr 2004 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Questions about DataTypes and generalization

  • Key: UMLR-22
  • Legacy Issue Number: 7223
  • Status: open  
  • Source: Red Hat ( Randall Hauch)
  • Summary:

    I have a few questions regarding section 7.12 entitled "Kernel - the
    DataTypes Diagram" in the final adopted Superstructure spec (03-08-02).

    DataType specializes Classifier, and as such it also inherits the ability to
    have generalization relationships with other Classifiers. Classifier has an
    additional operation 'maySpecializeType(Classifier):boolean' that is
    described/defined as follows:

    "The query maySpecializeType() determines whether this classifier may have a
    generalization relationship to classifiers of
    the specified type. By default a classifier may specialize classifiers of
    the same or a more general type. It is intended to be
    redefined by classifiers that have different specialization constraints."
    (p. 63)

    with the OCL:

    Classifier::maySpecializeType(c : Classifier) : Boolean;
    maySpecializeType = self.oclIsKindOf(c.oclType)

    DataType, nor its subtypes PrimitiveType and Enumeration, defines no
    additional constraints or additional operations. These additional
    constraints are executed/applied in the UML2 metamodel (rather than in a
    UML2 model), correct? If so, then this implies that a DataType may
    specialize another DataType, Classifier, Namespace, Type, etc., but that
    DataType may not specialize PrimitiveType or Enumeration. Please correct me
    if I'm interpreting this incorrectly.

    Consider an example with:

    • a PrimitiveType named "string"
    • a PrimitiveType named "float"
    • a DataType named "InternationalPrice" that specializes "float" and
      adds a new attribute/property called "currency" of type "string"

    The "InternationalPrice" DataType is conceptually a qualified type, meaning
    it is a float plus a qualifier of the value. Examples of instances would be

    {426.36, "US Dollars"}

    ,

    {401.23, "Euros"}

    ,

    {749.42, "Yen"}

    .

    If my interpretations of the Superstructure spec are correct, then this
    example cannot be modeled using UML2. And, in fact, the specification would
    actually allow me to create a new PrimitiveType named "double" that actually
    specializes my "InternationalPrice" DataType (since DataType is a supertype
    of PrimitiveType). My thought is that this is either a issue with the
    'maySpecializeType' operation or it is an issue with DataType, PrimitiveType
    and Enumeration not being properly constrained.

  • Reported: UML 2.5 — Tue, 6 Apr 2004 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

missing illustrations of graphical paths for create and destroy messages

  • Key: UMLR-21
  • Legacy Issue Number: 6975
  • Status: open  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Table 15 does not include illustrations for

    • create message (a graphical path flowing into a Lifeline head).
    • create message to lost
    • create message from found

    More illustrations need to be added to Table 15 as the new sorts of messages are added, for example:

    • synch and async create
    • synch and async destroy
  • Reported: UML 2.5 — Mon, 16 Feb 2004 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML 2 Super / Interactions / Ambiguous diagram tags

  • Key: UMLR-20
  • Legacy Issue Number: 6927
  • Status: open  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Diagrams have a frame and a tag that describes the kind of diagram. Most diagrams correspond to a portion of the metamodel, and in most cases there is a one-to-one correspondence between metamodel chapters and diagram types, although variants are allowed for special cases (such as 'package'). There are four kinds of diagrams showing interactions, each with its own unique contents and syntax: sequence diagrams, communications diagrams, interaction overview diagrams, and timing diagrams. Unlike the difference between class diagrams and package diagrams, for example, each of these is very different in appearance and content from the others, even though they allegedly all map to the same interaction model (which might be dubious in practice, given the very different content, but that's another matter). However, the examples all use the same tag, 'sd', for all of the kinds of interaction diagram. Clearly 'sd' is an abreviation for 'sequence diagram' and it is inappropriate for the other types. (The fact that it is an English-language abreviation is another problem that we will let pass for now.) It would seem that each kind of diagram should have its own tag, given that they have different syntax and usage. For example, we could use 'sd', 'cd', 'iod', and 'td' if we wish to keep the same abbreviated format. But in any case the tags should be different and they should be descriptive of the diagram, not the underlying modeling chapter. (The official tag for interaction diagrams as a group is 'interaction', not 'sd' (page 589), so 'sd' is already descriptive of just one variant.)

    If the argument is that you can tell apart the different variants of interaction diagram by looking at them, that argument would apply with even more force to the diagrams for different kinds of models, such as class diagrams, state machine diagrams, etc., so we wouldn't need tags at all. (Which may be true, and users will probably not bother most of the time, but let's at least get it right in the standard.)

  • Reported: UML 2.5 — Fri, 23 Jan 2004 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Redefinitions of OCL constraints must be aligned with MOF2.0/UML2.0 class R

  • Key: UMLR-19
  • Legacy Issue Number: 6922
  • Status: open  
  • Source: Fraunhofer FOKUS, Germany ( Michael Soden)
  • Summary:

    Redefinitions of OCL constraints must be aligned with MOF2.0/UML2.0 class Redefinition. I could not find any detailed information with respect to redefinition of (especially OCL class OclExpression) constraints in the docs ptc/03-09-15, ptc/03-10-04. A more precise semantic would help for the QVT redefinitions w.r.t patterns and technology mappings interoperability (JMI <> MOF2IDL alignment).

    Proposed resolution: It would be useful to add more precise abstract semantic for redefinition contexts of constraints (e.g. class 'Constraint' should specify that redefinition context must also be inheritance)

  • Reported: UML 2.0 — Mon, 19 Jan 2004 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML 2 Infrastructure / rule for redefinition of Property

  • Key: UMLR-18
  • Legacy Issue Number: 6878
  • Status: open  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The isConsistentWith() query defined on Property implies that in order for a property redefinition to be logically consistent, the redefining property must be derived if the redefined property is derived. Are these the correct semantics for redefinition? There are cases in the metamodel where this constraint is violated (e.g. Package::ownedMember is not derived, but it redefines derived property Namespace::ownedMember). If there is to be a constraint on redefinition, perhaps it makes more sense the other way around, i.e. a redefining property must be non-derived if the redefined property is non-derived.

  • Reported: UML 2.5 — Fri, 2 Jan 2004 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

inconsistency in the action model

  • Key: UMLR-27
  • Legacy Issue Number: 7337
  • Status: open  
  • Source: Missouri University of Science and Technology ( Thomas Weigert)
  • Summary:

    There is an inconsistency in the action model between actions for StructuralFeatures in general, and actions operating on links. The family of structural feature action, such as WriteStructuralFeatureAction, are defined for any kind of structural feature. Consequentially, these actions can manipulate values that are not due to attributes or assication ends (both special cases of Property) but of any kind of StructuralFeature. However, actions defined for links can only operate on links that are due to associations in the model. This because LinkEnd is identified through the association to a Property (named "end"). However, there are other links in the model, such as those due to Connectors. To make these consistent, one either should limit the structural feature actions to apply to Properties (rather than StructuralFeatures), or one should generalize the link actions to apply to liks identified by any StructuralFeature, not just to links identified by Properties. This difference in generality does, of course, not matter for the UML as defined, but it could hamper the deployment of actions to profiles that define other kinds of links. (This is, luckily, not a problem for links due to Connectors, as we can argue that for links due to connectors that are not explicitly typed, these are identified by the ends of the derived associations.)

  • Reported: UML 2.0 — Sat, 15 May 2004 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

large overlap between structural features and variables

  • Key: UMLR-26
  • Legacy Issue Number: 7329
  • Status: open  
  • Source: Missouri University of Science and Technology ( Thomas Weigert)
  • Summary:

    There is large overlap between structural features and variables. For example, examine the structural features actions and compare them to variable action. Upon study, one will discover that structural features and variables have much more in common. In fact, the following equation seems to hold: StructuralFeature = Variable + Feature That is: a variable denotes a location able to hold an instance. A structural feature is a feature of an object and denotes a location ale to hold an instance. Therefore, I suggest that StructuralFeature be made a subtype of Variable. In the infrastructure, variable would have no interpretation, other than being an abstract metaclass indicating the ability to hold a value. In the superstructure, variable is concrete as described in Activities. Not only would this allow to eliminate the duplication of actions related to accessing variables, but also, other duplications (as, e.g., with respect to their being connectable elements and the related explanations) could be avoided.

  • Reported: UML 2.0 — Sun, 9 May 2004 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML 2.0 Superstructure Kernal/Packages

  • Key: UMLR-17
  • Legacy Issue Number: 6645
  • Status: open  
  • Source: TimeWarp Engineering Ltd. ( Steven Cramer)
  • Summary:

    The Property ownedMember of the Class Package is redefined to specialize the EndType from NamedElement to PackageableElement. But is incorrectly changed from a derived union to NON Derived. If it is intended to be non derived the property string subsets on all the other members are in error.

    ownedMember for a Package should be a derived union subset by the following Properties:

    ownedType

    nestedPackage

    ownedRule

    An OCL equivalent would be as follows:

    ownedMember=ownedType->union(nestedPackage)->union(ownedRule)

  • Reported: UML 2.5 — Wed, 1 Oct 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

freeing namespace

  • Key: UMLR-16
  • Legacy Issue Number: 6624
  • Status: open  
  • Source: XTG, LLC ( Joaquin Miller)
  • Summary:

    I know ODP is <adjective>, so i'd like to add mention of a couple of other places where we will find name space standing on its own, and not conflated with package or other container.

    An IETF namespace is exactly "a set of terms usable as names."

    As Karl reminded me, a C++ name space is also "a set of terms usable as names," declared with the keyword 'namespace' and used with the keywords 'using namespace' (providing a naming context) or with the scope operator, '::' (converting a simple name to a name that is an identifier).

    [Unlike most Java tools, there is no requirement that the things in a C++ namespace all be in any particular container. Karl tells me that C++ programmers he works with don't like the way Java tools insist that a package-cum-namespace be identified with a directory that contains all elements of that package. (Of course, tools that do that are following "the extremely simple example" in The Java Language Specification. Sometimes the effect of simple examples on the future of the world.) It can be fine to have such simplifications in a programming language, but it's good to have more flexibility in models.]

    C++ also provides a form for aliases:
    namespace new_name = current_name ;

    Still more flexible is that other approach, which in addition to distinguishing name space from naming context, also allows the same item to have fully qualified names from different namespaces. If that's in MOF, let's use it. (Is that accomplished the relaxing, which MOF 2 package import provides? (If i import C from Pa into Pb, can i identify it with 'Pb::C'?))

    If not, let's put it there.

    Seems to me to be easy to accomplish, if Namespace is first class.

  • Reported: UML 2.5 — Mon, 17 Nov 2003 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

metaattribute isReadOnly

  • Key: UMLR-28
  • Legacy Issue Number: 7338
  • Status: open  
  • Source: Missouri University of Science and Technology ( Thomas Weigert)
  • Summary:

    The metaattribute isReadOnly is defined both for StructuralFeature and its subclass Property. Clearly, one or the other is incorrect. This, I believe, points to an unclarity in what StructuralFeatures are, as opposed to Property. By definition, StructuralFeatures denote values that are held in slots of an object. I believe that the intuition behind Property is that a property denotes a value that might be added, modified, or deleted during the course of the lifetime of a system. This is exemplified in the two variants of property: attribute and association end. As "isReadOnly" has to do with limiting the modification of the value, it is best placed on Property, assuming this intuition is correct. This intuition is substantiated by that Port is not a property but a structural feature, and ports cannot be modified, changed, or assigned to. (Note that if this intuition is not correct, the difference between Property and StructuralFeature needs to be clarified.) A consequence of this is also that one needs to clarify the set of actions that apply to StructuralFeatures (e.g., WriteStructuralFeatureAction). If it is Properties that are modified, etc., then these actions should really apply to properties, not structural features in general. Again, this change is consistent, as none of these actions makes sense for Ports. Further, for links the actions are already limited to properties (see LinkEndData). An issue regarding the inconsistency between actions applying to structural features and actions applying to links has been submitted and should be dealt with consistently.

  • Reported: UML 2.0 — Sat, 15 May 2004 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Priority of the joint transition

  • Key: UMLR-25
  • Legacy Issue Number: 7255
  • Status: open  
  • Source: ISTI-CNR ( Franco Mazzanti)
  • Summary:

    The specification says that: "The priority of joined transitions is based on the priority of the transition with the most transitively nested source state". Suppose that a join transition is has two transitions with source states at the same depth, but in two different regions. How is is established which of the two transition defines the priority of the join transition?. Notice that, depending on which transition is choosen, different other transitions might be allowed or disallowed to be fired. Some possible anwers are: - Any of the two transitions can be chosen statically. (i.e. the priority of the join transition always remains the same). - Any of the two transitions can be chosen, and the choice truly, completely nondeterministic (hence possibly dynamic) I.e. the priority of the join transitions can change each time the join transition is fired.

  • Reported: UML 2.5 — Wed, 21 Apr 2004 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

surface notation for state machines

  • Key: UMLR-29
  • Legacy Issue Number: 7372
  • Status: open  
  • Source: Missouri University of Science and Technology ( Thomas Weigert)
  • Summary:

    The surface notation for state machines allows to show, on the line representing a transition, certain key actions that will be performed by the behavior associated with the transition. This is straightforward, when the behavior is an activity (as those actions can be referenced). However, for any other behavior, e.g., an opaque behavior, we need a method of (in the metamodel) show that this behavior does contain certain actions. Note that this should not give an alternative way of defining sequences of actions; rather, this should merely state that this behavior will contain the exhibited actions but it may contain many more. Those actions would merely give a means of representing the graphical constructs in the metamodel

  • Reported: UML 2.0 — Mon, 24 May 2004 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML2 Super/Deployments/Manifestation

  • Key: UMLR-24
  • Legacy Issue Number: 7229
  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    Manifestation should inherit from Realization

    In Section 10.3.10 and Figure 124 it would make more sense for
    Manifestation to inherit from Realization rather than directly from
    Abstraction. The semantics of Realization are described as "A
    Realization signifies that the client set of elements are an
    implementation of the supplier set,.." which surely includes
    manifestation.
    The spec also states that Realization may be used to model
    transformations, which fits with the example given in Manifestation:
    "<<tool generated>> and <<custom code>> might be two manifestations for
    different classes".

    BTW There is a missing word in the description of Manifestation "A
    manifestation is the concrete physical of one or more model elements by
    an artifact."

  • Reported: UML 2.5 — Sun, 11 Apr 2004 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Provide exception handling for all behaviors.

  • Key: UMLR-30
  • Legacy Issue Number: 7398
  • Status: open  
  • Source: Missouri University of Science and Technology ( Thomas Weigert)
  • Summary:

    UML2 has added the capability of dealing with exceptional behavior. Exception handling can occur at various levels of the model. Unfortunately, the exception handling mechanism has not been systematically developed. Any kind of behavior should support the mechanism of catching and handling an exception that was raised somewhere within that behavior. Unfortunately, currently only activities allow for this. Similar capabilities should be available for interactions and statemachines, and even for use cases. Recommendation: Provide exception handling for all behaviors.

  • Reported: UML 2.0 — Sun, 30 May 2004 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT