${taskforce.name} Avatar
  1. OMG Task Force

UML 2.6 RTF — All Issues

  • Key: UMLR
  • Issues Count: 823
Open Closed All
All Issues

Issues Summary

Key Issue Reported Fixed Disposition Status
UMLR-845 The XMI for the little *Home" example is not well-formed UML 2.5.1 open
UMLR-841 Multiplicity of Operation::returnResult() should be [0..1], i.e. not multivalued UML 2.5.1 open
UMLR-842 UMLR-673, reported for UML 2.5, still isn't fixed in 2.5.1 UML 2.5.1 open
UMLR-673 Spec refers to TypeElement twice. Should be TypedElement UML 2.5 open
UMLR-844 Constraint "input" of ParameterSet assumes owner is always a BehavioralFeature UML 2.5.1 open
UMLR-843 PropertyTemplateParameter in description of constraint "binding_to_attribute" UML 2.5.1 open
UMLR-840 Parameters of a ParameterSet should be ordered UML 2.5.1 open
UMLR-837 Suggested improvement to description of "BehavioralFeature::isDistinguishableFrom()" UML 2.5.1 open
UMLR-839 Suggestion for improved wording of description for attribute "isDisjoint" UML 2.5.1 open
UMLR-838 Allow method bodies for abstract BehavioralFeatures UML 2.5.1 open
UMLR-696 The behavior of an OpaqueExpression should be allowed to have input parameters UML 2.5 open
UMLR-836 Behavior and ordering of Parameters in OpaqueExpression UML 2.5.1 open
UMLR-835 InformationItem specified as a concrete Class, but it is abstract according to its constraint "not_instantiable" UML 2.5.1 open
UMLR-834 Grammatical improvement is needed in the descriptions (p. 342) UML 2.5.1 open
UMLR-833 Simplification of Stereotypes Usage<--Create and Usage<--Instantiate UML 2.5.1 open
UMLR-832 Missing extends arrow in diagram UML 2.5.1 open
UMLR-831 Unclear wording about Stereotypes and ownership of their Properties UML 2.5.1 open
UMLR-830 Typo in the hyperlink for "Normative URL" UML 2.5.1 open
UMLR-829 Missing constraints for class Interval UML 2.5.1 open
UMLR-828 TemplateParameter placeholder names? UML 2.5.1 open
UMLR-827 UMLR-826 is a non-issue UML 2.5.1 open
UMLR-826 Stereotype must be owned by a Profile, but shows composition relationship to Package UML 2.5.1 open
UMLR-825 ConnectableElement is not defined until section 11, but Parameter (defined in section 9) inherits ConnectableElement and needs to see its definition UML 2.5.1 open
UMLR-824 Suggestion: Generalization::isSubstitutable() should return "Boolean = false" and not "Boolean [0..1]" UML 2.5.1 open
UMLR-823 Redundant association from Classifier to NamedElement at bottom of diagram UML 2.5.1 open
UMLR-822 Ambiguity of operation "Classifier::general()" and association end "/general" UML 2.5.1 open
UMLR-821 Multiplicity of composition/aggregation end for many different elements with {subsets owner} should be 1 and not 0..1 UML 2.5.1 open
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
UMLR-757 Make AssociationClasses unique again UML 2.5 open
UMLR-443 UML 2.5 issue. AssociationClasses should have isUnique property UML 2.5b1 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-480 Can passive classes have ClassifierBehaviors? UML 2.4.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
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-741 Are two identical bound templates the same? 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-542 Figure 12-15 (MOF Model Equivalent …) p.284 - MOF Model Equivalent navigation and ownership incorrect UML 2.4.1 open
UMLR-234 UML Interactions: Misleading suggestion of relationship between Interactions and Activities modeling UML 2.5 open
UMLR-582 What is a DurationInterval UML 2.4.1 open
UMLR-584 What is a DurationInterval UML 2.4.1 open
UMLR-438 Observations in TimeExpressions UML 2.5b1 open
UMLR-450 UML 2.5: Time Observation and Duration Observation problem UML 2.5b1 open
UMLR-740 DecisionNode is missing a constraint on incoming edges UML 2.5 open
UMLR-437 What is the abstract syntax for Figure 17.27? UML 2.5b1 open
UMLR-433 What is a UML diagram? is it restricted to showing elements that are instances of the M2 UML metamodel and nothing else? UML 2.5b1 open
UMLR-306 How to access a token value in a guard? UML 2.5 open
UMLR-428 Guard evaluation with decision input UML 2.5b1 open
UMLR-711 Conflicting constraints UML 2.5 open
UMLR-471 Allow a notation to allow for a default assignment of a decision to the owner of the activity UML 2.5b1 open
UMLR-528 Location: Figure 15-43 ActivityFinalNode example - Balancing Decision / Merge UML 2.4.1 open
UMLR-530 Location: Page 413, 15.3.2 Abstract Syntax Control Nodes Figure 15-26 UML 2.4.1 open
UMLR-243 Restrictions on decision nodes UML 2.5 open
UMLR-668 Unspecified and inconsistent notation for Observations UML 2.5 open
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-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-431 problems with BehavioralFeature::method UML 2.5b1 open
UMLR-488 Interaction parameters. UML 2.4.1 open
UMLR-489 How should context be represented? UML 2.4.1 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-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-666 Sequence Diagram Message Numbers 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-662 What are the type/classifiers of an InstanceValue 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-449 Contradiction between the abstract syntax and semantics of an Interval UML 2.5b1 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
UMLR-619 Class.isAbstract attribute is not necessary UML 2.5 open
UMLR-429 Missing glossary UML 2.5b1 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
UMLR-427 7.2.3, last sentence 2nd paragraph the revised text UML 2.5b1 open
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
UMLR-617 Location: 18.1.5 Examples Figure 18-2. 689 - Explain about Navigation UML 2.4.1 open
UMLR-616 UML 2.5: UML redefinition mechanism insufficiently granular UML 2.5 open
UMLR-505 Location: 18.2 Classifier Descriptions Use Case Constraints. 697 - Need stricter limit on associations UML 2.1.2 open
UMLR-504 Location: 18.2 Classifier Descriptions Extend Constraints. 695 - Constraint is overly restrictive UML 2.4.1 open
UMLR-502 Location: 18.1.4 Notation P. 688 - Can Use Cases have attributes and operations? UML 2.4.1 open
UMLR-503 Location: 18.2 Classifier Descriptions Use Case Constraints. 697 - Need stricter limit on associations (02) UML 2.1.2 open
UMLR-496 Location: Figure A.5 P. 734 - Use Cases are not behavior diagrams UML 2.4.1 open
UMLR-497 Location: Appendix A, list of frame names, p 734 - List of Namespaces suitable for diagram headers is overly restrictive UML 2.4.1 open
UMLR-500 Location: 18.1.1 Summary p 685 - Bases of specialized stereotypes UML 2.4.1 open
UMLR-501 Location: 19.5 Classifier Descriptions Deployment Specification Attributes P. 711 - Why a multiplicity of [0..1] UML 2.4.1 open
UMLR-498 Location: 22.3 Standard Stereotypes «Metamodel» p. 731 - «Subsystem» should be allowed for more classifiers UML 2.4.1 open
UMLR-499 Location: 19.5 Node Association Ends Node P. 714 - Shared ownership of nodes UML 2.4.1 open
UMLR-506 Location: 18.2 Classifier Descriptions Extend Constraints. 695 - Extensions must be a DAG UML 2.4.1 open
UMLR-495 Location: Figure B.3. 737 - A diagram is a PackageableElement UML 2.4.1 open
UMLR-568 Reword isComputable UML 2.4.1 open
UMLR-569 Location: 8.6 p 98 TimeObservation ...simplify UML 2.4.1 open
UMLR-576 Too many alls UML 2.4.1 open
UMLR-575 Intended to Produce UML 2.4.1 open
UMLR-577 Bad Description, observation has no value UML 2.4.1 open
UMLR-580 Like to overridden definition UML 2.4.1 open
UMLR-573 Why can’t the operand be a stringExpression UML 2.4.1 open
UMLR-578 Range Confusion UML 2.4.1 open
UMLR-570 Simplify (Location: 8.6 p 97 TimeExpression) UML 2.4.1 open
UMLR-574 Bad Description UML 2.4.1 open
UMLR-571 Simplify UML 2.4.1 open
UMLR-572 What incompatible about sub-expressions and operands UML 2.4.1 open
UMLR-434 PrimitiveTypes::Real is inconsistently specified relative to its mapping to xsd:double UML 2.5b1 open
UMLR-436 No explanation of how to deal with conflicting transitions of equal priority UML 2.5b1 open
UMLR-435 Definition of allOwningPackages() UML 2.5b1 open
UMLR-430 Several UMLDI redefining associations are invalid UML 2.5b1 open
UMLR-442 UseCases: Explanation of words “fragment” and “increment” UML 2.5b1 open
UMLR-445 Behavior does not override NamedElement::isDistinguishableFrom() like BehavioralFeature does UML 2.5b1 open
UMLR-426 Uml2.5 issue - constraints of Behavior incorrectly assume context is always non-null UML 2.5b1 open
UMLR-432 Add condition : Constraint[0..1] to the include relationship UML 2.4.1 open
UMLR-439 Timing Events Question / Issue UML 2.5b1 open
UMLR-441 The notation for ExtensionPoint provides for an “explanation”, but the metamodel provides nowhere to store it. UML 2.5b1 open
UMLR-440 UseCases: no way for an Extend to pick out individual ownedBehaviors of the extending UseCase UML 2.5b1 open
UMLR-595 Definition of invariant condition UML 2.4.1 open
UMLR-597 Section Unbalanced UML 2.4.1 open
UMLR-592 Need table correlating Literals with symbols (+,-,#,~) UML 2.4.1 open
UMLR-593 Inconsistent use of (s) UML 2.4.1 open
UMLR-601 Section 11.7 has no content or notation for template Collaborations Clause - 11: Structured Classifiers UML 2.4.1 open
UMLR-603 Section 11.3.4 isService clarification - Clause 11: Structured Classifiers UML 2.4.1 open
UMLR-596 Descendants rather than specializations UML 2.4.1 open
UMLR-602 Section 11.2.4 clarification - Clause 11: Structured Classifiers UML 2.4.1 open
UMLR-600 List attributes whose ordered property has change in UML 2.5 UML 2.4.1 open
UMLR-598 Bound Element Semantics overly specific UML 2.4.1 open
UMLR-599 UML 2.5 FTF issues for Clause 18: UseCases UML 2.4.1 open
UMLR-594 Template Notation example UML 2.4.1 open
UMLR-615 Clarification on the semantics of CommunicationPath UML 2.4.1 open
UMLR-614 isIntegral() UML 2.4.1 open
UMLR-613 Capitalization of dependency UML 2.4.1 open
UMLR-470 Profile: can a stereotype extend fewer metaclasses than another stereotype it specializes? UML 2.5b1 open
UMLR-469 Clarification re MOF Equivalent Semantics about defining/applying a stereotype to a slot of ininstance of a stereotype UML 2.5b1 open
UMLR-476 Node::nestedNode should subset Class::nestedClassifier, not Namespace::ownedMember. UML 2.4.1 open
UMLR-477 Meaning of State in ProtocolStateMachines UML 2.4.1 open
UMLR-479 Should “completion” event be an explicit event type? UML 2.4.1 open
UMLR-481 Not clear if “else” keyword is defined for State Machines UML 2.4.1 open
UMLR-482 State of the substates of the history state UML 2.4.1 open
UMLR-475 UML: No restrictions on what seem to be meaningless associations UML 2.5b1 open
UMLR-473 It is a pity that UML does not provide the ability for Messages to correspond directly to property accesses and updates UML 2.4.1 open
UMLR-472 Need packages overview diagram and explicit depiction of package dependencies UML 2.5b1 open
UMLR-474 Meaning of absent multiplicity notation UML 2.4.1 open
UMLR-478 Figure 14.39 – missing superclass UML 2.4.1 open
UMLR-517 Not clear when to use ExecutionOccurrenceSpecification with ExecutionSpecification UML 2.4.1 open
UMLR-518 Location: Pg. 617, Figure 17.4.4: Notation, Sub-clause: Message UML 2.4.1 open
UMLR-508 18.1.3 Semantics Use Case and Actors Extends P. 687 - No Alternative Path UML 2.4.1 open
UMLR-509 18.1.3 Semantics Use Case and Actors Extends P. 687 - First ExtensionPoint UML 2.4.1 open
UMLR-513 Location: 18.1.3 Semantics Use Cases and Actors P. 686 - What classifiers can be a subject? UML 2.4.1 open
UMLR-516 Location: 18. Global - No discussion of use case instances UML 2.4.1 open
UMLR-511 Location: 18.1.3 Semantics Use Cases and Actors P. 686 - Multiplicity at Use Case end UML 2.4.1 open
UMLR-510 18.1.3 Semantics Use Case and Actors Extends P. 687 - Show name of extension UML 2.4.1 open
UMLR-514 Location:Page #640, 17.8.2 Example Sequence Diagram UML 2.4.1 open
UMLR-512 Location: 18.1.3 Semantics Use Cases and Actors P. 686 - Multiple subjects require the same actors UML 2.4.1 open
UMLR-507 18.1.3 Semantics Use Case and Actors Extends P. 687 - Single Location UML 2.4.1 open
UMLR-515 Location: weak sequencing p. 622 UML 2.4.1 open
UMLR-585 What is a DurationConstaint UML 2.4.1 open
UMLR-586 Time constant UML 2.4.1 open
UMLR-579 More detail on Express UML 2.4.1 open
UMLR-590 Expression examples unclear UML 2.4.1 open
UMLR-588 OCL not indexed UML 2.4.1 open
UMLR-591 Semantics Clarification UML 2.4.1 open
UMLR-587 Event UML 2.4.1 open
UMLR-581 incompatible multiplicities UML 2.4.1 open
UMLR-583 one -- > first UML 2.4.1 open
UMLR-589 Orphan Title UML 2.4.1 open
UMLR-425 typo in 12.2.3 Model UML 2.5b1 open
UMLR-521 Location: Pg. 613, Figure 17.6 - : Incorrect multiplicities in the metamodel in Figure 17.6 UML 2.4.1 open
UMLR-522 Location: p 611 UML 2.4.1 open
UMLR-524 Not clear when to use ExecutionOccurrenceSpecification with ExecutionSpecification UML 2.4.1 open
UMLR-529 Location p413 Final Node - Rollback behavior UML 2.4.1 open
UMLR-532 Location p413 Final Node - Atomic behavior UML 2.4.1 open
UMLR-519 Location: 17.3.4 Notation Lifeline p 613 - Specification of color UML 2.4.1 open
UMLR-520 Location: Pg. 613, Figure 17.6 - Incorrect multiplicities in the metamodel in Figure 17.6 UML 2.4.1 open
UMLR-525 Interactions p 607 UML 2.4.1 open
UMLR-523 Location: 16.2.3 Semantics / Opaque Actions UML 2.4.1 open
UMLR-527 Location: Figure 15.67 page 436 UML 2.4.1 open
UMLR-526 Location: p 504 - Marshall Actions UML 2.4.1 open
UMLR-606 Inconsistent approach to type conformance UML 2.5b1 open
UMLR-608 Issue for UML 2.5 FTF against Clause 9: Classifiers UML 2.4.1 open
UMLR-604 "Object identity" undefined UML 2.5b1 open
UMLR-605 Consistent use of "conforms to" vs. "is a subtype of" UML 2.5b1 open
UMLR-455 Notation for Variables and Variable Actions is very vague and incomplete UML 2.5b1 open
UMLR-452 Rg. Realization and InterfaceRealization UML 2.5b1 open
UMLR-444 Clarification needed about the semantics of stereotype specialization and stereotype application UML 2.5b1 open
UMLR-451 Issue for Figure 17.18 UML 2.5b1 open
UMLR-448 Clarification about Interactions owning Actions and about the semantics of Actions owned by Interactions UML 2.5b1 open
UMLR-453 [UML 2.5] Redundancy in the definition of use case extensions UML 2.5b1 open
UMLR-456 Issue with Reply message in interactions (UML 2.5 Beta) UML 2.5b1 open
UMLR-447 Incorrect notation in figure 14.37 UML 2.5b1 open
UMLR-446 Shouldn't Gate and InteractionFragment be redefinable to support Interaction specialization? UML 2.5b1 open
UMLR-454 UML 2.5 - figures 14.37 and 14.38 use incorrect notation for keyword UML 2.5b1 open
UMLR-557 Location: Page 265, 12.2.3 Semantics - Unchanged URIs UML 2.4.1 open
UMLR-555 Location: 12.2.3 Semantics Package p 265 - Reference to unknown section heading UML 2.4.1 open
UMLR-566 Location: 9.6.4 Notation p 127 Missing Infix operation syntax / discussion UML 2.4.1 open
UMLR-567 ParameterSet Notation UML 2.4.1 open
UMLR-561 Location: constraints class_behavior p.190 UML 2.4.1 open
UMLR-562 Location 10.3.3 Receptions p.186 - exceptions for receptions? UML 2.4.1 open
UMLR-563 p 118: isException and other outputs UML 2.4.1 open
UMLR-560 Location: Constraints p 193 - All feturs must be public? UML 2.4.1 open
UMLR-564 Location p 162 ParameterSet associationends: Exceptions and parametersets UML 2.4.1 open
UMLR-558 Location: 12.1 Packages Summary p 264 UML 2.4.1 open
UMLR-559 Location: Figure 11-5 (ii) p 204 UML 2.4.1 open
UMLR-565 Query of alternative scopes? UML 2.4.1 open
UMLR-486 Problems with XMI IDs in the UML 2.5 UML.xmi file UML 2.4.1 open
UMLR-487 17 Semantics of interactions UML 2.4.1 open
UMLR-490 UML Interactions do not provide the ability for Messages to correspond directly to property accesses and updates UML 2.4.1 open
UMLR-493 Location: B.6 UML ProfileDiagrams . 768 - Profile Diagram Elements UML 2.4.1 open
UMLR-492 Location: B.6 UMLClass Diagram P. 757 - Class namespace diagrams? UML 2.4.1 open
UMLR-483 Overriding deferred events UML 2.4.1 open
UMLR-484 Stable state not needed UML 2.4.1 open
UMLR-491 Location: Annex C Keywords P. 778 - Inconsistent metaclass keywords UML 2.4.1 open
UMLR-485 Default entry if default history transition missing UML 2.4.1 open
UMLR-494 Location: B.2.2 P. 738 - What ISO document UML 2.4.1 open
UMLR-549 Location: Page 270/271, 12.2.3 Semantics - Model description confusing UML 2.4.1 open
UMLR-550 Location: Page 269, 12.2.3 Semantics - Association merge aggregation constraint is property rule UML 2.4.1 open
UMLR-545 Location: Page 286, 12.3.3 Semantics - Incorrect if statement UML 2.4.1 open
UMLR-544 Location: Page 285, 12.3.3 Semantics - Old behavior unnecessarily preserved UML 2.4.1 open
UMLR-552 Page 269, 12.2.3 Semantics - Property merge transformation conflicts with constrain UML 2.4.1 open
UMLR-553 Location: Page 267, 12.2.3 Semantics - Type and TypedElement confusion UML 2.4.1 open
UMLR-556 Location: Page 265, 12.2.3 Semantics PackageMerge - Long-winded package merge description UML 2.4.1 open
UMLR-546 Location: Page 281, 12.3.3 Semantics - Duplicated text UML 2.4.1 open
UMLR-554 Page 266, 12.2.3 Semantics - Un-matched resulting elements aren't always the same UML 2.4.1 open
UMLR-548 Location: Page 280, 12.3.3 Semantics - Note should be main text UML 2.4.1 open
UMLR-551 Location: Page 269, 12.2.3 Semantics - Property merge rule pointless UML 2.4.1 open
UMLR-547 Location: Page 280, 12.3.3 Semantics - Poorly indented XMI UML 2.4.1 open
UMLR-460 UML2.5: Clarification about UML profiles UML 2.5b1 open
UMLR-458 Serilaization of required stereotypes UML 2.5b1 open
UMLR-459 Reply messages now mandatory? UML 2.5b1 open
UMLR-466 Semantics of TimeConstraints and DurationConstraints UML 2.5b1 open
UMLR-461 Notation for DurationObservation with two event elements UML 2.5b1 open
UMLR-464 Semantics of Namespaces UML 2.5b1 open
UMLR-467 Stereotype for extended bound element realization UML 2.5b1 open
UMLR-462 Interactions and parameter assignments UML 2.5b1 open
UMLR-468 Please provide running footers or headers indicating the section/subsection of a page UML 2.5b1 open
UMLR-463 Semantics of Message argument mapping in Interactions UML 2.5b1 open
UMLR-457 UML2.5 issue: constraints needed in model of Standard Profile UML 2.5b1 open
UMLR-465 Meaning of access to constrainedElements UML 2.5b1 open
UMLR-543 Location: Page 286, 12.3.3 Semantics - Nonsensical alternative to stereotype name UML 2.4.1 open
UMLR-531 Location: p 410 UML 2.4.1 open
UMLR-537 Location: Page 328, 14.2.3 - UseCase cannot be the context of a StateMachine UML 2.4.1 open
UMLR-536 Location: Signal Receipt symbol UML 2.4.1 open
UMLR-534 Location: Page 346, State List Notations - Why must state lists be effect free? UML 2.4.1 open
UMLR-538 Location: 13.3.5 Examples p 314 UML 2.4.1 open
UMLR-540 Location: Opaque and Function Behaviors p 308 UML 2.4.1 open
UMLR-533 Location: p. 336 Compound transitions - Run-to-completion Paradigm UML 2.4.1 open
UMLR-539 Location: Page 316 redefinedBehavior - Extends UML 2.4.1 open
UMLR-535 Location: Page 331 deep history entry - Default deep history entry UML 2.4.1 open
UMLR-541 Location: Figure 12-13 p.281 - Incorrect use of << for «. UML 2.4.1 open
UMLR-347 UML 2.5 Beta 2 XMI invalid UML 2.5 open
UMLR-610 How to model a transition to history pseudostates in two orthogonal regions? UML 2.4.1 open
UMLR-612 Clarification on the semantics of inheritance between use cases UML 2.4.1 open
UMLR-607 Clarify aliasing in Namespaces UML 2.5b1 open
UMLR-609 Clarify ownership vs. membership for NamedElements UML 2.5b1 open
UMLR-611 Fuzzy diagrams UML 2.5b1 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

The XMI for the little *Home" example is not well-formed

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

    In section 12.3.3.1.3 "MOF-Equivalent Semantics", the XMI given for the little "Home" example (starting at the end of page 298 and continuing to page 299) is broken. Some XML attribute values are not quoted at all, and many of the quote marks are "smart" (AKA "fancy") quotes, causing well-formedness checks to fail.

    The longer example beginning on page 310 passes well-formedness checks. Both were tested in the opensource "XML Copy Editor" tool.

  • Reported: UML 2.5.1 — Sat, 19 Oct 2024 15:20 GMT
  • Updated: Mon, 28 Oct 2024 16:07 GMT

Multiplicity of Operation::returnResult() should be [0..1], i.e. not multivalued

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

    There is at the most only one return parameter allowed for an Operation due to the existing constraint "at_most_one_return". Why is the returnResult() operation multivalued? It should be [0..1], not [0..*].

    Instead of an empty set, it could return null if there is no return parameter, similar to lower(), type() and upper(). But the stated body for those operations is defined in terms of returnResult() returning a set. Would that have an impact?

  • Reported: UML 2.5.1 — Fri, 27 Sep 2024 15:08 GMT
  • Updated: Sat, 12 Oct 2024 14:11 GMT

UMLR-673, reported for UML 2.5, still isn't fixed in 2.5.1

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

    The issue reported here:
    https://issues.omg.org/issues/UMLR-673 "Spec refers to TypeElement twice. Should be TypedElement"

    still applies to 2.5.1. The affected pages are:
    p. 75 (in a description) and
    p. 192 in an OCL body for an operation (Property::isCompatibleWith(), section 9.9.17.7).

    "Pages" refer to the PDF file containing the specification document .

  • Reported: UML 2.5.1 — Tue, 1 Oct 2024 14:24 GMT
  • Updated: Fri, 11 Oct 2024 18:08 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: Fri, 11 Oct 2024 18:08 GMT

Constraint "input" of ParameterSet assumes owner is always a BehavioralFeature

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

    In section 9.9.16.5 Constraints of ParameterSet, the OCL implementation for the constraint named 'input' assumes that the owner of the ParameterSet is always BehavioralFeature. However, a ParameterSet can also be owned by a Behavior. Also, it is not specified whether the 'in' Parameters include 'inout' direction, and likewise whether 'out' Parameters includes 'inout' and 'return' directions:

    • input

    If a parameterized entity has input Parameters that are in a ParameterSet, then any inputs that are not in a
    ParameterSet must be streaming. Same for output Parameters.

    inv: ((parameter->exists(direction = ParameterDirectionKind::_'in')) implies
    behavioralFeature.ownedParameter->select(p | p.direction = ParameterDirectionKind::_'in'
    and p.parameterSet->isEmpty())->forAll(isStream))
    and
    ((parameter->exists(direction = ParameterDirectionKind::out)) implies
    behavioralFeature.ownedParameter->select(p | p.direction = ParameterDirectionKind::out
    and p.parameterSet->isEmpty())->forAll(isStream))

    The method should be corrected to account for all parameter directions as well as the two possible types of owner. There is an interesting discussion of this on StackOverflow.

  • Reported: UML 2.5.1 — Thu, 10 Oct 2024 15:07 GMT
  • Updated: Fri, 11 Oct 2024 14:39 GMT

PropertyTemplateParameter in description of constraint "binding_to_attribute"

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

    In section 9.9.17.8 Constraints, of the description for Property, the constraint "binding_to_attribute" on page 194 reads like this:

    A binding of a PropertyTemplateParameter representing an attribute must be to an attribute.

    Not sure what "PropertyTemplateParameter" is supposed to be ... either there is a missing space between "Property" and "TemplateParameter", or else maybe there are some missing words in the description. In any case, the OCL implementation is clear enough as to what this constraint does.

  • Reported: UML 2.5.1 — Fri, 4 Oct 2024 08:30 GMT
  • Updated: Fri, 11 Oct 2024 14:35 GMT

Parameters of a ParameterSet should be ordered

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

    Referring to ParameterSet, section 9.9.16.4 "Association Ends" on page 190 of the PDF file:
    Since parameters of a ParameterSet specify "alternative sets of inputs or outputs that a Behavior may use", and the Parameters of a Behavior are specified with the "ordered" constraint, by similar reasoning it seems that the parameters of a ParameterSet should also be ordered.

    Consider a Behavior which has two alternate sets of input parameters implemented by ParameterSets: each set contains a String and an Integer parameter but ordered differently. Without the ordering constraint, they might be considered equal, and no overloading would be possible.

  • Reported: UML 2.5.1 — Wed, 28 Aug 2024 12:26 GMT
  • Updated: Mon, 7 Oct 2024 09:42 GMT

Suggested improvement to description of "BehavioralFeature::isDistinguishableFrom()"

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

    In the UML 2.5.1 specification document on page 173 of the PDF file in section section 9.9.2.7 "Operations" of BehavioralFeature, the textual description of "isDistinguishableFrom()" does not fit 100% with the OCL implementation given.

    The description currently reads:

    The query isDistinguishableFrom() determines whether two
    BehavioralFeatures may coexist in the same Namespace. It specifies
    that they must have different signatures.

    Obviously, if they have different names, then they are also distinguishable from each other. This is the first element of the Tuple which is generated in the body of the query:

    body: (n.oclIsKindOf(BehavioralFeature) and ns.getNamesOfMember(self)-
    >intersection(ns.getNamesOfMember)->notEmpty()) implies
    Set

    Unknown macro: {self}

    >including(n.oclAsType(BehavioralFeature))>isUnique(ownedParameter->collect(p|
    Tuple

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

    ))

    My suggested improvement of the description:

    The query isDistinguishableFrom() determines whether two
    BehavioralFeatures may coexist in the same Namespace. It specifies
    that they must have different names, or different signatures if their
    names are the same.

  • Reported: UML 2.5.1 — Mon, 19 Aug 2024 16:44 GMT
  • Updated: Wed, 4 Sep 2024 14:22 GMT

Suggestion for improved wording of description for attribute "isDisjoint"

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

    In the section GeneralizationSet, section 9.9.8.4 "Attributes" on page 181, in the description for attribute "isDisjoint" the word "members" should be replaced by "elements" to avoid confusion with Classifier members. And, after all, sets have elements, not members.

    The original text reads:

    isDisjoint: Boolean [1..1] = false
    Indicates whether or not the set of specific Classifiers in a Generalization relationship have instance in
    common. If isDisjoint is true, the specific Classifiers for a particular GeneralizationSet have no members in
    common; that is, their intersection is empty. If isDisjoint is false, the specific Classifiers in a particular
    GeneralizationSet have one or more members in common; that is, their intersection is not empty.

    Suggested improvement:

    isDisjoint: Boolean [1..1] = false
    Indicates whether or not the set of specific Classifiers in a Generalization relationship have any elements in
    common. If isDisjoint is true, the specific Classifiers for a particular GeneralizationSet have no elements in
    common; that is, their intersection is empty. If isDisjoint is false, the specific Classifiers in a particular
    GeneralizationSet have one or more elements in common; that is, their intersection is not empty.

    This seems to be more in agreement with what the summary text on page 162 under 9.7.3 "Semantics" is saying.

  • Reported: UML 2.5.1 — Mon, 26 Aug 2024 15:33 GMT
  • Updated: Wed, 4 Sep 2024 14:15 GMT

Allow method bodies for abstract BehavioralFeatures

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

    In the section BehavioralFeature, section 9.9.2.8 "Constraints" on page 173:

    The constraint "abstract_no_method" declares: "When isAbstract is true there are no methods."

    At least for C++, this is NOT necessarily true because a member function declared as pure virtual can have a method body. However, the method can only be called using the fully qualified class name.

    This seems overly restrictive to me – there might have been a time when the C++ language disallowed method bodies for pure virtual functions, but I can't remember when that might have been ... in Scott Meyer's "Effective C++" 2nd edition, which dates from 1997, he remarks on page 162 that "it is possible to provide a definition for a pure virtual function (...)" and proceeds to illustrate different ways of calling the function.

    It might make more sense to define the constraint backwards, such that if "isAbstract" is false, that there must be a (possibly empty) method body.

  • Reported: UML 2.5.1 — Tue, 20 Aug 2024 11:41 GMT
  • Updated: Wed, 4 Sep 2024 14:13 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: Mon, 12 Aug 2024 10:26 GMT

Behavior and ordering of Parameters in OpaqueExpression

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

    Prior to the 2.5.1 specification, Behavior in an OpaqueExpression was restricted to have exactly one return Parameter and no input Parameters. This was relaxed to allow such Behaviors to have "in" Parameters now as well as one "return" Parameter (see section 8.3.3.3 "Opaque Expressions", the next-to-last paragraph).

    However, it appears that the operation body for "OpaqueExpression::result()" still assumes that there is only one parameter (see 8.6.16.6 "Operations"):

    body: if behavior = null then
    null
    else
    behavior.ownedParameter->first()
    endif

    This brings up the question of ordering of parameters: Obviously, the parameters in the signature of the Behavior must be ordered; however, it is not specified anywhere (AFAICT) whether the "return" parameter should be the first or perhaps the last in the ordering (obviously, at least IMHO, the only two places where it would make any sense are first and last).

    Either the placement, i.e. ordering, of the return Parameter needs to be specified (as well as for all other Behaviors), or the "result()" Operation needs to be rewritten if the return Parameter might be ordered last instead of first.

  • Reported: UML 2.5.1 — Tue, 6 Aug 2024 21:17 GMT
  • Updated: Mon, 12 Aug 2024 10:26 GMT

InformationItem specified as a concrete Class, but it is abstract according to its constraint "not_instantiable"

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

    On page 716, section 20.2.2 "InformationItem" (Classifier Description):

    InformationItem is specified as a concrete Class, but in fact it is abstract according to its constraint "not_instantiable". Also, there are no concrete Classes in the UML which specialize InformationItem.

    There is already the invariant constraint "convey_classifiers" included in InformationFlow; so why is InformationItem even necessary? If it is necessary, at least it should be defined as an abstract class – otherwise, it would need to have some kind of Element as an owner.

  • Reported: UML 2.5.1 — Mon, 29 Jul 2024 08:12 GMT
  • Updated: Mon, 12 Aug 2024 06:49 GMT

Grammatical improvement is needed in the descriptions (p. 342)

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

    On page 342 of the PDF file at section 13.4.11.4, there is a bit of "anguished English":

    • event : Event [1..1] (opposite A_event_trigger::trigger)
      The Event that detected by the Trigger.

    and

    • port : Port [0..*] (opposite A_port_trigger::trigger)
      A optional Port of through which the given effect is detected.

    Suggested improvements:

    "The Event that is detected by the Trigger" or simply: "The Event detected by the Trigger";

    "A*n* optional Port of through which the given effect is detected."

  • Reported: UML 2.5.1 — Thu, 25 Jul 2024 07:44 GMT
  • Updated: Fri, 9 Aug 2024 17:05 GMT

Simplification of Stereotypes Usage<--Create and Usage<--Instantiate

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

    In the Standard Profile described under section 22, there are two stereotypes presently defined which extend Usage but do much the same thing, lacking any detailed specification of how they should be different: «Create» and «Instantiate». However, the «Create» stereotype also extends BehavioralFeature, which seems to indicate that this should be a separate stereotype. This is also the only stereotype which appears to do "double duty" within the Standard Profile.

    I suggest that the extension Usage<-«Create» be removed entirely in favor of Usage<«Instantiate», leaving the BehavioralFeature<-«Create» extension in place. This way, «Create» and «Destroy» become orthogonal.

  • Reported: UML 2.5.1 — Fri, 12 Jul 2024 08:45 GMT
  • Updated: Fri, 12 Jul 2024 20:00 GMT

Missing extends arrow in diagram

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

    There should be an extends arrow from stereotype <<script>> to Artifact.

  • Reported: UML 2.5.1 — Tue, 9 Jul 2024 10:16 GMT
  • Updated: Tue, 9 Jul 2024 17:32 GMT

Unclear wording about Stereotypes and ownership of their Properties

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

    On page 301-302 under section 12.3.3.4 Stereotypes, there is this sentence on p. 302:

    "The type of a composite aggregation Stereotype Property cannot be a Stereotype (since Stereotypes are owned by their Extensions) or a metaclass (since instances of metaclasses are owned by other instances of metaclasses)..."

    I believe that this wording can be improved. A Stereotype must be owned by a Profile, either directly or indirectly through a Package owned by a Profile. This is stated on p. 322 in section 12.4.9.5 "Operations" of Stereotypes under the description of the "profile()" operation.

    To avoid confusion, the first quoted sentence could be worded like this:

    "The type of a composite aggregation Stereotype Property cannot be a Stereotype (since Stereotype *Properties* are owned by their Extensions)..."

    or perhaps better like this:

    "The type of a composite aggregation Stereotype Property cannot be a Stereotype (since Stereotype *instances* are owned by their Extensions)..."

    The ownership of instances of a Stereotype is defined in the last bulleted list item under section 12.3.3.1.3 "MOF-Equivalent Semantics" on p. 297-298 says: "An instance of a Stereotype (...) maps to an instance of the CMOF class representing the Stereotype. This stereotype instance is compositionally associated with the Element to which it applies using a Link that is an instance of the composite Association to which the Extension is mapped."

    I assume that this was the intended meaning?

  • Reported: UML 2.5.1 — Sat, 6 Jul 2024 14:29 GMT
  • Updated: Tue, 9 Jul 2024 17:32 GMT

Typo in the hyperlink for "Normative URL"

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

    There should be a colon and two slashes after "https".

  • Reported: UML 2.5.1 — Thu, 4 Jul 2024 07:54 GMT
  • Updated: Tue, 9 Jul 2024 17:30 GMT

Missing constraints for class Interval

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

    There should be at least two invariant constraints here:

    1. The types of "min" and "max" should be the same, and for both "min" and "max" the operation "isComputable()" should return "true";
    2. The value of "min" must be less than or equal to that of "max".

    A third such constraint could be added that the type(s) must not be Null.

  • Reported: UML 2.5.1 — Wed, 19 Jun 2024 08:16 GMT
  • Updated: Mon, 1 Jul 2024 15:44 GMT

TemplateParameter placeholder names?

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

    In most programming languages which support templates, one would normally define the primary template with placeholders for the type names, e.g.: "List<K>" or "Map<Key,Value>".

    However, TemplateParameter derives directly from Element; and so does ParameterableElement, as well as TemplateSignature. Since none of the above are NamedElement, where are we supposed to store the strings used for the placeholder names?

    Perhaps there is a simple solution which I have overlooked. The specification could be clearer on the subject.

  • Reported: UML 2.5.1 — Sun, 19 May 2024 11:53 GMT
  • Updated: Tue, 28 May 2024 20:23 GMT

UMLR-826 is a non-issue

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

    Please mark issue UMLR-826 as SOLVED ... I realize now that a Stereotype can be owned by a package contained within a Profile, and the owner must not necessarily be a Profile.

  • Reported: UML 2.5.1 — Sun, 19 May 2024 11:44 GMT
  • Updated: Tue, 28 May 2024 19:56 GMT

Stereotype must be owned by a Profile, but shows composition relationship to Package

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

    On page 322 under section 12.4.9.6 Constraints for Stereotypes, we have the following constraint:

    "generalize
    A Stereotype may only generalize or specialize another Stereotype."

    On the same page under section 12.4.9.4 Association Ends, we have:

    "/profile : Profile [1..1]{} (opposite A_profile_stereotype::stereotype)
    The profile that directly or indirectly contains this stereotype."

    If a given Stereotype is a nested Stereotype (assuming this is legal, since a Stereotype inherits Class), then its owner must be another Stereotype. Otherwise, its owner must be a Profile according to 12.4.9.4. If it is nested, then the operation "profile()" as described there should return the Profile containing (i.e. owning) the top-most, non-nested Stereotype in the hierarchy. Otherwise, "profile()" should return the owner of the Stereotype in question.

    However, in the diagram on page 295 (of the UML 2.5.1 specification PDF file), the composition relationship is drawn between Stereotype and Package, and not between Stereotype and Profile. Of course, a Profile "IS A" Package, but the ownership relationship would be much clearer if it were drawn between Stereotype and Profile.

    Ideally, one should use the

    {xor}

    constraint between two composition arrows, one self-directed for nested Stereotypes and one for Profiles, unless a Stereotype can have other types of owners...?

  • Reported: UML 2.5.1 — Mon, 6 May 2024 22:31 GMT
  • Updated: Tue, 7 May 2024 17:30 GMT

ConnectableElement is not defined until section 11, but Parameter (defined in section 9) inherits ConnectableElement and needs to see its definition

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

    Parameter is defined in section 9. However, the two generalizations of ConnectableElement, which is an abstract class, are already defined in section 7 (TypedElement and ParameterableElement). In order to define ConnectableElement, for example in C++, it is sufficient to provide forward declarations of the types ConnectorEnd and ConnectableElementTemplateParameter. Therefore, ConnectableElement could be defined in section 9 as well so that Parameter's definition need not be deferred until ConnectableElement has been defined. Otherwise, it is not possible to define Parameter until much later.

    Although nothing else in the metamodel seems to specialize Parameter, Parameter figures prominently in all of the related diagrams, so it should probably remain in section 9 where it currently resides. Would it make sense to move ConnectableElement's definition up to section 9?

  • Reported: UML 2.5.1 — Sun, 5 May 2024 16:39 GMT
  • Updated: Tue, 7 May 2024 17:20 GMT

Suggestion: Generalization::isSubstitutable() should return "Boolean = false" and not "Boolean [0..1]"

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

    Why bother with the multiplicity here? If the modeler leaves this undefined, it would make more sense to return a default value of "false". This would make implementation of the attribute much simpler.

  • Reported: UML 2.5.1 — Thu, 2 May 2024 09:55 GMT
  • Updated: Fri, 3 May 2024 15:30 GMT

Redundant association from Classifier to NamedElement at bottom of diagram

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

    The diagram on page 141 of the PDF file of the UML 2.5.1 reference under section 9.2.2 "Abstract Syntax" shows two directed associations from Classifier to NamedElement, one at the top left of the image and the other at the bottom right.

    Since the association ends in both cases are identical, one of these (most likely the bottom one) is redundant and should be removed. Removing the bottom one would also enable removing the NamedElement rectangle which is needed at the top for showing the generalization from RedefinableElement.

  • Reported: UML 2.5.1 — Wed, 24 Apr 2024 07:01 GMT
  • Updated: Fri, 3 May 2024 15:03 GMT

Ambiguity of operation "Classifier::general()" and association end "/general"

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

    The owned end "/general" of the association "A_general_classifier", which is a directed self-referencing loop from Classifier to itself, is described as follows on page 175 of the PDF file of the UML 2.5.1 reference under section 9.9.4.6 "Association Ends":

    /general : Classifier [0..*] (opposite A_general_classifier::classifier)
    The generalizing Classifiers for this Classifier.

    However, there is also an operation "general()" described on page 176 under 9.9.4.7 "Operations":

    general() : Classifier [0..*]
    The general Classifiers are the ones referenced by the Generalization relationships.

    and is implemented in OCL:

    body: parents()

    An element cannot be its own parent. Therefore, what is the semantic purpose of the association? As I understand it, an element cannot generalize itself; otherwise, there would be a cycle in the generalization hierarchy.

  • Reported: UML 2.5.1 — Sun, 21 Apr 2024 10:40 GMT
  • Updated: Fri, 3 May 2024 13:55 GMT

Multiplicity of composition/aggregation end for many different elements with {subsets owner} should be 1 and not 0..1

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

    At page 64 of the PDF file, section 7.2.3.1 "Elements", states: "Every Element in a model must be owned by exactly one other Element of that model, with the exception of the top-level Packages of the model."

    There are very many diagrams which show owner relationships as composition between different elements, sometimes with multiplicity as 0..1 and sometimes as 1.

    For example, on PDF page 64-65 under section 7.3 Templates, diagram of "Abstract Syntax" at 7.3.2:

    • TemplateableElement owns zero or one TemplateSignature, and TemplateSignature has exactly 1 owner;
    • Ownership of ParameterableElement is given correctly as 0..1 because a Package is also a ParameterableElement since it is a
      specialization of PackageableElement, but a Package might not have an owner.

    So these seem correct to me. However, referring to the diagram on (PDF) page 149, section 9.4.2 "Features - Abstract Syntax":

    • Parameter owns zero or more ValueSpecifications, but Parameter is the owner, so it should be exactly 1 and not 0..1;
    • BehavioralFeature owns Parameter and ParameterSet, but multipicity of the owner is 0..1 instead of 1;
    • ParameterSet owns Constraint, but multipicity of the owner is 0..1 instead of 1;

    Since neither ValueSpecification nor Parameter nor Constraint can be Packages, they should always have exactly one owner Element, if I understand this correctly.

  • Reported: UML 2.5.1 — Mon, 15 Apr 2024 13:57 GMT
  • Updated: Mon, 22 Apr 2024 17:03 GMT

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

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

UML 2.5 issue. AssociationClasses should have isUnique property

  • Key: UMLR-443
  • Legacy Issue Number: 18716
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    Dragan Milicev’s paper at http://afrodita.rcub.bg.ac.rs/~dmilicev/pubs/mdd/trumlassoc.zip points out that AssociationClasses can be multiply instantiated between the same set of end instances, even when all the ends are marked as unique. He proposes adding an isUnique property to AssociationClass to distinguish between circumstances where this is allowed and those where it is not.

  • Reported: UML 2.5b1 — Wed, 15 May 2013 04:00 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

Can passive classes have ClassifierBehaviors?

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

    Category: Major

    In the StateMachine section “Event processing for state machines”, there is an explicit statement: “for passive classes it can be implemented using a monitor”, which suggests that passive classes implement the run-to-completion paradigm. This implies that passive classes can have classifier behaviors. Perhaps this capability should be removed, but, it may not be backward compatible and might invalidate numerous existing designs (e.g., Rhapsody models).

  • Reported: UML 2.4.1 — Wed, 10 Oct 2012 04:00 GMT
  • Updated: Mon, 3 Feb 2020 16:26 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

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