1

we recently got the assignment to visualize the following process as a Use Case diagram:

The customer can use a touch panel to put together his menu of choice. After that, he can order the food he put together. After he ordered his food, he can choose whether he wants to pay by card or with a voucher. Then the customer waits for his food and picks it up at the counter.

Now while this is not really a complex process, my question would be how or if the use cases have a relationship to each other. My approach would be as follows:

enter image description here

My idea behind this is, that Use Case diagrams are not meant to show procedures in the right order but what use cases there are. Hence I didn't put a relation between the different use cases. I know that there is not ONE optimal solution and probably more ways to model this process but would my approach be wrong?

qwerty_so
  • 35,448
  • 8
  • 62
  • 86
hxog
  • 13
  • 3
  • Possible duplicate of [What's is the difference between include and extend in use case diagram?](https://stackoverflow.com/questions/1696927/whats-is-the-difference-between-include-and-extend-in-use-case-diagram) – Geert Bellekens Oct 22 '19 at 05:54
  • Not too bad at all. One thing: your middle associations must be <> as well. Use verb-substantive in all cases to name a UC. – qwerty_so Oct 22 '19 at 11:34
  • @qwerty_so Thanks for the answer! One last thing, you mean that I should use an <> relationship for the different payment methods instead of using a generalization? – hxog Oct 22 '19 at 11:53
  • Yes. You were not using a generalization but a directed association. Both would be wrong. UC as not associated and a generalization is an indication of functional decomposition. – qwerty_so Oct 22 '19 at 11:57
  • @qwerty_so Ok, got it! Thank you so much for helping me :) – hxog Oct 22 '19 at 12:05
  • A generalization between use cases is allowed in UML. But when you start specifying the use case flows, often in plain text, you may discover that ≪extend≫ (not ≪extends≫) or ≪include≫ would have been better. In this case, I guess ≪include≫ would be the best option: In use case 'Pay', you would specify that the user can make a choice between card or voucher. If (s)he chooses card, you include Pay by card and if (s)he chooses voucher, you include Pay by voucher. However, people have very different opinions about include and extend. – www.admiraalit.nl Oct 23 '19 at 14:10

1 Answers1

0

Simply put: your assumption is correct. There is (usually) no timely relation presented in a UC diagram. However, you can add pre-conditions to UCs. Than can be shown as stereotyped constraints on the diagram (but usually you just hide that for the more interested audience in the model). Avoid anything that goes in the direction of functional decomposition.

One more thing: I'd «include» pay order in pick up food.

Geert Bellekens
  • 12,788
  • 2
  • 23
  • 50
qwerty_so
  • 35,448
  • 8
  • 62
  • 86