constraintsumluse-caseuse-case-diagram

How to Represent Constraints for Role-Based Access Control in a Task Management Use Case Diagram?


I'm working on designing a use case diagram for a task management application, and I'm seeking guidance on representing role-based access control (RBAC) effectively.

I've created a preliminary use case diagram that includes actors such as "Manager" and "Standard User," along with various use cases like "Manage Projects," "Manage Tasks," and so on. However, I'm struggling to depict the relationship where standard users are restricted to projects and tasks assigned by managers.

I've created two use cases 'Manage Assigned Project' and 'Manage Assigned Tasks'. Tasks are dependent on a project. The manager is linked to the assigned project via association.

How to represent this constraint effectively in the use case diagram?

diagram

If deemed useful, here are the requirements I need to cover:

  1. The application should support CRUD operations (Create, Read, Update, Delete) on projects and tasks.
  2. Tasks can only be created if a project already exists.
  3. Managers should have access to all features across all projects and tasks.
  4. Standard users are limited to projects and tasks assigned by managers.
  5. Standard users can only read and edit tasks.
  6. Managers should be able to assign tasks and projects to standard users.

Solution

  • The manager and the project manager both aim to manage projects and tasks. It's their shared goal.

    It's just that their role and contributions in regard of this goal changes : while the manager has a greater responsibility, and probably has to identify, specify and assign tasks, the standard user contributes to the management of these items, of course limited to the assignements. This pleads to make manager a primary actor of manage project and manage task, and make standard user a supporting actor to the same use-cases.

    Whether you follow or not the advice, you could show the contraint in the diagram with a text between curly brackets { only for projects/tasks assigned to the user }. This would however clutter the diagram with too many details. A better alternative is to describe the constraint in the use-case description/ narrative.