Unified Modeling Language Avatar
  1. OMG Specification

Unified Modeling Language — Open Issues

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

Issues Summary

Key Issue Reported Fixed Disposition Status
UMLR-744 Attachment point of connectors not specified UML 2.5 open
UMLR-743 Implied Multiplicity of the association-like notation should be displayable UML 2.5 open
UMLR-742 Lifeline "same_classifier" constraint has an inconsistent specification UML 2.5 open
UMLR-741 Are two identical bound templates the same? UML 2.5 open
UMLR-738 Incorrect use of multiplicity element. UML 2.5 open
UMLR-620 Complete and Covering are Synonyms and used confusinginly UML 2.5 open
UMLR-730 Does the abort of an Do/Activity by an incoming event count as a Completion Event UML 2.5 open
UMLR-234 UML Interactions: Misleading suggestion of relationship between Interactions and Activities modeling UML 2.5 open
UMLR-438 Observations in TimeExpressions UML 2.5b1 open
UMLR-450 UML 2.5: Time Observation and Duration Observation problem UML 2.5b1 open
UMLR-740 DecisionNode is missing a constraint on incoming edges UML 2.5 open
UMLR-437 What is the abstract syntax for Figure 17.27? UML 2.5b1 open
UMLR-433 What is a UML diagram? is it restricted to showing elements that are instances of the M2 UML metamodel and nothing else? UML 2.5b1 open
UMLR-306 How to access a token value in a guard? UML 2.5 open
UMLR-428 Guard evaluation with decision input UML 2.5b1 open
UMLR-711 Conflicting constraints UML 2.5 open
UMLR-471 Allow a notation to allow for a default assignment of a decision to the owner of the activity UML 2.5b1 open
UMLR-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-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-717 Invalid XMI elements containing both xmi:type and href UML 2.5 open
UMLR-710 Missing visibility definition UML 2.5 open
UMLR-716 What is a "compound state"? UML 2.5 open
UMLR-715 All actions should be able to own control pins UML 2.5 open
UMLR-714 Missing Constraint: Associations cannot type StructuralFeatures UML 2.5 open
UMLR-348 Actor association constraint makes UseCase subclass of Class UML 2.5 open
UMLR-713 On page 290 of UML 2.5 formal/2015-03-01, UML 2.5 open
UMLR-712 New Issue on UML 2.5 formal/2015-03-01 re signalbroadcastaction vs. broadcastsignalaction UML 2.5 open
UMLR-92 UML/OCL spec mismatch-Constraint.context vs Constraint.constrainedElement UML 2.5 open
UMLR-696 The behavior of an OpaqueExpression should be allowed to have input parameters 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-431 problems with BehavioralFeature::method UML 2.5b1 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-666 Sequence Diagram Message Numbers UML 2.5 open
UMLR-41 section 7.3.17 /EnumerationLiteral should not be an InstanceSpecification UML 2.5 open
UMLR-665 Impossiblity to specify links for connected roles. UML 2.5 open
UMLR-664 Delegation Connector should not be typed UML 2.5 open
UMLR-663 Decide whether the document divisions are "sub clauses" or "subclauses" UML 2.5 open
UMLR-662 What are the type/classifiers of an InstanceValue UML 2.5 open
UMLR-660 Unexpected trigger reception has contradictory results in Protocol State Machines UML 2.5 open
UMLR-661 What does calling an "operation for a state" mean in PSM. UML 2.5 open
UMLR-658 No notation for associations defined for abstract classes UML 2.5 open
UMLR-202 UML:Notational option to display inherited features in a subclass UML 2.5 open
UMLR-657 Deploying a «deployment spec» has no explicit interpretation UML 2.5 open
UMLR-656 Shoppin->Shopping UML 2.5 open
UMLR-655 UML 2.5 refers to EBNF, but the spec uses a variant BNF, not EBNF UML 2.5 open
UMLR-384 Classifiers can contain Packages, but they can't have appropriate visibility UML 2.5 open
UMLR-654 Pin rectangles in examples should not overlap the action border UML 2.5 open
UMLR-653 Activity Generalization is underspecified UML 2.5 open
UMLR-315 Rename Specialization/Generalization between abstract classes UML 2.5 open
UMLR-449 Contradiction between the abstract syntax and semantics of an Interval UML 2.5b1 open
UMLR-652 In Sequence diagrams, the duration constraint shown as a vertical two-headed is ambiguous UML 2.5 open
UMLR-651 In the time-related syntax for Sequence diagrams, there are used two terms (now, duration). Are there more? Are these defined? UML 2.5 open
UMLR-650 It doesn't seem possible to use a time-based trigger in the alternate format transition-focused state machine. UML 2.5 open
UMLR-649 Use of decomposition indicator UML 2.5 open
UMLR-648 InstanceSpecification for a qualified Property UML 2.5 open
UMLR-646 Recursive use of Interaction Use UML 2.5 open
UMLR-647 Limitation on isDimension Partition to be uncontained appears unwarranted UML 2.5 open
UMLR-645 Classifier.allSlottableFeatures shall incorporate redefinition UML 2.5 open
UMLR-643 Location of owning fully qualifed name not specified. UML 2.5 open
UMLR-642 Clarify the difference between «create» and «instantiate» UML 2.5 open
UMLR-641 Missing parameter properties of stream and exception in BNF UML 2.5 open
UMLR-637 What is the order for EnumerationLiterals? UML 2.5 open
UMLR-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-429 Missing glossary UML 2.5b1 open
UMLR-420 Multiplicity of opposite end of a number of associations from various action metaclasses UML 2.5 open
UMLR-618 isDirectlyInstantiated is defined in reverse UML 2.5 open
UMLR-427 7.2.3, last sentence 2nd paragraph the revised text UML 2.5b1 open
UMLR-328 NamedElement::allNamespaces is invalid at model root UML 2.5 open
UMLR-351 Section 15.5.3: a missed word UML 2.5 open
UMLR-440 UseCases: no way for an Extend to pick out individual ownedBehaviors of the extending UseCase UML 2.5b1 open
UMLR-446 Shouldn't Gate and InteractionFragment be redefinable to support Interaction specialization? UML 2.5b1 open
UMLR-426 Uml2.5 issue - constraints of Behavior incorrectly assume context is always non-null UML 2.5b1 open
UMLR-430 Several UMLDI redefining associations are invalid UML 2.5b1 open
UMLR-468 Please provide running footers or headers indicating the section/subsection of a page UML 2.5b1 open
UMLR-472 Need packages overview diagram and explicit depiction of package dependencies UML 2.5b1 open
UMLR-451 Issue for Figure 17.18 UML 2.5b1 open
UMLR-452 Rg. Realization and InterfaceRealization UML 2.5b1 open
UMLR-454 UML 2.5 - figures 14.37 and 14.38 use incorrect notation for keyword UML 2.5b1 open
UMLR-466 Semantics of TimeConstraints and DurationConstraints UML 2.5b1 open
UMLR-455 Notation for Variables and Variable Actions is very vague and incomplete UML 2.5b1 open
UMLR-448 Clarification about Interactions owning Actions and about the semantics of Actions owned by Interactions UML 2.5b1 open
UMLR-459 Reply messages now mandatory? UML 2.5b1 open
UMLR-435 Definition of allOwningPackages() UML 2.5b1 open
UMLR-464 Semantics of Namespaces UML 2.5b1 open
UMLR-445 Behavior does not override NamedElement::isDistinguishableFrom() like BehavioralFeature does UML 2.5b1 open
UMLR-441 The notation for ExtensionPoint provides for an “explanation”, but the metamodel provides nowhere to store it. UML 2.5b1 open
UMLR-425 typo in 12.2.3 Model UML 2.5b1 open
UMLR-447 Incorrect notation in figure 14.37 UML 2.5b1 open
UMLR-465 Meaning of access to constrainedElements UML 2.5b1 open
UMLR-457 UML2.5 issue: constraints needed in model of Standard Profile UML 2.5b1 open
UMLR-434 PrimitiveTypes::Real is inconsistently specified relative to its mapping to xsd:double UML 2.5b1 open
UMLR-460 UML2.5: Clarification about UML profiles UML 2.5b1 open
UMLR-443 UML 2.5 issue. AssociationClasses should have isUnique property UML 2.5b1 open
UMLR-456 Issue with Reply message in interactions (UML 2.5 Beta) UML 2.5b1 open
UMLR-436 No explanation of how to deal with conflicting transitions of equal priority UML 2.5b1 open
UMLR-444 Clarification needed about the semantics of stereotype specialization and stereotype application UML 2.5b1 open
UMLR-469 Clarification re MOF Equivalent Semantics about defining/applying a stereotype to a slot of ininstance of a stereotype UML 2.5b1 open
UMLR-453 [UML 2.5] Redundancy in the definition of use case extensions UML 2.5b1 open
UMLR-467 Stereotype for extended bound element realization UML 2.5b1 open
UMLR-458 Serilaization of required stereotypes UML 2.5b1 open
UMLR-442 UseCases: Explanation of words “fragment” and “increment” UML 2.5b1 open
UMLR-462 Interactions and parameter assignments UML 2.5b1 open
UMLR-463 Semantics of Message argument mapping in Interactions UML 2.5b1 open
UMLR-439 Timing Events Question / Issue UML 2.5b1 open
UMLR-470 Profile: can a stereotype extend fewer metaclasses than another stereotype it specializes? UML 2.5b1 open
UMLR-347 UML 2.5 Beta 2 XMI invalid UML 2.5 open
UMLR-604 "Object identity" undefined UML 2.5b1 open
UMLR-461 Notation for DurationObservation with two event elements UML 2.5b1 open
UMLR-475 UML: No restrictions on what seem to be meaningless associations UML 2.5b1 open
UMLR-606 Inconsistent approach to type conformance UML 2.5b1 open
UMLR-616 UML 2.5: UML redefinition mechanism insufficiently granular UML 2.5 open
UMLR-605 Consistent use of "conforms to" vs. "is a subtype of" UML 2.5b1 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-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-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-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-245 New notation for attribute UML 2.5 open
UMLR-341 UML wording in Superstructure 2.4.1 UML 2.5 open
UMLR-607 Clarify aliasing in Namespaces UML 2.5b1 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-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-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-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-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-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-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-609 Clarify ownership vs. membership for NamedElements UML 2.5b1 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-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-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-301 Can PrimitiveTypes be user-defined and where? UML 2.5 open
UMLR-611 Fuzzy diagrams UML 2.5b1 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-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-107 Behavioral port UML 2.5 open
UMLR-78 consistent ordering of Association::memberEnd and ownedEnd UML 2.5 open
UMLR-81 All associations ends in the UML2 metamodel itself should be navigable UML 2.5 open
UMLR-173 UML2: Need clarification on circle plus notation for containment UML 2.5 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-67 Syntax of Transition UML 2.5 open
UMLR-195 Simplify by Making UML More Consistent: Allow States to be model as classes supporting inheritance and composition UML 2.5 open
UMLR-94 Default value types UML 2.5 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-174 Visibility and Import relationships UML 2.5 open
UMLR-149 Actors cannot own Operations - a contradiction UML 2.5 open
UMLR-61 Arguments of Message UML 2.5 open
UMLR-83 ControlNodes in ActivityPartitions UML 2.5 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-85 UML2: No notation for indicating Operation::raisedException UML 2.5 open
UMLR-212 UML: Cross model dependencies UML 2.5 open
UMLR-153 UML: Standard Techniques to disambiguate crossing lines needed UML 2.5 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-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-203 Provide notational mechanism to represent any group of model elements based on some criteria w/o stealing ownership UML 2.5 open
UMLR-184 Reconcile the algebra of collections across OCL & UML’s intentional & extensional semantics UML 2.5 open
UMLR-99 Optional values and evaluation of defaults UML 2.5 open
UMLR-116 UML 2.1.1 - notation for parameter sets UML 2.5 open
UMLR-129 pull semantics are only supported on Action inputs, not outputs UML 2.5 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-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-210 UML: Better Definition of Compliance UML 2.5 open
UMLR-197 UML: Incorporate SysML Requirements Model into UML UML 2.5 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-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-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-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-209 UML: Provide mathematical formalism for UML semantics to provide precise meaning to language constructs UML 2.5 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-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-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-66 OutputPin UML 2.5 open
UMLR-130 should be able to show gates on communication diagrams UML 2.5 open
UMLR-89 No way of specifying element documentation UML 2.5 open
UMLR-205 UML: Support for maintaining what-if models in repository without massive duplication UML 2.5 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-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-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-211 UML: Large Scale Model Support:Federated/Distibuted Models UML 2.5 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-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-217 UML: Timing semantics for activity diagram UML 2.5 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-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-33 Too much navigability from Generalizations UML 2.5 open
UMLR-23 UML2 Super/Deployment/inheritance UML 2.5 open
UMLR-24 UML2 Super/Deployments/Manifestation UML 2.5 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-10 Integration between behavioral "sublanguages": Interactions and Activities UML 2.5 open
UMLR-25 Priority of the joint transition UML 2.5 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-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-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

Attachment point of connectors not specified

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

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

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

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

Implied Multiplicity of the association-like notation should be displayable

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

    The specification says:

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

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

    Suggestion
    Add following sentence to the paragraph above:

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

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

Lifeline "same_classifier" constraint has an inconsistent specification

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

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

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

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

    Please clarify.

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

Are two identical bound templates the same?

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

    Consider: my general purpose library provides:

    mylib::Aggregate<T>

    My subsystems exploit this by drawing:

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

    and my application integrates the subsystems by drawing

    myapp::Aggregate<T -> String>

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

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

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

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

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

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

Incorrect use of multiplicity element.

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

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

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

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

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

Complete and Covering are Synonyms and used confusinginly

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Observations in TimeExpressions

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

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

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

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

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

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

UML 2.5: Time Observation and Duration Observation problem

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

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

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

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

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

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

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

DecisionNode is missing a constraint on incoming edges

  • Key: UMLR-740
  • Status: open  
  • Source: 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

What is the abstract syntax for Figure 17.27?

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

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

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

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

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

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

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

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

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

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

    { redefines DI::DiagramElement::modelElement }

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

    { redefines DI::DiagramElement::ownedElement }

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

    { redefines DI::DiagramElement::owningElement }

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

    { redefines DI::Edge::source }

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

    { redefines DI::Edge::target }

    These redefinitions have significant consequences:

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

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

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

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

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

    This approach seems very inflexible.

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

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

    This could be easily addressed with queries:

    UMLDI::UMLDiagramElement::showsUMLContentOnly() : Boolean

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

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

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

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

How to access a token value in a guard?

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

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

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

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

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

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

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

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

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

Guard evaluation with decision input

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

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

    Did I miss something?

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

Conflicting constraints

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

    One of the constraints on objectFlows in 15.7.22.6 is

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

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

    Imagine a decisionNode with 2 incoming objectFlows:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

problems with BehavioralFeature::method

  • Key: UMLR-431
  • Legacy Issue Number: 18847
  • Status: open  
  • Source: No Magic, Inc. ( Nerijus Jankevicius)
  • Summary:

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

    The UML metamodel problems:

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

    Clarifications and possible spec corrections are highly appreciated.

    UML 2.5 beta spec says:

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

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

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

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

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

Sequence Diagram Message Numbers

  • Key: UMLR-666
  • Status: open  
  • Source: No Magic, Inc. ( Jim Logan)
  • Summary:

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

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

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

What are the type/classifiers of an InstanceValue

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

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

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

    Suggest addition of:

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

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

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

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

Unexpected trigger reception has contradictory results in Protocol State Machines

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

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

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


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

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

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

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

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

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

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

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

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

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

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

No notation for associations defined for abstract classes

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

Contradiction between the abstract syntax and semantics of an Interval

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

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

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

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

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

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

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

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

    How should this be disambiguated

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

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

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

    See Summary

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

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

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

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

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

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

Use of decomposition indicator

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

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

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

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

InstanceSpecification for a qualified Property

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

Missing glossary

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

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

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

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

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

7.2.3, last sentence 2nd paragraph the revised text

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

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

    Every Element in a model must be owned by exactly one other Element of that model, with the exception of the top-level Packages of the model (see also Clause 12 on Packages)

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

    I suggest:

    Every Element in a model must be owned by exactly one other Element of that model, with the exception of the top-level Packages of the model, which may be un-owned. (see also Clause 12 on Packages)

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

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

UseCases: no way for an Extend to pick out individual ownedBehaviors of the extending UseCase

  • Key: UMLR-440
  • Legacy Issue Number: 18731
  • Status: open  
  • Source: Model Driven Solutions ( Steve Cook)
  • Summary:

    Although the textual semantics asserts that it can – “individual fragments” and other references - there is no way for an Extend to pick out individual ownedBehaviors of the extending UseCase

  • Reported: UML 2.5b1 — Thu, 23 May 2013 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Shouldn't Gate and InteractionFragment be redefinable to support Interaction specialization?

  • Key: UMLR-446
  • Legacy Issue Number: 18698
  • Status: open  
  • Source: NASA ( Nicolas Rouquette)
  • Summary:

    ML 2.5 section 17.2.3 Interaction semantics says:

    As Behavior an Interaction is generalizable and redefineable. Specializing an Interaction is simply to add more traces to those of the original. The traces defined by the specialization is combined with those of the inherited Interaction with a union.

    If a parent Interaction defines Gates, then a specializing Interaction will inherit its parent's Gates as Classifier::/inheritedMember.
    However, Gates that are inherited from a parent Interaction are not formalGates of a specializing Interaction; therefore, they cannot be used or redefined in the context of the specializing Interaction!

    Similarly, if a parent Interaction has fragments, then a specializing Interaction will inherit its parent's InteractionFragment as Classifier::/inheritedMember.
    However, InteractionFragment that are inherited from a parent Interaction are not fragments of a specializing Interaction; therefore, they cannot be used or redefined in the context of the specializing Interaction!

    To support the intent of the Interaction semantics, I suggest adding RedefinableElement as generalization parents of Gate and InteractionFragment.

  • Reported: UML 2.5b1 — Tue, 7 May 2013 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Uml2.5 issue - constraints of Behavior incorrectly assume context is always non-null

  • Key: UMLR-426
  • Legacy Issue Number: 18860
  • Status: open  
  • Source: Model Driven Solutions ( Steve Cook)
  • Summary:

    Constraints most_one_behavior and feature_of_context_classifier incorrectly assume context is always non-null. The latter also seems to assume that specification is non-null.

  • Reported: UML 2.5b1 — Wed, 7 Aug 2013 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Several UMLDI redefining associations are invalid

  • Key: UMLR-430
  • Legacy Issue Number: 18855
  • Status: open  
  • Source: NASA ( Nicolas Rouquette)
  • Summary:

    As much as I do not like the current restrictive approach taken for UMLDI,
    there are problems with the following associations, each of which fail the
    "redefined_property_inherited" constraint for their association-owned end:

    Figure B.4:

    A_UMLEdge_source_sourceEdge
    A_UMLEdge_target_targetEdge

    Figure B.5

    A_UMLNameLabel_modelElement_umlDiagramElement
    A_UMLRedefines_modelElement_umlDiagramElement

    Figure B.7

    A_UMLStereotypePropertyValueLabel_modelElement_umlDiagramElement

    Figure B.8

    A_UMLDiagramElement_localStyle_styledElement
    A_UMLDiagramElement_sharedStyle_styledElement

    Figure B.10

    A_UMLClassifierShape_modelElement_umlDiagramElement

    Figure B.11

    A_UMLAssociationEndLabel_modelElement_umlDiagramElement
    A_UMLMultiplicityElement_modelElement_umlDiagramElement

    Figure B.13

    A_UMLBehaviorDiagram_modelElement_umlDiagramElement
    A_UMLStateMachine_modelElement_umlDiagramElement
    A_UMLActivityDiagram_modelElement_umlDiagramElement
    A_UMLInteractionDiagram_modelElement_umlDiagramElement

    Figure B.14

    A_UMLStateShape_modelElement_umlDiagramElement

    All of these associations lack a generalization to the association whose
    ends are redefined.

  • Reported: UML 2.5b1 — Wed, 7 Aug 2013 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Please provide running footers or headers indicating the section/subsection of a page

  • Key: UMLR-468
  • Legacy Issue Number: 18252
  • Status: open  
  • Source: NASA ( Nicolas Rouquette)
  • Summary:

    The UML 2.5 document has great hyperlink/navigation support.
    However, since sub-sub-sections are unnumbered, it is sometimes difficult to tell where we are in the document if the sub-section runs across multiple pages.

    For example, look at sub-section 14.2.3 Semantics. The short title makes sense for the bookmarks but in the document itself, it would be easier if we had: 14.2.3 StateMachines Semantics
    This particular sub-section runs over several pages and has several sub-sub-sections; e.g. "States" on p. 319. It's hard to tell we're in the middle of 14.2.3.
    Unfortunately, Acrobat doesn't have a way to highlight the bookmark corresponding to the page we're currently reading.

    I suggest adding a footer or header with the numbered section or sub-section title to each page.
    It would be even better if the footer/header were in fact a hyperlink to jump to the beginning of that numbered section/sub-section.

  • Reported: UML 2.5b1 — Tue, 6 Nov 2012 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Need packages overview diagram and explicit depiction of package dependencies

  • Key: UMLR-472
  • Legacy Issue Number: 18195
  • Status: open  
  • Source: Simula Research Laboratory ( Bran Selic)
  • Summary:

    In the current 2.5 metamodel, there is a diagram that simply shows all the various packages that comprise it. Note, however, that we do not have such a diagram in the spec itself. In fact, as far as I can tell, it seems that the spec does not even mention explicitly that the metamodel is divided up into these packages.

    Furthermore, it is useful to see the dependencies between the various packages captured explicitly in diagrams. In a sense, this shows the intended couplings between the various modules, which is usually important architectural information. Not showing them explicitly either in the spec or in a metamodel diagram is obscuring this and could lead to corruption of the architecture in subsequent maintenance (e.g., the introduction of undesired and even incorrect couplings between the packages).

  • Reported: UML 2.5b1 — Tue, 23 Oct 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Issue for Figure 17.18

  • Key: UMLR-451
  • Legacy Issue Number: 18568
  • Status: open  
  • Source: Fraunhofer FOKUS ( Marc-Florian Wendland)
  • Summary:

    Figure 17.18 (Abstract Syntax: InteractionUse) does not show the association ‘A_returnValueRecipient_interactionUse’

  • Reported: UML 2.5b1 — Tue, 19 Mar 2013 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Rg. Realization and InterfaceRealization

  • Key: UMLR-452
  • Legacy Issue Number: 18496
  • Status: open  
  • Source: Fraunhofer FOKUS ( Marc-Florian Wendland)
  • Summary:

    not sure, but the way how Interfaces are supposed to be realizd throughout the spec may need some more Clarification in the spec. I might have missed some discussions on this topic, though. If this has already been clarified (haven’t found an issue in the issue sheet for the component section), please ignore my question.

    The required/provided Interfaces of Components are derived. The derivation algorithm (p 235) makes use of Classifier.allRealizedInterfaces() and C.allUsedInterface(). I do not have any problems with allUsedInterface, but allRealizedInterfaces() or more concrete directlyRealizedInterfaces() is not very well chosen I think. directlyRealizedInterface() is based on Realizations between the Classifier and an Interface. Given this, any Interface that is referenced by ComponentRealization or Substitution is part of the realized Interfaces of that Classifier.

    As a BehavioredClassifier, a Component should make use of InterfaceRealization solely. However, the provided Interfaces of a Component rely on the above mentioned concept, i.e., a Realization between a Classifier and Interface. Of course, using an InterfaceRealization instead would also do the job and calculate the provided Interface of that Component correctly. In case of Class and Component, it is just confusing why the algorithm to calculate the provided Interfaces is based on Realization, whereas BehavioredClassifier uses InterfaceRealizations. It could be even more confusing, in case only Realization relationships are used to establish the provided Interfaces, asking for BehavioredClassifier.interfaceRealization might return an empty list, since all Interfaces are realized via Realization.

    This may cause other issues: A DataType could establish a Realization dependency to an Interface. Classifier.allRealizedInterfaces() would return that Interface. This holds true for all non-Class Classifier, in fact. Is this a desired situation?

  • Reported: UML 2.5b1 — Fri, 22 Feb 2013 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML 2.5 - figures 14.37 and 14.38 use incorrect notation for keyword

  • Key: UMLR-454
  • Legacy Issue Number: 18449
  • Status: open  
  • Source: Model Driven Solutions ( Steve Cook)
  • Summary:

    Figures 14.37 and 14.38 show the word

    {extended}

    but the notation definition in 14.3.4 defines the keyword «extended» in guillemets. If it is a keyword, which is confirmed by Annex C, then the guillemets are correct and the curly braces wrong.

  • Reported: UML 2.5b1 — Wed, 13 Feb 2013 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Semantics of TimeConstraints and DurationConstraints

  • Key: UMLR-466
  • Legacy Issue Number: 18277
  • Status: open  
  • Source: nMeta ( Ed Seidewitz)
  • Summary:

    Specification: OMG Unified Modeling Language (OMG UML), Version 2.5 FTF – Beta 1 (ptc/2012-10-24)

    Subclause: 8.5.3

    A TimeConstraint is specified by a TimeInterval that has min and max TimeExpressions. Similarly, a DurationConstraint is specified by a DurationInterval that has min and max Durations. Both TimeExpressions and Durations identify Observations of specific event NamedElements. Should these observed event NamedElements be related to the constrainedElements of the constraints, and, if so, how?

  • Reported: UML 2.5b1 — Tue, 20 Nov 2012 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Notation for Variables and Variable Actions is very vague and incomplete

  • Key: UMLR-455
  • Legacy Issue Number: 18506
  • Status: open  
  • Source: Commissariat a l Energie Atomique-CEA ( Sebastien Gerard)
  • Summary:

    I think the notation for variables is supposed to be covered by the notation for variable actions – see figure 16.38, which describes a presentation option, but there is actually no specification for the canonical notation that it is an option for – nor was there in 2.4. We need a new issue: “Notation for Variables and Variable Actions is very vague and incomplete

  • Reported: UML 2.5b1 — Wed, 27 Feb 2013 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Clarification about Interactions owning Actions and about the semantics of Actions owned by Interactions

  • Key: UMLR-448
  • Legacy Issue Number: 18696
  • Status: open  
  • Source: NASA ( Nicolas Rouquette)
  • Summary:

    In UML 2.5, the summary of the Actions chapter in 16.1 refers to the possibility of an Interaction owning an Action and makes several points:

    (1) Actions are contained in Behaviors, specifically Activities (as ExecutableNodes, see Clause 15) and Interactions (see Clause 17). These Behaviors determine when Actions execute (2) and what inputs they have (3). However, the abstract syntax and semantics of Actions are very dependent on Activities (4), because they specialize elements and semantics from Activities to accept inputs and provide outputs and to define Actions that coordinate other Actions (Structured Actions, see sub clause 16.11).

    (1) is reflected in figure 17.1

    (2) is under-specified.

    17.12, ActionExecutionSpecification states:
    An ActionExecutionSpecification is a kind of ExecutionSpecification representing the execution of an Action.
    17.5.3 semantics of Action Execution Specification states:
    ActionExecutionSpecification is used for interactions specifying messages that result from actions, which may be actions owned by other behaviors.

    The semantics of ActionExecutionSpecification should be described in 1 place; suggest 17.12.

    (3) is a problem because 17.12 + 17.5.3 are insufficient to explain the semantics of ActionExecutionSpecification.

    Depending on who owns the Action and of the context classifier for the Action vs. the Interaction, several cases need to be distinguished.
    An ActionExecutionSpecification refers to an Action owned by the owning Interaction
    An ActionExecutionSpecification refers to an Action owned by an Activity whose context classifier is different than the context classifier of the owning Interaction
    An ActionExecutionSpecification refers to an Action owned by an Activity whose context classifier is also the context classifier of the owning Interaction
    The first case is severely under-specified.
    The last two cases are more complicated because the semantics of ActionExecutionSpecification depends on the semantics of Action owned by an Activity.

    In all 3 cases, it is unclear how the message notation in Interactions relates to the input/output pins of actions referred to via an ActionExecutionSpecification.

  • Reported: UML 2.5b1 — Tue, 7 May 2013 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Reply messages now mandatory?

  • Key: UMLR-459
  • Legacy Issue Number: 18413
  • Status: open  
  • Source: Fraunhofer FOKUS ( Marc-Florian Wendland)
  • Summary:

    until UML 2.3, the spec said about reply messages: “If the Message represents a CallAction, there will normally be a reply message from the called Lifeline back to the calling lifeline before the calling Lifeline will proceed.”

    Did the initial submission team agree on making reply messages mandatory?

    I’m just asking because the above mentioned sentence was removed (actually already by UML 2.4 RTF) and there is only one example listed in the current spec for synchronous calls showing reply messages, and also the semantics of Message indicates that reply messages are mandatory from now on.

    Tool vendors commonly not enforce the existence of reply messages for synchronous calls.

  • Reported: UML 2.5b1 — Fri, 1 Feb 2013 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Definition of allOwningPackages()

  • Key: UMLR-435
  • Legacy Issue Number: 18806
  • Status: open  
  • Source: Model Driven Solutions ( Steve Cook)
  • Summary:

    NamedElement:: allOwningPackages() is documented as

    “The query allOwningPackages() returns all the Packages that in which this NamedElement is directly or indirectly contained, without any intervening Namespace that is not a Package.”

    But the OCL is

    if namespace.oclIsKindOf(Package)

    then

    let owningPackage : Package = namespace.oclAsType(Package) in

    owningPackage->union(owningPackage.allOwningPackages())

    else

    null

    endif

    Which would stop looking at any element not owned by a Package - which contradicts the documentation.

    I think it should instead read:

    allNamespaces()->select(oclIsKindOf(Package))

    But allOwningPackages is only used in Profile::references_same_metamodel, and I don’t like that either:

    All elements imported either as metaclassReferences or through metamodelReferences are members of the same base reference metamodel.

    inv: metamodelReference.importedPackage.elementImport.importedElement.allOwningPackages()->

    union(metaclassReference.importedElement.allOwningPackages() )->notEmpty()

    Surely this is completely wrong, both in its own right, and especially in the light of the following statement:

    Where both a metaclassReference and a metamodelReference are present on a profile, the latter is ignored and only the specific metaclasses are available.

    I’m thinking the right logic would be something like this:

    (metaClassReference->isEmpty() implies metamodelReference.importedPackage.member->forAll( m1, m2 | m1.allOwningPackages().intersection(m2.allOwningPackages())->notEmpty()))

    and

    metaclassReference.importedElement->forAll( m1, m2 | m1.allOwningPackages().intersection(m2.allOwningPackages())->notEmpty())

    Any comments?

  • Reported: UML 2.5b1 — Wed, 10 Jul 2013 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Semantics of Namespaces

  • Key: UMLR-464
  • Legacy Issue Number: 18272
  • Status: open  
  • Source: nMeta ( Ed Seidewitz)
  • Summary:

    Specification: OMG Unified Modeling Language (OMG UML), Version 2.5 FTF – Beta 1 (ptc/2012-10-24)

    Subclause: 7.4.3

    The semantics of Namespaces in 7.4.3 needs to be better specified. In particular:

    • The concepts of “enclosing Namespace”, “hidden members” and “accessibility/availability of names” need to be clearly defined.
    • The handling of name clashes , visibility and distinguishability needs to be better specified.
    • The use of partially qualified vs. fully qualified names needs to be addressed.
  • Reported: UML 2.5b1 — Tue, 20 Nov 2012 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Behavior does not override NamedElement::isDistinguishableFrom() like BehavioralFeature does

  • Key: UMLR-445
  • Legacy Issue Number: 18728
  • Status: open  
  • Source: NASA ( Nicolas Rouquette)
  • Summary:

    BehavioralFeatures and Behaviors use Parameters to specify their signature; however, only BehavioralFeature overrides namespace distinguishability to take into account its signature; Behavior uses the inherited criteria from NamedElement. This means that two Behaviors of the same name and kind but with different Parameter signatures are not distinguishable in the same way that BehavioralFeatures of the same name and kind are.

    For example, two StateMachines with the same name but distinct Parameter signatures (in the sense of BehavioralFeature) are not Namespace distinguishable.
    It is unclear whether this is an explicit intent of the spec or a bug in the spec.

  • Reported: UML 2.5b1 — Wed, 22 May 2013 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

The notation for ExtensionPoint provides for an “explanation”, but the metamodel provides nowhere to store it.

  • Key: UMLR-441
  • Legacy Issue Number: 18732
  • Status: open  
  • Source: Model Driven Solutions ( Steve Cook)
  • Summary:

    The notation for ExtensionPoint provides for an “explanation”, but the metamodel provides nowhere to store it.

  • Reported: UML 2.5b1 — Thu, 23 May 2013 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

typo in 12.2.3 Model

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

    Last paragraph in 12.2.3 Model

    Currently

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

    Propose

    Relationships between elements in different Models generally have no direct impact on the contents of the Models because each Model is meant to be complete

  • Reported: UML 2.5b1 — Sun, 15 Sep 2013 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Incorrect notation in figure 14.37

  • Key: UMLR-447
  • Legacy Issue Number: 18701
  • Status: open  
  • Source: Model Driven Solutions ( Steve Cook)
  • Summary:

    Figure 14.37 shows an “extended” state machine. In it, the state ReadAmount is shown as extended, which means it is not inherited. Hence ReadAmount should have a solid border, not a dashed one.

  • Reported: UML 2.5b1 — Wed, 8 May 2013 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Meaning of access to constrainedElements

  • Key: UMLR-465
  • Legacy Issue Number: 18274
  • Status: open  
  • Source: nMeta ( Ed Seidewitz)
  • Summary:

    Specification: OMG Unified Modeling Language (OMG UML), Version 2.5 FTF – Beta 1 (ptc/2012-10-24)

    Subclause: 7.6.3

    The semantics of Constraints includes the statement “The only restriction is that the owning Element must have access to the constrainedElements.” What does it mean for one Element to “have access” to another?

  • Reported: UML 2.5b1 — Tue, 20 Nov 2012 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML2.5 issue: constraints needed in model of Standard Profile

  • Key: UMLR-457
  • Legacy Issue Number: 18443
  • Status: open  
  • Source: Model Driven Solutions ( Steve Cook)
  • Summary:

    Issue 15144 pointed out a lot of flaws in the modeling of standard profiles. Some of those flaws involved the absence of constraints. To help manage the process, I’m raising a separate issue that just lists the constraints that are needed. They ought to be OCL in the profile.

    The client and supplier of Usages stereotyped by Call must be Operations.

    The client and supplier of Usages stereotyped by Create must be Classifiers.

    Realization and ImplementationClass may not both be applied to the same element.

    Specification and Type may not both be applied to the same element.

    The clients of Usages stereotyped by Send must be Operations, and the suppliers must be Signals.

  • Reported: UML 2.5b1 — Tue, 12 Feb 2013 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

PrimitiveTypes::Real is inconsistently specified relative to its mapping to xsd:double

  • Key: UMLR-434
  • Legacy Issue Number: 18830
  • Status: open  
  • Source: NASA ( Nicolas Rouquette)
  • Summary:

    UML says:

    An instance of Real is a value in the (infinite) set of real numbers. Typically an implementation will internally represent Real numbers using a floating point standard such as ISO/IEC/IEEE 60559:2011 (whose content is identical to the predecessor IEEE 754 standard).

    Mapping this to xsd:double is just wrong:

    xsd:double has finite cardinality; PrimitiveTypes::Real has infinite cardinality.

    xsd:double has both upper and lower limits; PrimitiveTypes::Real has no such limits.

    3.3.5 double – http://www.w3.org/TR/2012/REC-xmlschema11-2-20120405/#double

    [Definition:] The double datatype is patterned after the IEEE double-precision 64-bit floating point datatype [IEEE 754-2008]. Each floating point datatype has a value space that is a subset of the rational numbers. Floating point numbers are often used to approximate arbitrary real numbers.

    Note: The only significant differences between float and double are the three defining constants 53 (vs 24), -1074 (vs -149), and 971 (vs 104).

    3.3.5.1 Value Space

    The ·value space· of double contains the non-zero numbers m × 2e , where m is an integer whose absolute value is less than 253, and e is an integer between -1074 and 971, inclusive. In addition to these values, the ·value space· of double also contains the following ·special values·: positiveZero, negativeZero, positiveInfinity, negativeInfinity, and notANumber.

    Note: As explained below, the ·lexical representation· of the double value notANumber is 'NaN'. Accordingly, in English text we generally use 'NaN' to refer to that value. Similarly, we use 'INF' and '-INF' to refer to the two values positiveInfinity and negativeInfinity, and '0' and '-0' to refer to positiveZero and negativeZero.

    Equality and order for double are defined as follows:

    Equality is identity, except that 0 = -0 (although they are not identical) and NaN ? NaN (although NaN is of course identical to itself).

    0 and -0 are thus equivalent for purposes of enumerations, identity constraints, and minimum and maximum values.

    For the basic values, the order relation on double is the order relation for rational numbers. INF is greater than all other non-NaN values; -INF is less than all other non-NaN values. NaN is ·incomparable· with any value in the ·value space· including itself. 0 and -0 are greater than all the negative numbers and less than all the positive numbers.

    Note: Any value ·incomparable· with the value used for the four bounding facets (·minInclusive·, ·maxInclusive·, ·minExclusive·, and ·maxExclusive·) will be excluded from the resulting restricted ·value space·. In particular, when NaN is used as a facet value for a bounding facet, since no double values are ·comparable· with it, the result is a ·value space· that is empty. If any other value is used for a bounding facet, NaN will be excluded from the resulting restricted ·value space·; to add NaN back in requires union with the NaN-only space (which may be derived using the pattern 'NaN').

    Note: The Schema 1.0 version of this datatype did not differentiate between 0 and -0 and NaN was equal to itself. The changes were made to make the datatype more closely mirror [IEEE 754-2008].

    3.3.5.2 Lexical Mapping

    The ·lexical space· of double is the set of all decimal numerals with or without a decimal point, numerals in scientific (exponential) notation, and the ·literals· 'INF', '+INF', '-INF', and 'NaN'

    Lexical Space

    [5] doubleRep ::= noDecimalPtNumeral | decimalPtNumeral | scientificNotationNumeral | numericalSpecialRep

    The doubleRep production is equivalent to this regular expression (after whitespace is eliminated from the expression):

    (+|)?([0-9](\.[0-9]*)?|\.[0-9])([Ee](+|)?[0-9]+)? |(+|-)?INF|NaN

    The double datatype is designed to implement for schema processing the double-precision floating-point datatype of [IEEE 754-2008]. That specification does not specify specific ·lexical representations·, but does prescribe requirements on any ·lexical mapping· used. Any ·lexical mapping· that maps the ·lexical space· just described onto the ·value space·, is a function, satisfies the requirements of [IEEE 754-2008], and correctly handles the mapping of the literals 'INF', 'NaN', etc., to the ·special values·, satisfies the conformance requirements of this specification.

    Since IEEE allows some variation in rounding of values, processors conforming to this specification may exhibit some variation in their ·lexical mappings·.

    The ·lexical mapping· ·doubleLexicalMap· is provided as an example of a simple algorithm that yields a conformant mapping, and that provides the most accurate rounding possible?and is thus useful for insuringg inter-implementation reproducibility and inter-implementation round-tripping. The simple rounding algorithm used in ·doubleLexicalMap· may be more efficiently implemented using the algorithms of [Clinger, WD (1990)].

    Note: The Schema 1.0 version of this datatype did not permit rounding algorithms whose results differed from [Clinger, WD (1990)].

    The ·canonical mapping· ·doubleCanonicalMap· is provided as an example of a mapping that does not produce unnecessarily long ·canonical representations·. Other algorithms which do not yield identical results for mapping from float values to character strings are permitted by [IEEE 754-2008].

    3.3.5.3 Facets

    The double datatype and all datatypes derived from it by restriction have the following ·constraining facets· with fixed values; these facets must not be changed from the values shown:

    whiteSpace = collapse (fixed)

    Datatypes derived by restriction from double may also specify values for the following ·constraining facets·:

    pattern

    enumeration

    maxInclusive

    maxExclusive

    minInclusive

    minExclusive

    assertions

    The double datatype has the following values for its ·fundamental facets·:

    ordered = partial

    bounded = true

    cardinality = finite

    numeric = true

  • Reported: UML 2.5b1 — Thu, 25 Jul 2013 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML2.5: Clarification about UML profiles

  • Key: UMLR-460
  • Legacy Issue Number: 18366
  • Status: open  
  • Source: NASA ( Nicolas Rouquette)
  • Summary:

    12.3.1 Summary

    The only mentions that the profile mechanism is applicable to arbitrary metamodel are:

    > The Profiles clause describes capabilities that allow metaclasses to be extended to adapt them for different purposes. (1st paragraph)

    The paragraph continues with "the UML metamodel". So the generality is very subtle.

    > In order to allow this, the reference metamodel must be defined as an instance of UML that corresponds to its definition using MOF.

    The next sentence reverts to the special case of a UML profile extending the UML metamodel:

    > Thus when defining a UML profile, the profile’s stereotypes are defined to extend the UML classes in the normative version of the UML metamodel whose XMI serialization is referenced in Annex E.

    The next paragraph is the same:

    > Profiles are not a first-class extension capability (i.e., it does not allow for creating new metamodels).

    > Rather, the intention of Profiles is to give a straightforward mechanism for adapting an existing metamodel with constructs that are specific to a particular domain, platform, or method.

    Again, the generality is lost in the next sentence:

    > Each such adaptation is grouped in a Profile. It is not possible to remove any of the Constraints that apply to UML using a Profile, but it is possible to add new Constraints that are specific to the Profile.

    The reasons for defining a profile are only explained in terms of extending the UML metamodel.

    If anything, these reasons are equally applicable for extending UMLDI!

    12.3.3 Semantics

    The sub-clause "Restricting Availability of UML Elements" is specific to UML profiles extending the UML metamodel.

    This is misleading. These restrictions are equally valid for UML profiles extending other metamodels (defined in UML of course)

    ProfileApplication.

    This is written again from the perspective of a UML profile extending the UML metamodel:

    > One or more Profiles that extend UML may be applied at will to a model Package.

    Again, the generality is lost.

    Stereotypes

    The "Restricting Availability of UML Elements" section in Profiles has the following constraint:

    > Stereotypes can participate only in binary Associations. The opposite class can be another Stereotype, a non-Stereotype Class that is a packagedElement of a Profile (directly or indirectly), or a UML metaclass.

    Because this constraint is in 12.3.1 only and not in 12.3.3, it is unclear whether this constraint is only applicable to UML profiles extending the UML metamodel or not.

    These problems are a consequence of the organization of the Profile clause which has an uneven split where the UML-based explanation is in one place (12.3.1) and the generic explanation elsewhere (12.3.3)

    For readers, it is difficult to tell whether there are differences between the two capabilities.

    It is difficult to tell what is specific to UML profiles extending the UML metamodel (I.e., does not apply to UML profiles extending other metamodels)

    It is difficult to tell whether users have to figure out how to "merge" 12.3.1 and 12.3.3 for UML profiles that extend both the UML metamodel and some other metamodel.

    This difficulty comes from the duplication of the content, once for UML a second time for other cases.

    It would be better if the material were not duplicated at all and if there care special cases for UML profiles extending the UML metamodel that do not apply to other cases, then have these clearly described in a sub-clause.

  • Reported: UML 2.5b1 — Tue, 8 Jan 2013 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML 2.5 issue. AssociationClasses should have isUnique property

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

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

  • Reported: UML 2.5b1 — Wed, 15 May 2013 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Issue with Reply message in interactions (UML 2.5 Beta)

  • Key: UMLR-456
  • Legacy Issue Number: 18457
  • Status: open  
  • Source: Simula Research Laboratory ( Bran Selic)
  • Summary:

    There is a clarifying statement for the labels on reply messages that was added in UML 2.5 Beta, which reads:

    "The message-name appearing in a reply-message-label is the name property of the Message. If the Message has a signature, this will be the name of the Operation referenced by the signature (which should be the Operation for whose call this is a reply)."

    This is more constrained than was the case in UML 2.4 and can lead to some backward compatibility problems. Namely, there is a situation supported in RSA-RTE where the reply message to an Operation call can have a different label than the name of the Operation to which it is a response.

    Although there is no OCL constraint that mandates that the label of the reply message has to be the same as the Operation that caused it, the above text can be interpreted as if such a constraint existed. My suggestion is to modify the second sentence in the quoted text above to read:

    " If the Message has a signature, this can be the name of the Operation referenced by the signature (which should be the Operation for whose call this is a reply)."

    This leaves the clarification in place, but does not prevent the possibility of different labels on the reply message.

  • Reported: UML 2.5b1 — Thu, 14 Feb 2013 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

No explanation of how to deal with conflicting transitions of equal priority

  • Key: UMLR-436
  • Legacy Issue Number: 18812
  • Status: open  
  • Source: Simula Research Laboratory ( Bran Selic)
  • Summary:

    The spec does not say anything about how to deal with the case where two or more conflicting transitions with the same priority (e.g., triggered by the same event but with different guards that evaluate to true). Presumably, this is left as an implementation choice.

    In any case, there should be an explicit statement on this point.

  • Reported: UML 2.5b1 — Mon, 15 Jul 2013 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Clarification needed about the semantics of stereotype specialization and stereotype application

  • Key: UMLR-444
  • Legacy Issue Number: 18706
  • Status: open  
  • Source: NASA ( Nicolas Rouquette)
  • Summary:

    Many profiles define stereotypes that specialize other stereotypes.
    UML 2.5 does this in two places:

    • UML 2.5, section 12.3.5 Examples, Figure 12.19 where the Entity and
      Session stereotypes specialize the Bean stereotype
    • UML2.5, section 22 StandardProfile, Figure 22.1 where the File
      stereotype has several specializations (Document, Executable, Š)

    The UML specification does not explicitly define a the semantics of
    stereotype specialization, particularly with respect to stereotype
    application.
    This puts UML users and UML tool vendors in the difficult position to
    interpret the UML specification to come up with such a semantics.
    Given the popularity of UML profiles in practice, the UML specification
    must explain this clearly.

    I propose using the UML semantics of classifier generalization as a
    guiding principle for specifying the semantics of stereotype
    specialization and application; that is:

    1) If a stereotype S2 specializes S1, then the semantics of S2 must be
    consistent with the semantics of S1.
    2) Given (1), the semantics of applying S2 to X must be consistent with
    the semantics of applying S1 to X.
    3) Given (1) and (2), it must be possible to define S2 in several ways:

    3a) S2 specializes S1; S1 is abstract and does not define any extension;
    S2 extends Classifier.

    There is only one property: S2::base_Classifier.
    It is not possible to apply S1 because it is abstract.
    Only S2 can be applied.

    3b) S2 specializes S1 but S2 does not define its own extension; instead,
    it inherits S1's "base_" property or properties.

    It is possible to apply S1 or S2 or both to the same element.
    The semantics should be consistent regardless of whether S1 only, S2 only
    or S1 and S2 are applied.

    3c) S2 specializes S1 and defines its own extension(s) by specializing
    S1's extension relationships and redefining the extension ends.

    For example, suppose S1 extends Classifier, then S1 has a property:
    S1::base_Classifier.
    Then, if S2 extends Classifier, the extension between S2 and Classifier
    specializes the extension between S1 and Classifier with redefinitions on
    both sides.
    That is, S2::base_Classifier

    { redefines S1::base_Classifier }

    This ensures that the semantics of applying S1 only to a Classifier is
    consistent with the semantics of applying S2 only to the same Classifier
    and with the semantics of applying S1 and S2 to the same Classifier.

    3d) S2 specializes S1 and defines its own extensions(s) but does not
    specializes any of S1's extensions.

    For example, suppose S1 extends Classifier, then S1 has a property:
    S1::base_Classifier.
    Then, if S2 extends Classifier without specializing S1's extension, then
    there are two distinct properties: S1::base_Classifier and
    S2::base_Classifier
    This should be ill-formed; there should be an explicit specialization of
    the extension and redefinitions of both sides as in (3c).

  • Reported: UML 2.5b1 — Fri, 10 May 2013 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Clarification re MOF Equivalent Semantics about defining/applying a stereotype to a slot of ininstance of a stereotype

  • Key: UMLR-469
  • Legacy Issue Number: 18245
  • Status: open  
  • Source: NASA ( Nicolas Rouquette)
  • Summary:

    The UML 2.5 beta document explains the mapping of Profiles, Stereotypes,
    and Extensions in terms of the CMOF-equivelent semantics as follows:

    • A Profile maps to a CMOF Package
      Š
    • A Stereotype maps to a CMOF class with the same name and properties
      Š
    • An instance of a Stereotype (created when the Stereotype is applied to
      an Element) maps to an instance of the CMOF class representing the
      Stereotype.
      It is associated with the Element to which it applies using a Link which
      is an instance of the Association to which the Extension is mapped.

    According to the above, this means that

    1) when defining the stereotype Clock (Fig 12.22), the property
    Clock::OSVersion maps to a property of the CMOF class named Clock
    2) when applying the stereotype Clock (Fig 12.26 and 12.27) to an element
    (StopWatch on Fig 12.22), the underlying semantics has an instance of the
    CMOF class Clock with a slot corresponding to the property
    Clock::OSVersion (Fig 12.27)

    It should be possible to define a stereotype extending UML::Slot and apply
    such stereotype to a slot corresponding to a property of an instance of a
    stereotype, e.g., the slot OSVersion="3.32" of Fig 12.27.

    This is a subtle point about the current profile mechanism that should be
    made clear in the spec.
    I suggest adding an explanation about this in the "MOF Equivalent
    Semantics" sub-section of section 12.3.3 Profile Semantics.

  • Reported: UML 2.5b1 — Sat, 3 Nov 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

[UML 2.5] Redundancy in the definition of use case extensions

  • Key: UMLR-453
  • Legacy Issue Number: 18467
  • Status: open  
  • Source: Airbus Group ( Yves Bernard)
  • Summary:

    As pointed out by Pete in issue #7793, there is a redundancy between ExtensionPoint::useCase and Extend::extendedCase since the later can be derived from the use case owning the ExtensionPoint. It should be specified as such.

  • Reported: UML 2.5b1 — Thu, 21 Feb 2013 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Stereotype for extended bound element realization

  • Key: UMLR-467
  • Legacy Issue Number: 18270
  • Status: open  
  • Source: nMeta ( Ed Seidewitz)
  • Summary:

    Specification: OMG Unified Modeling Language (OMG UML), Version 2.5 FTF – Beta 1 (ptc/2012-10-24)

    Subclause: 7.3.3

    UML 2.5 allows the “expanded bound element” for a template bound element to be related to the bound element using a realization. Should there be a standard stereotype to be applied to a realization used in this way?

  • Reported: UML 2.5b1 — Tue, 20 Nov 2012 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Serilaization of required stereotypes

  • Key: UMLR-458
  • Legacy Issue Number: 18436
  • Status: open  
  • Source: Airbus Group ( Yves Bernard)
  • Summary:

    There are some specific cases where serialization of Extension instances resulting from the application of a stereotype does not provide any added value. However it creates a memory footprint overhead. These cases can be characterized by the conjunction of the following conditions:
    The stereotype is defined so that it is an required extension (i.e. its isRequired property is “true”)
    This stereotype does not have any property or all of its properties are derived (i.e. isDerived is “true”)

    As per the current specifications of UML and MOF2XMI, I cannot find anything that formally implies the serialization of extensions resulting from the application of such a stereotype but this reading appears to be controversial (cf. the attached mails exchange).

    Nevertheless, the standard way to add semantics in a profile relies on stereotypes definition only and there are some practical cases leading to defined stereotypes of the kind described above. For instance, within the SysML specification we defined a set of queries to retrieve elements involved in a specific kind of relationships (e.g. allocation), even if those elements do not themselves hold any information about it.

    Finally, those stereotypes are no more that a specification mechanism used to define a set of query applicable to a set of elements and the memory footprint overhead is not justified.

    Suggested resolution:
    To add a Boolean query (with maybe a corresponding derived property) to the Extension metaclass. This will return “true” when an extension shall be serialized. I propose to use the following OCL expression to specify this query:

    context Extension
    def: mustBeSerialized() : Boolean = self.isRequired=false or self.ownedEnd.type.attribute->select(isDerived)->notEmpty()

    To clarify that extensions that return “false” to the query above are aliases for their base classes in any context where the profile is applied. Therefore, any reference to an element typed by the corresponding stereotype shall actually be resolved (and then serialized) as a reference to the corresponding instance of the extended class.

  • Reported: UML 2.5b1 — Mon, 11 Feb 2013 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UseCases: Explanation of words “fragment” and “increment”

  • Key: UMLR-442
  • Legacy Issue Number: 18729
  • Status: open  
  • Source: Model Driven Solutions ( Steve Cook)
  • Summary:

    The semantics of UseCases uses the words “fragment” and “increment” without explaining what these words mean in terms of the metamodel

  • Reported: UML 2.5b1 — Thu, 23 May 2013 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Interactions and parameter assignments

  • Key: UMLR-462
  • Legacy Issue Number: 18412
  • Status: open  
  • Source: Fraunhofer FOKUS ( Marc-Florian Wendland)
  • Summary:

    is it intended to not let message arguments being assignable to attributes of the receiving lifeline?

    As an example: Lifeline A sends a synchronous operation call to Lifeline B for the operation op(in x:Integer). Assume that the Type Lifeline B represents owns a Property p:Integer. The received actual parameter x shall be assigned to Property p of the receiving lifeline.

    With the current semantics of Messages and its description for notation it is only possible to assign out/inout/return values to a receiving lifeline. Consider the case that a certain Lifeline receives a Signal (no out/inout/return parameter at all) and wants to store the value of an attribute of that Signal in an attribute (either of the surrounding Interaction or its context Classifier); this is not possible by default.

    In my realm (which is validation and testing mainly using UTP), this is quite normal. A system under test (SUT) responds with a Signal and some values of that signal need to be stored for later calculation or re-sending.

    Shall we allow this in Interactions?

  • Reported: UML 2.5b1 — Fri, 1 Feb 2013 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Semantics of Message argument mapping in Interactions

  • Key: UMLR-463
  • Legacy Issue Number: 18411
  • Status: open  
  • Source: Fraunhofer FOKUS ( Marc-Florian Wendland)
  • Summary:

    The spec is inconsistent regarding the correspondence of Message arguments and its in/inout parameter.

    In Section 17.4.3 it says: “The arguments of the Message correspond to the in and inout ownedParameters of the Operation, in the order of the ownedParameters.”

    This is also specified in the formal OCL constraint in Section 17.12, subsection Message, subsubsection Constraints

    However, in Section 17.4.4 it says: “A request-message-label may only have input-arguments with in-parameter-names if the Message has a signature. In this case, the input-arguments are matched by name to the in and inout ownedParameters of an Operation or the attributes of a Signal.”

    I assume that the OCL is correct and the Notation section would need clarification?!

  • Reported: UML 2.5b1 — Fri, 1 Feb 2013 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Timing Events Question / Issue

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

    A wait for an absolute time event is reached in an activity diagram, but when the event time is evaluated, the time is in the past.

    Does the timer receive that event and continue, or does it wait there forever, or is the behaviour not specified.

    The spec does not seem to be specific.

  • Reported: UML 2.5b1 — Mon, 27 May 2013 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Profile: can a stereotype extend fewer metaclasses than another stereotype it specializes?

  • Key: UMLR-470
  • Legacy Issue Number: 18247
  • Status: open  
  • Source: NASA ( Nicolas Rouquette)
  • Summary:

    The UML 2.5 beta document is unclear about the combination of stereotype extensions & generalization relationships.
    Suppose a stereotype S1 extends metaclasses MC1 and MC2.
    Suppose another stereotype S2 specializes S1 and is only applicable to MC1 but not to MC2.

    Should S2's extension of MC1 then redefine S1's extensions of MC1 and of MC2 or is this restriction capability beyond the scope of the UML profile mechanism?

  • Reported: UML 2.5b1 — Mon, 5 Nov 2012 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT


"Object identity" undefined

  • Key: UMLR-604
  • Legacy Issue Number: 17615
  • Status: open  
  • Source: Object Management Group ( Andrew Watson)
  • Summary:

    UML semantics depend on "object identity", an undefined concept

    The rearrangement of UML concepts in dependency order, to minimise forward references, is nicely done in this specification. It highlights how careful UML is about defining all the concepts it uses (with the exception of the primitive types in Section 21, which are explicitly imported into the language).

    However, the term "object identity" is explicitly or implicitly used in a few places in the specification, but never defined. Worse, its introduction leads to undefined semantics for part of the language.

    1. References to the undefined concept "object identity".

    1.1 p38 "That is, no two values in the collection may be equal, where equality of objects (instances of Classes) is based on object identity ..."

    1.2 p184 "A DataType is a kind of Classifier. DataType differs from Class in that instances of a DataType are identified only by their value. All instances of a DataType with the same value are considered to be equal instances."

    This is an implicit reference to Class instances being identified by something other than their value (presumably their "object identity"). However, we search in vain for the corresponding text in the section on the semantics of Class to tell us how Class instances are identified.

    1.3 p488 "A TestIdentityAction is an action that tests if the two values given on its InputPins are identical objects ...

    If an object is classified solely as an instance of one or more Classes, then testing whether it is the "same object" as another object is based on the identity of the object ..."

    2. Undefined semantics as a result

    2.1 p488 "The result of a TestIdentityAction for objects that are classified by both Classes and DataTypes, or by other kinds of Classifiers, is not defined, but, in all cases the Action produces a Boolean result."

    Conclusion
    ----------
    Either the specification should define "object identity" (although this would still leave TestIdentityAction undefined under some circumstances), or (preferably) this undefined, implementation-level concept should be replaced by a definition of equality grounded in the equality of Primitive Types (with equality on all other Types being recursively defined in terms of equality on Primitive types).

  • Reported: UML 2.5b1 — Wed, 19 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Notation for DurationObservation with two event elements

  • Key: UMLR-461
  • Legacy Issue Number: 18276
  • Status: open  
  • Source: nMeta ( Ed Seidewitz)
  • Summary:

    Specification: OMG Unified Modeling Language (OMG UML), Version 2.5 FTF – Beta 1 (ptc/2012-10-24)

    Subclause: 8.4.4

    In 8.4.4 it says that “An Observation may be denoted by a straight line attached to the NamedElement it references.” However, a DurationObservation may reference two NamedElements. It is not clear what the notation is for that.

  • Reported: UML 2.5b1 — Tue, 20 Nov 2012 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML: No restrictions on what seem to be meaningless associations

  • Key: UMLR-475
  • Legacy Issue Number: 18186
  • Status: open  
  • Source: Simula Research Laboratory ( Bran Selic)
  • Summary:

    It seems possible to draw associations between any two kinds of types, including seemingly absurd combinations of associations between, say, an Interface and a Collaboration.Should there be constraints that prevent such combinations? If not, then the semantics of such combinations should be clarified.

  • Reported: UML 2.5b1 — Fri, 19 Oct 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Inconsistent approach to type conformance

  • Key: UMLR-606
  • Legacy Issue Number: 17613
  • Status: open  
  • Source: Object Management Group ( Andrew Watson)
  • Summary:

    The specification makes inconsistent statements about checking that communication between objects takes place according to the parameters of the communication mechanisms used.

    1. In some places the specification says that UML does not attempt to define a type-safe conformance relationship:

    1.1 On p128, in Semantics of Operations, it says:

    "Different type-conformance systems adopt different schemes for how the types of parameters and results may vary when an Operation is redefined in a specialization. When the type may not vary, it is called invariance. When the parameter type may be specialized in a specialized type, it is called covariance. When the parameter type may be generalized in a specialized type, it is called contravariance. In UML, such rules for type conformance are intentionally not specified."

    1.2 On p308-309 it says:

    "A method of an Operation shall have Parameters corresponding to the Parameters of the Operation. ... The data values associated with a request - input Operation parameter values or Signal attribute values - are then passed to a method invoked due to the request via the method parameters. ...

    However, no one approach is defined for matching the Parameters of the method to the Parameters of the BehavioralFeature. Possible approaches include exact match (i.e., the type of the corresponding Parameters, order, must be the same), co-variant match (the type of a Parameter of the method may be a subtype of the type of the Parameter of the BehavioralFeature), contra-variant match (the type of a Parameter of the method may be a supertype of the type of the Parameter of the BehavioralFeature), or a combination thereof."

    2. On the other hand, in several places the specification does try to define rules for type conformance, with varying levels of success:

    2.1 On p158 isConsistentWith is defined on operations, apparently in an attempt to test whether a operation can be redefined in a type-safe way. While the isConsistentWith semantics are broken on at least two counts (see separate issue report), this is an attempt to define a rule for type conformance on operations (albeit with a different name).

    2.2 p187: "By declaring a Reception associated to a given Signal, a Classifier specifies that its instances will be able to receive that Signal, or a subtype thereof, and will respond to it with the designated Behavior." i.e. Signals must be passed in a type-conformant way.

    2.3 p252: "A Port may be redefined when its containing EncapsulatedClassifier is specialized. The redefining Port may have additional Interfaces to those that are associated with the redefined Port or it may replace an Interface by one of its subtypes." Again, this is type conformance on Ports. There's similar language for redefining Connectors in a type-conformant way on p248.

    2.4 p424: "If the ObjectNode is untyped then the Parameters shall also be untyped. Otherwise, the input Parameter shall have either the same type as or a supertype of the ObjectNode, while the output Parameter shall have either the same type or a subtype of the ObjectNode." Again, this is type-conformant.

    Conclusion - there are several places where UML does intentionally define rules for type conformance. For consistency, either these type conformance rules should be removed or (preferably), the unhelpful statements (1.1 & 1.2 above) that UML does not enforce type conformance should be removed, and replaced by appropriate definitions of type conformance on Operations (perhaps based on a debugged version of isConsistentWith).

  • Reported: UML 2.5b1 — Wed, 19 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

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

Consistent use of "conforms to" vs. "is a subtype of"

  • Key: UMLR-605
  • Legacy Issue Number: 17611
  • Status: open  
  • Source: Object Management Group ( Andrew Watson)
  • Summary:

    "The query conformsTo() gives true for a Type that conforms to another."

    While the OCL throughout the text does indeed use the conformsTo() operation, the textual descriptions alongside the OCL mix references to "conformance" with references to "one Type being a subtype of another".

    For clarity, I suggest that either all these uses of "subtype" in the text are replaced by references to "conforms to" or (less preferable), some text is included in this description on p65 to say that "subtype" is a synonym for "conforms to".

    It might also be useful to include some words about type conformance in the very-short description of the Semantics of Types in section 7.5.3 (p37).

  • Reported: UML 2.5b1 — Wed, 19 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

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

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