How do you model a Java for each loop on a UML sequence diagram?

Question

for (Item i : collection) {
i.foo();
} 

In some abstract sequence diagrams you have a loop combined fragment with a condition along the lines of e.g. [for each item].

On a sequence diagram featuring Java implementation; what would you use as a loop guard?

If all lifelines must represent an object instance, how would you show that i: Item is not a single instance, but on each iteration a different object from the collection?

Warrick

Answer 1

You don't show each single bit in a SD but just an overview: it's an abstraction.

This quite clearly shows the intention of your loop.

You would show different Item instances only if you want to show different behavior during the loop.

Tumbling

Answer 2

For the second part of your question, there is a notation to draw multiple instances in the same lifeline using stacked boxes, for example:

from A Quick Introduction to UML Sequence Diagrams

The stacked boxes used for the figures variable indicate it refers to multiple instances, which can be interpreted as being a different instance around the loop. (As usual with UML, the semantics a somewhat in the eye of the beholder)

P. 571 of the UML 2.5 spec states:

The Lifeline head has a shape that is based on the classifier for the part that this lifeline represents. Often the head is a white rectangle containing the name.

The word "Often" can be interpreted as "take what is needed" as it does not obtrude the use of a single specific form.

Fraga

Ah, from the Internet. That must be right :-/ The official UML 2.5 spec does not have that notation. See pp. 593. – Tumbling

@ThomasKilian true - it was explicit in UML 1 that the lifeline started with an object symbol, and that is the notation for a multi-object symbol which can be used whenever the object has a multiplicity greater than 1. In UML2.5 the wording has changed to 'The Lifeline head has a shape that is based on the classifier for the part that this lifeline represents' and the metamodel has the type of what the lifeline represents as ConnectableElement, which represents a set. So it both a common notation from UML1 and within the allowed notations of the specification of UML 2. – Fraga

I took the freedom to add the reference. – Tumbling

In my opinion, the word "often" means, that most Classifiers have a rectangle notation. None have this stacked boxes notation. Therefore it is also not available for Lifelines. Of course it would be possible to define it in a user defined profile. Whatsoever, it will always represent only one instance, which could be an instance of a collection. – Stable

@AxelScheithauer the spec does not restrict what notation is used - you can use a picture of a kitten if you like and it will still be valid UML. – Fraga

@Pete. As I said, it is possible to define it in a user defined profile. You would have to define a stereotype with an image of a kitten, apply this to a Class, let a Lifeline represent it and choose to display the stereotype image instead of the Classifier rectangle. There is no other way to change the appearance of Lifelines or Classifiers in the specification, even though most tools are more flexible. – Stable

Answer 3

Unfortunately it cannot be done. The loop operator has a guard condition and a number of iterations between minint and maxint. I think, this doesn't allow "for each loop" semantics. If you want to add this, it must be done with a user defined stereotype «for each loop»: An example usage is:

Please note that the note symbol is a not a comment, but the notation for the stereotype properties. They reference the property e of Client1 and i of the Interaction Example1 (see diagram below). The i-Property is represented by a Lifeline and will refer to a different object in each occurrence of the loop content. This is achieved here by the user defined semantics of my «for each loop».

As an alternative you could add a semantic free comment with the same content. Misusing the guard for this purpose is not recommended.

If you want to use a java like iterator the diagram could look like this:

This diagram also shows, how to refer to different objects over time: The return value of a reply message is assigned to a Property of the Interaction or of the Class represented by the Lifeline or a Parameter.

Stable