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.
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.
Is it allowed in UML to generate arrow as follows between Administrator and Member ?
On one hand, Admin is a secondary actor because he will react according members actions.
On the other hand, he amends the website's content and can do everything a member can.
I have a doubt on the style of the arrow because it is not properly straight showing the heritage, is that an issue ?
What does UML say?
The difference between primary and secondary actors is not UML. The UML specification (see UML 2.5.1 page 638) does not even define the semantics when several actors are associated with the same use-case:
Each UseCase specifies some behavior that a subject can perform in collaboration with one or more Actors. (...)
The manner in which multiple Actors participate in the UseCase depends on the specific situation on hand and is not defined in this specification. For instance, a particular UseCase might require simultaneous action by two separate Actors or it might require complementary and successive actions by the Actors. (...)
An Actor models a type of role played by an entity that interacts with the subjects of its associated UseCases.
In UML, actors are classifiers, and classifiers may be specializations of other classifiers of the same kind. So, yes, from an UML perspective, an actor can be a generalization of another actor regardless of primary or secondary.
By the way, the notation of a generalization is a big non-filled triangle shape. The small arrow head whether open or plain is not correct; it's even misleading.
Is it about roles or is it about users?
According to your narrative:
Admin is a secondary actor because he will react according members actions. On the other hand, (...) he can do everything a Member can.
The main question here, is to know if you speak of the users (i.e. the persons who interact with the system) or if you speak about the user's role. To help you determining that, let's reason with an extreme case: suppose you'd have an intelligent bot or an external system that would replace the Admin (e.g. using some kind of interface); would this automated Admin still have to be a Member?
If yes, the role of Admin seems to automatically imply the role of Member. Generalization is ok.
If no, the role of Admin in reality independent of the role of Member and it just occurs that human users that have the admin role also have the Member role. In this case you should not use the generalization.
Use-case value and primary vs. secondary actors
UML is neutral about that, but use-cases should in principle be of value to a user, and help the user to achieve his/her goals. Without this principle of value, there is no primary and no secondary users. Here for example Spence & Bittner's definitions:
Primary actors: (...) The primary actors are those for whom the system is built; they are those to whom the system provides sufficient economic value to warrant its construction.
Secondary actors: These are the actors that support the use cases provided by the system and those that support the system itself.
I suspect that if an Admin generates quotes ("devis" in French in your diagram) and invoices ("Facture" in French), there are chances that it's not a secondary actor, but a primary actor.
Last but not the least, verify your usage of include and extend. This seems to correspond to a navigation flow or a functional decomposition (or both) of your system and not really use-cases. But I'll not develop more: for that you'd need to translate your use-cases.
Is a Generalization between primary & secondary Actor allowed?
primary and secondary actors do not exist in UML standard, so there is nothing in the standard saying this is not allowed.
In your case you can have that generalization because you it does not create a circularity.
Is it allowed in UML to generate arrow as follows between Administrator and Member ?
I don't know what is the relation drawn between Membre and Admin in your diagram, so I prefer to say no
I have a doubt on the style of the arrow because it is not properly straight showing the heritage, is that an issue ?
yes it is an issue because one does not know what that relation is / means
If you want a generalization the arrow head is different :
There are other problems in your diagram :
I do not see why Admin is a secondary actor, in your diagram Admin is always a primary actor. But see remark 5 below
by definition a Membre cannot register nor login, so Membre cannot activate the UC s'inscrire nor se connecter. An actor like guest can login or subscribe
when an UC includes an other than means the included UC is always done each time the including UC is activated. You certainly do no want Member login each time he/she want to edit his/her profile, same for Admin each time an account is deleted etc, and as I said by definition of the actors Member and Admin the login cannot be activated by them.
For a lot of people "se connecter" (login) does not have enough plus value to be an UC
how a Membre can "consulter l'historique de ses demandes / devis / facture" while Membre cannot ask the system to create them (with Admin as a secondary actor) ? Visibly some UCs a Member can activate are missing
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.
Can anyone give a good example of a use case diagram involving two actors?
Also, the diagrams generally have lines without arrows to connect actors to use cases. However, when two actors are involved, do the lines have to show a direction to indicate the path of messages?
For example, I have a system in which users can form groups. One user will initiate the formation of the group and request the other user to join. So in this case the use case will be form groups and will lines connecting to use case have an arrow from the 1st user who initiates the group formation to the 2nd?
Actor 1 -> Form groups -> Actor 2
Actor 1 -> Form groups -> Actor 2
- is a piece of information to be shown in some activity or sequence diagram.
On the Use Case diagram you show WHAT will be done and BY WHOM, but not in what sequence. If all users can start the group and if the user-starter has additional possibilities, then the use case will be:
Notice, Starter participates in group, too, but as he is getting all features from his parent, we needn't show it.
Also notice, that sequentially, Starter was a Newcomer, but he wasn't Joiner (this session). But structurally his parent is Joiner, because Starter has all his functionalities.
You can connect any number of actors to a single UseCase. The connection is of Association type and direction does not represent communication. By UML definition, the system executes a usecase in collaboration with actors. Actors are always external to the system that defined the usecase.
The behavior of a system which realizes a usecase can be defined by behavioral diagrams e.g. sequence, activity. Actors are represented as Lifeline in sequence or partitions in Activity.
An example could be the UseCase "Apply Payment order" of an Internet Bank application.
UseCase has two connections, one to "User" and the second to "Backend System" actors. The UseCase is realized by the Internet Bank in collaboration with the user and the backend system of the bank.
What is the best way to represent the use cases of a system which has multiple users who have to log in to a system, in order perform various tasks?
For example, consider a university system where the admin can log in and add students to a database and the registrar can also log in and modify the data base?
Please post a simple use case diagram if possible.
You can simply represent each user (or, more scalable, each group or role) as an Actor. Each Actor would then be associated to a different set of use cases.
If there are is-a relationships between Actors, you can of course use hierarchies, so the children will inherit their ancestors' use cases.