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.

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.

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.

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?

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.

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.

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 ...).