Unified Modeling Language Avatar
  1. OMG Specification

Unified Modeling Language — Open Issues

  • Acronym: UML
  • Issues Count: 7
  • Description: Issues not resolved
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

Messages to ports with only one connector

  • Key: UML241-39
  • Legacy Issue Number: 7654
  • Status: open  
  • Source: NIST ( 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

UML2 Superstructure - profiles

  • Key: UML241-38
  • Legacy Issue Number: 7780
  • Status: open  
  • Source: The MathWorks ( 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
    classes")
    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

UML 2 Super/Interactions/ LOOP construct specifications

  • Key: UML241-40
  • Legacy Issue Number: 7617
  • Status: open  
  • Source: Simula Research Laboratory ( 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*

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

Profiles

  • Key: UML241-42
  • Legacy Issue Number: 7608
  • Status: open  
  • Source: The MathWorks ( 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

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:
    Foo::newInstance("bar")
    foo.clone()
    Foo::make("bar")
    Foo::Foo("bar")
    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