Representing a "wait until" in an activity diagram in UML

Question

How can I represent a "wait until customer representative is available" in the UML activity diagram below? A solution in UML 1 or UML 2 are both acceptable.

Proposal 1

The simple line back to the second condition "looks" wrong.

Proposal 2

I also came up with this "cleaner" solution.

(I know that the final point is missing.)

Answer 1

IMHO, there is actually no need to include any conditional or "loop" for the "wait" state at all:

Any activity needs a certain time until it is completed. If a customer representative is available immediately, the time for the wait activity is zero, if not, the activity will just take some minutes or maybe hours. But the power of "zero" is it can be often handled just like any other number, without the need for artificial distinctions.

Of course, if you want to model the "Wait" activity explicitly, because in your system something essentially different will happen during a "real wait", go with your solution 2.

Answer 2

Are your diagrams ok ?

The guard on a decision node shall be placed on the tail of the line and not on the nodes (see UML 2.5 section 15.2.4). So [free customer representative available] on the top of the diamond shall be removed and the outgoing [yes] and [no] change to [customer representative available] and [customer representative not available].

After this, both diagrams would be formally ok:

• Proposal 2 would produce the expected result if and only if it is guaranteed that a customer representative is available when the wait activity is completed. This is not obvious, so better branch to the left, and put the merge diamond upfront the decision diamond, to be sure not to continue until a representative is available.

• Proposal 1 is completely correct. The control nodes in an activity diagram are either decision nodes with several outgoing flows, or merge nodes with several ingoing flows (see UML 2.5 section 15.3.2), but fortunately, both can be combined into a single diamond on the diagram (see UML 2.5 figure 15.34 in section 15.3.4.3). It's however a little bit less readable than distinct nodes.

• You already know, but you'd need an end node after the order.

But is it really the best way ?

Your diagrams rely on the human understanding of the activity wait (for representative). But I think we agree that waiting is not really an activity but rather a not activity.

Alternative 1: use an event driven approach with the help of an accept-event-action called Customer representative available that represents what you're waiting for. Merge the flow coming out of it with your normal flow. Attention: don't use the tempting TimeEvent (hour glass symbol): it is meant for events occurring at specific point in time (see UML 2.5 section 13.4.10.1)

Alternative 2: represent what you're really doing: you're finding a customer representative. This is the simpels way to show it.

Alternative 3 (my favorite): represent the true complexity of a multitasking world, with the use of a fork and a join control, and in-between everything that is happening in parallel:

Answer 3

If you use swim-lanes, I think you don't need any wait mechanism. It's implied that the Customer Representative has to be ready to do the task.

Here's a suggestion done with PlantUML/PlantText:

EDIT Here's another suggestion (source) with a more explicit wait semantic that allows for hanging up.

Answer 4

Having a "wait" state, or wait activity, is not implausible, and depending on the domain, not uncommon either. Mark it as such and defined how long the state will be active for (i.e. how long it it goes back to the decision point).

If the decision point doesn't have to be explicitly exposed, you can roll the decision and wait state into a single activity that moves on the availability of an operator.

On a side note; if the OP is a "demo" of the actual flow being assessed in your project, there are other options for models and modeling this behavior that may be worthwhile investigating, such as;

• FSM, a state with an event that moves the machine on to the "place order" state
• If there are multiple flows that require synchronisation, a join may be a better idea

Sometimes other solutions may just be another model, or a redesign of some sort that removes the wait state. That said, often then solution is just the wait state because that's the behavior of the process flow being modeled (whether that is by design or by analysis).

---

On the added second option, the "wait until" inherently requires a test to determine if the required condition is satisfied, I'm not sure the second option models that appropriately.

Answer 5

You should use a ReceiveSignalAction to represent receiving of a signal that a consultant is ready.

Sorry, no modeling tool available at the moment, I'll add the diagram when I sit to my computer.