Search code examples
umlactivity-diagram

Activity diagram iteration of loop for fixed number of times and point to a different activity if iteration ends

I developed the following activity diagram.

A client is requested a payment, and if he doesn't make the payment within 5 days, the company calls the client and gets an update if he still wants the lesson. However, I want to repeat the loop where we check if the payment is received within 5 days and call the client for an update, as the company would tolerate this 3 times, and if else the booking is cancelled. I am however, unsure of how to visualise this on my activity diagram.

enter image description here

Solution

  • Following your initial attempt

    One easy way would be to add on your Payment received witin 5 days / No branch a new decision node: Customer already contacted 3 times where No would continue the initial flow to call and Yes would lead to Cancel booking:

    enter image description here

    This supposes that you have a counter of the number of calls made per payment request.

    In your narrative, we see that there is a difference between the first call, and the subsequent ones. In my view this difference should be handled within Contact client by phone and does not need any special care. However, if the activity would differ more substantially between the initial call and the actions taken for reminders, you might need to consider a more complex branching. But the principle is the sam: you'd use a couple of decision nodes that check the call counter.

    A different approach

    In reality there is no loop. The person making the call is not waiting monitoring for the payment to arrive to make a second call. In principle, payment request received will lead without delay to the decision node, and would not be stuck there for 5 days. The 5 days is ok for human readers but is full of ambiguity. For example, will you also wait 5 days after your each call ? What if the payment is received on the 6th day, but the caller didn't call immediately on the 5th day, etc...

    To address such timing issue, you'd be better use timing events as explained in this other SO answer from qwerty_so. This allows you to clearly show the normal flow, and isolate the time-driven activities.

    (By the way, since we see that in reality the activity is related to the state of a payment request, you could elegantly complement your activity diagram with a state diagram.)