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

UML 2.4 BRM RTF — Open Issues

  • Key: UML241
  • Issues Count: 21
Open Closed All
Issues not resolved

Issues Descriptions

Loop notation

  • Key: UML241-45
  • Legacy Issue Number: 7590
  • Status: open  
  • Source: TMNA Services ( Jim Schardt)
  • Summary:

    I am putting together an example of a sequence diagram using the loop
    combinedFragment. The spec seems confusing. Just where does a guard
    condition that is not the minint or maxint get placed?

    According the CombinedFragemt definition, I can describe a minimum and
    maximum number of times to perform the loop. "The Guard may include a lower
    and an upper number of iterations of the loop as well as a Boolean
    expression." I can also describe a guard condition. However, the notation
    describes a syntax like LOOP (minint, maxint) with no extra guard.

    Do I place the extra guard as an interaction constraint in a region as shown
    in figure 333. Is this allowed? Do I only get one interaction constraint
    (either the min,maxint or the separate interaction constraint in the body of
    the loop combined fragment?

    I would like to say something like LOOP 1, * [status = notFound] or LOOP
    (1,*,status = notFound). I suppose I could say LOOP (1,[status = notFound]).
    All of these should say that the loop interaction is performed at least
    once. After that if the status is "notFound" then the loop continues
    otherwise the loop terminates.

  • Reported: UML 1.4.2 — Mon, 12 Jul 2004 04:00 GMT
  • Updated: Fri, 19 Aug 2016 09:33 GMT


  • Key: UML241-46
  • Legacy Issue Number: 7549
  • Status: open  
  • Source: Anonymous
  • Summary:

    In the opinion of some, "at present, the spec bases actions on foundations described in the activities section." However the text says: "An action is the fundamental unit of behavior specification." Thus the text contradicts the opinion. If the opinion is correct, the text should be corrected to agree

  • Reported: UML 2.0 — Wed, 16 Jun 2004 04:00 GMT
  • Updated: Sun, 8 Mar 2015 14:12 GMT

All single query operations in the spec defined in OCL invalid ?

  • Key: UML241-44
  • Legacy Issue Number: 7550
  • Status: open  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    This seems rather serious, but perhaps some OCL FTF person will reassure me that it's not:

    The UML 2 Superstructure spec defines additional query operations for a number of metaclasses. For example, the following query is defined for the metaclass Element:

    Element::allOwnedElements(): Set(Element);
    allOwnedElements = ownedElement->union(ownedElement->collect(e | e.allOwnedElements()))

    Another example is the query defined for ProtocolTransition:

    context Region::belongsToPSM () : Boolean
    result = if not stateMachine->isEmpty() then
    else if not state->isEmpty() then
    state.container.belongsToPSM ()
    else false

    Notice the different forms used to define these two queries. The first one uses the name of the operation to store the result while the second uses the OCL reserved word "result". In the spec, there many queries that use the first form and only three cases of the latter form.

    A review of the OCL spec with respect to this issue – as far as I can tell – indicates that there are three valid ways of specifying a query as shown by the following two examples:

    (1) using body expressions (note the 'body:' prefix in the second line):

    context Element::allOwnedElements(): Set(Element);
    body: ownedElement->union(ownedElement->collect(e | e.allOwnedElements()))

    (2) using postconditions (note the use of the reserved word 'result' following the 'post:' prefix):

    context Element::allOwnedElements(): Set(Element);
    post: result = ownedElement->union(ownedElement->collect(e | e.allOwnedElements()))

    (3) using auxilliary definitions (note the 'def:' prefix in the second line):

    context Element
    def: allOwnedElements(): Set(Element) = ownedElement->union(ownedElement->collect(e | e.allOwnedElements()))

    Unfortunately, neither of the two forms used in the spec conform to any of these formats, which seems to imply that every single query operation in the spec that is defined in OCL is invalid! There are 73 such queries at the moment.

    Can someone from the OCL team shed light on this?

  • Reported: RAS 2.0b1 — Thu, 17 Jun 2004 04:00 GMT
  • Updated: Sun, 8 Mar 2015 14:12 GMT

UML 2 Super/Interactions/ LOOP construct specifications

  • Key: UML241-40
  • Legacy Issue Number: 7617
  • Status: open  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    This issue is submitted on behalf of Craig Larman (see signature at the end fo this e-mail):

    Current: The LOOP keyword, used in sequence diagrams in a frame, has the syntax LOOP, LOOP( repeat ), or LOOP( min, max)

    Problem: Iteration over a collection of objects, sending the same “doX” message to each member is a very very common idiom, so it would be nice if the UML had an easy notation to support this (and otherwise, how will you reverse engineer to code to the right diagram case, or vice versa? It is currently not clear…). AAt present, it is not clear how to say “for i = 1 to collection.size”, nor is there support to allow this ‘i’ loop variable to be reference in a lifeline *selector*

    1. change the LOOP syntax to (in its fullest form), LOOP( <varName>, <start>, <end>, <increment>) e.g., LOOP( i, 1, 10, 1), or LOOP( i, 10, 1, -1). Increment should default to +1.
    a. Also <start> and <end> may be expressions referring to participants in the interaction, such as end = lineItems.size where lineItems is a collection of SalesLineItem objects. Note that there is already syntax for a “max” (similar to <end>), and one aspect of this change is making (or ensuring) it can be an expression involving lifeline participants, not just a constant.

    2. allow a lifeline contained within the frame to have its selector refer to the LOOP var. e.g., “ lineItems[ i ] : SalesLineItem” to indicate selecting one SalesLineItem from the lineItems collection, given the current value of ‘i’. Note that a selector such as “lineItem[ i ]” is already allowed in the spec (and there are examples in the spec). this request is for tying the ‘i’ variable to the LOOP construct.

    Variant Solutions:
    Perhaps the upper-bound can be handled in the LOOP guard instead. E.g., [ i < lineItems.size ]. However, in this case, i still need a way to indicate the incrementing of ‘i’, and the ability to legally refer to “i” in the selector “lineItems[ i ].

    i attach a picture to illustrate.

  • Reported: UML 1.4.2 — Tue, 3 Aug 2004 04:00 GMT
  • Updated: Sun, 8 Mar 2015 14:12 GMT

Section: 9.3.12

  • Key: UML241-41
  • Legacy Issue Number: 7614
  • Status: open  
  • Source: Missouri University of Science and Technology ( Thomas Weigert)
  • Summary:

    Instance values are depicted using the same icon as for the defining classifier. However, for parts this convenient notational convention is not defined. Allow to use the same icon as for the classifier that is the type of the part, when representing the part (modulo the namestring, which is necessarily different, as is the case with instance value also). As an example, a part that derives from an active class could then optionally be shown with the vertical side bars highlighting its active nature.

  • Reported: UML 2.0 — Tue, 3 Aug 2004 04:00 GMT
  • Updated: Sun, 8 Mar 2015 14:12 GMT

UML2 Superstructure - profiles

  • Key: UML241-38
  • Legacy Issue Number: 7780
  • Status: open  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    From the current spec I really can't work out what to implement. For what
    it's worth, this is what I think should be there:
    Properties can be typed either by MOF primitive types (the ones used in the
    UML metamodel, such as string, boolean and enumeration and subtypes), or by
    UML metaclasses. This is not only consistent wth UML 1.x, it also is likely
    to be the most easily implemented - vendors already need to provide a UI for
    editing boolean properties etc. and editing properties typed by metaclasses
    is easy - just use a list control to reference existing model elements.
    The spec seems to state that properties can typed by arbitrary model
    elements.("However, it is possible to have
    associations between ordinary classes, and from stereotypes to ordinary
    How is a tool supposed to know what to do with it - it looks like the
    current spec allows a stereotype property to be typed by something like an
    Actor, not the actor metaclass, but some specific actor - what use is that?
    The more I read about this the more I'm convinced that we will never get
    interoperability, unless we tighten the rules as I suggested above.

  • Reported: UML 1.4.2 — Thu, 23 Sep 2004 04:00 GMT
  • Updated: Sun, 8 Mar 2015 14:12 GMT

Messages to ports with only one connector

  • Key: UML241-39
  • Legacy Issue Number: 7654
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The semantics of Port says:

    > If there is a connector attached to only one side of a port, any
    > requests arriving at this port will terminate at this port.

    but it also says:

    > For a behavior port, the instance of the owning classifier will
    > handle requests arriving at this port (as specified in the behavior
    > of the classifier, see Chapter 13, Common Behaviors), if this
    > classifier has any behavior.

    And presumably for non-behavior ports, the message could be forwarded to
    the intefaces of the owning classifier. So the first statement above is
    incorrect, isn't it?

  • Reported: UML 1.4.2 — Tue, 31 Aug 2004 04:00 GMT
  • Updated: Sun, 8 Mar 2015 14:12 GMT


  • Key: UML241-42
  • Legacy Issue Number: 7608
  • Status: open  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    Issue with tags (i.e. properties of stereotypes); I can't see an example of
    display of multi-valued tags or tags whose types are UML metaclasses. There
    should be a normative mechanism for displaying these.

  • Reported: UML 1.4.2 — Wed, 28 Jul 2004 04:00 GMT
  • Updated: Sun, 8 Mar 2015 14:12 GMT

Wrong metamodel for internal transitions

  • Key: UML241-43
  • Legacy Issue Number: 7593
  • Status: open  
  • Source: International Business Machines ( Eran Gery [X] (Inactive))
  • Summary:

    Description: In the UML 2.0 statemachines an internal transition is modeled as a transition owned by a region.

    It is wrong that in order to specify an internal or local transition one needs

    to instantiate a region. This makes any state with local transitions a composite state which is wrong.

    Local/Internal transitions shall be owned directly by states and not via regions.

  • Reported: UML 1.4.2 — Fri, 16 Jul 2004 04:00 GMT
  • Updated: Sun, 8 Mar 2015 14:12 GMT

Section: 11.3.39

  • Key: UML241-37
  • Legacy Issue Number: 8184
  • Status: open  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Typo - Add an "s" to the first classifier in Description. The multiplicities for the associations newClassifier:Classifier[0..*] and oldClassifier:Classifer[0..*] do not agree with fig. 153. Please correct either figure or text - probably figure. Semantics need to clarify the differences/similarities between "existing," "old," and "new" classifiers

  • Reported: UML 2.0 — Mon, 31 Jan 2005 05:00 GMT
  • Updated: Sun, 8 Mar 2015 14:12 GMT

inadequate definition of 'constructor'

  • Key: UML241-36
  • Legacy Issue Number: 7866
  • Status: open  
  • Source: Capability Measurement ( Karl Frank)
  • Summary:

    The current "definition" of constructor, section 9.3.1 "Notation"
    subsection (page 75) leaves some issues.

    The description proposes a notation for associating an instance
    representation with a "constructor", noting only that a constructor is
    an operation that "must have the class as its classifier."

    Given a list of operations (_ _ is static):

    + newInstance(name:String):Foo
    + getFooForName(name:String):Foo
    + identity():Foo
    + clone():Foo
    + Foo(name:String):Foo
    + Foo(name:String):Foo
    + make(name:String):Foo

    Any of the above operations could be viewed as a constructor under the
    definition provided. The only marker suggested in the superstructure
    specification to clearly specify a constructor is a "<<create>>"
    assocation from the default instance created by the constructor.

    Assuming foo:Foo:
    In the predominant commercial OO languages, newInstance(...) and clone()
    are delegating the actual creation to Foo::Foo(...), but clone or copy
    may be the vehicles of instantiation in languages like io or self.

    If UML had a specific marker for constructors, like the stereotype
    "<<constructor>>" then OCL and other notations and tools could treat
    constructors specially where useful.

    The OCL specificaion already includes notation for Tuple and Collection
    "constructors" to specify what are essentially Tuple and Collection
    constants. Providing a standard marker for constructors might reliably
    allow similar clear constructs for all other types (ex. if baz >
    Foo(1.30, Currency::USDollars) then ...).

  • Reported: UML 1.4.2 — Sun, 17 Oct 2004 04:00 GMT
  • Updated: Sun, 8 Mar 2015 14:12 GMT

Composite structures/Unspecified connector features

  • Key: UML241-34
  • Legacy Issue Number: 7430
  • Status: open  
  • Source: Softeam ( Philippe Desfray)
  • Summary:

    Composite structures/Unspecified connector features between ports having multiple interfaces. What happens when ports have multiple interfaces, that in addition can mix
    required and provided interfaces? This is not specified. In particular, a
    connector could connect two ports using only a specified subset of the
    interfaces from both ports.

    Extend the metamodel to allow the specification of the interfaces used for a
    connector between ports having several interfaces.


    Provide a default rule for that situation, such as the connector uses the
    compatible interfaces between the interfaces of both ports.

  • Reported: RAS 2.0b1 — Wed, 2 Jun 2004 04:00 GMT
  • Updated: Sun, 8 Mar 2015 14:12 GMT

What is a mapping that is not computable?

  • Key: UML241-33
  • Legacy Issue Number: 7412
  • Status: open  
  • Source: X-Change Technologies ( Joaquin Miller)
  • Summary:

    "It is possible to specify a mapping between the specification and implementation elements, although it is not necessarily computable." What is a mapping that is not computable?

  • Reported: UML 2.0 — Tue, 1 Jun 2004 04:00 GMT
  • Updated: Sun, 8 Mar 2015 14:12 GMT

Issue in UML 2 Lifeline class

  • Key: UML241-31
  • Legacy Issue Number: 7447
  • Status: open  
  • Source: Independent ( Marc-Philippe Huget)
  • Summary:

    p. 386, it is written: "To depict method activations we apply a thin grey or white rectangle that covers the Lifeline line". Figure 8-144 p. 372 presents several sizes of grey rectangles. Particularly, does it mean that method activation is performed all along the Lifeline ob1:C1? A temporal vertical axis will be added to allow several sizes of rectangles and duration of method activation.

  • Reported: RAS 2.0b1 — Wed, 9 Jun 2004 04:00 GMT
  • Updated: Sun, 8 Mar 2015 14:12 GMT

Issue in UML 2 Interaction package

  • Key: UML241-30
  • Legacy Issue Number: 7443
  • Status: open  
  • Source: Independent ( Marc-Philippe Huget)
  • Summary:

    In the UML 2 Interaction package specification (UML
    2 spec, dated 2003/04/10): p. 381, it is written that
    "InteractionFragment is an abstract notion of the most general
    interaction unit. An interaction fragment is a piece of an interaction.
    Each interaction fragment is conceptually like an interaction by itself".

    InteractionFragment is described as an abstract notion and Interaction
    is defined as a specialization of InteractionFragment. Don't we define
    normally in the other way around: the InteractionFragment is the
    abstract notion and is called Interaction and the interaction is called
    InteractionFragment? We can have the definition for Interaction
    (previously called InteractionFragment): "Interaction is an abstract
    notion of the most general interaction unit. An Interaction is composed
    of at least an InteractionFragment".

    Usual semantics for fragments refers to something within something else
    but here, the something else is undefined.

  • Reported: RAS 2.0b1 — Wed, 9 Jun 2004 04:00 GMT
  • Updated: Sun, 8 Mar 2015 14:12 GMT

Issue in UML 2 Interaction class : Local attributes

  • Key: UML241-29
  • Legacy Issue Number: 7445
  • Status: open  
  • Source: Independent ( Marc-Philippe Huget)
  • Summary:

    It is possible to represent local attributes to an Interaction (see Figure 8-148 p. 380) but it is not written how these attributes are treated: are they public to all the lifelines? Is it possible to have private attributes and in this case to which lifelines? Are they local to the Interaction? What happens if one of the lifeline is self? Does it mean that these parameters are owned by the self lifeline?

  • Reported: RAS 2.0b1 — Wed, 9 Jun 2004 04:00 GMT
  • Updated: Sun, 8 Mar 2015 14:12 GMT


  • Key: UML241-32
  • Legacy Issue Number: 7442
  • Status: open  
  • Source: Cutter Information ( Oliver Sims)
  • Summary:

    The Components chapter of the UML2 Superstructure spec does not specify what component generalization/specialization means. Is it intended that this be left unspecified? If not, then I propose the semantics described in a paper I wrote on this subject prior to the spec being adopted. The paper suggested an approach that is consistent with substitutability semantics, and should also be able to be made to work with most if not all component technologies. I'd be happy to email the paper to anyone interested.

  • Reported: UML 2.0 — Thu, 3 Jun 2004 04:00 GMT
  • Updated: Sun, 8 Mar 2015 14:12 GMT

DeploymentSpecification - notation for DeploymentSpecification on the insta

  • Key: UML241-35
  • Legacy Issue Number: 7154
  • Status: open  
  • Source: PostFinance ( Karl Guggisberg)
  • Summary:

    DeploymentSpecification - notation for DeploymentSpecification on the instance level

    There are several examples of DeploymentSpecification on the instance level which use the notation name: value (i.e. execution: thread) instead of the default notation for slots (see InstanceSpecification on p. 59) name = value (i.e. execution = thread)

    See - Figure 132 on page 191 - Table 8, 2nd row, 2nd column on page 199

  • Reported: UML 2.0 — Sat, 13 Mar 2004 05:00 GMT
  • Updated: Sun, 8 Mar 2015 14:12 GMT

Issue in UML 2 Continuation

  • Key: UML241-26
  • Legacy Issue Number: 7451
  • Status: open  
  • Source: Independent ( Marc-Philippe Huget)
  • Summary:

    Is it not possible to have a symbol for the setting? That could help reading the diagram.

  • Reported: RAS 2.0b1 — Wed, 9 Jun 2004 04:00 GMT
  • Updated: Sun, 8 Mar 2015 14:12 GMT

Issue in UML 2 Interaction class: Lifeline ordering

  • Key: UML241-28
  • Legacy Issue Number: 7446
  • Status: open  
  • Source: Independent ( Marc-Philippe Huget)
  • Summary:

    Lifelines are associated to Interaction but it is not possible to save the ordering contrary to the fragments.

  • Reported: RAS 2.0b1 — Wed, 9 Jun 2004 04:00 GMT
  • Updated: Sun, 8 Mar 2015 14:12 GMT

Issue on UML 2 Interaction class

  • Key: UML241-27
  • Legacy Issue Number: 7444
  • Status: open  
  • Source: Independent ( Marc-Philippe Huget)
  • Summary:

    It is not possible to represent that an Interaction frame represents a design pattern with unbound parameters

  • Reported: RAS 2.0b1 — Wed, 9 Jun 2004 04:00 GMT
  • Updated: Sun, 8 Mar 2015 14:12 GMT