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.
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 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've never made a use-case diagram before so I'm wondering if mine is correct or not.
In short
This is an (almost) valid use-case diagram. But this does not make make them good use-cases. But what matters in the end is if it is useful to you.
More details
Is it formally correct according to UML?
UML is value-agnostic and defines UC on page 637 of the specs (highlight by me):
A UseCase is a kind of BehavioredClassifier that represents a
declaration of a set of offered Behaviors. Each UseCase specifies some
behavior that a subject can perform in collaboration with one or more
Actors. UseCases define the offered Behaviors of the subject without
reference to its internal structure. These Behaviors, involving
interactions between the Actors and the subject, may result in changes
to the state of the subject and communications with its environment.
Let's check the validity of your UC in view of this definition:
Start game, move paddle, restart game, and exit game are behaviors that the game (subject) offers in collaboration with the player (actor). These are valid UC according to UML.
Ball falls, hit all bricks, hit brick, and display score are behaviors that are more questionable: they do not require a collaboration or an interaction with the player. You could nevertheless argue that these make sense only if the user observe these behaviors, so there is an interaction with the player. So it could be claimed that these are also valid UC in regard of the UML definition.
Add score seems to be a purely internal behavior that is done without the user and not even observed by the user. This would not be a valid UC. However labels might be misleading: if Display score would mean the final game-over score and Add score would mean an update of the score on the screen, it could again be argued that it's a valid UC.
The use of extension (optional) and inclusion (systematic) seem also correct.
Is it a good UC?
While UML is value-agnostic, many authors define a use-case in a more ambitiuous way. In particular Ivar Jacobson, the inventor of the Use case defines it as:
A use case is all the ways of using a system to achieve a particular
goal for a particular user. Taken together the set of all the use
cases gives you all of the useful ways to use the system, and
illustrates the value that it will provide.
According to this definition, there is only one single use case here:
Play a game : this is the goal of the user that brings him/her value.
All the other elements are only ways of using the system to achieve this goal. So they belong to the single use-case. A approach would be to represent them as detail of the use-case description:
One suitable way would be to show these in terms of intent in an essential use-case. This approach was invented by Constantine and Lockwood in 1999. It is used centered and leaves full flexibility about the sequence of actions in the user interface.
Another modern way is the Use-Case 2.0, invented by Ivar Jacobson in 2011. These detailes would be shown as use-case slices, in a very similar way than user-stories.
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 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.