Unified Modeling Language Avatar
  1. OMG Specification

Unified Modeling Language — Open Issues

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

Issues Summary

Key Issue Reported Fixed Disposition Status
UMLR-480 Can passive classes have ClassifierBehaviors? UML 2.4.1 open
UMLR-542 Figure 12-15 (MOF Model Equivalent …) p.284 - MOF Model Equivalent navigation and ownership incorrect UML 2.4.1 open
UMLR-582 What is a DurationInterval UML 2.4.1 open
UMLR-584 What is a DurationInterval UML 2.4.1 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-354 State machine semantics for transition between regions of an orthogonal state UML 2.4.1 open
UMLR-488 Interaction parameters. UML 2.4.1 open
UMLR-489 How should context be represented? UML 2.4.1 open
UMLR-617 Location: 18.1.5 Examples Figure 18-2. 689 - Explain about Navigation UML 2.4.1 open
UMLR-504 Location: 18.2 Classifier Descriptions Extend Constraints. 695 - Constraint is overly restrictive UML 2.4.1 open
UMLR-502 Location: 18.1.4 Notation P. 688 - Can Use Cases have attributes and operations? UML 2.4.1 open
UMLR-496 Location: Figure A.5 P. 734 - Use Cases are not behavior diagrams UML 2.4.1 open
UMLR-497 Location: Appendix A, list of frame names, p 734 - List of Namespaces suitable for diagram headers is overly restrictive UML 2.4.1 open
UMLR-500 Location: 18.1.1 Summary p 685 - Bases of specialized stereotypes UML 2.4.1 open
UMLR-501 Location: 19.5 Classifier Descriptions Deployment Specification Attributes P. 711 - Why a multiplicity of [0..1] UML 2.4.1 open
UMLR-498 Location: 22.3 Standard Stereotypes «Metamodel» p. 731 - «Subsystem» should be allowed for more classifiers UML 2.4.1 open
UMLR-499 Location: 19.5 Node Association Ends Node P. 714 - Shared ownership of nodes UML 2.4.1 open
UMLR-506 Location: 18.2 Classifier Descriptions Extend Constraints. 695 - Extensions must be a DAG UML 2.4.1 open
UMLR-495 Location: Figure B.3. 737 - A diagram is a PackageableElement UML 2.4.1 open
UMLR-568 Reword isComputable UML 2.4.1 open
UMLR-569 Location: 8.6 p 98 TimeObservation ...simplify UML 2.4.1 open
UMLR-576 Too many alls UML 2.4.1 open
UMLR-575 Intended to Produce UML 2.4.1 open
UMLR-577 Bad Description, observation has no value UML 2.4.1 open
UMLR-580 Like to overridden definition UML 2.4.1 open
UMLR-573 Why can’t the operand be a stringExpression UML 2.4.1 open
UMLR-578 Range Confusion UML 2.4.1 open
UMLR-570 Simplify (Location: 8.6 p 97 TimeExpression) UML 2.4.1 open
UMLR-574 Bad Description UML 2.4.1 open
UMLR-571 Simplify UML 2.4.1 open
UMLR-572 What incompatible about sub-expressions and operands UML 2.4.1 open
UMLR-432 Add condition : Constraint[0..1] to the include relationship UML 2.4.1 open
UMLR-595 Definition of invariant condition UML 2.4.1 open
UMLR-597 Section Unbalanced UML 2.4.1 open
UMLR-592 Need table correlating Literals with symbols (+,-,#,~) UML 2.4.1 open
UMLR-593 Inconsistent use of (s) UML 2.4.1 open
UMLR-601 Section 11.7 has no content or notation for template Collaborations Clause - 11: Structured Classifiers UML 2.4.1 open
UMLR-603 Section 11.3.4 isService clarification - Clause 11: Structured Classifiers UML 2.4.1 open
UMLR-596 Descendants rather than specializations UML 2.4.1 open
UMLR-602 Section 11.2.4 clarification - Clause 11: Structured Classifiers UML 2.4.1 open
UMLR-600 List attributes whose ordered property has change in UML 2.5 UML 2.4.1 open
UMLR-598 Bound Element Semantics overly specific UML 2.4.1 open
UMLR-599 UML 2.5 FTF issues for Clause 18: UseCases UML 2.4.1 open
UMLR-594 Template Notation example UML 2.4.1 open
UMLR-615 Clarification on the semantics of CommunicationPath UML 2.4.1 open
UMLR-614 isIntegral() UML 2.4.1 open
UMLR-613 Capitalization of dependency UML 2.4.1 open
UMLR-476 Node::nestedNode should subset Class::nestedClassifier, not Namespace::ownedMember. UML 2.4.1 open
UMLR-477 Meaning of State in ProtocolStateMachines UML 2.4.1 open
UMLR-479 Should “completion” event be an explicit event type? UML 2.4.1 open
UMLR-481 Not clear if “else” keyword is defined for State Machines UML 2.4.1 open
UMLR-482 State of the substates of the history state UML 2.4.1 open
UMLR-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-478 Figure 14.39 – missing superclass UML 2.4.1 open
UMLR-517 Not clear when to use ExecutionOccurrenceSpecification with ExecutionSpecification UML 2.4.1 open
UMLR-518 Location: Pg. 617, Figure 17.4.4: Notation, Sub-clause: Message UML 2.4.1 open
UMLR-508 18.1.3 Semantics Use Case and Actors Extends P. 687 - No Alternative Path UML 2.4.1 open
UMLR-509 18.1.3 Semantics Use Case and Actors Extends P. 687 - First ExtensionPoint UML 2.4.1 open
UMLR-513 Location: 18.1.3 Semantics Use Cases and Actors P. 686 - What classifiers can be a subject? UML 2.4.1 open
UMLR-516 Location: 18. Global - No discussion of use case instances UML 2.4.1 open
UMLR-511 Location: 18.1.3 Semantics Use Cases and Actors P. 686 - Multiplicity at Use Case end UML 2.4.1 open
UMLR-510 18.1.3 Semantics Use Case and Actors Extends P. 687 - Show name of extension UML 2.4.1 open
UMLR-514 Location:Page #640, 17.8.2 Example Sequence Diagram UML 2.4.1 open
UMLR-512 Location: 18.1.3 Semantics Use Cases and Actors P. 686 - Multiple subjects require the same actors UML 2.4.1 open
UMLR-507 18.1.3 Semantics Use Case and Actors Extends P. 687 - Single Location UML 2.4.1 open
UMLR-515 Location: weak sequencing p. 622 UML 2.4.1 open
UMLR-585 What is a DurationConstaint UML 2.4.1 open
UMLR-586 Time constant UML 2.4.1 open
UMLR-579 More detail on Express UML 2.4.1 open
UMLR-590 Expression examples unclear UML 2.4.1 open
UMLR-588 OCL not indexed UML 2.4.1 open
UMLR-591 Semantics Clarification UML 2.4.1 open
UMLR-587 Event UML 2.4.1 open
UMLR-581 incompatible multiplicities UML 2.4.1 open
UMLR-583 one -- > first UML 2.4.1 open
UMLR-589 Orphan Title UML 2.4.1 open
UMLR-521 Location: Pg. 613, Figure 17.6 - : Incorrect multiplicities in the metamodel in Figure 17.6 UML 2.4.1 open
UMLR-522 Location: p 611 UML 2.4.1 open
UMLR-524 Not clear when to use ExecutionOccurrenceSpecification with ExecutionSpecification UML 2.4.1 open
UMLR-529 Location p413 Final Node - Rollback behavior UML 2.4.1 open
UMLR-532 Location p413 Final Node - Atomic behavior UML 2.4.1 open
UMLR-519 Location: 17.3.4 Notation Lifeline p 613 - Specification of color UML 2.4.1 open
UMLR-520 Location: Pg. 613, Figure 17.6 - Incorrect multiplicities in the metamodel in Figure 17.6 UML 2.4.1 open
UMLR-525 Interactions p 607 UML 2.4.1 open
UMLR-523 Location: 16.2.3 Semantics / Opaque Actions UML 2.4.1 open
UMLR-527 Location: Figure 15.67 page 436 UML 2.4.1 open
UMLR-526 Location: p 504 - Marshall Actions UML 2.4.1 open
UMLR-608 Issue for UML 2.5 FTF against Clause 9: Classifiers 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-566 Location: 9.6.4 Notation p 127 Missing Infix operation syntax / discussion UML 2.4.1 open
UMLR-567 ParameterSet Notation UML 2.4.1 open
UMLR-561 Location: constraints class_behavior p.190 UML 2.4.1 open
UMLR-562 Location 10.3.3 Receptions p.186 - exceptions for receptions? UML 2.4.1 open
UMLR-563 p 118: isException and other outputs UML 2.4.1 open
UMLR-560 Location: Constraints p 193 - All feturs must be public? UML 2.4.1 open
UMLR-564 Location p 162 ParameterSet associationends: Exceptions and parametersets UML 2.4.1 open
UMLR-558 Location: 12.1 Packages Summary p 264 UML 2.4.1 open
UMLR-559 Location: Figure 11-5 (ii) p 204 UML 2.4.1 open
UMLR-565 Query of alternative scopes? UML 2.4.1 open
UMLR-486 Problems with XMI IDs in the UML 2.5 UML.xmi file UML 2.4.1 open
UMLR-487 17 Semantics of interactions UML 2.4.1 open
UMLR-490 UML Interactions do not provide the ability for Messages to correspond directly to property accesses and updates UML 2.4.1 open
UMLR-493 Location: B.6 UML ProfileDiagrams . 768 - Profile Diagram Elements UML 2.4.1 open
UMLR-492 Location: B.6 UMLClass Diagram P. 757 - Class namespace diagrams? UML 2.4.1 open
UMLR-483 Overriding deferred events UML 2.4.1 open
UMLR-484 Stable state not needed UML 2.4.1 open
UMLR-491 Location: Annex C Keywords P. 778 - Inconsistent metaclass keywords UML 2.4.1 open
UMLR-485 Default entry if default history transition missing UML 2.4.1 open
UMLR-494 Location: B.2.2 P. 738 - What ISO document UML 2.4.1 open
UMLR-549 Location: Page 270/271, 12.2.3 Semantics - Model description confusing UML 2.4.1 open
UMLR-550 Location: Page 269, 12.2.3 Semantics - Association merge aggregation constraint is property rule UML 2.4.1 open
UMLR-545 Location: Page 286, 12.3.3 Semantics - Incorrect if statement UML 2.4.1 open
UMLR-544 Location: Page 285, 12.3.3 Semantics - Old behavior unnecessarily preserved UML 2.4.1 open
UMLR-552 Page 269, 12.2.3 Semantics - Property merge transformation conflicts with constrain UML 2.4.1 open
UMLR-553 Location: Page 267, 12.2.3 Semantics - Type and TypedElement confusion UML 2.4.1 open
UMLR-556 Location: Page 265, 12.2.3 Semantics PackageMerge - Long-winded package merge description UML 2.4.1 open
UMLR-546 Location: Page 281, 12.3.3 Semantics - Duplicated text UML 2.4.1 open
UMLR-554 Page 266, 12.2.3 Semantics - Un-matched resulting elements aren't always the same UML 2.4.1 open
UMLR-548 Location: Page 280, 12.3.3 Semantics - Note should be main text UML 2.4.1 open
UMLR-551 Location: Page 269, 12.2.3 Semantics - Property merge rule pointless UML 2.4.1 open
UMLR-547 Location: Page 280, 12.3.3 Semantics - Poorly indented XMI UML 2.4.1 open
UMLR-543 Location: Page 286, 12.3.3 Semantics - Nonsensical alternative to stereotype name UML 2.4.1 open
UMLR-531 Location: p 410 UML 2.4.1 open
UMLR-537 Location: Page 328, 14.2.3 - UseCase cannot be the context of a StateMachine UML 2.4.1 open
UMLR-536 Location: Signal Receipt symbol UML 2.4.1 open
UMLR-534 Location: Page 346, State List Notations - Why must state lists be effect free? UML 2.4.1 open
UMLR-538 Location: 13.3.5 Examples p 314 UML 2.4.1 open
UMLR-540 Location: Opaque and Function Behaviors p 308 UML 2.4.1 open
UMLR-533 Location: p. 336 Compound transitions - Run-to-completion Paradigm UML 2.4.1 open
UMLR-539 Location: Page 316 redefinedBehavior - Extends UML 2.4.1 open
UMLR-535 Location: Page 331 deep history entry - Default deep history entry UML 2.4.1 open
UMLR-541 Location: Figure 12-13 p.281 - Incorrect use of << for «. UML 2.4.1 open
UMLR-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-264 OccurrenceSpecification should have at least an optional notation UML 2.4 open
UMLR-262 Message arguments for a Signal signature too restrictive UML 2.4 open
UMLR-261 Relation of message arguments to signature parameters ambiguous UML 2.4 open
UMLR-265 The included use case is always required for the including use case to execute correctly UML 2.4.1 open
UMLR-266 Abstraction::mapping should be of type ValueSpecification or OpaqueExpression UML 2.4 open
UMLR-263 Message arguments should not be contained in a message UML 2.4 open
UMLR-294 Cannot set an activity as the source or target of an information flow UML 2.4.1 open
UMLR-254 Use cases specifying the same subject cannot be associated: exception UML 2.4 open
UMLR-252 Metaclass stereotype notion (02) UML 2.4 open
UMLR-251 Metaclass stereotype notion UML 2.4 open
UMLR-250 Profile URI Attribute - Mingled URI Definition and Use in XMI UML 2.4 open
UMLR-249 Package URI Attribute Uses Obsolete RFC 2396 UML 2.4 open
UMLR-255 A deferrable trigger may have a guard UML 2.4 open
UMLR-311 Name of Package in Figure 7.3 should be "Core" rather than "Constructs" UML 2.4.1 open
UMLR-270 Interaction.action should subset ownedMember in lieu of ownedElement UML 2.4.1 open

Issues Descriptions

Can passive classes have ClassifierBehaviors?

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

    Category: Major

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

  • Reported: UML 2.4.1 — Wed, 10 Oct 2012 04:00 GMT
  • Updated: Mon, 3 Feb 2020 16:26 GMT

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

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

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

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

What is a DurationInterval

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

    Identifies is better than points out.

    Subsequent description is confusing about one/two NamedElements.

    Suggest:

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

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

What is a DurationInterval

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

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

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

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

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

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

Interaction parameters.

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

    Other related issue - Interaction parameters.

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

    How value returning is represented?

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

How should context be represented?

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

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

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

Location: 18.1.5 Examples Figure 18-2. 689 - Explain about Navigation

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

    The example should be shown with navigation (arrows) on the associations, to indicate initiating (primary) and non-initiating (secondary) actors. This is legal and common notation
    This would partially address Issue 8855

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Updated: Mon, 9 Mar 2015 03:34 GMT

Location: 18.2 Classifier Descriptions Extend Constraints. 695 - Constraint is overly restrictive

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

    current text: The ExtensionPoints referenced by the Extend relationship must belong to the UseCase that is being extended

    Does this "belong" also include
    1) ExtensionPoints that would be inherited?
    2) ExtensionPoints that would be defined in Included Use Cases.

    Both of these are required to support behavioral refactoring and reuse. If a "super" UseCase or an Included UseCase are made to pull out common behavioral parts, it may be that some an extending use case needs to be inserted at
    a) extension points that cross use case boundaries (e.g., in the super and child use case, or in the included and base use case) or
    b) an extension UseCase needs to be inserted in a base use case, but not in all use cases tsshat include the Included UseCase, and not in all children of the generalized UseCase.

    Without including the extensionPoints from both these sources, such situations cannot be handled.

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: 18.1.4 Notation P. 688 - Can Use Cases have attributes and operations?

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

    A UseCase is a BehavioredClassifier, which is a Classifier, which has features of Type Property (Subclasses are Operation and Reception). However "feature" is a derived union and neither BehavioredClassifier nor UseCase define subsets of it. Therefore the features of a UseCase are always an empty set. I heard of one UML-Tool that actually enforces this rule.

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: Figure A.5 P. 734 - Use Cases are not behavior diagrams

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

    Use case diagrams don’t show change over time, they show intents, purposes, etc. They are neither structure nor behavior. Redraw diagram to make new category
    They are more similar to SysML requirement diagrams

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: Appendix A, list of frame names, p 734 - List of Namespaces suitable for diagram headers is overly restrictive

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

    A diagram of Model, Node, Datatype, etc. should be allowed.
    This is also UML 2.4 Open Issue 16484.

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: 18.1.1 Summary p 685 - Bases of specialized stereotypes

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

    Was wondering if clarification was needed on adding bases to specialized stereotypes. Since Extensions are associations:

    • Bases of general stereotypes inherit to specialized stereotypes, and instances of specialized stereotypes can be applied to any of the bases, including inherited ones.

    • Bases of specialized stereotypes can be specialized from more general bases by redefinition or subsetting of ExtensionEnds.

    This all follows from Extensions as associations/classifiers, so maybe doesn't really need to be explicitly said, not sure.

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: 19.5 Classifier Descriptions Deployment Specification Attributes P. 711 - Why a multiplicity of [0..1]

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

    An artifact can be located in multiple locations, for example, on a disk and in ROM, and in RAM. Similarly, it could execute partially in ROM and also in RAM. In addition, an executable could reside in multiple places in memory on the same machines, with multiple copies running at once. Also they could assigned to different "cores"

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: 22.3 Standard Stereotypes «Metamodel» p. 731 - «Subsystem» should be allowed for more classifiers

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

    Subsystem should also be allowed for other types of classifier, e.g., class. Limiting this to components enforces a particular methodological approach and is incompatible with Systems Engineers, who would use «Subsystem» for blocks, a specialization of Class.

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: 19.5 Node Association Ends Node P. 714 - Shared ownership of nodes

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

    In fancy hw, a node could be owned by more than one owning node: Shared memory, shared processors, distributed processing...

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: 18.2 Classifier Descriptions Extend Constraints. 695 - Extensions must be a DAG

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

    Missing constraint or discussion anywhere that the chain of extends relations must not contain loops

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: Figure B.3. 737 - A diagram is a PackageableElement

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

    A diagram is a packageableElement.

    What does it look like in a package

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Reword isComputable

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

    This is woolly just redirecting to 'can be computed'.

    Suggest: A ValueSpecification can be computed when all the algorithms, resources and values required to perform a computation are available. So a ValueSpecification would not be computable if an operation without a body was invoked, an off-line processor is required, or a source value is required. isComputable() is intended to be a static determination of capability, so a computation failure such as divide-by-zero or an I/O
    failure would not prevent isComputable() returning true, rather they would cause a query
    such as realValue() to return no value.

    ?? if a computation needs a currently locked resource, is it computable? Probably yes, since if the computation waits patiently the result will appear ??

    ?? Should be three-valued...

    True => a computation now will run
    False => a computation now will abort
    Null => a computation now might abort

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: 8.6 p 98 TimeObservation ...simplify

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

    Simpler:
    A TimeObservation identifies a time instant at which execution either enters or exits a particular NamedElement.
    ...

    firstEvent[i] is true to select the enter, or false to select the exit event when observing execution of the NamedElement

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Too many alls

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

    Too many 'all's; remove all in front of all the component values.

    Suggest just: ... concatenating the ordered String values of each operand or subExpression.

    Simplerbody: if subExpression->notEmpty()then subExpression->iterate(se; stringValue: String = '' | stringValue + se.stringValue())else operand->iterate(op; stringValue: String = '' | stringValue + op.stringValue())endifif notbody: subExpression->sum() + operand->sum()

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Intended to Produce

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

    How does the isIntegral determine the intent of the expression. It can only determine if the expressions produces an integer. Redefine

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Bad Description, observation has no value

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

    Bad description; observation has no value.

    Suggest:

    Observation specifies the event or events observed to determine a TimeExpression or Duration.

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Like to overridden definition

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

    In e.g. LiteralInteger and LiteralNull on p 91 (and the rest)there is no hyperlink from isComputable() to the overridden definition and indeed no qualified name to aid manual navigation.
    Consider
    Move 6 versions of isComputable() to LiteralSpecification.

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Why can’t the operand be a stringExpression

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

    Too many 'all's; remove all in front of all the component values.

    Suggest just: ... concatenating the ordered String values of each operand or subExpression.

    Simpler body: if subExpression->notEmpty()then subExpression->iterate(se; stringValue: String = '' | stringValue + se.stringValue())else operand->iterate(op; stringValue: String = '' | stringValue + op.stringValue())endifif notbody: subExpression->sum() + operand->sum()

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Range Confusion

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

    'range' is a bit confusing again. Use 'intervening distance', so that (temporal) distance is a consistent terminology.

    Use 'larger ValueSpecification' or 'ending ValueSpecification' rather than 'maximum value of the range'

    Use 'smaller ValueSpecification' or 'starting ValueSpecification' rather than 'minimum value of the range'

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Simplify (Location: 8.6 p 97 TimeExpression)

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

    The worded requirement should be in OCL, possibly deferring the issue to a clear definition of isConstant().

    expr <> null and observation->isEmpty() implies expr->isConstant()

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Bad Description

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

    Unnecessarily wordy suggest just:

    An OpaqueExpression specifies the computation of a set of values either in terms of a UML Behavior or a textual expression in some language.

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Simplify

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

    firstEvent[i] is true to select the enter, or false to select the exit event to constrain execution of the constrainedElement.

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

What incompatible about sub-expressions and operands

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

    The problem seems solvable

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Add condition : Constraint[0..1] to the include relationship

  • Key: UMLR-432
  • Legacy Issue Number: 18857
  • Status: open  
  • Source: Learning Tree International ( Brett Martensen)
  • Summary:

    The extend relationship is not intuitive to most users of UML.

    Add the condition:Constraint[0..1] and extension point (renamed as branch point) as an optional property of the include relationship and remove the extend relationship from the specification.

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

Definition of invariant condition

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

    This is not the normal interpretation of invariant conditions, and I believe it has no support in UML 2.4.1. The typical definition for invariant condition is that it must be true (it must hold) whenever it is checked, pre, post, and during. However, it need not hold while the object is not at a stable point and not query-able (not inspectable), but it must be true when and if the condition can be checked (by normal means). In an environment with multi-threading, this is often done with locks of some sort.

  • Reported: UML 2.4.1 — Tue, 25 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section Unbalanced

  • Key: UMLR-597
  • Legacy Issue Number: 17762
  • Status: open  
  • Source: Thematix Partners LLC ( Dr. Doug Tolbert)
  • Summary:

    The section needs some introductory material. What's here is good, useful and interesting stuff, but its purpose and why it's located at this point in the spec is not sufficiently motivated. The material presented is also somewhat unbalanced. For example, §6.3.1 calls out three model element categories: Classifiers, Events, and Behaviors. Then §6.3.3 contains some nice text on semantics of Behaviors, but nothing further is said about Classifiers or Events. Suggest some text for the two missing categories should be added – if they are important enough to mention, they deserve discussion.
    Proposed Resolution: Add described text.

  • Reported: UML 2.4.1 — Tue, 25 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Need table correlating Literals with symbols (+,-,#,~)

  • Key: UMLR-592
  • Legacy Issue Number: 17815
  • Status: open  
  • Source: Lockheed Martin ( John Watson)
  • Summary:

    There does not seem to be anywhere where there is any coorelation between the symbols and their meaning. If anything, it would be useful here.

    Throughout the document, readers are referred to 7.4 (where the enumerations) is defined, but that doesn’t help us to know what +, - … mean.

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Inconsistent use of (s)

  • Key: UMLR-593
  • Legacy Issue Number: 17807
  • Status: open  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    Sometimes a property with upper bound > 1 is referred to as having "Elements", for example, and sometimes "Element(s)". Dependency::client, Dependency::supplier, DirectedRelationship::source, DirectedRelationship::target all use the latter whereas ElementElement::ownedComments and Constraint::constrainedElements use the former. I'm sure there are many other examples. I think the former is better stylistically. (For what it's worth, Oracle's corporate documentation standards regard the use of parenthesized plurals as bad practice.)

    Proposed Resolution:

    Consistently use plurals rather than plural(s).

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section 11.7 has no content or notation for template Collaborations Clause - 11: Structured Classifiers

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

    Section 11.7 has no content or notation for template Collaborations. There was material in UML 2.4 section 17.4.7 about these.

  • Reported: UML 2.4.1 — Tue, 25 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section 11.3.4 isService clarification - Clause 11: Structured Classifiers

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

    Section 11.3.4 says “A Port of an EncapsulatedClassifier is shown as a small square symbol”. Does this perhaps only apply to Ports for which isService is true? The definition of isService would certainly seem to imply that a Port marked with isService = false would not appear on parts, for example. RSA hides the port when you make isService = false.

  • Reported: UML 2.4.1 — Tue, 25 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Descendants rather than specializations

  • Key: UMLR-596
  • Legacy Issue Number: 17778
  • Status: open  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    The Elements and Relationships sections both use the term "Descendants". Surely the term used here should be Specializations? I suspect this may be more widespread than just this section (7.2.4 contains another example).

    Proposed Resolution:

    Use specialization rather than descendants.

  • Reported: UML 2.4.1 — Tue, 25 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section 11.2.4 clarification - Clause 11: Structured Classifiers

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

    Section 11.2.4 says “Detail may also be shown within the part box indicating specific values for Properties of the part’s type when instances corresponding to the Property are created.” What does this mean?

  • Reported: UML 2.4.1 — Tue, 25 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

List attributes whose ordered property has change in UML 2.5

  • Key: UMLR-600
  • Legacy Issue Number: 17760
  • Status: open  
  • Source: Thematix Partners LLC ( Dr. Doug Tolbert)
  • Summary:

    Summary: As an aid to tool vendors, can properties whose

    {ordered}

    status has been changed be identified in the text or listed here?
    Proposed Resolution: Add described text.

  • Reported: UML 2.4.1 — Tue, 25 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Bound Element Semantics overly specific

  • Key: UMLR-598
  • Legacy Issue Number: 17782
  • Status: open  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    Point 2 ("If the copy...") seems to be overly specific for this section. Shouldn't this information be part of the Generalization and Operation semantics?

  • Reported: UML 2.4.1 — Tue, 25 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML 2.5 FTF issues for Clause 18: UseCases

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

    The condition of an Extend is a Constraint. What are its constrainedElements?

  • Reported: UML 2.4.1 — Tue, 25 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Template Notation example

  • Key: UMLR-594
  • Legacy Issue Number: 17783
  • Status: open  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    This could really do with a graphical example.

  • Reported: UML 2.4.1 — Tue, 25 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Clarification on the semantics of CommunicationPath

  • Key: UMLR-615
  • Legacy Issue Number: 17591
  • Status: open  
  • Source: THALES ( Hugues Vincent)
  • Summary:

    Title: Clarification on the semantics of CommunicationPath
    Where: section 19.4.3
    Nature of Issue: Clarification
    Severity of Issue: Minor
    Full Description of the Issue:
    The semantics of CommunicationPath is poorly defined: what is a 'specific communication path'? A wire, a protocol used...?

  • Reported: UML 2.4.1 — Thu, 13 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

isIntegral()

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

    Wouldn’t it be a better name to have the operation called isInteger?

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Capitalization of dependency

  • Key: UMLR-613
  • Legacy Issue Number: 17803
  • Status: open  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    "dependency" should be "Dependency"

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Node::nestedNode should subset Class::nestedClassifier, not Namespace::ownedMember.

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

    The way it is modeled now, a Node’s nested nodes will not appear in its nestedClassifier property, which must be wrong.

  • Reported: UML 2.4.1 — Wed, 10 Oct 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Meaning of State in ProtocolStateMachines

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

    Category: Minor

    In the section on “State in ProtocolStateMachines” it is stated:

    “The States of ProtocolStateMachines are exposed to the users of their context Classifiers. A protocol State represents an exposed stable situation of its context Classifier: When an instance of the Classifier classifier is not processing any BehavioralFeature invocation, users of this instance can always know its state configuration. ”

    This does not seem to make sense, at least for declarative protocol state machines – they do not have a run-time manifestation, so it is not clear what it means for the state of such a machine to be “exposed to collaborators”.

  • Reported: UML 2.4.1 — Wed, 10 Oct 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Should “completion” event be an explicit event type?

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

    Category: Minor

    Should a completion event described in the StateMachines chapter be defined as an explicit event type like ChangeEvent, etc.? If so, then it should be discussed in the Commo Behaviors clause as well.

  • Reported: UML 2.4.1 — Wed, 10 Oct 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Not clear if “else” keyword is defined for State Machines

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

    Category: Minor

    The 2.5 spec says:

    “As a way of avoiding this situation in some cases, it is possible to associate a predefined guard denoted as “else” with at most one outgoing Transition”

    The formal specification of the “else” keyword is not given (presumably maps to a Constraint that is the conjunctive negation of all the other Constraints)

  • Reported: UML 2.4.1 — Wed, 10 Oct 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

State of the substates of the history state

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

    Category: Clarification

    The 2.5 spec says:

    “Shallow history entry: If the incoming Transition terminates on a shallowHistory Pseudostate of the composite State, the active substate becomes the substate that was most recently active prior to this entry,”

    It is not clear what the ``state`of the substates of the history state are.

  • Reported: UML 2.4.1 — Wed, 10 Oct 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

It is a pity that UML does not provide the ability for Messages to correspond directly to property accesses and updates

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

    It is a pity that UML does not provide the ability for Messages to correspond directly to property accesses and updates

  • Reported: UML 2.4.1 — Fri, 24 Aug 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Meaning of absent multiplicity notation

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

    The UML 2.5 beta does not appear to take a clear position on what it means when the multiplicity is omitted from the notation for an element, although there are many places in the spec itself where multiplicity is absent.

  • Reported: UML 2.4.1 — Wed, 10 Oct 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Figure 14.39 – missing superclass

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

    Category: Minor

    The diagram for ProtocolStateMachines does not show the superclass of ProtocolConformance; it should in line with the general convention for such abstract syntax diagrams

  • Reported: UML 2.4.1 — Wed, 10 Oct 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Not clear when to use ExecutionOccurrenceSpecification with ExecutionSpecification

  • Key: UMLR-517
  • Legacy Issue Number: 18037
  • Status: open  
  • Source: Oracle ( Darren Kumasawa)
  • Summary:

    Location:
    Page #607, 17.2.3 Semantics, Execution Specifications
    Page #619, 17.5.3 Semantics, Execution Occurrence Specifications
    Title: Not clear when to use ExecutionOccurrenceSpecification with ExecutionSpecification

    Summary:
    Page #607, 17.2.3 Semantics, Execution Specifications
    "Typically the start occurrence and the finish occurrence will represent OccurrenceSpecifications such as a receive OccurrenceSpecification (of a Message) and the send OccurrenceSpecification (of a reply Message)."

    Page #619, 17.5.3 Semantics, Execution Occurrence Specifications
    "A ExecutionOccurrenceSpecification represents, on a lifeline, the start event or the end event of an ExecutionSpecification."

    When should ExecutionOccurrenceSpecifications be used as start and finish of ExecutionSpecification, and when should Message/Destruction OccurrenceSpecifications be used instead? The ExecutionOccurrenceSpecification is the only one that has a reference back to ExecutionSpecification. Is there a guideline of when to use one over the other?

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: Pg. 617, Figure 17.4.4: Notation, Sub-clause: Message

  • Key: UMLR-518
  • Legacy Issue Number: 18036
  • Status: open  
  • Source: Delligatti Associates, LLC ( Mr. Lenny Delligatti)
  • Summary:

    Title: Incorrect specification of the notation for a reply message.
    Summary:
    This clause states, “A reply Message (messageSort equals reply) has a dashed line with a filled arrow head.” A reply message has an open arrow head as shown in the usage example in Figure 17.14.

    Proposed Resolution: Replace “…filled arrow head” with “…open arrow head” in the excerpted sentence.

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

18.1.3 Semantics Use Case and Actors Extends P. 687 - No Alternative Path

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

    current text: Once a given fragment is completed, execution continues with the behavior of the extended UseCase following the ExtensionPoint.

    This means that inserting an extension UC can't ever supply alternative behavior to the base use cases, but can only supply additional behavior. This is contrary to the vast majority of practice.
    In addition, it prevents extension use cases from being used for exception handling where the behavior ends in the extension.

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

18.1.3 Semantics Use Case and Actors Extends P. 687 - First ExtensionPoint

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

    current text: ”If the condition of the Extend is true at the time the first ExtensionPoint is reached during the execution…

    It is a bit unclear whether “first” means the first of extensionPoints in the

    {ordered}

    extensionLocation list or the first that is reached in the particular execution path.

    Please clarify

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: 18.1.3 Semantics Use Cases and Actors P. 686 - What classifiers can be a subject?

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

    current text: “The subject of a UseCase could be a system or any other element that may have behavior, such as a Component, subsystem, or Class”

    The restriction on behavior elements is not clear.

    This limits subjects to element that may have behavior. There is no OCL to enforce this. Is this only BehavioredClassifiers? Can a UseCase be the subject of usecase?

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: 18. Global - No discussion of use case instances

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

    Need some discussion on the use and limitations of use case instances

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: 18.1.3 Semantics Use Cases and Actors P. 686 - Multiplicity at Use Case end

  • Key: UMLR-511
  • Legacy Issue Number: 18054
  • Status: open  
  • Source: Soluta.net ( Adriano Comai)
  • Summary:

    current text: “When an Actor has an association to a UseCase with a multiplicity that is greater than one at the UseCase end, it means that a given Actor can be involved in multiple UseCases of that type.”

    [AC] This relationship between Actors and UseCases is asymmetric and in my opinion inconsistent. When a UseCase has a upper multiplicity >1 towards Actor, this means that multiple instances of Actor are involved. At the opposite end, the meaning is undetermined. This should be avoided in a metamodel definition. It would surely be less ambiguous to state that the upper multiplicity from Actor to UseCase is just 1.

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

18.1.3 Semantics Use Case and Actors Extends P. 687 - Show name of extension

  • Key: UMLR-510
  • Legacy Issue Number: 18056
  • Status: open  
  • Source: Soluta.net ( Adriano Comai)
  • Summary:

    current text: “Extend is a kind of DirectedRelationship, such that the source is the extending UseCase and the target is the extended UseCase. It is also a kind of NamedElement so that it can have a name in the context of its owning UseCase.”

    [AC] I can infer that the owning UseCase is the extending UseCase, but I think this should be stated again, to avoid misunderstandings. It could be also useful to give an example, with a specific figure, of a naming of the extend relationship.

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location:Page #640, 17.8.2 Example Sequence Diagram

  • Key: UMLR-514
  • Legacy Issue Number: 18040
  • Status: open  
  • Source: Oracle ( Darren Kumasawa)
  • Summary:

    Title: Need more complicated Example Sequence Diagram

    Summary:
    Section 17.8.2 should include an example of a more complicated Sequence Diagram that includes BehaviorExecutionSpecification, ExecutionOccurrenceSpecification and CombinedFragment metamodel elements. It is unclear how these elements should be ordered in the "fragment" set of the Interaction. See diagram 17.14 for an example that would be useful to see the metamodel elements depicted.

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: 18.1.3 Semantics Use Cases and Actors P. 686 - Multiple subjects require the same actors

  • Key: UMLR-512
  • Legacy Issue Number: 18052
  • Status: open  
  • Source: Soluta.net ( Adriano Comai)
  • Summary:

    current text: “The same UseCase can be applied to multiple subjects”.

    [AC] I would add: “if, and only if, it is associated with the same actors”. Otherwise, it would be possible to have an inconsistent “reuse” of use cases, with a different set of actors in each context.

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

18.1.3 Semantics Use Case and Actors Extends P. 687 - Single Location

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

    current text: “All of the behavior of the included UseCase is executed at a single location in the included UseCase before execution of the including UseCase is resumed.

    It appears that it’s not possible (or unclear how) to insert the same included Use Case in multiple locations in the base (including) use case. Surely this is possible.

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: weak sequencing p. 622

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

    Need better explanation and examples

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

What is a DurationConstaint

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

    I've read the description of firstEvent four times and I still do not understand it. Rewrite so there is a simple if/else that avoids the need to do detailed comparison between two very similar sentences.

    Suggest:

    A DurationConstraint is a Constraint that refers to a DurationInterval. which may be the interval between execution entering and exiting a single constrained element, or between selectable enter/exit events on a pair of constrained elements.

    ...
    When there are two constrainedElements, firstEvent[i] is true to select the enter, or false to select the exit event for execution of the corresponding constrainedElement.

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Time constant

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

    Time constant means something else to me.
    Suggest: constant time value

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

More detail on Express

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

    What is a symbol? Suggest: a symbol such as "+" may be used to define the functionality of a particular expression node.

    Are there any semantics for the inherited name? Suggest: the inherited name may be used to give distinct identifications to expression nodes.

    Are there any semantics for the inherited type? Suggest: the inherited type may be used to identify the type resulting from evaluation of the expression node.

    What type should be used for a set of values? Suggest: a domain-specific type system may be appropriate to represent a richer or more specific variety of values than can be modeled directly in UML.

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Expression examples unclear

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

    These are unclear. How many Expression nodes in "plus(x,1)"? Is "xor" well-formed without arguments?

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

OCL not indexed

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

    Index OCL

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Semantics Clarification

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

    What are the relative semantics of 'symbol' and 'name'? What are the relative semantics of 'type'?

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Event

  • Key: UMLR-587
  • Legacy Issue Number: 17836
  • Status: open  
  • Source: INCOSE ( Sanford Friedenthal)
  • Summary:

    Should there be a specific metaclass for event that DurationObservation and TimeObservation refer to.

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

incompatible multiplicities

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

    It defines a symbol is inconsistent with the [0..1] multi

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

one -- > first

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

    the first NamedElement is better than one event Element

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Orphan Title

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

    Orphan title. Use Keep with Next style

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: Pg. 613, Figure 17.6 - : Incorrect multiplicities in the metamodel in Figure 17.6

  • Key: UMLR-521
  • Legacy Issue Number: 18030
  • Status: open  
  • Source: Delligatti Associates, LLC ( Mr. Lenny Delligatti)
  • Summary:

    The multiplicity shown for “coveredBy : InteractionFragment” is “”. However, I believe the lower multiplicity should be 1, not 0. A lifeline can only exist within an Interaction; it cannot exist independently. This is affirmed by the multiplicity of “1” shown in this figure for the end “interaction : Interaction”. And an Interaction is a type of InteractionFragment as we see in the metamodel in Figure 17.1. Therefore, an instance of Lifeline must always know at least one instance of InteractionFragment: the Interaction that owns it. And thus, the multiplicity for “coveredBy : InteractionFragment” should be “1..”, not “*”.

    Proposed Resolution:
    Change the multiplicity for the end “coveredBy : InteractionFragment” to “1..*”

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: p 611

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

    The notation in Figure 17.5 does not match the almost identical diagram of Figure 8.5

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Not clear when to use ExecutionOccurrenceSpecification with ExecutionSpecification

  • Key: UMLR-524
  • Legacy Issue Number: 18024
  • Status: open  
  • Source: Oracle ( Darren Kumasawa)
  • Summary:

    Location:
    Page #607, 17.2.3 Semantics, Execution Specifications
    Page #619, 17.5.3 Semantics, Execution Occurrence Specifications

    Summary:
    Page #607, 17.2.3 Semantics, Execution Specifications
    "Typically the start occurrence and the finish occurrence will represent OccurrenceSpecifications such as a receive OccurrenceSpecification (of a Message) and the send OccurrenceSpecification (of a reply Message)."

    Page #619, 17.5.3 Semantics, Execution Occurrence Specifications
    "A ExecutionOccurrenceSpecification represents, on a lifeline, the start event or the end event of an ExecutionSpecification."

    When should ExecutionOccurrenceSpecifications be used as start and finish of ExecutionSpecification, and when should Message/Destruction OccurrenceSpecifications be used instead? The ExecutionOccurrenceSpecification is the only one that has a reference back to ExecutionSpecification. Is there a guideline of when to use one over the other?

    Source: darren.kumasawa@oracle.com

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location p413 Final Node - Rollback behavior

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

    Consider adding a «rollback» region that is automatically executed if the parent is canceled.

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location p413 Final Node - Atomic behavior

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

    It is often necessary to prevent an ActivityFinalNode from terminating behavior in the middle.
    We recommend the creation of a stereotype for an Activity or Action, such as «atomic» which indicates that reaching an ActivityFinalNode on the diagram will allow the behavior to finish, but that no output tokens are emitted when this occurs.

    This prevents some sorts of inconsistency that can occur when cancelling.

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: 17.3.4 Notation Lifeline p 613 - Specification of color

  • Key: UMLR-519
  • Legacy Issue Number: 18033
  • Status: open  
  • Source: Delligatti Associates, LLC ( Mr. Lenny Delligatti)
  • Summary:

    Description: This clause states, “ExecutionSpecifications are represented as thin rectangles (grey or white) on the lifeline.” However, this is inconsistent with the idea that UML does not prescribe color for notations

    Proposed Resolution: In place of references to color, we should stick with the convention of using the terms “hollow” to mean the same color as the diagram background and “solid” to mean the same color as the boundary of the node or the path notation. In the case of overlapping notations (e.g. ExecutionSpecifications), perhaps the spec. can prescribe patterns (e.g. cross-hatch) instead of color.

    Source: Lenny Delligatti
    Discussion:

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: Pg. 613, Figure 17.6 - Incorrect multiplicities in the metamodel in Figure 17.6

  • Key: UMLR-520
  • Legacy Issue Number: 18031
  • Status: open  
  • Source: Delligatti Associates, LLC ( Mr. Lenny Delligatti)
  • Summary:

    The multiplicity shown for both ends named “covered” of type “Lifeline” is “*”. The multiplicity for both of these ends should be “1” to match the metaclass entries for “OccurrenceSpecification” and “StateInvariant”. Both entries show that these two metaclasses each have an association “covered : Lifeline [1]”. And “1” is the intuitively correct multiplicity; an instance of OccurrenceSpecification (e.g. send, receive, start, end, destruction) can only be associated with a single lifeline. And an instance of StateInvariant is placed on a single lifeline.

    Proposed Resolution:

    Change the multiplicity for both of the ends “covered : Lifeline” to “1”.

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Interactions p 607

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

    Current text:
    The invalid set of traces is associated only with the use of a Negative CombinedInteraction. For simplicity we describe only valid traces for all other constructs

    This is not quite true
    1) An assert declares all non-compliant traces as invalid
    2) It may also be possible to use consider on normal trace where the message to be considered is not in the trace to indicate that if it occurs it is invalid.
    3) It is also possible to declare invalid traces with state invariants. For example, imagine a constraint such as

    {1=2}

    Source: Michael Jesse Chonoles

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: 16.2.3 Semantics / Opaque Actions

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

    Detail:
    Why restrict OpaqueActions to textual concrete syntax, when other approaches are possible.

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: Figure 15.67 page 436

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

    Detail:
    Show notation to indicate specific partitions for control nodes

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: p 504 - Marshall Actions

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

    Why aren’t there Marshall Actions

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Issue for UML 2.5 FTF against Clause 9: Classifiers

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

    Section 9.6.4. There is no notation for raisedException. Can we add a notation?

  • Reported: UML 2.4.1 — Tue, 25 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: Page 265, 12.2.3 Semantics - Unchanged URIs

  • Key: UMLR-557
  • Legacy Issue Number: 17949
  • Status: open  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    "The URIs should hence be unique and unchanged once assigned." The UML metamodel changes its URI with every release. I think the UPDM profile used the same URI for multiple packages/profiles. Both of which conflict with the specification statement

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: 12.2.3 Semantics Package p 265 - Reference to unknown section heading

  • Key: UMLR-555
  • Legacy Issue Number: 17948
  • Status: open  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    The reference "(see Using XMI to Exchange Profiles in section Profile)", isn't using a known section heading and doesn't give a relevant section number.

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: 9.6.4 Notation p 127 Missing Infix operation syntax / discussion

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

    Location: 9.6.4 Notation p 127 Missing Infix operation syntax / discussion

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

ParameterSet Notation

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

    Notation for parameterset in a standard operation calls is very needed. If parametersets are used in an activity diagram, it may not be possible to match this up with an operation on the class, either in a list of operations or from a sequence diagram

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: constraints class_behavior p.190

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

    current text:
    If a behavior is classifier behavior, it does not have a specification

    Why is this so. How do you handle classifier behavior that has parameters (sometime called object behavior). It’s usually started by the constructor.

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location 10.3.3 Receptions p.186 - exceptions for receptions?

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

    Can’t receptions have out exceptions?

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

p 118: isException and other outputs

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

    An output posted to a Parameter with isException true during an invocation of a BehavioralFeature excludes outputs from being posted to any other outputs of the BehavioralFeature during the same invocation.

    This does not seem to match description of how exception handlers work later. I would rewrite it:

    Proposed text:
    An output may be posted to a Parameter with isException true during an invocation of a BehavioralFeature. When this occurs, unless an ExceptionHandler catches the exception, other outputs are not posted from the BehavioralFeature during the same invocation. When an ExceptionHandler catches the exception, outputs are posted from the BehavioralFeature at the level of the ExceptionHandler.

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: Constraints p 193 - All feturs must be public?

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

    Why
    An interface should be allowed to have not public proprieties/attributes. These are necessary to have them referred to in the protocol state machine, but they need not be public attributes, i.e., no direct or query-based access to their values from he outside. They need to be there to allow for a consistent description of the state-based behavior.

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location p 162 ParameterSet associationends: Exceptions and parametersets

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

    Throughout the specification, output parametersets are described as if all (non-optional) output parameters within the set are output. This is not exactly right if the parameterset contains an exception. Please describe how that works and make the document consistent

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: 12.1 Packages Summary p 264

  • Key: UMLR-558
  • Legacy Issue Number: 17947
  • Status: open  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    Summary:

    "Models...which organize extensions to UML." suggests that Models contain extensions, which I don't think is true.

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: Figure 11-5 (ii) p 204

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

    How do we show that each engine has 2 connections to each Wheel, as opposed to two in total?

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Query of alternative scopes?

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

    It should be possible within UML to query which of the alternative semantics apply.

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Problems with XMI IDs in the UML 2.5 UML.xmi file

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

    In the case of a derived, non-union attribute for which there is a corresponding derivation operation with the same name, the XMI IDs of one or the other of the attribute or the operation are incorrect in the UML 2.5 Beta 1 UML.xmi file (that is, inconsistent with what the IDs were in UML 2.4.1). For example, the XMI ID for the attribute NamedElement::qualifiedName is AcceptCallAction-qualifiedName. The XMI ID for the operation Namespace::importedMember is ConditionalNode-importedMember. Worse, the XMI IDs of the attribute Connector::kind and the operation Connector::kind are both the same, Connector-kind.

  • Reported: UML 2.4.1 — Fri, 5 Oct 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

17 Semantics of interactions

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

    17 Semantics of interactions (missing constraints for resolving Operations, Signals and Actions in MessageOccurrenceSpecifications & ExecutionOccurrenceSpecifications in the scope of the Interaction itself)
    Consider Figure 17.2 (in the UML2.5 Revised August draft):

    Clearly we expect that:

    "oper1()" is a Message whose Message::signature refers to A::oper1()

    "callback()" is a Message whose Message::signature refers to C::callback()

    However, there is nothing in the spec that constrains the ownership of a Message::signature : NamedElement relative to the Interaction context of that Message.

    In fact, other possible interpretations because UML does not prescribe a particular resolution process for determining the Behavior for a given BehavioralFeature or Reception (see section 13.2.3)

    The spec does not currently specify any kind of bound on this resolution process — that is, Behaviors could be found potentially anywhere in the model.

    This is obviously absurd: it is unreasonable to expect that Figure 17.2 corresponds to a model where neither A nor C define "oper1()" or "callback()" but rather that these 2 operations are defined in an completely unrelated class not involved in the interaction at all – e.g., B.

  • Reported: UML 2.4.1 — Tue, 2 Oct 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML Interactions do not provide the ability for Messages to correspond directly to property accesses and updates

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

    It is a pity that UML Interactions do not provide the ability for Messages to correspond directly to property accesses and updates

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: B.6 UML ProfileDiagrams . 768 - Profile Diagram Elements

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

    Wouldn’t this be the «profile» Package being modeled?

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: B.6 UMLClass Diagram P. 757 - Class namespace diagrams?

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

    if I'm using a class diagram to show the namespace structure of a class (not the composite structure), wouldn't that classdiagram have a modelElement, that of the owning class

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Overriding deferred events

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

    Category: Minor

    The 2.5 spec says:

    “Event occurrences remain in the event pool until:

    · a state configuration is reached where these Event types are no longer deferred or,

    · if a deferred Event type is used explicitly in a Trigger of a Transition whose source is the deferring State (i.e., a kind of override option)

    It is not clear if the override capability extends inside the deferring State or only on the outside. The latter option was chosen in the spec, since it would be difficult to spot the override if it occurred inside the deferring state. But….

  • Reported: UML 2.4.1 — Wed, 10 Oct 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Stable state not needed

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

    Category: Minor

    The 2.5 spec says:

    “A state configuration is said to be stable when:

    · no further Transitions from that state configuration are enabled and

    · all the entry Behaviors of that configuration, if present, have completed (but not necessarily the doActivity Behaviors of that configuration, which, if defined, may continue executing”

    I believe that the concept of a stable state configuration is not necessary, since all state configurations are, by definition, stable. I cannot think of a transient one

  • Reported: UML 2.4.1 — Wed, 10 Oct 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: Annex C Keywords P. 778 - Inconsistent metaclass keywords

  • Key: UMLR-491
  • Legacy Issue Number: 18115
  • Status: open  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    There a number of keywords that are used when the same notation is used for multiple metaclasses. These aren't derived from the name of the metaclass in a consistent manner. For example, centralBuffer for CentralBufferNode, deployment spec for DeploymentSpecification, substitute for Substitution.

    Stereotypes are now given as their exact name, without transliteration or abbreviation. Should the same approach be used for metaclasses?

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Default entry if default history transition missing

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

    Category: Minor

    The behavior in case of a default entry when the default history transition is missing was not specified; The following option was added in 2.5, but needs to be checked by vendors:

    “If no default history Transition is defined, then standard default entry of the State is performed”

  • Reported: UML 2.4.1 — Wed, 10 Oct 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: B.2.2 P. 738 - What ISO document

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

    Explain which document

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: Page 270/271, 12.2.3 Semantics - Model description confusing

  • Key: UMLR-549
  • Legacy Issue Number: 17956
  • Status: open  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    The description of Model uses viewpoint, vantage point and perspective. I realise these are synonyms but they don't really all need to be used here. Just use viewpoint as that is the attribute name. A Model is a view, but that isn't mentioned until the third paragraph. Really that should be in the first paragraph. Abstraction is also used giving the impression that it is something distinct from the viewpoint. However surely the viewpoint defines the level of abstraction. It might be a good idea to the define the terms viewpoint and view first of all and then show how Model relates to them.

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: Page 269, 12.2.3 Semantics - Association merge aggregation constraint is property rule

  • Key: UMLR-550
  • Legacy Issue Number: 17955
  • Status: open  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    Association Rules, Constraints 2 is a property rule so ought to appear there. The property rules ought to say something about shared aggregation too.

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: Page 286, 12.3.3 Semantics - Incorrect if statement

  • Key: UMLR-545
  • Legacy Issue Number: 17961
  • Status: open  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    "If the value is the name of a NamedElement..." doesn't make sense as the name is a string and doesn't have a qualified name.

    Proposed Resolution:

    Replace with:

    "If the value is a NamedElement..."

    Revised Text:
    Source: dave.hawkins@oracle.com

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: Page 285, 12.3.3 Semantics - Old behavior unnecessarily preserved

  • Key: UMLR-544
  • Legacy Issue Number: 17960
  • Status: open  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    "Matching between the names of Stereotype definitions and applications is case-insensitive, so naming stereotype applications with lower-case letters where the stereotypes are defined using upper-case letters is valid, although stylistically obsolete."

    What does matching actually mean here? I think this should really just say that the correct way to display stereotype names is exactly as they are in the model.

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 269, 12.2.3 Semantics - Property merge transformation conflicts with constrain

  • Key: UMLR-552
  • Legacy Issue Number: 17953
  • Status: open  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    Property Rules, Constraints 2 means that Transformations 7 is either wrong or unnecessary

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: Page 267, 12.2.3 Semantics - Type and TypedElement confusion

  • Key: UMLR-553
  • Legacy Issue Number: 17952
  • Status: open  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    General Package Merge Rules, Transformations 4 is round the wrong way. A TypedElement references a Type not the other way round. I suspect this rule shouldn't say anything about types at all. It should just be "All references to elements...resulting Elements..."

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: Page 265, 12.2.3 Semantics PackageMerge - Long-winded package merge description

  • Key: UMLR-556
  • Legacy Issue Number: 17950
  • Status: open  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    The paragraph starting "A PackageMerge can be viewed..." is a bit long-winded and contains lots of parentheses.

    Proposed Resolution:

    Simplify text, removing parentheses:

    A PackageMerge can be viewed as a set of transformations whereby the contents of the merged Package and the receiving Package are combined. Matching elements are merged into a single resulting element according to the formal rules of PackageMerge specified below. This is akin to “copying down” the features of superclasses into a subclass: the fully expanded subclass is the equivalent to the resulting package

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: Page 281, 12.3.3 Semantics - Duplicated text

  • Key: UMLR-546
  • Legacy Issue Number: 17959
  • Status: open  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    The "Defining Profiles for Non-UML Metamodels" section seems to duplicate the "Restricting Availability of UML Elements" section (which also has the wrong heading style). Surely this could just be done as a single block of text that describes the filtering rules in general and then gives a specific example using the UML metamodel, while stating that in theory other metamodels could be extended.

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 266, 12.2.3 Semantics - Un-matched resulting elements aren't always the same

  • Key: UMLR-554
  • Legacy Issue Number: 17951
  • Status: open  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    The "resulting element" is described as being the same when no match exists. However this isn't strictly true. References from the element may be updated to other resulting elements

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: Page 280, 12.3.3 Semantics - Note should be main text

  • Key: UMLR-548
  • Legacy Issue Number: 17957
  • Status: open  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    "[Note: ...]"

    I don't see why this is a note, it should just be a normal bit of text.

    Proposed Resolution:

    Remove "[Node:" and "]" keeping the note text.

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: Page 269, 12.2.3 Semantics - Property merge rule pointless

  • Key: UMLR-551
  • Legacy Issue Number: 17954
  • Status: open  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    Property Rules, Transformations 5 doesn't really do anything. It should probably be specifying the value of isDerivedUnion

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: Page 280, 12.3.3 Semantics - Poorly indented XMI

  • Key: UMLR-547
  • Legacy Issue Number: 17958
  • Status: open  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    The XMI for the HomeExample profile has variable indenting and unaligned XML open/close elements.

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: Page 286, 12.3.3 Semantics - Nonsensical alternative to stereotype name

  • Key: UMLR-543
  • Legacy Issue Number: 17962
  • Status: open  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    An alternative name is given for stereotypes:

    "If the ExtensionEnd is given a name, this name can be used in lieu of the stereotype name within the pair of guillemets when the stereotype is applied to a model element."

    Earlier, the specification of the extension end name is given as "extension_stereotypeName" so this is a rather bizarre option. When would this ever make sense?

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: p 410

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

    Show how to pass activities around

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: Page 328, 14.2.3 - UseCase cannot be the context of a StateMachine

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

    “If the StateMachine has a kind of BehavioredClassifier context, then that Classifier defines which Signal and CallEvent triggers
    are applicable”. A UseCase is a BehavioredClassifier and thus would be the context of a Statemachine. Since a UseCase cannot have Signal receptions or operations no such triggers would be applicable to this StateMachine.

    Proposed Res
    The radical solution would be to make UseCase not a BehavioredClassifier. However this would be out of scope. Therefore the next sentence should be changed:
    “If the StateMachine has no BehavioredClassifier context or this context is a UseCase…”

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: Signal Receipt symbol

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

    What is the motivation for the limitation on not have time events, or call events here

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: Page 346, State List Notations - Why must state lists be effect free?

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

    Why must they be effect-free? If all the transitions have the same effect, it would be easily understandable

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: 13.3.5 Examples p 314

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

    Explain why there are no examples

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: Opaque and Function Behaviors p 308

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

    Detail: Why limit OpagueBehavior to a textual specification. It seems to me that any language other than UML, including graphical languages would be opaque for this purpose.

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: p. 336 Compound transitions - Run-to-completion Paradigm

  • Key: UMLR-533
  • Legacy Issue Number: 17999
  • Status: open  
  • Source: University of Texas ( Omar Badreddin)
  • Summary:

    It should be stated that a do-activity is the exception here. Also, code within the do activity should be prevented from updating the state machine configurations or firing of events (directly or indirectly).

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: Page 316 redefinedBehavior - Extends

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

    What does “extends” mean in this context. Is it the extends of use cases? Or statemachines? Or profiles? I don’t believe it is defined clearly

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: Page 331 deep history entry - Default deep history entry

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

    Shouldn’t there be a default deep history transition. See p. 374.

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: Figure 12-13 p.281 - Incorrect use of << for «.

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

    Figure 12-13 has interface titled <<Home>> it should be «Home»

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

How to model a transition to history pseudostates in two orthogonal regions?

  • Key: UMLR-610
  • Legacy Issue Number: 17596
  • Status: open  
  • Source: self-employed ( Volker Spinke)
  • Summary:

    A transition that terminates on the outside edge of a composite state is called a default entry. In this case, the default entry rule is applied e. g. the transition originating from the initial pseudostate is performed. If the most recently active substate prior to this entry shall become the active substate, the transition must be drawn to a history pseudostate. Page 564 clearly states this.

    Next, the composite state is extended to an orthogonal state with two regions. Both regions contain a history pseudostate. A transition shall fork to both history states. I thought this is easy to model by introducing a fork pseudostate in the transition and drawing two outgoing transitions from the fork to the history pseudostates.

    This is obviously not the case as constraints rule 3 on page 582 states: "A fork segment must always target a state. (source.oclIsKindOf(Pseudostate) and source.kind = #fork) implies (target.oclIsKindOf(State))"

    It is also mentioned at other locations that an outgoing transition of a fork pseudostate must target a state. Pseudostates are not allowed as targets of outgoing transitions from a fork pseudostate.

    I am confused by this rule. My question is: How do I have to model a transition ending on the history states in two orthogonal regions?

    Thanks for your kind advice.

  • Reported: UML 2.4.1 — Mon, 17 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Clarification on the semantics of inheritance between use cases

  • Key: UMLR-612
  • Legacy Issue Number: 17589
  • Status: open  
  • Source: THALES ( Hugues Vincent)
  • Summary:

    Title: Clarification on the semantics of inheritance between use cases
    Where: section 18
    Nature of Issue: Clarification
    Severity of Issue: Minor
    Full Description of the Issue:
    It appears in figure 18-11 as it is implied by the abstract syntax that inheritance among use cases is possible. The semantics of such an inheritance needs to be described.

  • Reported: UML 2.4.1 — Thu, 13 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

OccurrenceSpecification should have at least an optional notation

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

    Until UML 2.3, OccurrenceSpecification (OS) was an abstract superclass for the concrete occurrence specifications MessageOccurrenceSpecificatio (MOS) and ExecutionOccurrenceSpecification (EOS). In UML 2.3 OS became concrete. This apparently subtle change has a significant impact of the usage of domain-specific events in Interaction. A user can now place an OS along a lifeline directly, instead of using using the already existent ActionExecutionSpecification or BehaviorExecutionSpecification. This eases the definition of domain-specific occurrence specifications (let's call it events from henceforth) by defining stereotypes directly for an OS.

    For example, in the UML Testing Profile, there are some test-specific events (e.g. ValidationAction, a sterotype for CallOperationAction) which can be used inside Interaction. Until UML 2.3 the steps for including such a domain-specific actions in Interactions have been the following:

    1. Create an Action and let it being contained by the Interaction
    2. Configure that Action and apply the corresponding stereotype
    3. Create the ActionExecutionSpecification
    4. Create the EOS as the start EOS and link the ActionExecutionSpecification with the EOS
    5.Create the EOS as the finish EOS and link the ActionExecutionSpecification with the EOS
    6. Link the ActionExecutionSpecification with the Action

    The whole procedure involved a lot of very fine-grained and subtled concepts and requires an advanced knowledge of the Interactions metamodel (frankly, only few tools support this complex procedure).

    Since UML 2.4, the steps are reduced to the following one:
    1. Create an OccurrenceSpecification on a lifeline
    2. Apply a stereotype to the OS and configurethe OS

    The stereotyped OS assumes the semantics provided by the domain-specific OS (in UTP ValidationOccurrenceSpecification). This reduces the complexity of integrating such domain-specific events, reduces the memory foorprint and eases the handling and creation of interactions containing such stereotyped OS.

    The problem is that OS does not declare a national representation, and we doubt that this concept will be provided by tools if there is not standardized representation.

    Therefore, we suggest to define a (at least optional) notation for OS as a rectangle or rounded rectangle with a compartment for stereotype visualization and a compartment for an optional label (name of the OS or an expression within the stereotype).

    This change would not affect the XMI or metamodel, but has a significant impact of the way interaction are perceived and created.

  • Reported: UML 2.4 — Thu, 29 Sep 2011 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Message arguments for a Signal signature too restrictive

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

    Constraint 4 of Message in section 14.3.18 requires that in case of a Signal signature, the arguments of the message must correspond to the properties of the Signal.

    We found this constraint too restrictive. A Signal is a classifier, hence it is possible to create an InstanceSpecification for the Signal. A InstanceSpecification can be referenced by an InstanceValue (ValueSpecification) from within the message argument list.

    We suggest to weaken the first sentence of constraint 4 a little from :

    In the case when the Message signature is a Signal, the arguments of the Message must correspond to the attributes of the
    Signal.

    to

    In the case when the Message signature is a Signal, the arguments of the Message must correspond to the attributes of the
    Signal, or to the Signal itself.

  • Reported: UML 2.4 — Thu, 29 Sep 2011 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Relation of message arguments to signature parameters ambiguous

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

    In section 14.3.18, the constraints 3 and 4 say that the arguments of message must correspond to the parameters/properties of the signature (operation/signal). This leads to an ambiguous siuation in some situations. For example:

    Let's assume there is an operation with the following signatur op1(x:String[*], y:String[*]) or a Signal S with two properties
    S::p1 : String[0..1]
    S::p2 : String[0..1]

    Since there is no direct relationship between an argument and a parameter/property it is not possible to determine what argument belongs to the first parameter/property (list in case opf operation example) and what to the second one.

    This problem always occurrs when two parameters/properties of the same type are specified in a sequence and the first one has either an optional multiplicity or an upper bound equals *.

    A possible solution is to introduce an additional metaclass MessageArgumentSpecification, which should be contained by Message instead of ValueSpecification directly, with the following structure:

    MessageArgumentSpecification{
    refersTo: TypedElement [1]

    {where the referenced TypedElement is either an instance of parameter or property}

    arguments : ValueSpecification [1..*]

    {ordered}

    }

    It might be also considerable to keep the association between a referenced element and an argument bilateral. In this case, the association between Message and MessageArgumentSpecification should be ordered.

  • Reported: UML 2.4 — Thu, 29 Sep 2011 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

The included use case is always required for the including use case to execute correctly

  • Key: UMLR-265
  • Legacy Issue Number: 16658
  • Status: open  
  • Source: ivmx.pl ( Michal Kasprzyk)
  • Summary:

    In the 'Descriiption' section of chapter '16.3.5 Include (from UseCases)' there is a sentence:
    'Note that the included use case is not optional, and is always required for the including use case to execute correctly.'

    Interpretation of ‘include’ relationship, implying that it’s usage is valid only if included UC is obligatory for including UC to execute correctly,
    is probably the source of opinion, that the only way to model conditional parts of UC scenario using external UC, is by using ‘extend’ relationship.

    I find such conclusion in many books dealing with analysis/UML, for instance: ' Business Analysis’, page 188 (ISBN-10: 1906124612,ISBN-13: 978-1906124618).

    As a result the difference in aplicability between ‘include’ and ‘extend’ relationship is stressed almost only based on conditionallity of relationship between UC.

    In my opinion it’s valid to use ‘include’ relationship when pointing to another UC, that won’t be executed every time the base UC does.
    It’s just the internal logic of base UC scenario, that decides if it’s appropriate to call external UC or not.
    And if we depend only on result of an external UC, we should use ‘include’ relationship (so most of the time), while when there is a need to introduce its logic we should use ‘extend’ relationship.

    I think, that the sentencje:
    'Note that the included use case is not optional, and is always required for the including use case to execute correctly'
    should be removed or clarified, because if forces analysts to use mostly (if not only) an ‘extend’ relationship, that is far more complicated to use and time consuming to document than ‘include’.

  • Reported: UML 2.4.1 — Thu, 10 Nov 2011 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Abstraction::mapping should be of type ValueSpecification or OpaqueExpression

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

    In many cases, modeler would like to specify the mapping of an Abstraction on an informal level by just providing a LiteralString or OpaqueExpression describing the mapping in a natural language.

    The necessity to use an Expression is for this kind of usage of this feature cumbersome and clunky.

    The resolution could be to use a more common metaclass of Expression, i.e. ValueSpecification, to provide the highest level of flexibility to the modeler, how mappings can be specified.

  • Reported: UML 2.4 — Wed, 14 Dec 2011 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Message arguments should not be contained in a message

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

    Figure 14.4 - Messages in the spec depicts that arguments of a message are contained in that message. This containmentship is not necessary and in many cases counterproductive.

    The containment prevents ValueSpecifications for being reused in multiple messages. Instead, the very same ValueSpecification must be created in each message.

    Since ValueSpecification is a PackageableElement, there is no problem in making the association between Message and ValueSpecification a non-containment association.

  • Reported: UML 2.4 — Thu, 29 Sep 2011 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Cannot set an activity as the source or target of an information flow

  • Key: UMLR-294
  • Legacy Issue Number: 19133
  • Status: open  
  • Source: Alstom Transport ( Wagner Schalch Mendes)
  • Summary:

    According to the constraints specified for an InformationFlow, its sources and targets can be only of the following kind: Actor, Node, UseCase, Artifact, Class, Component, Port, Property, Interface, Package, ActivityNode, ActivityPartition and InstanceSpecification except when its classifier is a relationship.

    In my opinion, Activity should also be included in the list.

  • Reported: UML 2.4.1 — Wed, 4 Dec 2013 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Use cases specifying the same subject cannot be associated: exception

  • Key: UMLR-254
  • Legacy Issue Number: 16292
  • Status: open  
  • Source: London Life Insurance Co. ( Willem Van Galen)
  • Summary:

    The UML Superstructure Specification V2.4 states in 16.3.6 UseCase (from UseCases): “Two use cases specifying the same subject cannot be associated since each of them individually describes a complete usage of the subject.”

    For the longest time, this looked like a common-sense rule. However, it seems to me that in the context of SOA there is at least on exception to this rule.

    Let’s say that:
    1. The subject represents a component (as understood in SOA) and the use cases represent the component’s services.
    2. The initiating actor of all of the component’s services is Another Use Case. This reflects the SOA reality that services are not directly consumed by human actors but by other use cases.
    3. The component offers services A and B, both of which trace back to legitimate uses.
    4. As it happens, when service B is defined in detail it turns out that one of its steps amounts exactly to the functionality represented as service A.

    In such situations, where the subject already has a public service (A) that can actually be reused by one or more of its other public services (B), I think it’s entirely reasonable to allow B to be associated with A. After all, A’s initiating actor is Another Use Case, which is exactly what B is. In object-orientated terms this amounts to an object performing an operation on itself.

    I propose for UML to accommodate this scenario.

  • Reported: UML 2.4 — Sat, 28 May 2011 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Metaclass stereotype notion (02)

  • Key: UMLR-252
  • Legacy Issue Number: 16119
  • Status: open  
  • Source: email.com ( Kirill Fakhroutdinov)
  • Summary:

    Text says: "The names of Profiles are shown using a dashed arrow with an open arrowhead from the package to the applied profile."
    "The names" is not relevant in this context. The arrow is related to profile application.
    The text should say something like: "The applied Profiles are shown ..."

  • Reported: UML 2.4 — Fri, 27 Jun 2014 11:17 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Metaclass stereotype notion

  • Key: UMLR-251
  • Legacy Issue Number: 16118
  • Status: open  
  • Source: email.com ( Kirill Fakhroutdinov)
  • Summary:

    Text says: "A Class that is extended by a Stereotype may be extended by the optional stereotype «Metaclass» ..."
    The second "extended" has no sense.
    It should say something like: "A Class that is extended by a Stereotype may be denoted by the optional stereotype «Metaclass» ..."

  • Reported: UML 2.4 — Sun, 17 Apr 2011 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Profile URI Attribute - Mingled URI Definition and Use in XMI

  • Key: UMLR-250
  • Legacy Issue Number: 16117
  • Status: open  
  • Source: email.com ( Kirill Fakhroutdinov)
  • Summary:

    While describing profile URI attribute for profiles UML specification mingled definition of URI and format used for XMI. URI value as a whole should follow URI specification RFC 2396 and OMG recommended format:
    uri = http://profileParentQualifiedName/version/profileName.xmi
    When URI is used for XMI, the profileParentQualifiedName part should also be (made?) valid XML QName, e.g. with "all other illegal XML QName characters removed". Note, that XML QName usually has namespace prefix followed by ':', e.g. 'taxes:dependent', which contradicts to and has no sense as related to the first URI 2396 requirement.

  • Reported: UML 2.4 — Sun, 17 Apr 2011 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Package URI Attribute Uses Obsolete RFC 2396

  • Key: UMLR-249
  • Legacy Issue Number: 16116
  • Status: open  
  • Source: email.com ( Kirill Fakhroutdinov)
  • Summary:

    Specification requires URI package attribute to follow the rules and syntax of the IETF URI specification RFC 2396. RFC 2396 was rendered obsolete by the more recent version of the URI syntax - RFC 3986, released in 2005.

  • Reported: UML 2.4 — Sun, 17 Apr 2011 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

A deferrable trigger may have a guard

  • Key: UMLR-255
  • Legacy Issue Number: 16307
  • Status: open  
  • Source: asu.edu ( Joe Mooney)
  • Summary:

    It is an unfortunate restriction to omit guards from the specification of <trigger>/defer.

    Please explicitly state or reconsider this restriction since using a guard would simplify many scenarios involving event deferral

  • Reported: UML 2.4 — Wed, 1 Jun 2011 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Name of Package in Figure 7.3 should be "Core" rather than "Constructs"

  • Key: UMLR-311
  • Legacy Issue Number: 19282
  • Status: open  
  • Source: lemke24.org ( Andreas Lemke)
  • Summary:

    The subtitle of the Figure 7.3:
    "The Core Packages"
    But the Name of the Package in the figure is "Constructs".

  • Reported: UML 2.4.1 — Mon, 10 Mar 2014 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Interaction.action should subset ownedMember in lieu of ownedElement

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

    In Figure 14.5 of UML 2.4.1 (and still valid for UML 2.5), the association end 'action' of Interaction subsets Element.ownedElement. Since Interaction is a Namespace and Action a NamedElement, I reckon it ought to subset Namespace.ownedMember instead.

  • Reported: UML 2.4.1 — Thu, 19 Apr 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT