Class diagram for user actions depending on roles

Question

I'm a beginner in UML, I have a PHP app where there is an admins area and users area. a user can have either admin role, user role or both. In the user interface we can submit a salary_request for a salary advance, and then in the admin panel we can either accept or deny the salary_requests and that will simply change the status for the actual salary_request.

The Database is as follow :

• users table : id, email, password, first_name, last_name
• roles table : id, name
• user_role : user_id, role_id (relation table between users and roles)
• salary_requests: id, amount, date, requested_by, validated_by, status

so the Classes are :

• User
• Role
• SalaryRequest
• and Status enum

I don't know how to add these relations/rules in the Class diagram :

• User can have one or multiple roles
• if the User is a simple user, he can only submit SalaryRequests
• if the User is an admin, he can accept or deny the SalaryRequest
• if the User has both roles admin & user he can add SalaryRequests and also accept or deny them.

All I could figure out is this Class diagram which is incomplete and I'm not sure if it's correct so far :

Answer 1

User can have one or multiple roles

Multiplicities can be applied to the association between User and Role to identify this. In UML, multiplicities are written in text at each end of the association, either in a list of absolute values or as a range in the form "Lower .. Upper", with '*' being a wildcard meaning "any".

For example:

• 0 .. * which means zero or many.
• 1 .. * which means one or many.
• 1, 2 which means one or two only.
• 1 which means exactly one.

Thus the association between User and Role could have a multiplicity of '1' (exactly one) on the User end and '1..*' (one or many) at the Role end.

However, I suspect that a Role can have more than one User fulfil it, so I suspect that the relationship is actually User '0..*' to Role '1..*'. I.e. a User must have 1 or more Roles, and a Role can have zero or more Users.

if the User is a simple user, he can only submit SalaryRequests if the User is an admin, he can accept or deny the SalaryRequest if the User has both roles admin & user he can add SalaryRequests and also accept or deny them.

This is a little harder explain how to express, as the answer depends on what you're trying to explain and why.

Class diagrams express aspects of the structure of your code rather than its behaviour, and what you are trying to express here is more behavioural.

The association between User and SalaryRequest in your diagram is already broad enough to cover all of the rules that you have identified above, so purely from a class-design perspective you could leave it as it is and explain the behavioural rules of the system in some other way (e.g. use Use Cases or an Activity Diagram to explain it instead).

However, if you think that the rules are strong enough that you need to encode them in the structure of the classes, then you would have to start deriving out different sub-types or composites in the classes that encapsulate the behaviour you want and then use associations between those to cast the rules in stone in the structure. But, a word of caution: I'm not sure you actually want to do this structurally, as the cost of changing structure is generally higher and more far-reaching than in changing behaviour.

Edit Following Comments Below

This is a possible way in which you can try and capture the behavioural rules in the structure of the classes. This example uses interfaces and operations (i.e. structural elements that encapsulate behaviour) to do that. You will notice that the behaviour is attached to the Role rather than the User. The User in their capacity fulfilling a Role performs these behaviours -- i.e. it's the Role that has the rights, not the User per se. At least that's my logic :-).