Reputation: 91
I have read this post: Use case generalization versus extension. I have 2 cases below.
Case 1
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
Reputation: 73376
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.
The use-cases in that specific diagram are ambiguous:
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
?«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.
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
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