12

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

wait state model

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

Proposal 2

I also came up with this "cleaner" solution.

enter image description here

(I know that the final point is missing.)

problemofficer - n.f. Monica
  • 440
  • 1
  • 3
  • 14
  • 1
    Your two proposals don't seem to represent the same thing to me. It looks like the first goes through multiple iterations of `wait`, while the second only does a single `wait` – Peter M Jun 26 '17 at 12:51
  • 1
    I think http://www.uml-diagrams.org/activity-diagrams-reference.html shows how to model send event signal. or accept action event. – oopexpert Jun 26 '17 at 23:30
  • Find this [activity diagram tutorial](https://creately.com/blog/diagrams/activity-diagram-tutorial/) to be very useful in figuring out questions like these. There are many examples and templates drawn on various scenarios to identify questions like these. – Shalin Oct 10 '18 at 06:58

5 Answers5

14

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

Activitive_Example

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.

Doc Brown
  • 199,015
  • 33
  • 367
  • 565
7

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.

enter image description here

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:

enter image description here

Community
  • 1
Christophe
  • 74,672
  • 10
  • 115
  • 187
  • 2
    Thank you very much for the elaborate answer. Question regarding alternative 3 and the join control: Wouldn't your model mean that I would have to wait for the music to finish playing until a order could be placed? – problemofficer - n.f. Monica Jun 26 '17 at 19:30
  • Well, indeed, you are completely right: the join will wait that music playing is finished, which might not be the most effective way to get the order placed. To solve this you could use an (interrupting edge)[http://www.uml-diagrams.org/activity-diagrams.html#activity-edge] with an event action, as in alternative 1. More complex, but at least the customer would at least have the music;-) . – Christophe Jun 26 '17 at 20:10
2

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:

enter image description here

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

enter image description here

Fuhrmanator
  • 1,435
  • 9
  • 19
1

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.

Niall
  • 1,831
  • 1
  • 18
  • 20
0

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.

Ister
  • 764
  • 3
  • 8