Primary Actor in Use Case - uml

Let's assume we have use case that can be triggered by two or more actors e.g. User1 and User2. It will have the exact same flow for both actors. How should I describe this use case correctly? Who is the primary actor - User1 or User2? Should I make two scenarios for both actors or make one and set two primary actors?

If two different users can use the system for the same goal, there is in fact only one use case that has one primary actor. You need to come up with a common name for the two users and create an actor that generalizes both users. Often this is difficult, because, other than having the same goal, both users might have nothing in common. In this case just use an artificial name that contains the goal. If both might want to use a door to enter the room, the common name could be "room enterer".

Related

How to identify the correct primary actor from the use case diagram?

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).

UML diagram use case condition

I am creating use-case diagram. I have two actors: user and admin. Admin can check all orders, and user can check only his/her orders.
Should I create two use cases in my UML diagram, or I can use one use case with condition for user actor?
If I can use condition, which symbol must I use? Square brackets or curly brackets?
You need to attach a constraint to either the connector, the use case or the actor (where it's most appropriate). It could look like this:
Note that this is an example and contains redundant constraints which should not be done for a real UC.
I believe you are doing too much as part of your use case analysis.
Use cases are listing what your users (actors) can do and what benefit they get from doing those actions.
Thinking that way, each user/actor will have a set of actions (use cases) that will provide them with a benefit.
In your example, you should have many use cases for each actor, e.g., Admin would be able to create/delete users and provileges (UC1), list all actions from one or many users (UC2) and both would yeild different results.
When you start building your domain and behaviour models, then you will start adding the details of the behaviour.

IS it possible to have a Scenario table without any actor request?

I have a general feature for sending user location to the server, finding location of him on the map and then finding some places near him.
If I separate this feature to two use cases, Second scenario table should start with no acting from member actor.
My question is if I can use two use cases and write second scenario table without acting from actor or should I combine two in one use case and scenario table
You need to learn that UCs are not meant to be decomposed. A UC represents a single added value for an actor dealing with the system under consideration. If there is no actor involved, you don't have a UC.
If you encounter lots of scenarios which are repeated in different UCs, then most likely your system is cut the wrong way.

UML use case diagram 2 actors connected with 1 use case

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.

How to represent login of multiple users in UML use case diagram?

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.

Resources