1

I'm on creating use case diagram that contains two actors: Admin and Super admin. The admin can do all the tasks as the super admin except the delete. The use case in the picture below is it right : use case diagram

the digram is on french:

**gérer  les utilisateurs** = manage users
**modifier un utilisateur**= edit user
**consulter un utilisateur**= view user
**rechercher un utilisateur**= search user
**ajouter un utilisateur**= add user
**supprimer un utilisateur** = delete user
Geert Bellekens
  • 12,788
  • 2
  • 23
  • 50
stack user
  • 37
  • 3
  • 2
    I'm beginning to think Use Cases modelling is simply to hard to get right. 90% of the use case questions here are basically the same. A bunch of includes and extends on diagram, containing functions and not use cases. – Geert Bellekens Jun 08 '22 at 12:50
  • @GeertBellekens I would guess that the teachers (or online lectures) are just doing it: functional decomposition. A really pity. – qwerty_so Jun 08 '22 at 15:30
  • 1
    It would be better if you created a translated diagram. Now you are just making it harder for people to help you. – Geert Bellekens Jun 08 '22 at 17:47
  • Another one: I'd guess the top right is `Login`. right? If so, that is no use case but a simple constraint attached to either UCs or actors. (Btw: you did not translate thatn your table; two times the same UC is also bad.) – qwerty_so Jun 08 '22 at 18:05
  • @qwerty_so I think that the question is in English, and OP even made the effort to provide a translation (which is more difficult to perform quickly in a picture). I therefore see no reason to close the question. Moreover, we have plenty of questions, with use cases called "UC1","UC2","UC3", which is not English either and is not more understandable than the picture without the translation. – Christophe Jun 08 '22 at 18:17
  • 1
    @Christophe You might have missed that I already retracted my close vote. Anyhow, UC1 etc. is as bad as non-English since you need the business context. – qwerty_so Jun 08 '22 at 18:20

1 Answers1

1

The «extend» approach is not suitable because it requires the use-case Manage users to add value on its own without any of the extensions. You‘ll find more arguments in this other answer. The right way to address this issue — if this level of detail is really desired — is to use generalisation on the use case side as well.

If you would just have the CRUD cases inheriting from the more general Manage users, an Administrator could, by way of use case specialisation, also realize the more sensitive Delete user. There are several ways to address this:

  • keep the general use case without actors. Associate the normal user to the three specializations and the admin to the deletion only.
    Online example with plantuml: enter image description here
  • keep only the association of the normal user to the general use case, and use a constraint on the deletion use case, to make clear that it requires the user to be superuser (this would be my preferred one, as it would allow also to get rid of the (too?) detailed uc):
    Example: enter image description here
  • more variants using intermediate elements of generalisation.
Christophe
  • 68,716
  • 7
  • 72
  • 138
  • can u give me an example please because I didn't undersand – stack user Jun 08 '22 at 16:19
  • See my comment above. Christophe might suggest another read from Cockburn or one of the UC inventors (he now has a version 2.0 or so IIRC). I had a similar issue when I started with UC synthesis 20 years ago. You need to forget andf re-learn! – qwerty_so Jun 08 '22 at 18:02
  • @stackuser I gave some examples, quickly drawn. – Christophe Jun 08 '22 at 18:13
  • I don't think that CRUD are UCs. They are a start of functional decomposition. It's more than enough to add a single constraint `{ only SU can delete a user }` . Period. – qwerty_so Jun 08 '22 at 18:24
  • @qwerty_so I fully agree with your remark on the authentication. This is not a use case. It's a precondition to the other use-cases. By the way, the initial diagram shows two use-cases with the same name, which is not valid either. On the CRUD, we can discuss about whether it's a good idea or not, but it is not wrong (see my other answer). – Christophe Jun 08 '22 at 18:24
  • 1
    Cross-posting :-) – qwerty_so Jun 08 '22 at 18:25
  • @qwerty_so I didn't count the number of "Read Bittner and Spence" out there. And Bittner and Spence say that these are valid use-cases, but discourage their use only to keep the diagrams simple and avoid unnecessary specification work ;-) – Christophe Jun 08 '22 at 18:27
  • 1
    @qwerty_so cross-posting, or answer encapsulation and reuse ? ;-) – Christophe Jun 08 '22 at 18:28
  • I think a better alternative would be have either a `Manage users` use case, and none of the others, have only the other use cases. I don't see the added value of such an inheritance. – Geert Bellekens Jun 08 '22 at 21:33
  • @GeertBellekens I do not disagree. while I personally would not go for detailed use cases at the the sub-goal level (see the linked question and the conditional statement “*if this level of detail is really desired*”), I nevertheless wanted to provide ways to do this correctly, considering the issues with the extend approach in this case. – Christophe Jun 09 '22 at 05:40