Unified Modeling Language Avatar
  1. OMG Specification

Unified Modeling Language — All Issues

  • Acronym: UML
  • Issues Count: 160
  • Description: All Issues
Open Closed All
All Issues

Issues Summary

Key Issue Reported Fixed Disposition Status
UMLR-443 UML 2.5 issue. AssociationClasses should have isUnique property UML 2.5b1 open
UMLR-438 Observations in TimeExpressions UML 2.5b1 open
UMLR-450 UML 2.5: Time Observation and Duration Observation problem UML 2.5b1 open
UMLR-437 What is the abstract syntax for Figure 17.27? UML 2.5b1 open
UMLR-433 What is a UML diagram? is it restricted to showing elements that are instances of the M2 UML metamodel and nothing else? UML 2.5b1 open
UMLR-428 Guard evaluation with decision input UML 2.5b1 open
UMLR-471 Allow a notation to allow for a default assignment of a decision to the owner of the activity UML 2.5b1 open
UMLR-677 Why is Association.memberEnd ordered? UML 2.5b1 open
UMLR-431 problems with BehavioralFeature::method UML 2.5b1 open
UMLR-449 Contradiction between the abstract syntax and semantics of an Interval UML 2.5b1 open
UMLR-429 Missing glossary UML 2.5b1 open
UMLR-427 7.2.3, last sentence 2nd paragraph the revised text UML 2.5b1 open
UML25-684 Typo in Interaction Example UML 2.5b1 UML 2.5 Duplicate or Merged closed
UML25-680 Profile::references_same_metamodel UML 2.5b1 UML 2.5 Resolved closed
UML25-679 Operation::isConsistentWith() UML 2.5b1 UML 2.5 Resolved closed
UML25-678 redefined states UML 2.5b1 UML 2.5 Resolved closed
UML25-677 Event pools for passive objects? UML 2.5b1 UML 2.5 Resolved closed
UML25-676 Who owns MessageEnds? UML 2.5b1 UML 2.5 Resolved closed
UML25-672 Problems with OCL definition of Package::makesVisible UML 2.5b1 UML 2.5 Resolved closed
UML25-673 Incomplete sentence UML 2.5b1 UML 2.5 Resolved closed
UML25-499 Association notation for properties does not allow representation of aggregation UML 2.5b1 UML 2.5 Resolved closed
UML25-498 UML2.5 issue: incorrect use of oclKindOf()->notEmpty() UML 2.5b1 UML 2.5 Resolved closed
UML25-497 wrong multiplicity of redefining states UML 2.5b1 UML 2.5 Resolved closed
UML25-496 Keywords are inconsistently defined and applied UML 2.5b1 UML 2.5 Resolved closed
UML25-487 InformationFlow::sources_and_target_kind UML 2.5b1 UML 2.5 Resolved closed
UML25-494 UML2.5 issue: clause 7.7.5 does not correctly refer to Instantiate stereotype UML 2.5b1 UML 2.5 Resolved closed
UML25-493 UML 2.5 - clause 14 does not put Examples at the correct heading level UML 2.5b1 UML 2.5 Resolved closed
UML25-489 Table C.1 apply UML 2.5b1 UML 2.5 Resolved closed
UML25-488 Metaclass operations incomplete UML 2.5b1 UML 2.5 Resolved closed
UML25-492 UML2.5 issue: clause 10 Signal and Reception UML 2.5b1 UML 2.5 Resolved closed
UML25-495 UML 2.5: ActivityPartition::represents keywords UML 2.5b1 UML 2.5 Resolved closed
UML25-490 UML 2.5 FTF - Clause 17 Interactions, Section 17.2.3 Semantics, subsection Interaction UML 2.5b1 UML 2.5 Resolved closed
UML25-486 Classifier::hasVisibilityOf(...) UML 2.5b1 UML 2.5 Resolved closed
UML25-485 Two entries UML 2.5b1 UML 2.5 Resolved closed
UML25-519 About UseCase description UML 2.5b1 UML 2.5 Resolved closed
UML25-518 Annex B summary table UML 2.5b1 UML 2.5 Resolved closed
UML25-529 actors of a use case express the requirements of its subject(s) regarding its/their environment. UML 2.5b1 UML 2.5 Resolved closed
UML25-528 UML: Parameter Direction and Effect UML 2.5b1 UML 2.5 Resolved closed
UML25-523 UML 2.5 Issue: specification for qualified association ends is in wrong clause UML 2.5b1 UML 2.5 Resolved closed
UML25-522 UML 2.5 class_name UML 2.5b1 UML 2.5 Resolved closed
UML25-526 Event pools for passive objects UML 2.5b1 UML 2.5 Resolved closed
UML25-525 Behavior after exceptions are encountered UML 2.5b1 UML 2.5 Resolved closed
UML25-521 UseCases editorial change UML 2.5b1 UML 2.5 Resolved closed
UML25-520 The current criteria used in UML for BehavioralFeature::isDistinguishable() is insufficient in practice UML 2.5b1 UML 2.5 Resolved closed
UML25-517 Clarify that stereotypes can be applied to UML DI UML 2.5b1 UML 2.5 Resolved closed
UML25-516 UML2.5 clause 17 keyword inconsistency UML 2.5b1 UML 2.5 Resolved closed
UML25-524 Completion events disambiguation UML 2.5b1 UML 2.5 Resolved closed
UML25-527 UML 2.5: Clarification of semantics for CreateLinkAction and DestroyLinkAction UML 2.5b1 UML 2.5 Resolved closed
UML25-530 UML 2.5 FTF Receptions may not have a method UML 2.5b1 UML 2.5 Resolved closed
UML25-503 Interactions needs to fix Gate name Distinguishability rules UML 2.5b1 UML 2.5 Resolved closed
UML25-502 ActionInputPin notations missing UML 2.5b1 UML 2.5 Resolved closed
UML25-515 UML 2.5's Collaboration semantics is inconsistent with Collaboration::collaborationRole UML 2.5b1 UML 2.5 Resolved closed
UML25-514 UML2.5's Connector role constraint excludes inherited roles UML 2.5b1 UML 2.5 Resolved closed
UML25-505 Message Constraint signature_is_Signal only merely refers to Signal.ownedAttributes as parameters of a Message signature UML 2.5b1 UML 2.5 Resolved closed
UML25-504 Classifier operation inherit(NamedElement[*]) : NamedElement[*] UML 2.5b1 UML 2.5 Resolved closed
UML25-511 Forked association notation ill-formed UML 2.5b1 UML 2.5 Resolved closed
UML25-501 UML 2.5 Beta 1 9.5.3 Qualifiers UML 2.5b1 UML 2.5 Resolved closed
UML25-500 Transition redefinition UML 2.5b1 UML 2.5 Resolved closed
UML25-513 parts should be allowed to show their interfaces UML 2.5b1 UML 2.5 Resolved closed
UML25-510 UML 2.5 FTF] Editorial / §15.5.1 p429 UML 2.5b1 UML 2.5 Resolved closed
UML25-509 Inheriting Connectors UML 2.5b1 UML 2.5 Resolved closed
UML25-507 UML 2.5 FTF 14.2.3 Page 327 Typo UML 2.5b1 UML 2.5 Resolved closed
UML25-506 Incorrect text on state list notation interchange UML 2.5b1 UML 2.5 Resolved closed
UML25-508 UML 2.5 FTF 15.3.3 Page 406 decisionInputBehavior rather than decisionInput UML 2.5b1 UML 2.5 Resolved closed
UML25-538 Clarification of use of BNF for textual notations UML 2.5b1 UML 2.5 Resolved closed
UML25-537 ActivityParameterNode notation UML 2.5b1 UML 2.5 Resolved closed
UML25-539 Avoid covariant parameters in metamodel operation redefinition UML 2.5b1 UML 2.5 Resolved closed
UML25-536 The resolution to Issue 18528 contains incorrect OCL and operation names UML 2.5b1 UML 2.5 Resolved closed
UML25-535 The resolution to issue 18415 contains invalid OCL UML 2.5b1 UML 2.5 Resolved closed
UML25-546 Wording corrections in Behavior Diagrams and Activity Diagram Labels UML 2.5b1 UML 2.5 Resolved closed
UML25-545 Labels for generalization sets in UML DI UML 2.5b1 UML 2.5 Resolved closed
UML25-541 Classifier and state annotations in UML DI UML 2.5b1 UML 2.5 Resolved closed
UML25-540 Dashed interaction lifelines in UML DI UML 2.5b1 UML 2.5 Resolved closed
UML25-532 Action operation redefinition is invalid UML 2.5b1 UML 2.5 Resolved closed
UML25-531 Association::endType() is inconsistent UML 2.5b1 UML 2.5 Resolved closed
UML25-534 Improve documentation of how derived properties are calculated UML 2.5b1 UML 2.5 Resolved closed
UML25-533 The resolution to 18697 contains errors UML 2.5b1 UML 2.5 Resolved closed
UML25-544 Template parameter rectangles UML 2.5b1 UML 2.5 Resolved closed
UML25-543 Ownership of property qualifier rectangles UML 2.5b1 UML 2.5 Resolved closed
UML25-542 Dependencies with more than two ends in UML DI UML 2.5b1 UML 2.5 Resolved closed
UML25-483 UML 2.5 issue: Clause 6.3 should contain a definition of "execution scope" UML 2.5b1 UML 2.5 Resolved closed
UML25-482 Fixed-point issues with the definition of default values for literals UML 2.5b1 UML 2.5 Resolved closed
UML25-475 Fix the notation to allow assignment of a decision to partition when the swimlanes are not practical. UML 2.5b1 UML 2.5 Resolved closed
UML25-474 UML association semantics vis-a-vis Interfaces (and other types of classifiers) UML 2.5b1 UML 2.5 Resolved closed
UML25-473 confusing wording and terminology for TransitionKind in the section “Transition kinds relative to source”. UML 2.5b1 UML 2.5 Resolved closed
UML25-472 The derived property Classifier::/inheritedMember does not correctly define the meaning of inheritance UML 2.5b1 UML 2.5 Resolved closed
UML25-471 UML 2.5 issue: structural features with isStatic = true may not have a slot in InstanceSpecifications UML 2.5b1 UML 2.5 Resolved closed
UML25-478 Notation for state machine specializations UML 2.5b1 UML 2.5 Resolved closed
UML25-477 UML2.5 issue : missing constraints on aggregation / composition UML 2.5b1 UML 2.5 Resolved closed
UML25-476 Two different Dashed Arrow Styles for Reply message in Figure 17.2 Interaction Example UML 2.5b1 UML 2.5 Resolved closed
UML25-481 Error in Dependency notation example UML 2.5b1 UML 2.5 Resolved closed
UML25-480 Error in diagram using StringExpressions UML 2.5b1 UML 2.5 Resolved closed
UML25-479 Inconsistent template binding notation example UML 2.5b1 UML 2.5 Resolved closed
UML25-484 UML 2.5 issue; the word "individual" is incorrect in 9.8 UML 2.5b1 UML 2.5 Resolved closed
UML25-553 misleading omission UML 2.5b1 UML 2.5 Resolved closed
UML25-552 Validation errors in UML metamodel UML 2.5b1 UML 2.5 Resolved closed
UML25-547 PrimitiveTypes::UnlimitedNatural lacks an XML-compatible serialization for the 'unbounded' value UML 2.5b1 UML 2.5 Resolved closed
UML25-549 Assocation display options too narrow UML 2.5b1 UML 2.5 Resolved closed
UML25-548 Annex E lacks sub-clauses for the XMI details for StandardProfile and UMLDI UML 2.5b1 UML 2.5 Resolved closed
UML25-551 UML 2.5 issue: subsettingContext() has incorrect logic UML 2.5b1 UML 2.5 Resolved closed
UML25-550 Headed composite and not ownedElement UML 2.5b1 UML 2.5 Resolved closed
UML25-554 Activity::structuredNode is incorrectly marked as readOnly = true UML 2.5b1 UML 2.5 Resolved closed
UML25-200 Missing word in section 7.4.3, "Semantics" UML 2.5b1 UML 2.5 Resolved closed
UML25-199 Four typos UML 2.5b1 UML 2.5 Resolved closed
UML25-206 ElementImport semantics UML 2.5b1 UML 2.5 Resolved closed
UML25-205 Same name" vs. "indistinguishable name" UML 2.5b1 UML 2.5 Resolved closed
UML25-204 Further clarify Element ownership constrains UML 2.5b1 UML 2.5 Resolved closed
UML25-203 Semantic conformance implies Abstract Syntax conformance UML 2.5b1 UML 2.5 Resolved closed
UML25-207 isConsistentWith() definition broken UML 2.5b1 UML 2.5 Resolved closed
UML25-202 Suggested improvements to conformance section UML 2.5b1 UML 2.5 Resolved closed
UML25-201 PDF links to Primitive Types don't work UML 2.5b1 UML 2.5 Resolved closed
UML25-208 Superfluous word on p309 UML 2.5b1 UML 2.5 Resolved closed
UMLR-434 PrimitiveTypes::Real is inconsistently specified relative to its mapping to xsd:double UML 2.5b1 open
UMLR-436 No explanation of how to deal with conflicting transitions of equal priority UML 2.5b1 open
UMLR-435 Definition of allOwningPackages() UML 2.5b1 open
UMLR-430 Several UMLDI redefining associations are invalid UML 2.5b1 open
UMLR-442 UseCases: Explanation of words “fragment” and “increment” UML 2.5b1 open
UMLR-445 Behavior does not override NamedElement::isDistinguishableFrom() like BehavioralFeature does UML 2.5b1 open
UMLR-426 Uml2.5 issue - constraints of Behavior incorrectly assume context is always non-null UML 2.5b1 open
UMLR-439 Timing Events Question / Issue UML 2.5b1 open
UMLR-441 The notation for ExtensionPoint provides for an “explanation”, but the metamodel provides nowhere to store it. UML 2.5b1 open
UMLR-440 UseCases: no way for an Extend to pick out individual ownedBehaviors of the extending UseCase UML 2.5b1 open
UMLR-470 Profile: can a stereotype extend fewer metaclasses than another stereotype it specializes? UML 2.5b1 open
UMLR-469 Clarification re MOF Equivalent Semantics about defining/applying a stereotype to a slot of ininstance of a stereotype UML 2.5b1 open
UMLR-475 UML: No restrictions on what seem to be meaningless associations UML 2.5b1 open
UMLR-472 Need packages overview diagram and explicit depiction of package dependencies UML 2.5b1 open
UMLR-425 typo in 12.2.3 Model UML 2.5b1 open
UMLR-606 Inconsistent approach to type conformance UML 2.5b1 open
UMLR-604 "Object identity" undefined UML 2.5b1 open
UMLR-605 Consistent use of "conforms to" vs. "is a subtype of" UML 2.5b1 open
UMLR-455 Notation for Variables and Variable Actions is very vague and incomplete UML 2.5b1 open
UMLR-452 Rg. Realization and InterfaceRealization UML 2.5b1 open
UMLR-444 Clarification needed about the semantics of stereotype specialization and stereotype application UML 2.5b1 open
UMLR-451 Issue for Figure 17.18 UML 2.5b1 open
UMLR-448 Clarification about Interactions owning Actions and about the semantics of Actions owned by Interactions UML 2.5b1 open
UMLR-453 [UML 2.5] Redundancy in the definition of use case extensions UML 2.5b1 open
UMLR-456 Issue with Reply message in interactions (UML 2.5 Beta) UML 2.5b1 open
UMLR-447 Incorrect notation in figure 14.37 UML 2.5b1 open
UMLR-446 Shouldn't Gate and InteractionFragment be redefinable to support Interaction specialization? UML 2.5b1 open
UMLR-454 UML 2.5 - figures 14.37 and 14.38 use incorrect notation for keyword UML 2.5b1 open
UMLR-460 UML2.5: Clarification about UML profiles UML 2.5b1 open
UMLR-458 Serilaization of required stereotypes UML 2.5b1 open
UMLR-459 Reply messages now mandatory? UML 2.5b1 open
UMLR-466 Semantics of TimeConstraints and DurationConstraints UML 2.5b1 open
UMLR-461 Notation for DurationObservation with two event elements UML 2.5b1 open
UMLR-464 Semantics of Namespaces UML 2.5b1 open
UMLR-467 Stereotype for extended bound element realization UML 2.5b1 open
UMLR-462 Interactions and parameter assignments UML 2.5b1 open
UMLR-468 Please provide running footers or headers indicating the section/subsection of a page UML 2.5b1 open
UMLR-463 Semantics of Message argument mapping in Interactions UML 2.5b1 open
UMLR-457 UML2.5 issue: constraints needed in model of Standard Profile UML 2.5b1 open
UMLR-465 Meaning of access to constrainedElements UML 2.5b1 open
UMLR-607 Clarify aliasing in Namespaces UML 2.5b1 open
UMLR-609 Clarify ownership vs. membership for NamedElements UML 2.5b1 open
UMLR-611 Fuzzy diagrams UML 2.5b1 open
UMLR-421 Missing Example of TemplateBinding with model element "Class" UML 2.5b1 open
UMLR-423 UML 2.5 beta issue - Operation notation is wrong UML 2.5b1 open
UMLR-339 Incorrect sentence UML 2.5b1 open
UMLR-338 Incomplete sentence UML 2.5b1 open
UMLR-336 meaning is not clear UML 2.5b1 open

Issues Descriptions

UML 2.5 issue. AssociationClasses should have isUnique property

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

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

  • Reported: UML 2.5b1 — Wed, 15 May 2013 04:00 GMT
  • Updated: Mon, 2 Jan 2023 09:44 GMT

Observations in TimeExpressions

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

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

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

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

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

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

UML 2.5: Time Observation and Duration Observation problem

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

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

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

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

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

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

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

What is the abstract syntax for Figure 17.27?

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

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

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

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

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

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

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

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

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

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

    { redefines DI::DiagramElement::modelElement }

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

    { redefines DI::DiagramElement::ownedElement }

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

    { redefines DI::DiagramElement::owningElement }

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

    { redefines DI::Edge::source }

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

    { redefines DI::Edge::target }

    These redefinitions have significant consequences:

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

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

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

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

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

    This approach seems very inflexible.

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

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

    This could be easily addressed with queries:

    UMLDI::UMLDiagramElement::showsUMLContentOnly() : Boolean

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

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

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

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

Guard evaluation with decision input

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

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

    Did I miss something?

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

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

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

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

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

Why is Association.memberEnd ordered?

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

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

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

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

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

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

problems with BehavioralFeature::method

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

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

    The UML metamodel problems:

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

    Clarifications and possible spec corrections are highly appreciated.

    UML 2.5 beta spec says:

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

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

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

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

Contradiction between the abstract syntax and semantics of an Interval

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

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

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

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

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

Missing glossary

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

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

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

7.2.3, last sentence 2nd paragraph the revised text

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

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

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

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

    I suggest:

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

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

Typo in Interaction Example

  • Key: UML25-684
  • Legacy Issue Number: 19348
  • Status: closed  
  • Source: gmail.com ( Pete Karousos)
  • Summary:

    v=mymsg(w=myout:16):96

    // this is a reply message assigning the return value 69 to 'v'

    Either the 96 needs to be a 69 or vice-versa but the two should match.

  • Reported: UML 2.5b1 — Sun, 20 Apr 2014 04:00 GMT
  • Disposition: Duplicate or Merged — UML 2.5
  • Disposition Summary:

    No Data Available

  • Updated: Thu, 12 Mar 2015 01:57 GMT

Profile::references_same_metamodel

  • Key: UML25-680
  • Legacy Issue Number: 18809
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    Profile::references_same_metamodel

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

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

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

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

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

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

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

    and

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

  • Reported: UML 2.5b1 — Thu, 11 Jul 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    duplicate of issue 18806 --withdrawn

  • Updated: Fri, 6 Mar 2015 23:16 GMT

Operation::isConsistentWith()

  • Key: UML25-679
  • Legacy Issue Number: 18807
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    I’m working on a couple of issues that complain that the rules for consistency of operation redefinition are incomplete.

    The current definition is this:

    isConsistentWith(redefinee : RedefinableElement) : Boolean

    {redefines RedefinableElement::isConsistentWith()}

    A redefining operation is consistent with a redefined operation if it has the same number of owned parameters, and the type of each owned parameter conforms to the type of the corresponding redefined parameter. The query isConsistentWith() specifies, for any two Operations in a context in which redefinition is possible, whether redefinition would be consistent in the sense of maintaining type covariance. Other senses of consistency may be required, for example to determine consistency in the sense of contravariance. Users may define alternative queries under names different from isConsistentWith(), as for example, users may define a query named isContravariantWith().

    pre: redefinee.isRedefinitionContextValid(self) body: redefinee.oclIsKindOf(Operation) and

    let op : Operation = redefinee.oclAsType(Operation) in

    self.ownedParameter->size() = op.ownedParameter->size() and

    Sequence

    {1..self.ownedParameter->size()}

    ->

    forAll(i |op.ownedParameter->at(1).type.conformsTo(self.ownedParameter->at.type))

    What this does is impose a “covariant” (Eiffel-like) rule on redefinition, but only on the types of the parameters – it ignores their names, multiplicity, ordering, uniqueness, direction or effect.

    The wording that says “Users may define alternative queries under names different from isConsistentWith(),…” seems to me to be unhelpful and misleading. Firstly, UML tools don’t normally provide such capabilities, and secondly, even if they did, the original consistency rule would still be enforced.

    There seem to me to be three approaches here.

    1. Tighten up the covariance rules so that they somehow incorporate names, multiplicity, uniqueness, ordering, direction etc.

    2. Recognize that “in” parameters should be contravariant, “out” and “return” parameters should be covariant, and “inout” parameters invariant, and make rules correspond to that.

    3. Relax things and make them more extensible. Remove the constraints on parameter replacement altogether (simply requiring the same number of parameters) and leave it to profiles to constrain what operation redefinition might mean.

    Given that the semantics for Operation says “In UML, such rules for type conformance are intentionally not specified” (although that sentence was inexplicably truncated between beta and betafinal) I think option 3 is correct.

    Any comments?

  • Reported: UML 2.5b1 — Wed, 10 Jul 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    issue withdrawn

  • Updated: Fri, 6 Mar 2015 23:16 GMT

redefined states

  • Key: UML25-678
  • Legacy Issue Number: 18757
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    It seems State can be redefined in one subtype only, because of multiplicity 0..1 of the "state" (see picture attached).
    That prevents from creating two subclasses which redefine the same states in inherited statemachine and our customers report the problem.

    I think, multiplicity should be changed to *.

  • Reported: UML 2.5b1 — Wed, 5 Jun 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    duplicate of issue 18455, issue closed by submitter

  • Updated: Fri, 6 Mar 2015 23:16 GMT

Event pools for passive objects?

  • Key: UML25-677
  • Legacy Issue Number: 18755
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    There does not seem to be any constraint that prevents a passive object from owning an event pool. Perhaps this is by design, but, if so, it is not clear how such an event pool is serviced. It looks like this should be clarified or perhaps a constraint preventing passive objects from having event pools should be introduced.

  • Reported: UML 2.5b1 — Tue, 4 Jun 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    duplicate of issue 18754

  • Updated: Fri, 6 Mar 2015 23:16 GMT

Who owns MessageEnds?

  • Key: UML25-676
  • Legacy Issue Number: 18734
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    I noticed that the metamodel does not have any composite property typed by MessageEnd.

    Since MessageEnd is a kind of NamedElement, we'd need to have a composite association to subset A_ownedMember_namespace.

  • Reported: UML 2.5b1 — Mon, 27 May 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    withdrawn by submitter

  • Updated: Fri, 6 Mar 2015 23:16 GMT

Problems with OCL definition of Package::makesVisible

  • Key: UML25-672
  • Legacy Issue Number: 19069
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Tomas Juknevicius)
  • Summary:

    Looking at the UML2.5 specification draft (I have the document UML25AfterBallot9.pdf - not sure if this is the newest one)
    I see problems with definition of Package::makesVisible - which is expressed in OCL.:

    makesVisible(el : NamedElement) : Boolean
    The query makesVisible() defines whether a Package makes an element visible outside itself. Elements with no visibility and elements with public visibility are made visible.
    pre: member->includes(el)
    body: ownedMember->includes(el) or
    (elementImport->select(ei|ei.importedElement = VisibilityKind::public)>collect(importedElement.oclAsType(NamedElement))>includes(el)) or
    (packageImport->select(visibility = VisibilityKind::public)>collect(importedPackage.member>includes(el))->notEmpty())

    Actually those problems carry on from the previous versions of UML;
    but since in previous versions even the OCL syntax was wrong (carried over from the pre-OCL2.0 times)
    I assumed this section is old/abandoned and did not pay much attention to it.

    But now with UML2.5 somebody took it seriously to update the syntax of the OCLs (kudos for that brave soul ), so we have an updated variant.
    But while the raw syntax problems were fixed, semantic problems were carried form the old revision verbatim.
    If we are updating OCLs anyway, I think it would be a good time to also correct those.

    So here goes:

    --------------------------------------------------------------------------------
    Problem #1

    the following comparison is nonsensical (the case handling ElementImports, line #2 of the body):

    ei.importedElement = VisibilityKind::public

    The OCL here tries to compare the model element (at the end of ElementImport relationship) with the enumeration literal - VisibilityKind::public, which is not what we want
    I think this passage should be restated as follows:

    ei.visibility= VisibilityKind::public

    i.e. we want to test whether element import has visibility set to public, just as in the other case - with package imports - one line below.

    Also the whole case handling element imports could be rewritten to simplify it:
    elementImport->exists(ei|ei.visibility = VisibilityKind::public and ei.importedElement = el)
    This does not change the semantics, but is much better readable/understandable: we are iterating through all (public) element imports
    checking whether imported element matches the element el.

    --------------------------------------------------------------------------------
    Problem #2
    the case handling package imports (line #3 of the body) is also borked:

    packageImport->select(visibility = VisibilityKind::public)>collect(importedPackage.member>includes(el))->notEmpty()

    Here the first part of the expression is OK; we take all package import relationships and filter them - accept only public ones:

    packageImport->select(visibility = VisibilityKind::public)
    But the next part again makes no sense

    ...>collect(importedPackage.member>includes(el))->notEmpty()
    here expression part

    importedPackage.member->includes(el)

    produces a boolean - whether element el is included among the members of the package being imported.
    So the result of the expression part

    ...>collect(importedPackage.member>includes(el))...
    is a collection of booleans (of the form:

    {false, false, true, false, true}

    ),
    where each boolean signifies whether element is among the members of each particular imported package.

    Then it makes no sense to test that for emptiness:

    ->notEmpty()
    this produces true if there is at least one item (does not matter true, or false) in that bag of booleans.
    So that part produces true if there is at least 1 public package import ( it does not matter what package is imported).

    I think this passage should be restated as follows:

    packageImport->select(visibility = VisibilityKind::public)>exists(importedPackage.member>includes(el))
    I.e. we are iterating through all (public) package imports and checking whether element el appears among members
    of at least one of the imported packages.

    --------------------------------------------------------------------------------

    So the final OCL of makesVisible could be (also getting rid of some unnecessary parentheses, and further simplification):

    pre: member->includes(el)
    body:
    ownedMember->includes(el) or
    elementImport->exists(ei|ei.visibility = VisibilityKind::public and ei.importedElement = el) or
    packageImport->exists(pi|pi.visibility = VisibilityKind::public and pi.importedPackage.member->includes(el))

  • Reported: UML 2.5b1 — Wed, 25 Sep 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Incomplete sentence

  • Key: UML25-673
  • Legacy Issue Number: 19419
  • Status: closed  
  • Source: toshiba-tsip.com ( VIRESH MOHAN)
  • Summary:

    In Section 9.6.3 Operations block, there is an incomplete sentence in one of the paragraphs.
    "
    Different type-conformance systems adopt different schemes for how the types of parameters and results may vary when an Operation is redefined in a specialization. When the type may not vary, it is called invariance. When the parameter type may be specialized in a specialized type, it is called covariance. When the parameter type may be generalized in a specialized type, it is called contravariance. In UML, s"

    As you can see the last sentence in the above paragraph is incomplete.

  • Reported: UML 2.5b1 — Tue, 20 May 2014 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Association notation for properties does not allow representation of aggregation

  • Key: UML25-499
  • Legacy Issue Number: 18466
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    UML 2.5 issue.

    There is a sentence in 9.5.4: “In a Classifier, an attribute may also be shown using association notation, with no adornments at the tail of the arrow.” This does not allow the use of diamond notation to represent properties that are aggregations or compositions.

  • Reported: UML 2.5b1 — Wed, 20 Feb 2013 05:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    This is independent of issue 15237, which complains about the very existence of this notation. If the notation
    is to remain, at least it needs to be comprehensibly defined.

  • Updated: Fri, 6 Mar 2015 20:59 GMT

UML2.5 issue: incorrect use of oclKindOf()->notEmpty()

  • Key: UML25-498
  • Legacy Issue Number: 18465
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    There is a systematic error in the OCL in Clause 17. There are many erroneous expressions of the form x.oclIsKindOf(T)->notEmpty(). These are apparently intended to mean x.oclIsKindOf(T), i.e. a Boolean-valued test that x has the type T or a subtype.

    The fact that the ->notEmpty() happens to pass the syntax checking is an unfortunate and misleading “feature” of OCL. Semantically, all of these expressions in their current form will evaluate to true, whatever their arguments.

    I found these constraints all to have the problem:

    all_lifelines

    interaction_uses_share_lifeline

    selector_int_or_string

    sending_receiving_message_event

    signature_is_signal

    signature_is_operation_request

    signature_is_operation_reply

  • Reported: UML 2.5b1 — Wed, 20 Feb 2013 05:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Change the OCL productions to replace:
    x.oclIsKindOf(T)->notEmpty()
    by:
    x.oclIsKindOf(T)

  • Updated: Fri, 6 Mar 2015 20:59 GMT

wrong multiplicity of redefining states

  • Key: UML25-497
  • Legacy Issue Number: 18455
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    UML spec, Figure 15.3 shows that multiplicity of redefining state is 0..1 which automatically means that it is impossible to have two or more subclasses which redefine the same state in their statemachines.

    It should be fixed to state [0..*] I believe

  • Reported: UML 2.5b1 — Thu, 14 Feb 2013 05:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Change the appropriate association end multiplicities from [0..1] to [0..*].

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Keywords are inconsistently defined and applied

  • Key: UML25-496
  • Legacy Issue Number: 18454
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    The word “keyword” is used inconsistently throughout the spec. It is defined in Annex C, which clearly says that keywords are always enclosed in guillemets, and lists the keywords that appear in the spec. Non-stereotype keyword are currently all defined starting with lower case, while standard stereotypes (also listed in Annex C and counting as keywords) use upper case.

    However:

    1. Several keywords defined in the spec are missing from Annex C: bind, collaboration, complete, disjoint, parallel, iterative, stream and flow.

    2. Several references in the spec to standard stereotypes use lower case and should use upper: derive, refine, trace

    3. In 7.7.5 instantiate is described and lower-cased as a keyword when it should be referred to as a standard stereotype in upper case

    4. 9.2.4 states that the standard notation for classifiers “shows the metaclass in guillemets”. This is not true: almost all classifiers define a lower-case keyword for their notation, such as interface; sometimes the keyword is different from the metaclass name, e.g. primitive.

    5. Notwithstanding the above, the notations for Collaboration, Class and StateMachine explicitly and inconsistently use the metaclass name with uppercase. In the case of Collaboration (11.7.4) and Class (11.4.4), Annex C is missing the keyword; in the case of StateMachine, Annex C shows it as statemachine.

    6. Some words are described as keywords when they are not. Clause 13: all, at, after, when; clause 14: via, protocol; clause 17: sd, self, out, strict

    7. Annex C itself uses the phrase ‘the keyword “trace”’ when it should surely say ‘the keyword «Trace»’.

  • Reported: UML 2.5b1 — Thu, 14 Feb 2013 05:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    There are many problems with keywords in Annex C and throughout the spec.
    (1) can be resolved by including appropriate definitions in Annex C.
    (2) can be resolved by correcting the references where they occur.
    For (3) a separate issue will be raised against clause 7.
    (4) can be resolved by altering 9.2.4 to refer to the keyword rather than the metaclass.
    (5) can be resolved by correcting the references to refer to the lower case name. (6) can be resolved by either rewriting to avoid the need for any terminology, or by using other terminology:
    “textual annotation” when the word is in curly brackets. Note that the BNF convention is to specify terminal
    symbols using single quotes; we should do the same in the specification text.
    (7) can be resolved as suggested.
    There are several words listed in the table in Annex C that are not keywords. Especially, compartment
    headers are not keywords (as they do not appear in guillemets) and should be removed from the table. This
    is a change from earlier versions of UML which were unclear and inconsistent about compartment naming.
    The notation placement “between braces” is contradictory with “Keywords are always enclosed in guillemets”.
    There are several related issues that can be merged with this one: 18113 is covered by 2. 18114 points out
    that «create»is a keyword as well as a standard stereotype. In fact «create»is not introduced anywhere in
    the spec as a keyword, and its definition as given in Annex C does not make sense because it cannot be
    represented in the abstract syntax. So the keyword can be deleted from the table. 11683 is rendered obsolete
    by the fact that

    {abstract}

    is correctly no longer described as a keyword.
    9125 is resolved by the points above.
    15756 is resolved by (1).
    15419 is resolved in the same way as 18114.
    Note also that issue 18112 removes all standard stereotypes from Annex C, so they are no longer defined as
    keywords.
    The resolution also corrects miscellaneous errors in Table C.1.

  • Updated: Fri, 6 Mar 2015 20:59 GMT

InformationFlow::sources_and_target_kind

  • Key: UML25-487
  • Legacy Issue Number: 18415
  • Status: closed  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    The OCL doesn't match the description - no check is made of the
    InstanceSpecification classifier. (This constraint could probably
    be split in two and the type test separated as an operation.)

  • Reported: UML 2.5b1 — Tue, 5 Feb 2013 05:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Note this change resolves both issues 18415 (which corrects the OCL) and 18690 (which adds Behaviors to
    the list of allowed types). The latter is merged with 18415 since both affect the same text allowing for a less
    confusing statement of their combined resolutions.
    In contrast to the 18415 issue summary, the OCL does check for InstanceSpecification, but it doesn’t not
    do so completely. The check that a source or target that is an InstanceSpecification is not a link is missing.
    These checks are added in the update OCL below.

  • Updated: Fri, 6 Mar 2015 20:59 GMT

UML2.5 issue: clause 7.7.5 does not correctly refer to Instantiate stereotype

  • Key: UML25-494
  • Legacy Issue Number: 18450
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    In 7.7.5 «instantiate» is described and lower-cased as though it were a keyword. It sort of implies that Instantiate is a subclass of Dependency.

    In fact «Instantiate» is a standard stereotype. It should be referred to using upper case, and the text should explain that it is a standard stereotype applied to a Usage. The figure and caption will need changing.

    (Note: this example is also the topic of issue 17804, which is a separate matter about the direction of the arrow.)

  • Reported: UML 2.5b1 — Wed, 13 Feb 2013 05:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 20:59 GMT

UML 2.5 - clause 14 does not put Examples at the correct heading level

  • Key: UML25-493
  • Legacy Issue Number: 18448
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    All the other clauses have Examples at the same level as Notation, Semantics etc. Clause 14 does not do this.

    14.3.4 defines the notation

    {final}

    in the Examples section: notation should be defined in the Notation section and exemplified in the Examples section.

  • Reported: UML 2.5b1 — Wed, 13 Feb 2013 05:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 12380

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Table C.1 apply

  • Key: UML25-489
  • Legacy Issue Number: 18417
  • Status: closed  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    The semantics of apply refer to 'importedProfile'. There is no
    such property. I'm not entirely sure why there's any OCL at all
    as the keyword is just used with the ProfileApplication diagram
    edge itself.

  • Reported: UML 2.5b1 — Tue, 5 Feb 2013 05:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 18124

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Metaclass operations incomplete

  • Key: UML25-488
  • Legacy Issue Number: 18416
  • Status: closed  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    The operations listed for each metaclass should give the uniqueness
    and ordering of all their parameters, including return type. For
    example, NamedElement::getAllNamespaces() is actually ordered. In
    addition, operation redefinitions should be given, for example,
    Package::mustBeOwned().

  • Reported: UML 2.5b1 — Tue, 5 Feb 2013 05:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Enhance the generator to produce annotations such as ordered, nonunique for all operation parameters and
    results with non-default values for isOrdered and isUnique in the generated Classifier Descriptions.
    Enhance the generator to produce annotations such as redefines op() for all operation redefinitions in the
    generated Classifier Descriptions.

  • Updated: Fri, 6 Mar 2015 20:59 GMT

UML2.5 issue: clause 10 Signal and Reception

  • Key: UML25-492
  • Legacy Issue Number: 18444
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    The sentence in 10.3.3 “The receiving object handles Signals as specified by its Receptions” should read “The receiving object handles Signals as specified by clause 13.3”. The current sentence seems to imply that a Reception is needed to receive a Signal which is actually not the case,

  • Reported: UML 2.5b1 — Tue, 12 Feb 2013 05:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    do as proposed

  • Updated: Fri, 6 Mar 2015 20:59 GMT

UML 2.5: ActivityPartition::represents keywords

  • Key: UML25-495
  • Legacy Issue Number: 18452
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    The keywords «attribute» and «class» are part of the notation for ActivityPartition (examples in 15.70 and 15.72) but are not specified in the notation and should be. They do appear in Annex C.

  • Reported: UML 2.5b1 — Wed, 13 Feb 2013 05:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The notation used in the example diagrams in Figures 15.70 and 15.72 is not consistent with the notation
    as specified in Subclause 15.6.4, which defines no such keywords. The figures also use underlining of
    ActivityPartition names, which is not specified, either.

  • Updated: Fri, 6 Mar 2015 20:59 GMT

UML 2.5 FTF - Clause 17 Interactions, Section 17.2.3 Semantics, subsection Interaction

  • Key: UML25-490
  • Legacy Issue Number: 18419
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Mr. Marc-Florian Wendland)
  • Summary:

    First sentence of fourth paragraph says:

    The invalid set of traces is associated only with the use of a Negative CombinedInteraction.

    But it ought to say:

    The invalid set of traces is associated only with the use of a Negative CombinedFragment.

  • Reported: UML 2.5b1 — Tue, 5 Feb 2013 05:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Apply the solution proposed in the issue’s summary.

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Classifier::hasVisibilityOf(...)

  • Key: UML25-486
  • Legacy Issue Number: 18414
  • Status: closed  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    Classifier::hasVisibilityOf(...)
    The description doesn't match the OCL.

  • Reported: UML 2.5b1 — Tue, 5 Feb 2013 05:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 18177

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Two entries

  • Key: UML25-485
  • Legacy Issue Number: 18408
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    UML 2.4.1 and UML 2.5 beta1 specs incorrectly show TWO entry behaviors on state, when only one is allowed in metamodel.
    Figure 14.5 State with compartments

  • Reported: UML 2.5b1 — Mon, 4 Feb 2013 05:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 16111

  • Updated: Fri, 6 Mar 2015 20:59 GMT

About UseCase description

  • Key: UML25-519
  • Legacy Issue Number: 18726
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Sebastien Gerard)
  • Summary:

    The description of a UseCase is: “A UseCase specifies a set of actions performed by its subject, which yields an observable result that is of value for one or more Actors or other stakeholders of the subject.”.

    However, UseCase may have no subjects. What happen in that case?

  • Reported: UML 2.5b1 — Tue, 21 May 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Clause 18 is inconsistent in using “subject” in the singular in many places. Clarify that a UseCase may refer
    to many subjects or none.

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Annex B summary table

  • Key: UML25-518
  • Legacy Issue Number: 18717
  • Status: closed  
  • Source: NIST ( Mr. Raphael Barbau)
  • Summary:

    It would probably help implementers of Annex B if it had something like the tables in BPMN's DI that show example graphics, the metaclasses involved, and some notes on how they're used, see the BPMN spec (http://www.omg.org/spec/BPMN/2.0/PDF), starting at Table 12.8 (Depiction Resolution for Loop Compensation Marker) in Section 12.3 (Notational Depiction Library and Abstract Element Resolutions).

  • Reported: UML 2.5b1 — Wed, 15 May 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    This issue is addressed by adding a table to the end of Annex B. This table shows example UML notations,
    and how they are represented in DI. The table refers the clauses and their figures, as well as Annex B clauses.

  • Updated: Fri, 6 Mar 2015 20:59 GMT

actors of a use case express the requirements of its subject(s) regarding its/their environment.

  • Key: UML25-529
  • Legacy Issue Number: 18760
  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    Quoted from §18.1.3, p686: “An Actor models a type of role played by an entity that interacts with the subjects of its associated UseCases (e.g., by exchanging
    signals and data), but which is external in the sense that an instance of an Actor is not a part of the instance of a subject of an
    associated UseCase. Actors may represent roles played by human users, external hardware, or other systems.”

    There are common cases where some actors (i.e. entities interaction with the subject) have no real needs (or requirements) by themselves for being part of a use case. Instead, the modeler use the specification of actors to defined what is not under the system responsibility. This seems a little odd to me to speak about “actor’s needs/requirements” in such a case. I would rather say that the actors of a use case express the requirements of its subject(s) regarding its/their environment.

  • Reported: UML 2.5b1 — Thu, 6 Jun 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Delete the contentious sentence (not actually mentioned in the issue, but the earlier sentence in 18.1.1 which
    talks about the “needs” of Actors) which adds no value to the spec.

  • Updated: Fri, 6 Mar 2015 20:59 GMT

UML: Parameter Direction and Effect

  • Key: UML25-528
  • Legacy Issue Number: 18759
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    The rules on Parameter Direction and Effect, seem overly weak.

    It doesn't seem to make sense to have a formal "inout" to also have the formal effect "delete", because it would be clearer to say "in"

    It doesn't seem to make sense to a formal "inout" to also have the formal effect "create", because it would be clearer to say "out"

    And Conrad says:
    Seems like we could change the modeling constraints to prevent inouts for create and delete, if we didn't mind the backward incompatibility.

    But Ed Seidewitz says
    The object passed out in on inout parameter doesn't have to be the same one that was passed in.

    For a "create" effect, the text says "Objects passed out of executions of the behavior as values of the parameter do not exist before those executions start." It doesn't say anything about objects passed in. Therefore, you could pass a non-null value into an inout parameter with the "create" effect, as long as the object passed out is a different, new object.

    The wording for "delete" is a little less clear, but I think it is reasonable to assume that it means that the object passed in on an inout parameter is destroyed, but that some other object could be passed out.

    Indeed, conceptually, an inout parameter could conceptually be both "delete" AND "create", meaning you pass in an object that gets destroyed and then get out a newly created object. However, the abstract syntax only allows at most one effect on a parameter

    So, we have at least different suggestions for changes to this material.

  • Reported: UML 2.5b1 — Wed, 5 Jun 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 17891

  • Updated: Fri, 6 Mar 2015 20:59 GMT

UML 2.5 Issue: specification for qualified association ends is in wrong clause

  • Key: UML25-523
  • Legacy Issue Number: 18750
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    The specification and examples for qualified association ends is currently in clause 9 but really ought to be in clause 11, where it should take into account the specification of multiplicity for association ends marked as unique.

  • Reported: UML 2.5b1 — Tue, 4 Jun 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Move the text fragments to the right place. The comment about unique ends has already been taken into
    account in 11.5.3.

  • Updated: Fri, 6 Mar 2015 20:59 GMT

UML 2.5 class_name

  • Key: UML25-522
  • Legacy Issue Number: 18748
  • Status: closed  
  • Source: Sparx Systems Pty Ltd ( Mr. J.D. Baker)
  • Summary:

    In section 17.3.4 <class_name> appears on the right hand side of the BNF but it is not defined in any other BNF statement. This is the only place in the spec where <class_name> appears. <class-name> appears in the text following the BNF. <class_name> in the BNF should be changed to <class-name>.

    Recommend that we add the following statement to the BNF

    <class-name>::=<Variable> | <Parameter> | <Property>

  • Reported: UML 2.5b1 — Mon, 3 Jun 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The Interactions working group agreed during the Berlin meeting that class_name is not optimal. In fact,
    the non-terminal symbol class_name does not reflect what it actually represents, i.e., the name of the Type
    that the ConnectableElement, which is represented by the Lifeline, is typed with.
    In addition, the font style of the non-terminal symbols has to be set to italics.

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Event pools for passive objects

  • Key: UML25-526
  • Legacy Issue Number: 18754
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    There does not seem to be any constraint that prevents a passive object from owning an event pool. Perhaps this is by design, but, if so, it is not clear how such an event pool is serviced. It looks like this should be clarified or perhaps a constraint preventing passive objects from having event pools should be introduced.

  • Reported: UML 2.5b1 — Tue, 4 Jun 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Currently, the only constraint related to Class:isActive is the passive_class constraint that “Only an active Class may
    own Receptions and have a classifierBehavior.” This means that a passive class may still have ownedBehaviors (including
    methods of operations), and these may service the event pool of instances of the class. (Note also that a passive
    object may receive Signal instances into its event pool, even though its Class does not have receptions.)
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Behavior after exceptions are encountered

  • Key: UML25-525
  • Legacy Issue Number: 18753
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    In the discussion of OpaqueBehaviors in caluse 13, it is mentioned that a Behavior may be "abandoned" after it has raised an exception. The semantics of "abandonment" following exceptions are not defined, except (it seems) for the specific case of ExecutableNodes in activities.

    So, is there something general that we can say in Common Behaviors about the state of a Behavior after it has encountered an exception? For example, in case of a state machine: is it meaningful for the state machine to handle an exception event after it has encountered an exception? (if so, what state is it in following an exception?)

  • Reported: UML 2.5b1 — Tue, 4 Jun 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The issue is referencing the following sentence in Subclause 13.2.3: “A FunctionBehavior may raise exceptions
    for certain input values, in which case the computation is abandoned.” It is rather odd to only mention
    exceptions in the specific case of FunctionBehaviors, since exceptions can potentially be raised by any kind
    of Behavior. This would be better explained more generally.

  • Updated: Fri, 6 Mar 2015 20:59 GMT

UseCases editorial change

  • Key: UML25-521
  • Legacy Issue Number: 18730
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    In the sentence “The individual fragments are executed as the corresponding ExtensionPoints of the extending UseCase are reached”, “extending” should read “extended”.

  • Reported: UML 2.5b1 — Thu, 23 May 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    indeed it should

  • Updated: Fri, 6 Mar 2015 20:59 GMT

The current criteria used in UML for BehavioralFeature::isDistinguishable() is insufficient in practice

  • Key: UML25-520
  • Legacy Issue Number: 18727
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    The current criteria only looks at the ordered collection of owned parameter types as a key for distinguishing behavioral features.
    For example, it means that, for UML, the following pairs of operations of the same name are not distinguishable:

    // difference in the parameter direction
    op1(String)
    op1():String

    // difference in the parameter effect
    op2(update String)
    op2(delete String)

    // difference in the parameter exception
    op3(Throwable)
    op3() throws Throwable

    // difference in the parameter collection characteristics
    op4(Set(String))
    op4(String[1])

    This means that UML is not able to represent some well-known programming languages where the above characteristics contribute to the signature of distinguishable operations (e.g., C, C++, Java, C#, …)

    This can be easily fixed.

    In the OCL for BehavioralFeature::isDistinguishableFrom(), replace:

    ...>isUnique(ownedParameter>collect(type))

    With:

    …>isUnique(ownedParameter>collect(p|Tuple

    {name=p.name, type=p.type,effect=p.effect,direction=p.direction,isException=p.isException,isStream=p.isStream,isOrdered=p.isOrdered,isUnique=p.isUnique,lower=p.lower,upper=p.upper}

    ))

    Since BehavioralFeature::ownedParameter is an ordered collection, the current definition constructs an ordered collection of the owned parameter types as a key for distinguishing BehavioralFeatures.

  • Reported: UML 2.5b1 — Wed, 22 May 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Clarify that stereotypes can be applied to UML DI

  • Key: UML25-517
  • Legacy Issue Number: 18715
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    [From Ed S in http://www.omg.org/archives/uml25-ftf/msg00357.html] Perhaps we can clarify this by simply adding some text to Annex B explicitly saying that stereotypes can be applied to UML DI elements and that a conforming tool is to interpret such stereotype application per 12.3.3 – that is, with the MOF equivalent semantics and XMI serialization. This would simply become part of the requirement for UML diagram interchange conformance. It seems like a useful capability to me.

  • Reported: UML 2.5b1 — Tue, 14 May 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    clarify as suggested

  • Updated: Fri, 6 Mar 2015 20:59 GMT

UML2.5 clause 17 keyword inconsistency

  • Key: UML25-516
  • Legacy Issue Number: 18702
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    The notation for ConsiderIgnoreFragment incorrectly refers to ‘consider’ and ‘ignore’ as keywords. These should be fixed in a similar manner to issue 18454.

  • Reported: UML 2.5b1 — Wed, 8 May 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Completion events disambiguation

  • Key: UML25-524
  • Legacy Issue Number: 18752
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Section 13.2.3 (Behaviors) refers to a "completion event" for Behaviors as does the StateMachines section. It appears that these are different two concepts that share the same name; the former seems to represent the termination of a Behavior whereas the latter specifies completion of one or more behaviors associated with a State (possibly one with multiple Regions). To avoid confusion between the two concepts, it would be useful to provide a clear specification of what is meant by a "completion event" in the CommonBehaviors semantics description. Also, it might be useful to choose a different name for this type of completion event to avoid confusion with the one in state machines (that particular term has been around since the original version of UML, so changing it would probably be more confusing).

  • Reported: UML 2.5b1 — Tue, 4 Jun 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 20:59 GMT

UML 2.5: Clarification of semantics for CreateLinkAction and DestroyLinkAction

  • Key: UML25-527
  • Legacy Issue Number: 18756
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    Semantics for DestroyLinkAction, and possibly CreateLinkAction, need clarification for the case of hybrid associations, i.e. associations which mix unique and non-unique ends. For example, what does DestroyLinkAction do for the case of a unique end where one or more other ends are non-unique and there is more than one outgoing link for the same value at the unique end?

  • Reported: UML 2.5b1 — Wed, 5 Jun 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 9013

  • Updated: Fri, 6 Mar 2015 20:59 GMT

UML 2.5 FTF Receptions may not have a method

  • Key: UML25-530
  • Legacy Issue Number: 18777
  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    According to the semantics of reception it seems that there should be a constraint implying that no method is specified for a reception.

    context Reception
    inv: self.method->isEmpty()

    What do you think?

  • Reported: UML 2.5b1 — Wed, 12 Jun 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Interactions needs to fix Gate name Distinguishability rules

  • Key: UML25-503
  • Legacy Issue Number: 18528
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    The isDistingishableFrom() operation of NamedElement needs to be
    overridden for Gate class to cover the case of when the gate is used as
    a formalGate of an Interaction. The association end formalGate subsets
    ownedElement, and since the Gate name attribute is optional, it is
    allowed to have two formal gates without an explicit name, but having
    derived names which are distinct.

    Even though the gate matching rules do not use this operation, we need
    to override it to avoid problems.

    In addition to this fix, there is a also need to add constraints to the
    gate names used for Gates for the gate matching rules to work properly.
    In particular, there are cases in use of gates which require distinction
    for the gate matching rules to work.

    Thus there is still a need to add new constraints on gate Names (explicit
    or derived).

    Because Gates which do not have an explicity name attribute have derived
    names, any constraint must include the possibility of these derived
    names.

    There is an explicit operation getGateName() on Gate class which returns
    the name of the gate which is to be used in the gate matching rules. If
    a gate does not have an explicit name attribute, a gate name is derived
    from the name of the message the gate is attached to , and the direction
    of the message with respect to the gate (e.g, foo_in, foo_out). The
    direction "in" or "out" is considered with respect to the outer perimeter
    of the interaction fragment that the gate is attached to.

    UML 2.5 added Gate matching rules in OCL, using this getGateName()
    operation, however there are currently no gate name distinguishably
    constraints in the spec. Two gates in the same container may have
    duplicate derived names, just because they are attached to two different
    messages, with the same direction, which happen to have the same name.
    There are cases when the gate matching rules will not work unless at
    least one of these gates needs includes an explicit name attribute value
    contrived to avoid the collision of the getGateNames() operation.

    The association end formalGates of Interaction subset ownedMember, and,
    as already stated above, we have to override the isDistinguisableFrom()
    operator for gate class. However, If there were two formal Gates with
    the same gate name in an interaction, the gate matching rules would
    become invalid.

    The association ends actualGates of InteractionUse, and cFragmentGates
    of CombinedFragment, both subset ownedElement, not ownedMember. So they
    no not need to obey the isDistinguisableFrom test. However, even though
    not required for the UML namespace Rules, actual Gates for an
    InteractionUse should have distinguishable gate names, in order for the
    gate matching rules to work.

    For the same reason, If a cFragmentGate is outside the CombinedFragment,
    then it must be distinguishable from other outer cFragmentGates of that
    same CombinedFragment.

    For the same reason, any two inner cFragmentGates associated with the
    same InteractionOperator of a CombinedFragment must have distinguished
    gate names.

    Thus we need to add a set of four constraints (one for each kind of gate)
    to the Gate class. Adding these four constraints will ensure that the
    gate matching rules work correctly.

    Proposed Change:

    Override the isDistinguishableFrom() operation of Gate to always return
    true.

    Add the following four new constraints to the Gate class. These rely on
    the four existing boolean operators of the Gate class which are used to
    determine in which of the four contexts of association that the gate is
    an instance of.

    formal_gate_distinguishable
    isFormal() implies <test that no other formal
    gate of the parent Interaction returns the same getGateName() as returned
    for self>

    actual_gate_distinguishable
    isActual() implies <test that no other actual
    gate of the parent InteractionUse returns the same getGateName() as
    returned for self>

    outside_cf_gate_distinguishable
    isOutsideCF() implies <test that no other
    outside cf gate of the parent CombinedFragment returns the same
    getGateName() as returned for self>

    inside_cf_gate_distinguishable
    isInsideCF() implies <test that no other
    inside cf gate attached to a message with its other end in the same
    InteractionOperator as self returns the same getGateName() as returned
    for self>

    I leave the detailed OCL for the actual OCL to include within the < >
    for the actual resolution of this issue.

  • Reported: UML 2.5b1 — Tue, 5 Mar 2013 05:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Override the isDistinguishableFrom() operation of Gate to always return true.
    Fix a problem in the isInnerCF operation, to fix the other End Gate situation.
    Add the following four new constraints to the Gate class. These rely on the four existing boolean operators
    of the Gate class which are used to determine in which of the four contexts of association that the gate is an
    instance of.
    formal_gate_distinguishable isFormal() implies <test that no other formal gate of the parent Interaction
    returns the same getGateName() as returned for self>
    actual_gate_distinguishable isActual() implies <test that no other actual gate of the parent InteractionUse
    returns the same getGateName() as returned for self>
    outside_cf_gate_distinguishable isOutsideCF() implies <test that no other outside cf gate of the parent CombinedFragment
    returns the same getGateName() as returned for self>
    inside_cf_gate_distinguishable isInsideCF() implies <test that no other inside cf gate attached to a message
    with its other end in the same InteractionOperator as self returns the same getGateName() as returned for
    self>

  • Updated: Fri, 6 Mar 2015 20:59 GMT

ActionInputPin notations missing

  • Key: UML25-502
  • Legacy Issue Number: 18507
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    UML 2.4.1, in the activity notation for ActionInputPin (as specialized) (Clause 12.3.3), says:

    "An action input pin with a ReadVariableAction as a fromAction is notated as an input pin with the variable name written beside it. An action input pin with a ReadSelfObject as a fromAction is notated as an input pin with the word “self” written beside it. An action input pin with a ValueSpecification as a fromAction is notated as an input pin with the value specification written beside it."

    The above seems to be missing from 2.5's notation section for ActionInputPin (Clause 16.2.4), though it is covered in Annex B (Clause B.4.3, Activity Diagram Labels), search on "ActionInputPin".

    Would also be good to include figures in the notation section for ActionInputPin (Clause 16.2.4), similar to Figure 16.38 (Presentation option for AddVariableValueAction).

  • Reported: UML 2.5b1 — Wed, 27 Feb 2013 05:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Dropping the description of this notation was unintentional

  • Updated: Fri, 6 Mar 2015 20:59 GMT

UML 2.5's Collaboration semantics is inconsistent with Collaboration::collaborationRole

  • Key: UML25-515
  • Legacy Issue Number: 18699
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    In UML 2.5 section 11.7.3 Collaboration Semantics says:

    Collaborations may be specialized from other Collaborations. If a role is extended in the specialization, its type in the specialized Collaboration must conform to its type in the general Collaboration. The specialization of the types of the roles does not imply corresponding specialization of the Classifiers that realize those roles. It is sufficient that they conform to the constraints defined by those roles.

    A specialized Collaboration can redefine some roles of its parent Collaborations but it should be possible to reuse them without redefining them.
    Unfortunately, this is not possible:

    Collaboration::collaborationRole subsets StructuredClassifier::/role, which is a derived union subsetted only by StructuredClassifier::ownedAttribute.

    That is, the inherited roles of a parent Collaboration are not roles of its specializing Collaborations.

    Currently, Collaboration::collaborationRole : ConnectableElement[*] subsets StructuredClassifier::role.
    That is, it is up to the discretion of the modeler to decide which subset of a Collaboration's roles are to be the Collaboration's collaborationRoles as well.

    It seems that the subset constraint is too strong; that is, it seems it should be relaxed such that a modeler could pick a subset of a Collaboration's roles and Collaboration's inherited roles as its collaborationRoles.
    That is, I suggest replacing:

    Collaboration::collaborationRole : ConnectableElement[*]

    {subsets StructuredClassifier::role}

    with:

    Collaboration::collaborationRole : ConnectableElement[*]

    { subsets Classifier::inheritedMember}

  • Reported: UML 2.5b1 — Tue, 7 May 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The issue is based on a misunderstanding. In fact the modeler chooses some ConnectableElements to be collaborationRoles,
    and /role is derived from that.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:59 GMT

UML2.5's Connector role constraint excludes inherited roles

  • Key: UML25-514
  • Legacy Issue Number: 18697
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    UML 2.5, section 11.8 provides an OCL encoding of the following role constraint on a Connector:

    [3] The ConnectableElements attached as roles to each ConnectorEnd owned by a Connector must be roles of the Classifier
    that owned the Connector, or they must be ports of such roles.

    inv: structuredClassifier <> null
    and
    end->forAll( e |
    structuredClassifier.role->includes(e.role)
    or
    e.role.oclIsKindOf(Port) and structuredClassifier.role->includes(e.partWithPort))

    Inherited roles are excluded because StructuredClassifier::/role is a derived union that is subsetted only once by StructuredClassifier::ownedAttribute

    In 17.7.3, Collaboration Semantics, the UML spec uses the term 'role' in a way that clearly suggests a broader intent than a subset of owned attributes:

    Neither all Features nor all contents of the participating instances nor all links between these instances are always required in a particular Collaboration. Therefore, a Collaboration is often defined in terms of roles typed by Interfaces.

    Collaborations may be specialized from other Collaborations. If a role is extended in the specialization, its type in the specialized Collaboration must conform to its type in the general Collaboration. The specialization of the types of the roles does not imply corresponding specialization of the Classifiers that realize those roles. It is sufficient that they conform to the constraints defined by those roles.

    In 17.7.3 CollaborationUses semantics, the UML spec uses the term 'role' in a way that could not legitimately restricted to a subset of owned attributes but instead include inherited attributes:

    The roleBindings are implemented using Dependencies owned by the CollaborationUse. Each role in the Collaboration is bound by a distinct Dependency and is its supplier. The client of the Dependency is a ConnectableElement that relates in some way to the context Classifier: it may be a direct role of the context Classifier, or an element reachable by some set of references from the context Classifier. These roleBindings indicate which ConnectableElement from the context Classifier plays which role in the Collaboration.

    One of the CollaborationUses owned by a Classifier may be singled out as representing the Behavior of the Classifier as a whole. This is called the Classifier’s representation. The Collaboration that is related to the Classifier by its representation shows how the instances corresponding to the StructuralFeatures of this Classifier (e.g., its attributes and parts) interact to generate the overall Behavior of the Classifier. The representing Collaboration may be used to provide a description of the Behavior of the Classifier at a different level of abstraction than is offered by the internal structure of the Classifier. The Properties of the Classifier are mapped to roles in the Collaboration by the role bindings of the CollaborationUse.

    I suggest replacing the term 'role' in chapter 11 and 17 with 'all roles' or 'owned an inherited roles' where applicable.

    I also suggest introducing a query:

    StructuredClassifier::allRoles() : ConnectableElement[*]
    body: allFeatures()>select(oclAsKind(ConnectableElement))>collect(oclAsType(ConnectableElement))->asSet()

    Then the roles constraint on Connector in 11.8 should read:

    [3] The ConnectableElements attached as roles to each ConnectorEnd owned by a Connector must be owned or inherited roles of the Classifier
    that owned the Connector, or they must be ports of such roles.

    inv: structuredClassifier <> null
    and
    end->forAll( e |
    structuredClassifier.allRoles()->includes(e.role)
    or
    e.role.oclIsKindOf(Port) and structuredClassifier.allRoles()->includes(e.partWithPort))

  • Reported: UML 2.5b1 — Tue, 7 May 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Accept the suggestions in the issue. For the Collaborations clause, avoid using “role” at all and use “collaborationRole”
    instead, which is defined for that purpose.
    This also resolves 7416.

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Message Constraint signature_is_Signal only merely refers to Signal.ownedAttributes as parameters of a Message signature

  • Key: UML25-505
  • Legacy Issue Number: 18545
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Mr. Marc-Florian Wendland)
  • Summary:

    Message Constraint signature_is_Signal only merely refers to Signal.ownedAttributes as parameters of a Message signature. This is not sufficient, since a Signal may specialize other signals and, thus, the Message should also allow to specify arguments for inherited attributes. Of course, redefined attributes need to be sorted out.

  • Reported: UML 2.5b1 — Wed, 13 Mar 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Instead of using the Signal.ownedAttributes directly in the OCL (let signalAttributes : OrderedSet(Property)
    = signature.oclAsType(Signal).ownedAttribute->asOrderedSet()) the inherited operation
    Classifier::inheritedMember():NamedElement[0..*] ought to be used in the let-statement. The operation
    filters redefined inherited elements and delivers the complete set of all inherited members, including the
    properties. These need to be extracted from the set of inherited members eventually. The resulting OCL
    would look like this:
    let signalAttributes : OrderedSet(Property) =
    signature.oclAsType(Signal).inheritedMember()->
    select(n:NamedElement | n.oclIsTypeOf(Property)->asOrderedSet()

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Classifier operation inherit(NamedElement[*]) : NamedElement[*]

  • Key: UML25-504
  • Legacy Issue Number: 18544
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Mr. Marc-Florian Wendland)
  • Summary:

    Classifier operation inherit(NamedElement[*]) : NamedElement[*] needs to be overridden for Signal, Interface, Enumeration, Component, Association

  • Reported: UML 2.5b1 — Wed, 13 Mar 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The definition in Classifier can handle redefinition for all of them, without need for any overriding

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Forked association notation ill-formed

  • Key: UML25-511
  • Legacy Issue Number: 18684
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Description: Figure 11.34 (Composite aggregation sharing a source segment) shows three association lines sharing one end (window), implying the end is owned by three classes, which isn't possible. Even if the three classes redefine window using the same name, the "shared" end would actually be separate elements in the model, though they would appear notationally the same. If this is the intention, redefinition of window should be added to the figure, and the text should explain that the "shared" graphical elements refer to three underlying model elements, (Annex B should be updated also). The notation wasn't in 2.4.1 that I can find.

  • Reported: UML 2.5b1 — Wed, 24 Apr 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The notation was in 2.4.1 and all earlier versions of UML. Quoting from UML 1.1 spec: “If there are two
    or more aggregations to the same aggregate, they may be drawn as a tree by merging the aggregation ends
    into a single segment. This requires that all of the adornments on the aggregation ends be consistent. This
    is purely a presentation option; there are no additional semantics to it”. From UML 2.4.1: “If there are two
    or more aggregations to the same aggregate, they may be drawn as a tree by merging the aggregation ends
    into a single segment. Any adornments on that single segment apply to all of the aggregation ends.”
    Some clarification is in order, both with regard to this particular notation, and with regard to the general
    question of what adornments may be suppressed in the notation for an Association. In particular, there is
    a misleading note about the default values for uniqueness and ordering that implies that the absence of a
    prop-modifier on the diagram has a semantic consequence; whereas in fact it is just another adornment that
    may be suppressed.

  • Updated: Fri, 6 Mar 2015 20:59 GMT

UML 2.5 Beta 1 9.5.3 Qualifiers

  • Key: UML25-501
  • Legacy Issue Number: 18505
  • Status: closed  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    The description of qualifiers in section 9.5.3 is unclear.
    I'm really struggling to understand it. The second paragraph
    in particular seems to unnecessarily divide qualifiers by
    the opposite end multiplicity. (In fact opposite ends, but
    the opposite end is for binary associations only.) I have
    no idea why this hints at implementation issues. Likewise
    why does the note mention tables and indices? It shouldn't
    be a note as it's a constraint on the multiplicity given
    the qualifier values.

    Here is an alternative explanation to replace all three
    paragraphs:

    A qualified Association end has qualifiers that partition
    the instances associated with an instance at that end, the
    qualified instance. Each partition is designated by a qualifier
    value, which is a tuple comprising one value for each qualifier.
    The multiplicities at the other ends of the association
    determine the number of instances in each partition. So, for
    example, 0..1 means there is at most one instance per qualifier
    value. If the lower bounds are non-zero, the qualifier values
    must be a finite set, for example, the qualifiers are typed by
    enumerations.

  • Reported: UML 2.5b1 — Tue, 26 Feb 2013 05:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    accept suggestion

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Transition redefinition

  • Key: UML25-500
  • Legacy Issue Number: 18495
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Mr. Marc-Florian Wendland)
  • Summary:

    A question: For transitions, the spec says:

    “… while the source State and trigger are preserved”

    Maybe related to not being a native speaker, but for me “preserved” means that at least the triggers defined for the extended transition must remain in the redefining transition, whereas new triggers can be added.

    Or does “preserve” mean in this context really to seal the triggers, i.e., I cannot add a new one?!

  • Reported: UML 2.5b1 — Thu, 21 Feb 2013 05:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 6395

  • Updated: Fri, 6 Mar 2015 20:59 GMT

parts should be allowed to show their interfaces

  • Key: UML25-513
  • Legacy Issue Number: 18695
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Axel Scheithauer)
  • Summary:

    The specification allows ports on parts to also show the interfaces of the type of the port:

    page 202: "Lollipop and socket symbols may optionally be shown to indicate the provided and required interfaces of the Port, using the same notation as for the Port’s definition."

    The same thing is not allowed for parts. While it might be not all that important for parts, it makes the notation incoherent.

    Proposed Resolution:
    Add following sentence:

    "Lollipop and socket symbols may optionally be shown to indicate the provided and required interfaces of the Part, using the same notation as for the Part’s definition."

  • Reported: UML 2.5b1 — Fri, 3 May 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The issue is correct, and it is indeed inconsistent not to permit this option

  • Updated: Fri, 6 Mar 2015 20:59 GMT

UML 2.5 FTF] Editorial / §15.5.1 p429

  • Key: UML25-510
  • Legacy Issue Number: 18677
  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    I don’t know whether this has already been raised or corrected

    In §15.5.1 “Summary”, p429. The second sentence starts with: “Generally, tThe ControlNodes […]” => the double “t” has to be removed.

  • Reported: UML 2.5b1 — Tue, 16 Apr 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    This has already been corrected.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Inheriting Connectors

  • Key: UML25-509
  • Legacy Issue Number: 18650
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    If parts are redefined in a subclass, should connectors of original redefined parts be inherited? Or lost/hidden/redefined too as original part does not exist in a subclass anymore, so why connectors should?

    If inherited, how should they be represented? If inherited connector is shown attached to a new redefining part, it may look ambiguous as it is NOT attached to it in the model.

    See diagram attached

  • Reported: UML 2.5b1 — Wed, 10 Apr 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    There are two aspects to this issue. Firstly, it needs to be made clearer that redefinition causes the redefining
    feature to stand in for the redefined feature in all uses of the redefined feature, including referring to it. This
    applies in many circumstances including connectors, transitions and activity edges. Secondly, there needs
    to be a well-defined notation for inherited features (such as connectors) so that a diagram can depict an
    inherited connector connecting to a redefined part.
    In the case of provided interfaces there is already a notation using a forward slash. This seems ill-advised
    since forward slash normally means derived. Change this notation to be the caret, and make the forward
    slash a deprecated option.

  • Updated: Fri, 6 Mar 2015 20:59 GMT

UML 2.5 FTF 14.2.3 Page 327 Typo

  • Key: UML25-507
  • Legacy Issue Number: 18569
  • Status: closed  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    Two examples of AnyReceivEvent rather than AnyReceiveEvent

  • Reported: UML 2.5b1 — Tue, 19 Mar 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Spelling error - Change “AnyReceivEvent” in section 14.2.3 to “AnyReceiveEvent”.

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Incorrect text on state list notation interchange

  • Key: UML25-506
  • Legacy Issue Number: 18566
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Under Figure 14.12 (Submachine Sate that uses an exit point), there is a NOTE saying the graphical notation for state lists cannot be exchanged normatively, but the interchange model for this given in the paragraph under Figure B.14 (State Shapes), starting at the third sentence.

  • Reported: UML 2.5b1 — Sun, 17 Mar 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    correct the statement cited

  • Updated: Fri, 6 Mar 2015 20:59 GMT

UML 2.5 FTF 15.3.3 Page 406 decisionInputBehavior rather than decisionInput

  • Key: UML25-508
  • Legacy Issue Number: 18570
  • Status: closed  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    The semantics of DecisionNode consistently uses
    decisionInputBehavior. However the property is
    actually decisionInput. Similarly for the notation
    and the constraint two_input_parameters.

  • Reported: UML 2.5b1 — Tue, 19 Mar 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    agreed that this is incorrect

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Clarification of use of BNF for textual notations

  • Key: UML25-538
  • Legacy Issue Number: 18802
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    In a number of places, the UML specification uses BNF to specify textual notations. However, as for all UML surface syntax, UML textual notations are generally for presentation. There is no requirement that such notations be unambiguously parsable – for example, a modeler may use arbitrary characters like “/” and “:” in a property name, even though these are used as special punctuation in the BNF for property textual notation. This can be confusing to some readers, since BNF is commonly used to specify parsable programming language text. Therefore, it may be worth providing a general clarification of this up front, perhaps in Clause 6 of the specification.

  • Reported: UML 2.5b1 — Tue, 9 Jul 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Make such a clarification in 6.4.1

  • Updated: Fri, 6 Mar 2015 20:59 GMT

ActivityParameterNode notation

  • Key: UML25-537
  • Legacy Issue Number: 18801
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    Customers are constantly asking for the ability to show parameter direction on ActivityParameterNode symbol.

    UML spec says:
    An ActivityParameterNode is notated as an ObjectNode, except that the full textual specification of the associated Parameter (see sub clause 9.4) may be used to label the ActivityParameterNode instead of the normal name/type label.

    However, I can't find Parameter BNF.

    Could you please help me to find/define a "standard" notation and don't you think it should be clarified in the spec?

  • Reported: UML 2.5b1 — Thu, 4 Jul 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    In 9.4.4 it says “There is no general notation for Parameter. Specific subclasses of BehavioralFeature define
    notation for their Parameters.”
    There are two subclasses of BehavioralFeature, Operation and Reception. Operation defines a notation for
    Parameter within its BNF. Reception says “Receptions are shown in the receptions compartment using the
    same notation as for Operations with the keyword «signal».”
    So there is only one notation for Parameter, and it should be defined there, so that ActivityParameterNode
    can refer to it.
    The notation for ParameterSet is incorrectly specified in the same way.
    This also resolves 17906.

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Avoid covariant parameters in metamodel operation redefinition

  • Key: UML25-539
  • Legacy Issue Number: 18810
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    The vast majority of operation redefinitions in the metamodel have invariant parameters, but four operations inconsistently use covariant parameter redefinition. MOF actually says nothing about whether covariant redefinition is allowed, but for consistency and type-safety the UML spec should avoid it. This can be done using a precondition that requires the parameter to be of the right type.

    Region::isRedefinitionContextValid(), State::isRedefinitionContextValid(), StateMachine::isRedefinitionContextValid(), and Classifer::conformsTo().

  • Reported: UML 2.5b1 — Thu, 11 Jul 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The operations that do not have covariant parameters are isCompatibleWith(p), isDistinguishableFrom(n,
    ns), and isConsistentWith(redefinee).
    The implementations of isCompatibleWith explicitly check the type of the parameter as part of the test:
    p.oclisKindOf(self.oclType()).
    The implementations of isDistinguishableFrom explicitly check the type of the parameter.
    The implementations of isConsistentWith call isRedefinitionContextValid() as a precondition. The truth of
    this precondition is a consequence of well-formedness rules.
    Rather than using a precondition as suggested in the issue, it is safer to make the operations explicitly check
    the parameter type in their logic.

  • Updated: Fri, 6 Mar 2015 20:59 GMT

The resolution to Issue 18528 contains incorrect OCL and operation names

  • Key: UML25-536
  • Legacy Issue Number: 18793
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    In the resolution to 18528, the operation getOperand() should have the type InteractionOperand, not InteractionFragment. Also the name getGateName() should be getName() throughout the revised text.

  • Reported: UML 2.5b1 — Tue, 2 Jul 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Change the type of Gate::getOperand(), and fix the names

  • Updated: Fri, 6 Mar 2015 20:59 GMT

The resolution to issue 18415 contains invalid OCL

  • Key: UML25-535
  • Legacy Issue Number: 18792
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    18415 was applied in Ballot 6. The revised OCL for sources_and_targets_kind contains the expressions self.informationSource.classifier and self.informationTarget.classifier, which are not well-typed. The first subexpression gives a NamedElement which in general does not have a classifier. The correct OCL should check if it is an InstanceSpecification, cast to InstanceSpecification and then check its classifier.

  • Reported: UML 2.5b1 — Tue, 2 Jul 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Revise the OCL and text related to sources_and_targets_kind, bearing in mind that an InstanceSpecification
    may in general have several classifiers

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Wording corrections in Behavior Diagrams and Activity Diagram Labels

  • Key: UML25-546
  • Legacy Issue Number: 18823
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Clause B.4.2 (Behavior Diagrams), second bullet, UseCase => Actor.

    Clause B.4.3 (Activity Diagram Labels), second bullet, UMLObjectNodes with ActivityParameterNodes => UMLShapes with ActivityParameterNodes as modelElements

  • Reported: UML 2.5b1 — Wed, 17 Jul 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Make the suggested edits

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Labels for generalization sets in UML DI

  • Key: UML25-545
  • Legacy Issue Number: 18821
  • Status: closed  
  • Source: NIST ( Mr. Raphael Barbau)
  • Summary:

    Annex B should explain how to model labels of generalization sets.

  • Reported: UML 2.5b1 — Wed, 17 Jul 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Add that generalization set constraint text are modeled as UMLLabels with generalization sets as modelElements,
    and that these labels and the ones for power types are owned by their generalization or generalization
    set edges. Also add that generalization set lines are modeled as UMLShapes with generalization sets as
    modelElements.

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Classifier and state annotations in UML DI

  • Key: UML25-541
  • Legacy Issue Number: 18817
  • Status: closed  
  • Source: NIST ( Mr. Raphael Barbau)
  • Summary:

    Annex B should explain how the

    {abstract}

    annotations in UMLClassifierShapes and the

    {extended}

    and

    {final}

    annotations in UMLStateShapes are modeled.

  • Reported: UML 2.5b1 — Wed, 17 Jul 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Clarify that these are direct instances of UMLLabel containing the text as specified by UML

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Dashed interaction lifelines in UML DI

  • Key: UML25-540
  • Legacy Issue Number: 18816
  • Status: closed  
  • Source: NIST ( Mr. Raphael Barbau)
  • Summary:

    Interaction lifelines can be dashed, but the model in Annex B cannot express this.

  • Reported: UML 2.5b1 — Wed, 17 Jul 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Add property to UMLInteractionDiagram to specify whether lifelines are dashed

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Action operation redefinition is invalid

  • Key: UML25-532
  • Legacy Issue Number: 18789
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    The operation Action::allOwnedNodes() redefines Action::allActions(). That must surely be wrong.

  • Reported: UML 2.5b1 — Tue, 2 Jul 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    yes, this is wrong

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Association::endType() is inconsistent

  • Key: UML25-531
  • Legacy Issue Number: 18788
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    The operation Association::endType() is inconsistent in multiplicity and ordering with the derived property endType which it is intended to calculate – the property is [1..*, ordered, unique} and the operation is

    {0..*, ordered, nonunique}

    . We think that the property is correct and the operation should be changed to match.

  • Reported: UML 2.5b1 — Tue, 2 Jul 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    In fact

    {ordered}

    is meaningless and unnecessary. Change both to be 1..*, unordered, unique. Introduce
    a constraint to ensure that all ends have a type, as stated in the semantics text in 11.5.3. Also change the
    definition of Property::subsettingContext which currently uses this property incorrectly.
    This resolves also 18859.

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Improve documentation of how derived properties are calculated

  • Key: UML25-534
  • Legacy Issue Number: 18791
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    Summary: Clause 6.4 needs to explain that derived properties are calculated by having an operation with the same name and return type.

  • Reported: UML 2.5b1 — Tue, 25 Jun 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Improve 6.4 to explain this.

  • Updated: Fri, 6 Mar 2015 20:59 GMT

The resolution to 18697 contains errors

  • Key: UML25-533
  • Legacy Issue Number: 18790
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    The definition for the new operation allRoles() contains no textual documentation. Also the OCL is wrong; it should read:

    allFeatures()>select(oclIsKindOf(ConnectableElement))>collect(oclAsType(ConnectableElement))->asSet()

  • Reported: UML 2.5b1 — Tue, 2 Jul 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Provide a textual documentation and change the OCL

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Template parameter rectangles

  • Key: UML25-544
  • Legacy Issue Number: 18820
  • Status: closed  
  • Source: NIST ( Mr. Raphael Barbau)
  • Summary:

    Annex B should explain how template parameter rectangles are modeled

  • Reported: UML 2.5b1 — Wed, 17 Jul 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Clarify that the template signature rectangles have template signatures as modelElements

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Ownership of property qualifier rectangles

  • Key: UML25-543
  • Legacy Issue Number: 18819
  • Status: closed  
  • Source: NIST ( Mr. Raphael Barbau)
  • Summary:

    Annex B should explain the ownership of property qualifier rectangles

  • Reported: UML 2.5b1 — Wed, 17 Jul 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Add that the UMLShape for property qualifier rectangles is owned by the UMLEdge for the association
    being qualified

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Dependencies with more than two ends in UML DI

  • Key: UML25-542
  • Legacy Issue Number: 18818
  • Status: closed  
  • Source: NIST ( Mr. Raphael Barbau)
  • Summary:

    Annex B should explain how dependency lines with more than two ends are modeled

  • Reported: UML 2.5b1 — Wed, 17 Jul 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Clarify that a UMLShape is used as the central point of the arrows.

  • Updated: Fri, 6 Mar 2015 20:59 GMT

UML 2.5 issue: Clause 6.3 should contain a definition of "execution scope"

  • Key: UML25-483
  • Legacy Issue Number: 18376
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    The semantics of static are defined with respect to a concept called “execution scope”. I think that concept needs a definition in section 6.3. Maybe the terminology is wrong – it might be “model instance” or “model execution” or something, but there needs to be a term for a set of related executing instances that comprise an instantiation of the model.

  • Reported: UML 2.5b1 — Tue, 15 Jan 2013 05:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Agreed. The concept of “execution scope” is also relevant to the reading of classifier extents.

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Fixed-point issues with the definition of default values for literals

  • Key: UML25-482
  • Legacy Issue Number: 18287
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    The definition of LiteralBoolean in the XMI for UML1.5 includes the following:

    <packagedElement xmi:type="uml:Class" xmi:id="LiteralBoolean" name="LiteralBoolean">

    …

    <ownedAttribute xmi:type="uml:Property" xmi:id="LiteralBoolean-value" name="value" visibility="public">

    …

    <defaultValue xmi:type="uml:LiteralBoolean" xmi:id="LiteralBoolean-value-_defaultValue"/>

    </ownedAttribute>

    …

    So the default value for value, which is correctly specified as false in the model, is specified by the absence of a value attribute as “the default value for LiteralBoolean::value” in the XMI. This is circular and ill-defined.

    One issue is with the XMI specification. The rule that property values should not be serialized when they have their default value should not apply when those properties are being used to define default values for themselves. Another issue is with the UML xmi. This needs to serialize the value for the default value of literals, regardless of other considerations. In the case above, value=”false”.

  • Reported: UML 2.5b1 — Wed, 5 Dec 2012 05:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Resolving Issue 18286 against XMI will make it valid to serialize the default value of the value property for
    literals. For UML 2.5, we will serialize them. XMI 2.5 will be published at the same time as UML 2.5 and
    UML 2.5 will be serialized as an instance of it.

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Fix the notation to allow assignment of a decision to partition when the swimlanes are not practical.

  • Key: UML25-475
  • Legacy Issue Number: 18192
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Fix the notation to allow assignment of a decision to partition when the swimlanes are not practical.

  • Reported: UML 2.5b1 — Mon, 22 Oct 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The notation already allows this, as described in Subclause 15.6.4 of the UML 2.5 beta specification. Under
    “Activity Partitions”, it states “In some diagramming situations, using parallel lines to delineate ActivityPartitions
    is not practical. An alternative is to place the partition name in parenthesis above the ActivityNode
    name. . . ” Thus the desired alternative notation is already provided for any ActivityNode. However, since
    the associated figure only shows Actions, the applicability to other ActivityNodes could be clearer.

  • Updated: Fri, 6 Mar 2015 20:59 GMT

UML association semantics vis-a-vis Interfaces (and other types of classifiers)

  • Key: UML25-474
  • Legacy Issue Number: 18185
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The semantics of associations are specified in terms of links, which the UML 2.4 spec defines as: "a tuple with one value for each end of the association, where each value is an instance of the type of the end" and the 2.5 spec as "a tuple with one value for each memberEnd of the Association, where each value is an instance of the type of the end". However, the specs include several examples of associations between interfaces. Since interfaces are abstract classifiers they cannot have instances ("Interfaces may not be instantiated"), the semantics of associations whose ends terminate on interfaces cannot be described by the above semantics.

    Some other semantics need to be provided for such cases.

    Furthermore, the issue extends to other types of classifiers (e.g., collaborations) where the meaning of "instance" is not straightforward.

  • Reported: UML 2.5b1 — Fri, 19 Oct 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    With regard to Interfaces, the issue relates to the wording “an instance of the type at the end”, which should
    be loosened to include “an instance of a type that implements the type at the end”.

  • Updated: Fri, 6 Mar 2015 20:59 GMT

confusing wording and terminology for TransitionKind in the section “Transition kinds relative to source”.

  • Key: UML25-473
  • Legacy Issue Number: 18184
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    A "local" transition is a group transition that emanates from a composite state (i.e., it is a group transition representing transitions form any contained substate of the composite source state) and terminates on an internal subvertex (the target vertex). This is OK and quite useful. However, the wording is confusing as is the terminology.

  • Reported: UML 2.5b1 — Fri, 19 Oct 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 13920

  • Updated: Fri, 6 Mar 2015 20:59 GMT

The derived property Classifier::/inheritedMember does not correctly define the meaning of inheritance

  • Key: UML25-472
  • Legacy Issue Number: 18177
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    UML 2.5: “The derived property Classifier::/inheritedMember does not correctly define the meaning of inheritance”, with this email discussion attached

  • Reported: UML 2.5b1 — Thu, 18 Oct 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    This issue boils down to the following key points.
    1. The property inheritedMember, which is part of the calculation of the members of a Classifier, does
    not include private members of generalizing Classifiers.
    2. Private properties of generalizing Classifiers should be instantiable as slots in InstanceSpecifications,
    even though they are not “inherited” according to 1.
    3. Something of a disagreement about whether redefined properties may have slots, even though they are
    excluded from inheritedMember. The resolution is to allow slots to be instantiable for private inherited properties, but still to hide redefined
    properties (which is done through the operation inherit()). This is done by defining and using a new operation
    for Slot constraints. Some other documentation is improved for clarity.
    This also resolves 18414.

  • Updated: Fri, 6 Mar 2015 20:59 GMT

UML 2.5 issue: structural features with isStatic = true may not have a slot in InstanceSpecifications

  • Key: UML25-471
  • Legacy Issue Number: 18176
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    There should be a constraint that structural features with isStatic = true may not have a slot in InstanceSpecifications

  • Reported: UML 2.5b1 — Thu, 18 Oct 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    No, there should not. Slots can be used to model the values of static features.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Notation for state machine specializations

  • Key: UML25-478
  • Legacy Issue Number: 18248
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    In chapter 14, the notation for state machine specializations uses <<extended>> and

    {final}.


    <<extended>> is defined as a constraint-based keyword for a Region or a StateMachine.
    However, the notation in 14.3.4 clearly indicates that a state can be extended.
    There should be a new entry in the keyword table specifying the constraint-based application
    of the extended keyword to a State that has a non-empty redefinedState.


    The notation only covers the possibility of a modeler declaring states and transitions as {final}

    .
    Conceptually, a modeler should also be able to declare a region as

    {final}.
    There is no definition for what {final}

    is. Since it requires explicit declaration from the modeler,
    it should be defined as a stereotype-based keyword notation with a new stereotype <<final>> defined in the UML standard profile.

    <<extended>> and

    {final}

    should be explicitly defined in the semantics section in 14.3.3.

  • Reported: UML 2.5b1 — Mon, 5 Nov 2012 05:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 12380

  • Updated: Fri, 6 Mar 2015 20:59 GMT

UML2.5 issue : missing constraints on aggregation / composition

  • Key: UML25-477
  • Legacy Issue Number: 18228
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    As far as I know, a Property may only be marked as an aggregation or composition if either (a) it is not an association end or (b) it is the end of a binary association and the other end is not marked as an aggregation or composition. The spec does not actually say this clearly, and there is no OCL to enforce it.

  • Reported: UML 2.5b1 — Thu, 25 Oct 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The text for Association says “A binary Association may represent a composite aggregation. . . ”. It doesn’t
    explicitly exclude the undesirable configurations.

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Two different Dashed Arrow Styles for Reply message in Figure 17.2 Interaction Example

  • Key: UML25-476
  • Legacy Issue Number: 18226
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    The example in Figure 17.2 has different dash types for the two reply messages.

    This is confusing since it is by no means significant.

  • Reported: UML 2.5b1 — Tue, 23 Oct 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Agreed. Amend Figure 17.2 in a sense that both reply arrows are identical.

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Error in Dependency notation example

  • Key: UML25-481
  • Legacy Issue Number: 18275
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

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

    Subclause: 7.7.4

    In Figure 7.18, the name within the guillemets should be a stereotype name, not the dependency name. The dependency name should be separate from the stereotype.

  • Reported: UML 2.5b1 — Tue, 20 Nov 2012 05:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 15046

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Error in diagram using StringExpressions

  • Key: UML25-480
  • Legacy Issue Number: 18273
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

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

    Subclause: 7.4.5

    In Figure 7.6, replace $<resource>$ with $a<Resource>$, $<resource>Allocation$ with $a<Resource>Allocation$ and $<resourceKind>$ with $the<ResourceKind>$ (for Request) or $a<ResourceKind>$ (for System).

    The notation for template binding shown in Figure 7.6 is also inconsistent with the description in 7.3.4.

  • Reported: UML 2.5b1 — Tue, 20 Nov 2012 05:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Agreed.
    This also resolves Issue 17794.

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Inconsistent template binding notation example

  • Key: UML25-479
  • Legacy Issue Number: 18271
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

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

    Subclauses: 7.3.4, 9.3.5

    In 7.3.4, it states that “A TemplateBinding is shown as a dashed arrow with the tail on the bound element and the arrowhead on the template and the keyword «bind». The binding information may be displayed as a comma-separated list of template parameter substitutions…” However, Figure 9.5 in 9.3.5 shows an example of a classifier binding using a realization arrow, not just a plain dashed arrow, and has the template parameter substitutions appearing within angle brackets. Both of these things are inconsistent with 7.3.4.

  • Reported: UML 2.5b1 — Tue, 20 Nov 2012 05:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The same problem was there in 2.4

  • Updated: Fri, 6 Mar 2015 20:59 GMT

UML 2.5 issue; the word "individual" is incorrect in 9.8

  • Key: UML25-484
  • Legacy Issue Number: 18384
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    Clause 9.8 uses the word “individual” in several places where it would be correct and consistent to use “instance”.

  • Reported: UML 2.5b1 — Tue, 22 Jan 2013 05:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Replace individual by instance and change “individual instance” to “instance.”

  • Updated: Fri, 6 Mar 2015 20:59 GMT

misleading omission

  • Key: UML25-553
  • Legacy Issue Number: 18947
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    The text in 6.1 and Annex E describing the serialization compatibility between 2.4.1 and 2.5 omits to mention that the clientDependency attribute needs to be present in 2.4.1 and absent in 2.5 for all NamedElements that are the clients of a Dependency. This omission is misleading

  • Reported: UML 2.5b1 — Fri, 20 Sep 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Include wording in 6.1 and Annex E to explain this change. Also point out that ordering may have been
    either added or removed from some properties for semantic consistency

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Validation errors in UML metamodel

  • Key: UML25-552
  • Legacy Issue Number: 18873
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    A body condition is specified for operation '<<oMGIssueTag>> <Operation> clientDependency () : Dependency [0..*]', but it is not a query.

    A body condition is specified for operation '<Operation> isConsistentWith (redefinee : RedefinableElement) : Boolean', but it is not a query.

    Derived union '<<oMGIssueTag>> <Property> / action : Action [0..1]' is not read only.

    Derived union '<<oMGIssueTag>> <Property> / action : Action [0..1]' is not read only.

    Derived union '<<oMGIssueTag>> <Property> / classifier : Classifier [0..1]' is not read only.

    Derived union '<<oMGIssueTag>> <Property> / directedRelationship : DirectedRelationship [0..*]' is not read only.

    Derived union '<<oMGIssueTag>> <Property> / directedRelationship : DirectedRelationship [0..*]' is not read only.

    Derived union '<<oMGIssueTag>> <Property> / memberNamespace : Namespace [0..*]' is not read only.

    Derived union '<<oMGIssueTag>> <Property> / redefinableElement : RedefinableElement [0..*]' is not read only.

    Derived union '<<oMGIssueTag>> <Property> / redefinableElement : RedefinableElement [0..*]' is not read only.

    Derived union '<<oMGIssueTag>> <Property> / relationship : Relationship [0..*]' is not read only.

    Derived union '<<oMGIssueTag>> <Property> / structuredClassifier : StructuredClassifier [0..*]' is not read only.

    IRJA0273E "<Package> Activities" has one or more package import cycles involving "<Package> StructuredClassifiers, <Package> Packages, <Package> CommonStructure, <Package> Classification, <Package> Actions."

    IRJA0273E "<Package> CommonBehavior" has one or more package import cycles involving "<Package> StructuredClassifiers, <Package> Packages, <Package> CommonStructure, <Package> Classification."

    IRJA0273E "<Package> Deployments" has one or more package import cycles involving "<Package> Packages, <Package> CommonStructure, <Package> Classification, <Package> StructuredClassifiers."

    IRJA0273E "<Package> InformationFlows" has one or more package import cycles involving "<Package> Packages, <Package> CommonStructure, <Package> Classification, <Package> StructuredClassifiers, <Package> UseCases."

    IRJA0273E "<Package> Interactions" has one or more package import cycles involving "<Package> Classification, <Package> StructuredClassifiers, <Package> Packages, <Package> CommonStructure."

    IRJA0273E "<Package> SimpleClassifiers" has one or more package import cycles involving "<Package> StructuredClassifiers, <Package> Packages, <Package> CommonStructure, <Package> Classification."

    IRJA0273E "<Package> StateMachines" has one or more package import cycles involving "<Package> StructuredClassifiers, <Package> Packages, <Package> CommonStructure, <Package> Classification."

    IRJA0273E "<Package> UML" has one or more package import cycles involving "<Package> StructuredClassifiers, <Package> Packages, <Package> CommonStructure, <Package> Classification, <Package> Actions."

    IRJA0273E "<Package> UseCases" has one or more package import cycles involving "<Package> Packages, <Package> CommonStructure, <Package> Classification, <Package> StructuredClassifiers."

    IRJA0273E "<Package> Values" has one or more package import cycles involving "<Package> StructuredClassifiers, <Package> Packages, <Package> CommonStructure, <Package> Classification."

    Redefining element '<<oMGIssueTag>> <Operation> isDistinguishableFrom (n : NamedElement, ns : Namespace) : Boolean' is not consistent with redefined element '<Operation> isDistinguishableFrom (n : NamedElement, ns : Namespace) : Boolean'. UML::Interactions::Gate::isDistinguishableFrom Model Validation Problem

    Redefining element '<Operation> isConsistentWith (redefinee : RedefinableElement) : Boolean' is not consistent with redefined element '<Operation> isConsistentWith (redefinee : RedefinableElement) : Boolean'. UML::Activities::ActivityNode::isConsistentWith Model Validation Problem

    Redefining element '<Property> region : Region [0..*]' is not consistent with redefined element '<<oMGIssueTag>> <Property> / redefinableElement : RedefinableElement [0..*]'. UML::StateMachines::A_redefinitionContext_region::region Model Validation Problem

    Redefining element '<Property> state : State [0..*]' is not consistent with redefined element '<<oMGIssueTag>> <Property> / redefinableElement : RedefinableElement [0..*]'. UML::StateMachines::A_redefinitionContext_state::state Model Validation Problem

    Redefining element '<Property> structuredClassifier : StructuredClassifier [0..1]' is not consistent with redefined element '<<oMGIssueTag>> <Property> / structuredClassifier : StructuredClassifier [0..*]'. UML::StructuredClassifiers::A_ownedAttribute_structuredClassifier::structuredClassifier Model Validation Problem

    Redefining element '<Property> transition : Transition [0..*]' is not consistent with redefined element '<<oMGIssueTag>> <Property> / redefinableElement : RedefinableElement [0..*]'. UML::StateMachines::A_redefinitionContext_transition::transition Model Validation Problem

  • Reported: UML 2.5b1 — Wed, 14 Aug 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The operations with bodies definitely need to be marked as queries.
    The derived unions definitely need to be marked as readonly. Cyclic package imports are not invalid.
    Three of the redefinitions are in fact invalid:
    region : Region [0..*]’ is not consistent with redefinableElement : RedefinableElement [0..*]
    state : State [0..*]’ is not consistent with redefined element redefinableElement : RedefinableElement [0..*]
    transition : Transition [0..*]’ is not consistent with redefined element redefinableElement : RedefinableElement
    [0..*]’.
    They appear in figure 14.35. The navigable ends of these associations are derived to mean “the nearest
    containing”. The non-navigable ends should be subsets (e.g. “the subset of elements redefined in this
    context that happen to be states”), not redefinitions.
    The remainder are not errors.

  • Updated: Fri, 6 Mar 2015 20:59 GMT

PrimitiveTypes::UnlimitedNatural lacks an XML-compatible serialization for the 'unbounded' value

  • Key: UML25-547
  • Legacy Issue Number: 18831
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    Some tools serialize 'unbounded' as '*' as shown in the UML spec, other tools serialize 'unbounded' as '-1'.
    The UML spec needs a clear specification for the serialization of 'unbounded' to ensure interchange across tools.

  • Reported: UML 2.5b1 — Thu, 25 Jul 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The W3 XML Schema 1.1 DataTypes specification includes an example of a definition of a datatype that is
    conceptually equivalent to that of PrimitiveTypes::UnlimitedLiteral in clause 2.4.1.3 of the XML Schema
    1.1 DataTypes specification: http://www.w3.org/TR/2012/REC-xmlschema11-2-20120405/#atomic-vs-list
    2.4.1.3 Union datatypes
    Union types may be defined in either of two ways. When a union type is ’constructed’ by ’union’, its
    ’value space’, ’lexical space’, and ’lexical mapping’ are the “ordered unions” of the ’value spaces’, ’lexical
    spaces’, and ’lexical mappings’ of its ’member types’. It will be observed that the ’lexical mapping’ of a
    union, so defined, is not necessarily a function: a given ’literal’ may map to one value or to several values
    of different ’primitive’ datatypes, and it may be indeterminate which value is to be preferred in a particular
    context. When the datatypes defined here are used in the context of [XSD 1.1 Part 1: Structures], the xsi:type
    attribute defined by that specification in section xsi:type can be used to indicate which value a ’literal’ which
    is the content of an element should map to. In other contexts, other rules (such as type coercion rules) may
    be employed to determine which value is to be used. When a union type is defined by ’restricting’ another
    ’union’, its ’value space’, ’lexical space’, and ’lexical mapping’ are subsets of the ’value spaces’, ’lexical
    spaces’, and ’lexical mappings’ of its ’base type’. ’Union’ datatypes are always ’constructed’ from other
    datatypes; they are never ’primitive’. Currently, there are no ’built-in’ ’union’ datatypes.
    Example
    A prototypical example of a ’union’ type is the maxOccurs attribute on the element element in XML Schema
    itself: it is a union of nonNegativeInteger and an enumeration with the single member, the string “unbounded”,
    as shown below.
    <attributeGroup name="occurs">
    <attribute name="minOccurs" type="nonNegativeInteger"
    use="optional" default="1"/>
    <attribute name="maxOccurs"use="optional" default="1">
    <simpleType>
    <union>
    <simpleType>
    <restriction base=’nonNegativeInteger’/>
    </simpleType>
    <simpleType>
    <restriction base=’string’>
    <enumeration value=’unbounded’/>
    </restriction>
    </simpleType>
    </union>
    </simpleType>
    </attribute>
    </attributeGroup>
    It is not possible to follow the above example because theMOF/XMI restricts a schemaType to be a datatype
    defined in the XML Schema DataType specification

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Assocation display options too narrow

  • Key: UML25-549
  • Legacy Issue Number: 18848
  • Status: closed  
  • Source: NIST ( Mr. Raphael Barbau)
  • Summary:

    The options on class and composite diagrams for how associations are displayed (with/without dots, etc) apply to other diagrams, such as package and object diagrams.

  • Reported: UML 2.5b1 — Thu, 1 Aug 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Introduce a class for the association options that generalizes the classes for structure diagrams and use case
    diagrams.

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Annex E lacks sub-clauses for the XMI details for StandardProfile and UMLDI

  • Key: UML25-548
  • Legacy Issue Number: 18837
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    Provide sub-clauses like the resolution for issue 18831

  • Reported: UML 2.5b1 — Wed, 31 Jul 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    This resolution depends on 18831.
    The nsPrefixes are taken from the UML 2.5 Beta1 XMI artifacts

  • Updated: Fri, 6 Mar 2015 20:59 GMT

UML 2.5 issue: subsettingContext() has incorrect logic

  • Key: UML25-551
  • Legacy Issue Number: 18859
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    The current logic says

    if association <> null then association.endType->excluding(type)

    But if the association has many ends of the same type, this is the wrong logic. Note this is independent of the fact that endType is a set – if it were a bag or sequence all occurrences of the type would be removed.

    It needs to work directly with the memberEnds – remove the current property from the memberEnds and collect the remaining types.

  • Reported: UML 2.5b1 — Wed, 7 Aug 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 18788

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Headed composite and not ownedElement

  • Key: UML25-550
  • Legacy Issue Number: 18858
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    In Figure B.3 (UML Diagrams and Diagram Elements) the heading property is composite, but not an ownedElement.

  • Reported: UML 2.5b1 — Wed, 7 Aug 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The heading property is just to identify the label that should conform to the heading syntax given in Annex
    A. It is not necessary for it to be composite. Heading labels will be owned by the diagram element they are
    nested in, like other labels

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Activity::structuredNode is incorrectly marked as readOnly = true

  • Key: UML25-554
  • Legacy Issue Number: 18948
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    Activity::structuredNode is incorrectly marked as readOnly = true

  • Reported: UML 2.5b1 — Fri, 20 Sep 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    This appears to be a throwback to 2.4, in which it was also marked as derived - it got marked as not derived
    by the resolution to urgent issue 16232. In 2.4 it was readonly and derived; in 2.4.1 it was neither (which
    means that readonly was removed when the issue was applied, even though the issue did not call for that);
    in 2.5 it has for some reason become readonly again. The only explanation I might offer for this is that
    somebody noticed while applying 16232 that readonly needed to be removed and did it, but this change did
    not get checked in.
    The resolution is to set readOnly to false. The only impact on the specification document is figure 16.45,
    which needs to be changed. The generated classifier descriptions do not contain the

    {readOnly}

    annotation

    • this is a separate issue which will need to be addressed in the future but is too disruptive to address at
      the time of writing. The consequence is that no change is needed to the generated classifier description for
      Activity::structuredNode.
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Missing word in section 7.4.3, "Semantics"

  • Key: UML25-200
  • Legacy Issue Number: 17601
  • Status: closed  
  • Source: Object Management Group ( Andrew Watson)
  • Summary:

    "associated whose subexpressions"

    There's clearly a word missing between "associated" and "whose".

  • Reported: UML 2.5b1 — Wed, 19 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Agreed. The missing word is “StringExpression

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Four typos

  • Key: UML25-199
  • Legacy Issue Number: 17600
  • Status: closed  
  • Source: Object Management Group ( Andrew Watson)
  • Summary:

    1. 13.4 Classifier Descriptions, Association Ends, p315
    "Behaviosr" -> "Behavio(u)r"

    2. 7.4.3 Semantics, Namespaces, p32
    "A namespace may also import NamedElements ...". "namespace" should be capitalised ("Namespace").

    3. 7.8 Classifier Descriptions, ElementImport [Class], Attributes, p49
    "whetherthe" -> "whether the".

    4. 9.9 Classifier Descriptions, Operations, p165
    "is the same or a subtype as" -> "is the same or a subtype of".

  • Reported: UML 2.5b1 — Wed, 19 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    1. “Behaviosr” no longer appears in the text. No change.
    2. The problem remains: fix it.
    3. “whetherthe” no longer appears in the text. No change.
    4. “is the same or a subtype as” appears in ValueSpecification::isCompatibleWith and Property::isCompatibleWith;
    fix it.

  • Updated: Fri, 6 Mar 2015 20:59 GMT

ElementImport semantics

  • Key: UML25-206
  • Legacy Issue Number: 17610
  • Status: closed  
  • Source: Object Management Group ( Andrew Watson)
  • Summary:

    "An ElementImport identifies an Element in a different Namespace, and allows the Element to be referenced using its name without a qualifier in the Namespace owning the ElementImport."

    Firstly, different to what?

    Secondly, "its name" is confusing, since the name may be changed via aliasing.

    I think this should be rewritten as: "An ElementImport identifies a NamedElement in a Namespace other than the one that owns it, and allows that NamedElement to be referenced using an unqualified name in the Namespace owning the ElementImport."

  • Reported: UML 2.5b1 — Wed, 19 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Same name" vs. "indistinguishable name"

  • Key: UML25-205
  • Legacy Issue Number: 17608
  • Status: closed  
  • Source: Object Management Group ( Andrew Watson)
  • Summary:

    " ...it also excludes PackageableElements that would have the same name as each other when imported."

    Surely this should say " ... it also excludes PackageableElements that would have indistinguishable names when imported."

    (See discussion of Namespace semantics on p33).

  • Reported: UML 2.5b1 — Wed, 19 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Further clarify Element ownership constrains

  • Key: UML25-204
  • Legacy Issue Number: 17606
  • Status: closed  
  • Source: Object Management Group ( Andrew Watson)
  • Summary:

    13. p26: "Every Element in a model must be owned by some other Element of that model ..."

    "Some" could perhaps be more precisely stated - "Every Element in a model is owned by exactly one other Element of that model ..."

  • Reported: UML 2.5b1 — Wed, 19 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Semantic conformance implies Abstract Syntax conformance

  • Key: UML25-203
  • Legacy Issue Number: 17605
  • Status: closed  
  • Source: Object Management Group ( Andrew Watson)
  • Summary:

    The conformance statement notes that "Model interchange conformance implies abstract syntax conformance" and "Diagram interchange conformance implies both concrete syntax conformance and abstract syntax conformance".

    As far as I can tell, Semantic conformance implies Abstract Syntax conformance. For consistency, this could also be noted.

  • Reported: UML 2.5b1 — Wed, 19 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 20:59 GMT

isConsistentWith() definition broken

  • Key: UML25-207
  • Legacy Issue Number: 17612
  • Status: closed  
  • Source: Object Management Group ( Andrew Watson)
  • Summary:

    The definition of "isConsistentWith(redefinee : RedefinableElement) : Boolean" is broken in at least two ways.

    Firstly, the OCL includes the term "op.ownedParameter->at(1)" which should presumably be "op.ownedParameter->at" (substitute letter "i" for digit "1").

    Secondly, the OCL and textual definition say that each parameter is checked for conformance in the same direction, regardless of whether they're "in" or "out" parameters.

    To deliver a safe substitutability (aka conformsTo) relationship, the "in" parameters of the substituting operation must conform to the "in" parameters of the substituted operation, but the "out" parameters must conform in the opposite direction (i.e. "out" parameters of the substituted operation conform to the "out" parameters of the substituting operation).

    Since "inout" parameters pass parameters in both directions, they must conform in both directions simultaneously (which is a good definition of being "the same type").

    Correcting the first bug is trivial. However, unless the second bug is also corrected, the given definition of isConsistentWith() will flag many type-safe substitutions as "not consistent", and many unsafe substitutions as "consistent". It must be corrected.

  • Reported: UML 2.5b1 — Wed, 19 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 15499

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Suggested improvements to conformance section

  • Key: UML25-202
  • Legacy Issue Number: 17604
  • Status: closed  
  • Source: Object Management Group ( Andrew Watson)
  • Summary:

    p15: "A conforming UML 2.5 tool shall be able to load and save XMI in UML 2.4.1 format as well as UML 2.5 format." It would be worth inserting a reference to Annexe E (p 784) which gives a rationale for this conformance requirement.

    p15: "A tool demonstrating diagram interchange conformance can import and export conformant DI ..." Similarly, it would be worth inserting a reference here to Annexe B (p736) on UML Diagram Interchange.

  • Reported: UML 2.5b1 — Wed, 19 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Accept the suggestions

  • Updated: Fri, 6 Mar 2015 20:59 GMT

PDF links to Primitive Types don't work

  • Key: UML25-201
  • Legacy Issue Number: 17602
  • Status: closed  
  • Source: Object Management Group ( Andrew Watson)
  • Summary:

    The comprehensive hyperlinks in the PDF version of the specification are useful when reading it online. However, the links for the Primitive types (Boolean, Integer, String, Real, UnlimitedNatural) don't work.

  • Reported: UML 2.5b1 — Wed, 19 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The individual primitive types don’t have their own heading in the document. Make the hyperlinks go to the
    clause heading for clause 21.

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Superfluous word on p309

  • Key: UML25-208
  • Legacy Issue Number: 17614
  • Status: closed  
  • Source: Object Management Group ( Andrew Watson)
  • Summary:

    "(i.e. the type of the corresponding Parameters, order, must be the same)"

    The word "order" and the two commas are superfluous.

  • Reported: UML 2.5b1 — Wed, 19 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

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

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

    UML says:

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

    Mapping this to xsd:double is just wrong:

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

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

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

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

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

    3.3.5.1 Value Space

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

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

    Equality and order for double are defined as follows:

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

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

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

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

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

    3.3.5.2 Lexical Mapping

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

    Lexical Space

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

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

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

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

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

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

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

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

    3.3.5.3 Facets

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

    whiteSpace = collapse (fixed)

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

    pattern

    enumeration

    maxInclusive

    maxExclusive

    minInclusive

    minExclusive

    assertions

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

    ordered = partial

    bounded = true

    cardinality = finite

    numeric = true

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

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

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

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

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

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

Definition of allOwningPackages()

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

    NamedElement:: allOwningPackages() is documented as

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

    But the OCL is

    if namespace.oclIsKindOf(Package)

    then

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

    owningPackage->union(owningPackage.allOwningPackages())

    else

    null

    endif

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

    I think it should instead read:

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

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

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

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

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

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

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

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

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

    and

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

    Any comments?

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

Several UMLDI redefining associations are invalid

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

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

    Figure B.4:

    A_UMLEdge_source_sourceEdge
    A_UMLEdge_target_targetEdge

    Figure B.5

    A_UMLNameLabel_modelElement_umlDiagramElement
    A_UMLRedefines_modelElement_umlDiagramElement

    Figure B.7

    A_UMLStereotypePropertyValueLabel_modelElement_umlDiagramElement

    Figure B.8

    A_UMLDiagramElement_localStyle_styledElement
    A_UMLDiagramElement_sharedStyle_styledElement

    Figure B.10

    A_UMLClassifierShape_modelElement_umlDiagramElement

    Figure B.11

    A_UMLAssociationEndLabel_modelElement_umlDiagramElement
    A_UMLMultiplicityElement_modelElement_umlDiagramElement

    Figure B.13

    A_UMLBehaviorDiagram_modelElement_umlDiagramElement
    A_UMLStateMachine_modelElement_umlDiagramElement
    A_UMLActivityDiagram_modelElement_umlDiagramElement
    A_UMLInteractionDiagram_modelElement_umlDiagramElement

    Figure B.14

    A_UMLStateShape_modelElement_umlDiagramElement

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Timing Events Question / Issue

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

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

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

    The spec does not seem to be specific.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    According to the above, this means that

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

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

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

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

UML: No restrictions on what seem to be meaningless associations

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

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

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

Need packages overview diagram and explicit depiction of package dependencies

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

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

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

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

typo in 12.2.3 Model

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

    Last paragraph in 12.2.3 Model

    Currently

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

    Propose

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

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

Inconsistent approach to type conformance

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

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

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

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

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

    1.2 On p308-309 it says:

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

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

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

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

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

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

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

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

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

"Object identity" undefined

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

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

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

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

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

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

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

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

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

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

    2. Undefined semantics as a result

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

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

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

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

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

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

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

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

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

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

Notation for Variables and Variable Actions is very vague and incomplete

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

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

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

Rg. Realization and InterfaceRealization

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

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

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

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

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

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

Clarification needed about the semantics of stereotype specialization and stereotype application

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

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

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

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

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

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

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

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

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

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

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

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

    { redefines S1::base_Classifier }

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

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

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

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

Issue for Figure 17.18

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

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

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

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

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

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

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

    (1) is reflected in figure 17.1

    (2) is under-specified.

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

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

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

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

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

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

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

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

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

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

Issue with Reply message in interactions (UML 2.5 Beta)

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

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

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

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

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

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

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

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

Incorrect notation in figure 14.37

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

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

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

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

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

    ML 2.5 section 17.2.3 Interaction semantics says:

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

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

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

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

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

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

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

    Figures 14.37 and 14.38 show the word

    {extended}

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

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

UML2.5: Clarification about UML profiles

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

    12.3.1 Summary

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

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

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

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

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

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

    The next paragraph is the same:

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

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

    Again, the generality is lost in the next sentence:

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

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

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

    12.3.3 Semantics

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

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

    ProfileApplication.

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

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

    Again, the generality is lost.

    Stereotypes

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

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

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

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

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

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

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

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

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

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

Serilaization of required stereotypes

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

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

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

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

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

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

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

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

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

Reply messages now mandatory?

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

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

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

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

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

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

Semantics of TimeConstraints and DurationConstraints

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

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

    Subclause: 8.5.3

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

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

Notation for DurationObservation with two event elements

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

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

    Subclause: 8.4.4

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

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

Semantics of Namespaces

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

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

    Subclause: 7.4.3

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

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

Stereotype for extended bound element realization

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

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

    Subclause: 7.3.3

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

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

Interactions and parameter assignments

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

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

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

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

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

    Shall we allow this in Interactions?

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

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

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

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

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

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

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

Semantics of Message argument mapping in Interactions

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Meaning of access to constrainedElements

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

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

    Subclause: 7.6.3

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

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

Clarify aliasing in Namespaces

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

    A couple of sentences explaining aliasing in Namespaces would be useful in the Namespace semantics section (7.4.3).

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

Clarify ownership vs. membership for NamedElements

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

    "A namespace may also import NamedElements from other Namespaces, in which case these, along with the ownedMembers, are members of the importing Namespace."

    A sentence clarifying ownership vs. membership for NamedElements would be useful. As far as I can tell, every NamedElement is owned by the Namespace in which it was created, but is a member of both its owning Namespace and every Namespace into which it has been successfully imported.

    (However, where a NamedElement is a PackageableElement, importing it creates an ElementImport which becomes a member of the Namespace instead, to allow for the possibility of aliasing of the PackageableElement's name.)

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

Fuzzy diagrams

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

    When viewed at high magnification (e.g. 500%), most of the diagrams in the PDF are quite fuzzy, and are clearly bitmaps. If possible, please regenerate them as vector diagrams.

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

Missing Example of TemplateBinding with model element "Class"

  • Key: UMLR-421
  • Legacy Issue Number: 19723
  • Status: open  
  • Source: gmail.com ( Jose Asdrubal Asencio)
  • Summary:

    I've been reviewing template binding where specifies substitution of Parameters in a Template Class and I found that:

    1- UML 2.5 haven't provided an example using class element model with binding relationship.

    2- UML 2.5 haven't provided an example, and example in code in whatever language programming or a note where explain what does it mean binding in code.

    I 've reviewed examples at Internet and there are not good examples relate with binding. Just very basic examples.

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

UML 2.5 beta issue - Operation notation is wrong

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

    There is a paragraph in Operation notation 9.6.4 that says this:

    “The return result of the Operation may be expressed as a return parameter, or as the type of the Operation. For example toString(return: String) …”

    This is wrong. If it means anything, it means an in parameter called return. The BNF does not allow return as a term for <direction>, but if it did, then the correct example would be this:

    toString(return result : String)

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

Incorrect sentence

  • Key: UMLR-339
  • Legacy Issue Number: 19430
  • Status: open  
  • Source: toshiba-tsip.com ( VIRESH MOHAN)
  • Summary:

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

    The return value is 96 but the comment suggests 69 is getting assigned to v.

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

Incomplete sentence

  • Key: UMLR-338
  • Legacy Issue Number: 19427
  • Status: open  
  • Source: toshiba-tsip.com ( VIRESH MOHAN)
  • Summary:

    In the explanation for "Entering a State" concept w.r.t. alternate entry points for a composite state, it appears that the description for "Entry point entry" is not a complete sentence.

    Entry point entry:

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

meaning is not clear

  • Key: UMLR-336
  • Legacy Issue Number: 19420
  • Status: open  
  • Source: toshiba-tsip.com ( VIRESH MOHAN)
  • Summary:

    In the part where the adornments on Association symbol are explained, the third bullet point seems to be confusing.

    A property string may be placed near the Association symbol, but far enough from any end to not be confused with a property string on an end.

    Though I am not in a position to say whether it's incorrect or not but I think it's bit convoluted as in "property string is placed so that it's not confused with a property string"?

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