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

UML 2.6 RTF — Open Issues

  • Key: UMLR
  • Issues Count: 743
Open Closed All
Issues not resolved

Issues Summary

Key Issue Reported Fixed Disposition Status
UMLR-767 Error in Loop fragment deffinition UML 2.5.1 open
UMLR-766 Duplicate section titles UML 2.5.1 open
UMLR-759 UML Specification "Normative References" uses non-secure links UML 2.5 open
UMLR-761 Property.Association is not a union UML 2.5.1 open
UMLR-765 Comments not annotating anything should annotate their owner UML 2.5 open
UMLR-89 No way of specifying element documentation UML 2.5 open
UMLR-764 Specializations of an Association Class UML 2.5.1 open
UMLR-219 UML has no way of distinguishing Notes from Comments UML 2.5 open
UMLR-185 Association class notation with just class or association UML 2.1.2 open
UMLR-763 Clarify that AcceptEventActions in InterruptibleActivityRegions are disabled when token leaves UML 2.5 open
UMLR-750 Description of Generalization of Enumerations is contradictory UML 2.5 open
UMLR-758 Duplicated xmi:id values in UML.xmi UML 2.5.1 open
UMLR-757 Make AssociationClasses unique again UML 2.5 open
UMLR-756 Behavior::behavioredClassifier bodycondition is serialized as a precondition UML 2.5.1 open
UMLR-755 Unclear whether current State during Transition is the target State UML 2.5.1 open
UMLR-754 Figure 9.11 misses attribute name UML 2.5.1 open
UMLR-753 I believe ptc/08-05-12 and ptc/08-05-06 got mixed up on the UML 2.2 specification page UML 2.2 open
UMLR-751 The definition of relative Time Events is ambigious UML 2.5.1 open
UMLR-292 About behavior ports UML 2.5 open
UMLR-54 Operation calls on behavior ports UML 2.0 open
UMLR-107 Behavioral port UML 2.5 open
UMLR-749 Are null NamedElement::name values names? UML 2.5 open
UMLR-747 Typo UML 2.5.1 open
UMLR-746 Figure 7.17 has some trucated labels UML 2.5 open
UMLR-745 Typo in last syntax example UML 2.5 open
UMLR-744 Attachment point of connectors not specified UML 2.5 open
UMLR-743 Implied Multiplicity of the association-like notation should be displayable UML 2.5 open
UMLR-742 Lifeline "same_classifier" constraint has an inconsistent specification UML 2.5 open
UMLR-741 Are two identical bound templates the same? UML 2.5 open
UMLR-738 Incorrect use of multiplicity element. UML 2.5 open
UMLR-620 Complete and Covering are Synonyms and used confusinginly UML 2.5 open
UMLR-730 Does the abort of an Do/Activity by an incoming event count as a Completion Event UML 2.5 open
UMLR-542 Figure 12-15 (MOF Model Equivalent …) p.284 - MOF Model Equivalent navigation and ownership incorrect UML 2.4.1 open
UMLR-234 UML Interactions: Misleading suggestion of relationship between Interactions and Activities modeling UML 2.5 open
UMLR-582 What is a DurationInterval UML 2.4.1 open
UMLR-584 What is a DurationInterval UML 2.4.1 open
UMLR-438 Observations in TimeExpressions UML 2.5b1 open
UMLR-450 UML 2.5: Time Observation and Duration Observation problem UML 2.5b1 open
UMLR-740 DecisionNode is missing a constraint on incoming edges UML 2.5 open
UMLR-437 What is the abstract syntax for Figure 17.27? UML 2.5b1 open
UMLR-433 What is a UML diagram? is it restricted to showing elements that are instances of the M2 UML metamodel and nothing else? UML 2.5b1 open
UMLR-306 How to access a token value in a guard? UML 2.5 open
UMLR-428 Guard evaluation with decision input UML 2.5b1 open
UMLR-711 Conflicting constraints UML 2.5 open
UMLR-471 Allow a notation to allow for a default assignment of a decision to the owner of the activity UML 2.5b1 open
UMLR-528 Location: Figure 15-43 ActivityFinalNode example - Balancing Decision / Merge UML 2.4.1 open
UMLR-530 Location: Page 413, 15.3.2 Abstract Syntax Control Nodes Figure 15-26 UML 2.4.1 open
UMLR-243 Restrictions on decision nodes UML 2.5 open
UMLR-668 Unspecified and inconsistent notation for Observations UML 2.5 open
UMLR-737 ReturnValueRecipient missing in Metamodel Diagram of InteractionUse UML 2.5 open
UMLR-736 Figure 17.20 "InteractionUse with value return" shows incorrect notation UML 2.5 open
UMLR-735 Undefined notation for ownedBehaviors in Figures 17.23 and 17.24 UML 2.5 open
UMLR-734 Instances are linked to other instances, not associated UML 2.5 open
UMLR-732 Odd restriction on state machine redefinition context UML 2.5 open
UMLR-729 Clarify diagram notation for collection parameters in operation UML 2.5 open
UMLR-728 Transistion selection algorithm is incomplete UML 2.5 open
UMLR-727 UML: Missing property subset for StateMachine::extendedStateMachine UML 2.5 open
UMLR-725 Nested activities in activity diagrams UML 2.5 open
UMLR-726 Template binding relationship incorrect notation UML 2.5 open
UMLR-724 bad example for weight in Figure 15.21 UML 2.5 open
UMLR-404 ActivityEdge weight examples UML 2.5 open
UMLR-723 Implication of weight of ActivityEdge is unclear UML 2.5 open
UMLR-722 Conjugated port properties shown on association ends and in compartments UML 2.5 open
UMLR-721 Actor Relationships UML 2.5 open
UMLR-720 Incorrect arrow heads for object flows UML 2.5 open
UMLR-718 Ambiguous meaning of word "composed" UML 2.5 open
UMLR-119 Section: Annex A: Diagrams UML 2.1.1 open
UMLR-681 ClassB::height missing from diagram UML 2.5 open
UMLR-680 Missing interface name in Figure 10.10 ISensor is a required Interface of TheftAlarm UML 2.5 open
UMLR-691 Section 14.2.4.4 is not a real section UML 2.5 open
UMLR-677 Why is Association.memberEnd ordered? UML 2.5b1 open
UMLR-684 Figure 11.23 (and 11.22) should use one brand of tire but show two instead UML 2.5 open
UMLR-690 Transition guards should be its own section. UML 2.5 open
UMLR-685 UML 2.5: StateMachine Vertex needs to be made a kind of RedefinableElement instead of State UML 2.5 open
UMLR-697 UML 2.5: StateMachine Vertex needs to be made a kind of UML 2.5 open
UMLR-702 Clarify that deep history uses the same default transition strategy as shallow history UML 2.5 open
UMLR-704 Figure 14.44 ProtocolStateMachine example error UML 2.5 open
UMLR-354 State machine semantics for transition between regions of an orthogonal state UML 2.4.1 open
UMLR-717 Invalid XMI elements containing both xmi:type and href UML 2.5 open
UMLR-710 Missing visibility definition UML 2.5 open
UMLR-716 What is a "compound state"? UML 2.5 open
UMLR-715 All actions should be able to own control pins UML 2.5 open
UMLR-714 Missing Constraint: Associations cannot type StructuralFeatures UML 2.5 open
UMLR-348 Actor association constraint makes UseCase subclass of Class UML 2.5 open
UMLR-713 On page 290 of UML 2.5 formal/2015-03-01, UML 2.5 open
UMLR-712 New Issue on UML 2.5 formal/2015-03-01 re signalbroadcastaction vs. broadcastsignalaction UML 2.5 open
UMLR-696 The behavior of an OpaqueExpression should be allowed to have input parameters UML 2.5 open
UMLR-92 UML/OCL spec mismatch-Constraint.context vs Constraint.constrainedElement UML 2.5 open
UMLR-706 What is "a separate InteractionConstraint"? UML 2.5 open
UMLR-703 XOR Constraint modeling UML 2.5 open
UMLR-705 Meaning of Event on Initial Transition unclear UML 2.5 open
UMLR-701 Inconsistent constraints about several kinds of UML Diagrams UML 2.5 open
UMLR-698 OpaqueExpression should own Behavior UML 2.5 open
UMLR-627 Semantics of Lifeline.selector not clear UML 2.5 open
UMLR-640 Notation is depreciated for inherited interface UML 2.5 open
UMLR-692 Comment is misleading UML 2.5 open
UMLR-689 Mixed plural/singular UML 2.5 open
UMLR-688 Plural vs Singulr? UML 2.5 open
UMLR-687 Unclear sentence UML 2.5 open
UMLR-686 Missing words in sentence UML 2.5 open
UMLR-68 reply messages in interactions UML 2.5 open
UMLR-101 Subclasses of InstanceSpecification UML 2.5 open
UMLR-112 ValueSpecification that refers to some Element shall be defined UML 2.5 open
UMLR-113 Ability to define "context specific" default values for Part UML 2.5 open
UMLR-431 problems with BehavioralFeature::method UML 2.5b1 open
UMLR-488 Interaction parameters. UML 2.4.1 open
UMLR-489 How should context be represented? UML 2.4.1 open
UMLR-683 Order of example information should be diagram first, then explanation. UML 2.5 open
UMLR-682 Link to "see" sections missing UML 2.5 open
UMLR-679 AssociationEnd/Attribute redefintion consistency UML 2.5 open
UMLR-678 Why is a qualified association qualifier composed by a Property? UML 2.5 open
UMLR-355 UML should support proxies for linking models UML 2.5 open
UMLR-676 No UML approach to create an infix operator UML 2.5 open
UMLR-674 Parameter types required for operation parameters UML 2.5 open
UMLR-329 TypeElement / TypedElement typo UML 2.5 open
UMLR-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-35 Disjointness should be independent of generalization UML 2.0 open
UMLR-41 section 7.3.17 /EnumerationLiteral should not be an InstanceSpecification UML 2.5 open
UMLR-665 Impossiblity to specify links for connected roles. UML 2.5 open
UMLR-664 Delegation Connector should not be typed UML 2.5 open
UMLR-663 Decide whether the document divisions are "sub clauses" or "subclauses" UML 2.5 open
UMLR-662 What are the type/classifiers of an InstanceValue UML 2.5 open
UMLR-660 Unexpected trigger reception has contradictory results in Protocol State Machines UML 2.5 open
UMLR-661 What does calling an "operation for a state" mean in PSM. UML 2.5 open
UMLR-658 No notation for associations defined for abstract classes UML 2.5 open
UMLR-202 UML:Notational option to display inherited features in a subclass UML 2.5 open
UMLR-657 Deploying a «deployment spec» has no explicit interpretation UML 2.5 open
UMLR-656 Shoppin->Shopping UML 2.5 open
UMLR-655 UML 2.5 refers to EBNF, but the spec uses a variant BNF, not EBNF UML 2.5 open
UMLR-384 Classifiers can contain Packages, but they can't have appropriate visibility UML 2.5 open
UMLR-654 Pin rectangles in examples should not overlap the action border UML 2.5 open
UMLR-653 Activity Generalization is underspecified UML 2.5 open
UMLR-315 Rename Specialization/Generalization between abstract classes UML 2.5 open
UMLR-449 Contradiction between the abstract syntax and semantics of an Interval UML 2.5b1 open
UMLR-652 In Sequence diagrams, the duration constraint shown as a vertical two-headed is ambiguous UML 2.5 open
UMLR-651 In the time-related syntax for Sequence diagrams, there are used two terms (now, duration). Are there more? Are these defined? UML 2.5 open
UMLR-650 It doesn't seem possible to use a time-based trigger in the alternate format transition-focused state machine. UML 2.5 open
UMLR-649 Use of decomposition indicator UML 2.5 open
UMLR-648 InstanceSpecification for a qualified Property UML 2.5 open
UMLR-646 Recursive use of Interaction Use UML 2.5 open
UMLR-647 Limitation on isDimension Partition to be uncontained appears unwarranted UML 2.5 open
UMLR-645 Classifier.allSlottableFeatures shall incorporate redefinition UML 2.5 open
UMLR-643 Location of owning fully qualifed name not specified. UML 2.5 open
UMLR-642 Clarify the difference between «create» and «instantiate» UML 2.5 open
UMLR-641 Missing parameter properties of stream and exception in BNF UML 2.5 open
UMLR-637 What is the order for EnumerationLiterals? UML 2.5 open
UMLR-639 Wrong expression for dipicting package merge process? UML 2.5 open
UMLR-638 Inconsistency in constraints and rules for property merge UML 2.5 open
UMLR-636 How to deal with guard in Transition redefinition? UML 2.5 open
UMLR-635 Typing error in figure 9.11 UML 2.5 open
UMLR-634 Wrong figure referrence in text UML 2.5 open
UMLR-633 Computation error for the example of ReduceAction UML 2.5 open
UMLR-631 UML 2: Lifeline should be made a TemplateableElement UML 2.5 open
UMLR-630 Semantics of UnlimitedNatural in notation section. UML 2.5 open
UMLR-629 Matching between '+-#~' in Property's and "public-private-protected-package" is not described UML 2.5 open
UMLR-628 Constraint wording implies aggregation is only for associations UML 2.5 open
UMLR-626 Need to constrain where triggers can be put in state machines UML 2.5 open
UMLR-625 Missing: how +-#~ symbols map to VisibilityKind UML 2.5 open
UMLR-624 Example for association-like notation for attribute contradicts description. UML 2.5 open
UMLR-623 In OCL, the use of ::_'in' appears unwarranted UML 2.5 open
UMLR-622 Define well-formed/ill-formed UML 2.5 open
UMLR-621 Clarify Property Qualifiers with a full Example UML 2.5 open
UMLR-619 Class.isAbstract attribute is not necessary UML 2.5 open
UMLR-429 Missing glossary UML 2.5b1 open
UMLR-420 Multiplicity of opposite end of a number of associations from various action metaclasses UML 2.5 open
UMLR-618 isDirectlyInstantiated is defined in reverse UML 2.5 open
UMLR-427 7.2.3, last sentence 2nd paragraph the revised text UML 2.5b1 open
UMLR-328 NamedElement::allNamespaces is invalid at model root UML 2.5 open
UMLR-351 Section 15.5.3: a missed word UML 2.5 open
UMLR-617 Location: 18.1.5 Examples Figure 18-2. 689 - Explain about Navigation UML 2.4.1 open
UMLR-616 UML 2.5: UML redefinition mechanism insufficiently granular UML 2.5 open
UMLR-454 UML 2.5 - figures 14.37 and 14.38 use incorrect notation for keyword UML 2.5b1 open
UMLR-457 UML2.5 issue: constraints needed in model of Standard Profile UML 2.5b1 open
UMLR-458 Serilaization of required stereotypes UML 2.5b1 open
UMLR-459 Reply messages now mandatory? UML 2.5b1 open
UMLR-462 Interactions and parameter assignments UML 2.5b1 open
UMLR-463 Semantics of Message argument mapping in Interactions UML 2.5b1 open
UMLR-460 UML2.5: Clarification about UML profiles UML 2.5b1 open
UMLR-466 Semantics of TimeConstraints and DurationConstraints UML 2.5b1 open
UMLR-461 Notation for DurationObservation with two event elements UML 2.5b1 open
UMLR-448 Clarification about Interactions owning Actions and about the semantics of Actions owned by Interactions UML 2.5b1 open
UMLR-451 Issue for Figure 17.18 UML 2.5b1 open
UMLR-455 Notation for Variables and Variable Actions is very vague and incomplete UML 2.5b1 open
UMLR-452 Rg. Realization and InterfaceRealization UML 2.5b1 open
UMLR-453 [UML 2.5] Redundancy in the definition of use case extensions UML 2.5b1 open
UMLR-456 Issue with Reply message in interactions (UML 2.5 Beta) UML 2.5b1 open
UMLR-439 Timing Events Question / Issue UML 2.5b1 open
UMLR-441 The notation for ExtensionPoint provides for an “explanation”, but the metamodel provides nowhere to store it. UML 2.5b1 open
UMLR-440 UseCases: no way for an Extend to pick out individual ownedBehaviors of the extending UseCase UML 2.5b1 open
UMLR-442 UseCases: Explanation of words “fragment” and “increment” UML 2.5b1 open
UMLR-445 Behavior does not override NamedElement::isDistinguishableFrom() like BehavioralFeature does UML 2.5b1 open
UMLR-443 UML 2.5 issue. AssociationClasses should have isUnique property UML 2.5b1 open
UMLR-444 Clarification needed about the semantics of stereotype specialization and stereotype application UML 2.5b1 open
UMLR-447 Incorrect notation in figure 14.37 UML 2.5b1 open
UMLR-446 Shouldn't Gate and InteractionFragment be redefinable to support Interaction specialization? UML 2.5b1 open
UMLR-465 Meaning of access to constrainedElements UML 2.5b1 open
UMLR-464 Semantics of Namespaces UML 2.5b1 open
UMLR-467 Stereotype for extended bound element realization UML 2.5b1 open
UMLR-468 Please provide running footers or headers indicating the section/subsection of a page UML 2.5b1 open
UMLR-470 Profile: can a stereotype extend fewer metaclasses than another stereotype it specializes? UML 2.5b1 open
UMLR-469 Clarification re MOF Equivalent Semantics about defining/applying a stereotype to a slot of ininstance of a stereotype UML 2.5b1 open
UMLR-472 Need packages overview diagram and explicit depiction of package dependencies UML 2.5b1 open
UMLR-477 Meaning of State in ProtocolStateMachines UML 2.4.1 open
UMLR-478 Figure 14.39 – missing superclass UML 2.4.1 open
UMLR-480 Can passive classes have ClassifierBehaviors? UML 2.4.1 open
UMLR-479 Should “completion” event be an explicit event type? UML 2.4.1 open
UMLR-481 Not clear if “else” keyword is defined for State Machines UML 2.4.1 open
UMLR-486 Problems with XMI IDs in the UML 2.5 UML.xmi file UML 2.4.1 open
UMLR-487 17 Semantics of interactions UML 2.4.1 open
UMLR-482 State of the substates of the history state UML 2.4.1 open
UMLR-483 Overriding deferred events UML 2.4.1 open
UMLR-485 Default entry if default history transition missing UML 2.4.1 open
UMLR-484 Stable state not needed UML 2.4.1 open
UMLR-475 UML: No restrictions on what seem to be meaningless associations UML 2.5b1 open
UMLR-473 It is a pity that UML does not provide the ability for Messages to correspond directly to property accesses and updates UML 2.4.1 open
UMLR-474 Meaning of absent multiplicity notation UML 2.4.1 open
UMLR-476 Node::nestedNode should subset Class::nestedClassifier, not Namespace::ownedMember. UML 2.4.1 open
UMLR-490 UML Interactions do not provide the ability for Messages to correspond directly to property accesses and updates UML 2.4.1 open
UMLR-491 Location: Annex C Keywords P. 778 - Inconsistent metaclass keywords UML 2.4.1 open
UMLR-434 PrimitiveTypes::Real is inconsistently specified relative to its mapping to xsd:double UML 2.5b1 open
UMLR-436 No explanation of how to deal with conflicting transitions of equal priority UML 2.5b1 open
UMLR-435 Definition of allOwningPackages() UML 2.5b1 open
UMLR-425 typo in 12.2.3 Model UML 2.5b1 open
UMLR-426 Uml2.5 issue - constraints of Behavior incorrectly assume context is always non-null UML 2.5b1 open
UMLR-432 Add condition : Constraint[0..1] to the include relationship UML 2.4.1 open
UMLR-430 Several UMLDI redefining associations are invalid UML 2.5b1 open
UMLR-500 Location: 18.1.1 Summary p 685 - Bases of specialized stereotypes UML 2.4.1 open
UMLR-502 Location: 18.1.4 Notation P. 688 - Can Use Cases have attributes and operations? UML 2.4.1 open
UMLR-503 Location: 18.2 Classifier Descriptions Use Case Constraints. 697 - Need stricter limit on associations (02) UML 2.1.2 open
UMLR-505 Location: 18.2 Classifier Descriptions Use Case Constraints. 697 - Need stricter limit on associations UML 2.1.2 open
UMLR-504 Location: 18.2 Classifier Descriptions Extend Constraints. 695 - Constraint is overly restrictive UML 2.4.1 open
UMLR-506 Location: 18.2 Classifier Descriptions Extend Constraints. 695 - Extensions must be a DAG UML 2.4.1 open
UMLR-507 18.1.3 Semantics Use Case and Actors Extends P. 687 - Single Location UML 2.4.1 open
UMLR-508 18.1.3 Semantics Use Case and Actors Extends P. 687 - No Alternative Path UML 2.4.1 open
UMLR-496 Location: Figure A.5 P. 734 - Use Cases are not behavior diagrams UML 2.4.1 open
UMLR-497 Location: Appendix A, list of frame names, p 734 - List of Namespaces suitable for diagram headers is overly restrictive UML 2.4.1 open
UMLR-498 Location: 22.3 Standard Stereotypes «Metamodel» p. 731 - «Subsystem» should be allowed for more classifiers UML 2.4.1 open
UMLR-493 Location: B.6 UML ProfileDiagrams . 768 - Profile Diagram Elements UML 2.4.1 open
UMLR-492 Location: B.6 UMLClass Diagram P. 757 - Class namespace diagrams? UML 2.4.1 open
UMLR-494 Location: B.2.2 P. 738 - What ISO document UML 2.4.1 open
UMLR-495 Location: Figure B.3. 737 - A diagram is a PackageableElement UML 2.4.1 open
UMLR-511 Location: 18.1.3 Semantics Use Cases and Actors P. 686 - Multiplicity at Use Case end UML 2.4.1 open
UMLR-512 Location: 18.1.3 Semantics Use Cases and Actors P. 686 - Multiple subjects require the same actors UML 2.4.1 open
UMLR-509 18.1.3 Semantics Use Case and Actors Extends P. 687 - First ExtensionPoint UML 2.4.1 open
UMLR-510 18.1.3 Semantics Use Case and Actors Extends P. 687 - Show name of extension UML 2.4.1 open
UMLR-499 Location: 19.5 Node Association Ends Node P. 714 - Shared ownership of nodes UML 2.4.1 open
UMLR-501 Location: 19.5 Classifier Descriptions Deployment Specification Attributes P. 711 - Why a multiplicity of [0..1] UML 2.4.1 open
UMLR-513 Location: 18.1.3 Semantics Use Cases and Actors P. 686 - What classifiers can be a subject? UML 2.4.1 open
UMLR-516 Location: 18. Global - No discussion of use case instances UML 2.4.1 open
UMLR-543 Location: Page 286, 12.3.3 Semantics - Nonsensical alternative to stereotype name UML 2.4.1 open
UMLR-545 Location: Page 286, 12.3.3 Semantics - Incorrect if statement UML 2.4.1 open
UMLR-544 Location: Page 285, 12.3.3 Semantics - Old behavior unnecessarily preserved UML 2.4.1 open
UMLR-546 Location: Page 281, 12.3.3 Semantics - Duplicated text UML 2.4.1 open
UMLR-540 Location: Opaque and Function Behaviors p 308 UML 2.4.1 open
UMLR-541 Location: Figure 12-13 p.281 - Incorrect use of << for «. UML 2.4.1 open
UMLR-553 Location: Page 267, 12.2.3 Semantics - Type and TypedElement confusion UML 2.4.1 open
UMLR-554 Page 266, 12.2.3 Semantics - Un-matched resulting elements aren't always the same UML 2.4.1 open
UMLR-556 Location: Page 265, 12.2.3 Semantics PackageMerge - Long-winded package merge description UML 2.4.1 open
UMLR-547 Location: Page 280, 12.3.3 Semantics - Poorly indented XMI UML 2.4.1 open
UMLR-548 Location: Page 280, 12.3.3 Semantics - Note should be main text UML 2.4.1 open
UMLR-549 Location: Page 270/271, 12.2.3 Semantics - Model description confusing UML 2.4.1 open
UMLR-558 Location: 12.1 Packages Summary p 264 UML 2.4.1 open
UMLR-559 Location: Figure 11-5 (ii) p 204 UML 2.4.1 open
UMLR-560 Location: Constraints p 193 - All feturs must be public? UML 2.4.1 open
UMLR-563 p 118: isException and other outputs UML 2.4.1 open
UMLR-564 Location p 162 ParameterSet associationends: Exceptions and parametersets UML 2.4.1 open
UMLR-550 Location: Page 269, 12.2.3 Semantics - Association merge aggregation constraint is property rule UML 2.4.1 open
UMLR-551 Location: Page 269, 12.2.3 Semantics - Property merge rule pointless UML 2.4.1 open
UMLR-552 Page 269, 12.2.3 Semantics - Property merge transformation conflicts with constrain UML 2.4.1 open
UMLR-557 Location: Page 265, 12.2.3 Semantics - Unchanged URIs UML 2.4.1 open
UMLR-555 Location: 12.2.3 Semantics Package p 265 - Reference to unknown section heading UML 2.4.1 open
UMLR-561 Location: constraints class_behavior p.190 UML 2.4.1 open
UMLR-562 Location 10.3.3 Receptions p.186 - exceptions for receptions? UML 2.4.1 open
UMLR-604 "Object identity" undefined UML 2.5b1 open
UMLR-606 Inconsistent approach to type conformance UML 2.5b1 open
UMLR-605 Consistent use of "conforms to" vs. "is a subtype of" UML 2.5b1 open
UMLR-595 Definition of invariant condition UML 2.4.1 open
UMLR-597 Section Unbalanced UML 2.4.1 open
UMLR-600 List attributes whose ordered property has change in UML 2.5 UML 2.4.1 open
UMLR-591 Semantics Clarification UML 2.4.1 open
UMLR-592 Need table correlating Literals with symbols (+,-,#,~) UML 2.4.1 open
UMLR-593 Inconsistent use of (s) UML 2.4.1 open
UMLR-603 Section 11.3.4 isService clarification - Clause 11: Structured Classifiers UML 2.4.1 open
UMLR-602 Section 11.2.4 clarification - Clause 11: Structured Classifiers UML 2.4.1 open
UMLR-608 Issue for UML 2.5 FTF against Clause 9: Classifiers UML 2.4.1 open
UMLR-594 Template Notation example UML 2.4.1 open
UMLR-598 Bound Element Semantics overly specific UML 2.4.1 open
UMLR-596 Descendants rather than specializations UML 2.4.1 open
UMLR-587 Event UML 2.4.1 open
UMLR-590 Expression examples unclear UML 2.4.1 open
UMLR-588 OCL not indexed UML 2.4.1 open
UMLR-589 Orphan Title UML 2.4.1 open
UMLR-599 UML 2.5 FTF issues for Clause 18: UseCases UML 2.4.1 open
UMLR-601 Section 11.7 has no content or notation for template Collaborations Clause - 11: Structured Classifiers UML 2.4.1 open
UMLR-613 Capitalization of dependency UML 2.4.1 open
UMLR-614 isIntegral() UML 2.4.1 open
UMLR-615 Clarification on the semantics of CommunicationPath UML 2.4.1 open
UMLR-524 Not clear when to use ExecutionOccurrenceSpecification with ExecutionSpecification UML 2.4.1 open
UMLR-525 Interactions p 607 UML 2.4.1 open
UMLR-526 Location: p 504 - Marshall Actions UML 2.4.1 open
UMLR-514 Location:Page #640, 17.8.2 Example Sequence Diagram UML 2.4.1 open
UMLR-515 Location: weak sequencing p. 622 UML 2.4.1 open
UMLR-517 Not clear when to use ExecutionOccurrenceSpecification with ExecutionSpecification UML 2.4.1 open
UMLR-520 Location: Pg. 613, Figure 17.6 - Incorrect multiplicities in the metamodel in Figure 17.6 UML 2.4.1 open
UMLR-521 Location: Pg. 613, Figure 17.6 - : Incorrect multiplicities in the metamodel in Figure 17.6 UML 2.4.1 open
UMLR-522 Location: p 611 UML 2.4.1 open
UMLR-533 Location: p. 336 Compound transitions - Run-to-completion Paradigm UML 2.4.1 open
UMLR-536 Location: Signal Receipt symbol UML 2.4.1 open
UMLR-534 Location: Page 346, State List Notations - Why must state lists be effect free? UML 2.4.1 open
UMLR-535 Location: Page 331 deep history entry - Default deep history entry UML 2.4.1 open
UMLR-518 Location: Pg. 617, Figure 17.4.4: Notation, Sub-clause: Message UML 2.4.1 open
UMLR-519 Location: 17.3.4 Notation Lifeline p 613 - Specification of color UML 2.4.1 open
UMLR-537 Location: Page 328, 14.2.3 - UseCase cannot be the context of a StateMachine UML 2.4.1 open
UMLR-539 Location: Page 316 redefinedBehavior - Extends UML 2.4.1 open
UMLR-538 Location: 13.3.5 Examples p 314 UML 2.4.1 open
UMLR-532 Location p413 Final Node - Atomic behavior UML 2.4.1 open
UMLR-531 Location: p 410 UML 2.4.1 open
UMLR-529 Location p413 Final Node - Rollback behavior UML 2.4.1 open
UMLR-523 Location: 16.2.3 Semantics / Opaque Actions UML 2.4.1 open
UMLR-527 Location: Figure 15.67 page 436 UML 2.4.1 open
UMLR-585 What is a DurationConstaint UML 2.4.1 open
UMLR-586 Time constant UML 2.4.1 open
UMLR-565 Query of alternative scopes? UML 2.4.1 open
UMLR-568 Reword isComputable UML 2.4.1 open
UMLR-569 Location: 8.6 p 98 TimeObservation ...simplify UML 2.4.1 open
UMLR-578 Range Confusion UML 2.4.1 open
UMLR-579 More detail on Express UML 2.4.1 open
UMLR-581 incompatible multiplicities UML 2.4.1 open
UMLR-572 What incompatible about sub-expressions and operands UML 2.4.1 open
UMLR-573 Why can’t the operand be a stringExpression UML 2.4.1 open
UMLR-576 Too many alls UML 2.4.1 open
UMLR-583 one -- > first UML 2.4.1 open
UMLR-577 Bad Description, observation has no value UML 2.4.1 open
UMLR-580 Like to overridden definition UML 2.4.1 open
UMLR-566 Location: 9.6.4 Notation p 127 Missing Infix operation syntax / discussion UML 2.4.1 open
UMLR-567 ParameterSet Notation UML 2.4.1 open
UMLR-570 Simplify (Location: 8.6 p 97 TimeExpression) UML 2.4.1 open
UMLR-571 Simplify UML 2.4.1 open
UMLR-575 Intended to Produce UML 2.4.1 open
UMLR-574 Bad Description UML 2.4.1 open
UMLR-347 UML 2.5 Beta 2 XMI invalid UML 2.5 open
UMLR-610 How to model a transition to history pseudostates in two orthogonal regions? UML 2.4.1 open
UMLR-612 Clarification on the semantics of inheritance between use cases UML 2.4.1 open
UMLR-607 Clarify aliasing in Namespaces UML 2.5b1 open
UMLR-609 Clarify ownership vs. membership for NamedElements UML 2.5b1 open
UMLR-611 Fuzzy diagrams UML 2.5b1 open
UMLR-383 History pseudo states in protocol state machines 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-381 Message lines can cross without the first being asynchronous 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-379 Need clarification between exceptionType and the type of the exceptionInput UML 2.5 open
UMLR-378 Does not seem possible to have an exception cause an interrupt (leave the region) UML 2.5 open
UMLR-377 What exception type is "any" exceptionType UML 2.5 open
UMLR-376 Coloring and shading on Figure 17.10 should be removed UML 2.5 open
UMLR-375 Caption for Table 17.5 on wrong page UML 2.5 open
UMLR-373 Vertical lines do not always describe the time-line for an interaction diagram UML 2.5 open
UMLR-372 use of ! instead of + or ∪ UML 2.5 open
UMLR-371 Extraneous " (double quote) in 17.5.4 BehaviorExecutionSpecification UML 2.5 open
UMLR-370 Message wildcards appear to ignore operation default values UML 2.5 open
UMLR-369 Tables 17.1, 17.3, 17.5, 17.6 Header Formats UML 2.5 open
UMLR-368 Mismatch of singular/plural Activity Goups are a grouping constructs UML 2.5 open
UMLR-367 Spelling error in ActivityGoups UML 2.5 open
UMLR-365 Use Cases both can and cannot have BehavioralFeatures UML 2.5 open
UMLR-364 As Events are Packageable Elements, how is their Package known? UML 2.5 open
UMLR-363 Semantics of Executable Nodes does not cover Control Flows on Control Pins UML 2.5 open
UMLR-362 A type defines a set member (not a set) UML 2.5 open
UMLR-361 Inconsistent use of Oxford comma in "Behavior, Event, and Trigger" UML 2.5 open
UMLR-360 Minor error in ptc-13-09-05 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-357 SignalBroadcastAction used where BroadcastSignalAction should be. UML 2.5 open
UMLR-356 Spelling error: i-->is UML 2.5 open
UMLR-353 2 Conformance: Missing Oxford comma in Item #2. UML 2.5 open
UMLR-396 Caption for Table 9.1 on wrong page UML 2.5 open
UMLR-395 Making the default for Generalization isDisjoint=False is contrary to modelers' expectations. UML 2.5 open
UMLR-394 How is an attribute that is not a part, a role? UML 2.5 open
UMLR-393 Lack of clarify of attribute vs attribute value. UML 2.5 open
UMLR-392 Generalizations should allow enumeration types as PowerTypes. UML 2.5 open
UMLR-391 Use of Qualifier and Qualified in same section of UML 2.5 spec should be more clearly disambiguated UML 2.5 open
UMLR-390 Continuation examples are missing InteractionConstraints for the Alternative CombinedFragment UML 2.5 open
UMLR-389 Extraneous " (double quote) in 17.6.3 Semantics UML 2.5 open
UMLR-388 As no UML operators are defined, it is not possible to write a UML Expression UML 2.5 open
UMLR-387 shoes-->shows UML 2.5 open
UMLR-386 UML needs standardized default package (or Model) UML 2.5 open
UMLR-385 Two classes can share attributes by use of element import UML 2.5 open
UMLR-400 Missing constraints preventing contradictory GeneralizationSets. UML 2.5 open
UMLR-399 What is the default setting for disjoint/overlapping and complete/incomplete for generalizations that are not part of a GeneralizationSet UML 2.5 open
UMLR-398 How can a GeneralizationSet not have any Generalizations? UML 2.5 open
UMLR-397 Ambiguity in description of TransitionKind UML 2.5 open
UMLR-352 Pin multiplicity and token upper bound UML 2.5 open
UMLR-350 UML 2.5 Section 15.2.3 p392 description for the ActivityEdge weight UML 2.5 open
UMLR-349 Another UML 2.5 Beta 2 XMI invalidity UML 2.5 open
UMLR-346 Classifier::ownedTemplateSignature needs to subset Element::ownedElement UML 2.5 open
UMLR-401 orthogonal State missing on bullet point list UML 2.5 open
UMLR-410 More on SateMachines UML 2.5 open
UMLR-409 Figure 14.5 State with Compartments does not show all the compartments that it should UML 2.5 open
UMLR-408 BNF notation as given and used is unclear about italics UML 2.5 open
UMLR-407 Figure 14.14 includes a "Submachine Sate" UML 2.5 open
UMLR-405 adding error UML 2.5 open
UMLR-413 A State can only have one Do/ behavior, but example shows more than one. UML 2.5 open
UMLR-412 Some hyperlinks are underlined and some are not. This is inconsistent UML 2.5 open
UMLR-411 These are typographical errors UML 2.5 open
UMLR-415 Object Flow arrow heads are inconsistent: V-shaped vs triangular UML 2.5 open
UMLR-414 Any Activity parameter is steaming. It must be too hot to handle UML 2.5 open
UMLR-421 Missing Example of TemplateBinding with model element "Class" UML 2.5b1 open
UMLR-418 InformatonFlows are constrained to be Classes or Classifiers -- which one? UML 2.5 open
UMLR-417 Are DeploymentSpecification execution-time input to components -- meaning they are somehow read by the component while they are running/executng? UML 2.5 open
UMLR-416 Can be performed their instances --> missing "by" UML 2.5 open
UMLR-424 UML 2.5: Property::isConsistentWith() error UML 2.5 open
UMLR-423 UML 2.5 beta issue - Operation notation is wrong UML 2.5b1 open
UMLR-422 UML2::Constraint UML 2.2 open
UMLR-403 Shouldn't it be possible to make the state of an object be private to support encapsulation/information hiding?. UML 2.5 open
UMLR-402 States of Reachable objects may be used in guard constraints, but reachable is not defined UML 2.5 open
UMLR-345 Issue against UML: implementation of OCL constraint containingProfile UML 2.5 open
UMLR-344 No specification of which visibility marking corresponds to which VisibilityKind value UML 2.5 open
UMLR-343 Semantics of static features UML 2.5 open
UMLR-342 BehavioralParameter should be BehavioralFeature UML 2.5 open
UMLR-341 UML wording in Superstructure 2.4.1 UML 2.5 open
UMLR-340 ExpansionNodes owned by ExpansionRegions? UML 2.5 open
UMLR-339 Incorrect sentence UML 2.5b1 open
UMLR-338 Incomplete sentence UML 2.5b1 open
UMLR-337 Message should extend Namespace UML 2.5 open
UMLR-336 meaning is not clear UML 2.5b1 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-334 Incorrect Result in ReduceAction Example UML 2.5 open
UMLR-333 UML 2.5 Mandatory but suppressible compartments UML 2.5 open
UMLR-332 UML 2.6 Issue --- SignalEvent Triggers UML 2.5 open
UMLR-331 Specification should not contain any methodology UML 2.5 open
UMLR-330 Incorrect OrderedSet returns UML 2.5 open
UMLR-327 Incorrectly drawn ParameterableElement.owningTemplateParameterSubstitution multiplicity UML 2.5 open
UMLR-326 Incorrect drawing of non-navigable redefined opposites UML 2.5 open
UMLR-325 Unnamed elements in a namespace UML 2.5 open
UMLR-324 Including use case depends on included use case but Include is no subclass of Dependency UML 2.5 open
UMLR-323 Unclear statement regarding Lifeline shape UML 2.5 open
UMLR-322 UML 2.5 Overly strict restriction on message slope in seq diagrams UML 2.5 open
UMLR-321 UML 2.5 issue on examples in 17.4.5 UML 2.5 open
UMLR-320 UML transition-centric state machine arrows (02) solid vs v-shaped arrow heads UML 2.5 open
UMLR-319 UML transition-centric state machine arrows (01) alternative exit pt vs entry pt notation UML 2.5 open
UMLR-318 UML 2.5 Visibility of a packagedElement UML 2.5 open
UMLR-317 UML 2.5 Issue on DI for reply arrows UML 2.5 open
UMLR-316 Ambiguous Profile::profileApplication UML 2.5 open
UMLR-314 UML 2.5 Figure 14.25 Choice Pseudostates UML 2.5 open
UMLR-313 Multiple Generalization Sets UML 2.5 open
UMLR-312 UML 2.5 Figure 10.10 Error UML 2.5 open
UMLR-311 Name of Package in Figure 7.3 should be "Core" rather than "Constructs" UML 2.4.1 open
UMLR-310 InstanceSpecification validity is not modelable UML 2.5 open
UMLR-309 Missing OpaqueXXX body constraint UML 2.5 open
UMLR-308 Generalization should be limited to relate similar UML-elements UML 2.5 open
UMLR-307 Type conformance for classifiers UML 2.5 open
UMLR-305 Rg. Reception.ownedParameter UML 2.5 open
UMLR-304 Descriptions missing for PseudostateKind literals UML 2.5 open
UMLR-303 Clause 21 Primitive Types is misnamed UML 2.5 open
UMLR-302 A PrimitiveType can/cannot have owned attributes. UML 2.5 open
UMLR-301 Can PrimitiveTypes be user-defined and where? UML 2.5 open
UMLR-300 Notation for PrimitiveTypes UML 2.5 open
UMLR-299 Problems with normative UML 2.5 Beta 2 Standard profile UML 2.5 open
UMLR-298 Problem with NamedElement::clientDependency subsets in UML 2.5 Beta 2 UML 2.5 open
UMLR-297 Problem with MultiplicityELement::lower redefinition in UML 2.5 Beta 2 UML 2.5 open
UMLR-296 BehavioredClassifier should redefine Classifier::conformsTo to include interfaceRealization UML 2.5 open
UMLR-295 Information flow instantiation UML 2.5 open
UMLR-294 Cannot set an activity as the source or target of an information flow UML 2.4.1 open
UMLR-293 About prescribed port implementation UML 2.5 open
UMLR-291 Sequence Diagram: Message limitation UML 2.5 open
UMLR-290 Improving the association direction notation 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-288 No rules on Extension Pts governing differences between Use Case definitions & «extend» relationships usage UML 2.5 open
UMLR-287 Use cases and use of arrows UML 2.5 open
UMLR-286 Even if Use Cases need not have an actor, there is some ambiguity when there is an «include»d or «extension» use case UML 2.5 open
UMLR-285 Abstract Syntax diagram for Use Cases 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-283 XMI.xmi is not merged UML 2.5 open
UMLR-282 Semantic error in UMLAssociationOrConnectorOrLinkShape::edge_instancespec invariant UML 2.5 open
UMLR-281 Semantic error in Lifeline::interaction_uses_share_lifeline UML 2.5 open
UMLR-280 ExtensionEnd upper/lower inconsistent with MultiplicityElement UML 2.5 open
UMLR-279 Relax Association::/endType from [1..*] to [0..*] UML 2.5 open
UMLR-278 Problems with OCL definition of Package::makesVisible UML 2.5 open
UMLR-277 isReplaceAll=true and lowerBound > 1 UML 2.5 open
UMLR-276 test UML 2.5 open
UMLR-275 applying and associating stereotypes and explanation of all aspects of their serialization UML 2.5 open
UMLR-274 Specifying the multiplicity of a part with an attribute UML 2.5 open
UMLR-273 Link notation for stereotype property value UML 2.5 open
UMLR-272 Generalization should be allowed to be cyclic and should no be restricted to be owned by the specialized classifier UML 2.5 open
UMLR-271 Migrate UML::Component's ability to own UML::PackageableElements to UML::Class UML 2.5 open
UMLR-270 Interaction.action should subset ownedMember in lieu of ownedElement UML 2.4.1 open
UMLR-269 Message Signature in Interactions and Reception.ownedParameter UML 2.5 open
UMLR-268 Concerning Transition and its owned elements UML 2.5 open
UMLR-267 UML 2.4/2.5 Aliases UML 2.5 open
UMLR-266 Abstraction::mapping should be of type ValueSpecification or OpaqueExpression UML 2.4 open
UMLR-265 The included use case is always required for the including use case to execute correctly UML 2.4.1 open
UMLR-264 OccurrenceSpecification should have at least an optional notation UML 2.4 open
UMLR-263 Message arguments should not be contained in a message UML 2.4 open
UMLR-262 Message arguments for a Signal signature too restrictive UML 2.4 open
UMLR-261 Relation of message arguments to signature parameters ambiguous UML 2.4 open
UMLR-260 Clarification about serializing the application of SysML 1.3 to a UML2.4.1 model UML 2.5 open
UMLR-259 UML Appendix A: After Figure A.4 UML 2.5 open
UMLR-258 UML: unification of OCL declarations UML 2.5 open
UMLR-257 Navigability orthogonal to end ownership or not? UML 2.3 open
UMLR-256 Ambiguous stereotype notation UML 2.5 open
UMLR-255 A deferrable trigger may have a guard UML 2.4 open
UMLR-254 Use cases specifying the same subject cannot be associated: exception UML 2.4 open
UMLR-253 State::stateInvariant multiplicity too restrictive UML 2.5 open
UMLR-252 Metaclass stereotype notion (02) UML 2.4 open
UMLR-251 Metaclass stereotype notion UML 2.4 open
UMLR-250 Profile URI Attribute - Mingled URI Definition and Use in XMI UML 2.4 open
UMLR-249 Package URI Attribute Uses Obsolete RFC 2396 UML 2.4 open
UMLR-248 Notation of Lifelines UML 2.5 open
UMLR-247 Tags typed by classes/blocks UML 2.5 open
UMLR-246 XMI representation of stereotype application UML 2.5 open
UMLR-245 New notation for attribute UML 2.5 open
UMLR-244 Retationships and composite structures UML 2.5 open
UMLR-242 Creation of an expansion node under an activity is allowed by UML and SysML specifications UML 2.3 open
UMLR-241 Part document structures in Superstructure need to conform to ISO standard Document Template Conventions UML 2.5 open
UMLR-240 UML 2.3 Infra 12 Incomplete conformance for infinity UML 2.5 open
UMLR-239 No Constraint for multiple associations UML 2.3b1 open
UMLR-238 UML 2 issue: connectors typed by Association Class UML 2.5 open
UMLR-237 Clarifying the support for and semantics of subsetting/redefinition for a pair of properties defined in different contex UML 2.5 open
UMLR-236 Under-specified associations in UML2.4 & the need for clarifying the semantic directionality for all UML associations UML 2.5 open
UMLR-235 Issue on UML 2.4 - notation for Component::provided UML 2.5 open
UMLR-233 Nasty UML 2.x Issue - /qualifiedName is not unambiguous UML 2.5 open
UMLR-232 Aggregation missing from Property string syntax UML 2.5 open
UMLR-231 Issue on UML 2.3 - Use of isAbstract for Interfaces UML 2.5 open
UMLR-230 How to specify actual parameters to pass to parameterized submachine StateMachine UML 2.5 open
UMLR-229 Ports UML 2.5 open
UMLR-228 Initialization of complex fields UML 2.5 open
UMLR-227 Owning of interaction fragments is ambiguous when InteractionOperands are present UML 2.5 open
UMLR-226 Chapter 14 is ambiguous and contradictory about how to link up messages and execution specifications UML 2.5 open
UMLR-225 issue10087 and association-like notation UML 2.5 open
UMLR-224 not sure it is possible to define a constraint without a context UML 2.5 open
UMLR-223 Timing Diagram and interchange UML 2.5 open
UMLR-222 Sequence diagram and Communication diagrams should support instances as lifelines UML 2.5 open
UMLR-221 Parameter UML 2.5 open
UMLR-220 NamedElements whose owners do not subset Namespace UML 2.5 open
UMLR-218 UML: Higher-level reusable frameworks UML 2.5 open
UMLR-217 UML: Timing semantics for activity diagram UML 2.5 open
UMLR-216 UML: Better Profile Capabilitiy UML 2.5 open
UMLR-215 UML:Access to standardized ontologies within models UML 2.5 open
UMLR-214 UML: Add abilities to specifiy intent of Assert, Negate, Consider, Ignore fragments UML 2.5 open
UMLR-213 UML: Improve Sequence Diagram Semantics (3-issues) UML 2.5 open
UMLR-212 UML: Cross model dependencies UML 2.5 open
UMLR-211 UML: Large Scale Model Support:Federated/Distibuted Models UML 2.5 open
UMLR-210 UML: Better Definition of Compliance UML 2.5 open
UMLR-209 UML: Provide mathematical formalism for UML semantics to provide precise meaning to language constructs UML 2.5 open
UMLR-208 UML: Diagrams as Model Elements UML 2.5 open
UMLR-207 UML: A strong ability to support generating Documents UML 2.5 open
UMLR-206 UML Support for multiple library levels UML 2.5 open
UMLR-205 UML: Support for maintaining what-if models in repository without massive duplication UML 2.5 open
UMLR-204 UML: A strong ability to support reviewing packages UML 2.5 open
UMLR-203 Provide notational mechanism to represent any group of model elements based on some criteria w/o stealing ownership UML 2.5 open
UMLR-201 UML: Include text description field with model element --- additional information added UML 2.5 open
UMLR-200 UML: Provide unique URL/URI Reference to/from Model Elements UML 2.5 open
UMLR-199 UML Associate an image/icon with each model element UML 2.5 open
UMLR-198 UML: Include text description field with model element UML 2.5 open
UMLR-197 UML: Incorporate SysML Requirements Model into UML UML 2.5 open
UMLR-196 UML: Need more robust value model that would enable capture of values vs time UML 2.5 open
UMLR-195 Simplify by Making UML More Consistent: Allow States to be model as classes supporting inheritance and composition UML 2.5 open
UMLR-194 Simplify by Making UML More Consistent: Apply class and composite structure diagram rules to behavior modeling UML 2.5 open
UMLR-193 UML Issue: Refactor UML to separate SW-Specific Aspects from Foundation Language UML 2.5 open
UMLR-192 One association end is derived, another is not UML 2.5 open
UMLR-191 Property subsets other regular property, non-derived union UML 2.5 open
UMLR-190 are Create messages aynch or synch, or doesn't it matter? UML 2.5 open
UMLR-189 UML 2 TemplateParameterSubstitution inconsistency about multiplicity of Actual and OwnedActual UML 2.5 open
UMLR-188 Stereotyped Constraints in UML UML 2.5 open
UMLR-187 Stereotyped Constraints in UML UML 2.5 open
UMLR-186 PrimitiveType has missing constraints UML 2.2 open
UMLR-184 Reconcile the algebra of collections across OCL & UML’s intentional & extensional semantics UML 2.5 open
UMLR-183 UML: Issue with stereotype icons in a profile UML 2.5 open
UMLR-182 The spec may require some clarification regarding figure 14.16 UML 2.5 open
UMLR-181 Need notation option to show type stereotype on typed element UML 2.5 open
UMLR-180 authorize a reference to an operation in a realized interface. UML 2.2 open
UMLR-179 Subsets vs. Redefines UML 2.5 open
UMLR-178 Package merge is missing a rule UML 2.2 open
UMLR-177 UML 2: notation and concepts for unbound and un-owned template parameters are not clear UML 2.5 open
UMLR-176 semantics of associating a use case with another use case, or indeed anything other than an actor, are unclear UML 2.2 open
UMLR-175 Should there be a constraint for extends equivalent to 16.3.6 [4] UML 2.2 open
UMLR-174 Visibility and Import relationships UML 2.5 open
UMLR-173 UML2: Need clarification on circle plus notation for containment UML 2.5 open
UMLR-172 Subsets vs. Redefines UML 2.5 open
UMLR-171 Template Binding Question UML 2.5 open
UMLR-170 there are numerous places where associations between UML elements have only one, navigable role UML 2.1.2 open
UMLR-169 Section: 18.3.8 UML 2.2 open
UMLR-168 The example in Figure 18.11 is badly designed in multiple ways and is strongly misleading UML 2.2 open
UMLR-167 Figure 18.9 shows a presentation option for an Interface which has not been introduced before (circle within box) UML 2.2 open
UMLR-166 Section: 18.3.6 UML 2.2 open
UMLR-165 issue within UPDM with profile diagrams UML 2.5 open
UMLR-164 Concrete specialization of the Relationship meta-class are missing UML 2.2 open
UMLR-163 UML 2.2 InteractionOperand abstract syntax UML 2.5 open
UMLR-162 Section: 9.3.11 Port UML 2.5 open
UMLR-161 UML 2 - appearance of Association Ends as members of the related classes UML 2.5 open
UMLR-160 UML2.2. Contradications in 14.3.10 UML 2.5 open
UMLR-159 Lack of clarity about meaning of package shapes containing elements with fully qualified names UML 2.5 open
UMLR-158 Section 9.3.4 Collaboration Use, 2nd constraint creates unneces UML 2.5 open
UMLR-157 we can create an invalid active state configuration UML 2.2 open
UMLR-156 Section: 7.3.9 Comment should be NamedElement UML 2.2 open
UMLR-155 UML2: Unclear how to indicate what events a classifier might send UML 2.5 open
UMLR-154 UML2.2 RTF: EnumerationLiteral is a DeploymentTarget UML 2.5 open
UMLR-153 UML: Standard Techniques to disambiguate crossing lines needed UML 2.5 open
UMLR-152 There is no way to specify the behavior of operations which are members of data types UML 2.5 open
UMLR-151 MARTE/section 7.2.1/ "several labels for the same classifiers in the Metamodel" bug UML 2.5 open
UMLR-150 18.3.8 Generalization of stereotyped model elements UML 2.2 open
UMLR-149 Actors cannot own Operations - a contradiction UML 2.5 open
UMLR-148 InterfaceRealization UML 2.5 open
UMLR-147 issue to address how problem 11240 was actually addressed in UML 2.2 spec UML 2.5 open
UMLR-146 Figure 7.65 and its explanation, P115 UML 2.5 open
UMLR-145 UML2 issue regarding Redefinition UML 2.5 open
UMLR-144 Section: 14.3.24, 14.3.20 UML 2.1.2 open
UMLR-143 3 3.2 Behavior (CommonBehaviors/BasicBehaviors) UML 2.1.2 open
UMLR-142 role bindings of a CollaborationUse UML 2.1.1 open
UMLR-141 Callout notation for many clients/suppliers SysML 1.0 open
UMLR-140 Section: Activities SysML 1.0 open
UMLR-139 UML 2.1.2 Super: Execution Specification UML 2.5 open
UMLR-138 Section: 15.3.7 Constraint [2] UML 2.1.2 open
UMLR-137 UML Super 2.1.2: section 18.3.2 UML 2.5 open
UMLR-136 Section: 18.3.3 UML 2.1.2 open
UMLR-135 new constraint ? UML 2.5 open
UMLR-134 Section 7.3.44 UML 2.1.2 open
UMLR-133 Section: 7.3.41 UML 2.1.2 open
UMLR-132 UML 2 has lost cability to represent operations by collaborations UML 2.1.2 open
UMLR-131 UML 2: Need an explicit listing of all semantic variation points UML 2.5 open
UMLR-130 should be able to show gates on communication diagrams UML 2.5 open
UMLR-129 pull semantics are only supported on Action inputs, not outputs UML 2.5 open
UMLR-128 UML2 Issue: notation for Literals does not allow for name UML 2.5 open
UMLR-127 Section: 14.4 UML 2.5 open
UMLR-126 Figure 7.48 and the accompanying discussion under 7.3.21 UML 2.1.1 open
UMLR-125 simpleTime package problems UML 2.5 open
UMLR-124 Section: 7.3.37 Package (from Kernel) UML 2.1.1 open
UMLR-123 UML2 Property collaborationRole should be removed UML 2.5 open
UMLR-122 Section: 16.3.5 UML 2.1.1 open
UMLR-121 Section: 7.3.3 UML 2.5 open
UMLR-120 Section: Annex A: Diagrams UML 2.1.1 open
UMLR-118 Section: 14.4 Timing Diagram: Continuous time axis UML 2.1.1 open
UMLR-117 9.3.9 Invocation Action UML 2.5 open
UMLR-116 UML 2.1.1 - notation for parameter sets UML 2.5 open
UMLR-115 Units and types are still problematic UML 2.5 open
UMLR-114 names and namespaces UML 2.5 open
UMLR-111 Section: 10.3.4 of formal/2007-02-03 UML 2.1.1 open
UMLR-110 clarification on Behavior::specification / meaning of InterfaceRealization UML 2.5 open
UMLR-109 Presentation option for return parameter for operation type are incomplete UML 2.5 open
UMLR-108 UML 2 Superstructure: Abstractions should be acyclic UML 2.5 open
UMLR-106 Connector contract is inflexible UML 2.5 open
UMLR-105 Constraint.context vs Constraint.constrainedElement UML 2.5 open
UMLR-104 Section: Chapter: 7.3.2.4 View SysML 1.0 open
UMLR-103 Section: 7 UML 2.0 open
UMLR-102 Association::isDerived should be derived UML 2.5 open
UMLR-100 Section: 13 & 14 UML 2.1.1 open
UMLR-99 Optional values and evaluation of defaults UML 2.5 open
UMLR-98 OCL Syntax in expressions UML 2.5 open
UMLR-97 Guidance for Representing Enumeration Values UML 2.5 open
UMLR-96 Section: 15.3.12, p 588, 589 UML 2.1.1 open
UMLR-95 Relationships UML 2.5 open
UMLR-94 Default value types UML 2.5 open
UMLR-93 Section: 7.3.33 UML 2.1.1 open
UMLR-91 ValueSpecification::isComputable() UML 2.5 open
UMLR-90 Unclear usage of LiteralExpression::type UML 2.5 open
UMLR-88 Unnecessary restriction on aggregations being binary UML 2.5 open
UMLR-87 New issue on notation for multiple stereotypes UML 2.5 open
UMLR-86 Link notation for instance diagrams does not cope with multiple classifiers UML 2.5 open
UMLR-85 UML2: No notation for indicating Operation::raisedException UML 2.5 open
UMLR-84 Reception has no notation for its signal UML 2.5 open
UMLR-83 ControlNodes in ActivityPartitions UML 2.5 open
UMLR-82 Notation for ordering action input and output pins UML 2.5 open
UMLR-81 All associations ends in the UML2 metamodel itself should be navigable UML 2.5 open
UMLR-80 Section: Sequence diagrams UML 2.0 open
UMLR-79 Section: 7.3.9 UML 2.1 open
UMLR-78 consistent ordering of Association::memberEnd and ownedEnd UML 2.5 open
UMLR-77 No ReadParameterAction or WriteParameterAction UML 2.5 open
UMLR-76 No notation for associating Exceptions with Operations UML 2.5 open
UMLR-75 Page: 107 UML 2.0 open
UMLR-74 Need more flexible notation for activity partitions UML 2.5 open
UMLR-73 Page: 492-493 UML 2.5 open
UMLR-72 Section: Classes UML 2.0 open
UMLR-71 Section: Activities UML 2.0 open
UMLR-70 Section: Classes UML 2.0 open
UMLR-69 UML2 Super / 14.3.13 Interaction UML 2.5 open
UMLR-67 Syntax of Transition UML 2.5 open
UMLR-66 OutputPin UML 2.5 open
UMLR-65 UML 2.0 Super/Use Cases/Subject of a Use Case UML 2.5 open
UMLR-64 Issue 7368 - make Classifier::useCase navigable UML 2.5 open
UMLR-63 Variables UML 2.5 open
UMLR-62 Numbering UML 2.5 open
UMLR-61 Arguments of Message UML 2.5 open
UMLR-60 ConditionalNode inputs used by more than one test UML 2.0 open
UMLR-59 Section: 14.3.3 Page: 508+ UML 2.0 open
UMLR-58 Section: 14.3.3 UML 2.0 open
UMLR-57 Arguments of Message UML 2.5 open
UMLR-56 Association in UseCase diagram UML 2.5 open
UMLR-55 Possibility to define a Collection as default Value needed UML 2.0 open
UMLR-53 Meaning of relationship between iteration clause and Lifeline.selector clau UML 2.5 open
UMLR-52 UML2-rtf issue: communication diagram UML 2.5 open
UMLR-51 Section: 10.3.1 UML 2.0 open
UMLR-50 Add a Constraint UML 2.5 open
UMLR-49 SequenceNode should have way to set output pins in CompleteStructured UML 2.0 open
UMLR-48 Add constraints on ConditionalNode UML 2.0 open
UMLR-47 ExpansionRegion (behavior in the shorthand notation) UML 2.0 open
UMLR-46 Section: Activities : Why is exception type needed? UML 2.0 open
UMLR-45 Section: Activities - clarification UML 2.0 open
UMLR-44 Activities section UML 2.0 open
UMLR-43 Section: 16.3.1 UML 2.0 open
UMLR-42 ReadStructuralFeatureAction UML 2.0 open
UMLR-40 Properties on Association for end objects UML 2.0 open
UMLR-39 Notation for classifierBehavior UML 2.0 open
UMLR-38 Contextualized attribute values Figures 121 UML 2.0 open
UMLR-37 End objects of a link In the semantics of AssociationClass UML 2.0 open
UMLR-36 Action for retrieving activity instance UML 2.0 open
UMLR-34 Section: Classes, Behavior UML 2.0 open
UMLR-33 Too much navigability from Generalizations UML 2.5 open
UMLR-32 Alternative entry and exit point notation is ambiguous UML 2.0 open
UMLR-31 Coupling between StateMachines and Activities UML 2.5 open
UMLR-30 Provide exception handling for all behaviors. UML 2.0 open
UMLR-29 surface notation for state machines UML 2.0 open
UMLR-28 metaattribute isReadOnly UML 2.0 open
UMLR-27 inconsistency in the action model UML 2.0 open
UMLR-26 large overlap between structural features and variables UML 2.0 open
UMLR-25 Priority of the joint transition UML 2.5 open
UMLR-24 UML2 Super/Deployments/Manifestation UML 2.5 open
UMLR-23 UML2 Super/Deployment/inheritance UML 2.5 open
UMLR-22 Questions about DataTypes and generalization UML 2.5 open
UMLR-21 missing illustrations of graphical paths for create and destroy messages UML 2.5 open
UMLR-20 UML 2 Super / Interactions / Ambiguous diagram tags UML 2.5 open
UMLR-19 Redefinitions of OCL constraints must be aligned with MOF2.0/UML2.0 class R UML 2.0 open
UMLR-18 UML 2 Infrastructure / rule for redefinition of Property UML 2.5 open
UMLR-17 UML 2.0 Superstructure Kernal/Packages UML 2.5 open
UMLR-16 freeing namespace UML 2.5 open
UMLR-15 ptc-03-09-15/Explain the new association modeling constructs UML 2.5 open
UMLR-14 ptc-03-09-15/Need for examples to include instance models UML 2.5 open
UMLR-13 Conditions for parameter sets UML 2.5 open
UMLR-12 Section 7.11.2 Association UML 2.5 open
UMLR-11 Clarification of use case semantics UML 2.5 open
UMLR-10 Integration between behavioral "sublanguages": Interactions and Activities UML 2.5 open
UMLR-9 UML 2 Super / State machines / Transition triggers cannot be redefined UML 2.5 open
UMLR-8 Join nodes that destroy tokens UML 2.5 open
UMLR-7 Deployment a dependency? UML 2.5 open
UMLR-6 Notation for method UML 2.5 open
UMLR-5 Promote local conditions to ExecutableNode UML 2.5 open
UMLR-4 Parameterization of lifelines UML 2.0 open
UMLR-3 More explanation needed on Figure 339 UML 2.0 open
UMLR-2 More examples UML 2.0 open
UMLR-1 Conditional Node and Loop Node notation missing UML 2.5 open

Issues Descriptions

Error in Loop fragment deffinition

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

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

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

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

Duplicate section titles

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

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

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

UML Specification "Normative References" uses non-secure links

  • Key: UMLR-759
  • Status: open  
  • Source: Lockheed Martin ( Charles Galey)
  • Summary:

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

  • Reported: UML 2.5 — Wed, 20 Mar 2019 02:59 GMT
  • Updated: Thu, 20 Jun 2019 07:06 GMT

Property.Association is not a union

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

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

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

Comments not annotating anything should annotate their owner

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

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

    Suggestion
    Current specification:

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

    add following sentences:

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

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

No way of specifying element documentation

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

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

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

Specializations of an Association Class

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

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

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

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

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

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

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

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

UML has no way of distinguishing Notes from Comments

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

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

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

Association class notation with just class or association

  • Key: UMLR-185
  • Legacy Issue Number: 14426
  • Status: open  
  • Source: Raytheon ( Roy Bell)
  • Summary:

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

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

Clarify that AcceptEventActions in InterruptibleActivityRegions are disabled when token leaves

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

    The specification says about InterruptibleActivityRegions:

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

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

    Suggestion
    Change the sentence to

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

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

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

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

Description of Generalization of Enumerations is contradictory

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

    The specification says:

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

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

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

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

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

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

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

Duplicated xmi:id values in UML.xmi

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

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

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

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

Make AssociationClasses unique again

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

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

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

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

  • Reported: UML 2.5 — Mon, 4 Mar 2019 14:11 GMT
  • Updated: Mon, 4 Mar 2019 16:42 GMT

Behavior::behavioredClassifier bodycondition is serialized as a precondition

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

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

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

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

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

Unclear whether current State during Transition is the target State

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

    The specification says:

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

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

    Suggested change

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

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

Figure 9.11 misses attribute name

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

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

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

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

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

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

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

The definition of relative Time Events is ambigious

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

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

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

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

About behavior ports

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

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

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

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

    This has to be clarified.

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

Operation calls on behavior ports

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

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

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

Behavioral port

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

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

    Description:

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

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

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

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

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

    Suggested resolution:

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

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

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

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

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

Are null NamedElement::name values names?

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

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

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

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

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

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

Typo

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

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

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

Figure 7.17 has some trucated labels

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

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

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

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

Typo in last syntax example

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

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

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

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

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

Attachment point of connectors not specified

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

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

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

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

Implied Multiplicity of the association-like notation should be displayable

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

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

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

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

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

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

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

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

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

    as well as:

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

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

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

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

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

What is a DurationInterval

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

    Identifies is better than points out.

    Subsequent description is confusing about one/two NamedElements.

    Suggest:

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

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

What is a DurationInterval

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

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

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

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

Observations in TimeExpressions

  • Key: UMLR-438
  • Legacy Issue Number: 18747
  • Status: open  
  • Source: Simula Research Laboratory ( 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: Model Driven Solutions ( 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

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

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

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

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

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

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

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

    Type Limitations on DecisionInputFlows

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

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

Restrictions on decision nodes

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

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

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

    Or

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

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

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

Unspecified and inconsistent notation for Observations

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

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

ActivityEdge weight examples

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

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

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

Implication of weight of ActivityEdge is unclear

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

    The specification says in 15.2.3.3:

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

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

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

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

    Suggestion
    After

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

    Add

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

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

Conjugated port properties shown on association ends and in compartments

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

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

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

Actor Relationships

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

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

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

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

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

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

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

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

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

Incorrect arrow heads for object flows

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

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

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

Ambiguous meaning of word "composed"

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

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

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

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

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

Section: Annex A: Diagrams

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

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

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

ClassB::height missing from diagram

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

    id

    Unknown macro: {redefines name}

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

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

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

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

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

    The socket does not have a name above it.

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

Section 14.2.4.4 is not a real section

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

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

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

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

Why is Association.memberEnd ordered?

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

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

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

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

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

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

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

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

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

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

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

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

Transition guards should be its own section.

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

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

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

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

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

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

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

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

  • Reported: UML 2.5 — Mon, 9 May 2016 18:57 GMT
  • Updated: Tue, 6 Dec 2016 19:45 GMT

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

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

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

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

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

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

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

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

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

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

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

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

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

Figure 14.44 ProtocolStateMachine example error

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

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

  • Reported: UML 2.5 — Fri, 5 Aug 2016 08:13 GMT
  • Updated: Tue, 6 Dec 2016 19:33 GMT

State machine semantics for transition between regions of an orthogonal state

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

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

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

Invalid XMI elements containing both xmi:type and href

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

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

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

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

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

Missing visibility definition

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

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

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

What is a "compound state"?

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

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

    Please define.

    See 14.2.3.8.4 p 313

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

All actions should be able to own control pins

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

    The specification says:

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

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

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

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

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

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

Missing Constraint: Associations cannot type StructuralFeatures

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

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

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

Actor association constraint makes UseCase subclass of Class

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

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

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

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

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

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

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

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

    Jon Siegel, OMG
    20161104

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Key: UMLR-92
  • Legacy Issue Number: 9751
  • Status: open  
  • Source: No Magic, Inc. ( Tomas Juknevicius)
  • Summary:

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

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

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

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

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

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

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

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

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

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

What is "a separate InteractionConstraint"?

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

    The specification says:

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

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

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

XOR Constraint modeling

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

    Fgure 7.16 of the UML 2.5 specification shows an

    {xor}

    constraint. How is this encoded in the UML model?

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

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

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

Meaning of Event on Initial Transition unclear

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

    The specification says:

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

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

    Suggestion

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

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

Inconsistent constraints about several kinds of UML Diagrams

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

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

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

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

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

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

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

OpaqueExpression should own Behavior

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

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

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

Semantics of Lifeline.selector not clear

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

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

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

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

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

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

Notation is depreciated for inherited interface

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

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

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

Comment is misleading

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

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

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

    I think this text should be deleted.

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

Mixed plural/singular

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

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

    Whoever it might be better to rewrite the sentence:

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

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

Plural vs Singulr?

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

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

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

Unclear sentence

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

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

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

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

Missing words in sentence

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

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

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

reply messages in interactions

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

    Similar situation with reply messages in interactions.

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

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

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

Subclasses of InstanceSpecification

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

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

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

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

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

ValueSpecification that refers to some Element shall be defined

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

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

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

Ability to define "context specific" default values for Part

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

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

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

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

Interaction parameters.

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

    Other related issue - Interaction parameters.

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

    How value returning is represented?

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

How should context be represented?

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

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

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

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

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

    Figure 11.29 has the correct ordering:

    • summary of figure
    • the figure
    • explanation of figure

    Figure 11.30 has an incorrect ordering:

    • summary of figure
    • explanation of figure
    • the figure

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

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

Link to "see" sections missing

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

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

    are missing clickable cross-references.

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

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

AssociationEnd/Attribute redefintion consistency

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

Disjointness should be independent of generalization

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

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

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

section 7.3.17 /EnumerationLiteral should not be an InstanceSpecification

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

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

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

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

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

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

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

Impossiblity to specify links for connected roles.

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

    The specification says

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

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

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

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

Delegation Connector should not be typed

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

    The Specification says

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

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

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

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

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

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

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

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

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

  • Reported: