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
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 have created a use case diagram based on a scenario, I identified 5 actors in total.
However, I am trying to identify the correct primary actor.
I am undecided between Team Leader and Maintenance Engineer as primary actor as they work pretty closely.
There are two levels at stake here.
For a whole system or a whole use case diagram there may often be several primary actors:
The primary actors are the ones for whom the system is built; they are the ones to whom the system provides sufficient economic value to warrant its construction. - Bittner & Spence in Use Case Modeling
At the level of a single use-case, there may often be one primary actor:
The primary actor of a use case is the stakeholder that calls on the system to deliver one of its services. (...) The primary actor is oten, but not always the actor who triggers the use case.- Cockburn in Writing effective use cases
In your case, it's even more ambiguous since you seem to have 13 use-cases split between 3 different systems (and some floating in-between): at which level are you looking for a primary actor?
Hints, not related to your question**
reread the narrative carefully, and make the difference between the location where the users are assigned, and the software system they are using (I suspect there's only one system at play);
keep in mind that the use-case is not a user task outside the system but a goal that the user want to achieve with the system (e.g. does "Return parts" correspond to an activity in the system?)
keep in mind that some actors may correspond to other systems that shall interact with the system you are design (e.g. is FMS really in your scope or is it a supporting actor?)
A primary actor is always the one that triggers the use case. Being external to the system under consideration he is the one to gain added value from using the system. There might well be multiple primary actors for a single use case. For the Install UC it would be both Leader and Engineer.
A so-called secondary actor in contrast is only involved in a way that its interaction is needed somewhere in the course of actions triggered by the primary actor.
Sometimes it makes sense to create an actor from which all primary actors inherit. You would give that actor the role name he plays. Just like in a theater. So in your case for the two "main" actors you can simply draw a generalization from Leader towards Engineeer. That means the Leader inherits from Engineer and thus has access to the Install use case. So bascially the Leader acts as Engineer (which pretty much makes sense).
So here is the relationship. Actor user is going to borrow from Actor Librarian. librarian uses the system to check if it is available and verify user thru a company id card.
I am aware that we don't put Actor user in the use case model since he will never use the system. It is only the librarian who can access it and since we are also not allowed to put relationship actor to actor.
How am I going to represent that this user interacts directly to the librarian and not the system?
Usually use cases are used to model things in the Platform Independent Model (PIM) aka Logical Model aka Functional Model.
In this case we describe only the behavior that will actually be automated by the system. That means that the interaction between the user and the librarian is out of scope.
The complete picture is drawn in the Computation Independent Model (CIM) aka Contextual Model aka Business Model
In this model the most popular notation these days is not use cases but BPMN.
So the user should play a role in your CIM, but not in the PIM.
You can always extend notations to your needs to convey your idea. E.g. you can do this:
What this example shows?
Does it mean:
a) Actor1 and Actor2 can use Use Case1
b) both Actor1 and Actor2 are needed to start Use Case1 (for example two people need to turn keys for firing rocket?)
c) Actor1 can start Use Case1 and Actor2 does something later
d) Actor2 can start Use Case1 and Actor1 does something later
Am I right that answer B is correct and:
A would be:
C would be:
D would be:
Your question is conceptually rich and quite relevant since it addresses a key notion of the use case diagrams, which is the purpose of the actors. To start with, understand that the sole purpose of an use case is to allow a given actor (the primary actor) to reach a well determined goal (defined as a set of actions that yields an observable result). If more than one actor is enabled to do that, either those actors are actually a single one or the use case delivers more than a single functionality, which is wrong (quoted from here):
A use case describes a discrete, standalone activity that an actor can
perform to achieve some outcome of value. A use case might encompass a
number of related activities having a common goal.
The goal the primary user achieves with a use case may deliver value to one or more actors, but keep in mind that only a single actor can be the primary one: if you have several actors associated to the same use case, one of them is primary and the remaining ones are necessarily secondary. To quote the well renowned expert A. Cockburn:
The use case is associated with the goal of one particular actor, who
is called primary actor for that use case. The use case describes the various
sets of interactions that can occur between the various external agents, or
actors, while the primary actor is in pursuit of that goal... The use case
collects together all the scenarios related to that goal of that primary actor,
including both those in which the goal is achieved, and those in which the goal
must be abandoned.
As Cockburn makes crystal clear, a use case exists to fulfill some need of a single actor. Extra actors are supporting the system somehow to make it meet the primary actor's demand. To quote the excellent "UML # Classroom", written by Seidl, Scholz et. al, "If a use case is associated with two actors, this does not mean that either one or the other actor is involved in the execution of the use case: it means that both are necessary for its execution".
A brief discussion on use cases in a post from An Oracle blog about Unified Method also highlights the difference between primary and secondary actors:
Primary Actors: The Actor(s) using the system to achieve a goal. The
Use Case documents the interactions between the system and the actors
to achieve the goal of the primary actor.
Secondary Actors: Actors that the system needs assistance from to achieve the primary actor’s goal.
... the Oracle Unified Method (OUM) concurs with the UML definition of
Actors, along with Cockburn’s refinement, but OUM also includes the following:
Secondary actors may or may not have goals that they expect to be satisfied
by the use case, the primary actor always has a goal, and the use case exists
to satisfy the primary actor.
The same idea is supported by Martin Fowler in his classic UML Distilled:
Each use case has a primary actor, which calls on the system to
deliver a service. The primary actor is the actor with the goal the
use case is trying to satisfy and is usually, but not always, the
initiator of the use case. There may be other actors as well with
which the system communicates while carrying out the use case. These
are known as secondary actors.
So, all in all, there is one - and only one - primary actor for each use case. Now, you have in your first diagram two actors and only one (the primary actor) is entitled to use the system in order to achieve a goal (the other actor assists the system to achieve the primary actor’s goal). This description fits the alternatives (c) and (d) in your list, but remember: it is not mandatory that the primary user starts the use case (it could be initiated by an internal or temporal event as well).
You interpreted correctly how item (a) has to be depicted since both Actor 1 and 2 are specializations of Actor 3, the one associated to the use case, which makes correct to state that "Actor1 and Actor2 can use Use Case1". But I am afraid you missed the point in the item (b) however. Indeed, item (b) does not depicts the first diagram as you supposed because you stated that "Actor1 and Actor2 are needed to start Use Case1". Again, use cases are initiated by internal (also "state"), temporal or external events (you can read more about that here); so, since there is a single primary actor for a given use case, by no means it needs two actors to be started. If you need an actor do something in order to allow another actor start an use case, this would be a pre-condition for that use case. With this regard, note that you can always use the notion of multiplicity to specify that two or more instances of an actor are required to execute the use case (here):
If a multiplicity greater than 1 is specified for the actor’s association end,
this means that more than one instance of an actor is involved in the execution
of the use case.
For clarity, consider the following reasoning. An actor is a role played by one or more users within the context of an executing use case. So, if Mary and John are system's users entitled to start an use case named, say, Sell an Item, both are playing the same role at that very moment as a single actor named, say, Seller. It doesn't matter that, in reality, they are a sales clerk and a sales manager: in the use case diagram, both act as a "the" Seller (actor).
In the picture below, you can see three use case diagrams, where we can further extend the argument.
UC-1 shows an use case in which two different actors, Sales Clerk and Sales Manager, are required to execute the use case Sell an Item; i.e., in the UC-1's description, both are needed to run it. That could indicate, for example, that every sale performed by a clerk has to be approved by a sales manager. In this case, Sales Clerk is a primary actor because it starts the use case and get some benefit from it (perform a sale) and Sales Manager is a secondary actor (it is involved in the execution).
In UC-2, both the manager (Sales Manager) and the seller (Sales Clerk) can sell an item (i.e., start the Sell an Item use case). Given that both perform the same role as a seller, this is likely to be modelled as an inheritance as depicted - Sales Clerk "IS A" Seller and the same goes for Sales Manager. As pointed out above, both actors are acting as "the" seller (Seller).
UC-3 depicts exactly the same situation seen in UC-1, with a minor difference though: the arrows indicate clearly who is the primary and the secondary actors (Sales Clerk and Sales Manager, respectively). As far as I am aware, those arrows are not standardized (quoting UML # Classroom: "Graphically, there is no differentiation between primary and secondary actors, between active and passive actors...").
To finalize the argument, consider the following use case diagram:
Could you say that both actors, Seller and Credit Card Company are entitled to start this use case? Of course not, this would be plainly wrong, as we know beforehand that credit card companies do not sell items in stores, but support sales through their computerized systems. In the same fashion, it would be a mistake to state that both Sales Clerk and Sales Manager might start the Sell an Item use case in the UC-1 diagram above.
Take a look here to a textbook on that.
Your response A i.e. Actor1 and Actor2 can use UseCase1 is the correct one.
Of course you can model that with your second diagram but in this case the model is a little bit different. Actor1 and Actor2 can also use UseCase1 but this is due to the fact that they are specialization of Actor3 which is the only kind of actor having acces to the usecase1
By UML definition, Actor is external entity to context of UseCase (for example modeled system, modul etc.) By definition, during usecase execution, system interracts with Actor. Association between UseCase and Actor does not define uses of usecase by Actor, but collaboration between Actor and system.
Association navigability in usecase diagram does not define communication as well.
A would say, all answers are correct, because it is not possible to determine, which actor initialized usecase, when it interact with system or what actor does.
You can provide more detailed description using definition of behaviors of system which implements (realize) functionality declared by usecases.
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.