Unified Modeling Language Avatar
  1. OMG Specification

Unified Modeling Language — Open Issues

  • Acronym: UML
  • Issues Count: 878
  • Description: Issues not resolved
Open Closed All
Issues not resolved

Issues Summary

Key Issue Reported Fixed Disposition Status
UAF13-18 UML::Property.defaultValue has upper multiplicity of 1 even though Property is a MultiplicityElement UML 2.5.1 open
UAF14-16 UML::Property.defaultValue has upper multiplicity of 1 even though Property is a MultiplicityElement UML 2.5.1 open
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
CORBA35-265 when is a connection a "bi-directional connection"? UML 2.0 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
OCL25-217 UML 2.5.1 embedded OCL syntax errors 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-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
UML241-45 Loop notation UML 1.4.2 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-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
UMLDI-30 Section: 8.5 Properties UMLDI 1.0 open
UMLDI-28 Invalid "diagram-interchange.xml" file in DI 2.0 's ptc/05-06-07 zip file UMLDI 1.0b1 open
UMLDI-27 Section: Annex C UMLDI 1.0b1 open
UMLDI-29 di-schema.xsd UMLDI 1.0b1 open
UMLDI-26 Diagram Interchange clarification UMLDI 1.0b1 open
UMLDI-25 UML Mapping in DI specification inadequate UMLDI 1.0b1 open
UMLDI-24 UML diagram interchange: list updating and nested graph nodes UMLDI 1.0b1 open
UMLDI-23 UML diagram interchange: size of graph node with autosize UMLDI 1.0b1 open
UMLDI-22 UML diagram interchange: use of bounds limiting UMLDI 1.0b1 open
UMLDI-21 UML diagram interchange: schema usage needed UMLDI 1.0b1 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
UML241-46 actions UML 2.0 open
UML241-40 UML 2 Super/Interactions/ LOOP construct specifications UML 1.4.2 open
UML241-41 Section: 9.3.12 UML 2.0 open
UML241-38 UML2 Superstructure - profiles UML 1.4.2 open
UML241-39 Messages to ports with only one connector UML 1.4.2 open
UML241-42 Profiles UML 1.4.2 open
UML241-43 Wrong metamodel for internal transitions UML 1.4.2 open
UML241-37 Section: 11.3.39 UML 2.0 open
UML241-36 inadequate definition of 'constructor' UML 1.4.2 open
UML241-33 What is a mapping that is not computable? UML 2.0 open
UML241-32 Components UML 2.0 open
UML241-35 DeploymentSpecification - notation for DeploymentSpecification on the insta UML 2.0 open
UML4DDS-32 UML Profile for DDS does not refer to WaitSet element UML4DDS 1.0b1 open
UML4DDS-31 format file url for qos_profile should be specified in more detail UML4DDS 1.0b1 open
UML4DDS-30 Problematic type library specification UML4DDS 1.0b1 open
UML4DDS-33 Figure 15-5: UML4DDS 1.0b1 open
UML4DDS-29 Figure 46: "manages" and "class" have not been defined previously. UML4DDS 1.0b1 open
UML4DDS-28 Section 7.3.2.2: what is the "field" stereotype? UML4DDS 1.0b1 open
UML4DDS-21 domainParticipant needs to be considered as a Component *and* a ddsProperty UML4DDS 1.0b1 open
UML4DDS-20 Section 7.2.5 figure 46 UML4DDS 1.0b1 open
UML4DDS-25 the name "relation" is syntactically too poor and too common UML4DDS 1.0b1 open
UML4DDS-24 Section 7.2.7 associations UML4DDS 1.0b1 open
UML4DDS-27 Section 7.3.2.1: UML2 conformance UML4DDS 1.0b1 open
UML4DDS-26 Paragraph 7.3 is non normative and, thus, should be moved in an annex UML4DDS 1.0b1 open
UML4DDS-23 missing link UML4DDS 1.0b1 open
UML4DDS-22 a domain needs to be considered as a ddsSpecification *and* a ddsProperty UML4DDS 1.0b1 open
UML4DDS-19 Section 7.2.4 How are complememts of types designed? UML4DDS 1.0b1 open
UML4DDS-18 Section 7.2.3: TopicStruct and TopicField UML4DDS 1.0b1 open
UML4DDS-17 Section 7.2.3: constraint should be specified UML4DDS 1.0b1 open
UML4DDS-12 Section 7.1.10: SharedKey is not specified anywhere UML4DDS 1.0b1 open
UML4DDS-11 Section 7.1.9: semantics behind dashed line "reads and writes" is unclear UML4DDS 1.0b1 open
UML4DDS-15 Section 7.2.2 UML4DDS 1.0b1 open
UML4DDS-14 Section 7.2.1: wrong UML2 notation UML4DDS 1.0b1 open
UML4DDS-13 which field is actually the key? UML4DDS 1.0b1 open
UML4DDS-16 Section 7.2.3association "type" UML4DDS 1.0b1 open
UML4DDS-7 Section 7.1.5 "TopicField" UML4DDS 1.0b1 open
UML4DDS-6 TopicField should be under Core::Specification UML4DDS 1.0b1 open
UML4DDS-5 Section 7.1 UML4DDS 1.0b1 open
UML4DDS-9 Figure 9: the names of the fields of a structure are not designed UML4DDS 1.0b1 open
UML4DDS-8 Figure 9 and following paragraphs: subset constraints are not designed UML4DDS 1.0b1 open
UML4DDS-4 "type" of a TopicDescription UML4DDS 1.0b1 open
UML4DDS-3 Section 7.1.4 UML4DDS 1.0b1 open
UML4DDS-10 Section 7.1.9 UML4DDS 1.0b1 open
UML4DDS-2 Fig 6:qosPolicy subsets property and not ownedEntity as stated in § 7.1.3.1 UML4DDS 1.0b1 open
UML4DDS-1 The document does not specify how the compliance levels are layered UML4DDS 1.0b1 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-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-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-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

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

  • Key: UAF13-18
  • 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:17 GMT
  • Updated: Fri, 20 Dec 2024 14:56 GMT

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

  • Key: UAF14-16
  • 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:17 GMT
  • Updated: Fri, 20 Dec 2024 14:56 GMT

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

when is a connection a "bi-directional connection"?

  • Legacy Issue Number: 7356
  • Status: open  
  • Source: Real-Time Innovations ( Mr. Dave Stringer)
  • Summary:

    The discussion on when to send BiDirIds over connections is floundering.
    In part, I think this is due to a lack of precision in our thinking (and more
    importantly in the adopted firewall spec we are working from).

    When does a GIOP connection become bi-directional? The implementation
    of the connection-initiator protocol engine must know this. Before this
    event it has to treat a GIOP Request message as a protocol error and after
    the event it has to dispatch the request.

    There seems to be an assumption (or more than one) that there is a
    relationship between an Object Reference (i.e. the programming language
    artefact representing CORBA::Object) and a GIOP connection.

    Whilst it is true that an implementation of the CORBA spec will provide a
    relationship (else an invocation cannot result in a GIOP Request message)
    the particular relationship was left to ORB implementers to provide for
    flexibility of implementation. Specifically, such a relationship is not prescribed
    in the CORBA specification (nor should it be).

    I suggest it would be dangerous to define a GIOP connection to change state
    when an Object Reference that (in some ill-defined way) "points to" a server
    that is the target of that connection, undergoes a policy change (i.e. its BiDir
    Offer policy is set to Allow).

    Instead, a GIOP connection presumably becomes bi-directional when an
    invocation on an Object Reference, with an effective Offer Policy of Allow, results
    in a Request message being sent over that connection.

    The specification must be explicit over which event causes the connection to
    become bi-directional.

    Also, can a connection cease to be bi-directional? For example if either the
    Object Reference invoked above or the POA with "Export = Allow" are destroyed.
    Again this would appear to be fraught with problems, leading to the assumption
    that the GIOP connection, once bi-directional, remains bi-directional until it is
    closed.

    Lastly, the closing of idle connections and the subsequent re-connection has
    hitherto been a matter for ORB implementers (Messaging::RebindPolicy not
    withstanding). This is unfortunate as an application won't be aware of the ORB
    having conserved resources in this way and the ORB should not be expected to
    provide session semantics that span multiple tcp connections (this is currently
    stated in the description of NegotiateSession).

  • Reported: UML 2.0 — Tue, 18 May 2004 04:00 GMT
  • Updated: Thu, 11 Jan 2024 17:33 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

UML 2.5.1 embedded OCL syntax errors

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

    The new OCL for UML 2.5.1 seems not to have been checked by any tool; shame on you. There are two syntax errors:

    OpaqueExpression-only_in_or_return_parameters-specification makes use of ParameterDirectionKind::in but 'in' is a reserved word and so it must be escaped as in other similar constraints. Change to ParameterDirectionKind::'in'

    Lifeline-interaction_uses_share_lifeline-_specification has a Bag rather than Boolean argument for the final implies. Perhaps the select(...) should be followed by a ->notEmpty() or the select(...) could be an exists(...)

  • Reported: UML 2.5.1 — Tue, 5 May 2020 16:55 GMT
  • Updated: Tue, 5 May 2020 16:55 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

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

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

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

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

About behavior ports

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

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

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

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

    This has to be clarified.

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

Operation calls on behavior ports

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

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

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

Behavioral port

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

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

    Description:

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

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

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

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

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

    Suggested resolution:

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

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

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

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

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

Are null NamedElement::name values names?

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

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

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

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

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

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

Typo

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

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

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

Figure 7.17 has some trucated labels

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

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

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

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

Typo in last syntax example

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

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

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

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

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

Attachment point of connectors not specified

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

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

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

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

Implied Multiplicity of the association-like notation should be displayable

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

    The specification says:

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

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

    Suggestion
    Add following sentence to the paragraph above:

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

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

Lifeline "same_classifier" constraint has an inconsistent specification

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

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

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

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

    Please clarify.

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

Are two identical bound templates the same?

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

    Consider: my general purpose library provides:

    mylib::Aggregate<T>

    My subsystems exploit this by drawing:

    mysub1::Aggregate<T -> String>
    mysub2::Aggregate<T -> String>

    and my application integrates the subsystems by drawing

    myapp::Aggregate<T -> String>

    Since each of the three Aggregates of String have different packages, oops, it would seem that they are different types and so cannot be passed interchangeably between subsystems.

    The above arises from the natural encoding of a graphical representation in which Aggregate<String> is drawn once per diagram/package and referenced many times. The package owns and so appropriates the shared type.

    In contrast, textual representations, in the absence of a typedef, elaborate Aggregate<String> for each reference. Each reference 'owns' the shared type, which is not appropriated by a prevailing package.

    (This has been a major problem for attempts to provide UML-aligned XMI serialization for OCL since e.g. there is obviously only one Set(String) but who owns it, who persists it, and how is it referenced? Eclipse OCL has prototyped a solution whereby a shared orphanage package is responsible for owning the singletons, but everyone persists their singletons. This incurs unpleasant costs in creating local orphanages during a serialization and destroying them again during loading. Struggling with this finally made me see that there is a fundamental UML limitation.)

    In similar scenarios where there is an ownership/reference dilemma, UML provides e.g. TemplateParameter::parameteredElement/ownedParameteredElement. Surely there should be a TypedElement::type/ownedType so that a TypedElement::ownedType can introduce a package-less type that is consequently shared by all similar introductions? Bloat could be avoided by one TypedElement::type referencing another TypedElement::ownedType. Alternatively a Package::sharedElements could contain local copies that are logically shared globally. (This could also solve the problem of everyone wanting their own Boolean PrimitiveType.)

  • Reported: UML 2.5 — Mon, 14 Aug 2017 07:31 GMT
  • Updated: Mon, 14 Aug 2017 10:52 GMT

Incorrect use of multiplicity element.

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

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

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

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

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

Complete and Covering are Synonyms and used confusinginly

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Figure 12-15 (MOF Model Equivalent …) p.284 - MOF Model Equivalent navigation and ownership incorrect

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

    Figure 12-15 (MOF Model Equivalent to Extending "Interface" by the Home" Stereotype) shows navigation only from the stereotype to the metaclass, but the paragraph just below it says the ExtensionEnd (the one opposite the metaclass) is a navigableOwnedEnd. Extensions were made navigableOwnedEnds in 2.3.
    Before that the spec explicitly said Extensions were non-navigable because the association owned them. This wasn't true, so Pete filed issue 9891 (ExtensionEnd description refers to old use of navigability) and it was corrected by making them navigableOwnedEnds.
    Presumably the figure should show navigation in both directions and use the dot notation to show which end is owned.
    A constraint could be added to Extension that its ownedEnd is a navigableOwnedEnd.

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Wed, 28 Jun 2017 17:23 GMT

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

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

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

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

    as well as:

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

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

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

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

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

What is a DurationInterval

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

    Identifies is better than points out.

    Subsequent description is confusing about one/two NamedElements.

    Suggest:

    It identifies either a NamedElement whose enter and exit events are observed, or a pair of NamedElements for each of which either an enter or exit event is observed.
    ...
    When there are two events, firstEvent[i] is true to select the enter, or false to select the exit, event for observation of the corresponding event. —

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Updated: Wed, 28 Jun 2017 17:17 GMT

What is a DurationInterval

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

    What is the "range" between two durations. Is it a statistical property? is it max to max, min to min, ....?? Ah. I get it. This is a spectacularly confusing class name. Introducing an alternate editorial term compounds rather than mitigates the problem. Use "distance" in the descriptions, then users might grasp that it is not a time interval. In max/min refer to larger/smaller duration rather than range.

    Discussion
    Source: Edward Willink
    I'm stll very confused, if two duration are being compared in some way, such that the min and max of the range is being found, then the durations must either be duration constants, or offset from some observation. If the two durations do not use the same observation, then there should be no duration interval?

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Updated: Wed, 28 Jun 2017 17:17 GMT

Observations in TimeExpressions

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

    In section 8.4.4 dealing with TimeExpression and Duration (both of which are kinds of ValueSpecification) it currently says:

    "A TimeExpression or Duration is denoted by the textual representation of its expr, if it has one (see sub clause 8.3.5). The representation is of a formula for computing the time or duration value, which may include the names of related Observations and constants. If a TimeExpression or Duration does not have an expr, then it is simply represented by its single associated Observation."

    It is not clear to me what is meant by "which may include the names of related Observations ". An Observation in the current time model is a kind of PackageableElement and not a value specification; i.e., it does not represent a value. The above text seems to suggest some kind of special case for Observation such that it should be treated as a value when its name appears in a TimeExpression or Duration. If so, what is the type of that value and where is it stored? (Note that Observation does not have an attribute for storing such a value.) What happens if the expression is one that computes the value of the Observation? Or, if the value of the Observation is needed to compute some other value?

    I suggested earlier that this problem can be easily resolved if we make Observation a kind of ValueSpecification, but this does mean a metamodel change.

  • Reported: UML 2.5b1 — Sun, 2 Jun 2013 04:00 GMT
  • Updated: Wed, 28 Jun 2017 17:16 GMT

UML 2.5: Time Observation and Duration Observation problem

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

    In the current model of Time (UML 2.5), TimeObservation and DurationObservation are both a kind of Observation which is, in turn, a kind of PackageableElement. Significantly, however, neither is a kind of ValueSpecificaiton or even a kind of TypedElement. Hence, it is not particularly meaningful to use it in expressions such as constraints or shown in numerous diagrams such as Figure 8.5 or in numerous diagrams in the Interactions clause (clause 17).

    Note that these examples might be OK if they actually referenced not the observations themselves, but to the associated TimeExpressions. Unfortunately, there are two issues that prevent this as a solution to the above problem:

    (1) It is not possible to navigate from an observation to its associated TimeExpression, which means that, given a TimeObservation or a DurationObservation element in a model, it is not possible to easily find the time value that is associated with it (what is the use of a time observation if we do not know the time value associated with it?)

    (2) A TimeExpression can be associated with multiple TimeObservations (or DurationObservations), which means that referencing a given TimeExpression does not necessarily identify which observation is being referenced. Hence, if the time expression is referenced in a constraint, that would presumably automatically apply to all observations pointed to by that expression, even if that is not the intent.

    One possible simple solution is to make Observation a kind of ValueSpecification instead of a kind of PackageableElement. (A more systematic solution would be to revisit and rationalize the entire SimpleTime and Intervals metamodel, which seem unnecessarily complicated.)

  • Reported: UML 2.5b1 — Wed, 24 Apr 2013 04:00 GMT
  • Updated: Wed, 28 Jun 2017 17:15 GMT

DecisionNode is missing a constraint on incoming edges

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

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

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

What is the abstract syntax for Figure 17.27?

  • Key: UMLR-437
  • Legacy Issue Number: 18749
  • Status: open  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    Figure 17.25 is very helpful to understand how interaction diagrams look like in the abstract syntax.

    It is really unfortunate there is no such diagram for all the figures in the interaction chapter.
    In particular, Figure 17.27 defies my ability to understand the abstract syntax behind it.

    Figure 17.27 shows several elements that an Activity can own but not an Interaction:
    initial state
    Control flow edges
    Final state
    Decision node
    Figure 17.27 shows several elements that an Interaction can own but not an Activity:
    (inline) interaction
    Duration constraint
    Interaction use
    Have I missed something or is there a genuine mismatch between the capabilities implied by the interaction diagram overviews per 17.10 and the actual capabilities of interactions per 17?

  • Reported: UML 2.5b1 — Mon, 27 May 2013 04:00 GMT
  • Updated: Wed, 28 Jun 2017 16:36 GMT

What is a UML diagram? is it restricted to showing elements that are instances of the M2 UML metamodel and nothing else?

  • Key: UMLR-433
  • Legacy Issue Number: 18854
  • Status: open  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    Figure B.3 in UML 2.5 effectively prevents any possibility of using UMLDI
    for anything but pure UML models.
    By pure UML models, I mean a UML model where all of the model elements are
    CMOF::Elements classified by an M2 UML classifier from the M2 UML
    metamodel.
    This excludes the possibility of using UMLDI for mixed UML models, that
    is, UML models that can include instances of classifiers from other
    metamodels or classifiers defined in a UML Profile applied to such model.

    These restrictions come from the redefinition approach taken for defining
    UMLDI as a closed, non-reusable extension of the DI metamodel:

    1) UMLDI::UMLDiagramElement::modelElement : UML::CommmonStructure::Element

    { redefines DI::DiagramElement::modelElement }

    2) UMLDI::UMLDiagramElement::ownedElement : UMLDI::UMLDiagramelement

    { redefines DI::DiagramElement::ownedElement }

    3) UMLDI::UMLDiagramElement::owningElement : UMLDI::UMLDiagramElement

    { redefines DI::DiagramElement::owningElement }

    4) UMLDI::UMLEdge::source : UMLDI::UMLDiagramElement

    { redefines DI::Edge::source }

    5) UMLDI::UMLEdge::target : UMLDI::UMLDiagramElement

    { redefines DI::Edge::target }

    These redefinitions have significant consequences:

    • One cannot reuse UMLDI as part of a new DI-based metamodel because UMLDI
      excludes any possibility of UMLDiagramElements to be owned by anything but
      a UMLDiagramElement.
    • One cannot reuse UMLDI as part of a mixed UML+BPMN DI metamodel because
      the only kinds of DI::Edges that a UMLDI::UMLDiagramElement can be the
      source or target of is a UMLDI::UMLDiagramElement
    • One cannot extend UMLDI because (1) restarts the use of the DI framework
      within UMLDI for pure UML content – that is, M1 models where everything
      is an instance of an M2 UML classifier.

    These restrictions pose a problem for UML tools that currently allow
    diagrams to show notation for mixed content – e.g., UML + images + tables
    + notes + powerpoint/visio like shapes/lines or diagrams showing content
    from multiple metamodels.
    Since UMLDI is too restrictive to support such diagrams, tool vendors will
    be faced with undesirable, expensive tradeoffs:

    • Keep the current diagram support, add support for UMLDI
    • Delay adding support for UMLDI until the OMG loosens the restrictions
    • Use UMLDI as a notional metamodel and implement one that has the
      capability to support existing diagram capabilities so that the tool can
      use DI-based diagram interchange (for the subset of pure UML models).
    • Ignore UMLDI

    For tool vendors, these tradeoffs mean expensive business decisions about
    supporting UMLDI.

    The advantage of this restrictive approach is that it certainly clarifies
    what a UML diagram is and what it can show – I.e., instances of the M2
    UML metamodel and nothing else.
    The disadvantage of this restrictive approach is that any diagram that
    shows anything that is not an instance of the M2 UML metamodel is, by
    definition, not a UML diagram.
    (in practice, that means a lot of diagrams would not be UML2.5 UMLDI
    diagrams anymore)

    This approach seems very inflexible.

    A more flexible approach would be to define UMLDI by subsetting the DI
    associations instead of redefining them.

    The advantage of this subsetting approach is that it allows extending and
    reusing UMLDI by adding additional associations that subset the DI
    associations as necessary.
    The disadvantage of this approach is that the scope of a UML diagram
    becomes open – that is, a UML diagram could also include instances of
    something other than the M2 UML metamodel and no instances of the M2 UML
    metamodel and still be called a UML diagram.

    This could be easily addressed with queries:

    UMLDI::UMLDiagramElement::showsUMLContentOnly() : Boolean

    modelElement->forAll(oclIsKindOf(UML::CommonStructure::Element)) and
    ownedElement->select(not oclIsKindOf(UMLDI::UMLDiagramElement)->isEmpty()
    and
    ownedElement->forAll(oclAsType(UMLDI::UMLDiagramElement).showsUMLContentOnl
    y())

    Then, diagram interchange tests could be conducted for UML models where
    the UML diagrams satisfy UMLDI::UMLDiagram::showsUMLContentOnly()

    Do you agree that loosening the UMLDI metamodel as described above makes
    sense and is important enough to do urgently for UML 2.5?

  • Reported: UML 2.5b1 — Wed, 7 Aug 2013 04:00 GMT
  • Updated: Wed, 28 Jun 2017 16:28 GMT

How to access a token value in a guard?

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

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

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

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

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

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

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

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

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

Guard evaluation with decision input

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

    It is not clear how one can refer to the value provided by the decision input from within the value specification of a guard belonging to an edge outgoing from a decision node.

    Did I miss something?

  • Reported: UML 2.5b1 — Tue, 27 Aug 2013 04:00 GMT
  • Updated: Wed, 28 Jun 2017 16:26 GMT

Conflicting constraints

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

    One of the constraints on objectFlows in 15.7.22.6 is

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

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

    Imagine a decisionNode with 2 incoming objectFlows:

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

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

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

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

Allow a notation to allow for a default assignment of a decision to the owner of the activity

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

    Allow a notation to allow for a default assignment of a decision to the owner of the activity (this is probably the normal circumstances). This is both a UML / SysML issue

  • Reported: UML 2.5b1 — Mon, 22 Oct 2012 04:00 GMT
  • Updated: Wed, 28 Jun 2017 16:23 GMT

Location: Figure 15-43 ActivityFinalNode example - Balancing Decision / Merge

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

    Diagramming style should reflect good diagramming and programming practice, which is NOT to share merge diamonds. This is like two IF statements sharing the same ENDIF

    If there are two decisions there should be two merges (in the majority of cases)

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Wed, 28 Jun 2017 16:22 GMT

Location: Page 413, 15.3.2 Abstract Syntax Control Nodes Figure 15-26

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

    Type Limitations on DecisionInputFlows

    It also does not seem logical necessary to restrict the decisionInputFlow to be an Objectflow. Though a ControlFlow has no value, it could be present or null, which could be tested to enable or disable the decision.

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Wed, 28 Jun 2017 16:22 GMT

Restrictions on decision nodes

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

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

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

    Or

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

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

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

Unspecified and inconsistent notation for Observations

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

    The specification says about the notation of Observations:

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

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

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

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

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

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

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

ReturnValueRecipient missing in Metamodel Diagram of InteractionUse

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

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

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

Figure 17.20 "InteractionUse with value return" shows incorrect notation

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

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

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

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

Undefined notation for ownedBehaviors in Figures 17.23 and 17.24

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

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

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

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

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

Instances are linked to other instances, not associated

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

    On page 198 it says:

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

    and on page 199:

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

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

    Suggestion
    Reword the sentences above:
    Page 198:

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

    and on page 199:

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

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

Odd restriction on state machine redefinition context

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

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

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

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

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

Clarify diagram notation for collection parameters in operation

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

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

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

Transistion selection algorithm is incomplete

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

    The specification says about the state machine transition selection algorithm:

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

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

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

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

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

    Suggestion
    reprase the sentence in "conflicting Transitions":

    Transitions in mutually orthogonal Regions are not conflicting.

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

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

UML: Missing property subset for StateMachine::extendedStateMachine

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

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

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

Nested activities in activity diagrams

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

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

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

Template binding relationship incorrect notation

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

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

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

bad example for weight in Figure 15.21

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

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

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

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

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

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

ActivityEdge weight examples

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

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

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

Implication of weight of ActivityEdge is unclear

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

    The specification says in 15.2.3.3:

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

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

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

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

    Suggestion
    After

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

    Add

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

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

Conjugated port properties shown on association ends and in compartments

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

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

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

Actor Relationships

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

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

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

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

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

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

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

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

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

Incorrect arrow heads for object flows

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

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

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

Ambiguous meaning of word "composed"

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

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

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

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

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

Section: Annex A: Diagrams

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

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

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

ClassB::height missing from diagram

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

    id

    Unknown macro: {redefines name}

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

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

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

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

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

    The socket does not have a name above it.

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

Section 14.2.4.4 is not a real section

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

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

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

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

Why is Association.memberEnd ordered?

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

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

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

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

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

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

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

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

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

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

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

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

Transition guards should be its own section.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

State machine semantics for transition between regions of an orthogonal state

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

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

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

Invalid XMI elements containing both xmi:type and href

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

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

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

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

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

Missing visibility definition

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

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

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

What is a "compound state"?

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

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

    Please define.

    See 14.2.3.8.4 p 313

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

All actions should be able to own control pins

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

    The specification says:

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

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

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

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

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

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

Missing Constraint: Associations cannot type StructuralFeatures

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

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

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

Actor association constraint makes UseCase subclass of Class

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

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

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

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

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

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

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

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

    Jon Siegel, OMG
    20161104

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

What is "a separate InteractionConstraint"?

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

    The specification says:

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

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

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

Loop notation

  • Key: UML241-45
  • Legacy Issue Number: 7590
  • Status: open  
  • Source: TMNA Services ( Jim Schardt)
  • Summary:

    I am putting together an example of a sequence diagram using the loop
    combinedFragment. The spec seems confusing. Just where does a guard
    condition that is not the minint or maxint get placed?

    According the CombinedFragemt definition, I can describe a minimum and
    maximum number of times to perform the loop. "The Guard may include a lower
    and an upper number of iterations of the loop as well as a Boolean
    expression." I can also describe a guard condition. However, the notation
    describes a syntax like LOOP (minint, maxint) with no extra guard.

    Do I place the extra guard as an interaction constraint in a region as shown
    in figure 333. Is this allowed? Do I only get one interaction constraint
    (either the min,maxint or the separate interaction constraint in the body of
    the loop combined fragment?

    I would like to say something like LOOP 1, * [status = notFound] or LOOP
    (1,*,status = notFound). I suppose I could say LOOP (1,[status = notFound]).
    All of these should say that the loop interaction is performed at least
    once. After that if the status is "notFound" then the loop continues
    otherwise the loop terminates.

  • Reported: UML 1.4.2 — Mon, 12 Jul 2004 04:00 GMT
  • Updated: Fri, 19 Aug 2016 09:33 GMT

XOR Constraint modeling

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

    Fgure 7.16 of the UML 2.5 specification shows an

    {xor}

    constraint. How is this encoded in the UML model?

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

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

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

Inconsistent constraints about several kinds of UML Diagrams

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

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

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

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

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

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

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

OpaqueExpression should own Behavior

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

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

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

Semantics of Lifeline.selector not clear

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

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

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

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

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

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

Notation is depreciated for inherited interface

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

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

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

Comment is misleading

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

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

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

    I think this text should be deleted.

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

Mixed plural/singular

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

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

    Whoever it might be better to rewrite the sentence:

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

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

Plural vs Singulr?

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

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

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

Unclear sentence

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

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

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

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

Missing words in sentence

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

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

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

reply messages in interactions

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

    Similar situation with reply messages in interactions.

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

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

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

Subclasses of InstanceSpecification

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

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

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

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

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

ValueSpecification that refers to some Element shall be defined

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

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

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

Ability to define "context specific" default values for Part

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

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

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

problems with BehavioralFeature::method

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

    We are experiencing problems while trying to support "functional allocations" - building behavioral/functional models separately from structural designs and reusing functions in alternative structural designs.

    The UML metamodel problems:

    1. Behavior can't be owned "outside" Classifier owning the operation and used as it's method (so not behavior libraries are possible).
    2. Behaviors can't be reused, cause it may have only one Operation ([0..1]) as specification (no reuse in alternative designs are possible)
    3. Operation may have multiple methods ([0..*]) - redefining behaviors in subtypes. As a result, operation in super class is modified every time new behavior implements an operation and depends on subtypes, which is not acceptable.

    Clarifications and possible spec corrections are highly appreciated.

    UML 2.5 beta spec says:

     method : Behavior [0..*] (opposite Behavior::specification) A Behavior that implements the BehavioralFeature. There may be at most one Behavior for a particular pairing of a Classifier (as owner of the Behavior) and a BehavioralFeature (as specification of the Behavior).

     specification : BehavioralFeature [0..1] (opposite BehavioralFeature::method) Designates a BehavioralFeature that the Behavior implements. The BehavioralFeature must be owned by the BehavioredClassifier that owns the Behavior or be inherited by it. The Parameters of the BehavioralFeature and the implementing Behavior must match. A Behavior does not need to have a specification, in which case it either is the classifierBehavior of a BehavioredClassifier or it can only be invoked by another Behavior of the Classifier.

    Proposed changes:
    1. Don't constrain where behavior must be owned to implement operation.
    2. Let the same behavior be a method of more than one Operation.
    3. change the rules, how Behavior::context is derived (now it is derived from the chain of the owners, but could be derived from the specification owner or ActivityPartition's represented elements) or make it non-derived.
    4. Allow one method only and use redefining Operations instead.

  • Reported: UML 2.5b1 — Thu, 1 Aug 2013 04:00 GMT
  • Updated: Sun, 8 May 2016 05:12 GMT

Interaction parameters.

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

    Other related issue - Interaction parameters.

    When Interaction itself is set as a method of Operation with parameters, how these are represented in Sequence Diagram? Can Parameter be represented as a lifeline? (Parameter is ConnectableElement).

    How value returning is represented?

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Sun, 8 May 2016 02:29 GMT

How should context be represented?

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

    We have similar issues to represent calls to self/context. How context should be represented? As lifeline with keyword "self" or "this"?

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Updated: Sun, 8 May 2016 02:29 GMT

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

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

    Figure 11.29 has the correct ordering:

    • summary of figure
    • the figure
    • explanation of figure

    Figure 11.30 has an incorrect ordering:

    • summary of figure
    • explanation of figure
    • the figure

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

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

Link to "see" sections missing

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

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

    are missing clickable cross-references.

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

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

AssociationEnd/Attribute redefintion consistency

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

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

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

    "6.4.2 The constraint

    {redefines endA}

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

    suggests such a redefinition is wrong.

    "9.9.17.7 Property::isConsistentWith"

    does not exclude such a redefinition..

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

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

Why is a qualified association qualifier composed by a Property?

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

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

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

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

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

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

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

UML should support proxies for linking models

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

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

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

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

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

No UML approach to create an infix operator

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

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

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

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

Parameter types required for operation parameters

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

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

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

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

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

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

TypeElement / TypedElement typo

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

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

    A similar typo occurs in 7.5.3.

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

Constraint TemplateSignature::own_elements too constraining

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

    The Constraint TemplateSignature::own_elements says:

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

    This is not always possible.

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

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

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

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

Need example of derived qualifier.

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

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

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

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

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

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

The Kind field from frame names should be bold

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

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

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

    Please correct the list on page 682.

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

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

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

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

Need BNF for Protocol State Machines Transitions

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Package names in wrong location.

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

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

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

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

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

    Please make consistent or relax the location rules

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

Sequence Diagram Message Numbers

  • Key: UMLR-666
  • Status: open  
  • Source: Dassault Systemes ( Mr. James L. Logan III)
  • Summary:

    In the UML 2.5 spec (formal-15-03-01), there seems to be an erroneous Figure 17.10 showing message numbers on a sequence diagram. I can find no other mention of numbers for messages. Not in 17.4.4 (Notation) or in 17.4.5 (Examples). Am I missing something?

  • Reported: UML 2.5 — Sun, 28 Feb 2016 16:36 GMT
  • Updated: Mon, 29 Feb 2016 08:11 GMT

Disjointness should be independent of generalization

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

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

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

section 7.3.17 /EnumerationLiteral should not be an InstanceSpecification

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

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

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

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

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

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

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

Impossiblity to specify links for connected roles.

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

    The specification says

    [...]Associations, [...] specify links between any suitably-typed instance of the associated Classifiers, Connectors specify links between instances playing the connected roles [...]

    A link specified by an Association can be modeled by an InstanceSpecification. A link only specified by a Connector cannot be modeled, since Connector is not a Classifier.

    That means that no object-diagram can show the links between connected roles, when the Connector is not typed by an Association. It doesn't help, that the InstanceSpecification could be left without classifier. In this case, it would not be possible to define the linked instances, since an InstanceSpecification without classifier can't have Slots.

  • Reported: UML 2.5 — Fri, 26 Feb 2016 18:00 GMT
  • Updated: Fri, 26 Feb 2016 18:00 GMT

Delegation Connector should not be typed

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

    The Specification says

    A delegation Connector [...] links a Port to a role within the owning EncapsulatedClassifier. It represents the forwarding of requests.

    What would be the meaning of an Association used as a type for this Connector? I fail to see one. Should there be a Constraint, that doesn't allow a type for a delegation Connector?

    Suggestion
    Add following Constraint to the Connector definition
    inv: self.kind = ConnectorKind::delegation implies type = null
    (OCL needs to be verified, I'm not sure that it is valid)

  • Reported: UML 2.5 — Fri, 26 Feb 2016 17:24 GMT
  • Updated: Fri, 26 Feb 2016 17:24 GMT

Decide whether the document divisions are "sub clauses" or "subclauses"

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

    The spec uses both.
    The spelling with the space predominates.

    ISO probably has a preference. Their document How to write standards http://www.iso.org/iso/how-to-write-standards.pdf use "subclauses" as one word.

    However some of their actual documents use either "subclauses" or "sub-clauses". I didn't see anyone using "sub clauses" and their documents appear to be internally consistent.

  • Reported: UML 2.5 — Wed, 24 Feb 2016 03:15 GMT
  • Updated: Wed, 24 Feb 2016 07:32 GMT

What are the type/classifiers of an InstanceValue

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

    An InstanceValue instance is part of two type systems. As a derived TypedElement, its type is UML::InstanceValue. As an InstanceSpecification.instance, its type is the InstanceSpecification::classifier(s).

    This is confusing to users who may attempt to use oclType() to access the type and get the 'wrong' type. (See http://issues.omg.org/browse/OCL25-206 and linked Eclipse OCL issues.)

    Suggest addition of:

    ValueSpecification::umlClassifiers() : Set(Classifier) = type->asSet()

    InstanceValue::umlClassifiers() : Set(Classifier) = instance.classifier

    These should contrast obviously with oclType() and its SMOF oclTypes() extension.

  • Reported: UML 2.5 — Tue, 16 Feb 2016 10:32 GMT
  • Updated: Thu, 18 Feb 2016 13:44 GMT

Unexpected trigger reception has contradictory results in Protocol State Machines

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

    On page 340, we have a definition of a unexpected trigger reception.
    14.4.3.2.1 Unexpected trigger reception
    The interpretation of the reception of an Event occurrence that does not match a valid trigger for the current State, state invariant, or pre-condition is not defined (e.g., it can be ignored, rejected, or deferred; an exception can be raised; or the application can stop on an error). It corresponds semantically to a pre-condition violation, for which no predefined Behavior is defined in UML

    However, in 14.4.3.2.3 under Unreferred Operations. We have:
    Unreferred Operations
    If a BehavioralFeature is not referred by any ProtocolTransition, then the operation can be called for any State of the ProtocolStateMachine, and will not change the current State or pre- and post-conditions.


    The problem I have is that an Unreferred operation fits the criteria for an Unexpected Trigger reception – as it does not match a valid trigger for the current state.

    It may be that once a behavioral feature is referred to on any of the PSM states, then it loses it's potentiality to be an unreferred to operation. If that is so, it should be made much clearer.

    But it is still not very useful. Imagine a protocol state machine with many states. Now imagine an operation that can be called while the psm is any of these states (with no precondition, post-condition, or state change). This would allow the PSM not to mention the behavior at all. Now imagine a change that would prohibit the operation from only one state. Perhaps it's not allowed while initializing. To model this all the states would have to explicitly mention this operation, which is a unwieldy solution.

    It is also unclear about the scope. If the classifier has a) more than one PSM or b) different concurrent regions within one PSM. Is an unreferred to behavioral feature evaluated by looking at the concurrent region, or by looking at the sum of all the PSMs for the classifier

  • Reported: UML 2.5 — Mon, 15 Feb 2016 22:44 GMT
  • Updated: Tue, 16 Feb 2016 20:46 GMT

What does calling an "operation for a state" mean in PSM.

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

    in 14.4.3.2.4, the text says:
    Unreferred Operations
    If a BehavioralFeature is not referred by any ProtocolTransition, then the operation can be called for any State of the ProtocolStateMachine, and will not change the current State or pre- and post-conditions.

    The phrase "the operation can be called for any State of the PSM" does not seem to conform to normal UML syntax.

    Please change to something like. "...the operation can be called on the Classifier while in any State of the ProtocolStateMachine"

  • Reported: UML 2.5 — Mon, 15 Feb 2016 23:48 GMT
  • Updated: Mon, 15 Feb 2016 23:48 GMT

No notation for associations defined for abstract classes

  • Key: UMLR-658
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Cory Casanave)
  • Summary:

    Use of abstraction is an essential part of design. One way UML supports abstraction is with abstract classes and their subclasses. For semantic clarity and precision, associations are defined on these abstract classes.
    However, when presented to stakeholders the view frequently needs to be "flattened" to more concrete classes Such concrete classes that subclass more abstract classes may show inherited properties and operations without showing the abstractions. The same is not true of associations - there is no way to show associations between concrete classes that are derived from abstract classes. This results in the abstractions becoming confusing and/or incomplete. Not all people can follow the abstractions.
    The suggested resolution is, on a class diagram, to allow associations to be shown between classes where that association is defined between supertypes of the more concrete classes. This "inherited association" should have some visible marker, such as a greyed out line.
    The result would be a "flattened view" of an abstract hierarchy more accessible to stakeholders only interested in the more concrete representation.

  • Reported: UML 2.5 — Thu, 4 Feb 2016 21:06 GMT
  • Updated: Tue, 9 Feb 2016 14:46 GMT

UML:Notational option to display inherited features in a subclass

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

    The ability to see the inherited features is often necessary, however, such items should be displayed in a graphically consistent manner – and available on all tools.

  • Reported: UML 2.5 — Mon, 11 Jan 2010 05:00 GMT
  • Updated: Mon, 8 Feb 2016 23:06 GMT

Deploying a «deployment spec» has no explicit interpretation

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

    In figure 19.6 "DeploymentSpecifications related to the DeployedArtifacts that they parameterize."
    there is a «deployment spec» with a dependency replacement to an «artifact», but there is a «deployment spec» that is contained with no relationship to anything. The possible interpretation for the later containment is that it is A) a physical containment, B) a deployment (as with the other contained artifacts), or C) a "configuration" of the deployment of the containing artifact, ShoppingApp.ear.

    Problem 1) There is not sufficient guidance to choose about A,B,C or something else
    Problem 2) The parameterization referred to in the diagram title is not justifiable. If interpretation C) is intended, which is my guess, the title should be have parameterize-->configure, so that a new term is not introduced. Even if C) is not intended, the title should be changed.

  • Reported: UML 2.5 — Mon, 8 Feb 2016 22:19 GMT
  • Updated: Mon, 8 Feb 2016 22:19 GMT

Shoppin->Shopping

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

    Spelling error on Figure 19.6 page 686.

    ShoppinCart.jar should be ShoppingCart.jar

    Identical problem occurs on Figure 19.2 page 685
    Figure 19.3 page 685

  • Reported: UML 2.5 — Mon, 8 Feb 2016 17:57 GMT
  • Updated: Mon, 8 Feb 2016 22:02 GMT

UML 2.5 refers to EBNF, but the spec uses a variant BNF, not EBNF

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

    In 8.2.4 Notation, the 6th bullet (page 70), we have:

    This notation is specified by the following EBNF rules:

    However, in 6.4 How to Read this Specification, last paragraph of page 16, we have

    For textual notations a variant of the Backus-Naur Form (BNF) is often used to specify the legal formats. The conventions of this BNF are:

    Everywhere else in the spec the notation is called BNF.

    Please fix this by deleting the "E" in EBNF on p 70.

  • Reported: UML 2.5 — Thu, 4 Feb 2016 06:37 GMT
  • Updated: Thu, 4 Feb 2016 06:37 GMT

Classifiers can contain Packages, but they can't have appropriate visibility

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

    It appears that Classes, as Namespaces, can contain Packages.

    The consequences of this are unclear and a bit confusing.

    For example, a package within a class can contain attributes for organization purposes.

    It appears that the package can have visibility that is marked private or public, but not protected nor package level visibility.

    In this case, when there is a package in the class, it appears that you can't make the package protected (and visible to a specialization of the class) or package level visibility (visible to member of any immediate outer package).

  • Reported: UML 2.5 — Tue, 4 Nov 2014 03:00 GMT
  • Updated: Sat, 30 Jan 2016 12:07 GMT

Pin rectangles in examples should not overlap the action border

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

    The specification says:

    Pin rectangles may be notated as small rectangles that are attached to the symbol for the Action that owns them.

    There is one other option to show pins:

    The situation in which the OutputPin of one Action is connected to the InputPin of the same name in another Action via an ObjectFlow may be shown by the optional notations of Figure 16.6.

    This Figure shows a rectangle in the middle between two actions.

    In many diagrams the Pins are shown overlapping the border of their owning Action. According to the specification this is wrong. I suggest to correct following Figures:

    • 15.63
    • 15.64 (here additionally the frame should be dashed and the keyword «structured» is missing)
    • 16.50
    • 16.52
    • 16.53
  • Reported: UML 2.5 — Thu, 28 Jan 2016 18:43 GMT
  • Updated: Thu, 28 Jan 2016 18:43 GMT

Activity Generalization is underspecified

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

    Inheritance is specified as

    When a Classifier is generalized, certain members of its generalizations are inherited

    There is a derived attribute /inheritedMember, whose derivation is given in OCL, making it perfectly clear, what is inherited.
    In Activities the inherited elements are defined only in the semantics paragraph:

    A specialized Activity inherits the nodes and edges of its general Activities.

    Since they are not members of the Activity, /inheritedMember will not contain them.

    Suggestion
    Add two derived attributes /inheritedNode and /inheritedEdge and specify the derivation.

  • Reported: UML 2.5 — Wed, 27 Jan 2016 18:56 GMT
  • Updated: Wed, 27 Jan 2016 18:56 GMT

Rename Specialization/Generalization between abstract classes

  • Key: UMLR-315
  • Legacy Issue Number: 19322
  • Status: open  
  • Source: NobleProg Ltd ( Bernard Szlachta)
  • Summary:

    Inheritance between an abstract and a solid class should not be named Inheritance (or specialization or generalization).
    Reason: If abstract classes do not have filled in methods, the concrete class just implements them, not extend. Therefore inheritance between concrete class and an abstract class is really an implementation. But implementation is used for interfaces. Therefore we need different name to describe the relationship between abstract class and concrete class.

  • Reported: UML 2.5 — Mon, 31 Mar 2014 04:00 GMT
  • Updated: Wed, 27 Jan 2016 17:54 GMT

Contradiction between the abstract syntax and semantics of an Interval

  • Key: UMLR-449
  • Legacy Issue Number: 18683
  • Status: open  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    In UML 2.5 Beta1, section 8.5.3, the semantics of an Interval specifies that:

    An Interval is evaluated by first evaluating each of its constituent ValueSpecifications, which must each evaluate to a single value.
    The value of the Interval is then the range from the min value to the max value—that is, the set of all values greater than or equal to the min value and less than or equal to the max value (which may be the empty set).

    The semantics suggests that an Interval would own its constituent min/max ValueSpecifications; however, the abstract syntax shown in Fig 8.4 shows otherwise: min/max do not have composite aggregation.
    This means that:
    An Interval does not own its constituent min/max ValueSpecifications
    The same ValueSpecification can be used as the min or max of more than one Interval (I.e., multiple Interval can share the same min/max ValueSpecification)
    Intervals are the only ValueSpecifications that do not compositionally own their constituent parts:
    LiteralSpecifications compositionally own their values
    Expressions compositionally own their operands and sub-expressions
    Durations and TimeExpressions own their expressions.
    Some ValueSpecifications have non-compositional properties but these do not have the semantics of "constituent parts" like min/max do for Interval:
    TimeObservations and DurationObservations refer to events non-compositionally
    TImeExpressions and Durations refer to optional observations
    OpaqueExpressions optionally refer to behavior and behavior result parameters non-compositionally.
    Suggest changing all min/max association end properties defined in Interval, TimeInterval and DurationInterval to have composite aggregation.

  • Reported: UML 2.5b1 — Sat, 20 Apr 2013 04:00 GMT
  • Updated: Mon, 25 Jan 2016 20:10 GMT
  • Attachments:

In Sequence diagrams, the duration constraint shown as a vertical two-headed is ambiguous

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

    If the duration constraint goes from the midst of one message to the midst of another (e.g., the return message), it is unclear whether it is from Start Msg1 to Start Msg2, End Msg1 to End MSg2, Start1 to End Msg2, or End1 to Start Msg2.

    How should this be disambiguated

  • Reported: UML 2.5 — Thu, 21 Jan 2016 17:09 GMT
  • Updated: Thu, 21 Jan 2016 17:09 GMT

In the time-related syntax for Sequence diagrams, there are used two terms (now, duration). Are there more? Are these defined?

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

    See Summary

  • Reported: UML 2.5 — Thu, 21 Jan 2016 16:31 GMT
  • Updated: Thu, 21 Jan 2016 16:31 GMT

It doesn't seem possible to use a time-based trigger in the alternate format transition-focused state machine.

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

    Signal receipt symbol
    ....
    Where <trigger> is specified as described in sub clause 13.3.4 with the restriction that only Signal and change Event types are
    allowed.
    ...

    How can I show, using the alternative format, a time trigger

  • Reported: UML 2.5 — Thu, 21 Jan 2016 16:29 GMT
  • Updated: Thu, 21 Jan 2016 16:29 GMT

Use of decomposition indicator

  • Key: UMLR-649
  • Legacy Issue Number: 19879
  • Status: open  
  • Source: Anonymous
  • Summary:

    Fig. 14.8 uses a decomposition indicator (a lying 8) which is not defined in the document. Actually it is already in UML 1.5 (fig. 3-74 on p. 3-141) in the HiddenComposite. There needs to be some formal description of this icon.

    Actually in Enterprise Architect this icon is used as commonplace for decomposition of arbitrary elements. This is a very convenient feature and it should be part of the general UML specification.

  • Reported: UML 2.5 — Mon, 7 Dec 2015 05:00 GMT
  • Updated: Tue, 5 Jan 2016 21:30 GMT

InstanceSpecification for a qualified Property

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

    As far as I can see, there is no possibility to specify an instance for a Class with a qualified Property.

    In figure 11.37 there is the example of a Class Bank that is associated with a Person with the qualifier accountNo. Where would the accountNo be specified in an InstanceSpecification of the Bank?

    If this is intentionally left out, this intention should be mentioned in the specification.

  • Reported: UML 2.5 — Mon, 4 Jan 2016 14:37 GMT
  • Updated: Mon, 4 Jan 2016 14:37 GMT

Recursive use of Interaction Use

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

    It appears possible that an interaction use refers to an interaction that it also appears in causing a kind of recursive call.

    This capability is not a problem (to me), but the specification should probably say something about this – limitations, constraints, etc.

  • Reported: UML 2.5 — Thu, 3 Dec 2015 02:20 GMT
  • Updated: Thu, 3 Dec 2015 07:04 GMT

Limitation on isDimension Partition to be uncontained appears unwarranted

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

    In 15.7.7.6 a constraint state that an isDimension Activity Partition may not be contained in another Activity Partition.

    Certain common modeling situations arise that make hierarchical dimensions of more than 2 levels useful.

    For example. Let Location be an isDimension ActivityPartition. It could have three lowerlevel partitions: US, EU, Other. Within the US, we could lower-level partitions, NY, Chicago, and Miami and so forth. It seems to me that the US would be also be an isDimension Activity Partition.

  • Reported: UML 2.5 — Thu, 3 Dec 2015 02:47 GMT
  • Updated: Thu, 3 Dec 2015 02:47 GMT

Classifier.allSlottableFeatures shall incorporate redefinition

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

    The Operation Classifier.allSlottableFeatures() is not correct for it does not take into account potentially redefined StructuralFeatures. This leads to a situation where Feature are defined as slottable that are, in fact, not visible in the scope of the Classifier of an InstanceSpecification.

    There are two options:
    1. Enhance allSlottableFeatures in a way that redefined StructuralFeatures are resolved first.
    2. Introduce another operation allEffectiveSlottableFeatures that invokes allSlottableFeatures and resolves the redefinition of those Features afterwards.

    In my opinion, option 1 should be followed.

  • Reported: UML 2.5 — Wed, 2 Dec 2015 05:00 GMT
  • Updated: Wed, 2 Dec 2015 20:24 GMT

Location of owning fully qualifed name not specified.

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

    When an package or other element is contained within another element, the path name / fully qualified name has no place to appear on the diagrams.

    In some tools they can appear below the Element name or above the Element name or in-line (as a prefix) with the Element name. The specification should clarify which, if any or all, are acceptable.

    Also, it should be clear that these paths are surrounded by {} or perhaps by [] or () or whatever. Currently, there is no guidance on what is acceptable,

  • Reported: UML 2.5 — Tue, 10 Nov 2015 22:33 GMT
  • Updated: Tue, 10 Nov 2015 22:33 GMT

Clarify the difference between «create» and «instantiate»

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

    The descriptions of these two dependencies seem to be identical in meaning and the UML discussion communities on LinkedIn and StackOverflow seem to be confused. It would help to have some differences identified. Here's my proposal.

    I use the dependency «Instantiate».when I mean a true object-oriented instantiation arrived at by calling the constructor (which is how the I would translate the model into code). I would use «Create» when it's a different kind of creation, either more indirect, conceptual, or using non-object-oriented features.

    Here are some examples. I would use «Create» to say Word-->«Create» a Document, a modeler «Create» a model. Though I normally wouldn't model this in detail, I would use «Create» to indicate a component «Create» a new database record, the database manager «Create» a new database, a programmer «Create» a new app. Or create a new element in an (non-object-oriented) array. These can happen without directly calling a traditional object-oriented constructor – and can't be directly converted to code.

    On the other hand, if I had a marriage operation on a person, it would probably «Instantiate» the association class object of marriage.

  • Reported: UML 2.5 — Tue, 10 Nov 2015 05:26 GMT
  • Updated: Tue, 10 Nov 2015 06:36 GMT

Missing parameter properties of stream and exception in BNF

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

    on Page 117 Paragraph 9.6.4 Notation, it says:

    The notation in class diagrams for exceptions and streaming Parameters on Operations has the keywords “exception” or “stream” in the property string.

    However, these are not shown as possible in the BNF definition of Operation Notation, nor in the section on Parameter notation in 9.4.4.

    I assume, though it is not completely clear that these keywords go on the parm-property and not the oper-property.

    Recommendations
    1) Modify the paragraph on 117 to say:

    The notation in class diagrams for exceptions and streaming Parameters on Operations has the keywords “exception” or “stream” in the parameter's property string.

    2) Modify the BNF in 9.4.4 as follows:

    <parm-property> indicates additional property values that apply to the Parameter.
    <parm-property> ::= ’ordered’ | ’unordered’ | ’unique’ | ’nonunique’ | ’seq’ | ’sequence’ | 'exception' | 'stream' where...

    and add after (on page 109)

    • ’seq’ or ’sequence’ applies when there is a multi-valued Parameter and means that its values constitute an ordered bag, i.e., isUnique = false and isOrdered = true.

    the following:

    • 'exception' indicates that this parameter has isException = true.
    • 'stream' indicates that this parameter has isStreaming = true.
  • Reported: UML 2.5 — Mon, 9 Nov 2015 17:52 GMT
  • Updated: Mon, 9 Nov 2015 17:52 GMT

What is the order for EnumerationLiterals?

  • Key: UMLR-637
  • Legacy Issue Number: 19850
  • Status: open  
  • Source: Anonymous
  • Summary:

    The constraint #1 (i.e., Matching EnumerationLiterals must be in the same order.) indicates the order of literals is meaningful and important for enumeration. So the question is what is the order for none matching literals in the resulting enumeration? For example, consider enumeration A is

    {A, B, C, E}

    and enumeration B (matching A) is

    {A, C, D, F}

    , what is the order for literals E, D, and F in the resulting enumeration?

  • Reported: UML 2.5 — Thu, 5 Nov 2015 05:00 GMT
  • Updated: Sun, 8 Nov 2015 21:38 GMT

Wrong expression for dipicting package merge process?

  • Key: UMLR-639
  • Legacy Issue Number: 19852
  • Status: open  
  • Source: Anonymous
  • Summary:

    In the example, the specification says X is the receiving element and Y is the merged element for the representation X@Y. But the Figure 12.7 displays a reverse order for the receiving element and the merged element for element A. Is this a bug or I misunderstand it?

  • Reported: UML 2.5 — Thu, 5 Nov 2015 05:00 GMT
  • Updated: Thu, 5 Nov 2015 16:55 GMT

Inconsistency in constraints and rules for property merge

  • Key: UMLR-638
  • Legacy Issue Number: 19851
  • Status: open  
  • Source: Anonymous
  • Summary:

    The constraint #2 (i.e., The value of isUnique of matching Properties must be the same.) demands the values of isUnique for matching properties are the same, which is a prerequisite for merging, but the transformation rule #7 (i.e., For matching Properties: if either the merged and/or receiving elements have isUnique = false, the resulting element has isUnique = false; otherwise, the resulting element has isUnique = true.) ignores it. How to explain it?

  • Reported: UML 2.5 — Thu, 5 Nov 2015 05:00 GMT
  • Updated: Thu, 5 Nov 2015 16:55 GMT

How to deal with guard in Transition redefinition?

  • Key: UMLR-636
  • Legacy Issue Number: 19849
  • Status: open  
  • Source: Anonymous
  • Summary:

    In p. 336 (i.e., 14.3.3.1.2 Transition redefinition) of UML 2.5 specification, the spec. says "A Transition of an extended StateMachine may in the StateMachine extension be redefined. Transitions can have their effect and target State replaced, while the source State and trigger are preserved." It does not mention the guard property of Transition, so, the guard property must be preserved or can be replaced? Any ideas?

  • Reported: UML 2.5 — Thu, 5 Nov 2015 05:00 GMT
  • Updated: Thu, 5 Nov 2015 16:55 GMT

Typing error in figure 9.11

  • Key: UMLR-635
  • Legacy Issue Number: 19848
  • Status: open  
  • Source: Anonymous
  • Summary:

    "Integer = 7" in ClassB in Figure 9.11 should be "height: Integer = 7".

  • Reported: UML 2.5 — Thu, 5 Nov 2015 05:00 GMT
  • Updated: Thu, 5 Nov 2015 16:55 GMT

Wrong figure referrence in text

  • Key: UMLR-634
  • Legacy Issue Number: 19847
  • Status: open  
  • Source: Anonymous
  • Summary:

    In the first sentence "Figure 15.71 depicts multidimensional swimlanes." of the last paragraph on p. 408. It should be Figure 15.72, not 15.71.

  • Reported: UML 2.5 — Thu, 5 Nov 2015 05:00 GMT
  • Updated: Thu, 5 Nov 2015 16:55 GMT

Computation error for the example of ReduceAction

  • Key: UMLR-633
  • Legacy Issue Number: 19846
  • Status: open  
  • Source: Anonymous
  • Summary:

    the sum of (2, 7, 5, 3) in the example for ReduceAction should be 17, not 11.

  • Reported: UML 2.5 — Thu, 5 Nov 2015 05:00 GMT
  • Updated: Thu, 5 Nov 2015 16:55 GMT

UML 2: Lifeline should be made a TemplateableElement

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

    To support generic interaction specifications, it would be useful to make Lifeline a TemplateableElement. This would allow a given interaction specification to be used in multiple places with different instances playing the appropriate roles.

  • Reported: UML 2.5 — Wed, 21 Oct 2015 04:00 GMT
  • Updated: Fri, 23 Oct 2015 16:20 GMT

Semantics of UnlimitedNatural in notation section.

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

    Clause 8.2.4 (Notation) mentions that "unlimited" denotes a lack of limit and not infinity. This is semantics, rather than notation, would be better in 8.2.3.

  • Reported: UML 2.5 — Mon, 19 Oct 2015 13:19 GMT
  • Updated: Mon, 19 Oct 2015 13:19 GMT

Matching between '+-#~' in Property's and "public-private-protected-package" is not described

  • Key: UMLR-629
  • Legacy Issue Number: 19838
  • Status: open  
  • Source: Anonymous
  • Summary:

    In 9.5.4:
    <visibility> is the visibility of the Property. (See VisibilityKind - sub clause 7.4.)
    <visibility> ::= ‘+’ | ‘-‘ | ‘#’ | ‘~’

    In 7.8.24 VisibilityKind [Enumeration]:
    • public
    • private
    • protected
    • package

    Matching between keywords and symbols is not described anywhere.

  • Reported: UML 2.5 — Sun, 11 Oct 2015 04:00 GMT
  • Updated: Wed, 14 Oct 2015 16:24 GMT

Constraint wording implies aggregation is only for associations

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

    Filed for Alexander Knapp (DOL team).
    The third constraint in 11.8.1.8 says "Only binary Associations can be aggregations", which can be read to mean composite properties must be ends of associations (compare to the OCL). Suggested rewording: "Aggregate associations must be binary".

  • Reported: UML 2.5 — Fri, 9 Oct 2015 13:00 GMT
  • Updated: Fri, 9 Oct 2015 13:00 GMT

Need to constrain where triggers can be put in state machines

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

    There does not seem to be any constraint that prevents a transition that does not emanate from an actual State from having a trigger. This means, for instance, that a transition originating on an entry or exit pseudostate, or a history pseudostate, could have a trigger, which is semantically invalid.

    A constraint should be added to ensure that only transitions originating from an actual State (except for the Final state) can have a trigger.

  • Reported: UML 2.5 — Fri, 24 Jul 2015 04:00 GMT
  • Updated: Fri, 31 Jul 2015 20:45 GMT

Missing: how +-#~ symbols map to VisibilityKind

  • Key: UMLR-625
  • Legacy Issue Number: 19819
  • Status: open  
  • Source: Anonymous
  • Summary:

    Although section 7.8.24 describes the VisibilityKind enumeration and its values, and sections 9.5.4 and 9.6.4 state that the +, -, # and ~ symbols can be used to denote visibility, nowhere is the mapping made explicit.

    I would expect a list like that at the end of section 9.21.2 of format-12-05-06 or section 7.3.56 of formal-12-05-07:

    '+' public
    '-' private
    '#' protected
    '~' package

  • Reported: UML 2.5 — Sun, 26 Jul 2015 04:00 GMT
  • Updated: Fri, 31 Jul 2015 20:34 GMT

Example for association-like notation for attribute contradicts description.

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

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

    However, in Figure 9.12 on page 116, an example is given with the following problems
    1) No aggregation adornment is shown
    2) A navigation adornment is given
    3) An ownership ball is given.
    4) An association name (role) is given.
    5) Multiplicity is given

    I assume that the attribute this is supposed to illustrated is endName:ClassName.

    Also, it doesn't seem to make sense to use a hollow aggregation adornment, as this would allow an attribute to be shared, which is otherwise not possible.

    Please add a little text to this example, showing
    1) what notation is required
    2) How it is distinguished (if all all) from an actual association end.
    3) What the attribute name is derivable from the diagram

  • Reported: UML 2.5 — Mon, 6 Jul 2015 06:06 GMT
  • Updated: Tue, 7 Jul 2015 09:15 GMT

In OCL, the use of ::_'in' appears unwarranted

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

    In several places in the UML spec, we find the following expression

    ParameterDirectionKind::_'in'

    What are the leading _ and ' ' doing there.
    For example, on page 310 we have.

    body: ownedParameter->select(direction=ParameterDirectionKind::_'in' or direction=ParameterDirectionKind::inout)

    See that the inout literal does not require _ or the quotes.

    This appears to happen with all OCL mentions of the "in" literal

  • Reported: UML 2.5 — Thu, 4 Jun 2015 19:54 GMT
  • Updated: Thu, 4 Jun 2015 21:34 GMT

Define well-formed/ill-formed

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

    These terms are used in a few places and are very unclear. Are activity diagrams that are blocked (because of diverted forks) well-formed? Are non-deterministic diagrams well-formed?

  • Reported: UML 2.5 — Thu, 4 Jun 2015 01:19 GMT
  • Updated: Thu, 4 Jun 2015 06:51 GMT

Clarify Property Qualifiers with a full Example

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

    Figure 11.37 has an example with presumably an Association for:

    Bank::persons : Person[*]

    {opposites Person::banks}

    Person::banks : Bank[*]

    {opposites Bank::persons}

    adding explicit names for clarity.

    The qualifier presumably adds a nested Property

    Bank::persons::accountNo : Person[?]

    specifying an important multiplicity and a possibly redundant type, although a qualified association might perhaps return a derived type.

    Where is it modeled that the qualifier itself is Integer[1] or perhaps String[3]?

    Presumably an opposite qualifier is required and this must form part of a refined Association. If this is indeed the case it needs a better example. If it not the case, the alternative solution needs an example.

  • Reported: UML 2.5 — Tue, 2 Jun 2015 04:00 GMT
  • Updated: Tue, 2 Jun 2015 14:13 GMT

Class.isAbstract attribute is not necessary

  • Key: UMLR-619
  • Legacy Issue Number: 19756
  • Status: open  
  • Source: Anonymous
  • Summary:

    Class.isAbstract attribute has the same type, multiplicity and default value as Classifier.isAbstract. Meaning of these attributes is also the same. Probably the Class.isAbstract attribute is not necessary and can be removed

  • Reported: UML 2.5 — Fri, 8 May 2015 04:00 GMT
  • Updated: Fri, 8 May 2015 21:12 GMT

Missing glossary

  • Key: UMLR-429
  • Legacy Issue Number: 18856
  • Status: open  
  • Source: me.com ( Thomas Kilian)
  • Summary:

    The document is missing a glossary (like all previous UML specs). A glossary however is inevitable for any technical document to clarify the meaning of technical terms.

  • Reported: UML 2.5b1 — Wed, 7 Aug 2013 04:00 GMT
  • Updated: Thu, 23 Apr 2015 05:34 GMT

Multiplicity of opposite end of a number of associations from various action metaclasses

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

    The opposite ends to the properties have the multiplicity 0..1:

    • ClearAssociationAction::association
    • ReadExtentAction::classifier
    • ReadLinkObjectEndAction::end
    • ReadLinkObjectEndQualifierAction::qualifier
    • ReplyAction::replyToCall

    This means that there can be at most one action in a model for any one value of the above properties. This clearly incorrect. The multiplicity should be 0..* in all these cases.

  • Reported: UML 2.5 — Fri, 13 Feb 2015 17:33 GMT
  • Updated: Mon, 20 Apr 2015 14:37 GMT

isDirectlyInstantiated is defined in reverse

  • Key: UMLR-618
  • Legacy Issue Number: 19741
  • Status: open  
  • Source: Anonymous
  • Summary:

    The following paragraph from the specification defines isDirectlyInstantiated in reverse (need to swap "true" and "false"):

    The isDirectlyInstantiated property specifies the kind of instantiation that applies to a Component. If false, the Component is instantiated as an addressable object. If true, the Component is defined at design-time, but at run-time (or execution-time) an object specified by the Component does not exist, that is, the Component is instantiated indirectly, through the instantiation of its realizing Classifiers or parts.

  • Reported: UML 2.5 — Mon, 13 Apr 2015 04:00 GMT
  • Updated: Sun, 19 Apr 2015 23:20 GMT

7.2.3, last sentence 2nd paragraph the revised text

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

    In 7.2.3, last sentence 2nd paragraph the revised text says:

    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 (see also Clause 12 on Packages)

    The problem is that this wording allows for top-level Packages to potentially have more than one owning Element.

    I suggest:

    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, which may be un-owned. (see also Clause 12 on Packages)

  • Reported: UML 2.5b1 — Thu, 12 Sep 2013 04:00 GMT
  • Updated: Tue, 17 Mar 2015 07:39 GMT

Section: 8.5 Properties

  • Key: UMLDI-30
  • Legacy Issue Number: 8179
  • Status: open  
  • Source: Gentleware AG ( Stefan Mueller)
  • Summary:

    In Table 1 a few standardized properties are defined. To be more conveniened with other standards (mainly SVG)the DI should use the property names 'fill' and 'stroke' instead of 'BackgroundColor' and 'ForegroundColor'

  • Reported: UMLDI 1.0 — Mon, 31 Jan 2005 05:00 GMT
  • Updated: Wed, 11 Mar 2015 23:48 GMT

Invalid "diagram-interchange.xml" file in DI 2.0 's ptc/05-06-07 zip file

  • Key: UMLDI-28
  • Legacy Issue Number: 10660
  • Status: open  
  • Source: Adaptive ( Mr. Gene Mutschler)
  • Summary:

    I tried to load the diagram-interchange.xml file in the referenced zip file into the Rational Rose UML 1.4 xmi addin. This addin reports 4 errors:

    Could not add DataType "Image" to Logical View – probably duplicate name.
    Could not add DataType "Dimension" to Logical View – probably duplicate name.
    Could not add DataType "Point" to Logical View – probably duplicate name.
    Relation "Generalization" @ in 'Image' was not resolved – not added.

    The first three are cases where data type names duplicate classes in the same package. This is at least bad form, if not actually illegal. Rose does not allow it.

    THe final error is a case where one of the "generalization" references of the "Image" class points to a Generalization object that is not in the file:

    <UML:GeneralizableElement.generalization>

    <UML:Generalization xmi.idref="EAID_B3BDA775_38C1_4989_87D1_A4CDF297DA06"/>

    </UML:GeneralizableElement.generalization>

    There is no object with an ID of "EAID_B3BDA775_38C1_4989_87D1_A4CDF297DA06" in the file.

  • Reported: UMLDI 1.0b1 — Fri, 9 Feb 2007 05:00 GMT
  • Updated: Wed, 11 Mar 2015 04:40 GMT

Section: Annex C

  • Key: UMLDI-27
  • Legacy Issue Number: 10499
  • Status: open  
  • Source: PCMS ( Russell Block)
  • Summary:

    I was looking over the specification wanting to create a program that will be able to produce and read the format. However, I could use some clarification in Annex C, C.2.1 Class Diagram. There is no representation for an association. I had been, for a short time, believed that it was DiAssociationClass, but upon looking that up, I found it was not. For DiAssociationEnd, the tree does not match up with the example, as I understand it, in Annex B. Annex C says that the RoleAdornment should product a node with simpleSemanticModelElement of 'RoleAdornment'. But there is no such nesting. The GraphNode(<AssociationEnd>)'s next nestings go straight to 'name', 'visibility', and 'multiplicity'. Could you clarify this for me? Also in the zip example, there is an undefined compartment used called 'ExpressionCompartment'. DiAssociationClass refers to 'Stereotypes'. Is that supposed to be StereotypeCompartment? In C.1, there are a few areas where ',' appears that is should be '<'.

  • Reported: UMLDI 1.0b1 — Sat, 2 Dec 2006 05:00 GMT
  • Updated: Wed, 11 Mar 2015 04:40 GMT

di-schema.xsd

  • Key: UMLDI-29
  • Legacy Issue Number: 13533
  • Status: open  
  • Source: NHS ( Ravi Natarajan)
  • Summary:

    The di-schema.xsd available from the link http://www.omg.org/cgi-bin/doc?ptc/05-06-07 import namespace <xsd:import namespace="http://www.omg.org/XMI" schemaLocation="XMI.xsd"/>. XMI.xsd is not present in the same package throws schema error on di-schema.xsd. Where can be the approved XMI.xsd found that the di-schema refers to.

  • Reported: UMLDI 1.0b1 — Fri, 20 Feb 2009 05:00 GMT
  • Updated: Wed, 11 Mar 2015 04:40 GMT

Diagram Interchange clarification

  • Key: UMLDI-26
  • Legacy Issue Number: 8971
  • Status: open  
  • Source: gmx.de ( Ludger Goeke)
  • Summary:

    The following figure shall picture a Part of a composite structure
    diagram. Are the graphically informations like the colon that seperates the
    name and the type of the part, the brackets that surround the multiplicity,
    and the ".." points that display the range of the Multiplicity legal
    Diagram Interchange informations ? Till now I saved
    those informations as TextElements with a SimpleSemanticModelElement.
    Is this ok or can I disregard those informations ?

    ______________________________________

     
    myPart : myPartType [1..*]
    _____________________________________
  • Reported: UMLDI 1.0b1 — Fri, 19 Aug 2005 04:00 GMT
  • Updated: Wed, 11 Mar 2015 04:40 GMT

UML Mapping in DI specification inadequate

  • Key: UMLDI-25
  • Legacy Issue Number: 7663
  • Status: open  
  • Source: gmail.com ( Guus Ramackers)
  • Summary:

    The current mapping from the Diagram Interchange meta model to UML is inadequately specified in Appendix A of the DI specification. It will not enable a standard encoding of DI models from the UML 2.0 meta model across vendors. Specifically:

    • the mapping does not cover UML 2.0
    • the mapping solely consists of a table listing a subset of UML meta classes
    • the mapping does not cover the complexities of UML 2.0 decomposition details, as specified in the UML 2.0 specification in the area of Sequence Diagrams, Activity Diagrams and State Machines.
  • Reported: UMLDI 1.0b1 — Wed, 25 Aug 2004 04:00 GMT
  • Updated: Wed, 11 Mar 2015 04:40 GMT

UML diagram interchange: list updating and nested graph nodes

  • Key: UMLDI-24
  • Legacy Issue Number: 7271
  • Status: open  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    If you are going to represent list items like attributes or operations by nested graph nodes, what happens if the semantic element has changed (lost an operation or gained an attribute) after the diagram is created. When should the list be updated?

  • Reported: UMLDI 1.0b1 — Thu, 22 Apr 2004 04:00 GMT
  • Updated: Wed, 11 Mar 2015 04:40 GMT

UML diagram interchange: size of graph node with autosize

  • Key: UMLDI-23
  • Legacy Issue Number: 7270
  • Status: open  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    In case of autosize (the size property is omitted) all across the aggregation hierarchy, how would you calculate the size of a graph node?

  • Reported: UMLDI 1.0b1 — Thu, 22 Apr 2004 04:00 GMT
  • Updated: Wed, 11 Mar 2015 04:40 GMT

UML diagram interchange: use of bounds limiting

  • Key: UMLDI-22
  • Legacy Issue Number: 7269
  • Status: open  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The use of Bounds (x, y, width, height) as layout constraints maybe acceptable for rendering diagrams, but is not very suitable for editing ones that employ other types of layout algorithms that might not necessarily use a Bounds constraint. (attributes could be laid out in their compartment using a flow layout that only considers the order of attributes in their collection to be what is relevant to the layout).

  • Reported: UMLDI 1.0b1 — Thu, 22 Apr 2004 04:00 GMT
  • Updated: Wed, 11 Mar 2015 04:40 GMT

UML diagram interchange: schema usage needed

  • Key: UMLDI-21
  • Legacy Issue Number: 7259
  • Status: open  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The proposal mainly talks about the schema of the UML diagram notation. It does not detail the expected usage of that schema or the “format”. The format should at least include the view aggregation hierarchies and the view properties assignment (what properties are installed for every view). Recently there was an appendix that talks about the aggregation hierarchy.

  • Reported: UMLDI 1.0b1 — Thu, 22 Apr 2004 04:00 GMT
  • Updated: Wed, 11 Mar 2015 04:40 GMT

NamedElement::allNamespaces is invalid at model root

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

    The specified OCL body for NamedElement::allNamespaces has its tests in the wrong order and consequently fails at the root since in:

    if owner.oclIsKindOf(TemplateParameter) and
    owner.oclAsType(TemplateParameter).signature.template.oclIsKindOf(Namespace) then
    ...
    else
    if namespace->isEmpty()
    then ...

    At the root owner is null and the navigation results in invalid for both arms of the conjunction and consequently the if condition and if result.

    Suggest the more readable, less redundant and more correct:

    if owner = null
    then OrderedSet{}
    else
    let enclosingNamespace : Namespace =
    if owner.oclIsKindOf(TemplateParameter)
    and owner.oclAsType(TemplateParameter).signature.template.oclIsKindOf(Namespace)
    then owner.oclAsType(TemplateParameter).signature.template.oclAsType(Namespace)
    else namespace
    endif
    in enclosingNamespace.allNamespaces()->prepend(enclosingNamespace)
    endif

  • Reported: UML 2.5 — Sun, 20 Apr 2014 04:00 GMT
  • Updated: Wed, 11 Mar 2015 03:37 GMT

Section 15.5.3: a missed word

  • Key: UMLR-351
  • Legacy Issue Number: 19545
  • Status: open  
  • Source: mail.ru ( Alexei Zinoviev)
  • Summary:

    In fourth paragraph, phrase "While the ExecutableNode is executing, it is considered to hold a single control indicating it is execution." the word "token" is missed.
    The corrected sentence: "While the ExecutableNode is executing, it is considered to hold a single control token indicating it is execution."

  • Reported: UML 2.5 — Tue, 29 Jul 2014 20:23 GMT
  • Updated: Wed, 11 Mar 2015 03:36 GMT

Location: 18.1.5 Examples Figure 18-2. 689 - Explain about Navigation

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

    The example should be shown with navigation (arrows) on the associations, to indicate initiating (primary) and non-initiating (secondary) actors. This is legal and common notation
    This would partially address Issue 8855

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Updated: Mon, 9 Mar 2015 03:34 GMT

actions

  • Key: UML241-46
  • Legacy Issue Number: 7549
  • Status: open  
  • Source: Anonymous
  • Summary:

    In the opinion of some, "at present, the spec bases actions on foundations described in the activities section." However the text says: "An action is the fundamental unit of behavior specification." Thus the text contradicts the opinion. If the opinion is correct, the text should be corrected to agree

  • Reported: UML 2.0 — Wed, 16 Jun 2004 04:00 GMT
  • Updated: Sun, 8 Mar 2015 14:12 GMT

UML 2 Super/Interactions/ LOOP construct specifications

  • Key: UML241-40
  • Legacy Issue Number: 7617
  • Status: open  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    This issue is submitted on behalf of Craig Larman (see signature at the end fo this e-mail):

    Current: The LOOP keyword, used in sequence diagrams in a frame, has the syntax LOOP, LOOP( repeat ), or LOOP( min, max)

    Problem: Iteration over a collection of objects, sending the same “doX” message to each member is a very very common idiom, so it would be nice if the UML had an easy notation to support this (and otherwise, how will you reverse engineer to code to the right diagram case, or vice versa? It is currently not clear…). AAt present, it is not clear how to say “for i = 1 to collection.size”, nor is there support to allow this ‘i’ loop variable to be reference in a lifeline *selector*

    Solution:
    1. change the LOOP syntax to (in its fullest form), LOOP( <varName>, <start>, <end>, <increment>) e.g., LOOP( i, 1, 10, 1), or LOOP( i, 10, 1, -1). Increment should default to +1.
    a. Also <start> and <end> may be expressions referring to participants in the interaction, such as end = lineItems.size where lineItems is a collection of SalesLineItem objects. Note that there is already syntax for a “max” (similar to <end>), and one aspect of this change is making (or ensuring) it can be an expression involving lifeline participants, not just a constant.

    2. allow a lifeline contained within the frame to have its selector refer to the LOOP var. e.g., “ lineItems[ i ] : SalesLineItem” to indicate selecting one SalesLineItem from the lineItems collection, given the current value of ‘i’. Note that a selector such as “lineItem[ i ]” is already allowed in the spec (and there are examples in the spec). this request is for tying the ‘i’ variable to the LOOP construct.

    Variant Solutions:
    Perhaps the upper-bound can be handled in the LOOP guard instead. E.g., [ i < lineItems.size ]. However, in this case, i still need a way to indicate the incrementing of ‘i’, and the ability to legally refer to “i” in the selector “lineItems[ i ].

    i attach a picture to illustrate.

  • Reported: UML 1.4.2 — Tue, 3 Aug 2004 04:00 GMT
  • Updated: Sun, 8 Mar 2015 14:12 GMT

Section: 9.3.12

  • Key: UML241-41
  • Legacy Issue Number: 7614
  • Status: open  
  • Source: Missouri University of Science and Technology ( Thomas Weigert)
  • Summary:

    Instance values are depicted using the same icon as for the defining classifier. However, for parts this convenient notational convention is not defined. Allow to use the same icon as for the classifier that is the type of the part, when representing the part (modulo the namestring, which is necessarily different, as is the case with instance value also). As an example, a part that derives from an active class could then optionally be shown with the vertical side bars highlighting its active nature.

  • Reported: UML 2.0 — Tue, 3 Aug 2004 04:00 GMT
  • Updated: Sun, 8 Mar 2015 14:12 GMT

UML2 Superstructure - profiles

  • Key: UML241-38
  • Legacy Issue Number: 7780
  • Status: open  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    From the current spec I really can't work out what to implement. For what
    it's worth, this is what I think should be there:
    Properties can be typed either by MOF primitive types (the ones used in the
    UML metamodel, such as string, boolean and enumeration and subtypes), or by
    UML metaclasses. This is not only consistent wth UML 1.x, it also is likely
    to be the most easily implemented - vendors already need to provide a UI for
    editing boolean properties etc. and editing properties typed by metaclasses
    is easy - just use a list control to reference existing model elements.
    The spec seems to state that properties can typed by arbitrary model
    elements.("However, it is possible to have
    associations between ordinary classes, and from stereotypes to ordinary
    classes")
    How is a tool supposed to know what to do with it - it looks like the
    current spec allows a stereotype property to be typed by something like an
    Actor, not the actor metaclass, but some specific actor - what use is that?
    The more I read about this the more I'm convinced that we will never get
    interoperability, unless we tighten the rules as I suggested above.

  • Reported: UML 1.4.2 — Thu, 23 Sep 2004 04:00 GMT
  • Updated: Sun, 8 Mar 2015 14:12 GMT

Messages to ports with only one connector

  • Key: UML241-39
  • Legacy Issue Number: 7654
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The semantics of Port says:

    > If there is a connector attached to only one side of a port, any
    > requests arriving at this port will terminate at this port.

    but it also says:

    > For a behavior port, the instance of the owning classifier will
    > handle requests arriving at this port (as specified in the behavior
    > of the classifier, see Chapter 13, Common Behaviors), if this
    > classifier has any behavior.

    And presumably for non-behavior ports, the message could be forwarded to
    the intefaces of the owning classifier. So the first statement above is
    incorrect, isn't it?

  • Reported: UML 1.4.2 — Tue, 31 Aug 2004 04:00 GMT
  • Updated: Sun, 8 Mar 2015 14:12 GMT

Profiles

  • Key: UML241-42
  • Legacy Issue Number: 7608
  • Status: open  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    Issue with tags (i.e. properties of stereotypes); I can't see an example of
    display of multi-valued tags or tags whose types are UML metaclasses. There
    should be a normative mechanism for displaying these.

  • Reported: UML 1.4.2 — Wed, 28 Jul 2004 04:00 GMT
  • Updated: Sun, 8 Mar 2015 14:12 GMT

Wrong metamodel for internal transitions

  • Key: UML241-43
  • Legacy Issue Number: 7593
  • Status: open  
  • Source: International Business Machines ( Eran Gery [X] (Inactive))
  • Summary:

    Description: In the UML 2.0 statemachines an internal transition is modeled as a transition owned by a region.

    It is wrong that in order to specify an internal or local transition one needs

    to instantiate a region. This makes any state with local transitions a composite state which is wrong.

    Local/Internal transitions shall be owned directly by states and not via regions.

  • Reported: UML 1.4.2 — Fri, 16 Jul 2004 04:00 GMT
  • Updated: Sun, 8 Mar 2015 14:12 GMT

Section: 11.3.39

  • Key: UML241-37
  • Legacy Issue Number: 8184
  • Status: open  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Typo - Add an "s" to the first classifier in Description. The multiplicities for the associations newClassifier:Classifier[0..*] and oldClassifier:Classifer[0..*] do not agree with fig. 153. Please correct either figure or text - probably figure. Semantics need to clarify the differences/similarities between "existing," "old," and "new" classifiers

  • Reported: UML 2.0 — Mon, 31 Jan 2005 05:00 GMT
  • Updated: Sun, 8 Mar 2015 14:12 GMT

inadequate definition of 'constructor'

  • Key: UML241-36
  • Legacy Issue Number: 7866
  • Status: open  
  • Source: Capability Measurement ( Karl Frank)
  • Summary:

    The current "definition" of constructor, section 9.3.1 "Notation"
    subsection (page 75) leaves some issues.

    The description proposes a notation for associating an instance
    representation with a "constructor", noting only that a constructor is
    an operation that "must have the class as its classifier."

    Given a list of operations (_ _ is static):

    + newInstance(name:String):Foo
    + getFooForName(name:String):Foo
    + identity():Foo
    + clone():Foo
    + Foo(name:String):Foo
    + Foo(name:String):Foo
    + make(name:String):Foo

    Any of the above operations could be viewed as a constructor under the
    definition provided. The only marker suggested in the superstructure
    specification to clearly specify a constructor is a "<<create>>"
    assocation from the default instance created by the constructor.

    Assuming foo:Foo:
    Foo::newInstance("bar")
    foo.clone()
    Foo::make("bar")
    Foo::Foo("bar")
    In the predominant commercial OO languages, newInstance(...) and clone()
    are delegating the actual creation to Foo::Foo(...), but clone or copy
    may be the vehicles of instantiation in languages like io or self.

    If UML had a specific marker for constructors, like the stereotype
    "<<constructor>>" then OCL and other notations and tools could treat
    constructors specially where useful.

    The OCL specificaion already includes notation for Tuple and Collection
    "constructors" to specify what are essentially Tuple and Collection
    constants. Providing a standard marker for constructors might reliably
    allow similar clear constructs for all other types (ex. if baz >
    Foo(1.30, Currency::USDollars) then ...).

  • Reported: UML 1.4.2 — Sun, 17 Oct 2004 04:00 GMT
  • Updated: Sun, 8 Mar 2015 14:12 GMT

What is a mapping that is not computable?

  • Key: UML241-33
  • Legacy Issue Number: 7412
  • Status: open  
  • Source: X-Change Technologies ( Joaquin Miller)
  • Summary:

    "It is possible to specify a mapping between the specification and implementation elements, although it is not necessarily computable." What is a mapping that is not computable?

  • Reported: UML 2.0 — Tue, 1 Jun 2004 04:00 GMT
  • Updated: Sun, 8 Mar 2015 14:12 GMT

Components

  • Key: UML241-32
  • Legacy Issue Number: 7442
  • Status: open  
  • Source: Cutter Information ( Oliver Sims)
  • Summary:

    The Components chapter of the UML2 Superstructure spec does not specify what component generalization/specialization means. Is it intended that this be left unspecified? If not, then I propose the semantics described in a paper I wrote on this subject prior to the spec being adopted. The paper suggested an approach that is consistent with substitutability semantics, and should also be able to be made to work with most if not all component technologies. I'd be happy to email the paper to anyone interested.

  • Reported: UML 2.0 — Thu, 3 Jun 2004 04:00 GMT
  • Updated: Sun, 8 Mar 2015 14:12 GMT

DeploymentSpecification - notation for DeploymentSpecification on the insta

  • Key: UML241-35
  • Legacy Issue Number: 7154
  • Status: open  
  • Source: PostFinance ( Karl Guggisberg)
  • Summary:

    DeploymentSpecification - notation for DeploymentSpecification on the instance level

    There are several examples of DeploymentSpecification on the instance level which use the notation name: value (i.e. execution: thread) instead of the default notation for slots (see InstanceSpecification on p. 59) name = value (i.e. execution = thread)

    See - Figure 132 on page 191 - Table 8, 2nd row, 2nd column on page 199

  • Reported: UML 2.0 — Sat, 13 Mar 2004 05:00 GMT
  • Updated: Sun, 8 Mar 2015 14:12 GMT

UML Profile for DDS does not refer to WaitSet element

  • Key: UML4DDS-32
  • Legacy Issue Number: 16343
  • Status: open  
  • Source: International Business Machines ( Gidi Gal)
  • Summary:

    UML Profile for DDS does not refer to WaitSet element, though it is part of
    DCPS package in DDS specification.

  • Reported: UML4DDS 1.0b1 — Wed, 22 Jun 2011 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

format file url for qos_profile should be specified in more detail

  • Key: UML4DDS-31
  • Legacy Issue Number: 15289
  • Status: open  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    in order to get real interoperability the spec should be more precise on the format of the qos_profile attribute. If it is a file url, how do we specify which qos_profile within that file to select? If it is a XML string, could that contain multiple qos_profiles or should it only contain one?

  • Reported: UML4DDS 1.0b1 — Mon, 14 Jun 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Problematic type library specification

  • Key: UML4DDS-30
  • Legacy Issue Number: 15084
  • Status: open  
  • Source: DECA ( Rick Warren)
  • Summary:

    The Types model included in the UML Profile for Data Distribution has 3 significant high-level problems that the FTF should address. These are:

    P-1. It does not describe any normative DDS type system.

    The DDS specification does not define the range of data types that may be used with DDS implementations. Although it implies an IDL-based type system by its specification of an IDL-based PSM, it does not articulate (a) which portions of IDL are normative with respect to DDS and (b) what extensions to the IDL 2 (or 3, or 3+) type system may be necessary to support DDS-specific concepts.

    For example, with respect to (a), some DDS implementations support valuetypes while others do not. And at least some DDS implementations omit support for "any" and "fixed." With respect to (b), different DDS implementations indicate keys in different ways and treat keys differently when they occur within nested objects.

    The purpose of the UML Profile for Data Distribution is to facilitate the modeling of DDS-based applications such that those models may be transformed into executable code that compiles and links against existing DDS implementations. It defines conformance for a UML-based model and consequently for a tool capable of viewing and editing such a model. It does not define conformance for a DDS middleware implementation itself. It is therefore incorrect to consider it to define a normative DDS system that would constrain DDS implementations; it must either describe a type system that is specified elsewhere, or it must be considered non-normative:

    P-2. It is not clear whether it is intended to be normative itself.

    Level-1 conformance with the profile is defined to include the Topics package, and Types is a sub-package of Topics, so in some sense it is implied that Level-1 conformance includes the Types package. The Types package is also a common library between DCPS and DLRL, which implies it is a part of Level-2 conformance as well.

    However, a type-modeling facility was not called for in the RFP, and the Types package is really just a supporting package for Topics, so it is not required to be normative. Indeed, given (1) above, it may not actually be appropriate to consider it normative. There is a precedent for this kind of situation: UPDM uses a UML profile for BPMN in a supporting and non-normative role.

    P-3. It does not meet the needs of complex DDS-based systems.

    Complex DDS-based systems – especially systems of systems – require support for type substitution and evolution. (For example, if the type Bar extends the type Foo, I should be able to publish Bar to you if you subscribe to Foo. This is completely analogous to typical object-oriented type substitution rules. Furthermore, I should be able to extend our shared type definition in a future version of my component, and you should be able to consume instances of that evolved type with well-defined semantics without rebuilding and redeploying yourself.) The Types model does not address these use cases.

    POSSIBLE RESOLUTION:

    The proposed resolution consists of two parts:

    R-1. Declare unambiguously that the current Types package is non-normative. This declaration in itself would be enough to resolve this issue. Even though it only addresses P-2 directly, P-1 immediately becomes moot. P-3 may be considered out of scope of the UML Profile, as indeed it is out of scope of the DDS 1.2 specification itself.

    This degree of resolution is sufficient, strictly speaking, but not wholly satisfactory. Therefore:

    R-2. The "Extensible and Dynamic Topics Types for DDS" ("X-Topics") RFP was issued specifically to address (a) the ambiguities in the DDS type system pointed out in P-1 and (b) the lack of flexibility noted in P-3. Therefore, once a response to this RFP is available (the joint revised submission will be up for a vote in the Jacksonville 2010 meeting), the UML Profile could allow implementers to use that specification to describe their types in a fully normative way. This use of X-Topics by the UML Profile could either be declared non-normative, like the current lightweight Types model, or could be declared to be an additional normative-but-optional conformance point within the UML Profile specification (as X-Topics support will be optional for DDS implementations themselves).

    Depending on the relative timeline for X-Topics adoption and availability and the conclusion of the UML Profile FTF, R-2 could be implemented either during the current FTF or, if desired, during a subsequent RTF.

  • Reported: UML4DDS 1.0b1 — Wed, 24 Feb 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Figure 15-5:

  • Key: UML4DDS-33
  • Legacy Issue Number: 16353
  • Status: open  
  • Source: International Business Machines ( Gidi Gal)
  • Summary:

    Figure 15-5: The connecting lines between <<topic>> ActiveUser and
    <<subscriber>> sub and <<publisher>> pub are not clear. If the intention is
    to represent a connector, it is not possible in UML to connect a part
    (topic) to a part (subscriber\publisher) of of another class

  • Reported: UML4DDS 1.0b1 — Thu, 30 Jun 2011 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Figure 46: "manages" and "class" have not been defined previously.

  • Key: UML4DDS-29
  • Legacy Issue Number: 12832
  • Status: open  
  • Source: THALES ( Hugues Vincent)
  • Summary:

    Figure 46: "manages" and "class" have not been defined previously.

  • Reported: UML4DDS 1.0b1 — Thu, 4 Sep 2008 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 7.3.2.2: what is the "field" stereotype?

  • Key: UML4DDS-28
  • Legacy Issue Number: 12831
  • Status: open  
  • Source: THALES ( Hugues Vincent)
  • Summary:

    what is the "field" stereotype? I didn't find any "field" execpt in the DLRL part. If my understanding of the previous pages is good, "filed" should be removed" and "userID: long" should be replaced with "<<Primitive>> userID: long" and so forth.

  • Reported: UML4DDS 1.0b1 — Thu, 4 Sep 2008 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

domainParticipant needs to be considered as a Component *and* a ddsProperty

  • Key: UML4DDS-21
  • Legacy Issue Number: 12824
  • Status: open  
  • Source: THALES ( Hugues Vincent)
  • Summary:

    Looking at Figure 46 and following, it seems that domainParticipant needs to be considered as a Component and a ddsProperty.

  • Reported: UML4DDS 1.0b1 — Thu, 4 Sep 2008 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 7.2.5 figure 46

  • Key: UML4DDS-20
  • Legacy Issue Number: 12823
  • Status: open  
  • Source: THALES ( Hugues Vincent)
  • Summary:

    looking at Figure 46, it seems that subscribers and publishers need to be considered as Properties (to be a part of a structured class) and as a Class (to be able to receive ports) as well. I thus propose to design publisher and subscriber as ddsProperty and ddsSpecification

  • Reported: UML4DDS 1.0b1 — Thu, 4 Sep 2008 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

the name "relation" is syntactically too poor and too common

  • Key: UML4DDS-25
  • Legacy Issue Number: 12828
  • Status: open  
  • Source: THALES ( Hugues Vincent)
  • Summary:

    the name "relation" is syntactically too poor and too common to be used here. Please find something more specific (such as dlrlRelation for instance).

  • Reported: UML4DDS 1.0b1 — Thu, 4 Sep 2008 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 7.2.7 associations

  • Key: UML4DDS-24
  • Legacy Issue Number: 12827
  • Status: open  
  • Source: THALES ( Hugues Vincent)
  • Summary:

    it should be stated that the associations "homes", "topicmanages" and "criterion" subset the UML2 association between UML2::Class and UML2::Property

  • Reported: UML4DDS 1.0b1 — Thu, 4 Sep 2008 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 7.3.2.1: UML2 conformance

  • Key: UML4DDS-27
  • Legacy Issue Number: 12830
  • Status: open  
  • Source: THALES ( Hugues Vincent)
  • Summary:

    UML2 conformance: ActiveUser should be change with "active_user:UserType" and the "type" tag should be removed (as well as with ChatMessage and MessageType).

  • Reported: UML4DDS 1.0b1 — Thu, 4 Sep 2008 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Paragraph 7.3 is non normative and, thus, should be moved in an annex

  • Key: UML4DDS-26
  • Legacy Issue Number: 12829
  • Status: open  
  • Source: THALES ( Hugues Vincent)
  • Summary:

    Paragraph 7.3 is non normative and, thus, should be moved in an annex

  • Reported: UML4DDS 1.0b1 — Thu, 4 Sep 2008 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

missing link

  • Key: UML4DDS-23
  • Legacy Issue Number: 12826
  • Status: open  
  • Source: THALES ( Hugues Vincent)
  • Summary:

    There is no link between, on the one hand, publisher, subscriber, domainparticipant, datareader, datawriter and, on the other hand, qosProperty (I guess it should).

  • Reported: UML4DDS 1.0b1 — Thu, 4 Sep 2008 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

a domain needs to be considered as a ddsSpecification *and* a ddsProperty

  • Key: UML4DDS-22
  • Legacy Issue Number: 12825
  • Status: open  
  • Source: THALES ( Hugues Vincent)
  • Summary:

    Looking at Figure 46 and following, it seems that a domain needs to be considered as a ddsSpecification and a ddsProperty.

  • Reported: UML4DDS 1.0b1 — Thu, 4 Sep 2008 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 7.2.4 How are complememts of types designed?

  • Key: UML4DDS-19
  • Legacy Issue Number: 12822
  • Status: open  
  • Source: THALES ( Hugues Vincent)
  • Summary:

    How are designed the complements of the types? For instance, a "sequence" does not mean anything by itself: another type is needed to precise it.

  • Reported: UML4DDS 1.0b1 — Thu, 4 Sep 2008 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 7.2.3: TopicStruct and TopicField

  • Key: UML4DDS-18
  • Legacy Issue Number: 12821
  • Status: open  
  • Source: THALES ( Hugues Vincent)
  • Summary:

    TopicStruct and TopicField should specialize ddsSpecification and ddsProperty

  • Reported: UML4DDS 1.0b1 — Thu, 4 Sep 2008 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 7.2.3: constraint should be specified

  • Key: UML4DDS-17
  • Legacy Issue Number: 12820
  • Status: open  
  • Source: THALES ( Hugues Vincent)
  • Summary:

    A constraint should be specified to subset the UML2 associations "attribute" between TopicStruct and TopicField.

  • Reported: UML4DDS 1.0b1 — Thu, 4 Sep 2008 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 7.1.10: SharedKey is not specified anywhere

  • Key: UML4DDS-12
  • Legacy Issue Number: 12815
  • Status: open  
  • Source: THALES ( Hugues Vincent)
  • Summary:

    SharedKey is not specified anywhere (used elsewhere but never defined).

  • Reported: UML4DDS 1.0b1 — Thu, 4 Sep 2008 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 7.1.9: semantics behind dashed line "reads and writes" is unclear

  • Key: UML4DDS-11
  • Legacy Issue Number: 12814
  • Status: open  
  • Source: THALES ( Hugues Vincent)
  • Summary:

    The semantics behind the dashed line "reads and writes" is unclear. Moreover, DataReader should reads Topics::TopicDescription that is more general than Topics:Topic. The dashed line is thus confusing

  • Reported: UML4DDS 1.0b1 — Thu, 4 Sep 2008 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 7.2.2

  • Key: UML4DDS-15
  • Legacy Issue Number: 12818
  • Status: open  
  • Source: THALES ( Hugues Vincent)
  • Summary:

    it should be stated that an association between qosProperty and qosPolicy subsets the UML2 association between UML2::Class and UML2::Property

  • Reported: UML4DDS 1.0b1 — Thu, 4 Sep 2008 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 7.2.1: wrong UML2 notation

  • Key: UML4DDS-14
  • Legacy Issue Number: 12817
  • Status: open  
  • Source: THALES ( Hugues Vincent)
  • Summary:

    wrong UML2 notation for an extension association between a stereotype and its metaclass

  • Reported: UML4DDS 1.0b1 — Thu, 4 Sep 2008 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

which field is actually the key?

  • Key: UML4DDS-13
  • Legacy Issue Number: 12816
  • Status: open  
  • Source: THALES ( Hugues Vincent)
  • Summary:

    If a key is designed as a subclass of TopicField, which field is actually the key? For instance, in the use case example shown in Figure 37, a PersonTopic has a key: taxNr (an int). Is this field designed as a DLRL::Key or as a Types::Integer? Anyway, the other information is lacking.

  • Reported: UML4DDS 1.0b1 — Thu, 4 Sep 2008 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 7.2.3association "type"

  • Key: UML4DDS-16
  • Legacy Issue Number: 12819
  • Status: open  
  • Source: THALES ( Hugues Vincent)
  • Summary:

    it should be stated that the association "type" subsets the UML2 association between UML2::Class and UML2::Property.

  • Reported: UML4DDS 1.0b1 — Thu, 4 Sep 2008 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 7.1.5 "TopicField"

  • Key: UML4DDS-7
  • Legacy Issue Number: 12810
  • Status: open  
  • Source: THALES ( Hugues Vincent)
  • Summary:

    TopicField" is a strange name in this context because it results in having a "typedef", a "union" and so forth as a topic field! To my mind, "TopicType" should be better for the sake of comprehensibility.

  • Reported: UML4DDS 1.0b1 — Thu, 4 Sep 2008 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

TopicField should be under Core::Specification

  • Key: UML4DDS-6
  • Legacy Issue Number: 12809
  • Status: open  
  • Source: THALES ( Hugues Vincent)
  • Summary:

    TopicField should be under Core::Specification (target of the association "type") instead of the too general Core::Entity.

  • Reported: UML4DDS 1.0b1 — Thu, 4 Sep 2008 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 7.1

  • Key: UML4DDS-5
  • Legacy Issue Number: 12808
  • Status: open  
  • Source: THALES ( Hugues Vincent)
  • Summary:

    §§ 7.1.4.3.4, 7.1.6.1.4, 7.1.6.2.4, 7.1.6.7.4, 7.1.6.5.4: There is a mismatch between, in the one hand, the type of the associations (XXXQosPolicy) and, on the other hand, the comment (that speaks of QosProperty) and the subset constraint (it subsets "property" which goes from Core:Entity to Core::TypedEntity while QosPolicies are not TypeEnties). Moreover, what is the added value of these associations when all these classes (Topic, DataReader, DataWriter, PublisherSubscriber, DomainParticipant, Figures 7-14 to 7-17), are Core::DomainEntities and, so, have a "qosPolicy" associations?

  • Reported: UML4DDS 1.0b1 — Thu, 4 Sep 2008 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Figure 9: the names of the fields of a structure are not designed

  • Key: UML4DDS-9
  • Legacy Issue Number: 12812
  • Status: open  
  • Source: THALES ( Hugues Vincent)
  • Summary:

    Figure 9: the names of the fields of a structure are not designed? I.e., following the associations "members" allows to find the names of types of the fields of the structure but not the name of the fields themselves.

  • Reported: UML4DDS 1.0b1 — Thu, 4 Sep 2008 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Figure 9 and following paragraphs: subset constraints are not designed

  • Key: UML4DDS-8
  • Legacy Issue Number: 12811
  • Status: open  
  • Source: THALES ( Hugues Vincent)
  • Summary:

    Figure 9 and following paragraphs: subset constraints are not designed (most of associations seems to subset at least ownEntity).

  • Reported: UML4DDS 1.0b1 — Thu, 4 Sep 2008 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

"type" of a TopicDescription

  • Key: UML4DDS-4
  • Legacy Issue Number: 12807
  • Status: open  
  • Source: THALES ( Hugues Vincent)
  • Summary:

    The "type" of a TopicDescription should be Types::TopicStruct instead of Types::TopicField.

  • Reported: UML4DDS 1.0b1 — Thu, 4 Sep 2008 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 7.1.4

  • Key: UML4DDS-3
  • Legacy Issue Number: 12806
  • Status: open  
  • Source: THALES ( Hugues Vincent)
  • Summary:

    Either TopicDescription is-a Core::TypedEntity or the association "type" subsets "property"

  • Reported: UML4DDS 1.0b1 — Thu, 4 Sep 2008 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 7.1.9

  • Key: UML4DDS-10
  • Legacy Issue Number: 12813
  • Status: open  
  • Source: THALES ( Hugues Vincent)
  • Summary:

    The semantics behind the dashed line named "is mapped to" is not specified (no class in the metamodel for instance).

  • Reported: UML4DDS 1.0b1 — Thu, 4 Sep 2008 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Fig 6:qosPolicy subsets property and not ownedEntity as stated in § 7.1.3.1

  • Key: UML4DDS-2
  • Legacy Issue Number: 12805
  • Status: open  
  • Source: THALES ( Hugues Vincent)
  • Summary:

    Figure 6: qosPolicy subsets property and not ownedEntity as stated in § 7.1.3.1

  • Reported: UML4DDS 1.0b1 — Thu, 4 Sep 2008 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

The document does not specify how the compliance levels are layered

  • Key: UML4DDS-1
  • Legacy Issue Number: 12804
  • Status: open  
  • Source: THALES ( Hugues Vincent)
  • Summary:

    The document does not specify how the compliance levels are layered. More precisely, does L3 include L2?

  • Reported: UML4DDS 1.0b1 — Thu, 4 Sep 2008 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2.5: UML redefinition mechanism insufficiently granular

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

    The current mechanism for redefining the elements of a classifier is not refined enough for cases where the redefined elements are complex hierarchical namespaces. As presently defined, in those situations, the mechanism results in needless duplication that creates maintenance difficulties and excessive memory overhead.

    To illustrate the problem, take, for example, the perfectly reasonable scenario where we have a high-level (e.g., abstract) state machine (which is a kind of Class), which we would like to refine in a subclass by adding a new state to one of its nested regions. This is achieved via the state machine redefinition mechanism as specified in section 14.3 of the 2.5 spec, which is based on the standard UML::RedefinableElement abstraction. In UML, a State is part of the namespace of a Region, which is either part of the namespace of a containing hierarchical State or, in case of the topmost Region, of the StateMachine itself. To add a State using this mechanism, it is necessary to redefine (i.e., “extend”) the Region defined in the superclass to which we wish to add the new State. Unfortunately, because of the all-or-nothing nature of the current redefinition mechanism, it is not sufficient to simply define a new redefining Region and include the new State within it. Because of the insufficient granularity of UML redefinition, it is also necessary to clone all the other elements that currently exist in the redefined region (i.e., all States, Pseudostates, Transitions, etc.). Furthermore, because the redefined Region is part of a higher-level namespace (State or StateMachine), that namespace must also be redefined, since it now contains a different Region than the original one. Which, in turn, requires redefinition of the next higher namespace (with all the requisite cloning), and so on. This chain of cloning redefinitions must necessarily continue all the way up to the topmost Region of the StateMachine, terminating in an almost complete clone the original StateMachine, even though we only wanted to add a single State to the original StateMachine.

    Needless to say, cloning presents a maintenance issue, since any changes in a superclass have to be propagated to all the affected clones in all the subclasses. Even worse, this approach results in potentially large and completely unnecessary memory overheads.

    It seems that redefinition should be based on an incremental approach, just like inheritance. That is, only the differences from the redefined element should be explicitly specified in the redefining element, while everything else existing in the namespace of the redefined element should be implicitly “inherited”.

  • Reported: UML 2.5 — Tue, 3 Mar 2015 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: 18.2 Classifier Descriptions Use Case Constraints. 697 - Need stricter limit on associations

  • Key: UMLR-505
  • Legacy Issue Number: 18081
  • Status: open  
  • Source: Soluta.net ( Adriano Comai)
  • Summary:

    current text (688): UseCases may have other Associations and Dependencies to other Classifiers (e.g., to denote input/output, events, and behaviors

    [AC] I believe here one or more constraints are missing. The associations an Actor can have are correctly constrained (see page 694) to be only with UseCase, Class and Component.
    A UseCase, in my opinion and in the whole literature that I know, can only have associations with Actors (while it can have other types of relationship, such as dependencies with other classifiers).
    If I am right, then also what is written on page 688 - “UseCases may have other Associations and Dependencies to other Classifiers (e.g., to denote input/output, events, and behaviors).” - should be corrected.

  • Reported: UML 2.1.2 — Fri, 21 Nov 2008 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: 18.2 Classifier Descriptions Extend Constraints. 695 - Constraint is overly restrictive

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

    current text: The ExtensionPoints referenced by the Extend relationship must belong to the UseCase that is being extended

    Does this "belong" also include
    1) ExtensionPoints that would be inherited?
    2) ExtensionPoints that would be defined in Included Use Cases.

    Both of these are required to support behavioral refactoring and reuse. If a "super" UseCase or an Included UseCase are made to pull out common behavioral parts, it may be that some an extending use case needs to be inserted at
    a) extension points that cross use case boundaries (e.g., in the super and child use case, or in the included and base use case) or
    b) an extension UseCase needs to be inserted in a base use case, but not in all use cases tsshat include the Included UseCase, and not in all children of the generalized UseCase.

    Without including the extensionPoints from both these sources, such situations cannot be handled.

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: 18.1.4 Notation P. 688 - Can Use Cases have attributes and operations?

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

    A UseCase is a BehavioredClassifier, which is a Classifier, which has features of Type Property (Subclasses are Operation and Reception). However "feature" is a derived union and neither BehavioredClassifier nor UseCase define subsets of it. Therefore the features of a UseCase are always an empty set. I heard of one UML-Tool that actually enforces this rule.

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: 18.2 Classifier Descriptions Use Case Constraints. 697 - Need stricter limit on associations (02)

  • Key: UMLR-503
  • Legacy Issue Number: 18082
  • Status: open  
  • Source: Soluta.net ( Adriano Comai)
  • Summary:

    I've also doubts on the following constraint: “UseCases can not have Associations to UseCases specifying the same subject.”. In my opinion, and in my interpretation of what is written on page 686, UseCases can not have Associations to UseCases, whether they specify or not the same subject.

    What form of association may exist among UseCases specifying different subjects?

  • Reported: UML 2.1.2 — Fri, 21 Nov 2008 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: Figure A.5 P. 734 - Use Cases are not behavior diagrams

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

    Use case diagrams don’t show change over time, they show intents, purposes, etc. They are neither structure nor behavior. Redraw diagram to make new category
    They are more similar to SysML requirement diagrams

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: Appendix A, list of frame names, p 734 - List of Namespaces suitable for diagram headers is overly restrictive

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

    A diagram of Model, Node, Datatype, etc. should be allowed.
    This is also UML 2.4 Open Issue 16484.

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: 18.1.1 Summary p 685 - Bases of specialized stereotypes

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

    Was wondering if clarification was needed on adding bases to specialized stereotypes. Since Extensions are associations:

    • Bases of general stereotypes inherit to specialized stereotypes, and instances of specialized stereotypes can be applied to any of the bases, including inherited ones.

    • Bases of specialized stereotypes can be specialized from more general bases by redefinition or subsetting of ExtensionEnds.

    This all follows from Extensions as associations/classifiers, so maybe doesn't really need to be explicitly said, not sure.

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: 19.5 Classifier Descriptions Deployment Specification Attributes P. 711 - Why a multiplicity of [0..1]

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

    An artifact can be located in multiple locations, for example, on a disk and in ROM, and in RAM. Similarly, it could execute partially in ROM and also in RAM. In addition, an executable could reside in multiple places in memory on the same machines, with multiple copies running at once. Also they could assigned to different "cores"

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: 22.3 Standard Stereotypes «Metamodel» p. 731 - «Subsystem» should be allowed for more classifiers

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

    Subsystem should also be allowed for other types of classifier, e.g., class. Limiting this to components enforces a particular methodological approach and is incompatible with Systems Engineers, who would use «Subsystem» for blocks, a specialization of Class.

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: 19.5 Node Association Ends Node P. 714 - Shared ownership of nodes

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

    In fancy hw, a node could be owned by more than one owning node: Shared memory, shared processors, distributed processing...

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: 18.2 Classifier Descriptions Extend Constraints. 695 - Extensions must be a DAG

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

    Missing constraint or discussion anywhere that the chain of extends relations must not contain loops

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: Figure B.3. 737 - A diagram is a PackageableElement

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

    A diagram is a packageableElement.

    What does it look like in a package

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Reword isComputable

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

    This is woolly just redirecting to 'can be computed'.

    Suggest: A ValueSpecification can be computed when all the algorithms, resources and values required to perform a computation are available. So a ValueSpecification would not be computable if an operation without a body was invoked, an off-line processor is required, or a source value is required. isComputable() is intended to be a static determination of capability, so a computation failure such as divide-by-zero or an I/O
    failure would not prevent isComputable() returning true, rather they would cause a query
    such as realValue() to return no value.

    ?? if a computation needs a currently locked resource, is it computable? Probably yes, since if the computation waits patiently the result will appear ??

    ?? Should be three-valued...

    True => a computation now will run
    False => a computation now will abort
    Null => a computation now might abort

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: 8.6 p 98 TimeObservation ...simplify

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

    Simpler:
    A TimeObservation identifies a time instant at which execution either enters or exits a particular NamedElement.
    ...

    firstEvent[i] is true to select the enter, or false to select the exit event when observing execution of the NamedElement

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Too many alls

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

    Too many 'all's; remove all in front of all the component values.

    Suggest just: ... concatenating the ordered String values of each operand or subExpression.

    Simplerbody: if subExpression->notEmpty()then subExpression->iterate(se; stringValue: String = '' | stringValue + se.stringValue())else operand->iterate(op; stringValue: String = '' | stringValue + op.stringValue())endifif notbody: subExpression->sum() + operand->sum()

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Intended to Produce

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

    How does the isIntegral determine the intent of the expression. It can only determine if the expressions produces an integer. Redefine

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Bad Description, observation has no value

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

    Bad description; observation has no value.

    Suggest:

    Observation specifies the event or events observed to determine a TimeExpression or Duration.

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Like to overridden definition

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

    In e.g. LiteralInteger and LiteralNull on p 91 (and the rest)there is no hyperlink from isComputable() to the overridden definition and indeed no qualified name to aid manual navigation.
    Consider
    Move 6 versions of isComputable() to LiteralSpecification.

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Why can’t the operand be a stringExpression

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

    Too many 'all's; remove all in front of all the component values.

    Suggest just: ... concatenating the ordered String values of each operand or subExpression.

    Simpler body: if subExpression->notEmpty()then subExpression->iterate(se; stringValue: String = '' | stringValue + se.stringValue())else operand->iterate(op; stringValue: String = '' | stringValue + op.stringValue())endifif notbody: subExpression->sum() + operand->sum()

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Range Confusion

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

    'range' is a bit confusing again. Use 'intervening distance', so that (temporal) distance is a consistent terminology.

    Use 'larger ValueSpecification' or 'ending ValueSpecification' rather than 'maximum value of the range'

    Use 'smaller ValueSpecification' or 'starting ValueSpecification' rather than 'minimum value of the range'

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Simplify (Location: 8.6 p 97 TimeExpression)

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

    The worded requirement should be in OCL, possibly deferring the issue to a clear definition of isConstant().

    expr <> null and observation->isEmpty() implies expr->isConstant()

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Bad Description

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

    Unnecessarily wordy suggest just:

    An OpaqueExpression specifies the computation of a set of values either in terms of a UML Behavior or a textual expression in some language.

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Simplify

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

    firstEvent[i] is true to select the enter, or false to select the exit event to constrain execution of the constrainedElement.

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

What incompatible about sub-expressions and operands

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

    The problem seems solvable

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

PrimitiveTypes::Real is inconsistently specified relative to its mapping to xsd:double

  • Key: UMLR-434
  • Legacy Issue Number: 18830
  • Status: open  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    UML says:

    An instance of Real is a value in the (infinite) set of real numbers. Typically an implementation will internally represent Real numbers using a floating point standard such as ISO/IEC/IEEE 60559:2011 (whose content is identical to the predecessor IEEE 754 standard).

    Mapping this to xsd:double is just wrong:

    xsd:double has finite cardinality; PrimitiveTypes::Real has infinite cardinality.

    xsd:double has both upper and lower limits; PrimitiveTypes::Real has no such limits.

    3.3.5 double – http://www.w3.org/TR/2012/REC-xmlschema11-2-20120405/#double

    [Definition:] The double datatype is patterned after the IEEE double-precision 64-bit floating point datatype [IEEE 754-2008]. Each floating point datatype has a value space that is a subset of the rational numbers. Floating point numbers are often used to approximate arbitrary real numbers.

    Note: The only significant differences between float and double are the three defining constants 53 (vs 24), -1074 (vs -149), and 971 (vs 104).

    3.3.5.1 Value Space

    The ·value space· of double contains the non-zero numbers m × 2e , where m is an integer whose absolute value is less than 253, and e is an integer between -1074 and 971, inclusive. In addition to these values, the ·value space· of double also contains the following ·special values·: positiveZero, negativeZero, positiveInfinity, negativeInfinity, and notANumber.

    Note: As explained below, the ·lexical representation· of the double value notANumber is 'NaN'. Accordingly, in English text we generally use 'NaN' to refer to that value. Similarly, we use 'INF' and '-INF' to refer to the two values positiveInfinity and negativeInfinity, and '0' and '-0' to refer to positiveZero and negativeZero.

    Equality and order for double are defined as follows:

    Equality is identity, except that 0 = -0 (although they are not identical) and NaN ? NaN (although NaN is of course identical to itself).

    0 and -0 are thus equivalent for purposes of enumerations, identity constraints, and minimum and maximum values.

    For the basic values, the order relation on double is the order relation for rational numbers. INF is greater than all other non-NaN values; -INF is less than all other non-NaN values. NaN is ·incomparable· with any value in the ·value space· including itself. 0 and -0 are greater than all the negative numbers and less than all the positive numbers.

    Note: Any value ·incomparable· with the value used for the four bounding facets (·minInclusive·, ·maxInclusive·, ·minExclusive·, and ·maxExclusive·) will be excluded from the resulting restricted ·value space·. In particular, when NaN is used as a facet value for a bounding facet, since no double values are ·comparable· with it, the result is a ·value space· that is empty. If any other value is used for a bounding facet, NaN will be excluded from the resulting restricted ·value space·; to add NaN back in requires union with the NaN-only space (which may be derived using the pattern 'NaN').

    Note: The Schema 1.0 version of this datatype did not differentiate between 0 and -0 and NaN was equal to itself. The changes were made to make the datatype more closely mirror [IEEE 754-2008].

    3.3.5.2 Lexical Mapping

    The ·lexical space· of double is the set of all decimal numerals with or without a decimal point, numerals in scientific (exponential) notation, and the ·literals· 'INF', '+INF', '-INF', and 'NaN'

    Lexical Space

    [5] doubleRep ::= noDecimalPtNumeral | decimalPtNumeral | scientificNotationNumeral | numericalSpecialRep

    The doubleRep production is equivalent to this regular expression (after whitespace is eliminated from the expression):

    (+|)?([0-9](\.[0-9]*)?|\.[0-9])([Ee](+|)?[0-9]+)? |(+|-)?INF|NaN

    The double datatype is designed to implement for schema processing the double-precision floating-point datatype of [IEEE 754-2008]. That specification does not specify specific ·lexical representations·, but does prescribe requirements on any ·lexical mapping· used. Any ·lexical mapping· that maps the ·lexical space· just described onto the ·value space·, is a function, satisfies the requirements of [IEEE 754-2008], and correctly handles the mapping of the literals 'INF', 'NaN', etc., to the ·special values·, satisfies the conformance requirements of this specification.

    Since IEEE allows some variation in rounding of values, processors conforming to this specification may exhibit some variation in their ·lexical mappings·.

    The ·lexical mapping· ·doubleLexicalMap· is provided as an example of a simple algorithm that yields a conformant mapping, and that provides the most accurate rounding possible?and is thus useful for insuringg inter-implementation reproducibility and inter-implementation round-tripping. The simple rounding algorithm used in ·doubleLexicalMap· may be more efficiently implemented using the algorithms of [Clinger, WD (1990)].

    Note: The Schema 1.0 version of this datatype did not permit rounding algorithms whose results differed from [Clinger, WD (1990)].

    The ·canonical mapping· ·doubleCanonicalMap· is provided as an example of a mapping that does not produce unnecessarily long ·canonical representations·. Other algorithms which do not yield identical results for mapping from float values to character strings are permitted by [IEEE 754-2008].

    3.3.5.3 Facets

    The double datatype and all datatypes derived from it by restriction have the following ·constraining facets· with fixed values; these facets must not be changed from the values shown:

    whiteSpace = collapse (fixed)

    Datatypes derived by restriction from double may also specify values for the following ·constraining facets·:

    pattern

    enumeration

    maxInclusive

    maxExclusive

    minInclusive

    minExclusive

    assertions

    The double datatype has the following values for its ·fundamental facets·:

    ordered = partial

    bounded = true

    cardinality = finite

    numeric = true

  • Reported: UML 2.5b1 — Thu, 25 Jul 2013 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

No explanation of how to deal with conflicting transitions of equal priority

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

    The spec does not say anything about how to deal with the case where two or more conflicting transitions with the same priority (e.g., triggered by the same event but with different guards that evaluate to true). Presumably, this is left as an implementation choice.

    In any case, there should be an explicit statement on this point.

  • Reported: UML 2.5b1 — Mon, 15 Jul 2013 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Definition of allOwningPackages()

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

    NamedElement:: allOwningPackages() is documented as

    “The query allOwningPackages() returns all the Packages that in which this NamedElement is directly or indirectly contained, without any intervening Namespace that is not a Package.”

    But the OCL is

    if namespace.oclIsKindOf(Package)

    then

    let owningPackage : Package = namespace.oclAsType(Package) in

    owningPackage->union(owningPackage.allOwningPackages())

    else

    null

    endif

    Which would stop looking at any element not owned by a Package - which contradicts the documentation.

    I think it should instead read:

    allNamespaces()->select(oclIsKindOf(Package))

    But allOwningPackages is only used in Profile::references_same_metamodel, and I don’t like that either:

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

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

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

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

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

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

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

    and

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

    Any comments?

  • Reported: UML 2.5b1 — Wed, 10 Jul 2013 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Several UMLDI redefining associations are invalid

  • Key: UMLR-430
  • Legacy Issue Number: 18855
  • Status: open  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    As much as I do not like the current restrictive approach taken for UMLDI,
    there are problems with the following associations, each of which fail the
    "redefined_property_inherited" constraint for their association-owned end:

    Figure B.4:

    A_UMLEdge_source_sourceEdge
    A_UMLEdge_target_targetEdge

    Figure B.5

    A_UMLNameLabel_modelElement_umlDiagramElement
    A_UMLRedefines_modelElement_umlDiagramElement

    Figure B.7

    A_UMLStereotypePropertyValueLabel_modelElement_umlDiagramElement

    Figure B.8

    A_UMLDiagramElement_localStyle_styledElement
    A_UMLDiagramElement_sharedStyle_styledElement

    Figure B.10

    A_UMLClassifierShape_modelElement_umlDiagramElement

    Figure B.11

    A_UMLAssociationEndLabel_modelElement_umlDiagramElement
    A_UMLMultiplicityElement_modelElement_umlDiagramElement

    Figure B.13

    A_UMLBehaviorDiagram_modelElement_umlDiagramElement
    A_UMLStateMachine_modelElement_umlDiagramElement
    A_UMLActivityDiagram_modelElement_umlDiagramElement
    A_UMLInteractionDiagram_modelElement_umlDiagramElement

    Figure B.14

    A_UMLStateShape_modelElement_umlDiagramElement

    All of these associations lack a generalization to the association whose
    ends are redefined.

  • Reported: UML 2.5b1 — Wed, 7 Aug 2013 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UseCases: Explanation of words “fragment” and “increment”

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

    The semantics of UseCases uses the words “fragment” and “increment” without explaining what these words mean in terms of the metamodel

  • Reported: UML 2.5b1 — Thu, 23 May 2013 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Behavior does not override NamedElement::isDistinguishableFrom() like BehavioralFeature does

  • Key: UMLR-445
  • Legacy Issue Number: 18728
  • Status: open  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    BehavioralFeatures and Behaviors use Parameters to specify their signature; however, only BehavioralFeature overrides namespace distinguishability to take into account its signature; Behavior uses the inherited criteria from NamedElement. This means that two Behaviors of the same name and kind but with different Parameter signatures are not distinguishable in the same way that BehavioralFeatures of the same name and kind are.

    For example, two StateMachines with the same name but distinct Parameter signatures (in the sense of BehavioralFeature) are not Namespace distinguishable.
    It is unclear whether this is an explicit intent of the spec or a bug in the spec.

  • Reported: UML 2.5b1 — Wed, 22 May 2013 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Uml2.5 issue - constraints of Behavior incorrectly assume context is always non-null

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

    Constraints most_one_behavior and feature_of_context_classifier incorrectly assume context is always non-null. The latter also seems to assume that specification is non-null.

  • Reported: UML 2.5b1 — Wed, 7 Aug 2013 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Add condition : Constraint[0..1] to the include relationship

  • Key: UMLR-432
  • Legacy Issue Number: 18857
  • Status: open  
  • Source: Learning Tree International ( Brett Martensen)
  • Summary:

    The extend relationship is not intuitive to most users of UML.

    Add the condition:Constraint[0..1] and extension point (renamed as branch point) as an optional property of the include relationship and remove the extend relationship from the specification.

  • Reported: UML 2.4.1 — Wed, 7 Aug 2013 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Timing Events Question / Issue

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

    A wait for an absolute time event is reached in an activity diagram, but when the event time is evaluated, the time is in the past.

    Does the timer receive that event and continue, or does it wait there forever, or is the behaviour not specified.

    The spec does not seem to be specific.

  • Reported: UML 2.5b1 — Mon, 27 May 2013 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

The notation for ExtensionPoint provides for an “explanation”, but the metamodel provides nowhere to store it.

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

    The notation for ExtensionPoint provides for an “explanation”, but the metamodel provides nowhere to store it.

  • Reported: UML 2.5b1 — Thu, 23 May 2013 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UseCases: no way for an Extend to pick out individual ownedBehaviors of the extending UseCase

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

    Although the textual semantics asserts that it can – “individual fragments” and other references - there is no way for an Extend to pick out individual ownedBehaviors of the extending UseCase

  • Reported: UML 2.5b1 — Thu, 23 May 2013 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Definition of invariant condition

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

    This is not the normal interpretation of invariant conditions, and I believe it has no support in UML 2.4.1. The typical definition for invariant condition is that it must be true (it must hold) whenever it is checked, pre, post, and during. However, it need not hold while the object is not at a stable point and not query-able (not inspectable), but it must be true when and if the condition can be checked (by normal means). In an environment with multi-threading, this is often done with locks of some sort.

  • Reported: UML 2.4.1 — Tue, 25 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section Unbalanced

  • Key: UMLR-597
  • Legacy Issue Number: 17762
  • Status: open  
  • Source: Thematix Partners LLC ( Dr. Doug Tolbert)
  • Summary:

    The section needs some introductory material. What's here is good, useful and interesting stuff, but its purpose and why it's located at this point in the spec is not sufficiently motivated. The material presented is also somewhat unbalanced. For example, §6.3.1 calls out three model element categories: Classifiers, Events, and Behaviors. Then §6.3.3 contains some nice text on semantics of Behaviors, but nothing further is said about Classifiers or Events. Suggest some text for the two missing categories should be added – if they are important enough to mention, they deserve discussion.
    Proposed Resolution: Add described text.

  • Reported: UML 2.4.1 — Tue, 25 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Need table correlating Literals with symbols (+,-,#,~)

  • Key: UMLR-592
  • Legacy Issue Number: 17815
  • Status: open  
  • Source: Lockheed Martin ( John Watson)
  • Summary:

    There does not seem to be anywhere where there is any coorelation between the symbols and their meaning. If anything, it would be useful here.

    Throughout the document, readers are referred to 7.4 (where the enumerations) is defined, but that doesn’t help us to know what +, - … mean.

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Inconsistent use of (s)

  • Key: UMLR-593
  • Legacy Issue Number: 17807
  • Status: open  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    Sometimes a property with upper bound > 1 is referred to as having "Elements", for example, and sometimes "Element(s)". Dependency::client, Dependency::supplier, DirectedRelationship::source, DirectedRelationship::target all use the latter whereas ElementElement::ownedComments and Constraint::constrainedElements use the former. I'm sure there are many other examples. I think the former is better stylistically. (For what it's worth, Oracle's corporate documentation standards regard the use of parenthesized plurals as bad practice.)

    Proposed Resolution:

    Consistently use plurals rather than plural(s).

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section 11.7 has no content or notation for template Collaborations Clause - 11: Structured Classifiers

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

    Section 11.7 has no content or notation for template Collaborations. There was material in UML 2.4 section 17.4.7 about these.

  • Reported: UML 2.4.1 — Tue, 25 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section 11.3.4 isService clarification - Clause 11: Structured Classifiers

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

    Section 11.3.4 says “A Port of an EncapsulatedClassifier is shown as a small square symbol”. Does this perhaps only apply to Ports for which isService is true? The definition of isService would certainly seem to imply that a Port marked with isService = false would not appear on parts, for example. RSA hides the port when you make isService = false.

  • Reported: UML 2.4.1 — Tue, 25 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Descendants rather than specializations

  • Key: UMLR-596
  • Legacy Issue Number: 17778
  • Status: open  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    The Elements and Relationships sections both use the term "Descendants". Surely the term used here should be Specializations? I suspect this may be more widespread than just this section (7.2.4 contains another example).

    Proposed Resolution:

    Use specialization rather than descendants.

  • Reported: UML 2.4.1 — Tue, 25 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section 11.2.4 clarification - Clause 11: Structured Classifiers

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

    Section 11.2.4 says “Detail may also be shown within the part box indicating specific values for Properties of the part’s type when instances corresponding to the Property are created.” What does this mean?

  • Reported: UML 2.4.1 — Tue, 25 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

List attributes whose ordered property has change in UML 2.5

  • Key: UMLR-600
  • Legacy Issue Number: 17760
  • Status: open  
  • Source: Thematix Partners LLC ( Dr. Doug Tolbert)
  • Summary:

    Summary: As an aid to tool vendors, can properties whose

    {ordered}

    status has been changed be identified in the text or listed here?
    Proposed Resolution: Add described text.

  • Reported: UML 2.4.1 — Tue, 25 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Bound Element Semantics overly specific

  • Key: UMLR-598
  • Legacy Issue Number: 17782
  • Status: open  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    Point 2 ("If the copy...") seems to be overly specific for this section. Shouldn't this information be part of the Generalization and Operation semantics?

  • Reported: UML 2.4.1 — Tue, 25 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML 2.5 FTF issues for Clause 18: UseCases

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

    The condition of an Extend is a Constraint. What are its constrainedElements?

  • Reported: UML 2.4.1 — Tue, 25 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Template Notation example

  • Key: UMLR-594
  • Legacy Issue Number: 17783
  • Status: open  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    This could really do with a graphical example.

  • Reported: UML 2.4.1 — Tue, 25 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Clarification on the semantics of CommunicationPath

  • Key: UMLR-615
  • Legacy Issue Number: 17591
  • Status: open  
  • Source: THALES ( Hugues Vincent)
  • Summary:

    Title: Clarification on the semantics of CommunicationPath
    Where: section 19.4.3
    Nature of Issue: Clarification
    Severity of Issue: Minor
    Full Description of the Issue:
    The semantics of CommunicationPath is poorly defined: what is a 'specific communication path'? A wire, a protocol used...?

  • Reported: UML 2.4.1 — Thu, 13 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

isIntegral()

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

    Wouldn’t it be a better name to have the operation called isInteger?

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Capitalization of dependency

  • Key: UMLR-613
  • Legacy Issue Number: 17803
  • Status: open  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    "dependency" should be "Dependency"

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Profile: can a stereotype extend fewer metaclasses than another stereotype it specializes?

  • Key: UMLR-470
  • Legacy Issue Number: 18247
  • Status: open  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    The UML 2.5 beta document is unclear about the combination of stereotype extensions & generalization relationships.
    Suppose a stereotype S1 extends metaclasses MC1 and MC2.
    Suppose another stereotype S2 specializes S1 and is only applicable to MC1 but not to MC2.

    Should S2's extension of MC1 then redefine S1's extensions of MC1 and of MC2 or is this restriction capability beyond the scope of the UML profile mechanism?

  • Reported: UML 2.5b1 — Mon, 5 Nov 2012 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Clarification re MOF Equivalent Semantics about defining/applying a stereotype to a slot of ininstance of a stereotype

  • Key: UMLR-469
  • Legacy Issue Number: 18245
  • Status: open  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    The UML 2.5 beta document explains the mapping of Profiles, Stereotypes,
    and Extensions in terms of the CMOF-equivelent semantics as follows:

    • A Profile maps to a CMOF Package
      Š
    • A Stereotype maps to a CMOF class with the same name and properties
      Š
    • An instance of a Stereotype (created when the Stereotype is applied to
      an Element) maps to an instance of the CMOF class representing the
      Stereotype.
      It is associated with the Element to which it applies using a Link which
      is an instance of the Association to which the Extension is mapped.

    According to the above, this means that

    1) when defining the stereotype Clock (Fig 12.22), the property
    Clock::OSVersion maps to a property of the CMOF class named Clock
    2) when applying the stereotype Clock (Fig 12.26 and 12.27) to an element
    (StopWatch on Fig 12.22), the underlying semantics has an instance of the
    CMOF class Clock with a slot corresponding to the property
    Clock::OSVersion (Fig 12.27)

    It should be possible to define a stereotype extending UML::Slot and apply
    such stereotype to a slot corresponding to a property of an instance of a
    stereotype, e.g., the slot OSVersion="3.32" of Fig 12.27.

    This is a subtle point about the current profile mechanism that should be
    made clear in the spec.
    I suggest adding an explanation about this in the "MOF Equivalent
    Semantics" sub-section of section 12.3.3 Profile Semantics.

  • Reported: UML 2.5b1 — Sat, 3 Nov 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Node::nestedNode should subset Class::nestedClassifier, not Namespace::ownedMember.

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

    The way it is modeled now, a Node’s nested nodes will not appear in its nestedClassifier property, which must be wrong.

  • Reported: UML 2.4.1 — Wed, 10 Oct 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Meaning of State in ProtocolStateMachines

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

    Category: Minor

    In the section on “State in ProtocolStateMachines” it is stated:

    “The States of ProtocolStateMachines are exposed to the users of their context Classifiers. A protocol State represents an exposed stable situation of its context Classifier: When an instance of the Classifier classifier is not processing any BehavioralFeature invocation, users of this instance can always know its state configuration. ”

    This does not seem to make sense, at least for declarative protocol state machines – they do not have a run-time manifestation, so it is not clear what it means for the state of such a machine to be “exposed to collaborators”.

  • Reported: UML 2.4.1 — Wed, 10 Oct 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Should “completion” event be an explicit event type?

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

    Category: Minor

    Should a completion event described in the StateMachines chapter be defined as an explicit event type like ChangeEvent, etc.? If so, then it should be discussed in the Commo Behaviors clause as well.

  • Reported: UML 2.4.1 — Wed, 10 Oct 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Not clear if “else” keyword is defined for State Machines

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

    Category: Minor

    The 2.5 spec says:

    “As a way of avoiding this situation in some cases, it is possible to associate a predefined guard denoted as “else” with at most one outgoing Transition”

    The formal specification of the “else” keyword is not given (presumably maps to a Constraint that is the conjunctive negation of all the other Constraints)

  • Reported: UML 2.4.1 — Wed, 10 Oct 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

State of the substates of the history state

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

    Category: Clarification

    The 2.5 spec says:

    “Shallow history entry: If the incoming Transition terminates on a shallowHistory Pseudostate of the composite State, the active substate becomes the substate that was most recently active prior to this entry,”

    It is not clear what the ``state`of the substates of the history state are.

  • Reported: UML 2.4.1 — Wed, 10 Oct 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML: No restrictions on what seem to be meaningless associations

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

    It seems possible to draw associations between any two kinds of types, including seemingly absurd combinations of associations between, say, an Interface and a Collaboration.Should there be constraints that prevent such combinations? If not, then the semantics of such combinations should be clarified.

  • Reported: UML 2.5b1 — Fri, 19 Oct 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

It is a pity that UML does not provide the ability for Messages to correspond directly to property accesses and updates

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

    It is a pity that UML does not provide the ability for Messages to correspond directly to property accesses and updates

  • Reported: UML 2.4.1 — Fri, 24 Aug 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Need packages overview diagram and explicit depiction of package dependencies

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

    In the current 2.5 metamodel, there is a diagram that simply shows all the various packages that comprise it. Note, however, that we do not have such a diagram in the spec itself. In fact, as far as I can tell, it seems that the spec does not even mention explicitly that the metamodel is divided up into these packages.

    Furthermore, it is useful to see the dependencies between the various packages captured explicitly in diagrams. In a sense, this shows the intended couplings between the various modules, which is usually important architectural information. Not showing them explicitly either in the spec or in a metamodel diagram is obscuring this and could lead to corruption of the architecture in subsequent maintenance (e.g., the introduction of undesired and even incorrect couplings between the packages).

  • Reported: UML 2.5b1 — Tue, 23 Oct 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Meaning of absent multiplicity notation

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

    The UML 2.5 beta does not appear to take a clear position on what it means when the multiplicity is omitted from the notation for an element, although there are many places in the spec itself where multiplicity is absent.

  • Reported: UML 2.4.1 — Wed, 10 Oct 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Figure 14.39 – missing superclass

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

    Category: Minor

    The diagram for ProtocolStateMachines does not show the superclass of ProtocolConformance; it should in line with the general convention for such abstract syntax diagrams

  • Reported: UML 2.4.1 — Wed, 10 Oct 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Not clear when to use ExecutionOccurrenceSpecification with ExecutionSpecification

  • Key: UMLR-517
  • Legacy Issue Number: 18037
  • Status: open  
  • Source: Oracle ( Darren Kumasawa)
  • Summary:

    Location:
    Page #607, 17.2.3 Semantics, Execution Specifications
    Page #619, 17.5.3 Semantics, Execution Occurrence Specifications
    Title: Not clear when to use ExecutionOccurrenceSpecification with ExecutionSpecification

    Summary:
    Page #607, 17.2.3 Semantics, Execution Specifications
    "Typically the start occurrence and the finish occurrence will represent OccurrenceSpecifications such as a receive OccurrenceSpecification (of a Message) and the send OccurrenceSpecification (of a reply Message)."

    Page #619, 17.5.3 Semantics, Execution Occurrence Specifications
    "A ExecutionOccurrenceSpecification represents, on a lifeline, the start event or the end event of an ExecutionSpecification."

    When should ExecutionOccurrenceSpecifications be used as start and finish of ExecutionSpecification, and when should Message/Destruction OccurrenceSpecifications be used instead? The ExecutionOccurrenceSpecification is the only one that has a reference back to ExecutionSpecification. Is there a guideline of when to use one over the other?

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: Pg. 617, Figure 17.4.4: Notation, Sub-clause: Message

  • Key: UMLR-518
  • Legacy Issue Number: 18036
  • Status: open  
  • Source: Delligatti Associates, LLC ( Mr. Lenny Delligatti)
  • Summary:

    Title: Incorrect specification of the notation for a reply message.
    Summary:
    This clause states, “A reply Message (messageSort equals reply) has a dashed line with a filled arrow head.” A reply message has an open arrow head as shown in the usage example in Figure 17.14.

    Proposed Resolution: Replace “…filled arrow head” with “…open arrow head” in the excerpted sentence.

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

18.1.3 Semantics Use Case and Actors Extends P. 687 - No Alternative Path

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

    current text: Once a given fragment is completed, execution continues with the behavior of the extended UseCase following the ExtensionPoint.

    This means that inserting an extension UC can't ever supply alternative behavior to the base use cases, but can only supply additional behavior. This is contrary to the vast majority of practice.
    In addition, it prevents extension use cases from being used for exception handling where the behavior ends in the extension.

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

18.1.3 Semantics Use Case and Actors Extends P. 687 - First ExtensionPoint

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

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

    It is a bit unclear whether “first” means the first of extensionPoints in the

    {ordered}

    extensionLocation list or the first that is reached in the particular execution path.

    Please clarify

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: 18.1.3 Semantics Use Cases and Actors P. 686 - What classifiers can be a subject?

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

    current text: “The subject of a UseCase could be a system or any other element that may have behavior, such as a Component, subsystem, or Class”

    The restriction on behavior elements is not clear.

    This limits subjects to element that may have behavior. There is no OCL to enforce this. Is this only BehavioredClassifiers? Can a UseCase be the subject of usecase?

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: 18. Global - No discussion of use case instances

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

    Need some discussion on the use and limitations of use case instances

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: 18.1.3 Semantics Use Cases and Actors P. 686 - Multiplicity at Use Case end

  • Key: UMLR-511
  • Legacy Issue Number: 18054
  • Status: open  
  • Source: Soluta.net ( Adriano Comai)
  • Summary:

    current text: “When an Actor has an association to a UseCase with a multiplicity that is greater than one at the UseCase end, it means that a given Actor can be involved in multiple UseCases of that type.”

    [AC] This relationship between Actors and UseCases is asymmetric and in my opinion inconsistent. When a UseCase has a upper multiplicity >1 towards Actor, this means that multiple instances of Actor are involved. At the opposite end, the meaning is undetermined. This should be avoided in a metamodel definition. It would surely be less ambiguous to state that the upper multiplicity from Actor to UseCase is just 1.

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

18.1.3 Semantics Use Case and Actors Extends P. 687 - Show name of extension

  • Key: UMLR-510
  • Legacy Issue Number: 18056
  • Status: open  
  • Source: Soluta.net ( Adriano Comai)
  • Summary:

    current text: “Extend is a kind of DirectedRelationship, such that the source is the extending UseCase and the target is the extended UseCase. It is also a kind of NamedElement so that it can have a name in the context of its owning UseCase.”

    [AC] I can infer that the owning UseCase is the extending UseCase, but I think this should be stated again, to avoid misunderstandings. It could be also useful to give an example, with a specific figure, of a naming of the extend relationship.

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location:Page #640, 17.8.2 Example Sequence Diagram

  • Key: UMLR-514
  • Legacy Issue Number: 18040
  • Status: open  
  • Source: Oracle ( Darren Kumasawa)
  • Summary:

    Title: Need more complicated Example Sequence Diagram

    Summary:
    Section 17.8.2 should include an example of a more complicated Sequence Diagram that includes BehaviorExecutionSpecification, ExecutionOccurrenceSpecification and CombinedFragment metamodel elements. It is unclear how these elements should be ordered in the "fragment" set of the Interaction. See diagram 17.14 for an example that would be useful to see the metamodel elements depicted.

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: 18.1.3 Semantics Use Cases and Actors P. 686 - Multiple subjects require the same actors

  • Key: UMLR-512
  • Legacy Issue Number: 18052
  • Status: open  
  • Source: Soluta.net ( Adriano Comai)
  • Summary:

    current text: “The same UseCase can be applied to multiple subjects”.

    [AC] I would add: “if, and only if, it is associated with the same actors”. Otherwise, it would be possible to have an inconsistent “reuse” of use cases, with a different set of actors in each context.

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

18.1.3 Semantics Use Case and Actors Extends P. 687 - Single Location

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

    current text: “All of the behavior of the included UseCase is executed at a single location in the included UseCase before execution of the including UseCase is resumed.

    It appears that it’s not possible (or unclear how) to insert the same included Use Case in multiple locations in the base (including) use case. Surely this is possible.

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: weak sequencing p. 622

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

    Need better explanation and examples

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

What is a DurationConstaint

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

    I've read the description of firstEvent four times and I still do not understand it. Rewrite so there is a simple if/else that avoids the need to do detailed comparison between two very similar sentences.

    Suggest:

    A DurationConstraint is a Constraint that refers to a DurationInterval. which may be the interval between execution entering and exiting a single constrained element, or between selectable enter/exit events on a pair of constrained elements.

    ...
    When there are two constrainedElements, firstEvent[i] is true to select the enter, or false to select the exit event for execution of the corresponding constrainedElement.

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Time constant

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

    Time constant means something else to me.
    Suggest: constant time value

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

More detail on Express

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

    What is a symbol? Suggest: a symbol such as "+" may be used to define the functionality of a particular expression node.

    Are there any semantics for the inherited name? Suggest: the inherited name may be used to give distinct identifications to expression nodes.

    Are there any semantics for the inherited type? Suggest: the inherited type may be used to identify the type resulting from evaluation of the expression node.

    What type should be used for a set of values? Suggest: a domain-specific type system may be appropriate to represent a richer or more specific variety of values than can be modeled directly in UML.

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Expression examples unclear

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

    These are unclear. How many Expression nodes in "plus(x,1)"? Is "xor" well-formed without arguments?

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

OCL not indexed

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

    Index OCL

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Semantics Clarification

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

    What are the relative semantics of 'symbol' and 'name'? What are the relative semantics of 'type'?

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Event

  • Key: UMLR-587
  • Legacy Issue Number: 17836
  • Status: open  
  • Source: INCOSE ( Sanford Friedenthal)
  • Summary:

    Should there be a specific metaclass for event that DurationObservation and TimeObservation refer to.

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

incompatible multiplicities

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

    It defines a symbol is inconsistent with the [0..1] multi

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

one -- > first

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

    the first NamedElement is better than one event Element

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Orphan Title

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

    Orphan title. Use Keep with Next style

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

typo in 12.2.3 Model

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

    Last paragraph in 12.2.3 Model

    Currently

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

    Propose

    Relationships between elements in different Models generally have no direct impact on the contents of the Models because each Model is meant to be complete

  • Reported: UML 2.5b1 — Sun, 15 Sep 2013 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: Pg. 613, Figure 17.6 - : Incorrect multiplicities in the metamodel in Figure 17.6

  • Key: UMLR-521
  • Legacy Issue Number: 18030
  • Status: open  
  • Source: Delligatti Associates, LLC ( Mr. Lenny Delligatti)
  • Summary:

    The multiplicity shown for “coveredBy : InteractionFragment” is “”. However, I believe the lower multiplicity should be 1, not 0. A lifeline can only exist within an Interaction; it cannot exist independently. This is affirmed by the multiplicity of “1” shown in this figure for the end “interaction : Interaction”. And an Interaction is a type of InteractionFragment as we see in the metamodel in Figure 17.1. Therefore, an instance of Lifeline must always know at least one instance of InteractionFragment: the Interaction that owns it. And thus, the multiplicity for “coveredBy : InteractionFragment” should be “1..”, not “*”.

    Proposed Resolution:
    Change the multiplicity for the end “coveredBy : InteractionFragment” to “1..*”

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: p 611

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

    The notation in Figure 17.5 does not match the almost identical diagram of Figure 8.5

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Not clear when to use ExecutionOccurrenceSpecification with ExecutionSpecification

  • Key: UMLR-524
  • Legacy Issue Number: 18024
  • Status: open  
  • Source: Oracle ( Darren Kumasawa)
  • Summary:

    Location:
    Page #607, 17.2.3 Semantics, Execution Specifications
    Page #619, 17.5.3 Semantics, Execution Occurrence Specifications

    Summary:
    Page #607, 17.2.3 Semantics, Execution Specifications
    "Typically the start occurrence and the finish occurrence will represent OccurrenceSpecifications such as a receive OccurrenceSpecification (of a Message) and the send OccurrenceSpecification (of a reply Message)."

    Page #619, 17.5.3 Semantics, Execution Occurrence Specifications
    "A ExecutionOccurrenceSpecification represents, on a lifeline, the start event or the end event of an ExecutionSpecification."

    When should ExecutionOccurrenceSpecifications be used as start and finish of ExecutionSpecification, and when should Message/Destruction OccurrenceSpecifications be used instead? The ExecutionOccurrenceSpecification is the only one that has a reference back to ExecutionSpecification. Is there a guideline of when to use one over the other?

    Source: darren.kumasawa@oracle.com

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location p413 Final Node - Rollback behavior

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

    Consider adding a «rollback» region that is automatically executed if the parent is canceled.

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location p413 Final Node - Atomic behavior

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

    It is often necessary to prevent an ActivityFinalNode from terminating behavior in the middle.
    We recommend the creation of a stereotype for an Activity or Action, such as «atomic» which indicates that reaching an ActivityFinalNode on the diagram will allow the behavior to finish, but that no output tokens are emitted when this occurs.

    This prevents some sorts of inconsistency that can occur when cancelling.

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: 17.3.4 Notation Lifeline p 613 - Specification of color

  • Key: UMLR-519
  • Legacy Issue Number: 18033
  • Status: open  
  • Source: Delligatti Associates, LLC ( Mr. Lenny Delligatti)
  • Summary:

    Description: This clause states, “ExecutionSpecifications are represented as thin rectangles (grey or white) on the lifeline.” However, this is inconsistent with the idea that UML does not prescribe color for notations

    Proposed Resolution: In place of references to color, we should stick with the convention of using the terms “hollow” to mean the same color as the diagram background and “solid” to mean the same color as the boundary of the node or the path notation. In the case of overlapping notations (e.g. ExecutionSpecifications), perhaps the spec. can prescribe patterns (e.g. cross-hatch) instead of color.

    Source: Lenny Delligatti
    Discussion:

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: Pg. 613, Figure 17.6 - Incorrect multiplicities in the metamodel in Figure 17.6

  • Key: UMLR-520
  • Legacy Issue Number: 18031
  • Status: open  
  • Source: Delligatti Associates, LLC ( Mr. Lenny Delligatti)
  • Summary:

    The multiplicity shown for both ends named “covered” of type “Lifeline” is “*”. The multiplicity for both of these ends should be “1” to match the metaclass entries for “OccurrenceSpecification” and “StateInvariant”. Both entries show that these two metaclasses each have an association “covered : Lifeline [1]”. And “1” is the intuitively correct multiplicity; an instance of OccurrenceSpecification (e.g. send, receive, start, end, destruction) can only be associated with a single lifeline. And an instance of StateInvariant is placed on a single lifeline.

    Proposed Resolution:

    Change the multiplicity for both of the ends “covered : Lifeline” to “1”.

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Interactions p 607

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

    Current text:
    The invalid set of traces is associated only with the use of a Negative CombinedInteraction. For simplicity we describe only valid traces for all other constructs

    This is not quite true
    1) An assert declares all non-compliant traces as invalid
    2) It may also be possible to use consider on normal trace where the message to be considered is not in the trace to indicate that if it occurs it is invalid.
    3) It is also possible to declare invalid traces with state invariants. For example, imagine a constraint such as

    {1=2}

    Source: Michael Jesse Chonoles

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: 16.2.3 Semantics / Opaque Actions

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

    Detail:
    Why restrict OpaqueActions to textual concrete syntax, when other approaches are possible.

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: Figure 15.67 page 436

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

    Detail:
    Show notation to indicate specific partitions for control nodes

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: p 504 - Marshall Actions

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

    Why aren’t there Marshall Actions

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Inconsistent approach to type conformance

  • Key: UMLR-606
  • Legacy Issue Number: 17613
  • Status: open  
  • Source: Object Management Group ( Andrew Watson)
  • Summary:

    The specification makes inconsistent statements about checking that communication between objects takes place according to the parameters of the communication mechanisms used.

    1. In some places the specification says that UML does not attempt to define a type-safe conformance relationship:

    1.1 On p128, in Semantics of Operations, it says:

    "Different type-conformance systems adopt different schemes for how the types of parameters and results may vary when an Operation is redefined in a specialization. When the type may not vary, it is called invariance. When the parameter type may be specialized in a specialized type, it is called covariance. When the parameter type may be generalized in a specialized type, it is called contravariance. In UML, such rules for type conformance are intentionally not specified."

    1.2 On p308-309 it says:

    "A method of an Operation shall have Parameters corresponding to the Parameters of the Operation. ... The data values associated with a request - input Operation parameter values or Signal attribute values - are then passed to a method invoked due to the request via the method parameters. ...

    However, no one approach is defined for matching the Parameters of the method to the Parameters of the BehavioralFeature. Possible approaches include exact match (i.e., the type of the corresponding Parameters, order, must be the same), co-variant match (the type of a Parameter of the method may be a subtype of the type of the Parameter of the BehavioralFeature), contra-variant match (the type of a Parameter of the method may be a supertype of the type of the Parameter of the BehavioralFeature), or a combination thereof."

    2. On the other hand, in several places the specification does try to define rules for type conformance, with varying levels of success:

    2.1 On p158 isConsistentWith is defined on operations, apparently in an attempt to test whether a operation can be redefined in a type-safe way. While the isConsistentWith semantics are broken on at least two counts (see separate issue report), this is an attempt to define a rule for type conformance on operations (albeit with a different name).

    2.2 p187: "By declaring a Reception associated to a given Signal, a Classifier specifies that its instances will be able to receive that Signal, or a subtype thereof, and will respond to it with the designated Behavior." i.e. Signals must be passed in a type-conformant way.

    2.3 p252: "A Port may be redefined when its containing EncapsulatedClassifier is specialized. The redefining Port may have additional Interfaces to those that are associated with the redefined Port or it may replace an Interface by one of its subtypes." Again, this is type conformance on Ports. There's similar language for redefining Connectors in a type-conformant way on p248.

    2.4 p424: "If the ObjectNode is untyped then the Parameters shall also be untyped. Otherwise, the input Parameter shall have either the same type as or a supertype of the ObjectNode, while the output Parameter shall have either the same type or a subtype of the ObjectNode." Again, this is type-conformant.

    Conclusion - there are several places where UML does intentionally define rules for type conformance. For consistency, either these type conformance rules should be removed or (preferably), the unhelpful statements (1.1 & 1.2 above) that UML does not enforce type conformance should be removed, and replaced by appropriate definitions of type conformance on Operations (perhaps based on a debugged version of isConsistentWith).

  • Reported: UML 2.5b1 — Wed, 19 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Issue for UML 2.5 FTF against Clause 9: Classifiers

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

    Section 9.6.4. There is no notation for raisedException. Can we add a notation?

  • Reported: UML 2.4.1 — Tue, 25 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

"Object identity" undefined

  • Key: UMLR-604
  • Legacy Issue Number: 17615
  • Status: open  
  • Source: Object Management Group ( Andrew Watson)
  • Summary:

    UML semantics depend on "object identity", an undefined concept

    The rearrangement of UML concepts in dependency order, to minimise forward references, is nicely done in this specification. It highlights how careful UML is about defining all the concepts it uses (with the exception of the primitive types in Section 21, which are explicitly imported into the language).

    However, the term "object identity" is explicitly or implicitly used in a few places in the specification, but never defined. Worse, its introduction leads to undefined semantics for part of the language.

    1. References to the undefined concept "object identity".

    1.1 p38 "That is, no two values in the collection may be equal, where equality of objects (instances of Classes) is based on object identity ..."

    1.2 p184 "A DataType is a kind of Classifier. DataType differs from Class in that instances of a DataType are identified only by their value. All instances of a DataType with the same value are considered to be equal instances."

    This is an implicit reference to Class instances being identified by something other than their value (presumably their "object identity"). However, we search in vain for the corresponding text in the section on the semantics of Class to tell us how Class instances are identified.

    1.3 p488 "A TestIdentityAction is an action that tests if the two values given on its InputPins are identical objects ...

    If an object is classified solely as an instance of one or more Classes, then testing whether it is the "same object" as another object is based on the identity of the object ..."

    2. Undefined semantics as a result

    2.1 p488 "The result of a TestIdentityAction for objects that are classified by both Classes and DataTypes, or by other kinds of Classifiers, is not defined, but, in all cases the Action produces a Boolean result."

    Conclusion
    ----------
    Either the specification should define "object identity" (although this would still leave TestIdentityAction undefined under some circumstances), or (preferably) this undefined, implementation-level concept should be replaced by a definition of equality grounded in the equality of Primitive Types (with equality on all other Types being recursively defined in terms of equality on Primitive types).

  • Reported: UML 2.5b1 — Wed, 19 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Consistent use of "conforms to" vs. "is a subtype of"

  • Key: UMLR-605
  • Legacy Issue Number: 17611
  • Status: open  
  • Source: Object Management Group ( Andrew Watson)
  • Summary:

    "The query conformsTo() gives true for a Type that conforms to another."

    While the OCL throughout the text does indeed use the conformsTo() operation, the textual descriptions alongside the OCL mix references to "conformance" with references to "one Type being a subtype of another".

    For clarity, I suggest that either all these uses of "subtype" in the text are replaced by references to "conforms to" or (less preferable), some text is included in this description on p65 to say that "subtype" is a synonym for "conforms to".

    It might also be useful to include some words about type conformance in the very-short description of the Semantics of Types in section 7.5.3 (p37).

  • Reported: UML 2.5b1 — Wed, 19 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Notation for Variables and Variable Actions is very vague and incomplete

  • Key: UMLR-455
  • Legacy Issue Number: 18506
  • Status: open  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Sebastien Gerard)
  • Summary:

    I think the notation for variables is supposed to be covered by the notation for variable actions – see figure 16.38, which describes a presentation option, but there is actually no specification for the canonical notation that it is an option for – nor was there in 2.4. We need a new issue: “Notation for Variables and Variable Actions is very vague and incomplete

  • Reported: UML 2.5b1 — Wed, 27 Feb 2013 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Rg. Realization and InterfaceRealization

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

    not sure, but the way how Interfaces are supposed to be realizd throughout the spec may need some more Clarification in the spec. I might have missed some discussions on this topic, though. If this has already been clarified (haven’t found an issue in the issue sheet for the component section), please ignore my question.

    The required/provided Interfaces of Components are derived. The derivation algorithm (p 235) makes use of Classifier.allRealizedInterfaces() and C.allUsedInterface(). I do not have any problems with allUsedInterface, but allRealizedInterfaces() or more concrete directlyRealizedInterfaces() is not very well chosen I think. directlyRealizedInterface() is based on Realizations between the Classifier and an Interface. Given this, any Interface that is referenced by ComponentRealization or Substitution is part of the realized Interfaces of that Classifier.

    As a BehavioredClassifier, a Component should make use of InterfaceRealization solely. However, the provided Interfaces of a Component rely on the above mentioned concept, i.e., a Realization between a Classifier and Interface. Of course, using an InterfaceRealization instead would also do the job and calculate the provided Interface of that Component correctly. In case of Class and Component, it is just confusing why the algorithm to calculate the provided Interfaces is based on Realization, whereas BehavioredClassifier uses InterfaceRealizations. It could be even more confusing, in case only Realization relationships are used to establish the provided Interfaces, asking for BehavioredClassifier.interfaceRealization might return an empty list, since all Interfaces are realized via Realization.

    This may cause other issues: A DataType could establish a Realization dependency to an Interface. Classifier.allRealizedInterfaces() would return that Interface. This holds true for all non-Class Classifier, in fact. Is this a desired situation?

  • Reported: UML 2.5b1 — Fri, 22 Feb 2013 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Clarification needed about the semantics of stereotype specialization and stereotype application

  • Key: UMLR-444
  • Legacy Issue Number: 18706
  • Status: open  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    Many profiles define stereotypes that specialize other stereotypes.
    UML 2.5 does this in two places:

    • UML 2.5, section 12.3.5 Examples, Figure 12.19 where the Entity and
      Session stereotypes specialize the Bean stereotype
    • UML2.5, section 22 StandardProfile, Figure 22.1 where the File
      stereotype has several specializations (Document, Executable, Š)

    The UML specification does not explicitly define a the semantics of
    stereotype specialization, particularly with respect to stereotype
    application.
    This puts UML users and UML tool vendors in the difficult position to
    interpret the UML specification to come up with such a semantics.
    Given the popularity of UML profiles in practice, the UML specification
    must explain this clearly.

    I propose using the UML semantics of classifier generalization as a
    guiding principle for specifying the semantics of stereotype
    specialization and application; that is:

    1) If a stereotype S2 specializes S1, then the semantics of S2 must be
    consistent with the semantics of S1.
    2) Given (1), the semantics of applying S2 to X must be consistent with
    the semantics of applying S1 to X.
    3) Given (1) and (2), it must be possible to define S2 in several ways:

    3a) S2 specializes S1; S1 is abstract and does not define any extension;
    S2 extends Classifier.

    There is only one property: S2::base_Classifier.
    It is not possible to apply S1 because it is abstract.
    Only S2 can be applied.

    3b) S2 specializes S1 but S2 does not define its own extension; instead,
    it inherits S1's "base_" property or properties.

    It is possible to apply S1 or S2 or both to the same element.
    The semantics should be consistent regardless of whether S1 only, S2 only
    or S1 and S2 are applied.

    3c) S2 specializes S1 and defines its own extension(s) by specializing
    S1's extension relationships and redefining the extension ends.

    For example, suppose S1 extends Classifier, then S1 has a property:
    S1::base_Classifier.
    Then, if S2 extends Classifier, the extension between S2 and Classifier
    specializes the extension between S1 and Classifier with redefinitions on
    both sides.
    That is, S2::base_Classifier

    { redefines S1::base_Classifier }

    This ensures that the semantics of applying S1 only to a Classifier is
    consistent with the semantics of applying S2 only to the same Classifier
    and with the semantics of applying S1 and S2 to the same Classifier.

    3d) S2 specializes S1 and defines its own extensions(s) but does not
    specializes any of S1's extensions.

    For example, suppose S1 extends Classifier, then S1 has a property:
    S1::base_Classifier.
    Then, if S2 extends Classifier without specializing S1's extension, then
    there are two distinct properties: S1::base_Classifier and
    S2::base_Classifier
    This should be ill-formed; there should be an explicit specialization of
    the extension and redefinitions of both sides as in (3c).

  • Reported: UML 2.5b1 — Fri, 10 May 2013 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Issue for Figure 17.18

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

    Figure 17.18 (Abstract Syntax: InteractionUse) does not show the association ‘A_returnValueRecipient_interactionUse’

  • Reported: UML 2.5b1 — Tue, 19 Mar 2013 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Clarification about Interactions owning Actions and about the semantics of Actions owned by Interactions

  • Key: UMLR-448
  • Legacy Issue Number: 18696
  • Status: open  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    In UML 2.5, the summary of the Actions chapter in 16.1 refers to the possibility of an Interaction owning an Action and makes several points:

    (1) Actions are contained in Behaviors, specifically Activities (as ExecutableNodes, see Clause 15) and Interactions (see Clause 17). These Behaviors determine when Actions execute (2) and what inputs they have (3). However, the abstract syntax and semantics of Actions are very dependent on Activities (4), because they specialize elements and semantics from Activities to accept inputs and provide outputs and to define Actions that coordinate other Actions (Structured Actions, see sub clause 16.11).

    (1) is reflected in figure 17.1

    (2) is under-specified.

    17.12, ActionExecutionSpecification states:
    An ActionExecutionSpecification is a kind of ExecutionSpecification representing the execution of an Action.
    17.5.3 semantics of Action Execution Specification states:
    ActionExecutionSpecification is used for interactions specifying messages that result from actions, which may be actions owned by other behaviors.

    The semantics of ActionExecutionSpecification should be described in 1 place; suggest 17.12.

    (3) is a problem because 17.12 + 17.5.3 are insufficient to explain the semantics of ActionExecutionSpecification.

    Depending on who owns the Action and of the context classifier for the Action vs. the Interaction, several cases need to be distinguished.
    An ActionExecutionSpecification refers to an Action owned by the owning Interaction
    An ActionExecutionSpecification refers to an Action owned by an Activity whose context classifier is different than the context classifier of the owning Interaction
    An ActionExecutionSpecification refers to an Action owned by an Activity whose context classifier is also the context classifier of the owning Interaction
    The first case is severely under-specified.
    The last two cases are more complicated because the semantics of ActionExecutionSpecification depends on the semantics of Action owned by an Activity.

    In all 3 cases, it is unclear how the message notation in Interactions relates to the input/output pins of actions referred to via an ActionExecutionSpecification.

  • Reported: UML 2.5b1 — Tue, 7 May 2013 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

[UML 2.5] Redundancy in the definition of use case extensions

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

    As pointed out by Pete in issue #7793, there is a redundancy between ExtensionPoint::useCase and Extend::extendedCase since the later can be derived from the use case owning the ExtensionPoint. It should be specified as such.

  • Reported: UML 2.5b1 — Thu, 21 Feb 2013 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Issue with Reply message in interactions (UML 2.5 Beta)

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

    There is a clarifying statement for the labels on reply messages that was added in UML 2.5 Beta, which reads:

    "The message-name appearing in a reply-message-label is the name property of the Message. If the Message has a signature, this will be the name of the Operation referenced by the signature (which should be the Operation for whose call this is a reply)."

    This is more constrained than was the case in UML 2.4 and can lead to some backward compatibility problems. Namely, there is a situation supported in RSA-RTE where the reply message to an Operation call can have a different label than the name of the Operation to which it is a response.

    Although there is no OCL constraint that mandates that the label of the reply message has to be the same as the Operation that caused it, the above text can be interpreted as if such a constraint existed. My suggestion is to modify the second sentence in the quoted text above to read:

    " If the Message has a signature, this can be the name of the Operation referenced by the signature (which should be the Operation for whose call this is a reply)."

    This leaves the clarification in place, but does not prevent the possibility of different labels on the reply message.

  • Reported: UML 2.5b1 — Thu, 14 Feb 2013 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Incorrect notation in figure 14.37

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

    Figure 14.37 shows an “extended” state machine. In it, the state ReadAmount is shown as extended, which means it is not inherited. Hence ReadAmount should have a solid border, not a dashed one.

  • Reported: UML 2.5b1 — Wed, 8 May 2013 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Shouldn't Gate and InteractionFragment be redefinable to support Interaction specialization?

  • Key: UMLR-446
  • Legacy Issue Number: 18698
  • Status: open  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    ML 2.5 section 17.2.3 Interaction semantics says:

    As Behavior an Interaction is generalizable and redefineable. Specializing an Interaction is simply to add more traces to those of the original. The traces defined by the specialization is combined with those of the inherited Interaction with a union.

    If a parent Interaction defines Gates, then a specializing Interaction will inherit its parent's Gates as Classifier::/inheritedMember.
    However, Gates that are inherited from a parent Interaction are not formalGates of a specializing Interaction; therefore, they cannot be used or redefined in the context of the specializing Interaction!

    Similarly, if a parent Interaction has fragments, then a specializing Interaction will inherit its parent's InteractionFragment as Classifier::/inheritedMember.
    However, InteractionFragment that are inherited from a parent Interaction are not fragments of a specializing Interaction; therefore, they cannot be used or redefined in the context of the specializing Interaction!

    To support the intent of the Interaction semantics, I suggest adding RedefinableElement as generalization parents of Gate and InteractionFragment.

  • Reported: UML 2.5b1 — Tue, 7 May 2013 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML 2.5 - figures 14.37 and 14.38 use incorrect notation for keyword

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

    Figures 14.37 and 14.38 show the word

    {extended}

    but the notation definition in 14.3.4 defines the keyword «extended» in guillemets. If it is a keyword, which is confirmed by Annex C, then the guillemets are correct and the curly braces wrong.

  • Reported: UML 2.5b1 — Wed, 13 Feb 2013 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: Page 265, 12.2.3 Semantics - Unchanged URIs

  • Key: UMLR-557
  • Legacy Issue Number: 17949
  • Status: open  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    "The URIs should hence be unique and unchanged once assigned." The UML metamodel changes its URI with every release. I think the UPDM profile used the same URI for multiple packages/profiles. Both of which conflict with the specification statement

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: 12.2.3 Semantics Package p 265 - Reference to unknown section heading

  • Key: UMLR-555
  • Legacy Issue Number: 17948
  • Status: open  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    The reference "(see Using XMI to Exchange Profiles in section Profile)", isn't using a known section heading and doesn't give a relevant section number.

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: 9.6.4 Notation p 127 Missing Infix operation syntax / discussion

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

    Location: 9.6.4 Notation p 127 Missing Infix operation syntax / discussion

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

ParameterSet Notation

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

    Notation for parameterset in a standard operation calls is very needed. If parametersets are used in an activity diagram, it may not be possible to match this up with an operation on the class, either in a list of operations or from a sequence diagram

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: constraints class_behavior p.190

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

    current text:
    If a behavior is classifier behavior, it does not have a specification

    Why is this so. How do you handle classifier behavior that has parameters (sometime called object behavior). It’s usually started by the constructor.

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location 10.3.3 Receptions p.186 - exceptions for receptions?

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

    Can’t receptions have out exceptions?

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

p 118: isException and other outputs

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

    An output posted to a Parameter with isException true during an invocation of a BehavioralFeature excludes outputs from being posted to any other outputs of the BehavioralFeature during the same invocation.

    This does not seem to match description of how exception handlers work later. I would rewrite it:

    Proposed text:
    An output may be posted to a Parameter with isException true during an invocation of a BehavioralFeature. When this occurs, unless an ExceptionHandler catches the exception, other outputs are not posted from the BehavioralFeature during the same invocation. When an ExceptionHandler catches the exception, outputs are posted from the BehavioralFeature at the level of the ExceptionHandler.

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: Constraints p 193 - All feturs must be public?

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

    Why
    An interface should be allowed to have not public proprieties/attributes. These are necessary to have them referred to in the protocol state machine, but they need not be public attributes, i.e., no direct or query-based access to their values from he outside. They need to be there to allow for a consistent description of the state-based behavior.

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location p 162 ParameterSet associationends: Exceptions and parametersets

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

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

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: 12.1 Packages Summary p 264

  • Key: UMLR-558
  • Legacy Issue Number: 17947
  • Status: open  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    Summary:

    "Models...which organize extensions to UML." suggests that Models contain extensions, which I don't think is true.

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: Figure 11-5 (ii) p 204

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

    How do we show that each engine has 2 connections to each Wheel, as opposed to two in total?

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Query of alternative scopes?

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

    It should be possible within UML to query which of the alternative semantics apply.

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Problems with XMI IDs in the UML 2.5 UML.xmi file

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

    In the case of a derived, non-union attribute for which there is a corresponding derivation operation with the same name, the XMI IDs of one or the other of the attribute or the operation are incorrect in the UML 2.5 Beta 1 UML.xmi file (that is, inconsistent with what the IDs were in UML 2.4.1). For example, the XMI ID for the attribute NamedElement::qualifiedName is AcceptCallAction-qualifiedName. The XMI ID for the operation Namespace::importedMember is ConditionalNode-importedMember. Worse, the XMI IDs of the attribute Connector::kind and the operation Connector::kind are both the same, Connector-kind.

  • Reported: UML 2.4.1 — Fri, 5 Oct 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

17 Semantics of interactions

  • Key: UMLR-487
  • Legacy Issue Number: 18131
  • Status: open  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    17 Semantics of interactions (missing constraints for resolving Operations, Signals and Actions in MessageOccurrenceSpecifications & ExecutionOccurrenceSpecifications in the scope of the Interaction itself)
    Consider Figure 17.2 (in the UML2.5 Revised August draft):

    Clearly we expect that:

    "oper1()" is a Message whose Message::signature refers to A::oper1()

    "callback()" is a Message whose Message::signature refers to C::callback()

    However, there is nothing in the spec that constrains the ownership of a Message::signature : NamedElement relative to the Interaction context of that Message.

    In fact, other possible interpretations because UML does not prescribe a particular resolution process for determining the Behavior for a given BehavioralFeature or Reception (see section 13.2.3)

    The spec does not currently specify any kind of bound on this resolution process — that is, Behaviors could be found potentially anywhere in the model.

    This is obviously absurd: it is unreasonable to expect that Figure 17.2 corresponds to a model where neither A nor C define "oper1()" or "callback()" but rather that these 2 operations are defined in an completely unrelated class not involved in the interaction at all – e.g., B.

  • Reported: UML 2.4.1 — Tue, 2 Oct 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML Interactions do not provide the ability for Messages to correspond directly to property accesses and updates

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

    It is a pity that UML Interactions do not provide the ability for Messages to correspond directly to property accesses and updates

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: B.6 UML ProfileDiagrams . 768 - Profile Diagram Elements

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

    Wouldn’t this be the «profile» Package being modeled?

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: B.6 UMLClass Diagram P. 757 - Class namespace diagrams?

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

    if I'm using a class diagram to show the namespace structure of a class (not the composite structure), wouldn't that classdiagram have a modelElement, that of the owning class

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Overriding deferred events

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

    Category: Minor

    The 2.5 spec says:

    “Event occurrences remain in the event pool until:

    · a state configuration is reached where these Event types are no longer deferred or,

    · if a deferred Event type is used explicitly in a Trigger of a Transition whose source is the deferring State (i.e., a kind of override option)

    It is not clear if the override capability extends inside the deferring State or only on the outside. The latter option was chosen in the spec, since it would be difficult to spot the override if it occurred inside the deferring state. But….

  • Reported: UML 2.4.1 — Wed, 10 Oct 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Stable state not needed

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

    Category: Minor

    The 2.5 spec says:

    “A state configuration is said to be stable when:

    · no further Transitions from that state configuration are enabled and

    · all the entry Behaviors of that configuration, if present, have completed (but not necessarily the doActivity Behaviors of that configuration, which, if defined, may continue executing”

    I believe that the concept of a stable state configuration is not necessary, since all state configurations are, by definition, stable. I cannot think of a transient one

  • Reported: UML 2.4.1 — Wed, 10 Oct 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: Annex C Keywords P. 778 - Inconsistent metaclass keywords

  • Key: UMLR-491
  • Legacy Issue Number: 18115
  • Status: open  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    There a number of keywords that are used when the same notation is used for multiple metaclasses. These aren't derived from the name of the metaclass in a consistent manner. For example, centralBuffer for CentralBufferNode, deployment spec for DeploymentSpecification, substitute for Substitution.

    Stereotypes are now given as their exact name, without transliteration or abbreviation. Should the same approach be used for metaclasses?

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Default entry if default history transition missing

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

    Category: Minor

    The behavior in case of a default entry when the default history transition is missing was not specified; The following option was added in 2.5, but needs to be checked by vendors:

    “If no default history Transition is defined, then standard default entry of the State is performed”

  • Reported: UML 2.4.1 — Wed, 10 Oct 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: B.2.2 P. 738 - What ISO document

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

    Explain which document

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: Page 270/271, 12.2.3 Semantics - Model description confusing

  • Key: UMLR-549
  • Legacy Issue Number: 17956
  • Status: open  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    The description of Model uses viewpoint, vantage point and perspective. I realise these are synonyms but they don't really all need to be used here. Just use viewpoint as that is the attribute name. A Model is a view, but that isn't mentioned until the third paragraph. Really that should be in the first paragraph. Abstraction is also used giving the impression that it is something distinct from the viewpoint. However surely the viewpoint defines the level of abstraction. It might be a good idea to the define the terms viewpoint and view first of all and then show how Model relates to them.

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: Page 269, 12.2.3 Semantics - Association merge aggregation constraint is property rule

  • Key: UMLR-550
  • Legacy Issue Number: 17955
  • Status: open  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    Association Rules, Constraints 2 is a property rule so ought to appear there. The property rules ought to say something about shared aggregation too.

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: Page 286, 12.3.3 Semantics - Incorrect if statement

  • Key: UMLR-545
  • Legacy Issue Number: 17961
  • Status: open  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    "If the value is the name of a NamedElement..." doesn't make sense as the name is a string and doesn't have a qualified name.

    Proposed Resolution:

    Replace with:

    "If the value is a NamedElement..."

    Revised Text:
    Source: dave.hawkins@oracle.com

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: Page 285, 12.3.3 Semantics - Old behavior unnecessarily preserved

  • Key: UMLR-544
  • Legacy Issue Number: 17960
  • Status: open  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    "Matching between the names of Stereotype definitions and applications is case-insensitive, so naming stereotype applications with lower-case letters where the stereotypes are defined using upper-case letters is valid, although stylistically obsolete."

    What does matching actually mean here? I think this should really just say that the correct way to display stereotype names is exactly as they are in the model.

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 269, 12.2.3 Semantics - Property merge transformation conflicts with constrain

  • Key: UMLR-552
  • Legacy Issue Number: 17953
  • Status: open  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    Property Rules, Constraints 2 means that Transformations 7 is either wrong or unnecessary

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: Page 267, 12.2.3 Semantics - Type and TypedElement confusion

  • Key: UMLR-553
  • Legacy Issue Number: 17952
  • Status: open  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    General Package Merge Rules, Transformations 4 is round the wrong way. A TypedElement references a Type not the other way round. I suspect this rule shouldn't say anything about types at all. It should just be "All references to elements...resulting Elements..."

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: Page 265, 12.2.3 Semantics PackageMerge - Long-winded package merge description

  • Key: UMLR-556
  • Legacy Issue Number: 17950
  • Status: open  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    The paragraph starting "A PackageMerge can be viewed..." is a bit long-winded and contains lots of parentheses.

    Proposed Resolution:

    Simplify text, removing parentheses:

    A PackageMerge can be viewed as a set of transformations whereby the contents of the merged Package and the receiving Package are combined. Matching elements are merged into a single resulting element according to the formal rules of PackageMerge specified below. This is akin to “copying down” the features of superclasses into a subclass: the fully expanded subclass is the equivalent to the resulting package

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: Page 281, 12.3.3 Semantics - Duplicated text

  • Key: UMLR-546
  • Legacy Issue Number: 17959
  • Status: open  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    The "Defining Profiles for Non-UML Metamodels" section seems to duplicate the "Restricting Availability of UML Elements" section (which also has the wrong heading style). Surely this could just be done as a single block of text that describes the filtering rules in general and then gives a specific example using the UML metamodel, while stating that in theory other metamodels could be extended.

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 266, 12.2.3 Semantics - Un-matched resulting elements aren't always the same

  • Key: UMLR-554
  • Legacy Issue Number: 17951
  • Status: open  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    The "resulting element" is described as being the same when no match exists. However this isn't strictly true. References from the element may be updated to other resulting elements

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: Page 280, 12.3.3 Semantics - Note should be main text

  • Key: UMLR-548
  • Legacy Issue Number: 17957
  • Status: open  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    "[Note: ...]"

    I don't see why this is a note, it should just be a normal bit of text.

    Proposed Resolution:

    Remove "[Node:" and "]" keeping the note text.

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: Page 269, 12.2.3 Semantics - Property merge rule pointless

  • Key: UMLR-551
  • Legacy Issue Number: 17954
  • Status: open  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    Property Rules, Transformations 5 doesn't really do anything. It should probably be specifying the value of isDerivedUnion

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: Page 280, 12.3.3 Semantics - Poorly indented XMI

  • Key: UMLR-547
  • Legacy Issue Number: 17958
  • Status: open  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    The XMI for the HomeExample profile has variable indenting and unaligned XML open/close elements.

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML2.5: Clarification about UML profiles

  • Key: UMLR-460
  • Legacy Issue Number: 18366
  • Status: open  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    12.3.1 Summary

    The only mentions that the profile mechanism is applicable to arbitrary metamodel are:

    > The Profiles clause describes capabilities that allow metaclasses to be extended to adapt them for different purposes. (1st paragraph)

    The paragraph continues with "the UML metamodel". So the generality is very subtle.

    > In order to allow this, the reference metamodel must be defined as an instance of UML that corresponds to its definition using MOF.

    The next sentence reverts to the special case of a UML profile extending the UML metamodel:

    > Thus when defining a UML profile, the profile’s stereotypes are defined to extend the UML classes in the normative version of the UML metamodel whose XMI serialization is referenced in Annex E.

    The next paragraph is the same:

    > Profiles are not a first-class extension capability (i.e., it does not allow for creating new metamodels).

    > Rather, the intention of Profiles is to give a straightforward mechanism for adapting an existing metamodel with constructs that are specific to a particular domain, platform, or method.

    Again, the generality is lost in the next sentence:

    > Each such adaptation is grouped in a Profile. It is not possible to remove any of the Constraints that apply to UML using a Profile, but it is possible to add new Constraints that are specific to the Profile.

    The reasons for defining a profile are only explained in terms of extending the UML metamodel.

    If anything, these reasons are equally applicable for extending UMLDI!

    12.3.3 Semantics

    The sub-clause "Restricting Availability of UML Elements" is specific to UML profiles extending the UML metamodel.

    This is misleading. These restrictions are equally valid for UML profiles extending other metamodels (defined in UML of course)

    ProfileApplication.

    This is written again from the perspective of a UML profile extending the UML metamodel:

    > One or more Profiles that extend UML may be applied at will to a model Package.

    Again, the generality is lost.

    Stereotypes

    The "Restricting Availability of UML Elements" section in Profiles has the following constraint:

    > Stereotypes can participate only in binary Associations. The opposite class can be another Stereotype, a non-Stereotype Class that is a packagedElement of a Profile (directly or indirectly), or a UML metaclass.

    Because this constraint is in 12.3.1 only and not in 12.3.3, it is unclear whether this constraint is only applicable to UML profiles extending the UML metamodel or not.

    These problems are a consequence of the organization of the Profile clause which has an uneven split where the UML-based explanation is in one place (12.3.1) and the generic explanation elsewhere (12.3.3)

    For readers, it is difficult to tell whether there are differences between the two capabilities.

    It is difficult to tell what is specific to UML profiles extending the UML metamodel (I.e., does not apply to UML profiles extending other metamodels)

    It is difficult to tell whether users have to figure out how to "merge" 12.3.1 and 12.3.3 for UML profiles that extend both the UML metamodel and some other metamodel.

    This difficulty comes from the duplication of the content, once for UML a second time for other cases.

    It would be better if the material were not duplicated at all and if there care special cases for UML profiles extending the UML metamodel that do not apply to other cases, then have these clearly described in a sub-clause.

  • Reported: UML 2.5b1 — Tue, 8 Jan 2013 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Serilaization of required stereotypes

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

    There are some specific cases where serialization of Extension instances resulting from the application of a stereotype does not provide any added value. However it creates a memory footprint overhead. These cases can be characterized by the conjunction of the following conditions:
    The stereotype is defined so that it is an required extension (i.e. its isRequired property is “true”)
    This stereotype does not have any property or all of its properties are derived (i.e. isDerived is “true”)

    As per the current specifications of UML and MOF2XMI, I cannot find anything that formally implies the serialization of extensions resulting from the application of such a stereotype but this reading appears to be controversial (cf. the attached mails exchange).

    Nevertheless, the standard way to add semantics in a profile relies on stereotypes definition only and there are some practical cases leading to defined stereotypes of the kind described above. For instance, within the SysML specification we defined a set of queries to retrieve elements involved in a specific kind of relationships (e.g. allocation), even if those elements do not themselves hold any information about it.

    Finally, those stereotypes are no more that a specification mechanism used to define a set of query applicable to a set of elements and the memory footprint overhead is not justified.

    Suggested resolution:
    To add a Boolean query (with maybe a corresponding derived property) to the Extension metaclass. This will return “true” when an extension shall be serialized. I propose to use the following OCL expression to specify this query:

    context Extension
    def: mustBeSerialized() : Boolean = self.isRequired=false or self.ownedEnd.type.attribute->select(isDerived)->notEmpty()

    To clarify that extensions that return “false” to the query above are aliases for their base classes in any context where the profile is applied. Therefore, any reference to an element typed by the corresponding stereotype shall actually be resolved (and then serialized) as a reference to the corresponding instance of the extended class.

  • Reported: UML 2.5b1 — Mon, 11 Feb 2013 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Reply messages now mandatory?

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

    until UML 2.3, the spec said about reply messages: “If the Message represents a CallAction, there will normally be a reply message from the called Lifeline back to the calling lifeline before the calling Lifeline will proceed.”

    Did the initial submission team agree on making reply messages mandatory?

    I’m just asking because the above mentioned sentence was removed (actually already by UML 2.4 RTF) and there is only one example listed in the current spec for synchronous calls showing reply messages, and also the semantics of Message indicates that reply messages are mandatory from now on.

    Tool vendors commonly not enforce the existence of reply messages for synchronous calls.

  • Reported: UML 2.5b1 — Fri, 1 Feb 2013 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Semantics of TimeConstraints and DurationConstraints

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

    Specification: OMG Unified Modeling Language (OMG UML), Version 2.5 FTF – Beta 1 (ptc/2012-10-24)

    Subclause: 8.5.3

    A TimeConstraint is specified by a TimeInterval that has min and max TimeExpressions. Similarly, a DurationConstraint is specified by a DurationInterval that has min and max Durations. Both TimeExpressions and Durations identify Observations of specific event NamedElements. Should these observed event NamedElements be related to the constrainedElements of the constraints, and, if so, how?

  • Reported: UML 2.5b1 — Tue, 20 Nov 2012 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Notation for DurationObservation with two event elements

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

    Specification: OMG Unified Modeling Language (OMG UML), Version 2.5 FTF – Beta 1 (ptc/2012-10-24)

    Subclause: 8.4.4

    In 8.4.4 it says that “An Observation may be denoted by a straight line attached to the NamedElement it references.” However, a DurationObservation may reference two NamedElements. It is not clear what the notation is for that.

  • Reported: UML 2.5b1 — Tue, 20 Nov 2012 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Semantics of Namespaces

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

    Specification: OMG Unified Modeling Language (OMG UML), Version 2.5 FTF – Beta 1 (ptc/2012-10-24)

    Subclause: 7.4.3

    The semantics of Namespaces in 7.4.3 needs to be better specified. In particular:

    • The concepts of “enclosing Namespace”, “hidden members” and “accessibility/availability of names” need to be clearly defined.
    • The handling of name clashes , visibility and distinguishability needs to be better specified.
    • The use of partially qualified vs. fully qualified names needs to be addressed.
  • Reported: UML 2.5b1 — Tue, 20 Nov 2012 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Stereotype for extended bound element realization

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

    Specification: OMG Unified Modeling Language (OMG UML), Version 2.5 FTF – Beta 1 (ptc/2012-10-24)

    Subclause: 7.3.3

    UML 2.5 allows the “expanded bound element” for a template bound element to be related to the bound element using a realization. Should there be a standard stereotype to be applied to a realization used in this way?

  • Reported: UML 2.5b1 — Tue, 20 Nov 2012 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Interactions and parameter assignments

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

    is it intended to not let message arguments being assignable to attributes of the receiving lifeline?

    As an example: Lifeline A sends a synchronous operation call to Lifeline B for the operation op(in x:Integer). Assume that the Type Lifeline B represents owns a Property p:Integer. The received actual parameter x shall be assigned to Property p of the receiving lifeline.

    With the current semantics of Messages and its description for notation it is only possible to assign out/inout/return values to a receiving lifeline. Consider the case that a certain Lifeline receives a Signal (no out/inout/return parameter at all) and wants to store the value of an attribute of that Signal in an attribute (either of the surrounding Interaction or its context Classifier); this is not possible by default.

    In my realm (which is validation and testing mainly using UTP), this is quite normal. A system under test (SUT) responds with a Signal and some values of that signal need to be stored for later calculation or re-sending.

    Shall we allow this in Interactions?

  • Reported: UML 2.5b1 — Fri, 1 Feb 2013 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Please provide running footers or headers indicating the section/subsection of a page

  • Key: UMLR-468
  • Legacy Issue Number: 18252
  • Status: open  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    The UML 2.5 document has great hyperlink/navigation support.
    However, since sub-sub-sections are unnumbered, it is sometimes difficult to tell where we are in the document if the sub-section runs across multiple pages.

    For example, look at sub-section 14.2.3 Semantics. The short title makes sense for the bookmarks but in the document itself, it would be easier if we had: 14.2.3 StateMachines Semantics
    This particular sub-section runs over several pages and has several sub-sub-sections; e.g. "States" on p. 319. It's hard to tell we're in the middle of 14.2.3.
    Unfortunately, Acrobat doesn't have a way to highlight the bookmark corresponding to the page we're currently reading.

    I suggest adding a footer or header with the numbered section or sub-section title to each page.
    It would be even better if the footer/header were in fact a hyperlink to jump to the beginning of that numbered section/sub-section.

  • Reported: UML 2.5b1 — Tue, 6 Nov 2012 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Semantics of Message argument mapping in Interactions

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

    The spec is inconsistent regarding the correspondence of Message arguments and its in/inout parameter.

    In Section 17.4.3 it says: “The arguments of the Message correspond to the in and inout ownedParameters of the Operation, in the order of the ownedParameters.”

    This is also specified in the formal OCL constraint in Section 17.12, subsection Message, subsubsection Constraints

    However, in Section 17.4.4 it says: “A request-message-label may only have input-arguments with in-parameter-names if the Message has a signature. In this case, the input-arguments are matched by name to the in and inout ownedParameters of an Operation or the attributes of a Signal.”

    I assume that the OCL is correct and the Notation section would need clarification?!

  • Reported: UML 2.5b1 — Fri, 1 Feb 2013 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML2.5 issue: constraints needed in model of Standard Profile

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

    Issue 15144 pointed out a lot of flaws in the modeling of standard profiles. Some of those flaws involved the absence of constraints. To help manage the process, I’m raising a separate issue that just lists the constraints that are needed. They ought to be OCL in the profile.

    The client and supplier of Usages stereotyped by Call must be Operations.

    The client and supplier of Usages stereotyped by Create must be Classifiers.

    Realization and ImplementationClass may not both be applied to the same element.

    Specification and Type may not both be applied to the same element.

    The clients of Usages stereotyped by Send must be Operations, and the suppliers must be Signals.

  • Reported: UML 2.5b1 — Tue, 12 Feb 2013 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Meaning of access to constrainedElements

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

    Specification: OMG Unified Modeling Language (OMG UML), Version 2.5 FTF – Beta 1 (ptc/2012-10-24)

    Subclause: 7.6.3

    The semantics of Constraints includes the statement “The only restriction is that the owning Element must have access to the constrainedElements.” What does it mean for one Element to “have access” to another?

  • Reported: UML 2.5b1 — Tue, 20 Nov 2012 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: Page 286, 12.3.3 Semantics - Nonsensical alternative to stereotype name

  • Key: UMLR-543
  • Legacy Issue Number: 17962
  • Status: open  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    An alternative name is given for stereotypes:

    "If the ExtensionEnd is given a name, this name can be used in lieu of the stereotype name within the pair of guillemets when the stereotype is applied to a model element."

    Earlier, the specification of the extension end name is given as "extension_stereotypeName" so this is a rather bizarre option. When would this ever make sense?

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: p 410

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

    Show how to pass activities around

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: Page 328, 14.2.3 - UseCase cannot be the context of a StateMachine

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

    “If the StateMachine has a kind of BehavioredClassifier context, then that Classifier defines which Signal and CallEvent triggers
    are applicable”. A UseCase is a BehavioredClassifier and thus would be the context of a Statemachine. Since a UseCase cannot have Signal receptions or operations no such triggers would be applicable to this StateMachine.

    Proposed Res
    The radical solution would be to make UseCase not a BehavioredClassifier. However this would be out of scope. Therefore the next sentence should be changed:
    “If the StateMachine has no BehavioredClassifier context or this context is a UseCase…”

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: Signal Receipt symbol

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

    What is the motivation for the limitation on not have time events, or call events here

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: Page 346, State List Notations - Why must state lists be effect free?

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

    Why must they be effect-free? If all the transitions have the same effect, it would be easily understandable

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: 13.3.5 Examples p 314

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

    Explain why there are no examples

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: Opaque and Function Behaviors p 308

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

    Detail: Why limit OpagueBehavior to a textual specification. It seems to me that any language other than UML, including graphical languages would be opaque for this purpose.

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: p. 336 Compound transitions - Run-to-completion Paradigm

  • Key: UMLR-533
  • Legacy Issue Number: 17999
  • Status: open  
  • Source: University of Texas ( Omar Badreddin)
  • Summary:

    It should be stated that a do-activity is the exception here. Also, code within the do activity should be prevented from updating the state machine configurations or firing of events (directly or indirectly).

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: Page 316 redefinedBehavior - Extends

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

    What does “extends” mean in this context. Is it the extends of use cases? Or statemachines? Or profiles? I don’t believe it is defined clearly

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: Page 331 deep history entry - Default deep history entry

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

    Shouldn’t there be a default deep history transition. See p. 374.

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: Figure 12-13 p.281 - Incorrect use of << for «.

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

    Figure 12-13 has interface titled <<Home>> it should be «Home»

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT


How to model a transition to history pseudostates in two orthogonal regions?

  • Key: UMLR-610
  • Legacy Issue Number: 17596
  • Status: open  
  • Source: self-employed ( Volker Spinke)
  • Summary:

    A transition that terminates on the outside edge of a composite state is called a default entry. In this case, the default entry rule is applied e. g. the transition originating from the initial pseudostate is performed. If the most recently active substate prior to this entry shall become the active substate, the transition must be drawn to a history pseudostate. Page 564 clearly states this.

    Next, the composite state is extended to an orthogonal state with two regions. Both regions contain a history pseudostate. A transition shall fork to both history states. I thought this is easy to model by introducing a fork pseudostate in the transition and drawing two outgoing transitions from the fork to the history pseudostates.

    This is obviously not the case as constraints rule 3 on page 582 states: "A fork segment must always target a state. (source.oclIsKindOf(Pseudostate) and source.kind = #fork) implies (target.oclIsKindOf(State))"

    It is also mentioned at other locations that an outgoing transition of a fork pseudostate must target a state. Pseudostates are not allowed as targets of outgoing transitions from a fork pseudostate.

    I am confused by this rule. My question is: How do I have to model a transition ending on the history states in two orthogonal regions?

    Thanks for your kind advice.

  • Reported: UML 2.4.1 — Mon, 17 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Clarification on the semantics of inheritance between use cases

  • Key: UMLR-612
  • Legacy Issue Number: 17589
  • Status: open  
  • Source: THALES ( Hugues Vincent)
  • Summary:

    Title: Clarification on the semantics of inheritance between use cases
    Where: section 18
    Nature of Issue: Clarification
    Severity of Issue: Minor
    Full Description of the Issue:
    It appears in figure 18-11 as it is implied by the abstract syntax that inheritance among use cases is possible. The semantics of such an inheritance needs to be described.

  • Reported: UML 2.4.1 — Thu, 13 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Clarify aliasing in Namespaces

  • Key: UMLR-607
  • Legacy Issue Number: 17609
  • Status: open  
  • Source: Object Management Group ( Andrew Watson)
  • Summary:

    A couple of sentences explaining aliasing in Namespaces would be useful in the Namespace semantics section (7.4.3).

  • Reported: UML 2.5b1 — Wed, 19 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Clarify ownership vs. membership for NamedElements

  • Key: UMLR-609
  • Legacy Issue Number: 17607
  • Status: open  
  • Source: Object Management Group ( Andrew Watson)
  • Summary:

    "A namespace may also import NamedElements from other Namespaces, in which case these, along with the ownedMembers, are members of the importing Namespace."

    A sentence clarifying ownership vs. membership for NamedElements would be useful. As far as I can tell, every NamedElement is owned by the Namespace in which it was created, but is a member of both its owning Namespace and every Namespace into which it has been successfully imported.

    (However, where a NamedElement is a PackageableElement, importing it creates an ElementImport which becomes a member of the Namespace instead, to allow for the possibility of aliasing of the PackageableElement's name.)

  • Reported: UML 2.5b1 — Wed, 19 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Fuzzy diagrams

  • Key: UMLR-611
  • Legacy Issue Number: 17603
  • Status: open  
  • Source: Object Management Group ( Andrew Watson)
  • Summary:

    When viewed at high magnification (e.g. 500%), most of the diagrams in the PDF are quite fuzzy, and are clearly bitmaps. If possible, please regenerate them as vector diagrams.

  • Reported: UML 2.5b1 — Wed, 19 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Missing Example of TemplateBinding with model element "Class"

  • Key: UMLR-421
  • Legacy Issue Number: 19723
  • Status: open  
  • Source: gmail.com ( Jose Asdrubal Asencio)
  • Summary:

    I've been reviewing template binding where specifies substitution of Parameters in a Template Class and I found that:

    1- UML 2.5 haven't provided an example using class element model with binding relationship.

    2- UML 2.5 haven't provided an example, and example in code in whatever language programming or a note where explain what does it mean binding in code.

    I 've reviewed examples at Internet and there are not good examples relate with binding. Just very basic examples.

  • Reported: UML 2.5b1 — Mon, 16 Feb 2015 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Object Flow arrow heads are inconsistent: V-shaped vs triangular

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

    in Figure 15.53, the object flow use solid arrow heads, though it the rest of the activity diagram material, the arrow heads are v-shaped. Please correct or clarify.

  • Reported: UML 2.5 — Wed, 28 Jan 2015 20:29 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

More on SateMachines

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

    "An internal Transition can be taken even if the SateMachine is in one or more Regions nested within the associated State."

    Please correct spelling error

  • Reported: UML 2.5 — Thu, 15 Jan 2015 02:19 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Figure 14.5 State with Compartments does not show all the compartments that it should

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

    Before Figure 14.6. the text says:

    A State may be subdivided into multiple compartments separated from each other by a horizontal line (Figure 14.6).

    Immediately after Figure 14.6, the four compartments of a state are defined.

    • name
    • internal Behaviors
    • internal Transitions
    • decomposition

      However, in the Figure, the internal Behaviors and internal Transitions are in the same compartment. It appears that the line between the name compartment and the remaining compartments is required but the line between the internal Behaviors and Transition is not required.

    This should be made clear.

    Also, the example has the items in the state in the order that the compartments would be defined. Is this required? Can I mix them if no separate compartment is used?

  • Reported: UML 2.5 — Wed, 14 Jan 2015 22:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

BNF notation as given and used is unclear about italics

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

    In the description of our BNF format page 9.

    Bullet 1.
    All non-terminals are in italics and enclosed between angle brackets (e.g., <non-terminal>).

    The Angle brackets are given in Roman (non-italic) font, however (almost) all uses have italic angle brackets. See example, indicated below for multiplicity_range

    Bullet 2.
    All terminals (keywords, strings, etc.), are enclosed between single quotes (e.g., ‘or’).
    The example uses Roman font, but almost all uses have the terminals in italic anyway. The quotes are also in Roman

    Bullet 3
    Non-terminal production rule definitions are signified with the ‘::=’ operator.
    The ::= operator is always used in italics.

    Bullet 4
    Repetition of an item is signified by an asterisk placed after that item: ‘*’.
    The * is roman, but it (always?) appears in italic

    Bullet 5
    Alternative choices in a production are separated by the ‘|’ symbol (e.g., <alternative-A> | <alternative-B>).
    The | is in roman, but it is used in italic

    Bullet 6
    Items that are optional are enclosed in square brackets (e.g., [<item-x>]).
    This is in italics, and coincidently, it is always used in italics. However, based on bullet 1, the angle brackets should be in roman.

    This confusion is throughout the spec and makes implementation harder.

    For example in 7.5.4, where the BNF definition of multiplicity range is given at
    <multiplicity-range> ::= [ <lower> ‘..’ ] <upper>

    Bullet 1 rules. The < and > are given in italics violating Bullet 1

    Bullet 2 rules
    In this case, the ".." is given as italics (both the .. and the quotes).
    Does this mean that all multiplicities that use the .. should have them in italics?
    Bullet 3 rules. The ::= is given in italics

    Using the example also on the 7.5.4 for the definition of order-designator
    <order-designator> ::= ‘ordered’ | ‘unordered’
    Bullet 2, As ordered and unordered are terminals this indicates that the terms ordered and unordered should be shown in italics. IN the figure below 7.11 they are shown in roman.
    Rules from Bullet 3 and 5 are also violated.

  • Reported: UML 2.5 — Wed, 14 Jan 2015 21:48 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Figure 14.14 includes a "Submachine Sate"

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

    Spelling Error in Figure title

  • Reported: UML 2.5 — Wed, 14 Jan 2015 20:56 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

InformatonFlows are constrained to be Classes or Classifiers -- which one?

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

    "20.1.3 InformationItems may be decomposed into more specific InformationItems or Classifiers

    InformationItems may only be realized by Classes (of all kinds, including Components, AssociationClasses, Behaviors, etc.), Interfaces, Signals, and other InformationItems"
    ..
    Shoun't the word "Classes" in the 2nd paragraph above be changed to "Classifiers" This whole section seems to be unclear about this.

  • Reported: UML 2.5 — Mon, 9 Feb 2015 20:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Are DeploymentSpecification execution-time input to components -- meaning they are somehow read by the component while they are running/executng?

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

    in 19.2.3 [Deployments] Semantics there is the following claim:
    "DeploymentSpecification information becomes execution-time input to components associated with DeploymentTargets via their deployedElements links."

    Is this saying something about the deployed system must work, that it must have accessibility to the model?

    Please clafiry

  • Reported: UML 2.5 — Mon, 9 Feb 2015 19:53 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Can be performed their instances --> missing "by"

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

    that can be performed by their instances

    missing word

  • Reported: UML 2.5 — Mon, 9 Feb 2015 19:41 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

A State can only have one Do/ behavior, but example shows more than one.

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

    Figure 14.1 Behavior StateMachines indicates only 0..1 Entry, Do and Exit behavior for a state.

    However, Figure 14.10 has an exit behavior as
    exit / exit/ turn off main light; turn off secondary

    It is unclear whether list of behaviors (separated by are to be executed serially or in parallel.

    I suggest that both serial and parallel syntax be supplied and Figure 14.1 (and elsewhere) be modified to indicate more than one behavior is allowed.

    Else (and less useful) Figure 14.10 has to be fixed

  • Reported: UML 2.5 — Wed, 21 Jan 2015 05:53 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Some hyperlinks are underlined and some are not. This is inconsistent

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

    For example, see 15.2.3 Semantics
    On this page there are
    references to sub clause 15.4 (2x)
    sub clause 7,4
    and sub clause 13.2
    They are all hyperlinks, but only the last two are blue and underlined. The first two are in normal text font.

  • Reported: UML 2.5 — Wed, 21 Jan 2015 05:37 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML 2.5: Property::isConsistentWith() error

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

    There appears to be an error in the Property::isConsistentWith() operation (page 155 of the 2.5 spec). As written, it looks like this (with a bit of my editing for readability) :

    isConsistentWith(redefiningElement : RedefinableElement) : Boolean

    {redefines RedefinableElement::isConsistentWith()}

    // The query isConsistentWith() specifies, for any two Properties in a context in which
    // redefinition is possible, whether redefinition would be logically consistent. A redefining
    // Property is consistent with a redefined Property if the type of the redefining Property
    // conforms to the type of the redefined Property, and the multiplicity of the redefining
    // Property (if specified) is contained in the multiplicity of the redefined Property.

    pre: redefiningElement.isRedefinitionContextValid(self)
    body: redefiningElement.oclIsKindOf(Property) and
    let prop : Property = redefiningElement.oclAsType(Property) in
    (prop.type.conformsTo(self.type) and
    ((prop.lowerBound()>notEmpty() and self.lowerBound()>notEmpty()) implies
    prop.lowerBound() >= self.lowerBound()) and
    ((prop.upperBound()>notEmpty() and self.upperBound()>notEmpty()) implies
    prop.lowerBound() <= self.lowerBound()) and
    (self.isComposite implies prop.isComposite))

    The problem is with the second last line, which should read:

    prop.upperBound() <= self.upperBound())

    Seems like a copy-paste error.

  • Reported: UML 2.5 — Fri, 20 Feb 2015 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML 2.5 beta issue - Operation notation is wrong

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

    There is a paragraph in Operation notation 9.6.4 that says this:

    “The return result of the Operation may be expressed as a return parameter, or as the type of the Operation. For example toString(return: String) …”

    This is wrong. If it means anything, it means an in parameter called return. The BNF does not allow return as a term for <direction>, but if it did, then the correct example would be this:

    toString(return result : String)

  • Reported: UML 2.5b1 — Tue, 2 Apr 2013 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML2::Constraint

  • Key: UMLR-422
  • Legacy Issue Number: 14430
  • Status: open  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Sebastien Gerard)
  • Summary:

    When modelling a constraint in UML on several constrained elements, how is itpossible to know which constrained element is the context of the constraint?

    In the spec, the metaattribute context of Constraint is derived, but the spec does not define how it is derived.

  • Reported: UML 2.2 — Tue, 22 Sep 2009 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

These are typographical errors

  • Key: UMLR-411
  • Legacy Issue Number: 19710
  • Status: open  
  • Source: Anonymous
  • Summary:

    Page 97, Line 16: The parameters to the operation -> The parameters of the operation

    Page 173, Line 11: profile?s -> profile's

    Page 190, Figure 12.11: volume; JavaInteger -> volume: JavaInteger

    Page 194, Line 27: stereotype?s -> stereotype's

  • Reported: UML 2.5 — Fri, 16 Jan 2015 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Shouldn't it be possible to make the state of an object be private to support encapsulation/information hiding?.

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

    From the following
    "A guard constraint may involve tests of orthogonal States of the current StateMachine, or explicitly designated States of some reachable object"

    it appears, that no matter how reachable object is defined (see UMLR-402), if it is reachable, the state is accessible. This seems to go against the principles of encapsulation and information hiding. We can make all the attribute of an object private, but the state, which is a often defined by the values of the attributes can't be made private

    My age may be private, but the fact that I'm in the state of being a teenage must be public? <wishful thinking perhaps>

    There should be some way of making an object's state private.

  • Reported: UML 2.5 — Tue, 13 Jan 2015 14:19 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

States of Reachable objects may be used in guard constraints, but reachable is not defined

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

    "A guard constraint may involve tests of orthogonal States of the current StateMachine, or explicitly designated States of some reachable object."

    Unfortunately, reachable is only used in one other spot in the specification where it is also of no help.

    Are all objects reachable? Does it depend on whether there is a chain of relationships, does it depend if the object is in a publicly available package...

  • Reported: UML 2.5 — Tue, 13 Jan 2015 14:12 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Any Activity parameter is steaming. It must be too hot to handle

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

    under Activity Parameter Nodes, when describing Figure 15.52, the text indicates a "steaming Parameter"

    Please correct

  • Reported: UML 2.5 — Tue, 27 Jan 2015 19:59 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

adding error

  • Key: UMLR-405
  • Legacy Issue Number: 19696
  • Status: open  
  • Source: gmx.de ( Dr. Götz Wankelmuth)
  • Summary:

    There seems to be an error in the latest UML 2.5 spec:
    16.13.5 Examples
    A ReduceAction can be used to reduce a list of numbers to the sum of the numbers. Such a ReduceAction has one InputPin for a collection of numbers, one OutputPin for a number and an addition function as the reducer Behavior. For example, suppose the input collection has four integers: (2, 7, 5, 3). The result of applying the ReduceAction to this collection with an addition function is 11. With the default of isOrdered=false, this can be computed in a number of ways, for example, ( ( (2+7) + 5) + 3), (2 + (7 + (5 + 3))), ((2 + 7) + (5 + 3)).
    If I understand the text correctly, the result must be 17.
    Please reply to this mail because I use the Beta 2 spec in my courses.
    Sicerely yours,
    Mit freundlichen Grüßen,
    Götz Wankelmuth

  • Reported: UML 2.5 — Mon, 22 Dec 2014 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

orthogonal State missing on bullet point list

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

    On page 322 there is a bullet point list

    • simple State (isSimple = true)
    • composite State (isComposite = true)
    • submachine State (isSubmachineState = true)

    The entry

    • orthogonal State (isOrthogonal = true)
      is missing (but mentioned in the following paragraph).
      It is a special kind of composite State, so this could be a reason to leave it out from the list. However, I think it is distinct enough from the other three, and is even given a derived property, so it probably should also be in the list.
  • Reported: UML 2.5 — Thu, 8 Jan 2015 19:53 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Use of Qualifier and Qualified in same section of UML 2.5 spec should be more clearly disambiguated

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

    In Section 9.5, there are several statements mentioning "qualifiers"
    e.g.,
    A Property that is a memberEnd may itself have other Properties that serve as qualifiers.
    and
    The notation for qualifiers is defined in 11.5 Associations.

    However, there are several statements mentioning "qualified"
    e.g.,

    • 'subsets’ <property-name> means that the Property is a proper subset of the Property identified by <property-name>, where <property-name> may be qualified.
    • ‘redefines’ <property-name> means that the Property redefines an inherited Property identified by <property-name>, where <property-name> may be qualified.

    I suspect they are discussing different things. A qualified name vs an association end qualifier.

    Please have mercy on us and make the usages clearer.
    Thanks

  • Reported: UML 2.5 — Thu, 20 Nov 2014 18:42 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML needs standardized default package (or Model)

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

    All elements in UML, except for some top-level packages, must be owned by some other element. This means that people who create models without specifying the owning element chain are creating invalid models, that are incapable of being exchanged.

    Some tools automatically supply a default owning package, which makes the model valid. However, the tools do not agree on the owning package name or whether it a <<model>>> (stereotyped package)

  • Reported: UML 2.5 — Tue, 11 Nov 2014 04:18 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

shoes-->shows

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

    In section 7.6.5 the statement under figure 7.14 says:

    Figure 7.15 shoes a constraint string attached to an attribute

    I assume that shoes->shows

  • Reported: UML 2.5 — Thu, 13 Nov 2014 08:28 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

In Sequence diagrams it is unclear if the name of the Gate can be different from the name of the message

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

    Formal Gate
    A formal Gate is just a point on the inside of the frame, as the end of a message. They may have an explicit name (see Figure 17.4).

    1) The word "they" should probably be "it".
    2) However, the gate and the message are different nameable items. The examples, in Figure 17.3,4, and 5 all have one name which appears to be the name of the message.

    All three examples,should be clarified, and at least one having both the message and gate named differently.

    In the description of Figure 17.3, the gate is given the implicit name of out_Unlock. In an almost identical Figure 17.5, the description says the gate name is Unlock. Which is it?

  • Reported: UML 2.5 — Wed, 29 Oct 2014 23:07 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Inconsistent use of Oxford comma in "Behavior, Event, and Trigger"

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

    In 13.1
    paragraph 2
    "UML provides Behavior, Event, and Trigger"
    but in paragraph 6.
    "UML Modeling mechanisms of Behaviors, Events and Triggers"

    They should be the same format, preferably using the Oxford comma as is done in most other places.

  • Reported: UML 2.5 — Wed, 15 Oct 2014 18:37 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

AcceptEventActions where the triggers are all for ChangeEvents or CallEvents should allow output ControlPins

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

    AcceptEventActions that wait on ChangeEvents are prohibited from having result OutputPins.

    Why can't they have control output pins?

  • Reported: UML 2.5 — Wed, 8 Oct 2014 20:22 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Minor error in ptc-13-09-05

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

    In ptc-13-09-05.pdf on page 9 it says:

    Where items need to be grouped they are enclosed in simple parenthesis; for example:

    (<item-1> | <item-2>) *

    signifies a sequence of one zero or more items, each of which is <item-1> or <item-2>.

    I think the word one must be replaces by zero because on page 28 it says:

    If the lower bound is equal to the upper bound, then an alternate notation is to use a string containing just the upper bound. For example, “1” is semantically equivalent to “1..1” multiplicity. A multiplicity with zero as the lower bound and an unspecified upper bound may use the alternative notation containing a single star “” instead of “0..” multiplicity.

  • Reported: UML 2.5 — Fri, 10 Oct 2014 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Pin multiplicity and token upper bound

  • Key: UMLR-352
  • Legacy Issue Number: 19564
  • Status: open  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    I'm a little confused about the relationship between the multiplicity
    of a Pin and its token upper bound. What does it mean for the token
    upper bound to be less than the multiplicity upper bound, or even
    the multiplicity lower bound?

  • Reported: UML 2.5 — Fri, 25 Jul 2014 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Classifier::ownedTemplateSignature needs to subset Element::ownedElement

  • Key: UMLR-346
  • Legacy Issue Number: 19511
  • Status: open  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    UML composite properties must subset Element::ownedElement.
    Classifier::ownedTemplateSignature doesn't.

    Note that issue 12244 suggested making a change to replace
    the ownedElement subset with a redefinition of another
    property. By 2.5 the change had already been made, so
    the issue was closed no change in ballot 1. However it was
    never the correct thing to do as the previously resolved
    general composite issue 14926 pointed out.

  • Reported: UML 2.5 — Mon, 7 Jul 2014 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Issue against UML: implementation of OCL constraint containingProfile

  • Key: UMLR-345
  • Legacy Issue Number: 19488
  • Status: open  
  • Source: NIST ( Mr. Peter Denno)
  • Summary:

    Problem: Recursion in calls to the OCL operation containingProfile() does not properly terminate.

    Current OCL in the spec for Stereotype.containingProfile():
    self.namespace.oclAsType(Package).containingProfile()
    The problem with this is that the argument won't be seen as a Profile after oclAsType(Package).

    I suggest instead this OCL for Stereotype.containingProfile():
    if self.namespace.oclIsKindOf(Profile)
    then self.namespace
    else self.namespace.containingProfile()
    endif

    Current OCL in the spec for Package.containingProfile():
    if self.oclIsKindOf(Profile)
    then self.oclAsType(Profile)
    else self.namespace.oclAsType(Package).containingProfile()
    endif

    I suggest instead this OCL for Package.containingProfile():
    if self.oclIsKindOf(Profile)
    then self
    else self.namespace.containingProfile()
    endif

    There still may be problems if, for example, a Classifier (or other subtypes of Namespace) were a namespace for a Package. In those cases (which I assume don't really happen), we would need additional containingProfile() methods like the one on Package.

  • Reported: UML 2.5 — Wed, 25 Jun 2014 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

No specification of which visibility marking corresponds to which VisibilityKind value

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

    Nowhere does the spec say which visibility marking corresponds to which value. There is no specification that # means protected, for example. This would best live in 7.4.4.

  • Reported: UML 2.5 — Mon, 16 Jun 2014 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

ExpansionNodes owned by ExpansionRegions?

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

    Are ExpansionNodes owned by their ExpansionRegions? ENs are pin-like, so it seems like they should be, but then I would have expected ER::in/outputElement and EN::regionAsIn/Output to be subsetted from StructuredActivityNode::node and ActivityNode::inStructuredNode, respectively. ENs could still be owned by ERs as SANs without the subsetting, but I couldn't find what the spec says about it. Is there a MIWG test for this case?

    Ed S's response:http://www.omg.org/archives/model-interchange/msg02614.html

  • Reported: UML 2.5 — Fri, 30 May 2014 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Incorrect sentence

  • Key: UMLR-339
  • Legacy Issue Number: 19430
  • Status: open  
  • Source: toshiba-tsip.com ( VIRESH MOHAN)
  • Summary:

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

    The return value is 96 but the comment suggests 69 is getting assigned to v.

  • Reported: UML 2.5b1 — Thu, 22 May 2014 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

BehavioralParameter should be BehavioralFeature

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

    In Section 13.4, Subsection Behavior, Subsubsection Constraints, the Constraint parameters_match says in the second sentence:

    “The Behavior Parameters must also "match" the BehavioralParameter Parameters, but the exact requirements for this matching are not formalized.”

    BehavioralParameter is not correct and should say BehavioralFeature.

  • Reported: UML 2.5 — Sat, 7 Jun 2014 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML wording in Superstructure 2.4.1

  • Key: UMLR-341
  • Legacy Issue Number: 19454
  • Status: open  
  • Source: Anonymous
  • Summary:

    I have a comment concerning wording in the UML 2.4.1 Superstructure document
    you are using both "classifier rectangle" and "class rectangle" for describing
    presentation options. Is this really appropriate?
    I'd like to suggest to use "classifier rectangle" consistently since
    there is no
    special representation shape of a class, and class is a specialization
    of classifier.
    Additionally, at page 152, you give "Classifier rectangle" with
    capital letter.
    I think that, in terms of consistency, it should be "classifier
    rectangle" there as well.

  • Reported: UML 2.5 — Thu, 5 Jun 2014 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Message should extend Namespace

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

    Messages in Interactions should extend Namespace similarly as Transition extends Namespace. Being a Namespace (would be backwards compatible) would make it possible to specify Constraints among Parameter of the Signature merely in the context of the particular Message and in addition to the Constraints already applied on the signature itself. This would enable testers to specify fine-grained interdependencies among Parameter (and for argument generation) in that particular situation. Such a feature on Messages would be actually quite handy for test generation purposes – also, similar to what is currently already possible and being done with Transitions.

    Any thoughts on that?

  • Reported: UML 2.5 — Mon, 14 Apr 2014 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Semantics of static features

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

    “In §9.4.3, the following sentence: “The isStatic property specifies whether the characteristic relates to the Classifier’s instances considered individually (isStatic=false), or to the Classifier itself (isStatic=true)” may suggest that a static feature cannot relates to the instances of this classifier. This does not seem to be the intent. If so, improve the sentence. Otherwise explain how the semantics of a property which have the same value for all the instances of a classifier shall be modeled.”

  • Reported: UML 2.5 — Fri, 27 Jun 2014 11:17 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Incomplete sentence

  • Key: UMLR-338
  • Legacy Issue Number: 19427
  • Status: open  
  • Source: toshiba-tsip.com ( VIRESH MOHAN)
  • Summary:

    In the explanation for "Entering a State" concept w.r.t. alternate entry points for a composite state, it appears that the description for "Entry point entry" is not a complete sentence.

    Entry point entry:

  • Reported: UML 2.5b1 — Wed, 21 May 2014 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Rg. Reception.ownedParameter

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

    in conjunction with the Message signature issue, I was wondering whether Reception should redefine BehavioralFeature.ownedParameter. In contrast to Operation.ownedParameter (that already redefines BehavioralFeature.ownedParameter), Reception.ownedParameter would have to be derived an read-only, since the number and characteristics of the parameters are completely derived from the Properties of the Signal referenced by the Reception.

    As a matter of fact, with the invariant ‘same_structure_as_signal’ there is already an explicit derivation algorithm given. This one could be the basis for developing the body expression of the derived, read-only Reception.ownedParameter.

    In my opinion, everything that can be expressed by means of the metamodel, should be expressed in the metamodel and not with additional Constraints.

  • Reported: UML 2.5 — Thu, 16 Jan 2014 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Generalization should be limited to relate similar UML-elements

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

    The Generalization relationship can be used between instances of all subclasses of the metaclass Classifier. At least in the chapter on Generalization there is no constraint given. Thus it is allowed to have a generalization between an Activity and a signal. This definitely makes no sense. Does it make sense to have a generalization between an Activity and a Class? What does that mean for the instances?

    The only Metaclass that defines a constraint for Generalizations seems to be Stereotype (page 293).

    Tools seem to enforce, that only instances of Metaclasses, that are in a Generalization relationship on the meta level may have Generalization relationships on the model level. I'm not sure, whether this makes sense. Anyway, I couldn't find anything in the specification supporting this view.

    Suggestion:
    Add a constraint to Generalization, that limits the related elements to be of the same or compatible Metaclasses.

  • Reported: UML 2.5 — Mon, 10 Feb 2014 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Type conformance for classifiers

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

    Subclause 9.2.3 (Semantics), Generalization, sixth paragraph, last sentence ("A Classifier is a Type, and conforms to itself and to all of its generalizations.") contradicts the previous sentences. Classifiers conform to their metaclassifiers, not necessarily themselves or their generalizations. This sentence might have been intended to refer to the instances of a classifier.

  • Reported: UML 2.5 — Mon, 3 Feb 2014 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Notation for PrimitiveTypes

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

    Latest UML 2.5 spec has

    In 21 Primitive Types 21.3 Notation

    “There is no notation for PrimitiveTypes. There is notation for literal values of PrimitiveTypes; this notation is covered in Clause 8.2.”

    However, in Figure 21.1 Primitive Types, there appears to be notation for PrimtitveTypes. And explicitly in 10.2.5 Examples

    “Figure 10.2 illustrates the notation for defining a PrimitiveType”

    Similarly in 10.2.4, a notation for PrimitiveType is described.

    So which is it? Is there notation for PrimitiveType or not? This needs to be made clear.

    Perhaps what is meant is “There is no notation for defining literals of any new (modeler-defined) PrimitiveType.” And replace the 2nd sentence with “There is notation for literal values of the UML-supplied PrimitiveTypes; this notation is covered in Clause 8.2.”

  • Reported: UML 2.5 — Fri, 17 Jan 2014 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Problems with normative UML 2.5 Beta 2 Standard profile


Descriptions missing for PseudostateKind literals

  • Key: UMLR-304
  • Legacy Issue Number: 19193
  • Status: open  
  • Source: Eclipse Foundation ( Mr. Kenneth Hussey)
  • Summary:

    Descriptions are missing for PseudostateKind enumeration literals, as are comments for those elements in the normative machine consumable file for UML, available at http://www.omg.org/spec/UML/20131001/UML.xmi (see related issue 17978).

  • Reported: UML 2.5 — Wed, 22 Jan 2014 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Clause 21 Primitive Types is misnamed

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

    Clause 21 is titled Primitive Types. However the content describes only the predefined types of UML that are located in the PrimitiveTypes package. The section should be titled, Primitive Types Package (or similar.

  • Reported: UML 2.5 — Fri, 17 Jan 2014 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Problem with NamedElement::clientDependency subsets in UML 2.5 Beta 2

  • Key: UMLR-298
  • Legacy Issue Number: 19186
  • Status: open  
  • Source: Eclipse Foundation ( Mr. Kenneth Hussey)
  • Summary:

    NamedElement::clientDependency is derived (see issue 15056) but the following subsets are not:

    Artifact::manifestation
    BehavioredClassifier::interfaceRealization
    Classifier::substitution
    DeploymentTarget::deployment

    IMHO, this defeats the intent of the resolution since one still has to "modify the model" in order to set up these special kinds of dependency. Besides, I don't know what it means for a non-derived property to subset a derived property which is not a union...

  • Reported: UML 2.5 — Fri, 17 Jan 2014 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Can PrimitiveTypes be user-defined and where?

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

    In 10.2.3 it says that

    “A PrimitiveType defines a predefined DataType, without any substructure.”

    What does it mean to be “predefined” If a PrimitiveType is predefined, then how can it be defined by a modeler? I recommend that the word “predefined” be deleted from this sentence. In addition, the general impression is that the PrimitiveTypes are only located in the PrimitiveType package and cannot be anywhere else

    Though based on a statement in Profile a PrimitiveType could be in a profile, though it couldn’t be used in a model «grin».

  • Reported: UML 2.5 — Fri, 17 Jan 2014 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

A PrimitiveType can/cannot have owned attributes.

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

    A datatype can have ownedAttributes. A primitivetype is a subclass of Datatype, so it can have owned attributes. However a primitive type cannot have any substructure. Unfortunately “substructure” is not defined.

    This is repeated by the by the classifier definition for PrimitiveType[Class] however there is no OCL that enforces any restriction.

    Either eliminate the restriction or define substructure and write some OCL.

  • Reported: UML 2.5 — Fri, 17 Jan 2014 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

InstanceSpecification validity is not modelable

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

    InstanceSpecifications may be used to indicate intermediate states in a transaction and so may not necessarily be valid.

    InstanceSpecification may be used to create test models and so should necessarily be valid.

    It is not easy for tooling to detect which is the design intent.

    Suggest adding an InstanceSpecification::isValidatable property to enable tools to behave usefully.

  • Reported: UML 2.5 — Fri, 21 Feb 2014 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Missing OpaqueXXX body constraint

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

    Presumably a well-formed UML model should have well-formed content, so surely there should be an OpaqueAction/Behavior/Expression constraint that requires the body to be well-formed in its corresponding language?

  • Reported: UML 2.5 — Fri, 21 Feb 2014 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML Appendix A: After Figure A.4

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

    There is a list of possible namespaces that are suitable for appearing in the package header (containing • activity • class • component • deployment • interaction • package • state machine • use case)

    It seems to me that there are other possible namespaces that could be diagramed. For example

    Model, Node, Datatype, etc.

  • Reported: UML 2.5 — Tue, 2 Aug 2011 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML: unification of OCL declarations

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

    UML supports declarations of elements with multiplicity bounds; OCL does not
    OCL supports declarations of nested collections; UML does not

    A possible unification of the capabilities/syntaxes could be achieved by UML introducing Bag/OrderedSet/Sequence/Set as alternatives for

    {ordered,unique}

    etc and OCL adopting <> brackets and multiplicity qualification.

    Concrete Syntax
    -----------------------

    The syntax is not obvious

    All of Set<Type[0..5]> or Set<Type>[0..5] or Set<Type : 0..5> or Set[0..5]<Type> could be a bounded Set.

    All of Set<Set<Type[0..5]>[0..5]> or Set<Set<Type>[0..5]>[0..5] or Set<Set<Type : 0..5>: 0..5> or Set[0..5]<Set[0..5]<Type>> could be a 2D bounded Set.

    Set[0..5]<Set[0..5]<Type>> seems to best localize the multiplicity for the collection-type.

    Abstract Syntax
    ----------------------

    UML embeds its 'collection' declaration in a MultiplicityElement, which doesn't scale to nested collections. MultiplicityElement is a nuisance for OCL since it provides an alternate form of collection declaration to the CollectionType type constructor. A unified behaviour could deprecate MultiplicityElement and introduce a CollectionType type constructor with ordered, unique, lower, upper in addition to signature attributes.

    Nullable Unit Collection Semantics
    -----------------------------------------------

    So far so good, but there is an OCL semantic issue that is exposed by a compatibility conversion of MultiplicityElement.

    Currently MyType[0..1] is a nullable non-collection, so an OCL navigation of an unspecified value gives a null, which crashes any navigated collect iteration such as a->collect(b)->collect(c). A crash on a null object is confusing with respect to an empty collection for which iterations just skip the empty. Deprecating MultiplicityElement would convert MyType[0..1] to Set[0..1]<MyType>; clearly a collection not an object, which avoids the value-dependence that a MultiplicityElement that happens to have a unit upper bound is not a Collection. There is now no way to express a nullable object, so perhaps a

    { nullable }

    constraint can be supported. This restores the semantic coverage and conversion compatibility: [1] is ignored, [0..1] is treated as

    {nullable} and other multiplicities become correspondingly bounded collections. This also has the benefit that ordered and unique would cease to have any relevant semantics for non-collection objects thereby eliminating OCL's dilemma as to whether a [1] { ordered, unique } should be converted to a unit OrderedSet rather than a unit Set by the -> operator.


    However, we can now wonder what the difference is between MyType{nullable}

    and Bag[0..1]<MyType> and why modelers should prefer one or the other. A difference is that in OCL a->collect(b)->collect(c) will crash if b is a null MyType

    {nullable} whereas it will skip over a null for the empty collection. This seems really bad; a collect over a structurally valid model crashes. But is this OCL just throwing a problem over the fence to UML? Perhaps the problem is that OCL 2.3 has still not resolved the distinct semantics of null and invalid. Perhaps, since OclVoid conforms to all types, null has null/empty values of all properties with a 0 lower bound. Therefore null.oclAsType(NamedElement).name could be null rather than invalid, and so a->collect(b)->collect(c) should crash on invalid structures, but return a result including interspersed nulls for intermediate collects at null nullable elements.


    So the difference between MyType{nullable}

    and Bag[0..1]<MyType> is that:

    MyType

    {nullable}

    is what modelers will normally use. It is an object that may be null and always participates in an iteration as exactly one value, which may be null which may in turn participate in strucyurally valid iterations.

    Bag[0..1]<MyType> is a clumsy but consistent alternative. It is a unit collection that may be empty and only participates in an iteration when not empty.

  • Reported: UML 2.5 — Fri, 8 Jul 2011 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Clarification about serializing the application of SysML 1.3 to a UML2.4.1 model

  • Key: UMLR-260
  • Legacy Issue Number: 16567
  • Status: open  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    SysML 1.3 – http://www.omg.org/cgi-bin/doc?ptc/2011-08-10 – is defined as an extension of UML 2.4.1
    What is the XMI serialization of applying the profile to a UML 2.4.1 Package?

    The XMI serialization of the application of a profile in UML 2.4.1, section 18.3.7, was written at a time when UML2.0 required Stereotypes to be directly contained in a Profile. UML 2.3 relaxed this. According to the Stereotype semantics defined in UML 2.4.1 (18.3.9), a Stereotype may be contained in a Profile or a Package which defines the namespace for the Stereotype.

    The XMI serialization in 18.3.7 is defined by a contrived example where a Stereotype is directly contained in its Profile (see Figs. 18.8, 18.9). SysML 1.3 has several nested packages (see Fig 4.3 in SysML 1.3) Neither UML 2.4.1 nor XMI 2.4.1 clearly address how the serialization of the application of Package-nested Stereotypes works.

    For SysML 1.3, the XMI published for the SysML profile itself looks like this:

    <?xml version="1.0" encoding="UTF-8"?>
    <xmi:XMI xmlns:xmi="http://www.omg.org/spec/XMI/20110701"
    xmlns:mofext="http://www.omg.org/spec/MOF/20110701"
    xmlns:uml="http://www.omg.org/spec/UML/20110701">
    <uml:Profile URI="http://www.omg.org/spec/SysML/20110919/SysML" xmi:type="uml:Profile"
    xmi:id="OMG_SysML_20110919_SysML_0"
    name="SysML"
    visibility="public">
    ...
    <packagedElement xmi:type="uml:Package" xmi:id="_OMG_SysML_20110919_SysML_Blocks" name="Blocks">
    ...
    <packagedElement xmi:type="uml:Stereotype" xmi:id="_OMG_SysML_20110919_SysML_Blocks-Block"
    name="Block">
    ...
    </packagedElement>
    ...
    </packagedElement>
    </uml:Profile>
    <mofext:Tag xmi:type="mofext:Tag" xmi:id="OMG_SysML_20110919_SysML_2"
    name="org.omg.xmi.nsPrefix"
    value="SysML"
    element="OMG_SysML_20110919_SysML_0"/>
    </xmi:XMI>

    Given the fact that, per the MOF/XMI 2.4.1 specification, only the toplevel UML Package Namespace maps to an XMI Document Namespace,
    it follows that nested UML Package Namespaces have no corresponding XML Namespace declaration.

    This means that SysML's Blocks Package cannot have any XML Namespace declaration per current MOF/XMI 2.4.1 rules.
    Therefore, the only possible serialization for this example is the following:

    <xmi:XMI
    ....
    xmlns:SysML="http://www.omg.org/spec/SysML/20110919/SysML"
    ....
    >
    <uml:Package name="A" ........>
    ....
    <packagedElement xmi:type="uml:Class" xmi:id="123" name="B"
    ....
    </uml:Package>
    ....
    <SysML:_OMG_SysML_20110919_SysML_Blocks-Block base_Class="123" xmi:id="456" ... />
    ....
    </xmi:XMI>

    This particular serialization may be surprising to some who might have expected:

    <xmi:XMI
    ....
    xmlns:SysML="http://www.omg.org/spec/SysML/20110919/SysML"
    ....
    >
    <uml:Package name="A" ........>
    ....
    <packagedElement xmi:type="uml:Class" xmi:id="123" name="B"
    ....
    </uml:Package>
    ....
    <SysML:Block base_Class="123" xmi:id="456" ... />
    ....
    </xmi:XMI>

    The familiar-looking XMI serialization assumes that all UML CLassifiers in scope of a Profile have unique XMI:id values. The reason is very subtle but it is a consequence of the fact that the MOF/XMI specification maps only the toplevel UML Namespace into a corresponding XML Namespace declaration – i.e., a toplevel UML::Model/Package/Profile has a corresponding XML Namespace declaration & prefix; nested UML Namespaces do not!

    This means that the UML Namespace distinguishability criteria that suffices for ensuring UML NamedElements are distinguishable within the same UML Namespace
    is insufficient to guarantee that the XMI encoding of such UML NamedElements will be also distinguishable in the scope of their containing XML Namespace!

    For SysML 1.3, I specifically used an unconventional XMI:id generation algorithm that encodes the fully qualified path (name/metatype/linearized collection order) of each UML Element so as to ensure that each XMI:id Element in the scope of an XMI document is distinguishable within that document.

  • Reported: UML 2.5 — Tue, 27 Sep 2011 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

OccurrenceSpecification should have at least an optional notation

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

    Until UML 2.3, OccurrenceSpecification (OS) was an abstract superclass for the concrete occurrence specifications MessageOccurrenceSpecificatio (MOS) and ExecutionOccurrenceSpecification (EOS). In UML 2.3 OS became concrete. This apparently subtle change has a significant impact of the usage of domain-specific events in Interaction. A user can now place an OS along a lifeline directly, instead of using using the already existent ActionExecutionSpecification or BehaviorExecutionSpecification. This eases the definition of domain-specific occurrence specifications (let's call it events from henceforth) by defining stereotypes directly for an OS.

    For example, in the UML Testing Profile, there are some test-specific events (e.g. ValidationAction, a sterotype for CallOperationAction) which can be used inside Interaction. Until UML 2.3 the steps for including such a domain-specific actions in Interactions have been the following:

    1. Create an Action and let it being contained by the Interaction
    2. Configure that Action and apply the corresponding stereotype
    3. Create the ActionExecutionSpecification
    4. Create the EOS as the start EOS and link the ActionExecutionSpecification with the EOS
    5.Create the EOS as the finish EOS and link the ActionExecutionSpecification with the EOS
    6. Link the ActionExecutionSpecification with the Action

    The whole procedure involved a lot of very fine-grained and subtled concepts and requires an advanced knowledge of the Interactions metamodel (frankly, only few tools support this complex procedure).

    Since UML 2.4, the steps are reduced to the following one:
    1. Create an OccurrenceSpecification on a lifeline
    2. Apply a stereotype to the OS and configurethe OS

    The stereotyped OS assumes the semantics provided by the domain-specific OS (in UTP ValidationOccurrenceSpecification). This reduces the complexity of integrating such domain-specific events, reduces the memory foorprint and eases the handling and creation of interactions containing such stereotyped OS.

    The problem is that OS does not declare a national representation, and we doubt that this concept will be provided by tools if there is not standardized representation.

    Therefore, we suggest to define a (at least optional) notation for OS as a rectangle or rounded rectangle with a compartment for stereotype visualization and a compartment for an optional label (name of the OS or an expression within the stereotype).

    This change would not affect the XMI or metamodel, but has a significant impact of the way interaction are perceived and created.

  • Reported: UML 2.4 — Thu, 29 Sep 2011 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Message arguments for a Signal signature too restrictive

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

    Constraint 4 of Message in section 14.3.18 requires that in case of a Signal signature, the arguments of the message must correspond to the properties of the Signal.

    We found this constraint too restrictive. A Signal is a classifier, hence it is possible to create an InstanceSpecification for the Signal. A InstanceSpecification can be referenced by an InstanceValue (ValueSpecification) from within the message argument list.

    We suggest to weaken the first sentence of constraint 4 a little from :

    In the case when the Message signature is a Signal, the arguments of the Message must correspond to the attributes of the
    Signal.

    to

    In the case when the Message signature is a Signal, the arguments of the Message must correspond to the attributes of the
    Signal, or to the Signal itself.

  • Reported: UML 2.4 — Thu, 29 Sep 2011 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Relation of message arguments to signature parameters ambiguous

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

    In section 14.3.18, the constraints 3 and 4 say that the arguments of message must correspond to the parameters/properties of the signature (operation/signal). This leads to an ambiguous siuation in some situations. For example:

    Let's assume there is an operation with the following signatur op1(x:String[*], y:String[*]) or a Signal S with two properties
    S::p1 : String[0..1]
    S::p2 : String[0..1]

    Since there is no direct relationship between an argument and a parameter/property it is not possible to determine what argument belongs to the first parameter/property (list in case opf operation example) and what to the second one.

    This problem always occurrs when two parameters/properties of the same type are specified in a sequence and the first one has either an optional multiplicity or an upper bound equals *.

    A possible solution is to introduce an additional metaclass MessageArgumentSpecification, which should be contained by Message instead of ValueSpecification directly, with the following structure:

    MessageArgumentSpecification{
    refersTo: TypedElement [1]

    {where the referenced TypedElement is either an instance of parameter or property}

    arguments : ValueSpecification [1..*]

    {ordered}

    }

    It might be also considerable to keep the association between a referenced element and an argument bilateral. In this case, the association between Message and MessageArgumentSpecification should be ordered.

  • Reported: UML 2.4 — Thu, 29 Sep 2011 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

The included use case is always required for the including use case to execute correctly

  • Key: UMLR-265
  • Legacy Issue Number: 16658
  • Status: open  
  • Source: ivmx.pl ( Michal Kasprzyk)
  • Summary:

    In the 'Descriiption' section of chapter '16.3.5 Include (from UseCases)' there is a sentence:
    'Note that the included use case is not optional, and is always required for the including use case to execute correctly.'

    Interpretation of ‘include’ relationship, implying that it’s usage is valid only if included UC is obligatory for including UC to execute correctly,
    is probably the source of opinion, that the only way to model conditional parts of UC scenario using external UC, is by using ‘extend’ relationship.

    I find such conclusion in many books dealing with analysis/UML, for instance: ' Business Analysis’, page 188 (ISBN-10: 1906124612,ISBN-13: 978-1906124618).

    As a result the difference in aplicability between ‘include’ and ‘extend’ relationship is stressed almost only based on conditionallity of relationship between UC.

    In my opinion it’s valid to use ‘include’ relationship when pointing to another UC, that won’t be executed every time the base UC does.
    It’s just the internal logic of base UC scenario, that decides if it’s appropriate to call external UC or not.
    And if we depend only on result of an external UC, we should use ‘include’ relationship (so most of the time), while when there is a need to introduce its logic we should use ‘extend’ relationship.

    I think, that the sentencje:
    'Note that the included use case is not optional, and is always required for the including use case to execute correctly'
    should be removed or clarified, because if forces analysts to use mostly (if not only) an ‘extend’ relationship, that is far more complicated to use and time consuming to document than ‘include’.

  • Reported: UML 2.4.1 — Thu, 10 Nov 2011 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Concerning Transition and its owned elements

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

    is there a reason why a transition's effect and triggers of a state machine transition (section 15.3.14 in UML 2.4, respectively section 14.5, subsection Transition in UML 2.5 initial submission) do not belong to the transition's namespace as members? Both simply subset ownedElement. In contrast, a transition's guard subsets Namespace:ownedRule, which made me think the former ones ought to subset Namespace:onwedMember in lieu of Element:ownedElement as well.

    I roughly flicked through the open issues of UML, but did not find anything related to this question. So, if there was not decided deliberately, I would open an issue for that

  • Reported: UML 2.5 — Sat, 4 Feb 2012 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Abstraction::mapping should be of type ValueSpecification or OpaqueExpression

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

    In many cases, modeler would like to specify the mapping of an Abstraction on an informal level by just providing a LiteralString or OpaqueExpression describing the mapping in a natural language.

    The necessity to use an Expression is for this kind of usage of this feature cumbersome and clunky.

    The resolution could be to use a more common metaclass of Expression, i.e. ValueSpecification, to provide the highest level of flexibility to the modeler, how mappings can be specified.

  • Reported: UML 2.4 — Wed, 14 Dec 2011 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Message arguments should not be contained in a message

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

    Figure 14.4 - Messages in the spec depicts that arguments of a message are contained in that message. This containmentship is not necessary and in many cases counterproductive.

    The containment prevents ValueSpecifications for being reused in multiple messages. Instead, the very same ValueSpecification must be created in each message.

    Since ValueSpecification is a PackageableElement, there is no problem in making the association between Message and ValueSpecification a non-containment association.

  • Reported: UML 2.4 — Thu, 29 Sep 2011 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML 2.4/2.5 Aliases

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

    There is no capability in UML for giving an element an alternate name (an alias) within the package that defines it.

  • Reported: UML 2.5 — Tue, 17 Jan 2012 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Under-specified associations in UML2.4 & the need for clarifying the semantic directionality for all UML associations

  • Key: UMLR-236
  • Legacy Issue Number: 15449
  • Status: open  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    Resolution 14977 cleaned up many association end subsets/redefinitions; in particular, this resolution ensures that if an association end subsets/redefines another, then there is a symmetric subsetting/redefinition of the other end and that the subsetted/redefined ends belong to the same association.

    Two group of proposed changes were removed from 14977.

    The first group involves generalization relationships among associations: http://www.omg.org/issues/uml2-rtf.open.html#Issue15274
    Generalization relationships are needed when the semantics of an association whose ends subset/redefine the ends of another association is that the set of links of the former association are necessarily a subset of the links of the latter. Since this isn't necessarily the case, it implies that generalization relationships are needed to clarify this semantic intent as shown in slide 31 of the following UML2.0 presentation: http://www.omg.org/members/cgi-bin/doc?omg/04-05-01.pdf

    The second group involves associations that are under-specified in the sense that each association:

    • does not own any end (i.e., both ends are navigable according to 7.3.45)
    • none of the ends subset/redefine ends of another association that has semantic directionality

    The criteria for an association to have semantic directionality is:
    a) one end is navigable; the other isn't
    b) one end is composite; the other isn't
    c) one end subsets/redefines another end of an association that is semantically directed; the other doesn't
    d) one end has required multiplicity (i.e., lower>0); the other is optional (i.e., lower=0)
    e) one end has bounded multiplicity (i.e., upper>0); the other has unbounded multiplicity (i.e., upper<0)

    Without semantic directionality, an association owns neither of its member ends and there is no objective criteria to determine what effect changing one association end can/should/may have on changes to the other end, if any.

    In UML2.4, there are 9 associations that fail all of (a) through (e):
    [qvto:transformation] A_containedEdge_inGroup
    [qvto:transformation] A_containedNode_inGroup
    [qvto:transformation] A_covered_coveredBy
    [qvto:transformation] A_edge_inPartition
    [qvto:transformation] A_generalizationSet_generalization
    [qvto:transformation] A_inInterruptibleRegion_node
    [qvto:transformation] A_inPartition_node
    [qvto:transformation] A_predecessorClause_successorClause
    [qvto:transformation] A_subject_useCase

    19 associations satisfy (a), (b), (c) but fail either (d) and (e):

    [qvto:transformation] A_before_toAfter
    [qvto:transformation] A_classifier_templateParameter_parameteredElement
    [qvto:transformation] A_connectableElement_templateParameter_parameteredElement
    [qvto:transformation] A_end_role
    [qvto:transformation] A_extension_metaclass
    [qvto:transformation] A_incoming_target_node
    [qvto:transformation] A_incoming_target_vertex
    [qvto:transformation] A_inputElement_regionAsInput
    [qvto:transformation] A_interruptingEdge_interrupts
    [qvto:transformation] A_method_specification
    [qvto:transformation] A_operation_templateParameter_parameteredElement
    [qvto:transformation] A_outgoing_source_node
    [qvto:transformation] A_outgoing_source_vertex
    [qvto:transformation] A_outputElement_regionAsOutput
    [qvto:transformation] A_parameterSet_parameter
    [qvto:transformation] A_parameteredElement_templateParameter
    [qvto:transformation] A_powertypeExtent_powertype
    [qvto:transformation] A_submachineState_submachine
    [qvto:transformation] A_toBefore_after

    All 28 cases above correspond to associations that, while well-formed in the metamodel according to 14977 & other applicable resolutions, are under-specified in the specification in the sense that there is a reasonable interpretation where each association has a natural direction, either because of cardinality restrictions (i.e., (d) or (e) would suffice to give direction to the 19 associations above) or because there is insufficient application of the architecture principles for OMG metamodels (e.g., incomplete modeling of ownership in most of the cases for the first group of 9 association).

    The consequence for end users is that each of the 28 associations represents a source of modeling errors unless tool implementations choose to implement these associations in a non-standard way, e.g., by ascribing a sensible semantics to these associations that removes the ambiguity about which end can be changed independently of the other end – i.e., the association is semantically directed in that one end can be logically derived from the other end.

  • Reported: UML 2.5 — Wed, 8 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Issue on UML 2.4 - notation for Component::provided

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

    In section 8.3.1 and Table 8.4 there are several examples of nation claiming to show ‘provided interface’ for a Component.

    However Component::provided is a derived property – with many base properties on which it is based.

    Hence it seems completely un-obvious what a tool is supposed to store/export if a user draws one of these diagrams. Or is it intended that users not be allowed to draw them at all, but invoke a query (in some manner rightly not covered by the UML spec) to cause the ‘provided’ line (and possibly related elements) to be displayed?

    A further problem is that the ‘provided’ notation is identical to the ‘provided interface’ notation documented in section 7.3.24. And Table 8.1 makes reference to 7.3.24 for the notation although it uses the different term ‘implements’.

    Therefore it seems that the notation should be separated from the derived property, with the notation retained for simple realizedInterfaces – either by removing the term ‘provided’ from the description of the diagrams or renaming the property to be more descriptive

  • Reported: UML 2.5 — Mon, 30 Aug 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Nasty UML 2.x Issue - /qualifiedName is not unambiguous

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

    qualifiedName is not unambiguous

    Section 7.3.33 states:

    “A named element also has a qualified name that allows it to be unambiguously identified within a hierarchy of nested namespaces.” And the description of the property has: “A name that allows the NamedElement to be identified within a hierarchy of nested Namespaces.”

    Constraint [2] describes the derivation of /qualifiedName which makes use of the names of the containing namespaces.

    However the use of isDistinguishableFrom in the constraint for Namespace, which allows the names to be the same but the types different, means that the name alone may not unambiguously identify either the element or its namespaces.

    It seems that we have the following options:

    • Remove the notion of type from isDistinguishableFrom and insist on the names being different
    • Somehow include the type/metaclass in the qualified name (which I think we can do without needing a qualified name for the type itself – since UML has a flat namespace – but it could cause problems for profiles or other metamodels)
    • Drop the idea that the qualified name allows unambiguous identification. Which would be a shame. And might affect it being marked as {id}

      as per the recent issue resolution

    BTW the OCL for the derivation of /qualifiedName uses union() to construct it: however AFAIK this will not result in a String.

  • Reported: UML 2.5 — Fri, 27 Jun 2014 11:17 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Creation of an expansion node under an activity is allowed by UML and SysML specifications

  • Key: UMLR-242
  • Legacy Issue Number: 15849
  • Status: open  
  • Source: Safran Engineering Services/Airbus ( gautreault fabien)
  • Summary:

    Which semantic for an expansion node owned by an activity (instead an expansion region)?

    According OMG Unified Modeling LanguageTM (OMG UML), Superstructure, Chapter 12.3.26

    An expansion node is an object node used to indicate a flow across the boundary of an expansion region.

    An expansion region is a structured activity region that executes multiple times corresponding to elements of an input collection. This specific structured activity node is using expansion node as input and output. From outside the expansions regions the elements of expansion nodes only appear as a collections, the elements of collection are only accessible from "inside the collection".

    Semantic of an expansion node owned by an expansion region is then well defined. However, in abstract syntax nothing prevents to create an expansion node owned by an activity instead of an expansion region. In this case semantic is questionable.
    If this kind of construction is not expected, a specific constraint should be added in UML specification in order to prevent an activity to owned expansion nodes. On the contrary, if this construction allowed, associates semantic should be defined.

  • Reported: UML 2.3 — Mon, 29 Nov 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Part document structures in Superstructure need to conform to ISO standard Document Template Conventions

  • Key: UMLR-241
  • Legacy Issue Number: 15823
  • Status: open  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Title: Part document structures in Superstructure need to conform to
    ISO standard Document Template Conventions
    Category: Editorial

    Nature of Problem

    UML 2.3 RTF resolved ISSUE 14296 as follows:


    Summary:
    This is a multipart standard, use of "Part I, II, III" make confusion.
    Delete Part III and Make others rewrite as clauses. 7. General
    Introduction, 10 Infrastructure Library, and renumber other clauses.
    Also, delete Part III page.
    Resolution:
    Agree to change word “Part” to “Sub Part” throughout document.

    PTC/9-9-08 , the UML 2.3 Superstructure convenience document has the changes of the
    tem “Part” to “Subpart”, as per the resolution to ISSUE

    However the published UML 2.3 Infrastructure reverted to the use of the term “Part”.

    Also, ISO document templates do not allow hanging text.

    The introductory text for each is not in any numbered clause.

    Proposed Resolution:

    Change term “Part” to “Subpart”, as in PTC/9-9-8.

    Add a new section

    6.4.3 Contents of Subparts

    6.4.3.1 Contents of Subpart I ­ Structure

    <move the hanging intro from Part I into this subclause, with minor edits to fix pointers
    to sections>

    6.4.3.2 Contents of Subpart II ­ Behaviour

    <move the hanging intro from Part II into this subclause, with minor edits to fix pointers
    to sections>

    6.4.3.3 Contents of Subpart III- Supplement

    <move the hanging intro from Part III into this subclause,>

    6.4.3.4 Contents of Subpart IV - Annexes

    <move the hanging intro from Part IV into this subclause,>

  • Reported: UML 2.5 — Mon, 22 Nov 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

How to specify actual parameters to pass to parameterized submachine StateMachine

  • Key: UMLR-230
  • Legacy Issue Number: 15303
  • Status: open  
  • Source: PTC ( Mr. Simon Moore)
  • Summary:

    A State Machine can have parameters. How can values for these parameters be passed from a submachine State which references a State Machine with parameters?

  • Reported: UML 2.5 — Fri, 25 Jun 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Ports

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

    We have a debate about the concept of Port in the SysML RTF and I would like to get your opinion about some points because we have divergent interpretations of the UML specification.

    Since a port can be typed by a class, what about the properties and the owned behavior(s) defined for that class?

    Does the interaction point that instantiates the port has slots to hold runtime values of the properties defined by its type or does it only refer to values held by the instance of its owner (or by a instance of its environment)?

    How ownedbehaviors defined by the type of the port may impact the way interactions at that port are managed?

  • Reported: UML 2.5 — Tue, 15 Jun 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Initialization of complex fields

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

    Is there a standard UML way of initializing complex fields. Several examples below

    A: Integer (3,2) = (1,2,3,4,5,6)

    A: Integer (3,2) = ((1,2,3), (4,5,6))

    A: Integer (3,2) = ((1,2), (3,4), (5,6))

    And are they all the same?

    A: Integer (2,3) = (1,2,3,4,5,6)

    A: Integer (2,3) = ((1,2,3), (4,5,6))

    A: Integer (2,3) = ((1,2), (3,4), (5,6))

    And are these the same?

    And what’s the difference.

    And here another set

    Measurement (a Type)

    Value: Real

    Unit : String

    Experiment:Measurement(3) = (1.0, “ft”, 2.0,”ft”,3,”ft”)

    = ((1.0,”ft”), (2.0,”ft”), (3,”ft”))

    Experiment:Measurement(3,2)) = (1.0, “ft”, 2.0,”ft”,3,”ft”, 4,”ft”, 5,”ft”,6,”ft”)

    ((1.0,”ft”), (2.0,”ft”), (3,”ft”), (4,”ft”), (5,”ft”), (6,”ft”))

    (((1.0,”ft”), (2.0,”ft”), (3,”ft”)), ((4.0,”ft”), (5.0,”ft”), (6,”ft”)))

    My preferences are for the last one above (the one with the extra set of parenthesis), because is better support composition

    e.g.

    NullResults:Measurement = (0.0,”ft”)

    StartingResults:Measurement(3) = (NullResults, NullResults, NullResults)

    Experiment:Measurement(3,2) = (StartingResults, ((4.0,”ft”),(5.0,”ft”),(6.0,”ft”)))

    The UML spec is silent about the correct way of doing this. I’d like to have a language independent way of doing this.

  • Reported: UML 2.5 — Tue, 6 Apr 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML 2 issue: connectors typed by Association Class

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

    Multiple tool vendors have failed to implement support for a Connector that has a type of an AssociationClass. This may be partly due to the fact that Connector (9.3.6) doesn’t explicitly describe this variation under type. Nor does any example show this use. I would expect that the properties/methods of Connector that has a type of an AssociationClass to be represented similarly to representation of an AssociationClass between Classes.

  • Reported: UML 2.5 — Fri, 10 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Clarifying the support for and semantics of subsetting/redefinition for a pair of properties defined in different contex

  • Key: UMLR-237
  • Legacy Issue Number: 15451
  • Status: open  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    Currently, the prevalent use of property subsetting/redefinition mechanism has been confined to a pairs of properties defined within a single artifact (e.g., metamodel, user model, ....) In principle, the specification allows using this mechanism even for a pair of properties where the subsetted/redefined property is defined in one artifact (e.g., a metamodel) and the subsetting/redefining property is defined in another artifact (e.g., a profile extending the metamodel). This flexibility could be useful in practice – e.g., see some of the proposed changes for SysML1.3 here: http://www.omg.org/members/sysml-rtf-wiki/doku.php?id=rtf3:groups:9_ports_and_flows.

    The specification does not explicitly discuss what is the semantics of subsetting/redefinition when the subsetted/redefined property is in a different artifact, potentially at a different level than the artifact where the subsetting/redefining property is defined.

    Combinations of subsetted/redefined property vs. subsetting/redefining property could include:

    • metamodel/profile
    • profile/profile
    • library/profile
  • Reported: UML 2.5 — Wed, 8 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML 2.3 Infra 12 Incomplete conformance for infinity

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

    Issue 15780 for OCL suggests resolving the inconsistent definition of
    UnlimitedNatural
    by defining '' infinity (and '-' minus infinity) as valid Integer and Real
    values.

    This is appropriate to resolve the anomally that

    Integer conformsTo Real so any Integer is a valid Real,
    UnlimitedNatural conformsTo Integer so any UnlimitedNatural is a valid
    Integer

    except that at present '*' is a valid UnlimitedNatural without a valid
    Integer
    or Real counterpart.

    The resolution of Issue 14196, introducing UnlimitedNatural to the OCL
    specification, indicates that any use of UnlimitedNatural '*' as an Integer
    or Real requires a conversion to invalid. This imposes an undesirable
    implementation burden in addition to the anomalous conformance behaviour.

    Therefore please add '' (and '-') to Integer and Real.

  • Reported: UML 2.5 — Wed, 27 Oct 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

No Constraint for multiple associations

  • Key: UMLR-239
  • Legacy Issue Number: 15763
  • Status: open  
  • Source: Oracle ( Antonio Petri)
  • Summary:

    There isn't a constraint that prevents multiple associations from being specified between the same Actor and Use Case. Multiplicity is handled already by the multiplicity at the association's ends, so having two or more different associations seems to be redundant.

  • Reported: UML 2.3b1 — Tue, 19 Oct 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Aggregation missing from Property string syntax

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

    The syntax for property strings (defined using BNF in Notation section of 7.3.44) does not include the ability to specify aggregation of shared or composite.

  • Reported: UML 2.5 — Tue, 29 Jun 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Issue on UML 2.3 - Use of isAbstract for Interfaces

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

    Use of isAbstract for Interfaces

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

    Section 7.3.24 of Superstructure states: “Because an interface is merely a declaration it is not an instantiable model element; that is, there are no instances of

    interfaces at run time.”

    And also: “An interface cannot be directly instantiated. Instantiable classifiers, such as classes, must implement an interface”

    .

    This would imply that isAbstract (inherited from Classifier) must be true. However there is no constraint to this effect on Interface. Furthermore none of the notation examples show the Interface name in italics.

    This is an issue for the Model Interchange Working Group

  • Reported: UML 2.5 — Mon, 28 Jun 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Retationships and composite structures

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

    UML Relationships, Comments and Constraints are unable to deal properly with composite structures that have more than one nested level. For instance: assume a class “A” with two properties “b1” and “b2” both typed by a class B with only one property “p”. A relationship, a comment or a constraint cannot target specifically A.b1.p and not A.b2.p.

  • Reported: UML 2.5 — Fri, 10 Dec 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

How is an attribute that is not a part, a role?

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

    11.2.3. says

    Property is a kind of ConnectableElement. All of the ownedAttributes of a StructuredClassifier are roles and can be connected using Connectors.

    Those ownedAttributes of a StructuredClassifier that have isComposite = true (see 9.5.3) are called its parts. Hence parts constitute a subset of roles

    So how are non composite properties (attributes) roles?

    A justification, example, and/or an excuse is needed.

  • Reported: UML 2.5 — Fri, 21 Nov 2014 06:47 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Lack of clarify of attribute vs attribute value.

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

    In the discussion of Figure 9.25a, the following appears:

    In diagram (a), each instance of Checking Account could have its own attributes (including those inherited from Account), such as account number and balance. Additionally, the equivalent instance for Checking Account may have attributes, such as interest rate and maximum delay for withdrawal.

    The text is unclear, but I assume that instances have their own attribute values, not attributes.

    The paragraphs below may have similar problems

  • Reported: UML 2.5 — Fri, 21 Nov 2014 04:59 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Generalizations should allow enumeration types as PowerTypes.

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

    A powerful and common modeling situation is the need to have a subclass for every value of an enumeration type. This is similar to the need for using PowerTypes, but without the capability of dynamically creating new specific instances (subclasses).

    Some uses:
    For example, on a project there may be 100 commandKinds. I'd make an enumeration type of the commands, and want a simple way of declaring that for possible enumeration type there is subclass of command.

    This use is similar to what was once possible with discriminators in UML 1.x

    This can be tied to the use of qualifiers to make some powerful idioms. A Team can have an association to TeamPlayer, that is qualified by PositionKind. The team can be said to have at least one TeamPlay for each PositionKind. And if the same PositionKind is used as the PowerType for a specialization of TeamPlayer, we have a subclass of TeamPlayer per PositionKind.

    An enumeration type powerType can be also be powerfully used in some model transformations. A class containing an enumeration attribute can be converted to a class w/o the attribute but with a set of specialized subclasses, each with value of the enumeration type. Of vice versa. This sort of transformation is common when moving from analysis to design.

  • Reported: UML 2.5 — Fri, 21 Nov 2014 04:51 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Caption for Table 9.1 on wrong page

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

    Make sure that Table captions are on the same page as their table.

    This is similar to the problem with the Table caption 1.5
    Issue UMLR-375

  • Reported: UML 2.5 — Fri, 21 Nov 2014 07:09 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Making the default for Generalization isDisjoint=False is contrary to modelers' expectations.

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

    Almost all UML modelers assume that default semantics for Generalization is isDisjoint=True. The justification for making the isDisjoint=False (overlapping) the default escapes me.

    Most real-world semantics are disjoint, and I believe most programming languages are also disjoint.

    Please change the default for isDisjoint=True

  • Reported: UML 2.5 — Fri, 21 Nov 2014 06:55 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Continuation examples are missing InteractionConstraints for the Alternative CombinedFragment

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

    In Figure 17.15 an example of a sequence diagram continuation is given. To make sense of this example, the interaction constraints for the alt operands should be shown. Without the constraints being shown, the two operands are both considered true.
    In Figure 17.16, the continuation is "rolled out", but the interaction constraints are still missing.

    To fix, in Figure 17.15, add the interaction constraints of "True" on the first of the alt operands (in both left and right diagrams), and add the the constraint of Else (or False) on the lower operands.

    In Figure 17.16 apply the interaction constraints in the same manner.

  • Reported: UML 2.5 — Tue, 18 Nov 2014 09:02 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Extraneous " (double quote) in 17.6.3 Semantics

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

    17.6.3 has the following sentence:

    The seq operator is described in “17.6.3 (Combined Fragment).

    Please remove the unneeded ".

    This is similar to UMLR-371

  • Reported: UML 2.5 — Tue, 18 Nov 2014 07:34 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

As no UML operators are defined, it is not possible to write a UML Expression

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

    An Expression requires the evaluation of one or more operator symbols. A tool, according to 8.3.3, can treat all Expressions as uninterpreted. There are no UML specified operators.

    However, the definition of an Opaque Expression is given as,
    An OpaqueExpression specifies the computation of a set of values either in terms of a UML Behavior or based on a textual statement in a language other than UML.

    As UML does not have a language of specified operators, all Expressions in a UML tool are OpaqueExpressions.

    Even if a tool gave a list of operators it would interpret, these operators would not be part of UML, and the expression would be an opaque expression given in a tool-specified language.

  • Reported: UML 2.5 — Thu, 13 Nov 2014 22:14 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

As Events are Packageable Elements, how is their Package known?

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

    Though an Event is a Packageable element (Figure 13.2 Events), it is unclear which Package owns it.
    One possibility would be the Trigger that refers to it. However, more than one Trigger can refer to the same Event, and these Triggers may be in different Packages (e.g., BroadCast Events)
    Another possibility would be the Package of the element that issues the Event. However, some Events have no clear originator. A SignalEvent may be issued from multiple places. More complexly, a change event may have multiple originators at the same time, from different Packages, such as on[Package1:A >Package2:B].

    The purpose of being Packageable is usually to imports and the ability to have unqualified names. As events seem not to have names (other than usage within a trigger), it does not appear that they could be the target of an import.
    If events don't and can't have names, they seem to be incorrectly identified as PackageablElements.

    So solutions.
    1) Stop them from being PackageableElements.
    2) Give them names and make them classifiers.
    ....

  • Reported: UML 2.5 — Fri, 17 Oct 2014 05:54 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Use Cases both can and cannot have BehavioralFeatures

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

    on page 673 it says:
    "Attributes and operations may be shown in compartments within the UseCase oval, with the same content as though they were in a normal Classifier rectangle."

    However, on page 302, it says
    "There are two kinds of BehavioralFeatures: Operations (see sub clause 9.6) and Receptions (see sub clause 10.3). Of the different kinds of BehavioredClassifiers in UML, only Classes may have BehavioralFeatures and only active Classes may have Receptions (see sub clause 11.4). Calling an Operation on or sending a Signal instance to an object of a Class is a request for the object to carry out an identified BehavioralFeature."

    So can Use Cases have operations or not?

    I believe that Use Cases should (in the sense of following modeling trends) allow for operations.

    I also don't see any reason why most Use Cases woudn't be active, and therefor allow for Receptions.

  • Reported: UML 2.5 — Wed, 22 Oct 2014 04:27 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Semantics of Executable Nodes does not cover Control Flows on Control Pins

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

    15.5.3 Semantics
    The Executable Nodes discussion requires all ControlFlows to be implicitly joined (effectively made mandatory). It should be possible to have optional ControlFlows if they arrive on pins (e.g., as part of a ParameterSet). It may also be possible to have optional ControlFlows if the implicit join could have a joinSpec by the use of constraint.
    Similarly, it should be possible to use a ParameterSet to have some controlPins w/o output control tokens.

  • Reported: UML 2.5 — Fri, 17 Oct 2014 05:23 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

A type defines a set member (not a set)

  • Key: UMLR-362
  • Legacy Issue Number: 19640
  • Status: open  
  • Source: Anonymous
  • Summary:

    CURRENT
    1) “A Type specifies a set of allowed values known as the instances of the Type.
    2) “Depending on the kind of Type, instances of the Type may be created or destroyed over time.
    3) “However, the rules for what constitutes an instance of the Type remain fixed by the definition of that Type.”

    COMMENTS
    1) “A Type specifies a set of allowed values known as the instances of the Type.
    Surely a type does not specify a set?
    Rather it specifies what it takes to one (any) member in the afore-mentioned set?
    It defines each individual in a collection of instances.
    Surely the sentence should be changed, perhaps along these lines?
    “A Type specifies each value in the set of values known as instances of the Type.”
    “A Type specifies the rules for what constitutes an instance of the Type.”
    "A Type specifies features shared by things that are instances of the Type.”
    "A Type specifies each member of a set by defining one or more characteristics shared by all the members of the set.”
    "The set members are instances of the Type."

    2) “Depending on the kind of Type, instances of the Type may be created or destroyed over time.
    So there are two kinds of Type? What are they are called?

    3) “However, the rules for what constitutes an instance of the Type remain fixed by the definition of that Type.”
    Surely “the definition of the type” is tautologous?
    The Type is the definition ­ the definition of the rules for what constitutes an instance.
    Surely should be changed thus?
    “The rules for what constitutes an instance of the Type remain fixed by the Type.

  • Reported: UML 2.5 — Tue, 14 Oct 2014 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

2 Conformance: Missing Oxford comma in Item #2.

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

    First sentence says "....to be created, read, updated, and deleted."
    However second sentence says "..to create, read, update and delete"

    This is an minor, but annoying inconsistency. Generally, the UML spec does (correctly) use the serial/Oxford comma. this one was missing.

  • Reported: UML 2.5 — Wed, 20 Aug 2014 04:20 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML 2.5 Mandatory but suppressible compartments

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

    In 11.4.4 (Classes) Notation

    “A Class has four mandatory compartments: attributes, operations, receptions (see 9.2.4) and internal structure (see 11.2.4).”

    However, a bit later in 11.4.5 Examples

    “Figure 11.16 shows three ways of displaying the Class Window, according to the options set out for Classifier notation in 9.2.4. The top left symbol shows all compartments suppressed.”

    It’s a bit confusing to have mandatory but suppressible compartments.

    And in 9.2.4 (Classifier) Notation

    Some compartments in Classifier shapes are mandatory and shall be supported by tools that exhibit concrete syntax conformance. Others are optional, in the sense that a conforming tool may not support such compartments.

    Any compartment may be suppressed. A separator line is not drawn for a suppressed compartment. If a compartment is suppressed, no inference may be drawn about the presence or absence of elements in it.

    Many readers have been confused by this use of mandatory. Apparently “mandatory” means mandatory for the tool vendor to support, but not mandatory to display.

    In 11.2.4 Notation, it is clarified. E.g.,

    This compartment is mandatory: all tools that conform to the concrete syntax of UML must implement it.

    I’m requesting a similar clarification in 11.4.4

  • Reported: UML 2.5 — Fri, 18 Apr 2014 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML 2.6 Issue --- SignalEvent Triggers

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

    On p 345 under the details of Transition it says:

    SignalEvent triggers and CallEvent triggers are not distinguishable by syntax and must be discriminated by their declaration elsewhere.

    However, on the next page under Signal receipt signal it says:

    The Signal receipt symbol is shown as a five-pointed polygon that looks like a rectangle with a triangular notch in one of its sides (either one). It maps to the trigger of the Transition and does not map to an Action of the Activity that specifies the effect Behavior. The names of the Signals of the Trigger as well as any guard are contained within the symbol as follows:

    <trigger> [‘,’ <trigger>]* [‘[‘ <guard> ‘]’]

    Where <trigger> is specified as described in sub clause 13.3.4 with the restriction that only Signal and change Event types are allowed. The trigger symbol is always first in the path of symbols and a compound transition can only have at most one such symbol.

    This means, that when the Signal Receipt symbol is used, and the trigger syntax is <name>[‘(‘[<assignment-specification>]’])’] is unambiguously a SignalEvent trigger and not a CallEvent trigger

  • Reported: UML 2.5 — Fri, 25 Apr 2014 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Incorrectly drawn ParameterableElement.owningTemplateParameterSubstitution multiplicity

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

    Fig 7.4 is drawn with ParameterableElement.owningTemplateParameterSubstitution as * rather than the 0..1 that appears in the text and model.

  • Reported: UML 2.5 — Sat, 19 Apr 2014 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Incorrect drawing of non-navigable redefined opposites

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

    Fig 9.10 shows three navigable Property.property

    Fig 9.13 shows Operation.operation as navigable

    The textual descriptions and the XMI consistently have redefined/subsetted opposites as unnavigable, so the diagrams are at fault.

    [From an OCL perspective three different Property.property makes OCL navigation troublesome.]

  • Reported: UML 2.5 — Sat, 19 Apr 2014 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Incorrect OrderedSet returns

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

    The OCL for

    StructuredClassifier::part() and Operation::results()

    retuirns a projection of an OrderedSet and so itself returns an OrderedSet. However the operations are declared to return Sets.

    Suggest adding ->asSet() to discard the ordering prior to return.

  • Reported: UML 2.5 — Tue, 22 Apr 2014 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Figures 15.45 and 15.46 in the spec are bad examples as they are of malformed activity diagrams

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

    Figures 15.45 and 15.46 in the spec are bad examples as they are of malformed activity diagrams, which can never execute. The first behavior is a successor of the first behavior, and, as such, can never execute.

    The figures can be fixed by preceding the first behavior with a start node which has as its successor a merge node, which has as its successor the first behavior. Then the loop back from the downstream decision node must be connected to the merge node.

  • Reported: UML 2.5 — Fri, 9 May 2014 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

meaning is not clear

  • Key: UMLR-336
  • Legacy Issue Number: 19420
  • Status: open  
  • Source: toshiba-tsip.com ( VIRESH MOHAN)
  • Summary:

    In the part where the adornments on Association symbol are explained, the third bullet point seems to be confusing.

    A property string may be placed near the Association symbol, but far enough from any end to not be confused with a property string on an end.

    Though I am not in a position to say whether it's incorrect or not but I think it's bit convoluted as in "property string is placed so that it's not confused with a property string"?

  • Reported: UML 2.5b1 — Tue, 20 May 2014 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Incorrect Result in ReduceAction Example

  • Key: UMLR-334
  • Legacy Issue Number: 19406
  • Status: open  
  • Source: gmail.com ( Pete Karousos)
  • Summary:

    Unless my understanding of the ReduceAction is way off, the example says that with an input collection of four integers (2,7,5,3) the result of applying the ReduceAction to this collection with an addition function is 11. I believe the result should be 17 since 2+7+5+3 = 17 regardless of order.

  • Reported: UML 2.5 — Sun, 4 May 2014 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Specification should not contain any methodology

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

    The statement "Such instances are often described by Interactions." is about methodology and not the language. For example I have a different opinion about that and would write "Such instances are often described by Activities."

    I propose to discard the sentence or to change it to

    "Such instances are described by concrete Behaviors."

  • Reported: UML 2.5 — Wed, 23 Apr 2014 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Improving the association direction notation

  • Key: UMLR-290
  • Legacy Issue Number: 19017
  • Status: open  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    The UML 2.5 notation for associations in section 11.5.4 states (4th paragraph):

    On a binary Association drawn as a solid line, a solid triangular arrowhead next to or in place of the name of the Association and pointing along the line in the direction of one end indicates that end to be the last in the order of the ends of the Association. The arrow indicates that the Association is to be read as associating the end away from the direction of the arrow with the end to which the arrow is pointing (see Figure 11.27). This notation is for documentation purposes only and has no general semantic interpretation. It is used to capture some application-specific detail of the relationship between the associated Classifiers.

    In practice, the order of association ends is not very useful. Deriving the direction of an association based on association end cardinality, aggregation type and navigability, which is a function of ownership (see Property::isNavigable()) would be more useful.

    I propose the following criteria (written in QVT Operational):

    modeltype uml uses 'http://www.nomagic.com/magicdraw/UML/2.4.1';

    /**

    • @author nicolas.f.rouquette@jpl.nasa.gov
    • October 2013 - UML2.6 Improving the association direction notation.
      */
      transformation AssociationDirectionCheck(in selectedAssociations:uml);
      property associations : Set(uml::Association) = selectedAssociations.rootObjects()[uml::Association];

    main() {
    log('Analyzing ' + associations->size().repr() + ' associations');
    associations->sortedBy(qualifiedName)->forEach(a)

    { var p := a.memberEnd![name='p']; var q := a.memberEnd![name='q']; log('Association ' + a.name + ' : ' + p.type.name + ' -- ' + q.type.name); p.describe('end1'); q.describe('end2'); }

    }

    helper uml::Property::describe(in prefix:String) {
    var a := self.association;
    assert fatal (a.oclIsKindOf(uml::Association));
    var other := a.memberEnd->excluding(self)->any(true);
    var dir := 'n/a';
    if (self.isMemberEndLogicallyDirectedToOtherEnd()) then dir := self.name + '>>' + other.name endif;
    if (other.isMemberEndLogicallyDirectedToOtherEnd()) then dir := other.name + '>>' + self.name endif;
    log(prefix + ': ' + self.namespace.name + '::' + self.name + ' : ' + self.type.name
    + '[' + self.lower.repr() + '..' + (if self.upper < 0 then '*' else self.upper.repr() endif) + ']'
    + '

    {memberEnd#' + a.memberEnd->indexOf(self).repr() + ', aggregation=' + self.aggregation.repr() + ', isNavigable=' + self.isNavigable().toString() + ', direction=' + dir + '}

    ');
    }

    helper uml::Property::isMemberEndLogicallyDirectedToOtherEnd() : Boolean

    { var a := self.association; assert fatal (a.oclIsKindOf(uml::Association)); var other := a.memberEnd->excluding(self)->any(true); var fwdDirByClassOrNav := ((self.owner = a) and (other.owner <> a)) or (not self.isNavigable()) and other.isNavigable(); var fwdDirByComposition := (not self.isComposite) and other.isComposite; var fwdDirByCardinality := (not self.isComposite) and (not other.isComposite) and (self.upper <= 1) and (other.upper < 0 or other.upper > 1); return fwdDirByClassOrNav or ((not fwdDirByClassOrNav) and (fwdDirByComposition or fwdDirByCardinality)); }

    query Boolean::toString() : String

    { if (self) then return 'Y' endif; return 'F'; }

    For a representative set of test cases varying all combinations of association end aggregation type, cardinality, ownership, navigability, member end order,
    the above criteria suffices to determine whether an association with ends p and q is in the forward direction (p>>q) or reverse (q>>p):

    [10/13/13 2:03 PM] Analyzing 22 associations
    [10/13/13 2:03 PM] Association AB'0 : A'0 – B'0
    [10/13/13 2:03 PM] end1: AB'0: : A'0[1..1]

    {memberEnd#1, aggregation=none, isNavigable=F, direction=p>>q}
    [10/13/13 2:03 PM] end2: A'0::q : B'0[1..1] {memberEnd#2, aggregation=none, isNavigable=Y, direction=p>>q}
    [10/13/13 2:03 PM] Association AB'1 : A'1 – B'1
    [10/13/13 2:03 PM] end1: AB'1: : A'1[1..1] {memberEnd#1, aggregation=none, isNavigable=F, direction=p>>q}

    [10/13/13 2:03 PM] end2: AB'1::q : B'1[1..1]

    {memberEnd#2, aggregation=none, isNavigable=Y, direction=p>>q}
    [10/13/13 2:03 PM] Association AB0 : A0 – B0
    [10/13/13 2:03 PM] end1: AB0: : A0[1..1] {memberEnd#2, aggregation=none, isNavigable=F, direction=p>>q}
    [10/13/13 2:03 PM] end2: A0::q : B0[1..1] {memberEnd#1, aggregation=none, isNavigable=Y, direction=p>>q}
    [10/13/13 2:03 PM] Association AB1 : A1 – B1
    [10/13/13 2:03 PM] end1: AB1: : A1[1..1] {memberEnd#2, aggregation=none, isNavigable=F, direction=p>>q}
    [10/13/13 2:03 PM] end2: AB1::q : B1[1..1] {memberEnd#1, aggregation=none, isNavigable=Y, direction=p>>q}
    [10/13/13 2:03 PM] Association CD'0 : C'0 – D'0
    [10/13/13 2:03 PM] end1: CD'0: : C'0[0..1] {memberEnd#1, aggregation=none, isNavigable=F, direction=p>>q}
    [10/13/13 2:03 PM] end2: C'0::q : D'0[1..1] {memberEnd#2, aggregation=composite, isNavigable=Y, direction=p>>q}
    [10/13/13 2:03 PM] Association CD'1 : C'1 – D'1
    [10/13/13 2:03 PM] end1: CD'1: : C'1[0..1] {memberEnd#1, aggregation=none, isNavigable=F, direction=p>>q}
    [10/13/13 2:03 PM] end2: CD'1::q : D'1[1..1] {memberEnd#2, aggregation=composite, isNavigable=Y, direction=p>>q}
    [10/13/13 2:03 PM] Association CD0 : C0 – D0
    [10/13/13 2:03 PM] end1: CD0: : C0[0..1] {memberEnd#2, aggregation=none, isNavigable=F, direction=p>>q}
    [10/13/13 2:03 PM] end2: C0::q : D0[1..1] {memberEnd#1, aggregation=composite, isNavigable=Y, direction=p>>q}
    [10/13/13 2:03 PM] Association CD1 : C1 – D1
    [10/13/13 2:03 PM] end1: CD1: : C1[0..1] {memberEnd#2, aggregation=none, isNavigable=F, direction=p>>q}
    [10/13/13 2:03 PM] end2: CD1::q : D1[1..1] {memberEnd#1, aggregation=composite, isNavigable=Y, direction=p>>q}
    [10/13/13 2:03 PM] Association EF'0 : E'0 – F'0
    [10/13/13 2:03 PM] end1: EF'0: : E'0[1..1] {memberEnd#1, aggregation=composite, isNavigable=F, direction=q>>p}
    [10/13/13 2:03 PM] end2: E'0::q : F'0[0..1] {memberEnd#2, aggregation=none, isNavigable=Y, direction=p>>q}

    [10/13/13 2:03 PM] Association EF'1 : E'1 – F'1
    [10/13/13 2:03 PM] end1: EF'1: : E'1[1..1]

    {memberEnd#1, aggregation=composite, isNavigable=F, direction=q>>p}

    [10/13/13 2:03 PM] end2: EF'1::q : F'1[0..1]

    {memberEnd#2, aggregation=none, isNavigable=Y, direction=p>>q}
    [10/13/13 2:03 PM] Association EF0 : E0 – F0
    [10/13/13 2:03 PM] end1: EF0: : E0[1..1] {memberEnd#2, aggregation=composite, isNavigable=F, direction=q>>p}
    [10/13/13 2:03 PM] end2: E0::q : F0[0..1] {memberEnd#1, aggregation=none, isNavigable=Y, direction=p>>q}
    [10/13/13 2:03 PM] Association EF1 : E1 – F1
    [10/13/13 2:03 PM] end1: EF1: : E1[1..1] {memberEnd#2, aggregation=composite, isNavigable=F, direction=q>>p}
    [10/13/13 2:03 PM] end2: EF1::q : F1[0..1] {memberEnd#1, aggregation=none, isNavigable=Y, direction=p>>q}
    [10/13/13 2:03 PM] Association GH'0 : G'0 – H'0
    [10/13/13 2:03 PM] end1: GH'0: : G'0[1..1] {memberEnd#1, aggregation=none, isNavigable=Y, direction=p>>q}
    [10/13/13 2:03 PM] end2: G'0::q : H'0[1..1] {memberEnd#2, aggregation=none, isNavigable=Y, direction=p>>q}

    [10/13/13 2:03 PM] Association GH'1 : G'1 – H'1
    [10/13/13 2:03 PM] end1: GH'1: : G'1[0..1]

    {memberEnd#1, aggregation=none, isNavigable=Y, direction=p>>q}
    [10/13/13 2:03 PM] end2: GH'1::q : H'1[0..*] {memberEnd#2, aggregation=none, isNavigable=Y, direction=p>>q}
    [10/13/13 2:03 PM] Association GH'2 : G'2 – H'2
    [10/13/13 2:03 PM] end1: H'2: : G'2[0..1] {memberEnd#1, aggregation=none, isNavigable=Y, direction=p>>q}

    [10/13/13 2:03 PM] end2: G'2::q : H'2[0..*]

    {memberEnd#2, aggregation=none, isNavigable=Y, direction=p>>q}
    [10/13/13 2:03 PM] Association GH0 : G0 – H0
    [10/13/13 2:03 PM] end1: GH0: : G0[1..1] {memberEnd#2, aggregation=none, isNavigable=Y, direction=p>>q}

    [10/13/13 2:03 PM] end2: G0::q : H0[1..1]

    {memberEnd#1, aggregation=none, isNavigable=Y, direction=p>>q}
    [10/13/13 2:03 PM] Association GH1 : G1 – H1
    [10/13/13 2:03 PM] end1: GH1: : G1[0..1] {memberEnd#2, aggregation=none, isNavigable=Y, direction=p>>q}
    [10/13/13 2:03 PM] end2: GH1::q : H1[0..*] {memberEnd#1, aggregation=none, isNavigable=Y, direction=p>>q}

    [10/13/13 2:03 PM] Association GH2 : G2 – H2
    [10/13/13 2:03 PM] end1: H2: : G2[0..1]

    {memberEnd#2, aggregation=none, isNavigable=Y, direction=p>>q}
    [10/13/13 2:03 PM] end2: G2::q : H2[0..*] {memberEnd#1, aggregation=none, isNavigable=Y, direction=p>>q}
    [10/13/13 2:03 PM] Association IJ'0 : I'0 – J'0
    [10/13/13 2:03 PM] end1: J'0: : I'0[0..1] {memberEnd#1, aggregation=none, isNavigable=Y, direction=p>>q}
    [10/13/13 2:03 PM] end2: I'0::q : J'0[1..1] {memberEnd#2, aggregation=composite, isNavigable=Y, direction=p>>q}
    [10/13/13 2:03 PM] Association IJ'1 : I'1 – J'1
    [10/13/13 2:03 PM] end1: J'1: : I'1[0..1] {memberEnd#1, aggregation=none, isNavigable=Y, direction=p>>q}
    [10/13/13 2:03 PM] end2: I'1::q : J'1[0..*] {memberEnd#2, aggregation=none, isNavigable=Y, direction=p>>q}

    [10/13/13 2:03 PM] Association IJ0 : I0 – J0
    [10/13/13 2:03 PM] end1: J0: : I0[0..1]

    {memberEnd#2, aggregation=none, isNavigable=Y, direction=p>>q}
    [10/13/13 2:03 PM] end2: I0::q : J0[1..1] {memberEnd#1, aggregation=composite, isNavigable=Y, direction=p>>q}
    [10/13/13 2:03 PM] Association IJ1 : I1 – J1
    [10/13/13 2:03 PM] end1: J1: : I1[0..1] {memberEnd#2, aggregation=none, isNavigable=Y, direction=p>>q}

    [10/13/13 2:03 PM] end2: I1::q : J1[0..*]

    {memberEnd#1, aggregation=none, isNavigable=Y, direction=p>>q}

    To facilitate reviewing this criteria, these associations are shown in the attached class diagram.

  • Reported: UML 2.5 — Sun, 13 Oct 2013 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Sequence Diagram: Message limitation

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

    In several places in the UML 2.5 spec the message line (that goes from lifeline to lifeline) is restricted to have the destination end no higher than the source end.

    While this sounds reasonable, it’s not really logically required in the general case.

    No, I’m not talking about faster-than-light messages.

    When a sequence diagram / fragment is “weak” (not strict) ordering, the individual life-lines can have their own time scale, and as long as causality is followed. And as each life-line’s time scale need not be uniform, a message going from one location on one lifeline to another lifeline but physically higher need not violate any logical or physical limitations.

    Please eliminate the restriction preventing upward aiming message lines when the ordering is weak. This will allow the modelers to have better use of the diagram real-estate.

    Michael

  • Reported: UML 2.5 — Sat, 19 Oct 2013 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Use cases and use of arrows

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

    Modelers often use arrows on the relationships between use cases and their actors. This is never explained/allowed/disallowed in the spec. One would think that if arrows are allowed, then qualifiers, ownership balls,

    {ordered}

    ,

    {unique}

    , etc. would also be allowed. Almost no one uses those arrows as true navigability. Perhaps some mention of the arrows is required and to allow for user determined semantics.

  • Reported: UML 2.5 — Fri, 11 Oct 2013 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Even if Use Cases need not have an actor, there is some ambiguity when there is an «include»d or «extension» use case

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

    Even if Use Cases need not have an actor, there is some ambiguity when there is an «include»d or «extension» use case. Much of the use case literature says, that the actors of the base use case are automatically actors of the extension or inclusion. They also say that duplicating the actors, that is, connecting the base’s actors to the extension or inclusion, implies that these actors may be needed twice for the extension/inclusion. This approach of assuming that the base’s actors are actors of the extension/inclusion is natural when the use cases are detailed out in sequence diagrams, and is almost a necessity when the extension/included use case can be used by many base use cases (where their actors could be different in each case). If an explicit actor is added to the extension/inclusion, is it added to the base’s actor or replace it?

  • Reported: UML 2.5 — Fri, 11 Oct 2013 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Information flow instantiation

  • Key: UMLR-295
  • Legacy Issue Number: 19167
  • Status: open  
  • Source: MITRE ( Dr. Fatma Dandashi)
  • Summary:

    Information flow instantiation. There is no UML construct to define flow and then to instantiate flows to use flow types and then flow instances that flow between two instances of two things.

  • Reported: UML 2.5 — Thu, 26 Dec 2013 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Cannot set an activity as the source or target of an information flow

  • Key: UMLR-294
  • Legacy Issue Number: 19133
  • Status: open  
  • Source: Alstom Transport ( Wagner Schalch Mendes)
  • Summary:

    According to the constraints specified for an InformationFlow, its sources and targets can be only of the following kind: Actor, Node, UseCase, Artifact, Class, Component, Port, Property, Interface, Package, ActivityNode, ActivityPartition and InstanceSpecification except when its classifier is a relationship.

    In my opinion, Activity should also be included in the list.

  • Reported: UML 2.4.1 — Wed, 4 Dec 2013 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Description of the OCL on Actor does not match OCL and both are obsolete.

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

    The description of the OCL on an Actor limits associations to Use Cases, Components, and Classes. However, the OCL limits it to Use Cases and Classes, forbids behavior, and doesn’t explicitly mention Components.

    a. I assume that Components are types of Classes, but Behavior is generally not a class (it’s a classifier), so I wonder why the limitation on behavior is needed?

    b. Wouldn’t this allow an Actor to have an attribute/part that is typed by a class?

    c. Isn’t this entire restriction obsolete? We don’t seem to be insisting that actors are outside of the subject anymore, almost all modeling approaches, allow for actors to be full design elements within a system. This is necessary to support multiple layers of system analysis, so that at one level some of the parts of a system become actors to other parts when modeled at the level. Requiring the modeling to introduce redundant elements to represent actors that are part of the higher-level system seems inappropriate.

  • Reported: UML 2.5 — Fri, 11 Oct 2013 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

About prescribed port implementation

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

    Description:

    The prescription made in the §11.3.3 about the implementation of Port seems to be overly restrictive:

    “When an instance of an EncapsulatedClassifier is created, instances corresponding to each of its Ports are created and held in the slots specified by each Port, in accordance with its type and multiplicity. These instances are referred to as “interaction points” and provide unique references.”

    As long as port is defined as “a distinct interaction point”, of which the primary purpose is: “enabling different communications to be distinguished based on the Port through which they occur”, the implementation described by the text quoted above, and which based on the instantiation of a separate object, is actually a possible implementation but it is not the only one.

    An alternative valuable implementation is to make them pure routing information that does not required any structural part instance (cf. SDL port semantics). UML should not prevent implementations of that kind.

  • Reported: UML 2.5 — Fri, 22 Nov 2013 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Problem with MultiplicityELement::lower redefinition in UML 2.5 Beta 2

  • Key: UMLR-297
  • Legacy Issue Number: 19185
  • Status: open  
  • Source: Eclipse Foundation ( Mr. Kenneth Hussey)
  • Summary:

    ExtensionEnd::lower invalidly redefines MultiplicityELement::lower (see issue 13992) - the multiplicity of ExtensionEnd::lower doesn't fall within that of MultiplicityELement::lower.

  • Reported: UML 2.5 — Fri, 17 Jan 2014 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

BehavioredClassifier should redefine Classifier::conformsTo to include interfaceRealization

  • Key: UMLR-296
  • Legacy Issue Number: 19179
  • Status: open  
  • Source: riseup.net ( Pieter Martin)
  • Summary:

    Currently interface realizations are not included in the conformance specification on BehavioredClassifier. In particular this is a problem for subsetting semantics when the subsetted property resides on an Interface.

  • Reported: UML 2.5 — Sat, 11 Jan 2014 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

No rules on Extension Pts governing differences between Use Case definitions & «extend» relationships usage

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

    Extension points appear to be documented in the properties of a use case. However, extension points are also allowed to be referred to in the condition note attached to the «extend» relationship. Is it legal to refer to an extension point that is not defined in the use case? Does this automatically add the extension point to the base use case. An example of this is in figures 18.3 and 18.11

  • Reported: UML 2.5 — Fri, 11 Oct 2013 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Abstract Syntax diagram for Use Cases

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

    The Abstract Syntax diagram for Use Cases should show that there is some intended relationship between an Actor and a Use Case. This should have the correct multiplicities as determined in the issue above. It can be a subset of existing relationships in the metamodel

  • Reported: UML 2.5 — Fri, 11 Oct 2013 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Navigability orthogonal to end ownership or not?

  • Key: UMLR-257
  • Legacy Issue Number: 16350
  • Status: open  
  • Source: gmail.com ( Adam Ci&#261;&#380;y&#324;ski)
  • Summary:

    At one point (page 42) the specification reads:
    "Navigability notation was often used in the past according to an informal convention, whereby non-navigable ends were assumed to be owned by the association whereas navigable ends were assumed to be owned by the classifier at the opposite end. This convention is now deprecated. Aggregation type, navigability, and end ownership are orthogonal concepts, each with their own explicit notation."

    The same thought can be found here: http://www.omg.org/issues/issue15128.txt :
    "... an old constraint from UML 1.x when navigability meant the same as ownership of property"

    However at another place (page 38) the specification reads:
    "An end property of an association that is owned by an end class or that is a navigable owned end of the association indicates that the association is navigable from the opposite ends; otherwise, the association is not navigable from the opposite ends."

    So is navigability orthogonal to end ownership or not? I think that the specification is somewhat unclear concerning these issues.

    The descriptions of ownedEnd and navigableOwnedEnd don't clarify much and seem to be too brief.

  • Reported: UML 2.3 — Tue, 28 Jun 2011 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Ambiguous stereotype notation

  • Key: UMLR-256
  • Legacy Issue Number: 16342
  • Status: open  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    Suppose we have a stereotype S extending UML::Class.
    We can apply S to a UML::Class, UML::Activity, UML::StateMachine and any other element whose metaclass is a kind of UML::Class.

    The UML notation for stereotype allows showing applications of S as <<S>> but this notation does not clearly show what kind of element the element is.
    In cases where distinct metaclasses (e.g., UML::Class, UML::Activity, UML::StateMachine) use the same notation (i.e. a box), the overall notation is ambiguous.

    The UML notation could be extended to show optionally the metaclass of an element, e.g., <<S>> [Class] vs. <<S>> [Activity] vs. <<S>> [StateMachine].

    Proposed resolution:

    in clause 18.3.9, Stereotype, under notation, change:

    When a stereotype is applied to a model element (an instance of a stereotype is linked to an instance of a metaclass),
    the name of the stereotype is shown within a pair of guillemets above or before the name of the model
    element, or where the name would appear if the name is omitted or not displayed. For model elements
    that do not have names but do have a graphical representation, unless specifically stated elsewhere, the stereotypes
    can be displayed within a pair of guillemets near the upper right corner of the graphical representation.
    If multiple stereotypes are applied, the names of the applied stereotypes are shown as a comma-separated list
    with a pair of guillemets. When the extended model element has a keyword, then the stereotype name will be displayed close to the keyword,
    within separate guillemets (example: «interface» «Clock»).

    to:

    When a stereotype is applied to a model element (an instance of a stereotype is linked to an instance of a metaclass),
    the name of the stereotype is shown within a pair of guillemets above or before the name of the model
    element, or where the name would appear if the name is omitted or not displayed optionally followed by the name of the
    model element's metaclass within a pair of square brackets. For model elements
    that do not have names but do have a graphical representation, unless specifically stated elsewhere, the stereotypes
    can be displayed within a pair of guillemets near the upper right corner of the graphical representation optionally
    followed by the name of the model element's metaclass within a pair of square brackets.
    If multiple stereotypes are applied, the names of the applied stereotypes are shown as a comma-separated list
    with a pair of guillemets. When the extended model element has a keyword, then the stereotype name will be displayed close to the keyword,
    within separate guillemets (example: «interface» [Interface], «Clock» [Class]).

  • Reported: UML 2.5 — Wed, 22 Jun 2011 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Notation of Lifelines

  • Key: UMLR-248
  • Legacy Issue Number: 15991
  • Status: open  
  • Source: International Business Machines ( Mr. Adam Neal)
  • Summary:

    In UML 2.3, section 14.3.19 (Lifelines), the notation of a lifeline is given as follows:

    <lifelineident> ::= ([‘[‘ ‘]’]] [: [decomposition]) | ‘self’ <selector> ::= <expression> <decomposition> ::= ‘ref’ <interactionident> [‘strict’]

    Given a Lifeline has an explicit name, it seems as though its not allowed to be displayed. Does anyone know if there is a specific reason for not showing the name of a Lifeline given it has one?

  • Reported: UML 2.5 — Wed, 26 Jan 2011 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Tags typed by classes/blocks

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

    The UML Superstructure spec states in Subclause 18.3.7 that:

    “A Profile can define Classes, DatatTypes, PrimitiveTypes and Enumerations as well as Stereotypes since Profiles imports Constructs. However, these types can only be used as the type of properties in the profile, they cannot be used as types in models the profile is applied to since they apply at the meta-model level, not the model level. It is however possible to define these types in separate packages and import them as needed in both profiles and models in order to use them for both purposes.

    Stereotypes can participate in binary associations. The opposite class can be another stereotype, a non-stereotype class that is owned by a profile, or a metaclass of the reference metamodel. For these associations there must be a property owned by the Stereotype to navigate to the opposite class. Where the opposite class is not a stereotype, the opposite property must be owned by the Association itself rather than the other class/metaclass.”

    However, the restrictions expressed in this text are not formalized by any constraints. Either OCL should be added to formalize these restrictions, or the restrictions should be removed

  • Reported: UML 2.5 — Wed, 12 Jan 2011 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

XMI representation of stereotype application

  • Key: UMLR-246
  • Legacy Issue Number: 15903
  • Status: open  
  • Source: Universidad Politecnica de Madrid ( Miguel de Miguel)
  • Summary:

    I think that the source of confusion could be the paragraph in page 683 in 10-11-13.pdf

    “The most direct implementation of the Profile mechanism that a tool can provide is by having a metamodel based

    implementation, similar to the Profile metamodel. However, this is not a requirement of the current standard, which

    requires only the support of the specified notions, and the standard XMI based interchange capacities. The profile

    mechanism has been designed to be implementable by tools that do not have a metamodel-based implementation.”

    In this paragraph the “XMI based interchange capacities” are mentioned, but there is not

    a direct reference to page 684, to clarify that these the “XMI interchange capacities” are specified in 684. This paragraph

    gives the impression that the XMI interchange format is not closed.

  • Reported: UML 2.5 — Fri, 17 Dec 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

New notation for attribute

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

    According to several discussions I had with UML users, it appears that many of them, who have the intent to simply to add an attribute to a class, finally create an association to the type of the required attribute. In all case I faced, the reason was that they prefer the notation UML proposes for association which is much more powerful. Mainly:
    Capability to get a modular diagram thanks to the “link notation”
    Capability to show the aggregation kind

    However attributes and association are not the same and it is a pity to introduce such a drift in the semantics just because of the notation.

    What do you think about adding a notation for the attributes that would offer the capability to represent all their properties and to designate their type using a link?

  • Reported: UML 2.5 — Fri, 10 Dec 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Use cases specifying the same subject cannot be associated: exception

  • Key: UMLR-254
  • Legacy Issue Number: 16292
  • Status: open  
  • Source: London Life Insurance Co. ( Willem Van Galen)
  • Summary:

    The UML Superstructure Specification V2.4 states in 16.3.6 UseCase (from UseCases): “Two use cases specifying the same subject cannot be associated since each of them individually describes a complete usage of the subject.”

    For the longest time, this looked like a common-sense rule. However, it seems to me that in the context of SOA there is at least on exception to this rule.

    Let’s say that:
    1. The subject represents a component (as understood in SOA) and the use cases represent the component’s services.
    2. The initiating actor of all of the component’s services is Another Use Case. This reflects the SOA reality that services are not directly consumed by human actors but by other use cases.
    3. The component offers services A and B, both of which trace back to legitimate uses.
    4. As it happens, when service B is defined in detail it turns out that one of its steps amounts exactly to the functionality represented as service A.

    In such situations, where the subject already has a public service (A) that can actually be reused by one or more of its other public services (B), I think it’s entirely reasonable to allow B to be associated with A. After all, A’s initiating actor is Another Use Case, which is exactly what B is. In object-orientated terms this amounts to an object performing an operation on itself.

    I propose for UML to accommodate this scenario.

  • Reported: UML 2.4 — Sat, 28 May 2011 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Metaclass stereotype notion (02)

  • Key: UMLR-252
  • Legacy Issue Number: 16119
  • Status: open  
  • Source: email.com ( Kirill Fakhroutdinov)
  • Summary:

    Text says: "The names of Profiles are shown using a dashed arrow with an open arrowhead from the package to the applied profile."
    "The names" is not relevant in this context. The arrow is related to profile application.
    The text should say something like: "The applied Profiles are shown ..."

  • Reported: UML 2.4 — Fri, 27 Jun 2014 11:17 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Metaclass stereotype notion

  • Key: UMLR-251
  • Legacy Issue Number: 16118
  • Status: open  
  • Source: email.com ( Kirill Fakhroutdinov)
  • Summary:

    Text says: "A Class that is extended by a Stereotype may be extended by the optional stereotype «Metaclass» ..."
    The second "extended" has no sense.
    It should say something like: "A Class that is extended by a Stereotype may be denoted by the optional stereotype «Metaclass» ..."

  • Reported: UML 2.4 — Sun, 17 Apr 2011 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Profile URI Attribute - Mingled URI Definition and Use in XMI

  • Key: UMLR-250
  • Legacy Issue Number: 16117
  • Status: open  
  • Source: email.com ( Kirill Fakhroutdinov)
  • Summary:

    While describing profile URI attribute for profiles UML specification mingled definition of URI and format used for XMI. URI value as a whole should follow URI specification RFC 2396 and OMG recommended format:
    uri = http://profileParentQualifiedName/version/profileName.xmi
    When URI is used for XMI, the profileParentQualifiedName part should also be (made?) valid XML QName, e.g. with "all other illegal XML QName characters removed". Note, that XML QName usually has namespace prefix followed by ':', e.g. 'taxes:dependent', which contradicts to and has no sense as related to the first URI 2396 requirement.

  • Reported: UML 2.4 — Sun, 17 Apr 2011 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

State::stateInvariant multiplicity too restrictive

  • Key: UMLR-253
  • Legacy Issue Number: 16249
  • Status: open  
  • Source: Northrop Grumman ( Mr. Christopher McClure)
  • Summary:

    The multiplicity of State::stateInvariant is specified as [0..1]. This seems to restrictive, as it common for states to have multiple invariants, especially since this is the most convenient mechanism for specifying the actual values for properties, etc. that define the state. Furthermore, widening the multiplicity to [*] would be in alignment with the multiplicities of pre/postconditions on operations, etc.

  • Reported: UML 2.5 — Mon, 16 May 2011 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Package URI Attribute Uses Obsolete RFC 2396

  • Key: UMLR-249
  • Legacy Issue Number: 16116
  • Status: open  
  • Source: email.com ( Kirill Fakhroutdinov)
  • Summary:

    Specification requires URI package attribute to follow the rules and syntax of the IETF URI specification RFC 2396. RFC 2396 was rendered obsolete by the more recent version of the URI syntax - RFC 3986, released in 2005.

  • Reported: UML 2.4 — Sun, 17 Apr 2011 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

A deferrable trigger may have a guard

  • Key: UMLR-255
  • Legacy Issue Number: 16307
  • Status: open  
  • Source: asu.edu ( Joe Mooney)
  • Summary:

    It is an unfortunate restriction to omit guards from the specification of <trigger>/defer.

    Please explicitly state or reconsider this restriction since using a guard would simplify many scenarios involving event deferral

  • Reported: UML 2.4 — Wed, 1 Jun 2011 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Owning of interaction fragments is ambiguous when InteractionOperands are present

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

    It is not clear from chapter 14 how interaction fragments are supposed to be owned when there are InteractionOperands present.

    It seems to be the case, but is not stated, that everything diagrammatically inside the operand should be owned by the fragment. This would, I think, give rise to the following consequences:

    1. The top and bottom of each fragment and operand must be on the same Lifeline or Execution. A fragment cannot span different executions or have its boundaries cover different levels of execution nesting.

    2. Everything inside of a fragment/operand must be entirely contained by the fragment/operand. This includes both sides of a message, all nested fragments, interaction uses, and the top and bottom of execution specifications.

    However it appears to be a valid instance of the metamodel to parent arbitrary fragments at any level of nesting, which would enable these constraints to be violated.

    The specification should confirm these ownership constraints. This would best be done in conjunction with the sentence “InteractionOperand contains an ordered set of InteractionFragments” in section 14.3.16, which should state exactly which InteractionFragments must be owned by the InteractionOperand.

    Different vendors’ interpretations of this ambiguity can cause interoperability problems.

  • Reported: UML 2.5 — Tue, 4 May 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Chapter 14 is ambiguous and contradictory about how to link up messages and execution specifications

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

    Chapter 14 is ambiguous and contradictory about how to link up messages and execution specifications. This is because in the metamodel the start and finish of an ExecutionSpecification are OccurrenceSpecifications, not ExecutionOccurrenceSpecifications. This means that it appears to be valid for the MessageOccurrenceSpecification that is a Message's receiveEvent to also be the start of an ExecutionSpecification.

    The text is equally ambiguous. The 14.3.10 paragraph "An ExecutionSpecification is a specification of the execution of a unit of behavior or action within the Lifeline. The duration of an ExecutionSpecification is represented by two ExecutionOccurrenceSpecifications, the start ExecutionOccurrenceSpecification and the finish ExecutionOccurrenceSpecification" appears to say unambiguously that the start and finish must be ExecutionOccurrenceSpecifications. However the later sentence "Typically the start occurrence and the finish occurrence will represent OccurrenceSpecifications such as a receive OccurrenceSpecification (of a Message) and the send OccurrenceSpecification (of a reply Message)" both introduces ambiguity through the use of the word "typically", and then proceeds to blatantly contradict the earlier paragraph.

    This causes tool interoperability problems.

    I suggest targeting ExecutionSpecification::start and finish onto ExecutionOccurrenceSpecification, and rewriting the contradictory semantics accordingly.

  • Reported: UML 2.5 — Tue, 4 May 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

issue10087 and association-like notation

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

    No problem with the issue itself or the proposed resolution. I’m just wondering about the principle of the “association-like notation”.

    My concerns:

    The specification says that “An attribute may also be shown using association notation”. Nevertheless, defining an attribute or using an association as described in figure 7.31 is not the same thing. The definition of one attribute generates only one property while the definition of a binary association generates two properties plus a classifier for the association itself.

    If it’s only a matter of notation, how to distinguish in a diagram between:

    a) an attribute with an association-like notation

    and

    b) a “true” association?

    Yves

  • Reported: UML 2.5 — Tue, 23 Mar 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

not sure it is possible to define a constraint without a context

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

    According to the semantics sub-clause of the §7.3.10, it seems that the intent is that there is a relationship between the context and the owner of the constraint:

    “In general there are many possible kinds of owners for a Constraint. The only restriction is that the owning element must have access to the constrainedElements.

    The owner of the Constraint will determine when the constraint specification is evaluated. For example, this allows an Operation to specify if a Constraint represents a precondition or a postcondition”

    I not sure it is possible to define a constraint without a context. I believe a constraint always has a context even if it is an implicit one.

    Maybe a convenient solution would be to make the context non-derived but mandatory ([1..1]) with a default value set to the constraint’s owner.

  • Reported: UML 2.5 — Tue, 16 Mar 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Timing Diagram and interchange

  • Key: UMLR-223
  • Legacy Issue Number: 15207
  • Status: open  
  • Source: Anonymous
  • Summary:

    In the more compact version of the Timing diagram (figure 14.30) we can see the change in state of a lifeline as it goes from one state to another.
    In particular, we see how the lifeline moves from the "Idle" state, then to other states, then back to "Idle".

    Some facts:
    If I'm interpreting this correctly, we are seeing StateInvariant on the timing diagram.
    StateInvariant is an InteractionFragment.
    The StateInvariant is kept in the Interaction::Fragment ordered collection.

    Issue:
    The problem is that if we move from the "Idle" state and then back to the same "Idle" state, we would have to create another StateInvariant to place in the Fragment collection - how else could we determine that we have moved back to the "Idle" state?
    StateInvariant also owns its Constraint, so there would be no way for the second StateInvariant to even refer to the same constraint as the first.
    Having to duplicate the StateInvariant and/or Constraint seems incorrect?
    ( As a side note, the spec uses the terminology "State or Condition" when it is refering to StateInvariant - I believe this is ambiguous )

    Am I overlooking something obvious? If not, I think this could not only pose problems for XMI interchange, but also seems to be inefficient.

    Any insight would be appreciated.

  • Reported: UML 2.5 — Fri, 16 Apr 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Missing constraints preventing contradictory GeneralizationSets.

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

    It is possible for two Generalizations to be part of GeneralizationSet A and part of GeneralizationSet B, where is A is constrained to be disjoint and B is constrained to be overlapping,

    There should be some discussion and/or OCL preventing this

  • Reported: UML 2.5 — Sat, 6 Dec 2014 07:04 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

What is the default setting for disjoint/overlapping and complete/incomplete for generalizations that are not part of a GeneralizationSet

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

    Currently, a generalization set has the default (overlapping, incomplete).

    However, as a Generalization does not need to have a GeneralizationSet, there is no default semantics for unnamed Generalization.

    Perhaps an approach that has all unnamed Generalizations with the same generalized Classifier as part of an "unnamed" GeneralizationSet would work. This would allow unnamed generalizations to have default overlapping/disjoint complete/incomplete semantics

  • Reported: UML 2.5 — Fri, 5 Dec 2014 09:22 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

How can a GeneralizationSet not have any Generalizations?

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

    9.7.2 Abstract Syntax allows a GeneralizationSet to have no Generalizations. This seems wrong. The GeneralizationSet applies to 1 or more Generalizations. When the last Generalization is deleted, any GeneralizationSet should be deleted.

  • Reported: UML 2.5 — Fri, 5 Dec 2014 09:04 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Ambiguity in description of TransitionKind

  • Key: UMLR-397
  • Legacy Issue Number: 19658
  • Status: open  
  • Source: Zeligsoft ( Ernesto Posse)
  • Summary:

    The spec seems to be contradictory regarding local transitions: in p. 378 is says that a local transition "[...] will not exit the composite (source) State, but it will exit and re-enter any state within the composite state that is in the current state configuration". Since it says "re-enter" it is implying that the current configuration doesn't change.
    However on p.328 it states that "for local Transitions the target Vertex must be different than the source Vertex". The only way I can reconcile the two is if by "source Vertex" and "target Vertex" they mean an exit point and entry point of the same composite state, i.e., being a self-transition.

    In summary, the formal definition in p.378 suggests that local transitions must be self-loops, while the description of p.328 suggests that local transitions cannot be self-loops. Both cases seem to be unnecessary restrictions, and there are no constraints in Transition enforcing those restrictions

  • Reported: UML 2.5 — Tue, 18 Nov 2014 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Two classes can share attributes by use of element import

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

    A class, as a namespace, can import attributes of another class. This is not sharing a type, but sharing a slot, creating shared memory.

  • Reported: UML 2.5 — Tue, 4 Nov 2014 03:06 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

History pseudo states in protocol state machines

  • Key: UMLR-383
  • Legacy Issue Number: 19648
  • Status: open  
  • Source: KnowGravity Inc. ( Mr. Markus Schacher)
  • Summary:

    I see no reason why UML prohibits history pseudo states in protocol state machines (constraint at the bottom of page 362). As I understand history states, they are merely a syntactical convenience that may be loss-lessly converted into a semantically equivalent state machine without history states. However, using history states usually greatly simplifies the specification of complex protocol state machines.

  • Reported: UML 2.5 — Wed, 29 Oct 2014 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Message lines can cross without the first being asynchronous

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

    In the description of Figure 17.3, where the messages of CardOut and OK cross before they are received, the description says.

    "Such communication may occur when the messages are asynchronous"

    Though this true, it is misleading. It's possible for the messages to cross even if the messages are synchronous. The sending lifeline may have multiple parts (or multiple threads), where each part (or thread) waits synchronously, the overall effect on the composite level is to look asynchronous. This was extensively discussed last year and the conclusion was that this was possible.

    Please eliminate the offending sentence

  • Reported: UML 2.5 — Thu, 30 Oct 2014 03:19 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Justification for messages on differnent sides of a gate being identical is not clear.

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

    In the description of matching on gates...
    "Gates are matched by name, with a formal Gate matched with an actual Gate having the same name, and with an inner CombinedFragment Gate matched with an outer CombinedFragment Gate having the same name.

    The Messages for matched Gates must correspond. Messages correspond if they have identical name, messageSort, and signature property values, as well as being in the same direction."

    Matching the Gates makes sense. However, requiring the message details to match invariantly seems to be overly restrictive. For example, a message in the same direction, and messageSort, but perhaps with covariant/contravariant matching of parameters should be acceptable

  • Reported: UML 2.5 — Thu, 30 Oct 2014 04:24 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Tables 17.1, 17.3, 17.5, 17.6 Header Formats

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

    Header of these tables should be consistently aligned. The middle column header is bottom justified, while the left and right column headers appear top justified. They should all probably be middle justified.

  • Reported: UML 2.5 — Thu, 23 Oct 2014 18:37 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Need clarification between exceptionType and the type of the exceptionInput

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

    Can we see an example with both specified.

    Can they be different?

    Which can be unspecified?

  • Reported: UML 2.5 — Fri, 24 Oct 2014 07:09 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Does not seem possible to have an exception cause an interrupt (leave the region)

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

    Because of they use the same notation. an exception handler and the target of a interrupting edge look identical. However, the semantics are quite different. In the exception handler case, tokens are emitted from the protected behavior. In the interrupting edge case, tokens in the region are abandoned, and instead leave from the interrupting edge "handler"

    1) the notation is too similar and confusing to modelers and readers.
    2) It's not possible to have an exception cause a region to be abandoned. This is a common and desirable situation
    3) In some circumstances it would be impossible to distinguish between an exception handler and interruptible region "handler". Imagine an exception handler whose exception edge crosses an interruptible region boundary. The only way to be sure it was an interruptible region handler is if it has outgoing edges. Without them, it could be either.

  • Reported: UML 2.5 — Fri, 24 Oct 2014 06:53 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

What exception type is "any" exceptionType

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

    The discussion of exception handlers seems that it is possible ot have an an "any" exception type.

    p 439
    "exceptionType : Classifier [1..*] (opposite A_exceptionType_exceptionHandler::exceptionHandler)
    The Classifiers whose instances the ExceptionHandler catches as exceptions. If an exception occurs whose type is any exceptionType, the ExceptionHandler catches the exception and executes the handlerBody."

    What is "any" and how do you specify it. Please clarify within the specificaiton.

  • Reported: UML 2.5 — Fri, 24 Oct 2014 06:38 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Vertical lines do not always describe the time-line for an interaction diagram

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

    In an interaction diagram each vertical line describes the time-line for a process, where time increases down the page.

    This is only true for sequence diagrams. Timing diagram use horizontal ordering. Communication and Interaction Overview diagrams may have incidental non-time ordered vertical lines.

    The following text from the spec should be qualified to only discuss sequence diagrams

    17.1.3 Partial ordering constraints on valid and invalid traces
    ...
    In an interaction diagram each vertical line describes the time-line for a process, where time increases down the page.

    17.3.3 Semantics
    Lifelines
    In an interaction diagram a Lifeline describes the time-line for a process, where time increases down the page

  • Reported: UML 2.5 — Fri, 24 Oct 2014 04:33 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Spelling error in ActivityGoups

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

    15.6.1 Summary
    ActivityGoups are a grouping consturcts.

  • Reported: UML 2.5 — Wed, 22 Oct 2014 18:07 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Message wildcards appear to ignore operation default values

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

    Operations may contain a list of Parameters, which are defined in 9.4.4.

    Parameters may an '= <default>' to specify the default value for that parameter.

    However, in Messages, argument wi/o values are given wildcard values, representing any legal value.

    A wildcard could be representing the default value, but as described, it appears that it need not be – it can be ANY legal value.

    This means that it is impossible to specify a message that uses the default values of a parameter wi/o making them explicit. This makes the specification of default values to operation parameters not applicable to messages. This seems unintended. (If intended, then it is wrong)

    The discussion of message wildcards should indicate that (at least for input arguments), an unspecified value or wildcard will use the parameter default.

    If this is somewho intended the specification needs to be explicit and come up with a way of making the default values useful.

  • Reported: UML 2.5 — Thu, 23 Oct 2014 20:05 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

use of ! instead of + or ∪

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

    The semantics of an Interaction are expressed in terms of a pair [P, I], where P is the set of valid traces and I is the set of invalid traces. P ! I need not be the whole universe of traces.

    The ! symbol should be eitther + or ∪

  • Reported: UML 2.5 — Fri, 24 Oct 2014 04:10 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Extraneous " (double quote) in 17.5.4 BehaviorExecutionSpecification

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

    See "17.2.4 (ExecutionSpecification).

    Please delete the unneeded doublequote (")

    This is similar to UMLR-389

  • Reported: UML 2.5 — Thu, 23 Oct 2014 20:08 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Coloring and shading on Figure 17.10 should be removed

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

    Standardize on tool -independence look

  • Reported: UML 2.5 — Fri, 24 Oct 2014 06:29 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Caption for Table 17.5 on wrong page

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

    Caption is on preceding page.

  • Reported: UML 2.5 — Fri, 24 Oct 2014 06:27 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Mismatch of singular/plural Activity Goups are a grouping constructs

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

    Probably remove the "a"

  • Reported: UML 2.5 — Wed, 22 Oct 2014 18:10 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

SignalBroadcastAction used where BroadcastSignalAction should be.

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

    SignalBroadcastAction used where BroadcastSignalAction should be.

    While each message is targeted at exactly one receiver object and caused by exactly one sending object, an occurrence of a sending event may result in a number of messages being generated (as in SignalBroadcastAction, see sub clause 16.3).

    While each message is targeted at exactly one receiver object and caused by exactly one sending object, an occurrence of a sending event may result in a number of messages being generated (as in SignalBroadcastActionBroadcastSignalAction, see sub clause 16.3).

  • Reported: UML 2.5 — Thu, 2 Oct 2014 02:56 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Spelling error: i-->is

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

    The letter "i" is used when I presume that the word "is" should be

    o ActionInputPins with fromActions that are ReadVariableActions may be shown in a shorthand notation that i only the ActionInputPin and nearby the name of the variable of the ReadVariableAction interchanged as a UMLNameLabel with the variable as modelElement.

    o ActionInputPins with fromActions that are ReadVariableActions may be shown in a shorthand notation that i it only the ActionInputPin and nearby the name of the variable of the ReadVariableAction interchanged as a UMLNameLabel with the variable as modelElement.

  • Reported: UML 2.5 — Thu, 2 Oct 2014 02:46 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML 2.5 Section 15.2.3 p392 description for the ActivityEdge weight

  • Key: UMLR-350
  • Legacy Issue Number: 19540
  • Status: open  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    The description for the ActivityEdge weight includes:

    It must evaluate to a positive LiteralUnlimitedNatural
    and may be a constant.

    I think that should be "an UnlimitedNatural value" rather
    than "LiteralUnlimitedNatural". (I'm not sure there's
    any need to specify that it may be a constant either.)

  • Reported: UML 2.5 — Thu, 24 Jul 2014 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Another UML 2.5 Beta 2 XMI invalidity

  • Key: UMLR-349
  • Legacy Issue Number: 19538
  • Status: open  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    For constraint specifications that "Cannot be expressed in OCL",
    there is an invalid language attribute in the XMI. For example:

    <specification xmi:type="uml:OpaqueExpression" xmi:id="ObjectFlow-same_upper_bounds-_specification" language=""/>

    language is a multivalued property with primitive type and these
    can only be represented as elements.

    (In 2.4.1 such unexpressable constraints were represented as
    (OCL,true), it's not clear the above change is intentional.)

  • Reported: UML 2.5 — Tue, 22 Jul 2014 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Unclear statement regarding Lifeline shape

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

    Section 17.3.4 states

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

    "part" is ambiguous. Its meaning can not be inferred from the specification of the Lifeline class. Can you change the wording of this sentence to clarify what is meant by "part" ?

    Proposed change : The Lifeline head has a shape that is based on the Type of the ConnectableElement that this lifeline represents.

  • Reported: UML 2.5 — Wed, 16 Apr 2014 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML 2.5 Overly strict restriction on message slope in seq diagrams

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

    In UML 2.5 Paragraph 17.4.4. Notation

    Message:
    “..A line must be such that every line fragment is either horizontal or downwards when traversed from send event to receive event.”

    While this restriction appears reasonable when first read, it is really overly strict.

    No, I’m not talking about faster-than-light messages.

    In the default, WEAK, interpretation of sequence diagrams, the time-wise ordering of occurrences within a lifeline is independent of occurrences on other lifelines, subject to cause/effect sequencing (message sending—>message reception). And, of course, the order of occurrences as depicted on the lifeline must be maintained.

    This is practically equivalent to saying that each lifeline has its own clock or timescale, and that ordering by that clock must be maintained and that causality across lifelines must be maintained. It is often thought that one could change the timescale (and not necessarily smoothly) on a lifeline without changing the interpretation or legality of the diagram.

    And as each life-line’s time scale need not be uniform, a message going from one location on one lifeline to another lifeline but physically higher need not violate any logical or physical limitations.

    However, the restriction on messages not taking a non-negative slope, prevents otherwise legal changes in scale and makes invalid some diagrams that do not violate causality or the within-lifeline ordering.

    Please eliminate the restriction preventing upward aiming message lines when the ordering is weak. This will allow the modelers to have better use of the diagram real-estate.

  • Reported: UML 2.5 — Sun, 13 Apr 2014 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Unnamed elements in a namespace

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

    I’ve asked myself what happens when a namespace owns members that have no name. For example two outgoing include relationships from a use case. A include relationship is a named element that typically has no name.

    NamedElement defines the query isDistinguishableFrom():

    isDistinguishableFrom(n : NamedElement, ns : Namespace) : Boolean The query isDistinguishableFrom() determines whether two NamedElements may logically co-exist within a Namespace. By default, two named elements are distinguishable if (a) they have types neither of which is a kind of the other or (b) they have different names.

    body: (self.oclIsKindOf(n.oclType()) or n.oclIsKindOf(self.oclType())) implies

    ns.getNamesOfMember(self)>intersection(ns.getNamesOfMember)>isEmpty()

    If I call that query at a unnamed include relationship with another unnamed include relationship as paramer n and the owning use case as namespace ns, the query returns true. That means two unnamed elements in a namespace are distinguishable which seems to be wrong from my point of view.

    Is that an issue or did I miss something?

  • Reported: UML 2.5 — Tue, 8 Apr 2014 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Including use case depends on included use case but Include is no subclass of Dependency

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

    The following sentences of the specification made me wonder why Include is no subclass of Dependency.

    "As the primary use of the Include relationship is for reuse of common parts, what is left in a base UseCase is usually not complete in itself but dependent on the included parts to be meaningful. This is reflected in the direction of the relationship, indicating that the base UseCase depends on the addition but not vice versa."

    Instead of the dependency being reflected in the direction of the relationship, the class could explicitly have Dependency semantics.

  • Reported: UML 2.5 — Wed, 16 Apr 2014 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML 2.5 Visibility of a packagedElement

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

    12.2.4 Notation

    The visibility of a packagedElement may be indicated by preceding the name by a visibility symbol (‘+’ for public and ‘-’ for private). Packages may not have protected or package visibility.

    This is a bit unclear, as the 2nd sentence does not include the first. I think you should say:

    …

    Package and their contained elements may not have protected or package visibility.

  • Reported: UML 2.5 — Mon, 31 Mar 2014 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML 2.5 Issue on DI for reply arrows

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

    In the UML 2.5 spec, the reply arrow on sequence diagrams now has two forms.

    17.4.4 Notation

    Message

    · A reply Message (messageSort equals reply) has a dashed line with either an open or filled arrow head.

    However, the DI section of the specification, p 754.

    Only allows the filled arrow head and does not support an option to specify which.

    This will mean that diagram interchange will not preserve use of the open arrow head (which is the traditional way of doing this)

    Michael Jesse Chonoles

    Change-Vision.

  • Reported: UML 2.5 — Mon, 31 Mar 2014 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Ambiguous Profile::profileApplication

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

    Profile::profileApplication

    {subsets directedRelationship wrt target}

    and occludes Package::profileApplication

    {subsets directedRelationship wrt source}

    .

    This means that

    aProfile.profileApplication <> aProfile.oclAsType(Package).profileApplication

    Since Profile::profileApplication is unnavigable, suggest renaming Profile::profileApplication as Profile::application

  • Reported: UML 2.5 — Mon, 31 Mar 2014 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML transition-centric state machine arrows (01) alternative exit pt vs entry pt notation

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

    In the UML 2.5 spec Figure 14.31 shows and the text describes the alternative exit point notation as a bracketed space

    — (exit point name) —

    The UML 2.5 spec in Figure 14.30 shows and the text describes the alternative entry point notation as a bracketed space with the string “via”.

    — (via entry point name) →

    This leaves the following, albeit pathological case:

    1st state — (via pointName) → 2nd state

    From the notation, you can’t be sure if “pointName” is the name of the entry point or if “via pointName” is the name of the exit point.

    One possible interpretation of the spec goes back to diagram in 14.32 and notices that there is no “leaving arrow head” (→) from the symbol for the exit point, but there is one for the entry point. If this is not accidental, then

    1st state — (via pointName) → 2nd state

    means the entry point pointName

    And the

    1st state — (via pointName) — 2nd state

    means the exit point “via pointName”

    However, this is pretty obscure and if intended should be clarified in the spec. If not intended, either “via” should be explicitly reserved (not allowed) in exit point names or the notation modified to distinguish them.

  • Reported: UML 2.5 — Sat, 5 Apr 2014 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML 2.5 issue on examples in 17.4.5

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

    In 17.4.5, the 3rd example, is

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

    However, the description says

    “This is a reply message assigning the return value 69 to ‘v’

    Choose either 96 or 69 and make consistent.

  • Reported: UML 2.5 — Sun, 13 Apr 2014 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML transition-centric state machine arrows (02) solid vs v-shaped arrow heads

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

    2nd related issue

    All the notation in the alternative transition-centric examples use solid, filled arrow heads. All the notation for the traditional state-centric examples use v-shaped arrow heads. However, the text never mentions this difference. The spec should clarify if this is part of the notation.

  • Reported: UML 2.5 — Sat, 5 Apr 2014 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML 2.5 Figure 10.10 Error

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

    In UML 2.5, Figure 10.10 is entitled

    ISensor is a required Interface of TheftAlarm

    However, the figure only shows an unnamed required Interface.

    The diagram needs to have the Interface named “ISensor” on the diagram.

  • Reported: UML 2.5 — Thu, 20 Mar 2014 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Name of Package in Figure 7.3 should be "Core" rather than "Constructs"

  • Key: UMLR-311
  • Legacy Issue Number: 19282
  • Status: open  
  • Source: lemke24.org ( Andreas Lemke)
  • Summary:

    The subtitle of the Figure 7.3:
    "The Core Packages"
    But the Name of the Package in the figure is "Constructs".

  • Reported: UML 2.4.1 — Mon, 10 Mar 2014 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Multiple Generalization Sets

  • Key: UMLR-313
  • Legacy Issue Number: 19288
  • Status: open  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    A generalization can appear in multiple generalization sets. The notation
    for this isn't completely clear to me as there are no examples of this
    case in the spec and the existing examples would be ambiguous if followed.

    The main problem is that there are multiple labels for the generalization
    set properties, for example the :TreeSpecies and

    {disjoint, incomplete}

    labels in the Tree example. Somehow these need to be visually joined to
    show they are properties of the same set. Additionally there are no
    examples showing the set name and any other properties so it's not clear
    what the full notation is.

    I'd guess the notation should actually be a single label in the form:

    name

    {complete, disjoint} : PowerType


    or

    {complete, disjoint}

    name : PowerType

    Which of those makes most sense?

  • Reported: UML 2.5 — Fri, 21 Mar 2014 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML 2.5 Figure 14.25 Choice Pseudostates

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

    Figure 14.25 Choice Pseudostates (and text above/below)

    The description of the figure indicates that the left hand (sub)diagram indicates the empty diamond should be on the right and the one with the operand inside the diamond should be on the left.

    The subdiagrams are backwards.

  • Reported: UML 2.5 — Sun, 30 Mar 2014 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

isReplaceAll=true and lowerBound > 1

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

    About the AddStructuralFeatureAction the UML 2.5 spec states that, if isReplaceAll is true: “[…]The StructuralFeature always has a single value when the Action completes, even if the lower multiplicity of the StructuralFeature is greater than 1 “( §16.8.3).

    In the other hand, the semantics of the multiplicities states the following (§7.5.3): “If a MultiplicityElement specifies a multivalued multiplicity (i.e., upper bound greater than 1), then an instantiation of this element has a collection of values. The multiplicity is a constraint on the number of values that may validly occur in that set.”.

    Does it mean that executing this action with isReplaceAll=true on a structural feature with a lower multiplicity greater than one will result in an invalid model or, in other words, that such a usage is somehow “illegal”?

  • Reported: UML 2.5 — Fri, 13 Sep 2013 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

test

  • Key: UMLR-276
  • Legacy Issue Number: 18239
  • Status: open  
  • Source: Object Management Group ( Mr. Juergen Boldt)
  • Summary:

    test

  • Reported: UML 2.5 — Fri, 27 Jun 2014 11:17 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

applying and associating stereotypes and explanation of all aspects of their serialization

  • Key: UMLR-275
  • Legacy Issue Number: 17564
  • Status: open  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    UML needs to explain in terms of UML what applying and associating
    stereotypes means and additionally needs to explain all aspects of their
    serialization. The UML specification has yet to explain what it means what "applying a stereotype" and what "stereotypes can participate in associations" mean in terms of UML.

    Since the UML profile mechanism is definitely not a metamodeling extension facility, these explanations must be made in terms of UML directly rather than indirectly via the "MOF2-equivalent semantics".

    Below is a 3-step proposal to explain what "applying a stereotype" and "stereotypes can participate in associations" mean in terms of UML.
    This proposal is illustrated using the SysML profile definition of the ValueType, Unit and QuantityKind stereotypes shown below:

    Point #1) The UML specification only shows how an instance of a stereotype is serialized but it does not say what that serialization is in terms of the UML metamodel.

    For example, we have:

    • 2 serializations of UML::InstanceSpecification

    <packagedElement xmi:type="uml:InstanceSpecification"

    xmi:id="_ISO-80000-1-SysML_mass_PackageableElement"

    name="mass">

    <packagedElement xmi:type="uml:InstanceSpecification"

    xmi:id="_ISO-80000-1-SysML_kilogram_PackageableElement"

    name="kilogram">

    • 2 serializations of instances of stereotypes, QuantityKind and Unit.

    <sysml:QuantityKind xmi:id="ISO-80000-1-SysML_mass_PackageableElement-appliedStereotypeInstance_InstanceSpecification"

    base_InstanceSpecification="_ISO-80000-1-SysML_mass_PackageableElement"/>

    <sysml:Unit xmi:id="ISO-80000-1-SysML_kilogram_PackageableElement-appliedStereotypeInstance_InstanceSpecification"

    base_InstanceSpecification="_ISO-80000-1-SysML_kilogram_PackageableElement"

    quantityKind="_ISO-80000-1-SysML_mass_PackageableElement-appliedStereotypeInstance"

    symbol="kg"/>

    I claim that serializations of instances of stereotypes are in fact just serializations of UML::InstanceSpecifications whose classifiers are stereotypes.

    That is, the above two elements are really a different serialization of the following:

    <packagedElement xmi:id="ISO-80000-1-SysML_mass_PackageableElement-appliedStereotypeInstance_InstanceSpecification"

    xmi:type="uml:InstanceSpecification"

    classifier="_SysML_Blocks_PackageableElement-QuantityKind_PackageableElement"
    base_InstanceSpecification="_ISO-80000-1-SysML_mass_PackageableElement"/>

    <packagedElement xmi:id="ISO-80000-1-SysML_kilogram_PackageableElement-appliedStereotypeInstance_InstanceSpecification"

    xmi:type="uml:InstanceSpecification"

    classifier="_SysML_Blocks_PackageableElement-Unit_PackageableElement"

    base_InstanceSpecification="_ISO-80000-1-SysML_kilogram_PackageableElement"

    quantityKind="_ISO-80000-1-SysML_mass_PackageableElement-appliedStereotypeInstance"

    symbol="kg"/>

    The rationale for this is simply that we must be able to specify constraints in OCL as well as queries/transformations in QVT and actions in any action language (e.g., ALF) where we can operate on instances of stereotypes without having to implement profile-specific tooling.

    Point #2) The UML specification should explicitly say that:

    2.1) an instance of a stereotype is a distinguished instance of UML::InstanceSpecification whose classifier is the stereotype definition

    2.2) what distinguishes an UML::InstanceSpecification whose classifier is a UML::Stereotype is that it is serialized differently than any other UML::InstanceSpecification (whose classifier is not a UML::Stereotype)

    The rationale for (2.1) is that this is the simplest way to address this point without introducing a new metaclass in the UML metamodel.
    The rationale for (2.2) is that we need a way to tell how to serialize any UML::InstanceSpecification, whether it is an instance of a stereotype or something else.

    Point #3) The meaning of "stereotypes can participate in associations" is that it is possible to create link instance of such an association (i.e., a UML::InstanceSpecifications) and that the slots of this link instance refer to the distinguished UML::InstanceSpecifications corresponding to the instances of the stereotypes related via such a link.

    The problem is that the UML specification (2.4 and 2.5) does not say how to serialize such links.

    This is something that caused me a lot of headaches when producing the XMI for SysML 1.3.
    Because the ISO-80000-1-SysML.xmi and ISO-80000-1-QUDV.xmi are libraries, there will be references to elements defined in them.
    Since the SysML profile has associations between Unit & QuantityKind, it means that we should be able to externally refer to particular links between particular instances of Unit & QuantityKind.

    I tried to do this in 1.3 but I realize that I got it wrong, specifically, the slot values refer to the UML elements representing Unit and QuantityKind when in fact they should be referring to the distinguished UML::InstanceSpecifications representing the instances of Unit & QuantityKind (see in bold below):

    <packagedElement xmi:type="uml:InstanceSpecification"

    xmi:id="_ISO-80000-1-SysML_a_kilogram_u00255Bunit_u00255D_mass_u00255BquantityKind_u00255D_PackageableElement"

    name="a_kilogram[unit]_mass[quantityKind]">

    <classifier href="http://www.omg.org/spec/SysML/20120322/SysML.xmi#_SysML_Blocks_PackageableElement-A_unit_quantityKind_PackageableElement"/>

    <slot xmi:type="uml:Slot"

    xmi:id="ISO-80000-1-SysML_a_kilogram_u00255Bunit_u00255D_mass_u00255BquantityKind_u00255D_PackageableElement-slot_Slot._SysML_Blocks_PackageableElement-A_unit_quantityKind_PackageableElement-unit_Property">

    <definingFeature href="http://www.omg.org/spec/SysML/20120322/SysML.xmi#_SysML_Blocks_PackageableElement-A_unit_quantityKind_PackageableElement-unit_Property"/>

    <value xmi:type="uml:InstanceValue"

    xmi:id="ISO-80000-1-SysML_a_kilogram_u00255Bunit_u00255D_mass_u00255BquantityKind_u00255D_PackageableElement-slotSlot._SysML_Blocks_PackageableElement-A_unit_quantityKind_PackageableElement-unit_Property-value_ValueSpecification.0"

    instance="_ISO-80000-1-SysML_kilogram_PackageableElement"/>

    </slot>

    <slot xmi:type="uml:Slot"

    xmi:id="ISO-80000-1-SysML_a_kilogram_u00255Bunit_u00255D_mass_u00255BquantityKind_u00255D_PackageableElement-slot_Slot._SysML_Blocks_PackageableElement-Unit_PackageableElement-quantityKind_Property">

    <definingFeature href="http://www.omg.org/spec/SysML/20120322/SysML.xmi#_SysML_Blocks_PackageableElement-Unit_PackageableElement-quantityKind_Property"/>

    <value xmi:type="uml:InstanceValue"

    xmi:id="ISO-80000-1-SysML_a_kilogram_u00255Bunit_u00255D_mass_u00255BquantityKind_u00255D_PackageableElement-slotSlot._SysML_Blocks_PackageableElement-Unit_PackageableElement-quantityKind_Property-value_ValueSpecification.0"

    instance="_ISO-80000-1-SysML_mass_PackageableElement"/>

    </slot>

    </packagedElement>

    These should have been:

    <packagedElement xmi:type="uml:InstanceSpecification"

    xmi:id="_ISO-80000-1-SysML_a_kilogram_u00255Bunit_u00255D_mass_u00255BquantityKind_u00255D_PackageableElement"

    name="a_kilogram[unit]_mass[quantityKind]">

    <classifier href="http://www.omg.org/spec/SysML/20120322/SysML.xmi#_SysML_Blocks_PackageableElement-A_unit_quantityKind_PackageableElement"/>

    <slot xmi:type="uml:Slot"

    xmi:id="ISO-80000-1-SysML_a_kilogram_u00255Bunit_u00255D_mass_u00255BquantityKind_u00255D_PackageableElement-slot_Slot._SysML_Blocks_PackageableElement-A_unit_quantityKind_PackageableElement-unit_Property">

    <definingFeature href="http://www.omg.org/spec/SysML/20120322/SysML.xmi#_SysML_Blocks_PackageableElement-A_unit_quantityKind_PackageableElement-unit_Property"/>

    <value xmi:type="uml:InstanceValue"

    xmi:id="ISO-80000-1-SysML_a_kilogram_u00255Bunit_u00255D_mass_u00255BquantityKind_u00255D_PackageableElement-slotSlot._SysML_Blocks_PackageableElement-A_unit_quantityKind_PackageableElement-unit_Property-value_ValueSpecification.0"

    instance="ISO-80000-1-SysML_kilogram_PackageableElement-appliedStereotypeInstance_InstanceSpecification"/>

    </slot>

    <slot xmi:type="uml:Slot"

    xmi:id="ISO-80000-1-SysML_a_kilogram_u00255Bunit_u00255D_mass_u00255BquantityKind_u00255D_PackageableElement-slot_Slot._SysML_Blocks_PackageableElement-Unit_PackageableElement-quantityKind_Property">

    <definingFeature href="http://www.omg.org/spec/SysML/20120322/SysML.xmi#_SysML_Blocks_PackageableElement-Unit_PackageableElement-quantityKind_Property"/>

    <value xmi:type="uml:InstanceValue"

    xmi:id="ISO-80000-1-SysML_a_kilogram_u00255Bunit_u00255D_mass_u00255BquantityKind_u00255D_PackageableElement-slotSlot._SysML_Blocks_PackageableElement-Unit_PackageableElement-quantityKind_Property-value_ValueSpecification.0"

    instance="ISO-80000-1-SysML_mass_PackageableElement-appliedStereotypeInstance_InstanceSpecification"/>

    </slot>

    </packagedElement>

    Point #3) There is no crossing of metalevels in SysML's ValueType (extension of UML::DataType) associated to stereotypes extending UML::InstanceSpecification (Unit, QuantityKind)

    In practice, it means that if we defined, say, "MassInKilograms", a UML::DataType and applied SysML::ValueType to it, we would have something like this:

    <packagedElement xmi:type="uml:DataType"

    xmi:id="123"

    name="MassInKilograms"/>

    <sysml:ValueType xmi:id="456" base_DataType="123"

    unit="ISO-80000-1-SysML_kilogram_PackageableElement-appliedStereotypeInstance_InstanceSpecification"

    quantityKind="ISO-80000-1-SysML_mass_PackageableElement-appliedStereotypeInstance_InstanceSpecification"/>

    And we should be able to explicitly create a link instance for the association between ValueType & Unit and its slots would refer to the distinguished UML::InstanceSpecifications corresponding to the stereotype instances thus related, I.e.:

    "456" and "ISO-80000-1-SysML_kilogram_PackageableElement-appliedStereotypeInstance_InstanceSpecification"

    Similarly, the link instance for the association between ValueType & QuantityKind would have as its slots the following:

    "456" and "ISO-80000-1-SysML_mass_PackageableElement-appliedStereotypeInstance_InstanceSpecification"

    The rationale for this point is that since stereotypes can participate in associations, it follows that instances of stereotypes can be linked via instances of such associations.

  • Reported: UML 2.5 — Mon, 27 Aug 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Relax Association::/endType from [1..*] to [0..*]

  • Key: UMLR-279
  • Legacy Issue Number: 18969
  • Status: open  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    An association could be defined with untyped association ends.

    UML2.5 currently prevents defining such associations.
    If it becomes well-formed in 2.6, this capability will be useful for the Precise Semantics of Composite Structures, particularly for untyped connectors.

  • Reported: UML 2.5 — Thu, 26 Sep 2013 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Problems with OCL definition of Package::makesVisible

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

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

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

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

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

    So here goes:

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

    Problem #1

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

    ei.importedElement = VisibilityKind::public

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

    ei.visibility= VisibilityKind::public

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

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

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

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

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

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

    packageImport->select(visibility = VisibilityKind::public)

    But the next part again makes no sense

    ...>collect(importedPackage.member>includes(el))->notEmpty()

    here expression part

    importedPackage.member->includes(el)

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

    ...>collect(importedPackage.member>includes(el))...

    is a collection of booleans (of the form:

    {false, false, true, false, true}

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

    Then it makes no sense to test that for emptiness:

    ->notEmpty()

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

    I think this passage should be restated as follows:

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

    I.e. we are iterating through all (public) package imports and checking whether element el appears among members
    of at least one of the imported packages.

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

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

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

  • Reported: UML 2.5 — Tue, 24 Sep 2013 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Specifying the multiplicity of a part with an attribute

  • Key: UMLR-274
  • Legacy Issue Number: 17536
  • Status: open  
  • Source: Lockheed Martin ( John Watson)
  • Summary:

    This is a request to add a capability in UML to specify the upper and/or lower multiplicity value of a part (composite aggregation relationship) with a class attribute of type integer; typically this attribute is a derived attribute. When derived, a constraint can be used to define the value derivation.

    This capability has been found to be useful in the following applications.
    1. When reference models are re-used in different contexts this capability allows some variants to be specified in the reference model and the value be automatically derived based on its use in the new context.
    2. The value of the multiplicity to be used for a specific configuration may be derived through an analysis performed external to the model.

    A diagram is available that shows an example of the concrete syntax that could be used. In this example a constraint is defined for the attribute “numberOfPedals”. If this diagram would be helpful and I can forward it. I did not see a means of attaching a jpg diagram to this on-line form.
    This capability can be developed in a way that does not impact on code generation or execution, as the values can all be constant at run time (and at code-generation time).
    The primary purpose of this is to allow the ability to have reference models for variations without using the overhead of templates (otherwise the whole model might need to be a template of template, which would certainly be unwieldy and confusing), and to allow for a common way of specifying this for descendant languages like SysML.

  • Reported: UML 2.5 — Thu, 2 Aug 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Link notation for stereotype property value

  • Key: UMLR-273
  • Legacy Issue Number: 17464
  • Status: open  
  • Source: PTC ( Mr. Simon Moore)
  • Summary:

    It would be very useful if a notation was defined to allow a stereotype instance property value which references another instance in the model to be shown as a link on a diagram.

    For example, a stereotype Foo could have a property Bar of type Foo (in order that one Foo can reference another Foo). On a diagram showing two instances of Foo, you could then add and show a link between them labelled Bar rather than only being allowed to use a compartment or callout note.

    This would be useful to many profiles, but I couldn't find an existing issue which covered it.

  • Reported: UML 2.5 — Mon, 2 Jul 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Generalization should be allowed to be cyclic and should no be restricted to be owned by the specialized classifier

  • Key: UMLR-272
  • Legacy Issue Number: 17393
  • Status: open  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    Currently, UML 2.4.1 requires that:
    The graph of classifier generalization relationships must be acyclic
    See 7.3.8 Classifier [2]

    Generalization hierarchies must be directed and acyclical. A classifier cannot be both a transitively general and
    transitively specific classifier of the same classifier.

    This constraint probably came from the influence of programming languages on the design of the UML.
    This constraint is certainly useful in many domain-specific applications of the UML but it is certainly not useful across all domains.
    For example, in ontologies, it is common practice to use circular generalization relationships among classifiers to express their semantic equivalence; see: http://www.w3.org/TR/owl2-syntax/#Equivalent_Classes
    The ODM 1.0 includes this approach as an option for using the UML as a notation for OWL1 ontologies — see 14.2.5.11 in http://www.omg.org/spec/ODM/1.0/
    A generalization must be owned by the specialized classifier
    See 7.3.20:

    specific: Classifier [1]
    References the specializing classifier in the Generalization relationship. Subsets DirectedRelationship::source and
    Element::owner

    This ownership constraint prevents using the UML where a generalization between A and B needs to be added without modifying A or B.

  • Reported: UML 2.5 — Fri, 27 Jun 2014 11:17 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Interaction.action should subset ownedMember in lieu of ownedElement

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

    In Figure 14.5 of UML 2.4.1 (and still valid for UML 2.5), the association end 'action' of Interaction subsets Element.ownedElement. Since Interaction is a Namespace and Action a NamedElement, I reckon it ought to subset Namespace.ownedMember instead.

  • Reported: UML 2.4.1 — Thu, 19 Apr 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Message Signature in Interactions and Reception.ownedParameter

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

    currently (till 2.5) a message's signature is of type NamedElement that
    resolves either to an Operation or Signal. Apart from the fact that the
    nearest common superclass is Namespace, the use of elements of different
    inheritance hierarchies makes it cumbersome/impractical to work with the
    signatures easily. You always have to check what concrete signature is
    associated, cast it into the appropriate subclass (i.e. either Signal or
    Operation) and use it further.

    Regarding Message::Signature, I was wondering, whether it wouldn't be
    simpler and far more consistent to refer to a BehavioralFeature
    (Operation/Reception which has to have an Signal associated) directly
    instead of NamedElement (which ought to be Namespace)?

    This leads to a situation where I was wondering why a Reception, though
    it is a BehavioralFeature, does not say any word about owned parameters
    at all? However, if Receptions would be able to capture information
    about parameter, too, the treatment of Reception and Operation would be
    pretty much the same with regard to their parameter semantics. So, it
    might be worth to reconsider the relationship between BehavioralFeature,
    Reception and Parameter. We could supplement

    BehavioralFeature::ownedParameter

    {ordered, subsets Namespace::ownedMember}

    containment

    with

    /Reception::ownedParameter [0..1]

    {redefines BehavioralFeature::ownedParameter }

    containment

    The derivation algorithm of Reception::ownedParameter could be similar
    to the following: A Reception declares at most one Parameter. Its type
    and name must exactly the name and type of the Signal, referenced by
    Reception::signal, if present. The direction kind of a Reception's
    Parameter must be set to IN exclusively.

    context Reception
    inv 'parameter':
    if not self.signal.oclIsUndefined then
    not self.ownedParameter.oclIsUndefined and
    self.ownedParameter.type = self.signal and self.ownedParameter.name =
    self.signal.name and self.ownedParameter.directionKind ==
    ParameterDirectionKind::IN
    else
    endif

    This would ease the usage of BehavioralFeatures a lot, I'd say. In case
    of Messages, one would only have to walk over
    Message::signature::parameter instead of casting it down to either an
    Operation or Signal..

  • Reported: UML 2.5 — Mon, 12 Mar 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Migrate UML::Component's ability to own UML::PackageableElements to UML::Class

  • Key: UMLR-271
  • Legacy Issue Number: 17390
  • Status: open  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    UML2.4.1 Superstructure, section 8.3, Figure 8.4 shows that UML::Component has a composite association to UML::PackageElement; that is:

    UML::Component::packagedElement : UML::PackageableElement

    { subsets UML::Namespace::ownedMember }

    This is the only place in the UML metamodel where a kind of UML::Classifier has the capability to own arbitrary kinds of UML::PackageableElements.

    As long as the classifier capabilities needed in practice are within the scope of what UML::Class already provides, then it is practically very useful to use UML::Component in lieu of UML::Class.
    By doing so, a UML::Component-as-an-enhanced-UML::Class gains the capability to own additional kinds of UML::PackageElements that a plain UML::Class cannot; e.g.:

    UML::Package, UML::Dependency, UML::InformationFlow, UML::ValueSpecification, UML::InstanceSpecification, UML::Event, UML::Observation, UML::Profile, UML::Model.

    Unfortunately, other kinds of UML::Class do not get such benefits. For example, a UML::StateMachine is a kind of UML::Class just like UML::Component but unlike UML::Component, it can't own arbitrary UML::PackageableElements.
    In particular, it cannot own any UML::Event even though this would make eminent sense in some cases (e.g., internal events not visible outside of the UML::StateMachine).

    Finally, the well-formedness and semantics of a kind of UML::Class with namespace-nested UML::PackageableElements need to be addressed for unusual combinations including but not necessarily limited to the following cases:

    1) nested UML::Profiles and UML::ProfileApplications
    2) specialization of a general classifier nested within its packagedElements
    3) applying a stereotype defined in a UML::Profile nested within its packagedElements
    4) the target of an elementImport from a UML::Namespace nested within its packagedElements

  • Reported: UML 2.5 — Fri, 27 Jun 2014 11:17 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Semantic error in UMLAssociationOrConnectorOrLinkShape::edge_instancespec invariant

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

    The OCL in UMLDI for UMLAssociationOrConnectorOrLinkShape::edge_instancespec invariant at "memberEnd->includes(e.modelElement))" has a semantic error becuase e is already an Element.

    Suggest change "e.modelElement" to "e".

  • Reported: UML 2.5 — Fri, 27 Jun 2014 11:17 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Semantic error in Lifeline::interaction_uses_share_lifeline

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

    The OCL for Lifeline::interaction_uses_share_lifeline has a semantic error at "... implies usingInteraction.lifeline->select..." the RHS of implies is non-Boolean.

    Changing "select" to "exists" makes the semantic problem go away

  • Reported: UML 2.5 — Tue, 24 Sep 2013 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

XMI.xmi is not merged

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

    In UML 2.4.1 Infrastructure/Superstructure.xmi provided the raw Packages. XMI.xmi provided the merged packages so that in UML 2.4.1 we have uml::Association.

    UML 2.5 abandons the merge and so there is just XMI.xmi. uml::Association exists via an import, but the primary definition is now uml::StructuredClassifiers::Association.

    To preserve compatibility with the UML 2.4.1 metamodel, the unmerged packages could be provided in e.g. UMLPackages.xmi, with XMI.xmi providing the merged packages as before.

  • Reported: UML 2.5 — Tue, 1 Oct 2013 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

In the Use Case section, it is unclear whether a use case requires an actor

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

    In the Use Case section, it is unclear whether a use case requires an actor.

    For example, in 18.1.3 it says:

    “Each UseCase specifies some behavior that a subject can perform in collaboration with one or more Actors.” Which requires at least one actor per Use Case. However, the resolution for 18045 deleted “one or more” from earlier in 18.1.3

  • Reported: UML 2.5 — Fri, 11 Oct 2013 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

ExtensionEnd upper/lower inconsistent with MultiplicityElement

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

    Issue 13992 changes the cardinality of MultiplicityElement lower and upper. This was not tracked by ExtensionEnd, which consequently has validation errors.

  • Reported: UML 2.5 — Tue, 24 Sep 2013 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Lack of clarity about meaning of package shapes containing elements with fully qualified names

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

    The UML specification is not clear what it means for an element with a fully qualified name to appear within a package shape on a package diagram.

    7.3.37 says “The members of the package may be shown within the large rectangle”. So it seems to rest on the definition of members, which is the union of owned members and imported members.

    This is somewhat reinforced by “elements that become available for use in an importing package through a package import or element import may have a distinct color or be dimmed to indicate that they cannot be modified”. Note that the definition of ElementImport says “identifies an element in another package, and allows the element to be referenced using its name without a qualifier”. So we’d expect imported elements to be dimmed, but not have a name qualification (a poor user experience if I may say so).

    Subsidiary issue: Why does it say that they cannot be modified? This is a matter for tool implementers, and has no place in the UML spec.

    But elsewhere it says “The public contents of a package are always accessible outside the package through the use of qualified names”;

    So how should I interpret the appearance of an element shape within a package shape when the element has its fully-qualified name (as frequently appears in the UML spec itself)? Does this imply the existence of an import or not? According to “The public contents of a package are always accessible outside the package through the use of qualified names” no import is necessary; according to “The members of the package may be shown within the large rectangle” an import is necessary. At the very least this should be clarified.

    More deeply perhaps the issue is that the definition of the term “referencing an element” is very dubious. Does appearing on a diagram involve referencing? How about appearing in tool windows, type pickers, etc?

  • Reported: UML 2.5 — Mon, 9 Feb 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section 9.3.4 Collaboration Use, 2nd constraint creates unneces

  • Key: UMLR-158
  • Legacy Issue Number: 13452
  • Status: open  
  • Source: Dell Technologies ( Mr. George Ericson)
  • Summary:

    Assuming one Collaboration represents mandatory features and another Collaboration wants to extend that. It seems natural to express only the differences in the second Collaboration and to use roleBinding to between properties of the extending Collaboration to properties of a CollaborationUse of the first. The implication is that properties of the first collaboration are included as part of the second collaboration, since the CollaborationUse is essentially an instantiation of the first Collaboration in the context of the second. The roleBindings indicate were instances of the properties of first are constrained to be instances of the second Collaboration.

    This usage would require that the 2nd constraint be modified and that properties of the CollaborationUse of the first Collaboration are interpreted as being incorporated into the second Collaboration except when there is a roleBinding between the properties of the first and second Collaborations.

  • Reported: UML 2.5 — Fri, 30 Jan 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML: Standard Techniques to disambiguate crossing lines needed

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

    With the increasing use of UML and descendant languages (e.g.., SysML) for more complex diagramming situations, the occasion for crossing lines becomes increasingly hard to avoid. When such happens, it often becomes difficult to determine the correct start/destination of each line. This is compounded by the use of tree structures for the depicting of generalization and aggregation/composition relationships.

    Whenever two lines cross, there can ambiguity associated with the line path. The UML standard should supply a normative technique to resolve this ambiguity, The introduction of a “jog” - a small curve in one of the intersecting lines – has traditionally be acceptable.

    Proposed solution:

    In the diagram appendix, add a paragraph introducing the problem and recommending a standard graphical solution. A diagram may be useful to convey the intent.

    If a normative solution is not desired, the paragraph can recommend several selected approaches to resolve the disambiguities.

  • Reported: UML 2.5 — Wed, 24 Dec 2008 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

There is no way to specify the behavior of operations which are members of data types

  • Key: UMLR-152
  • Legacy Issue Number: 13165
  • Status: open  
  • Source: Anonymous
  • Summary:

    I would like to bring to your attention (as the contact person for the UML standard) a small bug we found with the UML specification: There is no way to specify the behavior of operations which are members of data types such as enumerations. Such operations can be modeled in UML, since each classifier can have operations, and this is useful to describe, e.g. Java enumeration operations. However, they cannot be assigned method behaviors, since nested behavior can only be added to classes.
    One solution to this would be allowing to nest classifiers in data types - i.e. to copy the association nestedClassifier: Classifier [*] to DataType (just as was done for case for ownedOperation : Operation [*]).

  • Reported: UML 2.5 — Thu, 18 Dec 2008 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML 2 - appearance of Association Ends as members of the related classes

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

    Since the dot notation was introduced to represent ownership of association ends separately from navigability, it appears that the following is the case: a navigable association end that is owned by the association does not appear in the namespace of the class from which it is navigable. How, then, can it be said to be navigable? I believe that all navigable ends should appear in the namespace of the class from which they are navigable, regardless of who owns the ends.

  • Reported: UML 2.5 — Tue, 3 Mar 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML2.2. Contradications in 14.3.10

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

    14.3.10: says “An ExecutionSpecification is a specification of the execution of a unit of behavior or action within the Lifeline. The duration of an ExecutionSpecification is represented by two ExecutionOccurrenceSpecifications, the start ExecutionOccurrenceSpecification and the finish ExecutionOccurrenceSpecification.” However slightly lower down it says “The trace semantics of Interactions merely see an Execution as the trace <start, finish>. There may be occurrences between these. Typically the start occurrence and the finish occurrence will represent OccurrenceSpecifications such as a receive OccurrenceSpecification (of a Message) and the send OccurrenceSpecification (of a reply Message).” These appear to be directly contradictory.

    Is it necessary for the start and finish occurrences of an ExecutionSpecification to be ExecutionOccurrenceSpecifications? Is it valid to have a MessageOccurrenceSpecification at the start and finish of an ExecutionSpecification? Is it valid to have both a MessageOccurrenceSpecification and an ExecutionOccurrenceSpecification representing the start/end of a ExecutionSpecification? Are Message reception and Execution commencement the same or different events?

    Also the multiplicity on the source (non-navigable) end of ExecutionOccurrenceSpecification.Execution is 1, which makes the model clearly invalid. I believe it should either be 2 or 0..2, depending on the answers to the questions above.

  • Reported: UML 2.5 — Mon, 2 Mar 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

we can create an invalid active state configuration

  • Key: UMLR-157
  • Legacy Issue Number: 13449
  • Status: open  
  • Source: International Business Machines ( Mr. Adam Neal)
  • Summary:

    The spec states: "An entry point pseudostate is an entry point of a state machine or composite state. In each region of the state machine or composite state it has a single transition to a vertex within the same region." This is slightly ambiguous as one could take it to mean that the region is the region who owns the target dirctly. This would allow one to create the case where we can create an invalid active state configuration. consider: S1's region1 owns S2 and S3 who both have sub verticies. An entry point on S1 should only be able to target one vertex with region1 (either a direct or deeply nested vertex), but not more then one. If the assumption by a user was made that both the verticies in S2 and S3 could be targeted (since they are owned by different regions) then the tooling would essentially be allowing concurrent entries into a single region. Where as, really we need to specify more along the lines of that the LCA region of the source and target may have at most a single transition. An entry point pseudostate is an entry point of a state machine or state. For each transition that targets a vertex in region R, there may not exist another transition targeting a vertex in region R nor any region contained within R. Also, given the alternate semantics of entering a state (that regions don't have to be entered and the state itself can remain active), entry points should not be required on composite states only. Connecting to an entry point with no outgoing transitions or to the state border itself should be considered semantically the same. One usecase for this is that users may define entry/exit code on the state itself to preform some basic behavior, but in redefined contexts want to enhance the behavior by continuing that transition to a sub vertex.

  • Reported: UML 2.2 — Fri, 6 Feb 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Concrete specialization of the Relationship meta-class are missing

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

    Concrete specialization of the Relationship meta-class are missing. Except few cases restricted to very specific usages (import/merge, association), and according to the current meta-model, all concrete instaciations of Relationship are Dependencies. This situation has an undesirable side-effect in UML models but also in some UML profiles like SysML and MARTE. Indeed, specialized or extended relationships like Deployment or Allocation generate unexpected dependencies between related elements. A solution might be to add a concrete (Directed)Relationship meta-class in the meta-model. The concept of "Allocation" is very generic and might provides that meta-class. It would be a convenient generalization for Deployment.

  • Reported: UML 2.2 — Fri, 27 Mar 2009 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML 2.2 InteractionOperand abstract syntax

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

    Section 14.3.16 says “An InteractionOperand is contained in a CombinedFragment.” Yet the abstract syntax figure 14.7 shows that an InteractionOperand may be contained by a CombinedFragment, or may (via inheritance) be owned by an InteractionOperand. These are inconsistent and the specification should make clear which is correct.

  • Reported: UML 2.5 — Mon, 9 Mar 2009 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML2: Unclear how to indicate what events a classifier might send

  • Key: UMLR-155
  • Legacy Issue Number: 13395
  • Status: open  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    UML2 has Receptions which can be included in realized/provided Interfaces to indicate what Signal events a Classifier is able to receive. But it isn't clear how a Classifier would indicate in its interfaces what events it might send/generate, and therefore what events a collaborating Classifier connected to this Classifier in some way would need to be prepared to handle.

    UML2 Reception semantics should be updated to indicate Receptions can appear in either Realized/provided or Usage/required Interfaces. A Reception in a required interface would indicate a signal event the owning classifier might send through a SendSignalAction or BroadcastSignalAction. This would provide all the interface information needed on both sides of a connector to know what SignalEvents might be sent and/or received

  • Reported: UML 2.5 — Fri, 30 Jan 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML2.2 RTF: EnumerationLiteral is a DeploymentTarget

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

    EnumerationLiteral is an InstanceSpecification; InstanceSpecification is a DeploymentTarget. This makes EnumerationLiteral a DeploymentTarget, which is clearly nonsense.

    I strongly question both of these inheritance relationships

  • Reported: UML 2.5 — Wed, 14 Jan 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section: 9.3.11 Port

  • Key: UMLR-162
  • Legacy Issue Number: 13657
  • Status: open  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    Specification: UML 2.2 Beta1 (2008/05/01)

    Section: 9.3.11 Port

    Summary:

    Consider the MARTE2 FTF proposal developed in the resolution to MARTE issue 11820 in the scope of the tactical resolutions being developed for clauses 8 and 9 of the UML superstructure specification for the UML 2.3 RTF.

    The MARTE resolution to issue 11820 attached is available in ballot1 of the MARTE2 FTF as “issue11820 resolved.doc” here:

    http://www.omgwiki.org/marte-ftf2/doku.php?id=marte_ftf2_ballot_1

  • Reported: UML 2.5 — Tue, 3 Mar 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section: 7.3.9 Comment should be NamedElement

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

    I propose to define the Comment as a NamedElement instead of Element. The SysML and UPDM working groups identified that it is necessary that comment based model elements have a name, could be packaged and identified.

  • Reported: UML 2.2 — Tue, 3 Feb 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

MARTE/section 7.2.1/ "several labels for the same classifiers in the Metamodel" bug

  • Key: UMLR-151
  • Legacy Issue Number: 13088
  • Status: open  
  • Source: INRIA ( Pierre Boulet)
  • Summary:

    Using the profile, an element can have several stereotypes. However, in
    the metamodel, an element can not have several labels traducing these
    stereotypes. A traduction in the metamodel of this kind of element
    (stereotyped several times) can not be made.

  • Reported: UML 2.5 — Fri, 26 Sep 2008 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section: 16.3.5

  • Key: UMLR-122
  • Legacy Issue Number: 11307
  • Status: open  
  • Source: 4Soft GmbH ( Klaus Bergner)
  • Summary:

    The Description section states: "Note that the included use case is not optional, and is always required for the including use case to execute correctly." This is often understood as stating that the behavior of an included use case has to be executed during every execution of the behavior of the including use case. Example: The following informal use case fragment contains a conditional call of an included use case: Step x: If the user choses to print the reports, <<include>> the use case "Print reports". With the understanding given above, this use case fragment would be invalid (at least if the included use case is not included elsewhere in the including use case). In a similar vein, the Semantics section states: "All of the behavior of the included use case is executed at a single location in the included use case before execution of the including use case is resumed." Besides the obvious error (the sentence should say: "... is executed at a single location in the including use case ..."), this is sometimes understood as stating that the behavior of the included use case must be executed exactly once during the execution of the including use case. Another (equally wrong) interpretation would be that the included use case must be included exactly once in the use case specification (implying, for example, that there must not be two lines in the same textual use case specification containing an <<include>> directive for a certain use case). Both sections should be clarified, clearly stating that: - The behavior specification of the including use case may include an included use case multiply (although this is represented by a single include relationship in the use case diagram). Analogy: A routine that contains multiple calls to a subroutine in its source code. - The including use case is responsible for calling the included use case. It may choose to call it once, repeatedly, or not at all. Analogy: A routine with conditional execution paths or iterative behavior, performing subroutine calls conditionally or iteratively. Proposal for changing the sentence in the Description section: "Note that the included use case is not optional, and is always required for the including use case to be fully specified. The behavior specification of the including use case may include an included use case multiply (although this is represented by a single include relationship in the use case diagram)." Proposal for a change and an addition in the Semantics section: "All of the behavior of the included use case is executed in the including use case before execution of the including use case is resumed. Depending on behavior of the including use case, the included use case may be called once, multiple times or not at all." I would be very pleased to receive a first, quick reply by mail.

  • Reported: UML 2.1.1 — Mon, 27 Aug 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section: 7.3.3

  • Key: UMLR-121
  • Legacy Issue Number: 11287
  • Status: open  
  • Source: Petersen Enterprises ( Sören Petersen)
  • Summary:

    There is actually two closely related issues I would like to report. One is an (as I understand it) error related to figure 7.20 and the other is a humble request to enhance the documentation by more explicitly clarifying the semantics of association ends that are owned by an end class. Starting with the (possible) error. According to the specification (page 39) "An end property of an association that is owned by an end class or [...] is navigable from the opposite ends; [...]" Somewhat further down in the text there is a statement saying (page 43) "Aggregation type, navigability, and end ownership are orthogonal concepts [...]" Although this may be true in terms of notation, it is clear from the first citation (and common sense) that navigability and end ownership cannot be conceptually orthogonal. Moving on to figure 7.20, the first relation demonstrates this supposed orthogonality by showing a relation where the end connected to B is owned by A, but not navigable from A. I understand that this part might have been written with notation in mind; to demonstrate the orthogonality of the notational elements. It might, however, be considered bad practice to show notational examples that are inconsistent with the rest of the specification. The second "issue" is related to the concept of a property that is an association end owned by an end class. It took me quite some time and a lot of re-reading to understand that the "end class" was a of a different type than the type of the property. The only real hint about this was the last statement on a paragraph in on page 42 (in the notation section) stating that "This property is owned by the classifier at the other end." Since the whole concept of ownership seems a little vague, it might be a good idea to include a paragraph detailing this fact in the description of the semantics of associations. I hope this might be of some use.

  • Reported: UML 2.5 — Tue, 21 Aug 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Figure 7.48 and the accompanying discussion under 7.3.21

  • Key: UMLR-126
  • Legacy Issue Number: 11807
  • Status: open  
  • Source: Duke University ( John Madden)
  • Summary:

    Figure 7.48 and the accompanying discussion under 7.3.21 GeneralizationSet>Examples on pp 78-79 uses the example of a generalization set consisting of a single class to explain the proper use of the isCovering and isDisjoint attributes. I believe this example is infelicitous in the context of this exposition because generalization sets consisting of a single class present a special case, and this detracts from the exposition. In what way are they a special case? IF (a generalization set consists of a single class AND it is

    {incomplete}) THEN it can only be {disjoint}. This is because if the complement of an {incomplete}

    generalization set is non-empty, and consists of all instances that are NOT members of the solitary class in the generalization set. In other words, for a generalization set consisting of a single class, the combination

    {incomplete, overlapping}

    is self-contradictory. IF (a generalization set consists of a single class AND it is

    {complete}) THEN it can only be {overlapping}. This is because the complement of a {complete}

    generalization set is the null set, and the null set is a member of every set. In other words, the combination

    {complete, disjoint}

    is self-contradictory. I would recommend pointing out that generalization sets consisting of a single class represent a special case, and I would treat them separately (?footnote). For purposes of the exposition, I would modify Figure 7.48 to include at least two classes (perhaps Employee, Manager) instead of just Employee in the right-hand generalization set.

  • Reported: UML 2.1.1 — Sun, 9 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

simpleTime package problems

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

    We are experiencing problems with elements of simpleTime Package.
    TimeExpression, Duration, TimeEvent and Observation owners are not defined. The only possible owner becomes Package.
    If TimeConststraints or DurationConstraints are used in SequenceDiagram, these multiple small elements could be added just into nearest Package (second level owner of Interaction). In real world packages could contain hundreds of Classes with defined behaviors, so hundreds of TimeExpression, Duration, TimeEvent and Observation elements appears in the root of such package (together with thousands of events from MessageEnds).

  • Reported: UML 2.5 — Fri, 14 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section: 7.3.37 Package (from Kernel)

  • Key: UMLR-124
  • Legacy Issue Number: 11342
  • Status: open  
  • Source: Mid GmbH ( Joachim Back)
  • Summary:

    The type of association 'packageMerge' is shown as 'Package'. In contradiction to this is the describing text of this association and the Figure 7.14 on p. 34 showing that the association 'packageMerge' is from 'Package' to 'PackageMerge'. Correct in chapter '7.3.37 Package (from Kernel)' the type of association 'packageMerge' from 'Package' to 'PackageMerge'.

  • Reported: UML 2.1.1 — Wed, 12 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML2 Property collaborationRole should be removed

  • Key: UMLR-123
  • Legacy Issue Number: 11323
  • Status: open  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    The collaborationRole property of Collaboration does not appear to be needed and could be removed. A Collaboration's ownedAttributes subsets inherited derived union role, and therefore represent the roles in a Collaboration. Since Property is extended to be a ConnectableElement, collaborationRole is redundant with ownedAttributes. In addition, the description does not seem to make sense. A collaborationRole can't reference connectable elements (possibly contained in another classifier) because the roles of a Collaboration must be parts or ownedAttributes of that Collaboration. The roleBindings of a CollaborationUse bind the roles of its Collaboration type to parts of some other classifier.

    However, there could be another interpretation of collaborationRole. If Collaborations are used to represent patterns, then a Collaboration's ownedAttributes may represent the common part of the pattern while the collaborationRoles represent the variable part. Instantiating the pattern with a CollaborationUse may then mean that the Classifier owning the CollaborationUse would need to directly contain the common parts (copies of them from the collaboration), and require roleBindings to the variable parts. In this case, collaborationRole parts would require bindings (and therefore subclass role) while ownedAttributes don't (and wouldn't subclass role)?

    In any case, the purpose of property collaborationRole is unclear and should be amplified in the specification to distinguish it from ownedAttributes and how it should be used.

  • Reported: UML 2.5 — Thu, 30 Aug 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML2 Issue: notation for Literals does not allow for name

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

    Literals e.g. LiteralString are NamedElements but the notation does not allow for specifying the name.

  • Reported: UML 2.5 — Mon, 17 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section: 14.4

  • Key: UMLR-127
  • Legacy Issue Number: 11815
  • Status: open  
  • Source: Validas AG ( Reinhard Jeschull)
  • Summary:

    Our company uses UML 2.1 for model driven architecture. We are now at the point, where we need interaction overview diagrams (like the example on figure 14.28 on page 530). So, we searched the UML elements that are used in this diagram: ControlFlow, InteractionUse, InitialNode, ActivityFinalNode, ... Then, we tried to combine them via the metamodel to have a little class diagram which shows us the connections of the elements (for example ControlFlow has source and target to ActivityNode). But there is one problem: We can't find a way to add the InteractionUse in this diagram. It seems, that a ControlFlow isn't able to have an InteractionUse on one of its ends. Can you tell us, how the InteractionUse can be used correctly (so we can use it for XMI-export)? Thank you in advance. We look forward to hearing from you.

  • Reported: UML 2.5 — Thu, 13 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

should be able to show gates on communication diagrams

  • Key: UMLR-130
  • Legacy Issue Number: 12166
  • Status: open  
  • Source: Anonymous
  • Summary:

    In the 2.1.1 specification (070205):

    Although the superstructure specification does not mention it, I believe that we should be able to show gates on communication diagrams.
    Gates are not connectable elements so we cannot attach connectors to them. How then would we show message pathways (connectors) to the represented lifeline on the communication diagram? Gates don't "represent" connectable elements as lifelines do.

    I would like to request clarification on this point.

  • Reported: UML 2.5 — Tue, 8 Jan 2008 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

pull semantics are only supported on Action inputs, not outputs

  • Key: UMLR-129
  • Legacy Issue Number: 12162
  • Status: open  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    pull semantics are only supported on Action inputs, not outputs. There is currently no ActionOutput having a toAction: Action Property allowing action output pins to refer and write to parameters, variables or structural features. Either UML2 should include ActionOutputPin, or remove ActionInputPin and allow a Pin to have an optional action: Action [0..1].

  • Reported: UML 2.5 — Mon, 7 Jan 2008 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

new constraint ?

  • Key: UMLR-135
  • Legacy Issue Number: 12274
  • Status: open  
  • Source: Eclipse Foundation ( Mr. Kenneth Hussey)
  • Summary:

    Should there be a constraint ensuring that named elements with private visibility cannot be accessed outside their owning namespace? For example, the type of a property should not be a private member of a namespace outside of its namespace hierarchy…

  • Reported: UML 2.5 — Tue, 11 Mar 2008 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section 7.3.44

  • Key: UMLR-134
  • Legacy Issue Number: 12272
  • Status: open  
  • Source: OFFIS e.V. ( Christian Mrugalla)
  • Summary:

    The metaclasses 'Attribute' and 'AssociationEnd' (defined in UML 1.x) are merged in the metaclass 'Property' in UML 2.x. But the terms 'attribute' and 'association end' are still used in the standard, based one the two possible Property-containments (Property owned by a 'Class' respectively by an 'Association'). In addition, a semantic for the different values of the meta-property 'aggregation' is only defined for a 'Property' of style 'association end'. I propose to re-introduce the metaclasses 'Attribute' and 'AssociationEnd' as specializations of 'Property', making 'Property' an abstract class (the meta-property 'aggregation' should be then moved to AssociationEnd).

  • Reported: UML 2.1.2 — Wed, 12 Mar 2008 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML 2 has lost cability to represent operations by collaborations

  • Key: UMLR-132
  • Legacy Issue Number: 12203
  • Status: open  
  • Source: Missouri University of Science and Technology ( Thomas Weigert)
  • Summary:

    It appears that UML 2 has lost the ability to represent operations by collaborations. (There the collaboration related the parameters of the operation as roles.) Now a collaboration use can only be owned by a classifier. A behavior could still be explained by an operation, but not an operation. If this is desired, the references to operations owning collaboration uses need to be purged. Otherwise it has to be fixed that operations can own collaboration uses.

  • Reported: UML 2.1.2 — Thu, 31 Jan 2008 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML 2: Need an explicit listing of all semantic variation points

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

    A readily accessible list of all semantic variation points in the UML superstructure. It should probably be a separate appendix for easy reference and maintenance.

  • Reported: UML 2.5 — Thu, 24 Jan 2008 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section: 7.3.41

  • Key: UMLR-133
  • Legacy Issue Number: 12267
  • Status: open  
  • Source: OFFIS e.V. ( Christian Mrugalla)
  • Summary:

    The last sentence of the Semantics definition for Parameter is: "If the behavioral feature is an operation, then the type and multiplicity of this parameter is the same as the type and multiplicity of the operation itself.". The multiplicity of an operation is not defined in the standard: Operation does neither inherit from MultiplicityElement, nor has it an element called 'multiplicity'. Proposed resolution: Replace this sentence by: "If the behavioral feature is an operation, then the type of this parameter is the same as the type of the operation itself

  • Reported: UML 2.1.2 — Mon, 10 Mar 2008 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

No notation for associating Exceptions with Operations

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

    In UML2, exceptions are represented as Types associated with an Operation via the multivalued raisedException property. The types have names and possibly structure (e.g. holding details of an error) and may use inheritance. However there is no notation defined for actually modeling Types associated with Operations as raisedExceptions.

  • Reported: UML 2.5 — Thu, 8 Dec 2005 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page: 107

  • Key: UMLR-75
  • Legacy Issue Number: 9145
  • Status: open  
  • Source: University College London ( James Skene)
  • Summary:

    I'm attempting to implement a JMI repository for the UML2 superstructure. This is made more difficult by the use of package merge in the model. The following issues should be clarified in the definition of package merge: 1. Do classifiers in the resulting package extend classifiers in the merged package? If they do: The meta-model must contain all infrastructure packages and extension packages defined in the superstructure spec e.g. 'ProtocolStateMachines', 'PackagingComponents' etc., in order to facilitate reflective access to instances of types defined in these packages. However, these packages are not collected in one or more sensible enclosing namespaces (e.g. root 'infrastructure' and 'superstructure' packages), so the root namespace will be cluttered. Root packages for these elements should therefore be introduced in the infrastructure and superstructure specifications. If they do not: Some infrastructure packages will still be needed in the resulting meta-model, because the infrastructure specification uses import + generalisation rather than merge to establish the relationships between packages, e.g. in core::abstractions. For conformance level 0, instances of types in package UML would therefore not be instances of types in core::basic, because this package is merged into UML. However, they would be instances of types in other infrastructure packages, e.g. core::abstractions::elements::Element, because core::basic imports this type, rather than merging it. This seems illogical. Why should core::abstractions::elements have instances in this case, but not core::basic? This could be corrected by using merge in the infrastructure spec, hence avoiding dragging imports into the UML package. However, using merge in this way means redefining the semantics for each copy of the same type, which is why there is so much unnecessary duplication in the infrastructure and superstructure specs. In both interpretations of merge, infrastructure classes and packages penetrate the UML meta-model, leading to a lack of good namespace organisation. This has an impact on the ease with which reflection can be used in the repository. 2. On page 107 the specification states that the use of explicit merges and pre-applied merges in a meta-model is equivalent with regards to the semantics of the meta-model. This is false when reflection is considered, as the meta-model retreived by reflective methods will be different depending on the approach taken. This is significant: To retrieve all features of a classifier where merge has been used in the meta-model, you need not only to recurse the generalisation hierarchy, but also the package containment hierarchy to determine if any containing package is the recipient of a merge that could modify the features of the classifier. This is highly inconvenient. My recommendation to address these problems is that classifiers in a package that is the recipient of a merge should be defined to generalise matching types in the merged package. The package structure of the infrastructure and superstructure specifications should be revised to reflect the fact that most packages and types defined in the specification will therefore be retained in any UML2 specification. Alternatively, use merge rather than import in the infrastructure specification, with the prescription that meta-models accessed by reflection must have the merges rolled out. Also therefore provide explicit documentation of the rolled out meta-models for the various conformance levels for the superstructure.

  • Reported: UML 2.0 — Thu, 10 Nov 2005 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section: 7.3.9

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

    I propose an optional enhancement of the comment symbol: It is possible to draw a small circle at the end of the anchor line. That way it is easier to read a diagram if the anchor line crosses other dependency lines. The small circle is already used in several diagrams. It is part of the famous Visio stencil of Pavel Hruby.

  • Reported: UML 2.1 — Fri, 27 Jun 2014 11:17 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

consistent ordering of Association::memberEnd and ownedEnd

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

    Given that these are both

    {ordered}

    , indicating that ordering is important, then it seems only sensible that the ordering should be consistent, i.e. if Property p appears before Property q in memberEnd then that should also be the case for ownedEnd.
    There should therefore be a constraint added to this effect.

    There should probably also be a review of other cases where an ordered Property subsets another ordered property.
    Or should there be a more general constraint defined at the meta-level?

  • Reported: UML 2.5 — Tue, 31 Jan 2006 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

No ReadParameterAction or WriteParameterAction

  • Key: UMLR-77
  • Legacy Issue Number: 9247
  • Status: open  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    One difference between UML activity and BPEL process is that all
    data flows in UML must be explicit through connections between
    activity parameter nodes, pins, central buffer nodes, and/or data
    store nodes. UML activities can also have structural features and
    variables which allow data to be passed between actions without
    object flows, corresponding more like BPEL variable references.

    However, input and output parameters have no such indirect access.
    All actions that need information from parameters have to be
    connected through object flows. This is inconsistent and can lead to
    complex activity models because of the need for a large number of
    ForkNodes and ObjectFlows in order to access Activity parameters.

    UML2 should support actions to read and write parameters similar to
    reading and writing variables. The ActinInputPins can be used to
    simplify parameters in activities.

  • Reported: UML 2.5 — Wed, 18 Jan 2006 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Need more flexible notation for activity partitions

  • Key: UMLR-74
  • Legacy Issue Number: 9124
  • Status: open  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    Activity diagrams currently support two notation styles for denoting membership in a partition: horizontal or vertical, and possibly nested "swimlanes" and a parenthesized list of partition names displayed above an activity node. These notation styles are adequate in many cases, but can result in diagrams that are either difficult to layout or don't sufficiently display relationships between nodes that are in the same partition. In addition, control nodes often shouldn't belong to any partition at all, but may need to be displayed in a partition with adjoining nodes for diagram layout purposes. In this case, apparent inclusion in the partition on the diagram should not necessarily imply membership in the partition.

    One way to address these issues would be to include additional notation styles for partitions. For example, a partitions could be displayed as in concentric, overlapping circles, ovals, or rounded rectangles with activity nodes in the partitions displayed inside the partition shape. The same partition could be displayed many times on the same diagram allowing separation of members in the partition for diagram layout purposes.

    Control nodes often connect activity nodes across partitions and can have a strong influence on diagram layout. Having control nodes treated like other activity nodes in partitions can result in overly restrictive layout constraints, or accidental modification of the activity model for diagram layout purposes. For control nodes, perhaps the default should be that they are not placed in partitions unless explicitly stated by some tool action, and they could have a more restricted notation, such as requiring the parenthesized list only. This would allow control nodes to be freely interspersed between elements in a partition without necessarily belonging to that partition and keep diagram layout concerns from accidentally modifying the underlying activity model.

  • Reported: UML 2.5 — Fri, 28 Oct 2005 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML2 Super / 14.3.13 Interaction

  • Key: UMLR-69
  • Legacy Issue Number: 8975
  • Status: open  
  • Source: MID GmbH ( Mr. Detlef Peters)
  • Summary:

    Chapter 14.3.13 states on p. 526 that "Interactions are units of behavior of an enclosing Classifier. Interactions focus on the passing of information with
    Messages between the ConnectableElements of the Classifier." From chapter 9.3.13, it is obvious that only StructuredClassifiers can have such ConnectableElements. Additionally, chapter 13.3.2 states that the context of a Behavior is a BehavioredClassifier. When looking at the Classifier Hierarchy in Appendix F of the Spec, you will find a single Element which is a BehavioredClassifier, but not a StructuredClassifier: the UseCase.
    This is where the problems start.
    A UseCase is not allowed to have properties at all, but may be the owner of an Interaction. Consequently, with the current version of the Spec, an Interaction owned by a UseCase may never have any Lifeline at all!

    Proposed Resolution:
    Redefine the Association Behavior::context: BehavioredClassifier[0..1] to Interaction::context: StructuredClassifier, replace all occurrences of 'BehavioredClassifier' in the description by 'StructuredClassifier'
    It should still be possible that a UseCase is the owner of the Interation, but the determination of the Interaction's context would be much clearer.

  • Reported: UML 2.5 — Thu, 25 Aug 2005 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section: Classes

  • Key: UMLR-70
  • Legacy Issue Number: 9008
  • Status: open  
  • Source: Thematix Partners LLC ( Mrs. Elisa F. Kendall)
  • Summary:

    In Classes, Association, Semantics says: "Subsetting represents the familiar set-theoretic concept. It is applicable to the collections represented by association ends, not the association itself." and "Specialization is, in contrast to subsetting, a relationship in the domain of intensional semantics, which is to say it characterized the criteria whereby membership in the collection is defined, not by the membership. One classifier may specialize another by adding or redefining features; a set cannot specialize another set. A naive but popular and useful view has it that as the classifier becomes more specialized, the extent of the collection(s) of classified objects narrows. In the case of associations, subsetting ends, according to this view, correlates positively with specializing the association. This view falls down because it ignores the case of classifiers which, for whatever reason, denote the empty set. Adding new criteria for membership does not narrow the extent if the classifier already has a null denotation." ISSUE: It is the semantics of Generalization in UML is that all the instances of the subtype are instances of the supertype, so subtyping in UML implies subsetting. It is not necessarily proper subsetting, however, as the example above shows. Subsetting in UML can be achieved by subtyping (adding attributes, etc), but can only be done by adding constraints to the subtype. Also, for association classes, the user should be able to specialize an association class with another association class with the same semantics as subsetting ends.

  • Reported: UML 2.0 — Sun, 25 Sep 2005 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Syntax of Transition

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

    Syntax of Transition is described as:
    " <transition> ::= <trigger> [‘,’ <trigger>]* [‘[‘ <guard-constraint>’]’] [‘/’ <activity-expression>]

    The behavior expression may be an action sequence comprising a number of distinct actions including actions that explicitly

    generate events, such as sending signals or invoking operations."

    Information from this expression (operation call for example) can't be mapped and saved into model.

  • Reported: UML 2.5 — Mon, 20 Jun 2005 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

OutputPin

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

    OutputPin should hold output value, but there is no way to store it. Should be introduced similar metaclass like ValuePin for InputPin

  • Reported: UML 2.5 — Mon, 20 Jun 2005 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page: 492-493

  • Key: UMLR-73
  • Legacy Issue Number: 9111
  • Status: open  
  • Source: Universita di Torino ( Simona)
  • Summary:

    Hello, it is not clear to me whether it is still possible in UML2.0 to specify in interaction diagram (either sequence or communication) broadcast actions and lifeline representing multi-object. Figures Fig.14.22 and 14.23 (Superstructure 05-07-04), actually show the possibility of representing instances of the same type (class B) each one represented by a different lifeline: the selectors in that case are used to identify one specific instance and not a set of instances. Regards, Simona Bernardi

  • Reported: UML 2.5 — Mon, 24 Oct 2005 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section: Classes

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

    Classes should be able to support interfaces without being a BehavioredClassier (see figure 16). This introduces an unnecessary dependency of Classes on CommonBehavior

  • Reported: UML 2.0 — Sun, 25 Sep 2005 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section: Activities

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

    What is the effect of unique association ends the actions for creating and deleting links? For example, what if one end is unique and the other not?

  • Reported: UML 2.0 — Sun, 25 Sep 2005 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Properties on Association for end objects

  • Key: UMLR-40
  • Legacy Issue Number: 8077
  • Status: open  
  • Source: Thematix Partners LLC ( Mr. Roger Burkhart)
  • Summary:

    The memberEnd/ownedEnd/NavigableOwnedEnd properties of Association represent the navigations from one end object to other end objects along the association. There are no properties available for navigating from an instance of an association (link) to the end objects. This has a number of negative effects: - The model cannot represent structured associations properly, because association classes that are also structured classifiers cannot have connectors to end objects, because the end objects cannot be reached with StructuredClassifier.role (see constraint 3 on Connector). - An InstanceSpecification for link can use memberEnd properties of association as properties of the link, even though these properties are ownedAttribute of the end classes, rather than the association. This is due to the loose definition of Classifier.allFeatures. - A special action is needed to retrieve (the end objects of links (ReadLinkObjectEndAction), rather than (using the action for attribute values ReadStructuralFeatureAction. The metamodel should have an association for properties that have the end objects of link objects as values.

  • Reported: UML 2.0 — Wed, 5 Jan 2005 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Notation for classifierBehavior

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

    Need a notation for instances of the classifierBehavior metaassociation (Figure 311).

  • Reported: UML 2.0 — Thu, 30 Dec 2004 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Contextualized attribute values Figures 121

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

    Contextualized attribute values Figures 121 is an unworkable solution to defining contextualized attribute values. It requires restating all the parts and connectors in the composite class, otherwise the constructor would be incomplete. The class-based solution requires separate properties for each contextualized value with connectors to them from the contextualized property. The metamodel should be extended to include contextualized datatype properties, or at least a presentation option for the current cumbersome model (see Figure 12 and discussion in http://www.jot.fm/issues/issue_2004_11/column5

  • Reported: UML 2.0 — Thu, 30 Dec 2004 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

ReadStructuralFeatureAction

  • Key: UMLR-42
  • Legacy Issue Number: 8335
  • Status: open  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Chokri Mraidha)
  • Summary:

    This issue concerns the ReadStructuralFeatureAction. This action reads the values of a structural feature, in order if the structural feature is ordered. According to the sepcification, the multiplicity of the structural feature must be compatible with the multiplicity of the output pin, so the output pin will contain all the values of the structural feature. There is no way to read the value of a single element from a multi-valued structural feature without reading all its values. Adding an input pin (readAt) to ReadStructuralFeatureAction would allow this. This input pin would represent the index of the value we want to read in the structural feature. This issue stands for ReadVariableAction as well.

  • Reported: UML 2.0 — Thu, 24 Feb 2005 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section: Classes, Behavior

  • Key: UMLR-34
  • Legacy Issue Number: 8012
  • Status: open  
  • Source: gmail.com ( Guus Ramackers)
  • Summary:

    There doe snot appear to be a way to model parameters to operations that are multi-dimensional arrays. In general, such arrays can be modeled based on qualifiers. However, this assumes that there is an association between two Classifiers. This doesn't apply to parameters. Note that Parameters are MultiplicityElements, but that only allows the modeling of single dimensions.

  • Reported: UML 2.0 — Wed, 29 Dec 2004 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

End objects of a link In the semantics of AssociationClass

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

    End objects of a link In the semantics of AssociationClass, it says: It should be noted that in an instance of an association class, there is only one instance of the associated classifiers at each end , i.e. from the instance point of view, the multiplicity of the associations ends are "1". Two comments: - This is applicable to Association generally. - The portion after "i.e" is misleding. Instances have no multiplicity.

  • Reported: UML 2.0 — Thu, 30 Dec 2004 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Action for retrieving activity instance

  • Key: UMLR-36
  • Legacy Issue Number: 8016
  • Status: open  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    Action for retrieving activity instance: There should be an action for getting the instance of the activity class currently executing, for reflective applications.

  • Reported: UML 2.0 — Thu, 30 Dec 2004 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Activities section

  • Key: UMLR-44
  • Legacy Issue Number: 8473
  • Status: open  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    Add presentation option for multiple object flows between two actions, shown as one line.

  • Reported: UML 2.0 — Sun, 6 Mar 2005 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section: 16.3.1

  • Key: UMLR-43
  • Legacy Issue Number: 8464
  • Status: open  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Delete sub-sections Attributes and Rationale as there are none. I question, in light of Constraint [1] and the second paragraph in sub-section Semantics, that there are no associations for an actor. Both constraint [1] and Semantics clearly indicate that there are associations and the Semantics paragraph even indicates multiplicity possibilities greater than one. Figure 401 shows no navigability and association between UseCase and Actor although both Constraint [1] and Semantics indicate that there should be some. Typo - There are eleven "(" but only ten ")" in constraint [1]. Personal preference - Restate Changes from previous UML to "The additon of the constraint that requires that all actors must have names has been added."

  • Reported: UML 2.0 — Fri, 4 Mar 2005 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Add constraints on ConditionalNode

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

    Add constraints on ConditionalNode to ensure the test and body are owned by the conditional node (or have them owned by the clause with body outputs being referred to by a single clause. This would prevent sharing bodies across clauses It is unclear if this is much of a benefit, since changing the body of one clause will change another, which may not be the intention.).

  • Reported: UML 2.0 — Sun, 6 Mar 2005 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

ExpansionRegion (behavior in the shorthand notation)

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

    In ExpansionRegion, clarify that the behavior in the shorthand notation must have exactly one return parameter

  • Reported: UML 2.0 — Sun, 6 Mar 2005 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section: Activities : Why is exception type needed?

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

    Add constraint in ExceptionHandler that exception type must be compatible with the exception handler input. Why is exception type needed?

  • Reported: UML 2.0 — Sun, 6 Mar 2005 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section: Activities - clarification

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

    Clarify the constraints on ExceptionHandler, that results must be output pins introduced on structured nodes in CompleteStructuredActivities.

  • Reported: UML 2.0 — Sun, 6 Mar 2005 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML: Cross model dependencies

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

    There seems to be some confusion in the UML spec and by users about the applicability of run-time UML visibility/navigability rules to model time, some of the typical assumptions do not work with distributed models. This needs to be cleared up. For example, can a tool transverse a dependency that crosses models. Can a tool transverse the reverse direction?

    These need to be solved in a way that is internally consistent and consistent with distributed/federated models

  • Reported: UML 2.5 — Mon, 11 Jan 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML: Large Scale Model Support:Federated/Distibuted Models

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

    Large Scale, Distributed, and Federated System Support
    Many projects of interest have become so large that for practical reasons more than one “model” may be required. Such models may also be at different locations and supported in different tools. We need features in UML that will support very large distributed heterogeneous models in a standard way.

    While the complete solution to this strong need is not yet known, such features will probably need to include:

    1. higher level concepts than the standard package;

    2. a uniform URL/URI convention for models and model elements;

    3. standard APIs so that the tools can query each other;

    4. a strong ability to support IEEE 1471 views;

    5. ability to synchronize different models;

    6. ability to propose changes across models.

    While some of these solutions components may be considered tool issues, users with large models need a consistent standard solution. This may solved by a separate RFP but any changes to UML for other reasons must be checked to see if it interferes with large model scenarios.

    As a related problem, there seems to be some confusion in the UML spec and by users about the applicability of run-time UML visibility/navigability rules to model time, some of the typical assumptions do not work with distributed models. This needs to be cleared up.

  • Reported: UML 2.5 — Mon, 11 Jan 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML: Add abilities to specifiy intent of Assert, Negate, Consider, Ignore fragments

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

    In sequence diagrams the use of Assert, Negate, Consider, and Ignore fragments often leaves the reader confused about their intent.

    For example, an Assert fragment is intended to mean that this fragment is the only sequence of events to be considered. This could be interpreted as the only sequence

    1) that can occur; so the reader/developer does not need to consider others as they are impossible

    2) that is interesting; so that the reader/developer can ignore the others as being not interesting

    3) that is allowed; so if something else occurs it is an error

    4) that is allowed; so that the reader/developer needs to prevent the others from occurring.

    Similar issues arise with the other fragments

    An Negate Fragment, could be interpreted as

    1) this fragment can never occur, so don’t worry about it

    2) If this fragment occurs this is an error

    3) You need to prevent this fragment from occurring

    These can be solved by adding a parameter to these fragments

    e.g., Fact (this is the way it is); Enforce (this is the way we have to make it); Error (violations are errors); Ignore (don’t worry about violations)

  • Reported: UML 2.5 — Mon, 11 Jan 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML: Improve Sequence Diagram Semantics (3-issues)

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

    UML is missing useful sequence diagram support for.

    1) Information Flows

    2) Continuous or Repeating messages (for example, on the 200th heart beat message)

    3) Improved timing semantics (requirements for min/max timing)

    Without these features, it will not be possible to represent common situations on sequence diagrams or specify realtime behavior. It may also prevent mapping to state diagrams.

  • Reported: UML 2.5 — Mon, 11 Jan 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML: Better Profile Capabilitiy

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

    Better Profile Capability
    The profile mechanism needs to better support the general refactoring and reuse of profile elements to allow for compatible language evolution. This can include renaming on import, pulling in partial profiles, suppressing features, etc.

    Profiles should support a more sophisticated ability to add contextual and usage based information, such as consistency rules, formatting rules, model/diagram filters, GUI and presentation options, transformation, documentation, and code generation.

    These desired profile features are similar in nature to features required by viewpoints – the ability to control much of the model presentation based on audience or circumstances.

  • Reported: UML 2.5 — Mon, 11 Jan 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML:Access to standardized ontologies within models

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

    In many situations it is necessary to refer to externally defined ontologies, e.g., for types (esp enumerated types) icons, parts, etc. We need a way to select something from a rich list defined elsewhere.

  • Reported: UML 2.5 — Mon, 11 Jan 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

NamedElements whose owners do not subset Namespace

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

    Action is a kind of NamedElement, but the owners of Actions do not subset the property “namespace”.

    The same is true of ActivityNode, but this was discussed in 8668 and resolved as correct.

    The same is true of CollaborationUse: a CollaborationUse is not in the ownedMembers of its Classifier.

    The same is true of MessageEnd and MessageOccurrenceSpecification and Gate.

    The same is not true of InteractionFragment, i.e. InteractionFragments appear in the namespace of their enclosing interaction.

    Are all of these correct?

  • Reported: UML 2.5 — Thu, 14 Jan 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Sequence diagram and Communication diagrams should support instances as lifelines

  • Key: UMLR-222
  • Legacy Issue Number: 15123
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Sequence diagram and Communication diagrams should support instances as lifelines

  • Reported: UML 2.5 — Tue, 9 Mar 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Parameter

  • Key: UMLR-221
  • Legacy Issue Number: 15050
  • Status: open  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Sebastien Gerard)
  • Summary:

    Who could explain me the following constraint on Parameter within section 9.3.10:

    Constraints [1] A parameter may only be associated with a connector end within the context of a collaboration. self.end->notEmpty() implies self.collaboration->notEmpty()

    I wanted to draw delegation connectors between a port and as for example the Parameters of a behaviour such as an activity. Am I allow to do that?

  • Reported: UML 2.5 — Tue, 16 Feb 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML: Higher-level reusable frameworks

  • Key: UMLR-218
  • Legacy Issue Number: 14958
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Templates, Patterns, and Frameworks
    The current ability to capture software templates need to be expanded or augmented in ways that can be used to depict and utilize system design and architectural patterns, and higher-level reusable frameworks

  • Reported: UML 2.5 — Mon, 11 Jan 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML: Timing semantics for activity diagram

  • Key: UMLR-217
  • Legacy Issue Number: 14957
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Timing semantics for activity diagram
    Enable timing diagrams and associated timing semantics to support activity diagrams.

  • Reported: UML 2.5 — Mon, 11 Jan 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Package merge is missing a rule

  • Key: UMLR-178
  • Legacy Issue Number: 14081
  • Status: open  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    Package merge is missing a rule for when two elements have conflicting values for isLeaf, cf. the rule for abstract elements

  • Reported: UML 2.2 — Thu, 16 Jul 2009 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML 2: notation and concepts for unbound and un-owned template parameters are not clear

  • Key: UMLR-177
  • Legacy Issue Number: 14078
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    When creating classifier templates, it is possible to have template parameters that are not owned by the classifier, in at least the following situations:

    1. When the classifier is a partial binding, i.e. it is bound to a template classifier but not all the parameters are bound

    2. The classifier extends a template classifier and has a redefined signature.

    In these cases, what is the notation for the non-owned parameters? Let’s say, for example, that we define C1[A: Class, B: Class]. Then we create C2<A->G>. Does the notation for C2 show a parameter box with B, indicating that B remains to be bound?

    Indeed, from a metamodel point of view, is it correct for C2 to have a signature that refers to B as one of its non-owned parameters, or is C2’s signature “derived” according to “In a canonical model a bound element does not explicitly contain the model elements implied by expanding the templates it binds to, since those expansions are regarded as derived.”

    Similarly, given C1[A: Class, B: Class], let C3 inherit from C1. Does the notation for C3 show a parameter box with A and B?

    Let C3 inherit from C1 and also be bound to it. Is it possible for the formal parameter A defined in C1 to be substituted by the formal parameter A defined (by inheritance) in C3, according to the statement in 17.5.3: “In case of complete binding, the bound element may have its own formal template parameters, and these template parameters can be provided as actual parameters of the binding”?

  • Reported: UML 2.5 — Wed, 15 Jul 2009 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

semantics of associating a use case with another use case, or indeed anything other than an actor, are unclear

  • Key: UMLR-176
  • Legacy Issue Number: 14045
  • Status: open  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    The semantics of associating a use case with another use case, or indeed anything other than an actor, are unclear. There is a rule specifying that use cases may be only be associated with other use cases with different subjects because they describe a complete usage of the subject. But that doesn't explain what it means to have any association. The only hint is in the notation section that gives some examples as "(e.g., to denote input/output, events, and behaviors)." However these details ought to be part of semantics and expanded on.

  • Reported: UML 2.2 — Wed, 1 Jul 2009 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

authorize a reference to an operation in a realized interface.

  • Key: UMLR-180
  • Legacy Issue Number: 14090
  • Status: open  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Ansgar Radermacher)
  • Summary:

    A common task is to implement the operations of an interface I in a class A. The implementation of an operation has a specification reference to the realized operation. In the current UML specification, the operation must be copied into the class before it can be realized, since only owned behavioral features can be referenced: "(section 13.3.2) ... The behavioral feature must be owned by the classifier that owns the behavior or be inherited by it.". I.e. the standard only allows to reference inherited operations, but not realized operations. This is not very practical, since it implies not only copying the operation but also assuring that it remains synchronized with the operation that is defined in the interface (of course, the modeling tool could do the synchronization, but it would still imply storing redundant information within the model). It would be good to authorize a reference to an operation in a realized interface.

  • Reported: UML 2.2 — Wed, 22 Jul 2009 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Subsets vs. Redefines

  • Key: UMLR-179
  • Legacy Issue Number: 14084
  • Status: open  
  • Source: NASA ( Dr. Maged Elaasar)
  • Summary:

    Although I have read the sections in Infrastructure that talks about the meaning of association redefinition and subsetting, and I understand it for the most part, I find myself not sure sometimes which one to use when modeling associations that need to be specialized further down an inheritance hierarchy. This happened to me as I was modeling some parts of the new Diagram Definition metammodel.

    For some cases, it is obvious what to do like when you have an association with * multipclity that you expect to be populated differently down the hierarchy so you make it "derived union" in anticipation of subclasses subsetting it. However, for an association with 1..1 or 0..1 multipclity that you expect it to be specialized, I am not sure whether to declare it as derived union or as a regular association (in the latter case, I expect it to be redeined).

    These features have very powerful yet not much understood semantics by general practitioners, evident by them mostly being used by metamodelers like ourselves, but not by average users of UML (who understand the difference between is-a and has-a relationships for example and use them extensively). It is unfortunate, since these association semantics do have a good mapping to some popular programming languages (like Java as evident by the Eclipse UML2 implementation) and can help modelers intending to generate code from models had they know how to use them properly.

    Maybe we need some section in the spec giving a practitioner some guidance in when and how to use these concepts based on different situations that go beyond explaining what they are for?

  • Reported: UML 2.5 — Fri, 8 May 2009 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Visibility and Import relationships

  • Key: UMLR-174
  • Legacy Issue Number: 14022
  • Status: open  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    Am I wrong or is there actually something inconsistent in the specification around the concept of "visibility"?

    As I underlined for the ballot 6 vote, the current specification explicitly states that Element/PackageImport has no impact on element visibility. Cf. my comments posted on the 27th of April about issue #11567:

    "According to the current definition of the visibility concept, my understanding is that it's neither necessary nor possible to use Import relationships to make an element "visible" (i.e. available). The specification explicitely states that :

    • an ImportedElement can only have a public visibility or no visiblity at all (cf. ElementImport, constraint #2)
    • (p111) : "The public contents of a package are always accessible outside the package through the use of qualified names. "
    • (p66): "The visibility of the ElementImport may be either the same or more restricted than that of the imported element. "

    Then, the only concrete effect of an Import relationship is to give the ability to refere to an element using its simple name rather than its qualified one."

    Nevertheless, and even if there is no impact on the resolution, I found this sentence in the discussion of issue #12833 (ballot 8) : ". The names of stereotypes or classes in a parent profile are not visible to a profile nested in that parent profile without a PackageImport"

  • Reported: UML 2.5 — Tue, 23 Jun 2009 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML2: Need clarification on circle plus notation for containment

  • Key: UMLR-173
  • Legacy Issue Number: 13936
  • Status: open  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    Section 7.3.37, Notation indicates that "The members of the package may be shown within the large rectangle. Members may also be shown by branching lines to member elements, drawn outside the package. A plus sign within a circle is drawn at the end attached to the namespace (package). ". It is unclear if this is intended to apply to any Element owner/ownedElement relationship (such as nested classes, owned behaviors, etc.) or only to packages. Some vendors do support circle-plus notation to depict metamodel containment, others don't. If it applies only to packages, then what is the notation for these other membership associations?

  • Reported: UML 2.5 — Mon, 18 May 2009 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section: 18.3.8

  • Key: UMLR-169
  • Legacy Issue Number: 13862
  • Status: open  
  • Source: University of Kassel ( Michael Zapf)
  • Summary:

    The reader may be led to believe that the application of the stereotype <<clock>> changed the model by adding an operation "Click" to the class StopWatch. It should be clarified that the operation must be owned by the StopWatch even without applying the stereotype. The stereotype instance may, of course, be associated to this operation, and serves as a pointer, for example, to be used in model transformations. Figure 18.18 does not provide this information; it shows the result of the application and not the state before.

  • Reported: UML 2.2 — Thu, 9 Apr 2009 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

The example in Figure 18.11 is badly designed in multiple ways and is strongly misleading

  • Key: UMLR-168
  • Legacy Issue Number: 13859
  • Status: open  
  • Source: University of Kassel ( Michael Zapf)
  • Summary:

    The example in Figure 18.11 is badly designed in multiple ways and is strongly misleading. Although it serves to explain the package import, it should not suggest an improper application of stereotypes. The stereotype defined here (Device) holds attributes which are not typical for devices as such. For instance, a device is not expected to have a color or volume. It may make sense to apply this stereotype to a class of TVs, but not to a class of dishwashers, for example. A better disctinction would be electrical versus non-electrical devices, or handheld versus non-handheld. Second, the attributes as shown here refer to properties which are significant for instances, not for classes. The example basically shows that we can create a TV class, declaring this to be a device. The Factory package shows an instantiation, setting the volume to some value, but omitting the remaining attributes - which must be set as well. The volume parameter for a class of TVs is questionable - what should it mean? This may lead the reader to believe that the volume parameter is meaningful for instances of the model element, although it is associated to the stereotype instance which is associated to the model element. Basically, the element in the Factory package denotes the class of all TVs whose volume is set to 10. This still does not imply a meaning for the instances.

  • Reported: UML 2.2 — Thu, 9 Apr 2009 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Template Binding Question

  • Key: UMLR-171
  • Legacy Issue Number: 13926
  • Status: open  
  • Source: NASA ( Dr. Maged Elaasar)
  • Summary:

    In the spec, there is a constraint on TemplateParameterSubstitution, as follows:

    actual->forAll(a | a.isCompatibleWith(formal.parameteredElement))

    "actual" and "formal" are TemplatableElement. So looking up "isCompatibleWith" definition in the spec, I find this:

    The query isCompatibleWith() determines if this parameterable element is compatible with the specified parameterable element. By default parameterable element P is compatible with parameterable element Q if the kind of P is the same or a subtype as the kind of Q. Subclasses should override this operation to specify different compatibility constraints.

    ParameterableElement::isCompatibleWith(p : ParameterableElement) : Boolean;
    isCompatibleWith = p->oclIsKindOf(self.oclType)

    This means if I defined a class template with a template parameter linked to Interface A (a ParametrableElement), and I used this interface to type a property inside the class template, that I cannot substite the interface with Class B that realizes Interface A, because Class B and Interface A do not have compatible kinds (metaclasses).

    Is this what the constraint is saying? Is this Valid?

  • Reported: UML 2.5 — Wed, 29 Apr 2009 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

there are numerous places where associations between UML elements have only one, navigable role

  • Key: UMLR-170
  • Legacy Issue Number: 13908
  • Status: open  
  • Source: PTC ( Phillip Astle)
  • Summary:

    In the specification there are numerous places where associations between UML elements have only one, navigable role. This seriously restricts the ability of derived properties that are added as part of a profile. Though most tool vendors implement bi-directional relationships for everything anyway, this doesn't help at all when you're trying to define the implementation of the derived property (i.e. tag), as part of a property. It is my belief that all associations in UML should be bi-directional to support a method of non-ambiguous definition. A couple of obvious examples are: 1. Navigating from a realizing relationship to a realized InformationFlow. 2. Navigating from an ActivityEdge to an Action via a Pin.

  • Reported: UML 2.1.2 — Wed, 29 Apr 2009 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Subsets vs. Redefines

  • Key: UMLR-172
  • Legacy Issue Number: 13927
  • Status: open  
  • Source: NASA ( Dr. Maged Elaasar)
  • Summary:

    Although I have read the sections in Infrastructure that talks about the meaning of association redefinition and subsetting, and I understand it for the most part, I find myself not sure sometimes which one to use when modeling associations that need to be specialized further down an inheritance hierarchy. This happened to me as I was modeling some parts of the new Diagram Definition metammodel.

    For some cases, it is obvious what to do like when you have an association with * multipclity that you expect to be populated differently down the hierarchy so you make it "derived union" in anticipation of subclasses subsetting it. However, for an association with 1..1 or 0..1 multipclity that you expect it to be specialized, I am not sure whether to declare it as derived union or as a regular association (in the latter case, I expect it to be redeined).

    These features have very powerful yet not much understood semantics by general practitioners, evident by them mostly being used by metamodelers like ourselves, but not by average users of UML (who understand the difference between is-a and has-a relationships for example and use them extensively). It is unfortunate, since these association semantics do have a good mapping to some popular programming languages (like Java as evident by the Eclipse UML2 implementation) and can help modelers intending to generate code from models had they know how to use them properly.

    Maybe we need some section in the spec giving a practitioner some guidance in when and how to use these concepts based on different situations that go beyond explaining what they are for?

  • Reported: UML 2.5 — Fri, 8 May 2009 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Figure 18.9 shows a presentation option for an Interface which has not been introduced before (circle within box)

  • Key: UMLR-167
  • Legacy Issue Number: 13858
  • Status: open  
  • Source: University of Kassel ( Michael Zapf)
  • Summary:

    Figure 18.9 shows a presentation option for an Interface which has not been introduced before (circle within box)

  • Reported: UML 2.2 — Thu, 9 Apr 2009 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section: 18.3.6

  • Key: UMLR-166
  • Legacy Issue Number: 13856
  • Status: open  
  • Source: University of Kassel ( Michael Zapf)
  • Summary:

    Figure 18.8 includes a Metamodel formalism which has never been introduced, in particular with respect to customized metamodels. The presentation as a package with a triangle is new at this point. Although the concept of a metamodel is verbally explained in the Infrastructure, there is no abstract syntax. It becomes implicitly clear that a metamodel is a package. I suggest to insert a definition of a Metamodel as a subclass of Package in the Infrastructure document or in the Profiles chapter of this document. This also allows to explain what is meant by "applying a metamodel". Also, the term "a UML2 metamodel" (p. 666) is unclear, taking into account that UML2 itself is a metamodel. This all should be clarified due to the importance of the metamodel concept in this chapter. The same applies to the respective chapter of the Infrastructure document.

  • Reported: UML 2.2 — Thu, 9 Apr 2009 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

issue within UPDM with profile diagrams

  • Key: UMLR-165
  • Legacy Issue Number: 13848
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Strazdauskas)
  • Summary:

    there is an issue within UPDM with profile diagrams. As there are multiple stereotypes in the diagrams, showing metaclass and extension clutters the diagrams.
    They become literally unreadable in the spec as they need to fit in the page, since every element takes addition space for extension:

    In MagicDraw, we have such notation:

    It saves time, is intuitive, but this is non standard thing, so we cannot use it in UPDM.

    I would like to raise an issue on the notation of extended metaclass, but I'm open for discussion

  • Reported: UML 2.5 — Tue, 31 Mar 2009 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Should there be a constraint for extends equivalent to 16.3.6 [4]

  • Key: UMLR-175
  • Legacy Issue Number: 14044
  • Status: open  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    Should there be a constraint for extends equivalent to 16.3.6 [4], that extends should be an acylic relationship between use cases?

  • Reported: UML 2.2 — Wed, 1 Jul 2009 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

clarification on Behavior::specification / meaning of InterfaceRealization

  • Key: UMLR-110
  • Legacy Issue Number: 10656
  • Status: open  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    In 7.3.25 InterfaceRealization Semantics the UML2 spec says "For behavioral features, the implementing classifier will
    have an operation or reception for every operation or reception, respectively, defined by the interface. For properties, the
    realizing classifier will provide functionality that maintains the state represented by the property."

    While section 7.3.45 Realization Semantics says "A Realization signifies that the client set of elements are an implementation of the supplier set, which serves as the
    specification. The meaning of ‘implementation’ is not strictly defined, but rather implies a more refined or elaborate form
    in respect to a certain modeling context. It is possible to specify a mapping between the specification and implementation
    elements, although it is not necessarily computable."

    If you interpret this as a literal constraint, then the realizing Classifier would need to copy all of the BehavioralFeatures it realizes. However, it seems unnecessarily redundant to realize an interface and to have to copy all the operations into the realizing classifier too. This means that for an Activity, the "signature" content of an operation could have to be specified up to 6 times:
    1. An Operation in a provided Interface
    2. The same Operation copied into a realizing Class used as the type of a Port
    3. An Operation of a Component containing the Port
    4. The method Behavior whose specification is the Operation owned by the Class
    5. If the Behavior is an Activity, the ActivityParameterNodes
    6. The InputPins and OutputPins of a CallOperationAction that invokes the operation

    In addition, there would be no way for an ownedBehavior's specification to refer to an Operation of an Interface provided through a Port since different ports can realize the same interface but have different implementations.

    There is no explicit constraint that the Classifier has to have a matching Operation, so you could read the above semantics to mean that adding the InterfaceRealization effectively means the Realizing Classifier has the Interface's behavioral features. This seems to be common practice, you don't often see all the realized operations cloned into the realizing classifier as this is redundant and somewhat tedious to do and maintain.

    Consider changing the description of property Behavior::specification in section 13.3.2 from:
    Designates a behavioral feature that the behavior implements. The behavioral
    feature must be owned by the classifier that owns the behavior or be inherited
    by it. The parameters of the behavioral feature and the implementing behavior
    must match. If a behavior does not have a specification, it is directly associated
    with a classifier (i.e., it is the behavior of the classifier as a whole).

    to:

    Designates a behavioral feature that the behavior implements. The behavioral
    feature must be owned by the classifier that owns the behavior or be realized or inherited
    by it. The parameters of the behavioral feature and the implementing behavior
    must match. If a behavior does not have a specification, it is directly associated
    with a classifier (i.e., it is the behavior of the classifier as a whole).

    The possible problems with this change are:
    1 Subclasses cannot redefine realized operations of their superclasses unless the operation is duplicated in the superclass. This is because there would be no redefined element to reference in the superclass. This can be solved by cloning the operations that need to be redefined, or (more likely) redefining an ownedBehavior of the Superclass, not an Operation. So there is no change here.
    2. Setting the specification of an ownedBehavior would result in an update of the realized interface since the opposite of the specification property is the Interface's method property. This is unfortunate coupling between an interface and its method implementations, but there are many other such cases in UML2, and the method property is multi-valued. So this isn't really that much of a problem.

    Some advantages are:
    1. It matches the common understanding or realization
    2. It reduces redundancy in the model
    3. It allows an ownedBehavior's specification to be an Operation of an Interface provided through a Port in an EncapsulatedClassifer. This allows a EncapsulatedClassifier to provide different implementations for the same operation provided through different ports. This would not be possible if the specification operation had to be owned by the containing classifier as there would be no way to distinguish which operation the different behaviors corresponded to.

  • Reported: UML 2.5 — Fri, 9 Feb 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Presentation option for return parameter for operation type are incomplete

  • Key: UMLR-109
  • Legacy Issue Number: 10635
  • Status: open  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    Section 7.3.36 Operation, under Presentation Options explains notation options for expressing the return value of an Operation. The example is:

    toString(): String

    means the same thing as

    toString(return: String)

    This should also be the same as:

    toString(return result: String)

    That is, the default name of the return parameter is "result". This is to be consistent with OCL's reference to the result of an operation in a post condition, and to allow a behavior to be able to refer to a return parameter by name.

  • Reported: UML 2.5 — Mon, 29 Jan 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML 2 Superstructure: Abstractions should be acyclic

  • Key: UMLR-108
  • Legacy Issue Number: 10600
  • Status: open  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The UML Abstractions concept should include a constraint that a graph involving Abstraction relationships should be acyclic; i.e. an <element type> cannot be both a transitively higher level of abstraction and transitively lower level of abstraction of the same <element type>.

    not self.getHigherLevelAbstractions()->includes(self)

  • Reported: UML 2.5 — Fri, 19 Jan 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Constraint.context vs Constraint.constrainedElement

  • Key: UMLR-105
  • Legacy Issue Number: 10413
  • Status: open  
  • Source: Dassault Systemes ( Mr. Tomas Juknevicius)
  • Summary:

    The situation is now more-or-less clear.
    We will use a variant specified OCL spec for evaluating OCL constraints.

    However in my humble opinion, UML spec could also benefit if the descriptions
    of context and constrainedElement were clarrified a bit on how one should use them.
    As Karl correctly notes, when 2 properties can be used to specify the same thing,
    this introduces ambiguities in the model.

    Even if "nothing prevents the context and constrainedElement from beeing the same object",
    on the other hand nothing prevents these 2 from beeing different objects.
    Hence if author produces some UML model with constraints where constrainedElement!=context,
    the readers of this model cannot interpret it unambiguously.
    And I can imagine many cases, where constrainedElement will not be equal to context.
    For example if constraints are placed in a separate package from their constrained elements
    (perhaps constrained elements are in a separate, read-only library and constraints can not
    be added there; or for other packaging reasons). In this case context of these constraints
    will be their owner package (per UML2.1 rules) and constrainedElement will be completely
    unrelated to it.

    PS
    And this applies not only in the narrow case of constraints, specified in OCL.
    Almost all other languages need contextual information.
    For the sake of argument, lets say the constraint is specified in English language.
    Well, it so happens, that English language also needs some context to interpret sentences.
    The pronouns, such as "this", "these" or "such", can play the same role in English as the "self" variable in OCL.

    E.g. Imagine the constraint with specification=OpaqueExpression

    {language=English; body="these must be yellow"}

    placed into the class Box, having property contents:Apple[*] and constrainedElement pointing to this property.
    Now there is an ambiguity.
    If the constraint.context field is used for interpretting the phrase "these must be yellow" then the boxes must be yellow.
    If the constraint.constrainedElement is used, then apples in the box must be yellow.

    > Karl Frank wrote:
    >
    > Agreed. But imo it is a defect for the same thing to be specified in two equivalent ways. EVen if the context is by definition the constrained element, in the case of a
    > constraint, it remains an opening for confusion and doubt to specify it using different terms even when equivalent.
    >
    > But context means something different in regard to a behavior, so I believe constrainedElement is the right term, which is the one used in the OCL spec.
    >
    > - Karl
    >
    > --------------------------------------------------------------------------------------------------------------------------------------------------------------------------
    > From: Branislav Selic bselic@ca.ibm.com
    > Sent: Thursday, May 18, 2006 5:21 PM
    > To: Karl Frank
    > Cc: Juergen Boldt; ocl2-rtf@omg.org; Tomas Juknevicius; uml2-rtf@omg.org
    > Subject: RE: UML/OCL scpec mismatch - Constraint.context vs Constraint.constrainedElement
    >
    > I was indeed raising a separate OCL issue (a major one, I believe), but I was also saying that there is no real issue with the UML 2 spec. In fact, if you think about it,
    > there is nothing to prevent constrainedElement and context from being the same object. There is no real contradiction here.
    >
    > Bran

  • Reported: UML 2.5 — Mon, 22 May 2006 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section: 7

  • Key: UMLR-103
  • Legacy Issue Number: 10345
  • Status: open  
  • Source: NUI Maynooth ( Jacqueline McQuillan)
  • Summary:

    There is no way to indicate that an Operation is an abstract Operation, perhaps the Operation class should have an isAbstract attribute?( similar to the way the Classifer class has an isAbstract attribute to indicate that its abstract)

  • Reported: UML 2.0 — Tue, 12 Sep 2006 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Connector contract is inflexible

  • Key: UMLR-106
  • Legacy Issue Number: 10474
  • Status: open  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    Connector contract is inflexible and cannot bind connector ends to parts in the contract behavior. A Connector can have a contract which is a Behavior which specifies the valid interaction pattern across the connector. The Behavior could be an Interaction, Activity, StateMachine, ProtocolStateMachine, or OpaqueBehavior. However, the parts in the Behavior (lifeliines. activity partitions, target input pins, variables, etc.) cannot be bound to the ports at the end of the connector. So it is difficult to understand what part participating ports play in the contract beahvior. Another problem is that the may be more than one interaction between the parts at the connector ends representing different conversations between the same parties over the same connector. This would require more than one behavior for the contract in order to describe each interaction.

    Instead, the contract for a connector should be a CollaborationUse. The connectorEnds would then be bound to the roles they play in that contract. The Collaboration of the CollaborationUse can contain multiple ownedBehaviors which represent the interaction protocols between the roles. Parts playing these roles (as indicated by a CollaborationUse) would have to interact in a manner consistent with the corresponding Collaboration ownedBehavior. (These can match by name, but we may want to consider an extension that allowed bindings between operations of the parts and behavior of the collaboration to allow more flexible contracts).

    The interactions between connected consumers and providers instances are initiated by one party or the other (may not be the same for all such interactions). The provider will typically define the protocol consumers must follow in order to use the provided capabilities. One way to model these protocols is to set the type of the Port providing the capability to the Collaboration defining the protocol. Then the type of the CollaborationUse for any Connector connected to that port would be the type of the Port.

  • Reported: UML 2.5 — Wed, 29 Nov 2006 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section: 13 & 14

  • Key: UMLR-100
  • Legacy Issue Number: 9923
  • Status: open  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Sebastien Gerard)
  • Summary:

    Some of the concepts defined in the Interaction chapter (n 14), as for example BehaviorExecutionSpecification, are more general than Interaction and shoul dbe part of the chpater 13 which concern is behavior in general. I suggest to review the chapter 14 in order to extract from this section all the concept that are generic w.r.t. behavior and to put them in the chapter 13.

  • Reported: UML 2.1.1 — Tue, 18 Jul 2006 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Optional values and evaluation of defaults

  • Key: UMLR-99
  • Legacy Issue Number: 9887
  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    7.3.44 says that the defaultValue is "A ValueSpecification that is evaluated to give a default value for the Property when an object of the owning Classifier is instantiated."
    This makes it a bit pointless to have such as property as optional since it will always be set to its default value (though in theory the property could be explicitly unset - in which case it will not use the default value either.
    There is a need for dynamic evaluation of an expression associated with a Property if no value has been explicitly set.

    Proposed resolution:

    • if lower = 1 then defaultValue is assigned to the property when object is instantiated (and when the class is attached to an object using reclassify)
    • if lower = 0 then no assignment is made but the defaultValue (if present) is evaluated each time the property value is read: in effect it is acting as a derived property until a value is explicitly assigned.

    This behavior must also be included in the description of ReadStructurualFeatureAction (11.3.37) which does not mention default values at all.

  • Reported: UML 2.5 — Thu, 6 Jul 2006 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

OCL Syntax in expressions

  • Key: UMLR-98
  • Legacy Issue Number: 9886
  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    When OCL is used in body of OpaqueExpressions it's unclear what syntax should be used - in particular whether keywords like "context:", "inv:", "pre:" should be used or not. Section 7.3.35 should, for OCL, reference the correct concrete syntax element in the OCL spec. Additional material for this issue:

    At the moment in 7.3.35 there is just a 'style guideline' for how OCL constraints/expressions should be expressed using an OpaqueExpression
    For interoperability there should be a stronger statement that OCL constraints must have language = "OCL".
    Also it should be made clearer that such OpaqueExpressions should have type=Boolean

  • Reported: UML 2.5 — Thu, 6 Jul 2006 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Association::isDerived should be derived

  • Key: UMLR-102
  • Legacy Issue Number: 9999
  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    In the L3 metamodel there are only 5 Associations with isDerived=true.
    These are:
    A_context_action
    A_deployedElement_deploymentTarget
    A_state_redefinitionContext
    A_extension_metaclass
    A_containedEdge_inGroup

    However there are clearly many more Associations which are in practice derived - for example anything with an end which is a derivedUnion.
    It seems that an Association should automatically be derived if one or both of its ends are derived.

    Proposed resolution:
    Make Association::isDerived itself a derived property (so it becomes Association::/isDerived)
    The OCL for the derivation would be:
    context Association isDerived = self.memberEnd->exists(isDerived)

  • Reported: UML 2.5 — Wed, 26 Jul 2006 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section: 10.3.4 of formal/2007-02-03

  • Key: UMLR-111
  • Legacy Issue Number: 10781
  • Status: open  
  • Source: Vilnius University, Lithuania ( Donatas Ciuksys)
  • Summary:

    The direction of deployment dependency is wrong in all figures that use this kind of dependency, e.g. figure 10.9 on page 216 (direction is opposite to the one stated in metamodel). The deployment dependency in these figures is being drawn from artifact (client) to target (suplier), though figure 10.4 on page 210 defines Deployment as being dependency with DeploymentTarget as client and DeployedArtifact as supplier, so direction should be opposite - from target to artifact. As an alternative, the metamodel could be adjusted.

  • Reported: UML 2.1.1 — Mon, 19 Feb 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML 2.1.1 - notation for parameter sets

  • Key: UMLR-116
  • Legacy Issue Number: 10957
  • Status: open  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    I note that the notation for parameters sets shown is for invocations of activities, not for activity definitions. Is it intended that there is a similar notation for grouping activity parameter nodes that represent parameter sets?

  • Reported: UML 2.5 — Tue, 27 Mar 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Units and types are still problematic

  • Key: UMLR-115
  • Legacy Issue Number: 10824
  • Status: open  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    Units and types are still problematic. UML notation is not able to show tags of some referenced elements - in case of attributes, they should show tags of type, in case of slots, they should show tags of type of defining feature (secondary reference).

  • Reported: UML 2.5 — Fri, 9 Mar 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

names and namespaces

  • Key: UMLR-114
  • Legacy Issue Number: 10823
  • Status: open  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    Namespace defines derived "member" collection for NamedElements identifiable by name.
    However not all Namespaces subset this collection, so NamedElements are added just to ownedElements.

    Example: Activity and ActivityNodes. Actions and ObjectNodes could have identical names because they are not added into "ownedMember" collection and are not identified by name.
    Is this correct or bug in metamodel? I believe we could find more such Namespaces.

  • Reported: UML 2.5 — Wed, 14 Mar 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section: 14.4 Timing Diagram: Continuous time axis

  • Key: UMLR-118
  • Legacy Issue Number: 11092
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Table 14.6., State or condition timeline: It is unclear how the time information is stored in the interaction model. Especially if it is a continuous timeline. Please clarify the repository model for timing diagrams

  • Reported: UML 2.1.1 — Fri, 8 Jun 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

9.3.9 Invocation Action

  • Key: UMLR-117
  • Legacy Issue Number: 10999
  • Status: open  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    In the semantics, the spec needs to state what happens if there are multiple instances corresponding to the port (which might happen if the multiplicity upper bound of the port is greater than 1)

  • Reported: UML 2.5 — Thu, 10 May 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section: Annex A: Diagrams

  • Key: UMLR-120
  • Legacy Issue Number: 11273
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The abbreviation sd for interaction diagrams should be renamed to id. sd stands for sequence diagram, but there three more interaction diagrams. It is confusing to have a diagram kind sd for a timing diagram.

  • Reported: UML 2.1.1 — Fri, 10 Aug 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Meaning of relationship between iteration clause and Lifeline.selector clau

  • Key: UMLR-53
  • Legacy Issue Number: 8700
  • Status: open  
  • Source: TMNA Services ( Jim Schardt)
  • Summary:

    UML2-rtf issue: Meaning of the relationship between the iteration clause and the Lifeline.selector clause.

    Interactions often involve the invocation of multiple instances of the same class. For example I may want and instance of my Portfolio class to invoke the currentValue method on instances of associated Asset classes that belong to an asset category (Asset.assetCategory = Stock). This way a portfolio may assess its own value by summing up the current value of all its stock assets. To model this I want to show the same message - currentValue() being sent to the selection of assets that have the assetCategory equal to "Stock."

    Does the current UML2 communications diagram notation support the following:

    A portfolio Lifeline labeled theFund : Portfolio
    An asset Lifeline labeled myAssets [assetCategory = Stock] : Asset
    This would have to represent not one but all the asset instances that had an assetCategory of Stock
    A line connecting the two Lifelines
    A message with a sequence expression that looks like:
    1 *[holding := 1..n] : assetValue = currentValue()

    Lifelines are defined to represent only one interacting entity in an interaction. However the interaction syntax for communication diagrams would indicate that the lifeline can be "multivalued."

    The need for a Lifeline to represent multiple instances for the purpose of sending a single message to all of them at some nesting level is very common.

    Suggestion: Allow the Lifeline to have a multiplicity shown within brackets as with parts. Constrain the lifeline to have multiplicity one or greater. Constrain the lifeline with a multiplicity greater than one to have a selector that can, upon applying the selector, result in a single particpant.

  • Reported: UML 2.5 — Thu, 21 Apr 2005 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section: 14.3.3 Page: 508+

  • Key: UMLR-59
  • Legacy Issue Number: 8765
  • Status: open  
  • Source: Ostfold University College ( Dr. Oystein Haugen)
  • Summary:

    Sequence diagrams are often used for early specification of requirements. The distinction between potential and mandatory behavior is not adequately described in UML 2.0 Interactions. To improve this we suggest an additional operator "xalt" that describes alternative operands that are mandatory meaning that any refinement should keep at least some of the behavior of each operand. See paper at <<UML2003>>: Haugen, Stølen: STAIRS - Steps to Analyze Interactions with Refinement Semantics

  • Reported: UML 2.0 — Wed, 4 May 2005 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section: 14.3.3

  • Key: UMLR-58
  • Legacy Issue Number: 8764
  • Status: open  
  • Source: Ostfold University College ( Dr. Oystein Haugen)
  • Summary:

    In sequence diagrams, the neg operator is used to describe invalid behaviours. However, people tend to interpret neg slightly differently depending on the context in which it appears, thus making it difficult to define a precise semantics for it. Two examples: A sequence diagram with a neg fragment is usually taken to describe also positive (valid) behaviours, i.e. the behaviours of the diagram with the neg fragment simply omitted. This implies that the empty trace should be positive for the neg fragment in this context. Another common use of neg is to state that one of the alternatives (operands) of an alt construct describes the invalid behaviour. In this case, the neg fragment has no positive behaviours (not even the empty trace). Recommendation: Consider introducing another operator in addition, due to the different uses of the neg operator.

  • Reported: UML 2.0 — Wed, 4 May 2005 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML 2.0 Super/Use Cases/Subject of a Use Case

  • Key: UMLR-65
  • Legacy Issue Number: 8883
  • Status: open  
  • Source: MID GmbH ( Mr. Detlef Peters)
  • Summary:

    Section 16.3.2 allows "classifiers in general to own use cases". Section 16.3.6 however states that the "subject of a use case could be (...) any other element that may have behavior". These elements are called "BehavioredClassifier" by Section 13 and are a specialization of Classifier.
    Please clarify the consequences of these statements:

    • may all Classifiers be owners of UseCases, but only BehavioredClassifiers be the subject of a UseCase?
    • what is the semantics of Non-BehavioredClassifiers, e.g. an Interaction or OpaqueBehavior, owning a UseCase or being a subject of it? A UseCase "represents a declaration of an offered behavior" (16.3.6), so how can Non-BehavioredClassifiers ever offer a behavior?
  • Reported: UML 2.5 — Tue, 28 Jun 2005 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Issue 7368 - make Classifier::useCase navigable

  • Key: UMLR-64
  • Legacy Issue Number: 8855
  • Status: open  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    To indicate which actor initiates the interaction a communicates association may optionally be adorned with an arrow head to represent navigability.
    (No arrowhead indicates either actor can initiate the interaction.)

    Constraints:
    [1] Only one arrowhead can point towards the use case.
    [2] All other communicates associations have arrow heads pointing towards the other actors.

    Figure 409, page 660 could be modified and used as an example.

  • Reported: UML 2.5 — Thu, 2 Jun 2005 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML2-rtf issue: communication diagram

  • Key: UMLR-52
  • Legacy Issue Number: 8699
  • Status: open  
  • Source: TMNA Services ( Jim Schardt)
  • Summary:

    UML2-rtf issue related to communication diagrams:

    Section 14.4 describes the sequence expression tied to messages on a communications diagram. However, the abstract syntax does not (as far as I can trace the diagram) model the sequence expression. This leaves the sequence expression semantics wide open.

    Some tools implement the sequence express but the concept of threads and nesting implicit in the expression syntax are undefined in the meta model.

    Recommendation: Add a SequenceExpresion element into the model associate it with message, and define it explicitly. Describe the semantics of nesting messages.

  • Reported: UML 2.5 — Thu, 21 Apr 2005 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section: 10.3.1

  • Key: UMLR-51
  • Legacy Issue Number: 8693
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Bidirectional association between artifact and operation required Fig. 124 on page 205 show an unidirectional association from artifact to operation. In the context of the Actions it is necessary to access the owner of an operation. Therefore the association must be bidirectional.

  • Reported: UML 2.0 — Sun, 10 Apr 2005 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Arguments of Message

  • Key: UMLR-61
  • Legacy Issue Number: 8786
  • Status: open  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    3. Arguments of Message
    Variables, members and other "value holders" can be used as arguments of call actions or arguments of message (for example setName(name) where "name" is variable defined in Interaction), but now arguments are simple ValueSpecification, so can't have reference to "real" argument (variable, member, parameter of behavior etc.)
    Maybe Argument should be in metamodel as in UML 1.4, or at least ValueSpecification should be subclassed in Interactions package and introduce reference to Element that value it represents?

  • Reported: UML 2.5 — Wed, 18 May 2005 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

ConditionalNode inputs used by more than one test

  • Key: UMLR-60
  • Legacy Issue Number: 8779
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    ConditionalNode inputs used by more than one test. In ConditionalNode, the tokens in input pins might be consumed by one test body execution and not available to another. They need a similar mechanism to LoopNode that copies the inputs to test body in puts and destroys the original inputs when the loop node is done

  • Reported: UML 2.0 — Sun, 15 May 2005 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Association in UseCase diagram

  • Key: UMLR-56
  • Legacy Issue Number: 8758
  • Status: open  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    Actor and UseCase can't own Properties, this means that associations
    > in UseCase diagram are always non-navigable at both ends.
    > Is this correct?

    ??? I don't have the time at the moment to check whether such a constraint exists, but, if it does, it is certainly an error. For example, in the case of Actors there is an explicit constraint that assumes that actors have properties. Can you tell me where your assumption that Actors and UseCases cannot own Properties comes from?

  • Reported: UML 2.5 — Tue, 3 May 2005 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Possibility to define a Collection as default Value needed

  • Key: UMLR-55
  • Legacy Issue Number: 8756
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Multiple default values. In Figures 10 and 12, the max multiplicity for defaultValue is 1. What if the property or parameter is multivalued? There is no value specification for collections.

  • Reported: UML 2.0 — Tue, 3 May 2005 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Variables

  • Key: UMLR-63
  • Legacy Issue Number: 8788
  • Status: open  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    What namespace should be owner of variables used in sequence diagram?
    If variables are added into Interaction, they conflict, because every execution (method for example, or even loop) can introduce variables with some names, that should be not accessible outside.
    Maybe ExecutionSpecification or InteractionFragment should be NameSpaces and declare collection for storing variables?

  • Reported: UML 2.5 — Wed, 18 May 2005 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Numbering

  • Key: UMLR-62
  • Legacy Issue Number: 8787
  • Status: open  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    Messages in UML 2.0 can't have numbers in the model, but all examples of sequence and communication diagrams are with numbers. How numbers should be mapped into model? How to migrate with old activator, successors, predecessors?

  • Reported: UML 2.5 — Wed, 18 May 2005 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Add a Constraint

  • Key: UMLR-50
  • Legacy Issue Number: 8684
  • Status: open  
  • Source: FUNDP ( Pierre Yves Schobbens)
  • Summary:

    No consistency condition is put between predecessor clauses, for instance two clauses can be the predecessor of each other. Add a Constraint: The transitive closure of predecessorClause must be a strict partial order.

  • Reported: UML 2.5 — Tue, 5 Apr 2005 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

SequenceNode should have way to set output pins in CompleteStructured

  • Key: UMLR-49
  • Legacy Issue Number: 8501
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    SequenceNode should have way to set output pins in CompleteStructured, like ConditionalNode and LoopNode do.

  • Reported: UML 2.0 — Sun, 6 Mar 2005 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Arguments of Message

  • Key: UMLR-57
  • Legacy Issue Number: 8761
  • Status: open  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    arguments of call actions or arguments of message (for example
    > setName(name) where "name" is variable defined in Interaction), but
    > now arguments are simple ValueSpecification, so can't have
    > refference to "real" argument (variable, member, parameter of behavior etc.)
    > Maybe Argument should be in metamodel as in UML 1.4, or at least
    > ValueSpecification should be subclassed in Interactions package and
    > introduce reference to Element that value it represents?

  • Reported: UML 2.5 — Tue, 3 May 2005 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML: Include text description field with model element --- additional information added

  • Key: UMLR-201
  • Legacy Issue Number: 14941
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    While almost every tool supports the concept of a model element specification, they are not consistent on which elements can have them nor are they consistent on the contents/typing of the specification. Please make model element specification available on ALL elements and make the format and content a rich field.

    This capability is required for modelers to incorporate significant amount of explanatory documentation for each element. The ability to include textual descriptions for each model element and other basic metadata should be part of UML. In addition, such text should be augmented with the ability to structure and format the model element descriptions.

    We would like to see support for RTF, PDF, XML, HTML, and XHTML, as well as support for including graphics

    Similarly, a modeler should be able to type any attribute with a string-like type that allows for similar formatting or markup.

  • Reported: UML 2.5 — Mon, 11 Jan 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML: Provide unique URL/URI Reference to/from Model Elements

  • Key: UMLR-200
  • Legacy Issue Number: 14940
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Unique URL/URI Reference to/from Model Elements

    In Model-Driven Development (MDD), the model is the repository of truth on the project. However, we recognize that the complete containment of all information on a project in a single tool repository is not a near-term solution. To this end, we need the ability to support explicit references from model elements to externals (such as documents, other types of models) and similar references back.

    This are not just pointers, we need the ability to incorporate information (e.g., documents, web pages, diagrams, pictures) from elsewhere and to support refreshing with current data, as well as the export of model information into external locations. Some simple examples:

    1. A driving requirements document may contain tables and pictures, a modeler will need direct access to these elements.

    2. A reviewer of a model may need to see diagrams where the appropriate and current icons substitute for the UML graphical elements.

    3. An organization may wish to publish documentation of a particular aspect of the model on the internet and wish that the visitors always obtained the latest information

  • Reported: UML 2.5 — Mon, 11 Jan 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML: A strong ability to support generating Documents

  • Key: UMLR-207
  • Legacy Issue Number: 14947
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    A strong ability to support generating Documents
    On the type of projects that we work on, we find that the project needs the ability to produce standardized documents from the models. While most tools support documentation generation to some extent, the rules used to construct the documents are not standardized. UML needs the ability to create these documents in a standardized way that can support automatic generation from the package structure, the model element descriptions (see above), incorporating diagrams, externals (see URL/URI above), and document models (a UML model of the document by composition of sections).

    The creation of these documents should support rule-based and manually constructed diagrams.

    These could be based on IEEE 1471 views and the use of QVT.

  • Reported: UML 2.5 — Mon, 11 Jan 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML Support for multiple library levels

  • Key: UMLR-206
  • Legacy Issue Number: 14946
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    In large-scale development environments where development may be iterative and/or incremental, it often happens that there are standardized libraries of common or reusable elements, in various levels of completion. These may be type definitions, classes, objects, parts, requirements, etc. While current «import» and «access» are useful to reuse these elements, we need the ability to specify an ordered chain of libraries, where an element usage would obtain the first occurrence of the element in the chain. Note that the libraries may be located remotely or on the web.

  • Reported: UML 2.5 — Mon, 11 Jan 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Provide notational mechanism to represent any group of model elements based on some criteria w/o stealing ownership

  • Key: UMLR-203
  • Legacy Issue Number: 14943
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Non-structural, non-owning Containment
    While packages and stereotypes have their purposes, we need another way of combining and identifying groups of related elements based on specific partitioning criteria. This allows us to categorize and organize system elements – a common task for SEs.

    We could use this to identify those elements that are related to a particular architectural layer, due in a particular delivery, produced by a particular manufacturer, or related to a particular concern (e.g., security).

    Model elements could belong to any number of these containers. These containers should appear on diagrams, tables, and the browsers, but should not confer or change any prior ownership. Populating these containers could be done mechanically and/or by execution of rules. The containers can have value properties and dependencies that are considered to logically apply to the members of the container

  • Reported: UML 2.5 — Mon, 11 Jan 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML: Better Definition of Compliance

  • Key: UMLR-210
  • Legacy Issue Number: 14950
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Diagram / Model Interchange
    The current level of Diagram and Model interchangeability is appalling and is a significant barrier to further penetration of UML/SysML Into the marketplace. With the advent of new test suites (such as by OMG’s Model Interchange Working Group (MIWG)), the UML specification should require demonstrated success in some of these tests before a UML tool can be declared conforming to UML.

    OCL Support
    A minimal required support for OCL should be defined as part of compliance.

    QVT Support
    A minimal required support for QVT should be defined as part of compliance.

  • Reported: UML 2.5 — Mon, 11 Jan 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML: Provide mathematical formalism for UML semantics to provide precise meaning to language constructs

  • Key: UMLR-209
  • Legacy Issue Number: 14949
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Leverage and build upon fUML semantics and associated formalism to provide semantics for behavior and structure

  • Reported: UML 2.5 — Mon, 11 Jan 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML: Support for maintaining what-if models in repository without massive duplication

  • Key: UMLR-205
  • Legacy Issue Number: 14945
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Support for maintaining what-if models in repository without massive duplication

    UML and descendant modeling languages should be able to support multiple solutions within a model without excessive duplication. This could be because of planned system evolution or because we need to compare multiple approaches. One solution might be to support standardized named effectivity/expiration fields for each model element (including dependencies). All diagrams, queries, reports, etc., could be conditioned by a selected date. Instead of dates, a set of version numbers could apply to each model element, with the model filtering work in same way.

  • Reported: UML 2.5 — Fri, 27 Jun 2014 11:17 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML: A strong ability to support reviewing packages

  • Key: UMLR-204
  • Legacy Issue Number: 14944
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    A strong ability to support reviewing packages
    On the large projects, we find that the project needs the ability to present model subsets to reviewers, and allow commenting, proposed corrections, assignment of action items, and red-line comparisons. UML needs the ability to create these review packages in a way that can support the types of changes that reviewers propose – without changing the underlying model.

    The creation of these review packages should support both rule-based and manually constructed packages, including the diagrams and the selection of elements.

    These could be based on IEEE 1471 views and the use of QVT.

  • Reported: UML 2.5 — Mon, 11 Jan 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML: Diagrams as Model Elements

  • Key: UMLR-208
  • Legacy Issue Number: 14948
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Diagrams as Model Elements
    Make diagrams full and equal model elements, tied to the regular model element that the diagram is displaying. Refer to the SysML specification in Annex A.

    All diagrams types should have an unique 2-3 character model element type, and also supporting diagram types.

    As a regular model element is should be able to support attributes, such as ownership, status, purpose, version (possibly operations also) and dependencies. As a model element, it should be referable by any URL/URI scheme that can reference model elements.

  • Reported: UML 2.5 — Mon, 11 Jan 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML Associate an image/icon with each model element

  • Key: UMLR-199
  • Legacy Issue Number: 14939
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    UML should support the ability to associate an image/icon with each model element. Current approaches only allow a stereotype based approach. Each model instance should be able to have its own icon.

  • Reported: UML 2.5 — Mon, 11 Jan 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Reconcile the algebra of collections across OCL & UML’s intentional & extensional semantics

  • Key: UMLR-184
  • Legacy Issue Number: 14356
  • Status: open  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    Reconcile the algebra of collections across OCL & UML’s intentional & extensional semantics & test this statically with OCL & dynamically with OCL & fUML scenarios. Bran,

    Your comments and those from Dave Hawkins & Salman Qadri confirm my
    suspicions that it would be unwise to submit a resolution to 8023 in ballot 10; I won’t.

    Dragan Milicev’s paper is really excellent; I’m really glad you pointed this out.
    I highly recommend this paper for consideration in the UML2 RFI workshop:

    On the Semantics of Associations and Association Ends in UML
    Milicev, D.;
    Software Engineering, IEEE Transactions on
    Volume 33, Issue 4, April 2007 Page(s):238 - 251
    http://ieeexplore.ieee.org/search/wrapper.jsp?arnumber=4123326

    Dragan clearly states that his formalization of association is squarely in
    the domain of intentional semantics; not extensional semantics as stated in
    clause 7.3.3:

    “An association describes a set of tuples whose values refer to typed
    instances. An instance of an association is called a link.”

    This paper points to a fundamental limitation in the way the runtime
    semantics of the UML2 has been specified in clause 6.3.1 in the domain of
    extensional semantics:

    “Classes, events, and behaviors model sets of objects, occurrences, and
    executions with similar properties. Value specifications, occurrence
    specifications, and execution specifications model individual objects,
    occurrences, and executions within a particular context.”

    The real problem here isn’t in the fact that there are two different ways to
    specify the semantics of associations ­ the restrictive interpretation in
    Dragan’s terminology which is really an extensional semantics and the
    intentional semantics Dragan proposes which I believe is fundamentally
    correct (as far as I’ve read it).

    The real problem is in the semantic mismatch between the extensional & intentional semantics of associations (assuming Dragan is right).
    The current extensional semantics of the UML2 is based on an impoverished notion of collections: sets & sequences.
    Dragan’s intentional semantics for associations involves the same categories of collections that OCL uses: sets, sequences & bags (see clause 7.5.11 in ocl2/ocl2.1)

    What this all means is that we need to focus an RTF cycle on reconciling the algebra of collections across OCL & the extensional & intentional semantics of UML2 and of fUML.
    The goal of this reconciliation is twofold:

    we should be able to specify all necessary well-formedness constraints on the relationship between M1 & M0 in OCL
    we should be able to use fUML to exercise relevant scenarios of events starting in one M1/M0 context and finishing in another M1/M0’ context and specify in OCL well-formedness constraints on the relationship between M0/M0’ as a function of the events processed & the behavior that happened as a result of processing by some active object (see clause 6.4.2).

    We can use the fUML subset to scope this reconciliation effort to something manageable as an RTF; learn from this experience and use that to tackle more exotic things like state machines.

  • Reported: UML 2.5 — Tue, 8 Sep 2009 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML: Issue with stereotype icons in a profile

  • Key: UMLR-183
  • Legacy Issue Number: 14227
  • Status: open  
  • Source: International Business Machines ( Mr. Gary Johnston)
  • Summary:

    Currently, a profile can include an icon for a stereotype. This means that a stereotype can have just one icon. If a stereotype extends more than one UML metaclass the profile designer might want to include different icons depending on which of the metaclasses the stereotype is applied to. For example, if I define a stereotype <Foo> that extends both <metaclass> Interface and <metaclass> Class, I will probably want a different icon for the two different usages of <Foo> but there is no way to define more than one icon per stereotype.
    The suggestion is that one should be able to specify an icon for the extension relationship between a stereotype and metaclass instead of (or in addition to, perhaps) on the stereotype itself. Profile authors would then be able to assign distinct icons for different stereotype usages. And UML tools would then be able to display distinct icons in such cases.
    This issue came up during discussions of the in-progress SoaML specification & profile. One of its stereotypes (<ServiceInterface>) extends both Class and Interface and the icons for each should be visually distinct. Currently, profiles don't provide a way to make this happen.

  • Reported: UML 2.5 — Thu, 27 Aug 2009 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

The spec may require some clarification regarding figure 14.16

  • Key: UMLR-182
  • Legacy Issue Number: 14186
  • Status: open  
  • Source: Anonymous
  • Summary:

    The spec may require some clarification regarding figure 14.16 .

    I believe that "PIN" is just an attribute of the interaction "UserAccepted" but it may be unclear from the picture alone.

    In addition, how can the local attribute PIN be passed as a parameter to the operation Code()? On the message "Code" would we specify an attribute of type Opaque Expression and use PIN ? This seems to break the formal link between PIN the attribute and PIN the argument.

  • Reported: UML 2.5 — Tue, 11 Aug 2009 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Need notation option to show type stereotype on typed element

  • Key: UMLR-181
  • Legacy Issue Number: 14183
  • Status: open  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    A part (property, port, etc.) of a class is a TypedElement and can of course have applied stereotypes of its own. However, it is often useful to know not only the Type of a TypedElement, but how that type is stereotyped. This would provide more complete information about the type that helps communicate the meaning of the model.

    Some tools by default show the stereotypes of a type on parts typed by that type. For example, if Interface Purchasing is stereotyped as <<Provider>>, a port typed by that Interface might be displayed as <<Provider>>purchaser: Purchasing. But this is actually incorrect because it shows <<Provider>> extending a Port while the stereotype is defined to extend Inteface, not Property.

    UML2 should provide a notation option to allow Type stereotype names to be displayed in TypedElements. The example above could be more correctly shown as purchaser: <<Provider>> Purchasing - the stereotype for the interface is next to the interface, on the other side of the colon. If the Port is a <<Service>> port, then that would be shown as <<Service>>purchaser: <<Provider>>Purchasing.

  • Reported: UML 2.5 — Thu, 6 Aug 2009 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Stereotyped Constraints in UML

  • Key: UMLR-188
  • Legacy Issue Number: 14544
  • Status: open  
  • Source: Alion Science and Technology ( Mr. James L. Logan III)
  • Summary:

    The UML 2.2 spec (ptc/2008-05-05) does not allow showing only a constraint name in braces. I have found this non-standard feature very valuable when working with business users and would like to see it allowed.

    The most flexible way to use constraints is to have a short, informal English description as the name, and real OCL as the formal expression. Having the flexibility to show either the name or the expression gives the best of two worlds: business SMEs can read and validate the informal English name while tools can use the OCL expression to actually enforce the constraints. In addition, a diagram can present a view for business SMEs or a view for technical people.

    I recommend changing the notation from this:

    <constraint> ::= '

    {' [ <name> ':' ] <Boolean-expression> '}

    '

    to this:

    <constraint> ::= '

    {' [ <name> ] ':' <Boolean-expression> | <name> '}

    '

    This change would allow:

    the author to choose to show:
    only { : expression } for technical users (a common practice)
    only

    { name }

    for non-technical users (a currently disallowed but important practice)
    both

    { name : body }


    the viewer to tell the difference between the name and the expression when only one is shown
    consistency with the way several other things work in UML, such as:
    action names
    action pin names
    instance specification names (i.e., just shows the name when there's no type)

    attributes (i.e., one can suppress the ": Type")

  • Reported: UML 2.5 — Thu, 8 Oct 2009 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Stereotyped Constraints in UML

  • Key: UMLR-187
  • Legacy Issue Number: 14536
  • Status: open  
  • Source: Alion Science and Technology ( Mr. James L. Logan III)
  • Summary:

    In the UML 2.2 spec (ptc/2008-05-05), there is no way to show that a constraint on a class has a stereotype or stereotype tags. I would like to see something with nested braces. For example, { <<stereotype>> constraint1: body

    {tag1=value, tag2=value}

    }.

    I recommend changing the notation from this:

    A Constraint is shown as a text string in braces ({}) according to the following BNF:

    <constraint> ::= '

    {' [ <name> ':' ] <Boolean-expression> '}

    '

    to this:

    A Constraint is shown as a text string in braces ({}) according to the following BNF:

    <constraint> ::= '{' [ <stereotypes> ] [ <name> ':' ] <Boolean-expression> [ '

    {' <valuestring> '}

    ' ] '}'

    The <stereotypes> and <valuestring> use the presentation options described in 18.3.8 (Stereotype).

  • Reported: UML 2.5 — Wed, 7 Oct 2009 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Property subsets other regular property, non-derived union

  • Key: UMLR-191
  • Legacy Issue Number: 14928
  • Status: open  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    Property subsets other regular property, non-derived union. I would like to get rid of that as it causes implementation overhead costs, we must manage and synchronize two collections.

    Association::memberEnd is not union but is subsetted
    Class::ownedAttribute is not union but is subsetted
    TemplateSignature::parameter is not union but is subsetted

  • Reported: UML 2.5 — Fri, 8 Jan 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

are Create messages aynch or synch, or doesn't it matter?

  • Key: UMLR-190
  • Legacy Issue Number: 14588
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    In 14.3.24, the textual definition of MessageSort is badly formatted, which needs to be fixed. Then it provides for messages of sorts synchCall, asynchCall, asynchSignal, createMessage, deleteMessage and reply.

    So is a createMessage synchronous, or asynchronous, or can it be either? The semantics of CreateObjectAction say “The new object is returned as the value of the action” - which implies that synchronous ought to be a possibility. But chapter 14 appears silent on this topic.

  • Reported: UML 2.5 — Wed, 28 Oct 2009 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML 2 TemplateParameterSubstitution inconsistency about multiplicity of Actual and OwnedActual

  • Key: UMLR-189
  • Legacy Issue Number: 14555
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    In the model, Actual is shown as 1.* and OwnedActual is shown as *.

    In the text 17.5.5, Actual is shown as 1 and OwnedActual is shown as 0..1.

  • Reported: UML 2.5 — Mon, 12 Oct 2009 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

PrimitiveType has missing constraints

  • Key: UMLR-186
  • Legacy Issue Number: 14449
  • Status: open  
  • Source: gmail.com ( Guus Ramackers)
  • Summary:

    The UML specification text for PrimitiveType states that it has no operationsnor attributes:

    "A primitive type defines a predefined data type, without any relevant substructure (i.e., it has no parts in the context of
    UML). A primitive datatype may have an algebra and operations defined outside of UML, for example, mathematically."

    However, because PrimitiveType is a subtype of DataType in the spec, it inherits the ability have attributes and operations.

    Constraints need to be added to restrict this, or else PrimitiveType should not specialize DataType.

    The current situation is confusing to tool vendors. Potentially any imported XMI might have a PrimitiveType with attributes and operations defined according to the specification.

  • Reported: UML 2.2 — Mon, 5 Oct 2009 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML Issue: Refactor UML to separate SW-Specific Aspects from Foundation Language

  • Key: UMLR-193
  • Legacy Issue Number: 14933
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Refactor UML to separate SW-Specific Aspects from Foundation Language

    One useful refactoring would be to separate UML into a abstract modeling part and a software model part, so that other standards can base themselves on the abstract modeling piece without the baggage of software specific features. We would not want to encourage programming language-specific profiles, but wish to take out things such as components from the base UML profile.

  • Reported: UML 2.5 — Mon, 11 Jan 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

One association end is derived, another is not

  • Key: UMLR-192
  • Legacy Issue Number: 14930
  • Status: open  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    One association end is derived, another is not. It causes implementation issues, as when we set one end, opposite should be automatically set also.

    Vertex::outgoing [0..*] is derived, opposite Transition::source [1] is not
    Activity::structuredNode [0..*] is derived, opposite StructuredActivityNode::activity [0..
    ConnectableElement::end [0..*] is derived, opposite ConnectorEnd::role [1] is not
    Package::ownedType [0..*] is derived, opposite Type::package [0..] is not
    Package::nestedPackage [0..*] is derived, opposite Package::nestingPackage [0..] is not
    Vertex::incoming [0..*] is derived, opposite Transition::target [1] is not

  • Reported: UML 2.5 — Fri, 8 Jan 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Simplify by Making UML More Consistent: Allow States to be model as classes supporting inheritance and composition

  • Key: UMLR-195
  • Legacy Issue Number: 14935
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    In OMT, states could be modeling on the class diagram, which was a powerful alternative approach to capture the structure of a state machine. It made clear the relationships between entry/exit actions of superstates on substates, the ability to override responses to trigger/actions pairs of superstates by a substate, the scope of a defer, what a history node really does, etc. understandable in a way that statemachines don’t do because of their different presentation style. This should also restore the ability to identify state-specific attributes and constraints, and the ability to specify parameters on the state’s possible behaviors – two features that have often been requested. Restoring this ability will make UML treatment of states more like their treatment for classes. Similar ideas have been periodically proposed, see http://www.conradbock.org/statemachine.html.

  • Reported: UML 2.5 — Mon, 11 Jan 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Simplify by Making UML More Consistent: Apply class and composite structure diagram rules to behavior modeling

  • Key: UMLR-194
  • Legacy Issue Number: 14934
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Simplify by Making UML More Consistent: Apply class and composite structure diagram rules to behavior modeling.

    One problem with UML now is that the ability to simplify by applying more consistency is not taken advantage of. By being consistent – eliminating special cases, the specification becomes smaller, the modelers have to learn less, the tools can reuse code, and UML becomes easier to understand and use.

    As behaviors (e.g., operations, activities) are classifiers, there is no good reason why the class and composite structure diagrams cannot be used to model them. This would allow for diagrams showing inheritance, composition, associations, dependencies, etc. While this may not be “OO”, it would support functional decomposition/programming approaches, simplify, and make more regular the specification. See the RFI response ad/2009-08-05.

  • Reported: UML 2.5 — Mon, 11 Jan 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML: Include text description field with model element

  • Key: UMLR-198
  • Legacy Issue Number: 14938
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    While almost every tool supports the concept of a model element specification, they are not consistent on which elements can have them nor are they consistent on the contents/typing of the specification. Please make model element specification available on ALL elements and make the format and content a rich field.

  • Reported: UML 2.5 — Mon, 11 Jan 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML: Incorporate SysML Requirements Model into UML

  • Key: UMLR-197
  • Legacy Issue Number: 14937
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Software Developers, and any people who are using UML as a core language can use the ability to capture /categorize requirements

  • Reported: UML 2.5 — Mon, 11 Jan 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML: Need more robust value model that would enable capture of values vs time

  • Key: UMLR-196
  • Legacy Issue Number: 14936
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Current timing model does not enable useful capture/mapping of values vs time. UML does support initial values and current values, but not evolving values. This is necessary for proper description of the behavior, capture of simulations, requirements development

  • Reported: UML 2.5 — Mon, 11 Jan 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

InterfaceRealization

  • Key: UMLR-148
  • Legacy Issue Number: 12860
  • Status: open  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    InterfaceRealization.contract and InterfaceRealization.implementingClassifier currently subset Dependency.supplier and Dependency.client respectively.

    It seems to be that redefinition is a more appropriate relationship between these attributes, because InterfaceRealization.supplier and InterfaceRealization.client (as inherited) are restricted to the multiplicities of, and will always have the exactly the same values as, InterfaceRealization.contract and InterfaceRealization.implementingClassifier.

  • Reported: UML 2.5 — Fri, 27 Jun 2014 11:17 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

issue to address how problem 11240 was actually addressed in UML 2.2 spec

  • Key: UMLR-147
  • Legacy Issue Number: 12852
  • Status: open  
  • Source: Anonymous
  • Summary:

    believe we need to raise a new issue to address how problem 11240 was actually addressed in the UML 2.2 spec.

    If I'm not mistaken, the fix for issue 11240 should involve redefining TemplateParameter::default and constraining the type to Classifier. However, all that was actually done to address the problem was to remove the offending (redundant) "defaultClassifier" property. The original issue: http://www.omg.org/issues/uml2-rtf.html#Issue11240 , makes mention of the redefinition.

  • Reported: UML 2.5 — Thu, 11 Sep 2008 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Figure 7.65 and its explanation, P115

  • Key: UMLR-146
  • Legacy Issue Number: 12837
  • Status: open  
  • Source: Architecture Technology Institute ( Hiroshi Miyazaki)
  • Summary:

    there is a following description:
    "A in package P3(P3::A) represents the result of the merge of P1::A into
    P2::A and not just the incremnetP2::A."

    According to definition of Package import,
    If the name of an imported element is the same as the name of an element
    owned by the importing namespace, that element is not added to the importing namespace.

    Therefore, if there is same name A on the Pacakge"P3", P2::A is invisible from P3?

  • Reported: UML 2.5 — Mon, 8 Sep 2008 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section: 15.3.7 Constraint [2]

  • Key: UMLR-138
  • Legacy Issue Number: 12354
  • Status: open  
  • Source: Logica ( Tis Veugen)
  • Summary:

    Constraint [2] says: A protocol transition never has associated actions. My problem is that this constraint makes it impossible to specify a consistent pair of a server protocol state machine (PSM) and a client PSM. The server PSM has call events as triggers. It also has internal events causing autonomous state transitions. However, the latter transitions must be notified to the client PSM. This can only be done by actions in which signal events are generated to the client FSM. Such signals are the triggers in the client FSM; and in fact the same problem happens here. Since the call events to the server PSM are caused by internal events at the client PSM, that force call events to the server PSM in the actions. I hope this issue can be solved or at least clarified. Thanks.

  • Reported: UML 2.1.2 — Sun, 23 Mar 2008 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML Super 2.1.2: section 18.3.2

  • Key: UMLR-137
  • Legacy Issue Number: 12285
  • Status: open  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    In the semantics section the spec says

    “When the extension is required, then the cardinality on the extension stereotype is “1.” The role names are provided using the following rule: The name of the role of the extended metaclass is: ‘base_’ extendedMetaclassName The name of the role of the extension stereotype is: ‘extension$_’ stereotypeName.”

    I have two issues with this. This first is that in all example that follows – the extension role names don’t have a dollar in them and so are inconsistent with the spec.

    Secondly, I think this should say that these are the default names if the modeller doesn’t provide any. In fact later on in the Presentation Options section of 18.3.8, the spec says:

    “If the extension end is given a name, this name can be used in lieu of the stereotype name within the pair of guillemets when the stereotype is applied to a model element.”

  • Reported: UML 2.5 — Wed, 19 Mar 2008 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML2 issue regarding Redefinition

  • Key: UMLR-145
  • Legacy Issue Number: 12570
  • Status: open  
  • Source: Anonymous
  • Summary:

    For practical reasons, we would like to consider certain properties of redefinable elements to be inheritable (or possibly derived from the redefined element).

    For example, if one were to redefine a property, then if the type of a redefining property were not explicitly set, it could inherit (or derive) the type from the redefined property. This would save on space in the serialized model and also help keep the model in a consistent state at all times, if for example the type of the redefined property were to change.

    Currently, there are constraints mentioning that the Type of the redefining property must be 'consistent' with that of the redefined property, any resolution would have to consider modifying such constraints to take redefinition into account.

    Other properties that could be considered inherited would be do/entry/exit actions of a state and, target of a transition amongst others.

    I believe this might be a similar argument to issue 12530.

  • Reported: UML 2.5 — Thu, 10 Jul 2008 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section: 14.3.24, 14.3.20

  • Key: UMLR-144
  • Legacy Issue Number: 12568
  • Status: open  
  • Source: Motorola ( Andrzej Zielinski)
  • Summary:

    Problem 5 5.1 Interactions diagrams shows messages that are type of MessageSort (from Interactions/BasicInteractions, level L1). There is no way to express that a message is an exception. Only signals and calls are expressed. Exception is none of them ++++++++++++++++++++++++++++++++++++++++++ from Bran Selic <bran.selic@gmail.com> hide details Jun 9 to Andrzej Zielinski <072404@gmail.com> date Jun 9, 2008 7:46 PM subject Re: UML 2.x issues mailed-by gmail.com Bran Selic: Agreed

  • Reported: UML 2.1.2 — Thu, 10 Jul 2008 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML 2.1.2 Super: Execution Specification

  • Key: UMLR-139
  • Legacy Issue Number: 12355
  • Status: open  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    The description for Execution Specification says:

    “An ExecutionSpecification is a specification of the execution of a unit of behavior or action within the Lifeline. The

    duration of an ExecutionSpecification is represented by two ExecutionOccurrenceSpecifications, the start

    ExecutionOccurrenceSpecification and the finish ExecutionOccurrenceSpecification.”

    This sounds right to me. However, the association ends ‘start’ and ‘finish’ are to the more general OccurrenceSpecification, thus:

    “Associations

    • start : OccurrenceSpecification[1]

    References the OccurrenceSpecification that designates the start of the Action or Behavior.

    • finish: OccurrenceSpecification[1]

    References the OccurrenceSpecification that designates the finish of the Action or Behavior.”

    The semantics also refer to OccurrenceSpecification.

    “Semantics

    The trace semantics of Interactions merely see an Execution as the trace <start, finish>. There may be occurrences

    between these. Typically the start occurrence and the finish occurrence will represent OccurrenceSpecifications such as a

    receive OccurrenceSpecification (of a Message) and the send OccurrenceSpecification (of a reply Message).”

    The spec should make the description, association and semantics sections consistent.

  • Reported: UML 2.5 — Tue, 25 Mar 2008 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section: 18.3.3

  • Key: UMLR-136
  • Legacy Issue Number: 12279
  • Status: open  
  • Source: OFFIS e.V. ( Christian Mrugalla)
  • Summary:

    Section 18.3.3 states, that "An ExtensionEnd is never navigable. If it was navigable, it would be a property of the extended classifier". Whereas in section 7.3.3 (Association) on page 43, it is stated that: "Navigability notation was often used in the past according to an informal convention, whereby non-navigable ends were assumed to be owned by the association whereas navigable ends were assumed to be owned by the classifier at the opposite end. This convention is now deprecated. Aggregation type, navigability, and end ownership are orthogonal concepts [...]" The mentioned description in ExtensionEnd seems to contradict the definition of an Association. For the UML Profile Extension Mechanism two issues are essential to be clarified: 1) Is it possible, that an ExtensionEnd (which is owned by the Extension instead of the extended Class) is navigable? 2) Is it possible in a UML-Profile to define an Association which relates a Stereotype with a metaclass and which is navigable on both association ends (if the association end which refers to the stereotype is owned by the association itself instead of by the extended class)? [unidirectional Associations navigable from a stereotype to the extended metaclass seem to be allowed, as exemplified in the SysML 1.0 Standard at page 164]

  • Reported: UML 2.1.2 — Fri, 14 Mar 2008 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

role bindings of a CollaborationUse

  • Key: UMLR-142
  • Legacy Issue Number: 12544
  • Status: open  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    Using a simple Dependency to define the role bindings of a CollaborationUse seems too "light". I suggest to change for a Realization relationship which has a stronger - and i think more convenient - semantic.

  • Reported: UML 2.1.1 — Mon, 23 Jun 2008 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Actors cannot own Operations - a contradiction

  • Key: UMLR-149
  • Legacy Issue Number: 12942
  • Status: open  
  • Source: Anonymous
  • Summary:

    The ability for an Actor to implement an Interface was added as a result of this issue against the UML2 specification: http://www.omg.org/issues/uml2-rtf.html#Issue8078

    Because an Actor is now a BehavioredClassifier it can implement interfaces, but according to the UML superstructure specification, Actors cannot own Operations. This situation seems to contradict the semantics for InterfaceRealization (UML Superstructure v2.1.2 section 7.3.25):

    "An interface realization relationship between a classifier and an interface implies that the classifier supports the set of
    features owned by the interface, and any of its parent interfaces. For behavioral features, the implementing classifier will
    have an operation or reception for every operation or reception, respectively, defined by the interface."

  • Reported: UML 2.5 — Wed, 8 Oct 2008 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

18.3.8 Generalization of stereotyped model elements

  • Key: UMLR-150
  • Legacy Issue Number: 13058
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    It is not clear whether it is allowed to have a generalization relationship between two model elements that have different stereotypes. Please clarify in the uml specification

  • Reported: UML 2.2 — Thu, 6 Nov 2008 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

3 3.2 Behavior (CommonBehaviors/BasicBehaviors)

  • Key: UMLR-143
  • Legacy Issue Number: 12566
  • Status: open  
  • Source: Motorola ( Andrzej Zielinski)
  • Summary:

    Problem 3 3.2 Behavior (CommonBehaviors/BasicBehaviors) is having relationship redefinedBehavior, that should be derived

  • Reported: UML 2.1.2 — Thu, 10 Jul 2008 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Notation for ordering action input and output pins

  • Key: UMLR-82
  • Legacy Issue Number: 9400
  • Status: open  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    Input and output pins of an action in an activity are ordered, and their order corresponds to the order of the parameters of actions such as CallOperationAction or CallBehaviorAction. This is the only way pins correlate with their corresponding parameters. A Pin has no direct ownedAttribute that refers to its corresponding Parameter.

    Ordering is sufficient for correlating pins with parameters, but it is difficult to visualize on a diagram. An action may have many input and output pins oriented around the action, and there is no way to visually determine which pin is associated with which parameter. In many cases, the pin name may correspond directly to the parameter name providing a visual connection. However, this is not possible for ActionInputPins or ValuePins where the pin name refers to some structural feature or value specification.

    UML2 should consider a presentation option that shows pins ordered starting from the bottom right corner of the action and following clockwise around the action ending at the right bottom side. The first pin is always the target input pin for a CallOperationAction. The last pin corresponds to the return parameter if any.

    This makes pin ordering visible in the diagrams, and establishes an unambiguous correlation between pins and parameters in call actions. However, it may result in some layout restrictions and extra object flow crossings in diagrams. This should not be much of an issue in practice because the pins can be moved around the edge of the action, just not reordered. And ActionInputPins allow reference to inputs without requiring explicit object flows.

  • Reported: UML 2.5 — Tue, 28 Feb 2006 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

All associations ends in the UML2 metamodel itself should be navigable

  • Key: UMLR-81
  • Legacy Issue Number: 9371
  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    A) All associations ends in the UML2 metamodel itself should be navigable
    The top of section 6.5.2 states that "An association with one end marked by a navigability arrow means that:
    • the association is navigable in the direction of that end,"

    This does not make sense now that navigability has nothing to do with property ownership and is used in effect to indicate a requirement for efficient access.
    However there is no justification for non-navigability in the context of the UML metamodel itself (which is in effect an application model/specification of a UML tool). Given that most users of UML tools would reasonably expect to do 'where used' navigations/queries with reasonable efficiency then there seems to be no reason for having ends owned by Associations being non-navigable. Furthermore OCL and QVT engines would also expect efficient traversal.
    An important case in point is that currently the association end from an Element to its applied Stereotypes is marked 'non-navigable' using the old notation. While there is an argument for not having a property on the Element itself, navigating the association from Element to its applied Stereotypes is an important access that any tool would require to be very efficient (e.g. to allow the tool to display the stereotype name/icon on diagrams where the element appears).
    When UML2 was designed, the arrows were used to mean property ownership only. We should honor that design intent.

    Proposed resolution:
    At top of section 6.5.2 replace:
    "An association with one end marked by a navigability arrow means that:
    • the association is navigable in the direction of that end,
    • the marked association end is owned by the classifier, and
    • the opposite (unmarked) association end is owned by the association.
    With:
    "An association with one end marked by a navigability arrow means that:
    • the marked association end is owned by the classifier, and
    • the opposite (unmarked) association end is an owned navigable end of the association.

    Alternative resolution:
    Redraw all diagrams to not show the deprecated notation of using navigability arrows to indicate ownership.

  • Reported: UML 2.5 — Thu, 23 Feb 2006 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section: Sequence diagrams

  • Key: UMLR-80
  • Legacy Issue Number: 9370
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    A "par"-like operator with two concurrent regions where one region is interrupted when the other is completed. According to me, the only way to express the same semantics today is to use many nested "opt" operators, which is not practical. I am under the impression that this should be quite a common need.

  • Reported: UML 2.0 — Tue, 21 Feb 2006 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Unnecessary restriction on aggregations being binary

  • Key: UMLR-88
  • Legacy Issue Number: 9701
  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    There seems to be no reason why n-ary Associations are required to have aggregation=none: there should be a restriction that this is allowed for at most one End but it could reasonably be allowed

  • Reported: UML 2.5 — Thu, 4 May 2006 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

New issue on notation for multiple stereotypes

  • Key: UMLR-87
  • Legacy Issue Number: 9599
  • Status: open  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Description of Problem

    Section 18.3.8 has the following paragraph:

    Presentation Options If multiple stereotypes are applied to an element,
    it is possible to show this by enclosing each stereotype name within a
    pair of guillemets and listing them after each other. A tool can choose whether it
    will display stereotypes or not. In particular, some tools can choose not to
    display “required stereotypes,” but to display only their attributes (tagged
    values) if any.

    Annex B has the following paragraph:

    If multiple keywords and/or stereotype names apply to the same model element,
    they all appear between the same pair of guillemets, separated by commas:
    “«” <label> [“,” <label>]* “»”

    These two paragraphs seem to contradict each other, since the annex B does
    not allow multiple guillemet pairs for the same element, while 18.3.8 does.

    Proposed Solution:
    Add clarification that Both presentation options should be allowed.

  • Reported: UML 2.5 — Mon, 24 Apr 2006 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Link notation for instance diagrams does not cope with multiple classifiers

  • Key: UMLR-86
  • Legacy Issue Number: 9445
  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    Figure 7.54 of ptc/06-01-02 shows an Instance Diagram notation for a
    Link.
    With the accompanying text:
    "An instance specification whose classifier is an association represents
    a link and is shown using the same notation as for
    an association, but the solid path or paths connect instance
    specifications rather than classifiers. It is not necessary to
    show an underlined name where it is clear from its connection to
    instance specifications that it represents a link and not
    an association. End names can adorn the ends. Navigation arrows can be
    shown, but if shown, they must agree with the
    navigation of the association ends."

    However this does not cater for the fact that the metamodel allows an
    InstanceSpecification to be associated with many Classifiers.

    Proposed resolution:
    Extend the metamodel for Instances to explicitly model Links. For a good
    start see the instances model in the MOF2 Core Abstract Semantics
    chapter (it is not part of MOF - it is only there to explain the
    semantics of MOF in terms of metamodel instances).

  • Reported: UML 2.5 — Wed, 15 Mar 2006 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Guidance for Representing Enumeration Values

  • Key: UMLR-97
  • Legacy Issue Number: 9842
  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    Guidance should be given as to how to use the properties of
    EnumerationLiteral to represent the typical scenario of an
    EnumerationLiteral having a distinct value and meaning e.g. the color
    Blue is represented as the code B or the number 5. In this case I would
    expect the name of the EnumerationLiteral to be "Blue" with an
    associated LiteralString (via inherited property
    InstanceSpecification::specification) of "B" or LiteralInteger of 5. The
    notation for this could be that for default values e.g. Blue = "B" in
    the 'attribute' compartment. Or alternatively the InstanceSpecification
    syntax could be used as per Figure 7.52.

  • Reported: UML 2.5 — Tue, 27 Jun 2006 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section: 15.3.12, p 588, 589

  • Key: UMLR-96
  • Legacy Issue Number: 9840
  • Status: open  
  • Source: Engenuity Technologies, Inc. ( Mikon Dosogne)
  • Summary:

    There are 3 kinds (TransitionKind) of transitions: internal, external and local. Are there firing priorities between these? For example, consider the case of an internal transition within a state and an external transition with same state as its source state, triggered by the same event, with no guard conditions. If that event occurs, which transition(s) will fire? The standard states, "An internal transition in a state conflicts only with transitions that cause an exit from that state," but neither the firing priorities nor the transition selection algorithm define how such a conflict should be resolved.

  • Reported: UML 2.1.1 — Mon, 26 Jun 2006 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Relationships

  • Key: UMLR-95
  • Legacy Issue Number: 9834
  • Status: open  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    Why Transition, ActivityEdge, Message, Connector are not Relationships?
    At least Transition and ActivityEdge should be DirectedRelationships in my opinion.

    If this is done intentionally, please explain, otherwise please register an issue.

  • Reported: UML 2.5 — Tue, 20 Jun 2006 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

ControlNodes in ActivityPartitions

  • Key: UMLR-83
  • Legacy Issue Number: 9401
  • Status: open  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    ControlNodes, like any other ActivityNode or ActivityEdge can be contained in an ActivityPartition. Containment in a partition can be designated either using swimlanes or by denoting the partition names in parenthesis above the ActivityNode name.

    This is generally fine, but can result in significant layout problems when swimlanes are used to designate activity partitions. UML2 does not define any semantics for ControlNodes or ActivityEdges belonging to an ActivityPartition, so they generally do not belong to any partition. When swimlanes are used, the nodes that do not belong in any partition have to be displayed someplace. One convention is to create a default swimlane for these nodes that for example could appear as a partition with the same name as the activity. This results in extreme layout issues as all the control nodes end up being in the same partition resulting in very ugly diagrams with flow lines crossing partitions everywhere. If a user attempts to layout the diagram by moving the control nodes, this results in edits to the underlying model, something that the user may not have intended, or many not have permission to do. Some tools allow editing diagrams on read only models as long as the edits don't result in any changes to the model. This is especially common for diagrams that include views of other models in order to establish a context and show referenced elements.

    Another problem is activity edges which cross many swimlanes while connecting their source and target. It is unclear from the notation in which of these partitions the edge should be included: none of them, all of them, or only the partitions at their connection points.

    UML2 should consider a presentation option or notation convention that ControlNodes and ActivityEdges do not belong to ActivityPartitions unless explicitly shown using the partition name in parenthesis above the node or edge name. Putting a control node or edge in a swimlane should not imply that the node or edge is in the corresponding partitions. The notation should require that these element explicitly state the partitions they belong to.

  • Reported: UML 2.5 — Tue, 28 Feb 2006 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML2: No notation for indicating Operation::raisedException

  • Key: UMLR-85
  • Legacy Issue Number: 9406
  • Status: open  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    Section 7.3.36 specifies the notation for Operation, but there is no notation for denoting raisedExceptions. Section 12.3.41 introduces Parameter::isException and suggests exception parameters are indicated out parameters with

    {exception}

    after the parameter type to indicate Parameter::isException=true.

    However, Operation::raisedException is not a Parameter, it is a reference to a Type. So a raisedException is not a TypedElement like parameter, has no multiplicity or ordering, etc. Raised exceptions are quite different than parameters and even in activities, RaiseExceptionAction and ExceptionHandlers do not exchange exception data through parameters.

    Consider adding <oper-property> ::= 'throws' '('<type-list>')' in section 7.3.36 for denoting exceptions that could be raised by an operation. This is a significant part of the specification of an operation indicating information clients must know in order to use the operation and should be clearly visible in the operation's signature.

  • Reported: UML 2.5 — Wed, 1 Mar 2006 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Reception has no notation for its signal

  • Key: UMLR-84
  • Legacy Issue Number: 9402
  • Status: open  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    There doesn't appear to be any notation of indicating the signal of a Reception. Reception may also be missing a constaint similar to SendSignalAction where the parameters of the BehavioralFeature have to match the ownedAttributes of the Signal in number, order, and type.

  • Reported: UML 2.5 — Tue, 28 Feb 2006 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Unclear usage of LiteralExpression::type

  • Key: UMLR-90
  • Legacy Issue Number: 9703
  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    LiteralExpression inherits a type property but its use, semantics and notation are not documented. There should at least be appropriate constraints e.g. that LiteralString.type is a subtype of PrimitiveTypes::String.

  • Reported: UML 2.5 — Thu, 4 May 2006 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Default value types

  • Key: UMLR-94
  • Legacy Issue Number: 9805
  • Status: open  
  • Source: Eclipse Foundation ( Mr. Kenneth Hussey)
  • Summary:

    The type of a default value should conform to the type of the property/parameter that owns it. Constraints to that effect should be added to the UML specification.

  • Reported: UML 2.5 — Tue, 6 Jun 2006 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section: 7.3.33

  • Key: UMLR-93
  • Legacy Issue Number: 9754
  • Status: open  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Sebastien Gerard)
  • Summary:

    I believe it would be interesting formodelling to be abble to add a feature to the coenpt of NamedElement in order to be abble to define a short name (e.g. an acronym). I propose to add the property: - shortName: String [0..1] the abreviation or acronym assocatied to the NamedElement

  • Reported: UML 2.1.1 — Tue, 23 May 2006 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

ValueSpecification::isComputable()

  • Key: UMLR-91
  • Legacy Issue Number: 9705
  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    ValueSpecification::isComputable() introduces conformance requirements not captured in compliance points.
    Section 7.3.54, Additional Operations states : "A conforming implementation is expected to deliver true for this operation for all value specifications that it can compute, and to compute all of those for which the operation is true. A conforming implementation is expected to be able to compute the value of all literals."

  • Reported: UML 2.5 — Thu, 4 May 2006 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Alternative entry and exit point notation is ambiguous

  • Key: UMLR-32
  • Legacy Issue Number: 7952
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Alternative entry and exit point notation is ambiguous. It is not clear if it relates to an entry point or to an exit point.

  • Reported: UML 2.0 — Mon, 29 Nov 2004 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Coupling between StateMachines and Activities

  • Key: UMLR-31
  • Legacy Issue Number: 7620
  • Status: open  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    As I was reading through the text of issue 6114 it dawned on me that there is a needless and problematic coupling between state machines and activities. Namely, in figure 187, there is an association from ObjectNode to State, presumably to deal with the old "object in state" idea. This is similar to the coupling that was attempted but rejected in the Interactions chapter.

    While it may look attractive to have a formal link to the idea of State from state machines, there are two serious problems that make this much more trouble than it's worth:

    (1) The notion of "object state" – as seen by users/manipulators of that object – could be completely different from the implementation state of that object. This is the old principle of hiding implementation. Viewed from the outside, an invoice object may be in the "Paid" state, but this does not necessarily mean that the object has such a state in its implementation. In fact, there is no guarantee that the implementation will be based on state machines at all. Of course, you can say that this is a reference to some kind of external state machine view of an object – which sounds reasonable, but here is where the second problem comes in:

    (2) State in the UML 2.0 spec comes with a sh..load of baggage: in effect, the whole state machine kit and caboodle. It's not very modular, and, unless you use profiles to shear away all the stuff that you don't want (which is about 99% of state machines machinery), you will force vendors who innocently just want to support the simple idea of "object in state" to implement all of state machines.

    Like I say, the feature doesn't look worth it. Let your State concept be a simple name. My guess is that most users who want to use this feature don't even want to know what a state machine is (the concept of states is not necessarily linked to state machines!).

    So, my suggestion is that in figure 187, you simply provide a subclass of ObjectNode called ObjectInState and give it a "stateName" attribute and you will get what 95% of your users want. Tying state machines to activities for that one little feature seems overkill.

  • Reported: UML 2.5 — Wed, 4 Aug 2004 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Too much navigability from Generalizations

  • Key: UMLR-33
  • Legacy Issue Number: 7997
  • Status: open  
  • Source: Capability Measurement ( Karl Frank)
  • Summary:

    his is a significant issue with the Superstructure, Classes chapter, PowerTypes package, impacting implementability and consistency between products at different levels of conformance to UML 2.

    I propose to simplify the abstract syntax to specify a one way arrow navigating a one-many metassociation from GeneralizationSet to Generalizations that belong to that set. The problem here is very much the same as the problem with dependency, but in a different part of the metamodel.

    Figure 18, The contents of PowerTypes package shows a many-many navigable association between GeneralizationSet.generalization and Generalization.generalizationSet.

    Problems with this:

    1. only 1-way navigation is desired. As toolvendor I don't want to update the Generalization to have any info wrt what if any GeneralizationSets it belongs to. As a user, I do not want the generalization relationship itself, which is very simple in a UML Level 1 product, to be muddied with extra info in a UML product that goes beyond Level 1 by adding support for PowerSets.

    2. only 1-many cardinality is desired. Although not navigable, a mapping from generalization to the generalization set is still provided in the metamodel, in a conceptual sense.

    Point 2 is consistent with thinking of the specialization classifier in the generalization as being an instance of more than one powertype, because this classifier is just a participant in the generalization, it is the generalization that we want to have a mapping to at most one powertype. The scope of the required change is limited to the text and diagram specifying this metasssociation of GeneralizationSet.

  • Reported: UML 2.5 — Wed, 22 Dec 2004 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

ptc-03-09-15/Need for examples to include instance models

  • Key: UMLR-14
  • Legacy Issue Number: 6497
  • Status: open  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    Issue and Recommendation: In general the specification of the Core would
    benefit from instance diagrams accompanying example models, especially in
    cases where there is significant change from UML 1.x. An instance diagram
    accompanying an example model would show how the model instantiates the
    elements of metamodel. This will contribute to a greater level of common
    understanding among readers of the specification and thus will help ensure
    interoperability.

    For example, consider Figure 3-23 from the submission document and which
    defines the abstract syntax for the elements of the
    Core::Constructs::Constraints package. Despite the existence of
    accompanying explanatory text, the distinction between the Namespace that
    owns a Constraint and the Namespace that provides the context for a
    Constraint may be difficult for the reader to grasp completely. Figures
    3-24, 3-25, and 3-26 from the submission document, respectively, provide
    example models. An instance diagram for at least one of the examples that
    shows how the elements of the example model instantiate elements of
    Core::Constructs::Constraints would go a long way toward preventing
    misunderstandings. Such misunderstandings would compromise
    interoperability, since there is a high probability (in my opinion) that
    different implementers would render models to XMI differently.

    This example is only one of many that I could cite from the submission where
    examples plus associated instance diagrams would be beneficial.

  • Reported: UML 2.5 — Fri, 7 Nov 2003 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Conditions for parameter sets

  • Key: UMLR-13
  • Legacy Issue Number: 6487
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Selection behavior on object nodes should be changed to allow execution at insertion time, keeping the queue

  • Reported: UML 2.5 — Fri, 7 Nov 2003 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Clarification of use case semantics

  • Key: UMLR-11
  • Legacy Issue Number: 6445
  • Status: open  
  • Source: Anonymous
  • Summary:

    Use cases and associated sequence and activity diagrams are
    widely used by systems engineers to specify the functionality of the system,
    and describe the interaction between the system and the actors. However,
    there is much confusion regarding use case semantics. Consider the following
    recommendations to clarify use case semantics:
    a) Establish an explicit representation to depict the relationship between a
    use case and its realization as a sequence diagram, activity diagram, etc.
    In addition, allow for a similar representation to show the relationship
    between an included/extended use case, and the interaction fragments which
    realize the included/extended use case.
    b) Clarify the relationship between a use case (solid oval) and a
    collaboration (dashed oval), and determine whether they can represent the
    same or a similar concept.

  • Reported: UML 2.5 — Thu, 6 Nov 2003 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Integration between behavioral "sublanguages": Interactions and Activities

  • Key: UMLR-10
  • Legacy Issue Number: 6441
  • Status: open  
  • Source: Anonymous
  • Summary:

    Although both Sequence Diagrams and Activity Diagrams have
    added many advanced features in UML 2, these features appear to have been
    added independently, so that they appear as two separate behavioral
    languages. Consider improving the integration between them by supporting the
    following:
    a) Allow for an activity in an activity diagram to represent an invoked
    operation in a message on a sequence diagram.
    b) Allow for interaction diagram notations to be applied to activity
    diagrams, such as the use of references, alternates, and gates.
    c) Clarify that time and other constraints can be applied to an activity
    diagram in a manner similar to how they are applied to sequence diagrams.

  • Reported: UML 2.5 — Thu, 6 Nov 2003 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

ptc-03-09-15/Explain the new association modeling constructs

  • Key: UMLR-15
  • Legacy Issue Number: 6498
  • Status: open  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    Issue: The Core’s abstract syntax makes heavy use of new association
    modeling constructs. Two of them in particular may be unfamiliar to many
    who read the submission:
    · Subsets
    · Derived unions

    The submission provides only a brief explanation of these two new
    constructs, which I quote below:

    "A navigable property may be marked as a subset of another, as long as the
    owner of the subsetting property is the same as or a specialization of the
    owner of the subsetted property. In this case, the collection associated
    with an
    instance of the subsetting property must be included in (or the same as) the
    collection associated with the corresponding instance of the subsetted
    property.

    A property may be marked as being a derived union. This means that the
    collection of values denoted by the property in some context is derived by
    being the strict union of all of the values denoted, in the same context, by
    properties defined to subset it. If the property has a multiplicity upper
    bound of 1, then this means that the values of
    all the subsets must be null or the same."

    Recommendation: Since these constructs are so heavily used to define the
    Core itself, it would be useful for the submission to provide some overall
    guidance on how to use them. Providing rationale for why specific ones are
    chosen in specific places in the definition of the Core would be an
    effective way of disseminating understanding of these constructs and
    understanding of the Core as well.

  • Reported: UML 2.5 — Fri, 7 Nov 2003 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

More explanation needed on Figure 339

  • Key: UMLR-3
  • Legacy Issue Number: 6086
  • Status: open  
  • Source: Ostfold University College ( Dr. Oystein Haugen)
  • Summary:

    The Figure 339 on page 425 needs more explanation. The use of lifelines to represent return value, and the notation for interaction occurrences with return value should be explained in greater length. Furthermore it should be made clear how the operations put and get are used to set and read values from lifelines representing attributes and parameters.

  • Reported: UML 2.0 — Fri, 29 Aug 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

More examples

  • Key: UMLR-2
  • Legacy Issue Number: 6083
  • Status: open  
  • Source: Thematix Partners LLC ( Mr. James J. Odell)
  • Summary:

    The Interaction chapter contains a number of examples, but there have been requests for even more examples especially on the different kinds of combined fragments (Section 14.3.1)

  • Reported: UML 2.0 — Fri, 29 Aug 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Promote local conditions to ExecutableNode

  • Key: UMLR-5
  • Legacy Issue Number: 6137
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Promote local precondition to ExecutableNode. There might be other
    associations on Action that should be at ExecutableNode

  • Reported: UML 2.5 — Sat, 30 Aug 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Parameterization of lifelines

  • Key: UMLR-4
  • Legacy Issue Number: 6088
  • Status: open  
  • Source: Ostfold University College ( Dr. Oystein Haugen)
  • Summary:

    In general there is a need to have lifelines as formal parameters such that Interactions can be used in slightly different contexts. This may now be partly achieved through templates, but more notation etc. is needed for this to be really practical.

  • Reported: UML 2.0 — Fri, 29 Aug 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML 2 Super / State machines / Transition triggers cannot be redefined

  • Key: UMLR-9
  • Legacy Issue Number: 6395
  • Status: open  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Transition triggers do not appear to be redefinable in the current metamodel. There does not seem to be any reason for this restriction and it should be removed

  • Reported: UML 2.5 — Fri, 31 Oct 2003 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Join nodes that destroy tokens

  • Key: UMLR-8
  • Legacy Issue Number: 6368
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Would be useful if join nodes optionally destroyed tokens not accepted,
    especially when using join expressions.

  • Reported: UML 2.5 — Mon, 20 Oct 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Deployment a dependency?

  • Key: UMLR-7
  • Legacy Issue Number: 6353
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    If Artifact and Node are classifiers, why is deployment a dependency?
    Then runtime artifacts cannot be deployed to runtime nodes.

  • Reported: UML 2.5 — Mon, 20 Oct 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Notation for method

  • Key: UMLR-6
  • Legacy Issue Number: 6150
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Provide a notation for a behavior used as a method of an operation

  • Reported: UML 2.5 — Sat, 30 Aug 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Conditional Node and Loop Node notation missing

  • Key: UMLR-1
  • Legacy Issue Number: 6071
  • Status: open  
  • Source: CA Technologies ( Andrew Haigh)
  • Summary:

    In 03-07-06 there was notation for conditional nodes and loop nodes for activities. These are missing in 03-08-02. Makes taking the certification difficult

  • Reported: UML 2.5 — Thu, 21 Aug 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section 7.11.2 Association

  • Key: UMLR-12
  • Legacy Issue Number: 6470
  • Status: open  
  • Source: Sparx Systems Pty Ltd ( Mr. J.D. Baker)
  • Summary:

    What is the sematics of an association with neither end navigable? Provide an example of when this might be used. (C to D page 85).

  • Reported: UML 2.5 — Fri, 7 Nov 2003 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML2 Super/Deployment/inheritance

  • Key: UMLR-23
  • Legacy Issue Number: 7227
  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    Deployment should not be a Dependency
    Section 10.3.4, figure 126 show the Deployment subclass of Dependency
    with location subsetting client and deployedArtifact subsetting
    supplier.
    This means in effect that a Node is deemed dependent on the Artifacts
    that are deployed to it which seems to me the wrong way round if
    anything.

    Since it is not really true either that an Artifact is dependent on the
    Node it is deployed to, it does not seem sensible for Deployment to
    inherit from Dependency at all: it should inherit directly from
    DirectedRelationship.

    [Aside: Figure 126 shows 'subsets source' and 'subsets target' which is
    not reflected in section 10.3.4. I had assumed that Dependency would
    itself specify client and supplier to subset/redefine source and target
    but this oddly appears not to be the case]

  • Reported: UML 2.5 — Sun, 11 Apr 2004 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Questions about DataTypes and generalization

  • Key: UMLR-22
  • Legacy Issue Number: 7223
  • Status: open  
  • Source: Red Hat ( Randall Hauch)
  • Summary:

    I have a few questions regarding section 7.12 entitled "Kernel - the
    DataTypes Diagram" in the final adopted Superstructure spec (03-08-02).

    DataType specializes Classifier, and as such it also inherits the ability to
    have generalization relationships with other Classifiers. Classifier has an
    additional operation 'maySpecializeType(Classifier):boolean' that is
    described/defined as follows:

    "The query maySpecializeType() determines whether this classifier may have a
    generalization relationship to classifiers of
    the specified type. By default a classifier may specialize classifiers of
    the same or a more general type. It is intended to be
    redefined by classifiers that have different specialization constraints."
    (p. 63)

    with the OCL:

    Classifier::maySpecializeType(c : Classifier) : Boolean;
    maySpecializeType = self.oclIsKindOf(c.oclType)

    DataType, nor its subtypes PrimitiveType and Enumeration, defines no
    additional constraints or additional operations. These additional
    constraints are executed/applied in the UML2 metamodel (rather than in a
    UML2 model), correct? If so, then this implies that a DataType may
    specialize another DataType, Classifier, Namespace, Type, etc., but that
    DataType may not specialize PrimitiveType or Enumeration. Please correct me
    if I'm interpreting this incorrectly.

    Consider an example with:

    • a PrimitiveType named "string"
    • a PrimitiveType named "float"
    • a DataType named "InternationalPrice" that specializes "float" and
      adds a new attribute/property called "currency" of type "string"

    The "InternationalPrice" DataType is conceptually a qualified type, meaning
    it is a float plus a qualifier of the value. Examples of instances would be

    {426.36, "US Dollars"}

    ,

    {401.23, "Euros"}

    ,

    {749.42, "Yen"}

    .

    If my interpretations of the Superstructure spec are correct, then this
    example cannot be modeled using UML2. And, in fact, the specification would
    actually allow me to create a new PrimitiveType named "double" that actually
    specializes my "InternationalPrice" DataType (since DataType is a supertype
    of PrimitiveType). My thought is that this is either a issue with the
    'maySpecializeType' operation or it is an issue with DataType, PrimitiveType
    and Enumeration not being properly constrained.

  • Reported: UML 2.5 — Tue, 6 Apr 2004 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

missing illustrations of graphical paths for create and destroy messages

  • Key: UMLR-21
  • Legacy Issue Number: 6975
  • Status: open  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Table 15 does not include illustrations for

    • create message (a graphical path flowing into a Lifeline head).
    • create message to lost
    • create message from found

    More illustrations need to be added to Table 15 as the new sorts of messages are added, for example:

    • synch and async create
    • synch and async destroy
  • Reported: UML 2.5 — Mon, 16 Feb 2004 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML 2 Super / Interactions / Ambiguous diagram tags

  • Key: UMLR-20
  • Legacy Issue Number: 6927
  • Status: open  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Diagrams have a frame and a tag that describes the kind of diagram. Most diagrams correspond to a portion of the metamodel, and in most cases there is a one-to-one correspondence between metamodel chapters and diagram types, although variants are allowed for special cases (such as 'package'). There are four kinds of diagrams showing interactions, each with its own unique contents and syntax: sequence diagrams, communications diagrams, interaction overview diagrams, and timing diagrams. Unlike the difference between class diagrams and package diagrams, for example, each of these is very different in appearance and content from the others, even though they allegedly all map to the same interaction model (which might be dubious in practice, given the very different content, but that's another matter). However, the examples all use the same tag, 'sd', for all of the kinds of interaction diagram. Clearly 'sd' is an abreviation for 'sequence diagram' and it is inappropriate for the other types. (The fact that it is an English-language abreviation is another problem that we will let pass for now.) It would seem that each kind of diagram should have its own tag, given that they have different syntax and usage. For example, we could use 'sd', 'cd', 'iod', and 'td' if we wish to keep the same abbreviated format. But in any case the tags should be different and they should be descriptive of the diagram, not the underlying modeling chapter. (The official tag for interaction diagrams as a group is 'interaction', not 'sd' (page 589), so 'sd' is already descriptive of just one variant.)

    If the argument is that you can tell apart the different variants of interaction diagram by looking at them, that argument would apply with even more force to the diagrams for different kinds of models, such as class diagrams, state machine diagrams, etc., so we wouldn't need tags at all. (Which may be true, and users will probably not bother most of the time, but let's at least get it right in the standard.)

  • Reported: UML 2.5 — Fri, 23 Jan 2004 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Redefinitions of OCL constraints must be aligned with MOF2.0/UML2.0 class R

  • Key: UMLR-19
  • Legacy Issue Number: 6922
  • Status: open  
  • Source: Fraunhofer FOKUS, Germany ( Michael Soden)
  • Summary:

    Redefinitions of OCL constraints must be aligned with MOF2.0/UML2.0 class Redefinition. I could not find any detailed information with respect to redefinition of (especially OCL class OclExpression) constraints in the docs ptc/03-09-15, ptc/03-10-04. A more precise semantic would help for the QVT redefinitions w.r.t patterns and technology mappings interoperability (JMI <> MOF2IDL alignment).

    Proposed resolution: It would be useful to add more precise abstract semantic for redefinition contexts of constraints (e.g. class 'Constraint' should specify that redefinition context must also be inheritance)

  • Reported: UML 2.0 — Mon, 19 Jan 2004 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML 2 Infrastructure / rule for redefinition of Property

  • Key: UMLR-18
  • Legacy Issue Number: 6878
  • Status: open  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The isConsistentWith() query defined on Property implies that in order for a property redefinition to be logically consistent, the redefining property must be derived if the redefined property is derived. Are these the correct semantics for redefinition? There are cases in the metamodel where this constraint is violated (e.g. Package::ownedMember is not derived, but it redefines derived property Namespace::ownedMember). If there is to be a constraint on redefinition, perhaps it makes more sense the other way around, i.e. a redefining property must be non-derived if the redefined property is non-derived.

  • Reported: UML 2.5 — Fri, 2 Jan 2004 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

inconsistency in the action model

  • Key: UMLR-27
  • Legacy Issue Number: 7337
  • Status: open  
  • Source: Missouri University of Science and Technology ( Thomas Weigert)
  • Summary:

    There is an inconsistency in the action model between actions for StructuralFeatures in general, and actions operating on links. The family of structural feature action, such as WriteStructuralFeatureAction, are defined for any kind of structural feature. Consequentially, these actions can manipulate values that are not due to attributes or assication ends (both special cases of Property) but of any kind of StructuralFeature. However, actions defined for links can only operate on links that are due to associations in the model. This because LinkEnd is identified through the association to a Property (named "end"). However, there are other links in the model, such as those due to Connectors. To make these consistent, one either should limit the structural feature actions to apply to Properties (rather than StructuralFeatures), or one should generalize the link actions to apply to liks identified by any StructuralFeature, not just to links identified by Properties. This difference in generality does, of course, not matter for the UML as defined, but it could hamper the deployment of actions to profiles that define other kinds of links. (This is, luckily, not a problem for links due to Connectors, as we can argue that for links due to connectors that are not explicitly typed, these are identified by the ends of the derived associations.)

  • Reported: UML 2.0 — Sat, 15 May 2004 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

large overlap between structural features and variables

  • Key: UMLR-26
  • Legacy Issue Number: 7329
  • Status: open  
  • Source: Missouri University of Science and Technology ( Thomas Weigert)
  • Summary:

    There is large overlap between structural features and variables. For example, examine the structural features actions and compare them to variable action. Upon study, one will discover that structural features and variables have much more in common. In fact, the following equation seems to hold: StructuralFeature = Variable + Feature That is: a variable denotes a location able to hold an instance. A structural feature is a feature of an object and denotes a location ale to hold an instance. Therefore, I suggest that StructuralFeature be made a subtype of Variable. In the infrastructure, variable would have no interpretation, other than being an abstract metaclass indicating the ability to hold a value. In the superstructure, variable is concrete as described in Activities. Not only would this allow to eliminate the duplication of actions related to accessing variables, but also, other duplications (as, e.g., with respect to their being connectable elements and the related explanations) could be avoided.

  • Reported: UML 2.0 — Sun, 9 May 2004 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML 2.0 Superstructure Kernal/Packages

  • Key: UMLR-17
  • Legacy Issue Number: 6645
  • Status: open  
  • Source: TimeWarp Engineering Ltd. ( Steven Cramer)
  • Summary:

    The Property ownedMember of the Class Package is redefined to specialize the EndType from NamedElement to PackageableElement. But is incorrectly changed from a derived union to NON Derived. If it is intended to be non derived the property string subsets on all the other members are in error.

    ownedMember for a Package should be a derived union subset by the following Properties:

    ownedType

    nestedPackage

    ownedRule

    An OCL equivalent would be as follows:

    ownedMember=ownedType->union(nestedPackage)->union(ownedRule)

  • Reported: UML 2.5 — Wed, 1 Oct 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

freeing namespace

  • Key: UMLR-16
  • Legacy Issue Number: 6624
  • Status: open  
  • Source: XTG, LLC ( Joaquin Miller)
  • Summary:

    I know ODP is <adjective>, so i'd like to add mention of a couple of other places where we will find name space standing on its own, and not conflated with package or other container.

    An IETF namespace is exactly "a set of terms usable as names."

    As Karl reminded me, a C++ name space is also "a set of terms usable as names," declared with the keyword 'namespace' and used with the keywords 'using namespace' (providing a naming context) or with the scope operator, '::' (converting a simple name to a name that is an identifier).

    [Unlike most Java tools, there is no requirement that the things in a C++ namespace all be in any particular container. Karl tells me that C++ programmers he works with don't like the way Java tools insist that a package-cum-namespace be identified with a directory that contains all elements of that package. (Of course, tools that do that are following "the extremely simple example" in The Java Language Specification. Sometimes the effect of simple examples on the future of the world.) It can be fine to have such simplifications in a programming language, but it's good to have more flexibility in models.]

    C++ also provides a form for aliases:
    namespace new_name = current_name ;

    Still more flexible is that other approach, which in addition to distinguishing name space from naming context, also allows the same item to have fully qualified names from different namespaces. If that's in MOF, let's use it. (Is that accomplished the relaxing, which MOF 2 package import provides? (If i import C from Pa into Pb, can i identify it with 'Pb::C'?))

    If not, let's put it there.

    Seems to me to be easy to accomplish, if Namespace is first class.

  • Reported: UML 2.5 — Mon, 17 Nov 2003 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

metaattribute isReadOnly

  • Key: UMLR-28
  • Legacy Issue Number: 7338
  • Status: open  
  • Source: Missouri University of Science and Technology ( Thomas Weigert)
  • Summary:

    The metaattribute isReadOnly is defined both for StructuralFeature and its subclass Property. Clearly, one or the other is incorrect. This, I believe, points to an unclarity in what StructuralFeatures are, as opposed to Property. By definition, StructuralFeatures denote values that are held in slots of an object. I believe that the intuition behind Property is that a property denotes a value that might be added, modified, or deleted during the course of the lifetime of a system. This is exemplified in the two variants of property: attribute and association end. As "isReadOnly" has to do with limiting the modification of the value, it is best placed on Property, assuming this intuition is correct. This intuition is substantiated by that Port is not a property but a structural feature, and ports cannot be modified, changed, or assigned to. (Note that if this intuition is not correct, the difference between Property and StructuralFeature needs to be clarified.) A consequence of this is also that one needs to clarify the set of actions that apply to StructuralFeatures (e.g., WriteStructuralFeatureAction). If it is Properties that are modified, etc., then these actions should really apply to properties, not structural features in general. Again, this change is consistent, as none of these actions makes sense for Ports. Further, for links the actions are already limited to properties (see LinkEndData). An issue regarding the inconsistency between actions applying to structural features and actions applying to links has been submitted and should be dealt with consistently.

  • Reported: UML 2.0 — Sat, 15 May 2004 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Priority of the joint transition

  • Key: UMLR-25
  • Legacy Issue Number: 7255
  • Status: open  
  • Source: ISTI-CNR ( Franco Mazzanti)
  • Summary:

    The specification says that: "The priority of joined transitions is based on the priority of the transition with the most transitively nested source state". Suppose that a join transition is has two transitions with source states at the same depth, but in two different regions. How is is established which of the two transition defines the priority of the join transition?. Notice that, depending on which transition is choosen, different other transitions might be allowed or disallowed to be fired. Some possible anwers are: - Any of the two transitions can be chosen statically. (i.e. the priority of the join transition always remains the same). - Any of the two transitions can be chosen, and the choice truly, completely nondeterministic (hence possibly dynamic) I.e. the priority of the join transitions can change each time the join transition is fired.

  • Reported: UML 2.5 — Wed, 21 Apr 2004 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

surface notation for state machines

  • Key: UMLR-29
  • Legacy Issue Number: 7372
  • Status: open  
  • Source: Missouri University of Science and Technology ( Thomas Weigert)
  • Summary:

    The surface notation for state machines allows to show, on the line representing a transition, certain key actions that will be performed by the behavior associated with the transition. This is straightforward, when the behavior is an activity (as those actions can be referenced). However, for any other behavior, e.g., an opaque behavior, we need a method of (in the metamodel) show that this behavior does contain certain actions. Note that this should not give an alternative way of defining sequences of actions; rather, this should merely state that this behavior will contain the exhibited actions but it may contain many more. Those actions would merely give a means of representing the graphical constructs in the metamodel

  • Reported: UML 2.0 — Mon, 24 May 2004 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML2 Super/Deployments/Manifestation

  • Key: UMLR-24
  • Legacy Issue Number: 7229
  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    Manifestation should inherit from Realization

    In Section 10.3.10 and Figure 124 it would make more sense for
    Manifestation to inherit from Realization rather than directly from
    Abstraction. The semantics of Realization are described as "A
    Realization signifies that the client set of elements are an
    implementation of the supplier set,.." which surely includes
    manifestation.
    The spec also states that Realization may be used to model
    transformations, which fits with the example given in Manifestation:
    "<<tool generated>> and <<custom code>> might be two manifestations for
    different classes".

    BTW There is a missing word in the description of Manifestation "A
    manifestation is the concrete physical of one or more model elements by
    an artifact."

  • Reported: UML 2.5 — Sun, 11 Apr 2004 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Provide exception handling for all behaviors.

  • Key: UMLR-30
  • Legacy Issue Number: 7398
  • Status: open  
  • Source: Missouri University of Science and Technology ( Thomas Weigert)
  • Summary:

    UML2 has added the capability of dealing with exceptional behavior. Exception handling can occur at various levels of the model. Unfortunately, the exception handling mechanism has not been systematically developed. Any kind of behavior should support the mechanism of catching and handling an exception that was raised somewhere within that behavior. Unfortunately, currently only activities allow for this. Similar capabilities should be available for interactions and statemachines, and even for use cases. Recommendation: Provide exception handling for all behaviors.

  • Reported: UML 2.0 — Sun, 30 May 2004 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT