Loop in UML activity diagram using a region

20
votes

I am modeling a loop in an UML activity diagram. It works well with simple condition nodes (diagram 1), but I am looking for a more expressive way to emphasise the loop semantic. So I came to "regions" or "interruptible regions" which are shown here and there, but I couldn't find many really satisfying examples.

My example is a function which processes messages of a given list. The loop aborts as soon as the first valid message is found, then the message is processed and the function returns true. Otherwise, it returns false (please no comments on sense or nonsense, it's only for the sake of a sample).

Diagram 1: uses a good old activity diagram conditional node. It is easier to follow the control flow along the arrows, admittedly, but there is no "The LOOP", there is just an "if".

Diagram 2:

  • is the (positive) exit condition correct, using an interrupting edge? True, it could be part of the [test] section of the loop along with the iterator.
  • BTW: how is the iterating character of a for-loop best expressed in UML?
  • Is the activity final node inside the loop body correct (i.e. when the conditional "message valid?" yields "no")? It somehow feels wrong to use a final node here, but how else can I express the control flow of one loop?

The functionality of both diagrams should be equivalent:

loop with conditional node

loop with region

Edit: Another diagram which implements the suggestions from Steph:

  • Initial and final node inside the loop body
  • "further processing" is now inside the loop body. Well... OK here but there might be other loops where I would rather have it outside. Then I might change the design anyway...
  • The "next message" can also be seen as the iterator object itself instead of the action "(provide the) next message" from the original diagram.
  • The two object flow arrows might be a bit overkill, but I think they are correct.

enter image description here

1
loopsandroid-activityuml
May you explain what the "fork" symbol in your "isMessageValid"-state is representing? I'm not aware of such a symbol. – Torsten
This is an action (not a state) with "call behavior". It symbolizes that "isMessageValid" is not just a boolean flag but a placeholder for another diagram which explains a deeper work flow (in tools like EA, you can also double-click on that action to switch to this diagram). Note that when I drew this diagram some years ago, I was not very experienced. Now, I would write "validity check" since UML should be abstract and programming language independent. When there is no other diagram but a known object with a method isMessageValid() to call, one can write that as well - without the fork. – Ingmar
Alright, it's an action since it is an activity diagram. Thank you for your thorough explanation. I only knew the "two bubble/state" symbol (composite state). Is that equivalent to the fork? – Torsten
No. In short: in activity diagrams, the action node with the 'fork' calls another activity and behaves like it, but does not own it. That activity can be called from different places like a function in common programming languages. The two-bubbles symbol is a 'hidden composition indicator' showing that the part's own internals are just not shown in detail. It is a 1-1 relationship. Mostly seen in state diagrams; EA for instance uses it also in component and use case diagrams etc. to show that the part decomposes into more sub-parts (and for link symbols to other related diagrams). – Ingmar

1 Answers

10
votes

In UML, the activity final node represents a completion, so it is correct in a loop region as you use it, it is the normal completion of the content of your loop (which in turns leads to the next iteration). As a side note, I advise you to also use an initial node for the beginning of your loop.

And there is also the flow final node, that represents an exit, instead of a completion. Thus, you can use it to represent the "break" statement, instead of the interrupting edge you use. In this case you have to integrate the "further message processing node", in the "yes" branch, just before this flow final node.

The interrupting edge is rather for interruptions coming from outside the current processing. The region is interruptible, and some events (usually noted with receive nodes) may completely interrupt it no matter the progress of the region content. Here it is not the case.

Concerning the iterating character, there is nothing very visual, unfortunately. I tend to use an object node on top of the region, just beside the initial node.