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. 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. 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". But I am afraid you missed the point in the item (b) however. 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". 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). 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). So, all in all, there is one - and only one - primary actor for each use case. Which the system communicates while carrying out the use case. Use case is trying to satisfy and is usually, but not always, the The primary actor is the actor with the goal the The same idea is supported by Martin Fowler in his classic UML Distilled:Įach use case has a primary actor, which calls on the system toĭeliver a service. Secondary actors may or may not have goals that they expect to be satisfiedīy the use case, the primary actor always has a goal, and the use case exists the Oracle Unified Method (OUM) concurs with the UML definition ofĪctors, along with Cockburn’s refinement, but OUM also includes the following: Secondary Actors: Actors that the system needs assistance from to achieve the primary actor’s goal. To achieve the goal of the primary actor. Use Case documents the interactions between the system and the actors Primary Actors: The Actor(s) using the system to achieve a goal. 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".Ī brief discussion on use cases in a post from An Oracle blog about Unified Method also highlights the difference between primary and secondary actors: To quote the excellent "UML Classroom", written by Seidl, Scholz et. Extra actors are supporting the system somehow to make it meet the primary actor's demand. Including both those in which the goal is achieved, and those in which the goalĪs Cockburn makes crystal clear, a use case exists to fulfill some need of a single actor. The use caseĬollects together all the scenarios related to that goal of that primary actor, Sets of interactions that can occur between the various external agents, orĪctors, while the primary actor is in pursuit of that goal.
Is called primary actor for that use case. The use case is associated with the goal of one particular actor, who 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. Number of related activities having a common goal. Perform to achieve some outcome of value.
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):Ī use case describes a discrete, standalone activity that an actor can 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). 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.
0 kommentar(er)
