4

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?

Christophe
  • 68,716
  • 7
  • 72
  • 138
Haru
  • 71
  • 5
  • 1
    You have the extension direction wrong in your first case. Extension like you mean it (update movie only happens if one of the main use cases is executed) should be in the other direction. It would be the correct direction for include though. But I agree with the other answers, you probably don't even need includes, extends or generalizations in your case (or even in most cases) – Geert Bellekens Jun 06 '22 at 11:34

2 Answers2

3

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.

Christophe
  • 68,716
  • 7
  • 72
  • 138
  • I agree to change `Update movie` to `Manage movie`. Management includes more than CRUD, but in this case, let's just talk about CRUD. Inclusive means CRUD can occur with the same movie object. I can create, read, modify a movie and then delete it from the website. An example of a generalization is `Make payment` use case. It can be divided into `Pay via PayPal` and `Pay via credit card`. When either use cases occurs, a transaction is created. I mean, two use cases work with different objects. It makes me confused. – Haru Jun 06 '22 at 10:37
  • @Haru The handling of CRUD fuels a lot of debates and made some consultants very rich ;-) My preferred option is not to show the detailed CRUD in the diagrams, since diagrams are meant to provide the big picture. But if there's no use case, the topic nevertheless needs to be tackled, described, implemented and tested in a way or another. So in the end, it doesn't make much difference to do one way or the other, except for the simplicity of the diagrams. An additional generalization issue is to find out if `Create movie` has more in common with `Update movie` or with `Create author`. – Christophe Jun 06 '22 at 13:30
  • You `make payment` is another common example. For the user, the goal is to pay. The payment media is just a detail. You could opt for a goal-oriented use-case, and leave some space for payment media related interactions. Update to you to describe these: you could just add two paragraph behind the `Pay` narrative. But if you think its important to differentiate the use-cases, for example because the secondary actors (bank operators vs PayPal) are different, it is up to you to use specialization. Specialization has the advantage that you could later add `Pay cash`, `Apple Pay`, etc. – Christophe Jun 06 '22 at 13:35
  • I mean, the overall principle is sufficient. Btw. the specialization do not need to clutter your main diagram but could be shown on a separate diagram (in UML, keep diagrams simple and focused). So it has also the advantage of facilitating maintenance of diagrams with separation of concerns. Last but not least, if you'd use [Entity-Boundary-Control](https://en.wikipedia.org/wiki/Entity-control-boundary) to relate your classes to the use cases, it would seem straightforward to make `Control Paying` a generalization of `Control Paying with PayPal` that would share a big part of the behavior – Christophe Jun 06 '22 at 13:39
  • ... but override the ones which are specific to PayPal. I hope I don't confuse you with these lengthy explanations @Haru - What I mean to say is that ultimately, these diagrams are only a tool to facilitate the delivering of software, and it's up to you to see what way helps you the most to get the software delivered in the end ;-) – Christophe Jun 06 '22 at 13:42
1

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.

qwerty_so
  • 35,448
  • 8
  • 62
  • 86