1

For an example, say, I want to draw a use-case diagram for an artificial vending machine like so:

  • The vending machine have 3 options: carbonated drinks, tea, and pure water.

  • The user can choose only 1 of the above for an order:

    • If the user chooses carbonated drinks, the user needs to choose which brand: say Coke or Pepsi.
    • Else if the user chooses tea, then he/she have to choose the amount of sugar.
    • Else if the user chooses pure water, then that's it.
  • After choosing the drinks, the user then has to choose the number of drinks (a little bit contrived). The machine then sends out a confirmation message for the user to confirm.

I tried this but not really sure of it, don't know what to keep, what to add or what to remove..

The questions are:

  • Should the 2 Choose the number of drinks and Confirm here be kept independently as use-cases, or should they be merge with the grand use-case: Buy a kind of drink?

  • If at least 1 of them is to be kept, should I draw them as including use-case of Buy a kind of drink or should they be drawn as independent use-cases?

  • The 3 use-cases Buy carbonated, Buy tea, Buy pure water I considered as the discretization of Buy a kind of drink. For Buy carbonated and Buy tea, should I keep the including use-cases: Choose brand and Choose sugar amount or should I remove them also?

  • More general question: When should a step of doing some big use-case should be kept as a use-case, and when shouldn't? There are a lot of questions on here that are the same, but the answers are non-consistent.

1 Answers1

1

Use cases are about the what and not about the how. The latter goes into Activity and is split to Actions. Use case only show the added value a system under consideration brings to its actors.

So the only added value is Sell drinkand that's it.

I recommend reading Bittner/Spence about use cases. They call it synthesis and that's the right word. Not analysis and even less decomposition.

Strange, that techies always want to decompose things. Well, I know it's hard to learn since I had been scratching my head too. It's probably so complicated because its about simplicity.

qwerty_so
  • 35,448
  • 8
  • 62
  • 86
  • Thank you for answering. Just another question. Why is splitting `Sell drink` into `Sell carbonated`, ... is also counted as functional decomposition? I understand why my `<>` is counted as such, but [here](https://www.uml-diagrams.org/examples/hospital-management-use-case-diagram-example.html?context=uc-examples) they also split it like that. Is it because there is something to their splitting that is different from `sell drink`, or they are also analyzing the use-case? Thank you. – Toàn Trần Aug 10 '23 at 02:23
  • Any bubble must be a single added value. I would not see any difference in selling beer from water as both serve to quench thirst. If you can explain the difference (probably taking alcohol into account) then go ahead. Basically: find the added value; don't explain how it's achieved! – qwerty_so Aug 10 '23 at 09:13
  • Got it. Thank you! – Toàn Trần Aug 10 '23 at 09:33