I am developing a use case diagram for dog veterinary. However, I was confused that whether I should use dog as an actor or not as it cannot communicate with the system. However, everything that system does is totally dependent on dog like, checking, giving injections e.t.c.
What is an actor?
The key is to define precisely the system under consideration (called the subject in UML-speak), since this determines what is or is not an actor:
Each UseCase specifies some behavior that a subject can perform in collaboration with one or more Actors.
(...) An Actor models a type of role played by an entity that interacts with the subjects of its associated UseCases (e.g., by exchanging signals and data). Actors may represent roles played by human users, external hardware, or other systems.
A more general requirement analysis concept is the stakeholder. All the actors are stakeholders, but there may be stakeholders that are not be actors, for example, if they benefit from a system indirectly.
Is the dog an actor?
It depends on the system under consideration. The main cases are:
The system is an app only used by the veterinary: the dog is not an actor. The system supports the veterinary to achieve his/her goals. There is no direct interaction between the dog and the system (except by accident, if he jumps on the keyboard). The dog nevertheless benefits indirectly from the system, so you may consider it as a stakeholder (should not be represented on the diagram)
The system is composed of a veterinary app and equipment that exchanges signals with the dog (e.g. microphone for AI barking analysis, camera, cardiovascular monitoring electrodes, echographic scanner...). The dog is an actor, even if the dog is passive in the interaction and does not realise that there is a computer involved. The dog is a secondary actor because the use-case supports primarily the goals of the veterinary.
The system is the veterinary clinic: You are then making a business analysis. The dog owner would be a primary actor, since he/she interacts with the clinic for achieving his/her goals, i.e. keeping his/her best companion in good health. The dog would be a secondary actor since it would also interact with the clinic for the use-cases of the owner (wilfully or not). But in such an analysis, the veterinary would be part of the system under consideration and not an actor.
In view of the wording of your question, you're most probably in the first case.
I would suppose it to be a secondary actor. That means it will take part in a use case but not starting it. You can leave it simply out or if you intend to differntiate between different animals you can also use general forms (like mamal).
Indeed an actor is someone/thing that gets added value from the system under consideration. I would think that a pet feeding has also an animal as primary actor. Probably not the case here, but just think of who gets the added value: that's an (primary) actor.
Related
I'm stuck and confuse if I need to identify Database as an Actor since the database is given in the scenario.
I tried first to make it as an actor since based on the scenario, the data needed is from database. I Also tried to create a use case for the whole scenario but not sure if correct.
Here is the link of the scenario: https://justpaste.it/7tljo
The Use Case Diagram I created:
Is the database an actor?
A database should in principle not be an actor in a use-case. Two reasons for that:
A database is in general a component used to implement a system, so it is part of the system's internals (even if it is bought from a third party and installed on a separate server). But actors must be external to the system.
Actors may represent separate systems that interact with the system. But some degree of autonomy is expected since they play a role in the case: either the system actor supports the use-case, like a human actor could do, or it uses the system for achieving its own goals.
More generally, some useful question to ask yourself about candidate system actors: does the business need to know? are users or business stakeholders interested in? is the system actor a system that would be useful if your system wouldn’t exist? could we imagine the same use case with a human user instead of a system actor?
Is the overall diagram ok?
Syntactically, the diagram looks ok. But it methodically break down features/functionality in smaller pieces. This is called functional decomposition: Although it is not forbidden by UML, it leads to complex and unreadable diagrams. This is why the use-case community recommends not to do this, and instead prefer to align use case on user goals.
Hint: if you start to think about workflows, order of operations or user interface components when you design your use-cases (e.g. review contract, approve contract), you probably should consider using an activity diagram instead.
This is a question confused me for a rather long time.
For the definition of stakehoder, I can understand that a stakeholder is not always an actor. For example, to build a nuclear power station, the National Nuclear Safety Administration may be a stakeholder, but it does not interact with the station, so it's not an actor.
But on the other hand, is an actor always a stakeholder?
Consider this: we build a underground cable system, and some rat bite the cable. In usecase analysis, I would like to model the rat as an actor, but it is definitely not a stakeholder of this system.
Well, the rat has an interest in not being electrocuted. So, it is a stakeholder. The question is, how important you consider it to be. Probably not so much.
Also, you would not analyse the use case "satisfy hunger for cables". Rather you should analyse how to "protect cable against rat bites". Both are valid use cases, but I assume, that you don‘t want your system to be used in the first way and therefore you should not model it. The second one is only a use case, if your system shall have functions to drive off rats.
The UML doesn‘t say much about how to describe use cases. I always recommend to describe them from the viewpoint of the stakeholder for whom the result is of value.
In short
Yes, every actor is always stakeholder. But not every stakeholder is an actor.
Some more thoughts:
First definition
In the UML specifications, there is no definition of stakeholders. But it is said that:
[A use case] specifies a set of behaviors performed by that subject [i.e. the system], which yields an observable result that is of value for Actors or other stakeholders of the subject.
This wording also suggests that actors are stakeholders: if they weren't, the word "other" wouldn't be needed.
By the way, this clearly eliminates the rat from the suspected actors, since the cabling system is not supposed to produce results of value for rats. And the result that could be observed on the rats is not of value for the other stakeholders.
How are stakeholders related to use cases?
Many systems produce an observable result that is of value for the actor interacting with the system: the actor benefits of cash after a withdrawal, the actor could achieve a task with the system, etc...
But the value is not always for the actor. If you walk through a body scanner at the airport, as a user you might not fully value the results of being scanned yourself. But the airport, the airline, homeland and security, and the other passengers may very well value the result of the use case. This shows that not all stakeholders who have interest in a system, are necessarily users.
Second definition
As strange as it may sound, the SWEBOK does not define the stakeholder either. They just enumerate some examples, such as users, customers, regulators etc. ISO 21500 does also have a definition by example.
Moreover, we must keep in mind that the interest of a stakeholder is not only the own benefit, but could be the opposite. If your neighbor installs a video surveillance system with a camera that captures the entry of your house, you're neither the customer, nor the user, but you will probably be a stakeholder perceiving a threat for your right to privacy.
A popular definition is therefore the PMI's:
An individual, group or organization that may affect, be affected or perceive itself to be affected by a decision, activity or outcome of a project, programme or portfolio.
We can cross check that according to this definition that all actors are stakeholders, since they will be affected by the future system.
And the rats?
Rats are in principle not actors of an underground cabling system, as the system is not build for providing them value nor to involve them to provide value to other stakeholders. Rats could be considered as stakeholders if we'd extend the concept to animals: they may be affected or think to be affected by all this cables. Bust most probably, they are simply a source of malfunctions in the system's environment.
This reminds me a story that an old system engineer told me 30 years ago, and that happened to him at the begin of his career, probably another 30 years before. It was on his first bigger computing project, a large electromechanical computer designed to compute the payroll of a large organisation. For some reasons, there were some mistakes every month, but never the same. After months of (expensive) debugging, they found out that some rats indeed have eaten the hull of some cables in the floor space under the very large computer, and if a rat by chance walked on the wires at the wrong moment, it closed random circuits that were supposed to stay open. A more modern version of the first bug?
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).
Can I business actor use normal use case on use case diagram in UML or maybe he needs business use case?
Also I would appreciate explanation of difference between actor and bussines actor.
UML does not define business actor or business usecase. It is simply Actor and UseCase.
You can created business model of Bank for example using standard Actors and UseCases. But, methodologies can extend UML elements by stereotypes like "business actor" just to say, that model is defined on business level.It is again standard UML usage.
Extending the answer from Vladimir. As answered, there is only use case concept in UML:
UML extension mechanism based on stereotypes permits modeller to give the particurar meaning to general UML concepts.
Use case model base semantic idea is to model interactions between Actors and System. Use cases are units of this interaction. By default the context is a software system, so Actors are system users and the System is a software system. Use cases model usage of software system by actors.
"Business use cases" are one of UML extensions, pretty well known. It defines business actors and business use cases (among other elements).
It shifts the default concret model meaning. System is not more a software system, but rather a Business process. Actor is not a software system user, but rather a business process participant (a worker). A business use case is an interaction between a worker and business process and must not mandatory involve software system.
Back to your question... You should not directly mix business use case elemnts and "normal" use case elements, simply because they live in different apstractions! Thea are interrelated and a business actor can easily give a corresponding system aytor, but they are two sepaarate model concepts.
An example:
A business use case could be "Create an invoice", business actor "sales agent". This business task can be performed different ways, e.g. manually and via system.
In the first case (manual), there is no corresponding system use case, because there is no system involved.
In the second case, we could use a software system to enter the invoice. The actor can be a "Sales Agent", but it's a different entity from the first one (although might refer to the same physical person).
Note that the ampping between two models is not 1-1. They will always be quite different as they focus on different abstractions. SOme actors might overlap, some new can be introduced in the system model, some can exist only on business level.
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.