This question already has an answer here:
UML Use case model: Actor Generalization
(1 answer)
Closed 6 months ago.
I have two main actors in the use case diagram where I am modeling the use cases for the visitors of my project: an admin and a user. A user has to signup and then login in order for him/her to open his/her page while an admin has only to login without doing the signup.
Can I make the admin a generalization of a user since he inherits all use cases of the user except for the signup use case?(ofc he has different use cases as well) If not, then should I show them as actors that have no relation between each other?
The generalization would look like this:
You may indeed make one actor to be specialization of another. This means that the specialized actor (i.e. at the tail of the generalization reliationship, here the Admin) inherits all the use cases of the more general one.
If some use-cases are not relevant for the specialized actor, you may clarify this by introducing some further abstraction: make a difference between all users and normal vs. admin users:
This being said, there is a debate about whether Sign-up should or not be a use-case. It is not independent of the others. In fact it's not a goal of user, but just a constraint that is required to perform any operation. And this constraint can be different depending on whether you're admin or simple users.
Related
I want a use case - store information system. I am to present the owner's requirements on a use case diagram, incl. a customer who, after logging in, does shopping, and an admin, who after logging in, manages prices, etc.
Can I log into the system generalize from one use case - two actors combined with one use case (below)? How can I 'improve' the diagram?
UML does not specify the semantic when more than one actor is associated to the same use-case. It can mean for example that one of the actors only is involved without the other, that the two actors are involved at the same time, or that the two actors are involved one after the other.
For sure, actors and use-cases are classifiers. You can therefore use generalization of use-cases or of actors (as explained with an example here) .
But your diagram, while syntactically correct, has some issue:
First Admin account is not a use-case: it does not produce any observable results to the actor; it is an internal detail of the sytem. So it does not correspond to the UML criteria of a use-case.
Then, Login, Confirm password (and perhaps Checkout?) do not correspond to user goals. As explained here, this is not fundamentally wrong according to the UML specifications, but it is a bad practice. Use-cases are meant to describe actor goals, and not details of a process or a user interface.
Maybe i'm old school, but you should also surround the use-cases with a box representing the "subject", i.e. the system under consideration.
There's no special magic about it, UML Use Case describes a case and can have more than one user.
Maybe just moving the shared Use Cases next.
But, since Use Case diagrams support User Inheritance as if they were classes, maybe adding a generic abstract superclass alike GenericUser with the shared Use Cases, and subclass alike User and Admin with their own specific Use Cases would be useful.
I am trying to design a Use Case Diagram for an app like Stack Overflow. I have tried to add some basic functionalities in this diagram.
I want to improve this diagram to include an exhaustive list of all the features of Stack Overflow, but have no idea of how to do so. Also, should there be another actor for Admin who manages user accounts, or not? And if we are asked for Use Cases, should we describe the inner functionalities, preconditions and postconditions of each use case separately?
What if other than these two actors, I decide to add a Mediator actor too, who forwards the problems to the mentor, and when a mentor solves it, it is the responsibility of mediator to mark it solved?
If you want to map all the use cases and actors in StackOverflow you can take the Tour and search for some known Q&A in the Help Center.
And yes, if you want to make an exhaustive list, then you should include every actor - including Admin and Mediator. However, I'm not sure that you can figure out the admin's use cases (or other managing roles in this platform) since you are a user and it isn't reflected to you.
If there are use-cases that are unique to a specific actor, then you should add that actor to the diagram - and use inheritance! (When actor b has all the cases of a plus more, then b is inherits a) - this one is called "Generalization of an Actor" (you can google search some examples).
As for your other questions:
Please note that Use Case Diagram is an addition to the Use Case Modeling, more like an appendix. When you are modeling - you explain lots of details about the use case (some of them you've mentioned), such as: Primary actor, Scope, User Story, Postconditions, Preconditions, Triggers, Flow, and many more... There are a lot of templates actually. You can review them Here.
You do not describe visually* any preconditions or post-conditions, however, you have some tools that can describe which cases are **included in a specific case (in order to use feature Y - you should go over feature X). Or, which cases extends other cases (while you are using feature X, you can (but not have to) use feature Y).
Hope it helped :)
I encourage you to use a modeler rather than to draw your diagram by hand.
I want to improve this diagram to include an exhaustive list of all the features of Stack Overflow
The exhaustive list of the features of S.O. is certainly very be long, and you will have problem too see it because surely some parts are hidden to 'standard' users. What is your goal, to model S.O. or to use it as an exercise ? On the second case it is not necessary to manage all
should there be another actor for Admin who manages user accounts, or not?
Sure they are admins or 'super' users.
if we are asked for Use Cases, should we describe the inner functionalities, preconditions and postconditions of each use case separately?
A use case is not only an ellipse in a diagram, and a model is not ajust a list of diagrams. Yes each UC must have its description and the possible pre/post conditions etc
What if other than these two actors, I decide to add a Mediator actor too ...
I don't know if there are mediators, but I am quite surprised by the 'mentor' whose role is to answer. If you have him you make a separation between the roles consisting to ask and to answer, so the other role cannot be the very general user but probably must be more specific
You will have lot of remarks about the UC login for sure ;-)
I am creating a Use-Case diagram in StarUML for a university project but I am not completely sure if I'm doing it correctly.
For example, on the website I am making I have 2 roles - User and Admin. The admin can do everything that the user can plus some extra.
In my Use-Case diagram, should the admin actor have the same use-cases as the user plus the extra ones only he can use or should he only have use-cases that are available to the admin.
Example 1:
User--->Upload File
Admin--->Upload File
--->Delete File
Example 2:
User--->Upload File
Admin--->Delete File
In the examples, User and Admin are the roles, ---> is the directed association and Upload/Delete file are the 2 Use-Cases. Which example would be the correct one?
As always there is single and clear answer ... it depends.
If you are realy doing use case analysis, then you want to identify what uses cases an actor needs and what actors are interacting with a use case. Thus, if an admin (when acting as an admin) shall also being allowed to upload files, then he needs an association to the correspondig use case. Becuase he might have some further needs for the use case as the user.
A second possibility is to model that an admin is also an user. This is modelled by generalization. This has some further effects and you need to be verycarefully when soing this (in larger context). And further, it is for non-deverlopers a bit cumbersome to see that a special actor is also a normal actor. E.g., consider this when saying the manager has more use cases than an employee (this will lead to long and pointless discussions with your manager...).
So your example 2 is not realy incorrect but misses the point of an use case analysis.
I have three main actors in my Use Case diagram, Admin, SuperAdmin, User.
Now SuperAdmin CRUD Admins, each admin have different privilege, 3 different privileges to be precise.
My question is do I have to create 3 types of Admins (so 2 more actors) which each admin is represented according to his privilege, or just create a single Admin actor & link it to all three use cases (the 3 privileges)?
I am new user of UML & This is my 1st project.
That depends on the privileges.
If a privilege is a use case - a specific behaviour of the subject(system you are creating), exposed to a user - then if two actors differ in admittance to this use case, they should be shown as different actors. For example, one admin can register a user, the other cannot. Make also different names for them.
If a privilege is NOT a behaviour - for example, one admin can set the priority level of user 0..5 and another can set it in range 0..7, they could be shown as one actor and their privileges could be shown as states. State machines, according to UML standard, can be included in Use Cases.
If the privilege is merely temporary, surely use one actor, because it IS the state. Don't forget, that different users in different moments often have different options. But this fact is to be described by state machine, inside or outside of the Use case diagram.
By UML definition, actor does not represent privilegies.
UML says, When system executes declared usecases, it interacts (or collaborates) with actors associated to usecase. It means, if actor does not have association (direct or indirect) to UseCase, it has not access to this functionality.
Actor can specialize other actor, it means, specialized actor interact with system during execution of usecases, thas more general actor has associated etc.
Do not define actors only just to describe privilegies, it is not correct approach.
I have a few questions regarding use-case diagram:
If my system has register/login use-case for guest, should it be enabled for admin, user (i just wanna clarify, if i have login system, do i assume that admin, user etc. are people who already logged in to system so i skip them with logging thing)?
If my system has a student actor, that is signing for individual seminars/courses, do i have (or am i allowed) to make use-case for ,,taking class'' after singing for them, and should there be relations between those 2
Should my teacher inherit from student actor, since he can browse courses as well? (and so on admin?)
Is my payment setup correct?
Remember that these are roles not people. An admin can be a guest, so long as they behave entirely like a guess, no special functions or rules. However, during log-in the user role could change, become admin. Note you are in some sense missing authenticate user, each use-case that requires security should include it, generally not extend.
Only if it interacts with the system, example, triggers an auto completion or is tracked in some way there of. Relations are not needed generally, associations could help communicate something that is ambiguous, but I am not sure what the would be in this case.
Nope, really then the role is any user could browse courses once they are authenticated. You could have students, admins, and teachers be sub-types of authenticated or associated person, etc.
Depends. Firstly you never pay and sign-up at the same time, so from a user standpoint that is broken. There are other ways in UML to connect this constraint of paying for courses. Process diagram, state diagram, etc. Because payment is really a long running transaction which can be hard to pin down. I would personally show the student and the external payment system interacting with the "payment" use cases.
Remember unless you are generating code most of the time UML is about communication so knowing your audience. Do not be afraid to use comments or constraints, if this is homework, use a constraint and get some real points. Maybe even put a constraint on the sign and pay course use cases.
If you want the admin to be able to log-in then he would have a use case for that. I agree that he most likely won't be registering, so maybe you want to break the register/log-in into two use cases?
You do not have to make a "Take Class" use case. Only make it, if that's how the user will interact with the system. My guess is that he won't be "taking" the class with the system, in which case it won't be a use case of the system.
I would think that you wouldn't want to inherit from student. First of all, from a realistic stand-point, it doesn't make sense. That would mean a teacher is-a student. You could extract that behavior to another parent class, but that might make the hierarchy too large and confusing.
If you are asking whether it is correct to say "sign for course" includes "pay for course," then maybe, it's probably better to use extend.
Another suggestion. The black arrow (usually means "dependency" in UML) you have between Actors and Use Cases, should probably be bi-directional, non-arrowed, line (this is usually called "association") At least that is what the UML standard says.