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.
Related
The system has 3 types of users : system admin, company user and supplier user. One of the system functionalities is to manage a list of unit costs for some actions. I am trying to draw a UML use case of this specific functionality but I don't really know if I am doing it properly.
Only the system admin and the company user can access this functionality, is it right to specify that like in the picture below?
Is there something wrong or mistake in this use case?
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.
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 ... :)
I am going to draw uml use case diagram for follow scenario :
In the university to set up a new coffee management system. These are the (informal) requirements:
1. A coffee machine dispenses coffee at the press of a button.
2. There are different coffee flavors (espresso, cappuccino, or latte macchiato) with different
prices.
3. Every user has an account on the coffee management system.
4. Every user logs on to the system using some identification (a password or picture).
5. Users choose the coffees they had (or will have) and mark them as “dispensed”.
6. The price for the coffee is automatically deducted from their account.
7. A special user (the “administrator”) can recharge user’s accounts.
How can I create a use case for the above scenario including alternatives and exceptions.
I tried to draw use case diagrams, please if someone can check is it correct or not. Thanks in advance.
I had here a dialogue with one UML starter over another system. I think, the discussion could be useful for you.
I would:
change type password to login. Throw off verify user.
Add create login, set password, change password, delete login - more use cases for Admin.
Join login and all those into Account management rectangle = a subsystem.
Nowhere it is said that the user should be student. Don't limit entities without reasons.
Add Add/Remove/Edit Sorts and Set/Edit Prices use cases to Admin. Join them into Assortiment subsystem.
Add View Assortiment for the User.
Put generalization arrow from admin to user. Admin can use the system, too, and he needs login.
Add look account state to the user
Where do you have this "mark them as “dispensed”" and how do you imagine it?
Use some tool for editing. To redraw the diagram at every edition takes much time. (You could take free variant of VP-UML, it is not ideal, but practicing this you are learning to one of the three widely used proprietary tools)
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.