Displaying levels of access for different types of accounts in a UML diagram

Pardon the title, it's a bit hard to properly explain what I need help with, but I'll give it a go.

I'm working on a Java project, an order management application. I've got several classes for the different types of functionalities in the application, e.g. an Order class, a Client class, a Task class, etc. Each of these tasks have methods that pertain to the things they do, e.g. the Order class has a method called newOrder() - you get the point.

There's been a change now and I need to add something new to the application: there's supposed to be three different types of accounts from which you can access the application: Admin, Project Manager or Developer. Each of these accounts will have different types of access to the functionalities of the application. Admins and project managers will have similar levels of acccess, but the developers will only have access to projects (orders) where they have been given access by an admin.

I'm in the stage where I'm drawing up the UML diagram for this and I'm really struggling with how I'm supposed to visualise this. My first thought was to create a User class and three subclasses (Admin, Project Manager & Developer) that all extend to the User class. Each of those three classes will include the methods for what they're allowed to do, e.g. the Admin and the Project Manager classes will have the method newOrder() but the Developer class won't have that.

I'm sure you can tell that I'm quite new at this, but any help you can give me at this point is very appreciated!

First of all, let's get rid of an ambiguity: what OOP languages usually call access level, access modifiers, access specifiers is called visibility in UML. It's shown with an extra character at the left of the class member: + for public, # for protected, - for private and ~ for package.

But it gets quickly obvious that you are not interested in access level in the OOP sense, but in authorisations and access control in the application. And there is no general UML solution for that. It's entirely dependent on your requirements and you design:

• You may indeed have different specialisation of a more general User and define at compile time what sub-class can do what operation. Your approach would be a good start for that. Unfortunately, a same user would not be able to have several types of accesses at the same time.
• Alternatively, you could have only one class of User but also a class Role, and each User could have one or more Role. This uses composition over inheritance and is more flexible.
• Aleternatively, each business entity, such as Order could be affected to an AccessControlGroup (e.g. user department? subsidiary code? or just an access code?): the Role would be related to one or more AccessControlGroup.
• Or you could even need more complex access control groups if you want to combine for example groups of data with groups of operations with a finer control of who can do what with what data.

As you see, different requirements may require very differents design.

Lastly, there is the question: where to put the newOrder():

• is it in the Order class itself? Then that method could take User as argument, to check dynalically if the User is authorised to.
• is it in the User class ? But should different categories of users with the same rights implement the same newOrder() method?
• is it some class representing a business transaction or a use-case?
• ...

As you see, there are plenty of solutions. It's not only the requirements, but also about architectural choices, about class responsibilities and seperation of concerns. Full books were written on those topics, if you want to dig further.

Conclusion: UML will no tell you how your solution should look like: you need to make the choices, and then you will show in UML what you have decided

This is base of OOP thinking. You have already identified the required Objects and verge of identifying Properties and Actions. You need to get the requirement right from different sources then identify the possible actions for Developer, PM & Admin object(Actor). Now, of course, set of common actions can be moved to User (Parent).

I feel , your thinking is going right direction, just need to get more clarity on requirement to identify right set of actions which will turn into series of methods.

Steps of doing UML Design could be ...

1. Identifying Usecase / flow
2. Identifying Objects (You already did)
3. Identifying possible Actions for each objects
4. Identifying possible properties for the object to hold the state of the object
5. Coming up with Sequence Diagrams showing interactions between Objects in an
   Usecase

Note, start with Simple and minimum detailing then, evolve from there. You are on right track already.