In my application, I have actors guest, user and admin, user can use basic features and admin can do things like manage users.
Beside, each user can create an organization, and inside organization also have different roles: member, collaborator, and admin
I drawed a use case diagram that have this generalization:
user <- member <- collaborator <- owner <- admin . But clearly admin can only access organizations that admin belongs to, so admin cannot have generalization from owner. So I think this is not the right way.
I’m thinking of create 2 different use case diagrams for this case. One is system-level (contains guest, user, admin) and one is organization-level (contains member, collaborator, owner). The problem is that I don’t how to represent relationship between these 2 diagrams, maybe I can use a note description to depict that relationship?
Appreciate for any help on this.
Thanks!
hdat.syzygy is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
1
Use of generalization is a great idea and elegant solution. However, it should be used wisely an only when it corresponds to the reality of your domain:
- Your argument suggest that not all admins are owners. So don’t use this generalization.
- However from your narrative I understand that admins always belong to an organisation. You may therefore consider
adminas a specialization ofmember.
There is one ambiguity in your narrative: are the admin actors (first paragraph) the same than users that have the admin role?
With this question in mind, and considering that UML actors correspond to roles that an external user can have, I’d suggest the follwoing approach:
- Rethink your actors with only one set of roles, focusing on why actors would use your system. This will facilitate the use case analysis that should focus on the goals of the actors.
- If this is not possible or would require duplicates/combined roles, consider indeed two diagrams, one for the system concern, and one for the organizational concern. I am not sure however that the first one will bring much value added.
Also don’t forget that you can use constraints in your diagram to express in plain words important constraints, such as the need to be logged, or having a subscribtion, or the fact that an admin can only perform use-cases for the organization he/she belongs to.
1