1

I have a use case here for delete. This is trying to demonstrate that a user can delete Users, Projects and Posts. If you want to do delete a User, you select "User" from the deletion menu, a user menu dialog box will pop up where you will type a name and press "Delete" to confirm deleting that user. For Projects, you select "Project" in the deletion menu and another menu pops up where you type the projects name and click "Delete" to delete the project. That is how I am looking to implement it in software. However displaying it in use case I am a little confused. Is this a good use of extension point use case to demonstrate that functionality or is a specialisation better to use in this scenario where the parent would be "Delete" with children named "Delete User", "Delete Project" etc...

enter image description here

Based on Writing Effective Use Cases by Alistair Cockburn

My personal tendency is to write "Manage X", to get the advantage of less clutter, unless it turns out not to work well for some reason, usually related to the complexity of the writing, and only then break it out into "Create X", "Update X", "Delete X"

enter image description here

Specialization enter image description here

Christophe
  • 68,716
  • 7
  • 72
  • 138
Krellex
  • 613
  • 2
  • 7
  • 20

1 Answers1

2

The UML specs explain that:

The extended UseCase is defined independently of the extending UseCase and is meaningful independently of the extending UseCase.

In your case, I doubt that Delete is meaning independently of Delete User, Delete Project, and Delete post. The point is that the use-cases are independent of the internal implementation of the software. They should in principle represent user goalds and the set of behaviors needed to achieve them.

In Writing effective use-cases Cockburn dedicates a chapter to CRUD and parameterized use-cases. He provides a useful question:

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

He proposes several approaches, including the principle of parametric use-cases: a generic use case (i.e. a generalization) describes the general behavior, and parameters are used to specialize the use-case description. ALthough his book is about use-case speicifications and not use-case diagrams, he describes an idea that is much closer to specialization than extension.

Christophe
  • 68,716
  • 7
  • 72
  • 138
  • Thanks for the reply. I had a look at Writing effective use-cases prior to seeing your answer. I have adjusted the post to reflect what I felt was mentioned in the book. Would the improved implementation be acceptable for CRUD operations? For my work I must explain the CRUD operations which is why I have decided to make "Manage X" with extension use cases relating to the CRUD operations so I can explain this. I feel this implementation makes sense although I would love to hear what you think. – Krellex Oct 17 '21 at 07:37
  • @Krellex THe CRUD is indeed one example of parametric use-case. Cockburn's idea is to avoid a multiplication of details, and this is why he recommends "Manage xxx". In this regard, the extend is worse since instead of four use cases, you'll end up with 5. ANd semantically, my argument still stands: Manage project is an independent use case. If it needs extensions, then it's no longer independent. If it doesn't need them, why bother to show them at all? Moreover, the extensions are not really extensions: in reality, it's about specialization. – Christophe Oct 17 '21 at 09:07
  • @Krellex In case I was too fast in the reasoning: if you had an independent "Manage X" the reader would understand that this UC is about creating, updating, viewing, etc..). But if on the same diagram you show "Create x" as an extension, it means that the "Create" is not part of "Manage", since an extension is needed to cover it. THis is why the extensions empty the main UC from its substance to a point that it is not independent anymore. A better example would be "Manage X", extended by "Clone X": the creation goal is covered by "Manage", but the "clone" exends it an optional goal. – Christophe Oct 17 '21 at 09:17
  • After reading your first comment I edited the post to show the specialization version to see if it did make more sense. Would you instead just recommend having "Manage Project", "Manage User" which would imply CRUD which would then allow me to then remove the extend relationships? – Krellex Oct 17 '21 at 09:21
  • 1
    Usually, I prefer a UC with the big picture and have a couple of "Manage Xxx" without the CRUD details. The reason is that in my domain, usually different groups of people are interested/involved in the different "Xxx" and the "Xxx" represent also different sets of requirements. So yes, I'd recommend this if you're in a similar context. You can then always work at a more granular level with specializations if needed. The key to a successful UC diagram is to focus on users goals (CRUD is not always a good approach) – Christophe Oct 17 '21 at 09:41