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:
The functionality of both diagrams should be equivalent:
Edit: Another diagram which implements the suggestions from Steph:
To show a loop, you use the loop operand with a single fragment and put the basis of the iteration in the guard. For conditional logic, you can use an alt operator and put a condition on each fragment. Only the fragment whose guard is true will execute. If you have only one region, there is an opt operator.
Loop Node. You can model the loop using the UML Loop Node. The Loop node consists of 3 partitions (activity regions) that contain various parts of the loop: setup - defines the initial conditions of the loop.
Two possible representation of the loop in the UML activity diagram - a) shows loop where the condition is checked before the action is taken and b) shows the loop where the loop condition is checked after taking action.
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With