0

I need help to reduce the use cases on my subsystem.

This subsystem is about manage multiple accounts for users, administrators and a superuser with the following requirements:

The system shall manage users accounts, where there are:

  • Users: can create, read, update, delete and block their own accounts, also login.

    Create needs email authentication. Login should ask for 2-step auth (optional)

  • Admins: can manage all users accounts (CRUD, block and login) as a user. Also read only and login their own account.

    Login needs 2 step authentication.

  • Superuser: can manage both users and admin accounts (CRUD, block, logins) and their own superuser account.

    Create admin needs email & phone auth.
    Login is same as admins, needs 2 step auth.
    Can delegate the superuser access to another admin.

The system's flow need to be clear just with use case diagram and use case descriptions (without other type of diagram)

What is the right way to design these use cases to avoid redundacy on use case descriptions and make unnecessary use cases on diagram?

For example, on this system, the user, admin, and superuser have a Login Use Case each one. User Login ask for 2 step auth (optional) while on admin and superuser the 2 step auth must be always required.

SuperUser inherits from Admin who inherits from User.

The final goal I am looking for is to make (for instance) these 3 login uses cases into one that connects to the User Actor only so Admin and SuperUser inherit the use case but, due to the behavior is different for every Actor, I want to put one Login Use Case Description which changes the behavior according to the Actor type who triggers the Login. So instead of have 3 Login Use Cases (one for each actor), I have just 1 use case and 1 description that works for all.

Christophe
  • 68,716
  • 7
  • 72
  • 138
Josael Perez
  • 94
  • 8
  • 1
    It does not help to delete and repost a closed question without editing it. Voted to close again. – qwerty_so Aug 03 '20 at 13:25
  • I already edited it, I deleted all other questions and leave just one, also made a summary of the requierements to be more clear – Josael Perez Aug 03 '20 at 13:27
  • 1
    Well, you changed some words. But basically it's the same as before. Why "reduce the use cases"? That's illogical. Either you have the UCs for your system or you don't. – qwerty_so Aug 03 '20 at 17:28
  • Oh, the thing was that other users told me that my old question was confusing (the first version) cause it had multiple questions (for syntax, rules, reduce, meanings, and so on), then I changed it but was closed. So I refactor and focus on just reduce this time – Josael Perez Aug 03 '20 at 21:32
  • 1
    I made research and found about CRUD pattern, so I could have 1 use case which describes those 4 behaviors in its description, but I can't find a way to make the description clear for multiple actors who inherit one use case, so maybe I'm missing something – Josael Perez Aug 03 '20 at 21:38

1 Answers1

2

What you seem to look for is the parametrised use-cases, which is a concept promoted by Alistair Cockburn for textual use-cases.

The typical example is CRUD when the same use-case description is used over and over again with a slight variant for each operation. The approach is the to have a parametrised use case where the parameter is the operation (create, read, update, delete).

The same concept doesn’t exist in UML notation as far as I know. So you would typically have either a use case Manage XYZ and describe the details in the narratives, or the four use-cases Create XYZ, Update XYZ, Delete XYZ, Read XYZ. Personally I prefer the first, so that the use-case convey the big picture.

Instead of multiplying the same use-cases for the different actors, you could also use less use-cases and use contraints to explain in plain text the special rules that apply to the different categories of actors for the different use-cases.

Finally, I’d like to add that use-cases are not meant to model flows and sequence of events. Use cases are meant to identify different goals that would translate to different kind of interactions. In this regard I wonder if it could make sense to distinguish Manage own account and Manage other user account since this correspond to very different goals.

Christophe
  • 68,716
  • 7
  • 72
  • 138
  • Okay, the second one is what I'm doing right now but it makes me to create 4 similar narratives with some variations (steps for auth), which is what I want to avoid, so I 'm trying to put just "Manage XYZ" for 1 Actor A, which at that point is okay, but if another Actor B comes to inherit from A, I don't know how to change the single actor use case narrative for multiple actors in common. What you said about parameters and constraints is actually very useful but, Can I use them just in the narratives? and, Can the parameters be actors? – Josael Perez Aug 03 '20 at 23:26
  • Also, when I started to learn about sequence diagrams, I realized that if I merge CRUD operations (for instance) on 1 use case, the narrative and the sequence diagram will grow each time a new actor comes to inherit. I wonder if UML standard tells you the right way to reduce use cases, with clear narratives (like follow conventions) without making more complex sequence diagrams when merging similar use cases (like one CRUD only use case for different actors involved) – Josael Perez Aug 03 '20 at 23:41
  • @JosaelPerez yes you can use them only in the narratives. The constraint in the diagram is only if you want to communicate these rules in a concise manner. The parameter could be whatever you want, including actors if some steps in the narrative are actor-dependent. – Christophe Aug 03 '20 at 23:48
  • @JosaelPerez The UML standard says nothing about narratives. For this you may read Cockburn’s excellent book “Writing effective use-cases”. His approach on describing parameterised cases should help to make growth easier. – Christophe Aug 03 '20 at 23:52
  • Thank you, I guess it is what I need, I will read it! – Josael Perez Aug 03 '20 at 23:58