Haru
Haru

Reputation: 91

Extended vs Generalization in Use Case

I have read this post: Use case generalization versus extension. I have 2 cases below. enter image description here Case 1

enter image description here Case 2

Update movie only happens when at least one of three use cases happens. In generalization relationship, there is one and only use case happens. In extended relationship, Update movie can happen without any use cases. So which one should I use?

Upvotes: 4

Views: 2213

Answers (2)

Christophe
Christophe

Reputation: 73376

In short

If keeping only the left use-case is not an option, then prefer the second version based on generalization, as it better conveys a goal-oriented use-cases. However, consider renaming the general use case.

More arguments

The use-cases in that specific diagram are ambiguous:

  • Use-cases are in principle for actor goals. The left case looks like a goal. The right could be sub-goals that matter to the user (ok for a use case) or functional decomposition of how to achieve the goal (not ok for a use case).
  • It is not clear how Update movie is different from Modify movie, looking at the usual understanding of CRUD. So a renaming is required to avoid ambiguity. What about Manage movie?
  • Looking at the left, the relation to the use-cases on the right, with «extends» suggests that you are in fact modeling a user interface or a feature where for example a window Update movie could lead to the different other functions or features, each on the right being optional. This would make sense only if the left Update movie would make sense for an actor without considering any of its extensions. But this is not the case, since you claim that "at least one of three use cases [on the right] happen". Let's avoid this kind of functional decomposition.

The version with the generalization, could perfectly correspond to proper use cases, with a general goal, that are specified in more specific goals, each making sense on its own.

What do authors say?

Alistair Cockburn dedicates in his excellent book Writing effective use-cases a full chapter on CRUD use-cases:

The question is, are they all part of one bigger use case, Manage xxx, or are they separate?
In principle they are separate because each is a separate goal, carried out by a different person with different security level. However they clutter up the use-case set and can triple the number of items to track.

As Cockburn focuses on describing use cases more than the UML models, he then describes what he calls "parameterized use cases", with a general use case with some scenario actions that would be more specific for the specific use cases. This technique corresponds very much to generalization/specialization, to which he also refers in an annex about the UML notation.

Kurt Bitter and Ian Spence in their excellent book Use Case Modeling discourage the use of CRUD use cases. Their main argument is not that CRUD cases are wrong, but that they are time consuming and provide little value for the modeling:

Although it is technically appropriate to employ use cases to describe this kind of behavior [CRUD], it’s probably not a great use of time to describe this behavior in terms of use cases. We summarize this guideline as “use cases should contain more than CRUD.”

They clarify why it is not worth the effort:

Use cases for simple CRUD behavior don’t add much value to ensuring that the system is doing the right thing. (...) there’s little chance of getting the requirements wrong.

Upvotes: 3

qwerty_so
qwerty_so

Reputation: 36305

None of the above are use cases. They are pure functions and as such actions within activities describing some use case. A use case brings added value to its actor. It's the sublimation point where you start building. It's never the functions! So what you are doing is functional decomposition. You're on the completely wrong track.

As always I recommend Bittner/Spence about use case modelling. The best read you can find.

Upvotes: 1

Related Questions