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:
carbonated drinks
, the user needs to choose which brand: say Coke or Pepsi.tea
, then he/she have to choose the amount of sugar.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.
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 drink
and 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.