Let's say that i have started making an use case diagram for tourist agency web application. So what bothering me is the thing that i am not sure should i make administrator role and connect him with other actors with the generalization because they share common behaviors.
For example, i have web-site visitor as a role, then i have registered one who can book hotels... Now i was thinking of putting the administrator role who would have permissions to do what ever he wants to do. So all i need is your advice and what you would do if you will ever have the similar problem.
Yes, you can do that. And it's a common pattern. An actor represents (plays) a role within the system under consideration. And if you find people acting with different roles you can apply a generalization. Especially if you generalize Administrator from User this says that the admin can do anything the user can do.
Related
In my application each user can create his own system and add team members to it. Each team member in scope of a system has a certain set of permissions, basing on which system decides if team member can access the functionality.
Some examples are:
Access to analytics board
Access to system configuration utility
Access to team management utility
Access to service handling utility
Each team member can have assigned any combination of these permissions.
I'd like to create an UML use case diagram, but i don't know how to represent use cases which are restricted only to team members that are allowed to use them.
Representing permission is like breaking the generalisation os UML use-case diagrams. You need to write them down in your use case scenario and for UML you can have separate section wise representation.
I don't think that use case diagram is sufficient for your requirements. You are talking about a user who has set of permissions. These permission are variable in time. It doesn’t depend on position (what’s more, we are not talking about being a deputy for a boss who just left for holiday).
In this case I always prepare use case such as Manage Permission and an actor is always a user. Then I make a class diagram where the user/permission model is. Then you have several possibilities how to work with permissions:
In every scenario the first step should be checking the permission to
do this steps.
Every use case has a preconditions related to
permissions.
…
Check the diagram where the simplest example is.
In the model part, I use actors inheritance to model right. For example, the
most simple actor is "user" and it is linked to use case "login" only, it gets the minimum right.
Others actors inherit from it. Like that they all have the right to connect to the system.
The most powerful actor, let say Administrator, inherits from all actors like that it gets all rights.
After you can not translate this in code automatically ... :)
The admin is able to do everything the same as the user, AND see and modify the tickets that are not theirs. Normal users can only do all that on the tickets that they have created. Another difference is that the admin gets a list of all the tickets, while users get a list of their own tickets only (the "Show all tickets" extension). Those are the only differences between the user and the admin.
How do I represent the admin?
Adding another actor and connecting to all doesn't seem like a good idea.
Each of the ticket related use cases have a condition "User created the ticket.", simply adding "OR user is an admin" would pretty much do the job, but then it wouldn't be clear that the system has an admin. The problem is that the admin is basically a user with one additional permission.
While it isn't directly explained in UML specification, you can add another user admin, show generalization between actors where admin is a specialization of user and link UCs that can be performed by admin only to admin actor while UCs available to user (and admin) only to user actor.
A specialized actor has access (can run) all UCs of an actor it specializes plus its own UCs.
Such approach is suggested e.g. by Howard Podesva (see "UML for IT Business Analysts") and is compliant with UML specification.
Note also that the association between actor and Use Case shows only that the actor is somehow involved in UC. While in most cases it is initiation it doesn't have to be always the case.
Now both admin and user can do the same thing, but admin can have few extra use cases.
Company X wants a web-based system that serves as a market place of ideas. Users should be able to login and post new ideas. Other users can comment on them and “upvote” them. The Administrators can login and mark that ideas have been implemented, and can reward the employee who posted it.
Following are the requirements:
Users should be able to login.
Users should be able to post a new idea.
Users should be able to search for and view other ideas
Users should be able to comment on ideas
Users should be able to upvote ideas
Administrators should be able to mark ideas as implemented
Administrators should be able to delete unwanted comments
Do you guys think my diagram is correct? I am new to UML so you guys can make fun!
http://imgur.com/TGKhweh
It is a not so bad start. Only:
Administrators are also users. They descend from them. So, they should have a generalization connection - empty triangle head arrow from Admin to User. Or to OtherUser (look below).
it is more natural to have a picture and name of an exemplar of agent. So, user, administrator - in singular.
you can divide Users from Other Users only if they have different definition and that difference is seen from the documentation, too. It is not. I would use only Users.
Of course, if some users really have different rights, it is OK, but:
the name is not good, IMHO.
They have all options of users, don't they? So they have to descend from Users
You should continue by adding the parts of your future system, that will collaborate with human agents on these use cases. Now you have only the first half of work done.
Edit:
Still your admin hasn't the generalization error from Admin to User. Admin can do ALL activities that user can, cannot he?
Still you have no subsystems on the diagram.
Search through older ideas should be the use case directly connected to user. And it does not extends nothing on the diagram.
Remember - use Include and Extends only on the last stage of UC diagram creation. When you already have the main picture and are refining it. And very often they should be used only on further, more thorough diagrams. Using Include and Extend from the start means that you haven't found the main concepts yet.
I am working on a project with very detailed security requirements. I would honestly not be surprised if the model proposed was as complex as for any intelligence/security agency. Now I've read that incorporating security with business logic is a mixing of concerns and thus a practice to be avoided.
However, all attempts at abstracting security have either failed or created "abstractions" as messy as before. Is it possible for security to be so specific that it becomes part of business rules? In some situations violating security, only masks the data, whereas in other situations will terminate the session, and at others time it will trigger default values to be used instead. The are many requirements that respond to security priveleges.
My fundamental question is: could I be in an exceptional case (i.e. one where incorporating security is sound) or am I not understanding something fundamental about abstracting security?
Edit:
tl;dr (of answers as I understand them): authentication (who are you) is very much a cross cutting concern and should be abstracted, whereas authorization (what can you do) is business logic. Lacking that vocabulary and having only the term "security" (or perhaps failing to appreciate the distinction between the two) lead to my confusion.
Security is split into two parts; authentication and authorization. Authentication is a pretty specific use case. How do you determine that a user is trusted out of a set of untrusted users. I think this is cross cutting; you need to keep unauthenticated users out of your system, or a subset of your system.
Authorization (can the user do something) is very much a business rule. It can (and often is) very specific and different to each use case. Who determines what roles can do what? Well, the business does. No one else can answer that for you.
In the Csla.Net 4 framework, that's exactly how authorization is treated; as a specialized business rule. You're not even limited to "user is in role" or "user has permission." You can make more complex rules "user can edit this field if workflow step has not past this particular step."
I suppose an exceptional case would be if your business logic IS security services of some kind then yes. However I think your problem may be that you are confusing user authorization with authentication.
Certainly Authentication should have a set of rules associated with it but the end result should be, identification of the user and creation of the session.
Authorization would be seperate from that where we determine the user role, and what privileges are laid out by that role.
A typical example would be that Authentication returns a User object and stores it in session. The User has 1 to many roles. A role may have 1 to many privileges. A business logic method might be sendEmail. This method queries the User object for a specific privilege, if it exists do something, if not do something else.
EDIT: Security in my opinion should always be a cross cutting concern when it comes to the user, however if your business logic involves properties of objects that are not the user, CRUD of those objects, or administering other users then it falls in line with your business requirements and thus is Business Logic.
IS it best to configure permissions within a website for Administration access, separate webPages, or a completely separate application to administer changes on the site?
I usually configure permissions within the same website and have separate web pages for administration.
In some cases, having the same page with more controls can be useful as well, for instance, if you want a page to Approve/Reject comments, or something like that, instead of creating a separate interface you just add a few buttons depending on the role of the logged in user.
I often find that with questions starting "Is it best to" that there's usually a someone and a sometime involved (a kind of pragmatics type thinking - whome and in what context)
Different contexts will offer up different pro's and con's for each of the scenarios you've presented here and depending on who requires what functionality may also sway your choice.
With regard to the "who" part there may be other questions you'll be asking yourself about the process you're going through. Is it my users that require admin access, is it my development team, is it the managing director with little I.T. experience etc etc.
Questions about the medium used may also play a role in the decision you make. Are the "admin" people going to be on a PC, sales reps on-the-road using a palmtop which might suit it's own software application etc.