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.
Related
I read that it is not correct to connect more than one primary actor to a use case so a situation like the image below is not correct
So I used inheritance like this
But the use case has an extended use case that is for only one actor (the second actor does not have that extended use case).
So in my example both manager and HR can browse users but only the manager can block a user.
How can I represent that in the diagram?
Two (or more actors) connected to one use case mean that all actors are involved in this use case. If you want to show, that either one of multiple actors can be involved, a generalization is a good possibility.
The notion of "primary" actor is not specified in UML. Therefore, I talked about actors involved in a use case. Of course, in the description of the use case you will be clear about which actor initiates the use. This will be the primary actor.
All the problems you have with «extend» can be solved by simply omitting it. In my opinion «extend» doesn't contribute to a better model. If you want to say that there is an overlap in the description of several use cases, you could use «include». But actually, you should not worry too much about these relationships. After all, you want to describe what actors are using the system for. Each actor goal is an own use case.
I'm with Axel: stay away from «extend» unless you know what it's meant for. I would guess that in your case it's legit. So what you can do is to just add a constraint to either the extend relation or to the actors explaining the restriction. Simply show it as a note with the constraint { in curly brackts}.
Otherwise there is a convention to put primary actors (the one that triggers the UC) to the left and involved actors to the right. Your approach with generalization is just fine. An actor represents role (like in a screenplay). And identifying those roles is an essential part during UC synthesis.
As always I recommend to read Bittner/Spence about use case modeling.
This notion of "primary" actor is not in the latest (2.5.1) version of the UML Specification. You just associate the right actor/s (Manager, HR or both) to each of your use cases without using generalization (inheritance).
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).
I wondered if anyone could let me know whether this diagram is approximately correct?
I am depicting a database booking system and am very confused about the relationships between some of these use cases. I am fairly sure that I should include them on the same diagram but unsure whether some of my actors (Vet / Nurse) should be on the right hand side because they are kind of end-users whilst also being first users (sorry can't recall the term).
So when you modeling a Use case diagram, you have to realize that you can only approach for describe the functional requirements of the system.
Your system is treated as a blackbox-that is, dealing with what the system does in response to the actor's inputs, not the internals of how it does it. And use case always starts with an input from an actor.
Before modeling a diagram, you have to identify actors(Primary, Secondary), use cases & use case relationships. Actors are who or what initiates events involved in the task of the use case. Actors are simply roles that people pre objects play.
According to your problem,
A dog owner calls the clinic to make an appointment for a yearly
checkup. The nurse finds the nearest empty time slot in
appointment book and schedules the appointment for that time slot.
in here you can see that two people, dog owner and nurse involving the scenario, but the actual actor who interacts with the system is the nurse.
And the use case is a summary of scenarios for a single task or goal. So, you can see that Nurse is Making the appointment for the dog owner.
So to finally, you have to identify what are the relationships. simply relationships are representing communication between actor and use case or dependencies between use cases.
Dependencies between use cases can be defined by using include & extend relationships.
Include is using for determine to identify common sequences of interactions in several use cases. (Can be extracted and reused)
& extend is using for model alternative paths that a use case might have.And you have to keep in mind that base use case doesn't depend on the extension use case
What is the meaning of the direction of an association between actor and use case in a UML use case diagram? Is it data flow direction or control flow direction? Does the standard say anything about this?
Ah no. This is an association, in the norm, association between actor and use has no direction. Please see image extracted from the norm.
The usage is: if the actor is on the left, it means that's a "primary actor", the actor who activates the use case. If the actor is on the right, it means that the actor is a secondary one: he participates to use case but does not activate it.
Please, take care to the multiplicity: "The example shows that a Customer or Administrator may or may not participate in any of their associated UseCases
(hence the 0..1 multiplicity). From the UseCase perspective, every UseCase in the example must have an Actor to
initiate it (hence the 1 multiplicity). The Deposit and Register ATM UseCases require participation by the Bank, while
the bank can participate with many Deposit and Register ATM UseCases at the same time." (extract, p641)
The point is if you get a lot of actors, keeping them on the left or the right is not easy. So "I" (but this is my way, not the norm) use directed association, if this is from the actor to the use case, it means that's the actor is a primary one, if this is from the use case to the actor it means this is a secondary one.
Direction in UC diagrams have no agreed common meaning. I once used directed vs. un-directed arrows to distinguish between primary and secondary actors (and wrote that down in the modeling directives of the domain). I'm not the only one doing that. And only later I learned that (as #granier pointed out) it's also common to just put primary actors left and secondary actors right of the system boundary.
N.B. As commented #granier the UC stuff in the UML spec is too techie. Some of it is fishy like include/extend which is simply mistaken for functional decomposition. The picture #granier took from the specs even lacks good wording for UC names. I'd rather go and read Bittner/Spence who really know what they are talking of in business terms.
Is UML allowing this?
Can I define how an actor is interacting with use case?
In other words, can an use case have a different action depending on who triggered it?
For example in the following picture, Client pays for food, and waiter accepts the payment, but client and waiter are connected to the same use case. Wouldn't it be more convenient, to make separate use case called "Receive the payment" for waiter?
UML allows such things, but they are nonsense (like you can use English language to talk nonsense). A use case represents an added value for its primary actor. And if you have some UC Pay for food this is only a UC for the Waiter, not for the Client. The latter is only a secondary actors and of course he has no added value from this UC - rather the opposite.
If you want to follow very strict way describing how Client interacts with a restaurant as System under Discussion then you don't have Waiter as an actor, it's part of the System and does not belong to diagram of this level.
Is it possible for use case to have different action depending on which Actor triggers it?
Technically yes, but it smells bad. Consider to split the common part into separate scenario (this probably would require creation of a new common role as well). Anyway this is not related really to the main part of your question.
Client pays for food, and waiter accepts the payment, but client and waiter are connected to the same use case.
Here goes the tricky part. They aren't connected to the same use case, only client is connected to your "Pay for food". A use case describes interplay of Actor and the system under discussion. In "Pay for food" Waiter is a part of the system, you just don't have it as an actor on this level.
Wouldn't it be more convenient, to make separate use case called "Receive the payment" for waiter?
It's not about convenience actually, but yes. You have "Client pays for food" step in some high level "Client eats in restaurant" scenario. You can expand it into a scenario one level lower with steps like "System provides a receipt", "Client gives cash", "System returns change".
Now you can expand "System provides a receipt" into yet another scenario now on Subfunction level where you can finally introduce Waiter as an actor and describe steps how he goes to cash register, unlocks it with a badge, selects table, click "print receipt"... And on diagram of this level you will finally put Waiter as an actor.
Very easily. UC diagram has special words for that.
You can have an action of Payment that will Include actions of Receiving Money and Paying. It is absolutely normal.
Don't forget, that the use case diagram needn't to be the most common diagram in the project. UML outspokenly doesn't limit diagrams to abstraction levels. So, you can make more common use case, without include subtasks and later make more specific one, with include's. The first one will be that to be shown to the client, and the second one probably will not.