Search code examples
umlactoruse-casevisual-paradigm

Some help diagram a use case with Visual Paradigm

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

Solution

  • 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.