For the sake of simplicity:
There is a permission based system in place with different kinds of user levels and actions (think: UNIX file system permissions)
What would be the best approach to visualize this in UML?
For the sake of simplicity:
There is a permission based system in place with different kinds of user levels and actions (think: UNIX file system permissions)
What would be the best approach to visualize this in UML?
I like to think of a file system object has having a number of standard methods, each of which has an associated permission.
There are 9 methods/permissions that of usually of interest: the combinations of (User, Group, Other) * (Read, Write, Execute). Additionally, there are options like Sticky and SetUID.
A file system object is associated with one user and one group. A user is associated with any number of groups.
The current user is associated with any number of groups.
The above is pretty standard class diagram stuff. File system objects, users, groups, associations. And the file system objects have a pile of attributes and the 9 canonical methods.
The constraint on what's allowed doesn't have a tidy diagram. It's a set of rules expressions. The first is which permission set to use (user, group or other) and then which permission in the set (read, write or execute).
You could, I suppose, define a class of users with some set of concrete objects (Unix has user, group, other), and a class of operations with some set of concrete objects (Unix has read, write, execute). You can then define permissions with two associations: one to user class and one to operation class.
I think it's easier to just list the complete set methods that to fussily diagram the combinations user class instances and operation class instances.
I typically have classes that represent Users, Roles, and Permissions. Users belong to Roles and Roles are granted Permissions. Permissions are required to access other objects. In UML I suppose that you would model Role as an abstract base class and have multiple different implementations, one for each role.
Typically, I model a Permission as object containing sets of readable,writable,delete-able business entity classes (perhaps containing property exclusions or inclusions). Each role, then has one Permission. That permission allows or denies access to one or more other classes. Permission is by default denied, and access only allowed if the class is in the appropriate set for the action requested.