UML用例图2个actor与1个用例相关联

Question

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:

Answer 1

Your response A ie 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

Answer 2

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.

Answer 3

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 is the specification of a set of actions performed by a system, which yields an observable result that is, typically, of value for one or more actors or other stakeholders of the system.

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 ; ie, 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 (ie, 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.