0

Example:

  • Use Case 1 : Buy drinks
  • Use Case 2 : Buy food

A user can enter our store and start by ordering some drinks. We can upsell him a food item => Buy food extends buy drinks.
The other way around would be possible as well. A user wants to order a sandwich and we upsell him a drink. => Buy drinks extends buy food.
Is this the correct way to model this or would it be better to use Generalization/Specialization were we would have a Buy item that specializes in Buy Drinks/Buy food.
Or maybe still some other way... ?

DiscoFever
  • 123
  • 8
  • For which system do you think denotes "buy" and added value? To the actor itself. You are probably describing a POS. So "Sell X" should basically be the UC. – qwerty_so Jul 20 '16 at 09:41

2 Answers2

0

You are trying functional decomposition when using <<extends>> (this way). Use cases are not about functional decomposition of systems but synthesis of actions around a unique added value the system under consideration (SUC) delivers to an actor. Try viewing it from this perspective. So what are those unique added values of the SUC (which I guess is a sales system)? It's Sell Goods and either there is a difference between Sell Food and Sell Drinks then they are different UCs or there is none, in which case you don't need two UCs.

qwerty_so
  • 35,448
  • 8
  • 62
  • 86
0

Extend is never bi-directional (i.e. the extend relationship is always a directed one).

In your case you have just one use case as suggested by Thomas Kilan.

If you keep insisting on having the use cases differentiated then generalization is a good choice but most probably it's unnecessary in your case.

While this is extremely rare (and definitely not your case) it's not forbidden to use two extend relationship between the same use cases in the opposite directions (or to build other form of a cycle using extend relationship) if this represents the logic of the system (e.g. managing of two separate entities that each can be handled separately or together with any of the two as the initiated one). In practice such cycles can be solved during discussion with the (future) system users and should be avoided. On the other hand include relationship can never create a cycle and if they do the model is not valid.

Ister
  • 5,958
  • 17
  • 26
  • hi @Ister. "In practice such cycles can be solved during discussion with the (future) system users and should be avoided" could you please explain, why this should be avoided? i'm facing exactly that situation. – rome Sep 19 '18 at 22:10
  • I won't quote any sources for that but the reality is the existence of such cycle is hardly ever a real-life scenario. There are few good reasons to avoid that. First it is usually a sign there is an over-use of extensions and inclusions in the UC diagram (they should be sparse anyway), second it might lead to ambiguity, even an infinite loop, third they lead to processes that are difficult to maintain. Finally usually in real life such cycle is a representation of "how things are done" without considering "what is the goal" which make one of the UCs the actual master. – Ister Sep 20 '18 at 06:26