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

Open Issues

  • Issues not resolved
  • Name: uml2-rtf
  • Issues Count: 526

Issues Summary

Key Issue Reported Fixed Disposition Status
UMLR-620 Complete and Covering are Synonyms and used confusinginly UML 2.5 open
UMLR-730 Does the abort of an Do/Activity by an incoming event count as a Completion Event UML 2.5 open
UMLR-234 UML Interactions: Misleading suggestion of relationship between Interactions and Activities modeling UML 2.5 open
UMLR-738 Incorrect use of multiplicity element. UML 2.5 open
UMLR-740 DecisionNode is missing a constraint on incoming edges UML 2.5 open
UMLR-306 How to access a token value in a guard? UML 2.5 open
UMLR-711 Conflicting constraints UML 2.5 open
UMLR-243 Restrictions on decision nodes UML 2.5 open
UMLR-668 Unspecified and inconsistent notation for Observations UML 2.5 open
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-404 ActivityEdge weight examples UML 2.5 open
UMLR-724 bad example for weight in Figure 15.21 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-685 UML 2.5: StateMachine Vertex needs to be made a kind of RedefinableElement instead of State 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-704 Figure 14.44 ProtocolStateMachine example error UML 2.5 open
UMLR-354 State machine semantics for transition between regions of an orthogonal state UML 2.4.1 open
UMLR-717 Invalid XMI elements containing both xmi:type and href UML 2.5 open
UMLR-710 Missing visibility definition UML 2.5 open
UMLR-716 What is a "compound state"? UML 2.5 open
UMLR-715 All actions should be able to own control pins UML 2.5 open
UMLR-714 Missing Constraint: Associations cannot type StructuralFeatures UML 2.5 open
UMLR-348 Actor association constraint makes UseCase subclass of Class UML 2.5 open
UMLR-713 On page 290 of UML 2.5 formal/2015-03-01, UML 2.5 open
UMLR-712 New Issue on UML 2.5 formal/2015-03-01 re signalbroadcastaction vs. broadcastsignalaction UML 2.5 open
UMLR-696 The behavior of an OpaqueExpression should be allowed to have input parameters UML 2.5 open
UMLR-92 UML/OCL spec mismatch-Constraint.context vs Constraint.constrainedElement UML 2.5 open
UMLR-706 What is "a separate InteractionConstraint"? UML 2.5 open
UMLR-703 XOR Constraint modeling UML 2.5 open
UMLR-705 Meaning of Event on Initial Transition unclear 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-683 Order of example information should be diagram first, then explanation. UML 2.5 open
UMLR-682 Link to "see" sections missing UML 2.5 open
UMLR-679 AssociationEnd/Attribute redefintion consistency UML 2.5 open
UMLR-678 Why is a qualified association qualifier composed by a Property? UML 2.5 open
UMLR-355 UML should support proxies for linking models UML 2.5 open
UMLR-676 No UML approach to create an infix operator UML 2.5 open
UMLR-674 Parameter types required for operation parameters UML 2.5 open
UMLR-329 TypeElement / TypedElement typo UML 2.5 open
UMLR-673 Spec refers to TypeElement twice. Should be TypedElement UML 2.5 open
UMLR-672 Constraint TemplateSignature::own_elements too constraining UML 2.5 open
UMLR-671 Need example of derived qualifier. UML 2.5 open
UMLR-670 The Kind field from frame names should be bold UML 2.5 open
UMLR-659 Need BNF for Protocol State Machines Transitions UML 2.5 open
UMLR-669 DI refers to putting the Diagram Kind in bold... UML 2.5 open
UMLR-667 Package names in wrong location. UML 2.5 open
UMLR-35 Disjointness should be independent of generalization UML 2.0 open
UMLR-41 section 7.3.17 /EnumerationLiteral should not be an InstanceSpecification UML 2.5 open
UMLR-665 Impossiblity to specify links for connected roles. UML 2.5 open
UMLR-664 Delegation Connector should not be typed UML 2.5 open
UMLR-663 Decide whether the document divisions are "sub clauses" or "subclauses" UML 2.5 open
UMLR-660 Unexpected trigger reception has contradictory results in Protocol State Machines UML 2.5 open
UMLR-661 What does calling an "operation for a state" mean in PSM. UML 2.5 open
UMLR-658 No notation for associations defined for abstract classes UML 2.5 open
UMLR-202 UML:Notational option to display inherited features in a subclass UML 2.5 open
UMLR-657 Deploying a «deployment spec» has no explicit interpretation UML 2.5 open
UMLR-656 Shoppin->Shopping UML 2.5 open
UMLR-655 UML 2.5 refers to EBNF, but the spec uses a variant BNF, not EBNF UML 2.5 open
UMLR-384 Classifiers can contain Packages, but they can't have appropriate visibility UML 2.5 open
UMLR-654 Pin rectangles in examples should not overlap the action border UML 2.5 open
UMLR-653 Activity Generalization is underspecified UML 2.5 open
UMLR-315 Rename Specialization/Generalization between abstract classes UML 2.5 open
UMLR-652 In Sequence diagrams, the duration constraint shown as a vertical two-headed is ambiguous UML 2.5 open
UMLR-651 In the time-related syntax for Sequence diagrams, there are used two terms (now, duration). Are there more? Are these defined? UML 2.5 open
UMLR-650 It doesn't seem possible to use a time-based trigger in the alternate format transition-focused state machine. UML 2.5 open
UMLR-649 Use of decomposition indicator UML 2.5 open
UMLR-648 InstanceSpecification for a qualified Property UML 2.5 open
UMLR-646 Recursive use of Interaction Use UML 2.5 open
UMLR-647 Limitation on isDimension Partition to be uncontained appears unwarranted UML 2.5 open
UMLR-645 Classifier.allSlottableFeatures shall incorporate redefinition UML 2.5 open
UMLR-643 Location of owning fully qualifed name not specified. UML 2.5 open
UMLR-642 Clarify the difference between «create» and «instantiate» UML 2.5 open
UMLR-641 Missing parameter properties of stream and exception in BNF UML 2.5 open
UMLR-637 What is the order for EnumerationLiterals? UML 2.5 open
UMLR-638 Inconsistency in constraints and rules for property merge UML 2.5 open
UMLR-635 Typing error in figure 9.11 UML 2.5 open
UMLR-633 Computation error for the example of ReduceAction UML 2.5 open
UMLR-636 How to deal with guard in Transition redefinition? UML 2.5 open
UMLR-639 Wrong expression for dipicting package merge process? UML 2.5 open
UMLR-634 Wrong figure referrence in text 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-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-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-347 UML 2.5 Beta 2 XMI invalid UML 2.5 open
UMLR-616 UML 2.5: UML redefinition mechanism insufficiently granular 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-326 Incorrect drawing of non-navigable redefined opposites 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-414 Any Activity parameter is steaming. It must be too hot to handle UML 2.5 open
UMLR-395 Making the default for Generalization isDisjoint=False is contrary to modelers' expectations. UML 2.5 open
UMLR-327 Incorrectly drawn ParameterableElement.owningTemplateParameterSubstitution multiplicity UML 2.5 open
UMLR-251 Metaclass stereotype notion UML 2.4 open
UMLR-409 Figure 14.5 State with Compartments does not show all the compartments that it should UML 2.5 open
UMLR-290 Improving the association direction notation 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-260 Clarification about serializing the application of SysML 1.3 to a UML2.4.1 model UML 2.5 open
UMLR-224 not sure it is possible to define a constraint without a context 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-394 How is an attribute that is not a part, a role? UML 2.5 open
UMLR-330 Incorrect OrderedSet returns UML 2.5 open
UMLR-371 Extraneous " (double quote) in 17.5.4 BehaviorExecutionSpecification UML 2.5 open
UMLR-323 Unclear statement regarding Lifeline shape UML 2.5 open
UMLR-316 Ambiguous Profile::profileApplication UML 2.5 open
UMLR-240 UML 2.3 Infra 12 Incomplete conformance for infinity UML 2.5 open
UMLR-292 About behavior ports UML 2.5 open
UMLR-255 A deferrable trigger may have a guard UML 2.4 open
UMLR-300 Notation for PrimitiveTypes UML 2.5 open
UMLR-276 test UML 2.5 open
UMLR-398 How can a GeneralizationSet not have any Generalizations? UML 2.5 open
UMLR-423 UML 2.5 beta issue - Operation notation is wrong UML 2.5b1 open
UMLR-275 applying and associating stereotypes and explanation of all aspects of their serialization UML 2.5 open
UMLR-360 Minor error in ptc-13-09-05 UML 2.5 open
UMLR-408 BNF notation as given and used is unclear about italics UML 2.5 open
UMLR-320 UML transition-centric state machine arrows (02) solid vs v-shaped arrow heads UML 2.5 open
UMLR-314 UML 2.5 Figure 14.25 Choice Pseudostates UML 2.5 open
UMLR-412 Some hyperlinks are underlined and some are not. This is inconsistent UML 2.5 open
UMLR-287 Use cases and use of arrows UML 2.5 open
UMLR-331 Specification should not contain any methodology UML 2.5 open
UMLR-229 Ports UML 2.5 open
UMLR-281 Semantic error in Lifeline::interaction_uses_share_lifeline 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-385 Two classes can share attributes by use of element import UML 2.5 open
UMLR-273 Link notation for stereotype property value UML 2.5 open
UMLR-336 meaning is not clear UML 2.5b1 open
UMLR-296 BehavioredClassifier should redefine Classifier::conformsTo to include interfaceRealization UML 2.5 open
UMLR-269 Message Signature in Interactions and Reception.ownedParameter UML 2.5 open
UMLR-383 History pseudo states in protocol state machines UML 2.5 open
UMLR-357 SignalBroadcastAction used where BroadcastSignalAction should be. UML 2.5 open
UMLR-267 UML 2.4/2.5 Aliases UML 2.5 open
UMLR-338 Incomplete sentence UML 2.5b1 open
UMLR-253 State::stateInvariant multiplicity too restrictive UML 2.5 open
UMLR-405 adding error 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-239 No Constraint for multiple associations UML 2.3b1 open
UMLR-228 Initialization of complex fields UML 2.5 open
UMLR-364 As Events are Packageable Elements, how is their Package known? 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-382 Justification for messages on differnent sides of a gate being identical is not clear. UML 2.5 open
UMLR-302 A PrimitiveType can/cannot have owned attributes. UML 2.5 open
UMLR-410 More on SateMachines UML 2.5 open
UMLR-342 BehavioralParameter should be BehavioralFeature UML 2.5 open
UMLR-411 These are typographical errors UML 2.5 open
UMLR-363 Semantics of Executable Nodes does not cover Control Flows on Control Pins UML 2.5 open
UMLR-312 UML 2.5 Figure 10.10 Error UML 2.5 open
UMLR-274 Specifying the multiplicity of a part with an attribute UML 2.5 open
UMLR-232 Aggregation missing from Property string syntax UML 2.5 open
UMLR-362 A type defines a set member (not a set) UML 2.5 open
UMLR-325 Unnamed elements in a namespace UML 2.5 open
UMLR-332 UML 2.6 Issue --- SignalEvent Triggers UML 2.5 open
UMLR-343 Semantics of static features UML 2.5 open
UMLR-401 orthogonal State missing on bullet point list UML 2.5 open
UMLR-353 2 Conformance: Missing Oxford comma in Item #2. UML 2.5 open
UMLR-249 Package URI Attribute Uses Obsolete RFC 2396 UML 2.4 open
UMLR-257 Navigability orthogonal to end ownership or not? UML 2.3 open
UMLR-245 New notation for attribute UML 2.5 open
UMLR-341 UML wording in Superstructure 2.4.1 UML 2.5 open
UMLR-277 isReplaceAll=true and lowerBound > 1 UML 2.5 open
UMLR-377 What exception type is "any" exceptionType UML 2.5 open
UMLR-321 UML 2.5 issue on examples in 17.4.5 UML 2.5 open
UMLR-295 Information flow instantiation UML 2.5 open
UMLR-349 Another UML 2.5 Beta 2 XMI invalidity UML 2.5 open
UMLR-333 UML 2.5 Mandatory but suppressible compartments UML 2.5 open
UMLR-386 UML needs standardized default package (or Model) UML 2.5 open
UMLR-293 About prescribed port implementation UML 2.5 open
UMLR-282 Semantic error in UMLAssociationOrConnectorOrLinkShape::edge_instancespec invariant UML 2.5 open
UMLR-375 Caption for Table 17.5 on wrong page UML 2.5 open
UMLR-280 ExtensionEnd upper/lower inconsistent with MultiplicityElement 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-424 UML 2.5: Property::isConsistentWith() error UML 2.5 open
UMLR-278 Problems with OCL definition of Package::makesVisible UML 2.5 open
UMLR-297 Problem with MultiplicityELement::lower redefinition in UML 2.5 Beta 2 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-339 Incorrect sentence UML 2.5b1 open
UMLR-233 Nasty UML 2.x Issue - /qualifiedName is not unambiguous UML 2.5 open
UMLR-397 Ambiguity in description of TransitionKind UML 2.5 open
UMLR-372 use of ! instead of + or ∪ UML 2.5 open
UMLR-334 Incorrect Result in ReduceAction Example UML 2.5 open
UMLR-418 InformatonFlows are constrained to be Classes or Classifiers -- which one? UML 2.5 open
UMLR-392 Generalizations should allow enumeration types as PowerTypes. UML 2.5 open
UMLR-368 Mismatch of singular/plural Activity Goups are a grouping constructs UML 2.5 open
UMLR-313 Multiple Generalization Sets UML 2.5 open
UMLR-289 Description of the OCL on Actor does not match OCL and both are obsolete. 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-252 Metaclass stereotype notion (02) UML 2.4 open
UMLR-271 Migrate UML::Component's ability to own UML::PackageableElements to UML::Class UML 2.5 open
UMLR-389 Extraneous " (double quote) in 17.6.3 Semantics UML 2.5 open
UMLR-268 Concerning Transition and its owned elements UML 2.5 open
UMLR-361 Inconsistent use of Oxford comma in "Behavior, Event, and Trigger" 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-307 Type conformance for classifiers UML 2.5 open
UMLR-370 Message wildcards appear to ignore operation default values UML 2.5 open
UMLR-400 Missing constraints preventing contradictory GeneralizationSets. 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-236 Under-specified associations in UML2.4 & the need for clarifying the semantic directionality for all UML associations UML 2.5 open
UMLR-231 Issue on UML 2.3 - Use of isAbstract for Interfaces UML 2.5 open
UMLR-337 Message should extend Namespace 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-369 Tables 17.1, 17.3, 17.5, 17.6 Header Formats UML 2.5 open
UMLR-415 Object Flow arrow heads are inconsistent: V-shaped vs triangular UML 2.5 open
UMLR-250 Profile URI Attribute - Mingled URI Definition and Use in XMI UML 2.4 open
UMLR-373 Vertical lines do not always describe the time-line for an interaction diagram 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-376 Coloring and shading on Figure 17.10 should be removed UML 2.5 open
UMLR-279 Relax Association::/endType from [1..*] to [0..*] UML 2.5 open
UMLR-225 issue10087 and association-like notation UML 2.5 open
UMLR-365 Use Cases both can and cannot have BehavioralFeatures UML 2.5 open
UMLR-238 UML 2 issue: connectors typed by Association Class 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-407 Figure 14.14 includes a "Submachine Sate" UML 2.5 open
UMLR-241 Part document structures in Superstructure need to conform to ISO standard Document Template Conventions UML 2.5 open
UMLR-422 UML2::Constraint UML 2.2 open
UMLR-350 UML 2.5 Section 15.2.3 p392 description for the ActivityEdge weight UML 2.5 open
UMLR-246 XMI representation of stereotype application UML 2.5 open
UMLR-393 Lack of clarify of attribute vs attribute value. UML 2.5 open
UMLR-283 XMI.xmi is not merged UML 2.5 open
UMLR-244 Retationships and composite structures UML 2.5 open
UMLR-390 Continuation examples are missing InteractionConstraints for the Alternative CombinedFragment 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-262 Message arguments for a Signal signature too restrictive UML 2.4 open
UMLR-263 Message arguments should not be contained in a message UML 2.4 open
UMLR-346 Classifier::ownedTemplateSignature needs to subset Element::ownedElement UML 2.5 open
UMLR-352 Pin multiplicity and token upper bound UML 2.5 open
UMLR-356 Spelling error: i-->is UML 2.5 open
UMLR-344 No specification of which visibility marking corresponds to which VisibilityKind value UML 2.5 open
UMLR-256 Ambiguous stereotype notation UML 2.5 open
UMLR-258 UML: unification of OCL declarations 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-227 Owning of interaction fragments is ambiguous when InteractionOperands are present UML 2.5 open
UMLR-248 Notation of Lifelines UML 2.5 open
UMLR-367 Spelling error in ActivityGoups UML 2.5 open
UMLR-381 Message lines can cross without the first being asynchronous UML 2.5 open
UMLR-259 UML Appendix A: After Figure A.4 UML 2.5 open
UMLR-340 ExpansionNodes owned by ExpansionRegions? UML 2.5 open
UMLR-304 Descriptions missing for PseudostateKind literals UML 2.5 open
UMLR-285 Abstract Syntax diagram for Use Cases UML 2.5 open
UMLR-235 Issue on UML 2.4 - notation for Component::provided UML 2.5 open
UMLR-247 Tags typed by classes/blocks 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-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-270 Interaction.action should subset ownedMember in lieu of ownedElement UML 2.4.1 open
UMLR-223 Timing Diagram and interchange UML 2.5 open
UMLR-379 Need clarification between exceptionType and the type of the exceptionInput UML 2.5 open
UMLR-387 shoes-->shows UML 2.5 open
UMLR-266 Abstraction::mapping should be of type ValueSpecification or OpaqueExpression UML 2.4 open
UMLR-254 Use cases specifying the same subject cannot be associated: exception UML 2.4 open
UMLR-345 Issue against UML: implementation of OCL constraint containingProfile UML 2.5 open
UMLR-299 Problems with normative UML 2.5 Beta 2 Standard profile UML 2.5 open
UMLR-298 Problem with NamedElement::clientDependency subsets in UML 2.5 Beta 2 UML 2.5 open
UMLR-318 UML 2.5 Visibility of a packagedElement UML 2.5 open
UMLR-261 Relation of message arguments to signature parameters ambiguous UML 2.4 open
UMLR-288 No rules on Extension Pts governing differences between Use Case definitions & «extend» relationships usage 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-265 The included use case is always required for the including use case to execute correctly UML 2.4.1 open
UMLR-301 Can PrimitiveTypes be user-defined and where? UML 2.5 open
UMLR-230 How to specify actual parameters to pass to parameterized submachine StateMachine UML 2.5 open
UMLR-396 Caption for Table 9.1 on wrong page UML 2.5 open
UMLR-308 Generalization should be limited to relate similar UML-elements UML 2.5 open
UMLR-421 Missing Example of TemplateBinding with model element "Class" UML 2.5b1 open
UMLR-416 Can be performed their instances --> missing "by" UML 2.5 open
UMLR-310 InstanceSpecification validity is not modelable UML 2.5 open
UMLR-264 OccurrenceSpecification should have at least an optional notation UML 2.4 open
UMLR-226 Chapter 14 is ambiguous and contradictory about how to link up messages and execution specifications UML 2.5 open
UMLR-322 UML 2.5 Overly strict restriction on message slope in seq diagrams UML 2.5 open
UMLR-305 Rg. Reception.ownedParameter UML 2.5 open
UMLR-317 UML 2.5 Issue on DI for reply arrows UML 2.5 open
UMLR-309 Missing OpaqueXXX body constraint UML 2.5 open
UMLR-303 Clause 21 Primitive Types is misnamed UML 2.5 open
UMLR-291 Sequence Diagram: Message limitation UML 2.5 open
UMLR-161 UML 2 - appearance of Association Ends as members of the related classes UML 2.5 open
UMLR-40 Properties on Association for end objects UML 2.0 open
UMLR-118 Section: 14.4 Timing Diagram: Continuous time axis UML 2.1.1 open
UMLR-107 Behavioral port UML 2.5 open
UMLR-78 consistent ordering of Association::memberEnd and ownedEnd UML 2.5 open
UMLR-126 Figure 7.48 and the accompanying discussion under 7.3.21 UML 2.1.1 open
UMLR-81 All associations ends in the UML2 metamodel itself should be navigable UML 2.5 open
UMLR-150 18.3.8 Generalization of stereotyped model elements UML 2.2 open
UMLR-34 Section: Classes, Behavior UML 2.0 open
UMLR-173 UML2: Need clarification on circle plus notation for containment UML 2.5 open
UMLR-60 ConditionalNode inputs used by more than one test UML 2.0 open
UMLR-193 UML Issue: Refactor UML to separate SW-Specific Aspects from Foundation Language UML 2.5 open
UMLR-108 UML 2 Superstructure: Abstractions should be acyclic UML 2.5 open
UMLR-122 Section: 16.3.5 UML 2.1.1 open
UMLR-67 Syntax of Transition UML 2.5 open
UMLR-59 Section: 14.3.3 Page: 508+ UML 2.0 open
UMLR-54 Operation calls on behavior ports UML 2.0 open
UMLR-133 Section: 7.3.41 UML 2.1.2 open
UMLR-175 Should there be a constraint for extends equivalent to 16.3.6 [4] UML 2.2 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-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-93 Section: 7.3.33 UML 2.1.1 open
UMLR-96 Section: 15.3.12, p 588, 589 UML 2.1.1 open
UMLR-75 Page: 107 UML 2.0 open
UMLR-94 Default value types UML 2.5 open
UMLR-55 Possibility to define a Collection as default Value needed UML 2.0 open
UMLR-206 UML Support for multiple library levels UML 2.5 open
UMLR-158 Section 9.3.4 Collaboration Use, 2nd constraint creates unneces UML 2.5 open
UMLR-123 UML2 Property collaborationRole should be removed UML 2.5 open
UMLR-198 UML: Include text description field with model element UML 2.5 open
UMLR-105 Constraint.context vs Constraint.constrainedElement UML 2.5 open
UMLR-208 UML: Diagrams as Model Elements UML 2.5 open
UMLR-38 Contextualized attribute values Figures 121 UML 2.0 open
UMLR-168 The example in Figure 18.11 is badly designed in multiple ways and is strongly misleading UML 2.2 open
UMLR-136 Section: 18.3.3 UML 2.1.2 open
UMLR-132 UML 2 has lost cability to represent operations by collaborations UML 2.1.2 open
UMLR-174 Visibility and Import relationships UML 2.5 open
UMLR-149 Actors cannot own Operations - a contradiction UML 2.5 open
UMLR-103 Section: 7 UML 2.0 open
UMLR-61 Arguments of Message UML 2.5 open
UMLR-83 ControlNodes in ActivityPartitions UML 2.5 open
UMLR-45 Section: Activities - clarification UML 2.0 open
UMLR-121 Section: 7.3.3 UML 2.5 open
UMLR-154 UML2.2 RTF: EnumerationLiteral is a DeploymentTarget UML 2.5 open
UMLR-160 UML2.2. Contradications in 14.3.10 UML 2.5 open
UMLR-102 Association::isDerived should be derived 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-80 Section: Sequence diagrams UML 2.0 open
UMLR-85 UML2: No notation for indicating Operation::raisedException UML 2.5 open
UMLR-51 Section: 10.3.1 UML 2.0 open
UMLR-212 UML: Cross model dependencies UML 2.5 open
UMLR-180 authorize a reference to an operation in a realized interface. UML 2.2 open
UMLR-153 UML: Standard Techniques to disambiguate crossing lines needed UML 2.5 open
UMLR-164 Concrete specialization of the Relationship meta-class are missing UML 2.2 open
UMLR-182 The spec may require some clarification regarding figure 14.16 UML 2.5 open
UMLR-219 UML has no way of distinguishing Notes from Comments UML 2.5 open
UMLR-111 Section: 10.3.4 of formal/2007-02-03 UML 2.1.1 open
UMLR-42 ReadStructuralFeatureAction UML 2.0 open
UMLR-76 No notation for associating Exceptions with Operations UML 2.5 open
UMLR-190 are Create messages aynch or synch, or doesn't it matter? UML 2.5 open
UMLR-214 UML: Add abilities to specifiy intent of Assert, Negate, Consider, Ignore fragments 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-165 issue within UPDM with profile diagrams UML 2.5 open
UMLR-49 SequenceNode should have way to set output pins in CompleteStructured UML 2.0 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-44 Activities section UML 2.0 open
UMLR-143 3 3.2 Behavior (CommonBehaviors/BasicBehaviors) UML 2.1.2 open
UMLR-184 Reconcile the algebra of collections across OCL & UML’s intentional & extensional semantics UML 2.5 open
UMLR-43 Section: 16.3.1 UML 2.0 open
UMLR-99 Optional values and evaluation of defaults UML 2.5 open
UMLR-48 Add constraints on ConditionalNode UML 2.0 open
UMLR-116 UML 2.1.1 - notation for parameter sets UML 2.5 open
UMLR-72 Section: Classes UML 2.0 open
UMLR-156 Section: 7.3.9 Comment should be NamedElement UML 2.2 open
UMLR-129 pull semantics are only supported on Action inputs, not outputs UML 2.5 open
UMLR-140 Section: Activities SysML 1.0 open
UMLR-57 Arguments of Message 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-138 Section: 15.3.7 Constraint [2] UML 2.1.2 open
UMLR-216 UML: Better Profile Capabilitiy UML 2.5 open
UMLR-163 UML 2.2 InteractionOperand abstract syntax UML 2.5 open
UMLR-84 Reception has no notation for its signal UML 2.5 open
UMLR-200 UML: Provide unique URL/URI Reference to/from Model Elements UML 2.5 open
UMLR-71 Section: Activities UML 2.0 open
UMLR-104 Section: Chapter: 7.3.2.4 View SysML 1.0 open
UMLR-39 Notation for classifierBehavior UML 2.0 open
UMLR-210 UML: Better Definition of Compliance UML 2.5 open
UMLR-197 UML: Incorporate SysML Requirements Model into UML UML 2.5 open
UMLR-134 Section 7.3.44 UML 2.1.2 open
UMLR-110 clarification on Behavior::specification / meaning of InterfaceRealization UML 2.5 open
UMLR-74 Need more flexible notation for activity partitions UML 2.5 open
UMLR-145 UML2 issue regarding Redefinition UML 2.5 open
UMLR-70 Section: Classes UML 2.0 open
UMLR-218 UML: Higher-level reusable frameworks UML 2.5 open
UMLR-222 Sequence diagram and Communication diagrams should support instances as lifelines UML 2.5 open
UMLR-90 Unclear usage of LiteralExpression::type UML 2.5 open
UMLR-201 UML: Include text description field with model element --- additional information added UML 2.5 open
UMLR-46 Section: Activities : Why is exception type needed? UML 2.0 open
UMLR-135 new constraint ? UML 2.5 open
UMLR-199 UML Associate an image/icon with each model element UML 2.5 open
UMLR-52 UML2-rtf issue: communication diagram UML 2.5 open
UMLR-98 OCL Syntax in expressions UML 2.5 open
UMLR-172 Subsets vs. Redefines UML 2.5 open
UMLR-185 Association class notation with just class or association UML 2.1.2 open
UMLR-139 UML 2.1.2 Super: Execution Specification UML 2.5 open
UMLR-53 Meaning of relationship between iteration clause and Lifeline.selector clau UML 2.5 open
UMLR-178 Package merge is missing a rule UML 2.2 open
UMLR-209 UML: Provide mathematical formalism for UML semantics to provide precise meaning to language constructs UML 2.5 open
UMLR-58 Section: 14.3.3 UML 2.0 open
UMLR-127 Section: 14.4 UML 2.5 open
UMLR-177 UML 2: notation and concepts for unbound and un-owned template parameters are not clear UML 2.5 open
UMLR-73 Page: 492-493 UML 2.5 open
UMLR-183 UML: Issue with stereotype icons in a profile UML 2.5 open
UMLR-141 Callout notation for many clients/suppliers SysML 1.0 open
UMLR-170 there are numerous places where associations between UML elements have only one, navigable role UML 2.1.2 open
UMLR-131 UML 2: Need an explicit listing of all semantic variation points UML 2.5 open
UMLR-181 Need notation option to show type stereotype on typed element UML 2.5 open
UMLR-189 UML 2 TemplateParameterSubstitution inconsistency about multiplicity of Actual and OwnedActual UML 2.5 open
UMLR-151 MARTE/section 7.2.1/ "several labels for the same classifiers in the Metamodel" bug UML 2.5 open
UMLR-37 End objects of a link In the semantics of AssociationClass UML 2.0 open
UMLR-50 Add a Constraint 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-169 Section: 18.3.8 UML 2.2 open
UMLR-66 OutputPin UML 2.5 open
UMLR-130 should be able to show gates on communication diagrams UML 2.5 open
UMLR-79 Section: 7.3.9 UML 2.1 open
UMLR-89 No way of specifying element documentation UML 2.5 open
UMLR-124 Section: 7.3.37 Package (from Kernel) UML 2.1.1 open
UMLR-205 UML: Support for maintaining what-if models in repository without massive duplication 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-88 Unnecessary restriction on aggregations being binary UML 2.5 open
UMLR-179 Subsets vs. Redefines UML 2.5 open
UMLR-82 Notation for ordering action input and output pins UML 2.5 open
UMLR-191 Property subsets other regular property, non-derived union UML 2.5 open
UMLR-166 Section: 18.3.6 UML 2.2 open
UMLR-86 Link notation for instance diagrams does not cope with multiple classifiers UML 2.5 open
UMLR-87 New issue on notation for multiple stereotypes UML 2.5 open
UMLR-115 Units and types are still problematic UML 2.5 open
UMLR-157 we can create an invalid active state configuration UML 2.2 open
UMLR-162 Section: 9.3.11 Port UML 2.5 open
UMLR-215 UML:Access to standardized ontologies within models UML 2.5 open
UMLR-95 Relationships UML 2.5 open
UMLR-188 Stereotyped Constraints in UML UML 2.5 open
UMLR-69 UML2 Super / 14.3.13 Interaction UML 2.5 open
UMLR-125 simpleTime package problems UML 2.5 open
UMLR-171 Template Binding Question UML 2.5 open
UMLR-97 Guidance for Representing Enumeration Values UML 2.5 open
UMLR-148 InterfaceRealization UML 2.5 open
UMLR-142 role bindings of a CollaborationUse UML 2.1.1 open
UMLR-211 UML: Large Scale Model Support:Federated/Distibuted Models UML 2.5 open
UMLR-186 PrimitiveType has missing constraints UML 2.2 open
UMLR-62 Numbering UML 2.5 open
UMLR-207 UML: A strong ability to support generating Documents UML 2.5 open
UMLR-213 UML: Improve Sequence Diagram Semantics (3-issues) UML 2.5 open
UMLR-100 Section: 13 & 14 UML 2.1.1 open
UMLR-146 Figure 7.65 and its explanation, P115 UML 2.5 open
UMLR-204 UML: A strong ability to support reviewing packages UML 2.5 open
UMLR-117 9.3.9 Invocation Action UML 2.5 open
UMLR-120 Section: Annex A: Diagrams UML 2.1.1 open
UMLR-47 ExpansionRegion (behavior in the shorthand notation) UML 2.0 open
UMLR-217 UML: Timing semantics for activity diagram UML 2.5 open
UMLR-144 Section: 14.3.24, 14.3.20 UML 2.1.2 open
UMLR-137 UML Super 2.1.2: section 18.3.2 UML 2.5 open
UMLR-91 ValueSpecification::isComputable() UML 2.5 open
UMLR-63 Variables UML 2.5 open
UMLR-106 Connector contract is inflexible UML 2.5 open
UMLR-64 Issue 7368 - make Classifier::useCase navigable UML 2.5 open
UMLR-36 Action for retrieving activity instance UML 2.0 open
UMLR-152 There is no way to specify the behavior of operations which are members of data types UML 2.5 open
UMLR-114 names and namespaces UML 2.5 open
UMLR-221 Parameter UML 2.5 open
UMLR-128 UML2 Issue: notation for Literals does not allow for name UML 2.5 open
UMLR-192 One association end is derived, another is not UML 2.5 open
UMLR-187 Stereotyped Constraints in UML UML 2.5 open
UMLR-56 Association in UseCase diagram UML 2.5 open
UMLR-220 NamedElements whose owners do not subset Namespace UML 2.5 open
UMLR-77 No ReadParameterAction or WriteParameterAction UML 2.5 open
UMLR-65 UML 2.0 Super/Use Cases/Subject of a Use Case UML 2.5 open
UMLR-109 Presentation option for return parameter for operation type are incomplete UML 2.5 open
UMLR-155 UML2: Unclear how to indicate what events a classifier might send UML 2.5 open
UMLR-14 ptc-03-09-15/Need for examples to include instance models UML 2.5 open
UMLR-8 Join nodes that destroy tokens 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-11 Clarification of use case semantics 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-33 Too much navigability from Generalizations UML 2.5 open
UMLR-23 UML2 Super/Deployment/inheritance 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
UMLR-1 Conditional Node and Loop Node notation missing UML 2.5 open
UMLR-7 Deployment a dependency? UML 2.5 open
UMLR-13 Conditions for parameter sets UML 2.5 open
UMLR-31 Coupling between StateMachines and Activities UML 2.5 open
UMLR-32 Alternative entry and exit point notation is ambiguous UML 2.0 open
UMLR-10 Integration between behavioral "sublanguages": Interactions and Activities UML 2.5 open
UMLR-2 More examples UML 2.0 open
UMLR-25 Priority of the joint transition 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-16 freeing namespace 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-28 metaattribute isReadOnly UML 2.0 open
UMLR-27 inconsistency in the action model UML 2.0 open
UMLR-5 Promote local conditions to ExecutableNode UML 2.5 open
UMLR-18 UML 2 Infrastructure / rule for redefinition of Property UML 2.5 open
UMLR-20 UML 2 Super / Interactions / Ambiguous diagram tags UML 2.5 open
UMLR-26 large overlap between structural features and variables UML 2.0 open
UMLR-12 Section 7.11.2 Association UML 2.5 open
UMLR-6 Notation for method UML 2.5 open
UMLR-17 UML 2.0 Superstructure Kernal/Packages UML 2.5 open

Issues Descriptions

Complete and Covering are Synonyms and used confusinginly

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Key: UMLR-234
  • Legacy Issue Number: 15421
  • Status: open  
  • Source: Simula Research Laboratory ( 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

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: Wed, 28 Jun 2017 17:19 GMT

DecisionNode is missing a constraint on incoming edges

  • Key: UMLR-740
  • Status: open  
  • Source: nMeta ( Ed Seidewitz)
  • Summary:

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

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

How to access a token value in a guard?

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

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

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

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

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

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

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

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

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

Conflicting constraints

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

    One of the constraints on objectFlows in 15.7.22.6 is

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

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

    Imagine a decisionNode with 2 incoming objectFlows:

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

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

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

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

Restrictions on decision nodes

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

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

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

    Or

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

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

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

Unspecified and inconsistent notation for Observations

  • Key: UMLR-668
  • Status: open  
  • Source: oose Innovative Informatik eG ( 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 ( 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 ( 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 ( 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 ( 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 ( 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 ( 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 ( 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

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

bad example for weight in Figure 15.21

  • Key: UMLR-724
  • Status: open  
  • Source: oose Innovative Informatik eG ( 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

Implication of weight of ActivityEdge is unclear

  • Key: UMLR-723
  • Status: open  
  • Source: oose Innovative Informatik eG ( 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 ( 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 ( 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 ( Ed 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 RedefinableElement instead of State

  • Key: UMLR-685
  • Status: open  
  • Source: Object Management Group ( 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: Tue, 6 Dec 2016 19:45 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 ( 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 ( 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

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: Tue, 6 Dec 2016 19:33 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 ( 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 ( 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 ( 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 ( Jon 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 ( Jon Siegel)
  • Summary:

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

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

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

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

  • Key: UMLR-696
  • Status: open  
  • Source: nMeta ( Ed Seidewitz)
  • Summary:

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

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

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

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

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

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

  • Key: UMLR-92
  • Legacy Issue Number: 9751
  • Status: open  
  • Source: No Magic, Inc. ( 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 ( Axel Scheithauer)
  • Summary:

    The specification says:

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

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

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

XOR Constraint modeling

  • Key: UMLR-703
  • Status: open  
  • Source: Model Driven Solutions ( Ed 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

Meaning of Event on Initial Transition unclear

  • Key: UMLR-705
  • Status: open  
  • Source: oose Innovative Informatik eG ( 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 Aug 2016 18:49 GMT

Inconsistent constraints about several kinds of UML Diagrams

  • Key: UMLR-701
  • Status: open  
  • Source: NASA ( Nicolas 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 ( 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 ( 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: No Magic, Inc. ( 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: No Magic, Inc. ( 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: No Magic, Inc. ( 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: No Magic, Inc. ( Nerijus Jankevicius)
  • Summary:

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

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

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

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

    Figure 11.29 has the correct ordering:

    • summary of figure
    • the figure
    • explanation of figure

    Figure 11.30 has an incorrect ordering:

    • summary of figure
    • explanation of figure
    • the figure

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

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

Link to "see" sections missing

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

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

    are missing clickable cross-references.

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

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

AssociationEnd/Attribute redefintion consistency

  • Key: UMLR-679
  • Status: open  
  • Source: Model Driven Solutions ( Ed 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 ( Ed 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 ( 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 ( Ed Willink)
  • Summary:

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

    A similar typo occurs in 7.5.3.

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

Spec refers to TypeElement twice. Should be TypedElement

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

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

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

Constraint TemplateSignature::own_elements too constraining

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

    The Constraint TemplateSignature::own_elements says:

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

    This is not always possible.

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

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

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

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

Need example of derived qualifier.

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

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

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

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

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

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

The Kind field from frame names should be bold

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

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

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

    Please correct the list on page 682.

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

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

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

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

Need BNF for Protocol State Machines Transitions

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Package names in wrong location.

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

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

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

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

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

    Please make consistent or relax the location rules

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

Disjointness should be independent of generalization

  • Key: UMLR-35
  • Legacy Issue Number: 8014
  • Status: open  
  • Source: NIST ( Evan 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 ( 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 ( 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 ( Axel Scheithauer)
  • Summary:

    The Specification says

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

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

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

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

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

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

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

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

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

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

Unexpected trigger reception has contradictory results in Protocol State Machines

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

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

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


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

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

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

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

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

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

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

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

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

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

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

No notation for associations defined for abstract classes

  • Key: UMLR-658
  • Status: open  
  • Source: Model Driven Solutions ( 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 ( 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 ( Axel Scheithauer)
  • Summary:

    Inheritance is specified as

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

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

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

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

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

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

Rename Specialization/Generalization between abstract classes

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

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

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

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

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

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

    How should this be disambiguated

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

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

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

    See Summary

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

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

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

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

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

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

Use of decomposition indicator

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

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

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

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

InstanceSpecification for a qualified Property

  • Key: UMLR-648
  • Status: open  
  • Source: oose Innovative Informatik eG ( 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 ( 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

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

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

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

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

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

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

UML 2: Lifeline should be made a TemplateableElement

  • Key: UMLR-631
  • Legacy Issue Number: 19841
  • Status: open  
  • Source: Simula Research Laboratory ( 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 ( 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 ( 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 ( 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 ( Ed 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

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

  • Key: UMLR-420
  • Status: open  
  • Source: nMeta ( 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

NamedElement::allNamespaces is invalid at model root

  • Key: UMLR-328
  • Legacy Issue Number: 19349
  • Status: open  
  • Source: Model Driven Solutions ( Ed 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


UML 2.5: UML redefinition mechanism insufficiently granular

  • Key: UMLR-616
  • Legacy Issue Number: 19732
  • Status: open  
  • Source: Simula Research Laboratory ( 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

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

Incorrect drawing of non-navigable redefined opposites

  • Key: UMLR-326
  • Legacy Issue Number: 19345
  • Status: open  
  • Source: Model Driven Solutions ( Ed 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

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

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

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

Incorrectly drawn ParameterableElement.owningTemplateParameterSubstitution multiplicity

  • Key: UMLR-327
  • Legacy Issue Number: 19346
  • Status: open  
  • Source: Model Driven Solutions ( Ed 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

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

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

Improving the association direction notation

  • Key: UMLR-290
  • Legacy Issue Number: 19017
  • Status: open  
  • Source: NASA ( Nicolas 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

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

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

not sure it is possible to define a constraint without a context

  • Key: UMLR-224
  • Legacy Issue Number: 15236
  • Status: open  
  • Source: Airbus Group ( 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

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

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

Incorrect OrderedSet returns

  • Key: UMLR-330
  • Legacy Issue Number: 19351
  • Status: open  
  • Source: Model Driven Solutions ( Ed 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

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

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

Ambiguous Profile::profileApplication

  • Key: UMLR-316
  • Legacy Issue Number: 19323
  • Status: open  
  • Source: Model Driven Solutions ( Ed 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 2.3 Infra 12 Incomplete conformance for infinity

  • Key: UMLR-240
  • Legacy Issue Number: 15788
  • Status: open  
  • Source: Model Driven Solutions ( Ed 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

About behavior ports

  • Key: UMLR-292
  • Legacy Issue Number: 19070
  • Status: open  
  • Source: Airbus Group ( 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, 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

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

test

  • Key: UMLR-276
  • Legacy Issue Number: 18239
  • Status: open  
  • Source: Object Management Group ( Juergen Boldt)
  • Summary:

    test

  • Reported: UML 2.5 — Fri, 27 Jun 2014 11:17 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

UML 2.5 beta issue - Operation notation is wrong

  • Key: UMLR-423
  • Legacy Issue Number: 18611
  • Status: open  
  • Source: Model Driven Solutions ( 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

applying and associating stereotypes and explanation of all aspects of their serialization

  • Key: UMLR-275
  • Legacy Issue Number: 17564
  • Status: open  
  • Source: NASA ( Nicolas 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

Minor error in ptc-13-09-05

  • Key: UMLR-360
  • Legacy Issue Number: 19637
  • Status: open  
  • Source: Model Driven Solutions ( 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

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

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

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

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

Specification should not contain any methodology

  • Key: UMLR-331
  • Legacy Issue Number: 19353
  • Status: open  
  • Source: oose Innovative Informatik eG ( 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

Ports

  • Key: UMLR-229
  • Legacy Issue Number: 15290
  • Status: open  
  • Source: Airbus Group ( 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

Semantic error in Lifeline::interaction_uses_share_lifeline

  • Key: UMLR-281
  • Legacy Issue Number: 18972
  • Status: open  
  • Source: Model Driven Solutions ( Ed 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

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

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

Link notation for stereotype property value

  • Key: UMLR-273
  • Legacy Issue Number: 17464
  • Status: open  
  • Source: PTC ( 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

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

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

Message Signature in Interactions and Reception.ownedParameter

  • Key: UMLR-269
  • Legacy Issue Number: 17226
  • Status: open  
  • Source: Fraunhofer FOKUS ( 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

History pseudo states in protocol state machines

  • Key: UMLR-383
  • Legacy Issue Number: 19648
  • Status: open  
  • Source: KnowGravity Inc. ( 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

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

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

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

State::stateInvariant multiplicity too restrictive

  • Key: UMLR-253
  • Legacy Issue Number: 16249
  • Status: open  
  • Source: Northrop Grumman ( 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

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

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

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

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

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

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

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

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

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

BehavioralParameter should be BehavioralFeature

  • Key: UMLR-342
  • Legacy Issue Number: 19455
  • Status: open  
  • Source: Fraunhofer FOKUS ( 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

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

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

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

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

Aggregation missing from Property string syntax

  • Key: UMLR-232
  • Legacy Issue Number: 15315
  • Status: open  
  • Source: Adaptive ( 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

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

Unnamed elements in a namespace

  • Key: UMLR-325
  • Legacy Issue Number: 19342
  • Status: open  
  • Source: oose Innovative Informatik eG ( 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

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

Semantics of static features

  • Key: UMLR-343
  • Legacy Issue Number: 19468
  • Status: open  
  • Source: Airbus Group ( 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

orthogonal State missing on bullet point list

  • Key: UMLR-401
  • Status: open  
  • Source: oose Innovative Informatik eG ( 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: