Some help diagram a use case with Visual Paradigm

0
votes

I am modeling a use case in UML using Visual Paradigm CE but I have a few doubts regarding my model. Take a look to the picture below:

enter image description here

This are the rules I am trying to represent with that model:

  • There are 3 user types: Superadmin, Admin and Executive
  • There is a functionality called: Admin User
  • Admin User is divided in 4 basic actions: Create, Read, Update and Delete
  • Superadmin has all the power (can do anything) while Admin only has a few permissions (in this case Create User)
  • Executive can only perform a few actions within the system: Create User and Delete User

Taking this as a starting point, the diagram is correct? How would to do? I must say this is a example use case just to get the correct way to represent the relation between diagram elements.

Update: Based on the answer by @thomas-kilian I have made this two diagrams:

including CRUD in Admin User UC extends CRUD from Admin User UC

2
umlactoruse-casevisual-paradigm
In most cases you can combine all the CRUD scenarios into a single use case such as "Manage Users". I would not model those low level security requirements on the use case level. – Geert Bellekens
@GeertBellekens yes but then I could have troubles describing the UC as it should have several actions and I am not clear at all on how to achieve this description – ReynierPM
Use use case scenarios to describe the different cases. – Geert Bellekens

2 Answers

2
votes

Do you really need use case "Admin User"? Maybe the following diagram will suit your needs:

enter image description here

If you really have behavior in 'Admin User', not contained in the other use cases, then you can keep it, but I would use a consistent naming convention, e.g. verb + noun, and thus rename 'Admin User' to 'Administer Users'.

Diagram 1 is possible. In this case, SuperAdmin can reach the 'Create User' functionality both directly (inherited from Admin) and via Admin User. Apparently, Admin User has multiple alternative flows. Create User is included in one alternative flow, Update User in another, etc. This is fine.

Diagram 2 is also possible. In this case, SuperAdmin can only reach the 'Create User' functionality via Admin User.

Diagram 3 is possible, but tricky. Actors 'Admin' and 'Executive' are associated to so-called "extending use cases" Create User and Delete User. An extending use case typically only defines a use case fragment, which is to be inserted at a particular point in the extended use case (Admin User). But since actors Admin and Executive directly execute use cases Create User and Delete User, these use cases must describe complete flows of events. If you manage to define the flows of events of the extending use cases such, that they are suited both for direct execution and for insertion at the extension points inside use case Admin User, then it's fine.

0
votes

It mainly depends on whom you are asking. So here are my 5 cent:

  • Avoid include/extend as they are a sign of functional decomposition (if at all: extend in your diagram is the wrong way around)
  • CRUD UCs are always borderline. I would in this case not try to introduce the Admin User as it does not seem to be a valid UC while the CRUD parts are.
  • As you connected the actors the Super Admin can do anything, but the admin can only create. That does not seem to be logical. If you have a generalized actor, this inherits all access to UCs of the general one. Means: you don't need to repeat the connections to UC (unless you add some constraints).