Can anyone give a good example of a use case diagram involving two actors?
Also, the diagrams generally have lines without arrows to connect actors to use cases. However, when two actors are involved, do the lines have to show a direction to indicate the path of messages?
For example, I have a system in which users can form groups. One user will initiate the formation of the group and request the other user to join. So in this case the use case will be form groups and will lines connecting to use case have an arrow from the 1st user who initiates the group formation to the 2nd?
Actor 1 -> Form groups -> Actor 2
Actor 1 -> Form groups -> Actor 2
- is a piece of information to be shown in some activity or sequence diagram.
On the Use Case diagram you show WHAT will be done and BY WHOM, but not in what sequence. If all users can start the group and if the user-starter has additional possibilities, then the use case will be:
Notice, Starter participates in group, too, but as he is getting all features from his parent, we needn't show it.
Also notice, that sequentially, Starter was a Newcomer, but he wasn't Joiner (this session). But structurally his parent is Joiner, because Starter has all his functionalities.
You can connect any number of actors to a single UseCase. The connection is of Association type and direction does not represent communication. By UML definition, the system executes a usecase in collaboration with actors. Actors are always external to the system that defined the usecase.
The behavior of a system which realizes a usecase can be defined by behavioral diagrams e.g. sequence, activity. Actors are represented as Lifeline in sequence or partitions in Activity.
An example could be the UseCase "Apply Payment order" of an Internet Bank application.
UseCase has two connections, one to "User" and the second to "Backend System" actors. The UseCase is realized by the Internet Bank in collaboration with the user and the backend system of the bank.
Related
I am Working on a project for Orders data visualization Dashboard.
This is the use case Diagram:
Currently I'm working on the activity diagram and my question is: Can the Manager and the Shipper login into the system and initiate their own activities in the same diagram?
An activity diagram "specifies behavior by sequencing subordinate units". It can perfectly have several initial nodes, e.g. one for Admin and one for Manager or Shipper. And when the activity is invoked, all those initial nodes would be activated at the same time, starting each a concurrent flow, each being performed at its own pace.
But this makes only sense if the Manager's actions and the Shipper's actions are really related, concurrent and somehow synchronized. E.g. every time an Admin login is performed, a Manager login would be expected.
If the Manager flow as well as the Shipper flow are both independent and in reality unsequenced, you should use separate activity diagrams. In this case, trying to squeeze them into a single diagram could even be misleading.
Additional remarks, unrelated to your question:
Typically you'd have a separate activity diagram for each use case. It's not an obligation, but it's a common practice to describe what happens for a specific use-case. In your case, it would mean that only the Ship Order and the Update product stock would be in a situation where actions could be interdependent.
When activity diagrams are used to design systems, it shows in principle what happens inside the system. The actors are outside the system. So the partitions (columns) would in principle not show what an actor does, but what the system does in relation with an actor. Of course, if you use activity diagrams for process modeling, it would be a different story.
Yes, they can. With each InitialNode a flow begins and the tokens run down the actions independently. Probably at a certain time you will have some synchronization between both (this is not mandatory but otherwise it would probably rather pointless to have two independent flows in the same diagram). In that case you either have a MergeNode (bar) to wait for both tokens to arrive or an action has two incoming edges waiting for both tokens in order to commence.
Is it allowed in UML to generate arrow as follows between Administrator and Member ?
On one hand, Admin is a secondary actor because he will react according members actions.
On the other hand, he amends the website's content and can do everything a member can.
I have a doubt on the style of the arrow because it is not properly straight showing the heritage, is that an issue ?
What does UML say?
The difference between primary and secondary actors is not UML. The UML specification (see UML 2.5.1 page 638) does not even define the semantics when several actors are associated with the same use-case:
Each UseCase specifies some behavior that a subject can perform in collaboration with one or more Actors. (...)
The manner in which multiple Actors participate in the UseCase depends on the specific situation on hand and is not defined in this specification. For instance, a particular UseCase might require simultaneous action by two separate Actors or it might require complementary and successive actions by the Actors. (...)
An Actor models a type of role played by an entity that interacts with the subjects of its associated UseCases.
In UML, actors are classifiers, and classifiers may be specializations of other classifiers of the same kind. So, yes, from an UML perspective, an actor can be a generalization of another actor regardless of primary or secondary.
By the way, the notation of a generalization is a big non-filled triangle shape. The small arrow head whether open or plain is not correct; it's even misleading.
Is it about roles or is it about users?
According to your narrative:
Admin is a secondary actor because he will react according members actions. On the other hand, (...) he can do everything a Member can.
The main question here, is to know if you speak of the users (i.e. the persons who interact with the system) or if you speak about the user's role. To help you determining that, let's reason with an extreme case: suppose you'd have an intelligent bot or an external system that would replace the Admin (e.g. using some kind of interface); would this automated Admin still have to be a Member?
If yes, the role of Admin seems to automatically imply the role of Member. Generalization is ok.
If no, the role of Admin in reality independent of the role of Member and it just occurs that human users that have the admin role also have the Member role. In this case you should not use the generalization.
Use-case value and primary vs. secondary actors
UML is neutral about that, but use-cases should in principle be of value to a user, and help the user to achieve his/her goals. Without this principle of value, there is no primary and no secondary users. Here for example Spence & Bittner's definitions:
Primary actors: (...) The primary actors are those for whom the system is built; they are those to whom the system provides sufficient economic value to warrant its construction.
Secondary actors: These are the actors that support the use cases provided by the system and those that support the system itself.
I suspect that if an Admin generates quotes ("devis" in French in your diagram) and invoices ("Facture" in French), there are chances that it's not a secondary actor, but a primary actor.
Last but not the least, verify your usage of include and extend. This seems to correspond to a navigation flow or a functional decomposition (or both) of your system and not really use-cases. But I'll not develop more: for that you'd need to translate your use-cases.
Is a Generalization between primary & secondary Actor allowed?
primary and secondary actors do not exist in UML standard, so there is nothing in the standard saying this is not allowed.
In your case you can have that generalization because you it does not create a circularity.
Is it allowed in UML to generate arrow as follows between Administrator and Member ?
I don't know what is the relation drawn between Membre and Admin in your diagram, so I prefer to say no
I have a doubt on the style of the arrow because it is not properly straight showing the heritage, is that an issue ?
yes it is an issue because one does not know what that relation is / means
If you want a generalization the arrow head is different :
There are other problems in your diagram :
I do not see why Admin is a secondary actor, in your diagram Admin is always a primary actor. But see remark 5 below
by definition a Membre cannot register nor login, so Membre cannot activate the UC s'inscrire nor se connecter. An actor like guest can login or subscribe
when an UC includes an other than means the included UC is always done each time the including UC is activated. You certainly do no want Member login each time he/she want to edit his/her profile, same for Admin each time an account is deleted etc, and as I said by definition of the actors Member and Admin the login cannot be activated by them.
For a lot of people "se connecter" (login) does not have enough plus value to be an UC
how a Membre can "consulter l'historique de ses demandes / devis / facture" while Membre cannot ask the system to create them (with Admin as a secondary actor) ? Visibly some UCs a Member can activate are missing
Im new in UML,
I am recently in charge of a web application, this application manages projects through a flow of states. There are multiple users within the application and each of them can intervene in the flow in a certain state.
Therefore I want to represent this information through a state diagram for me and for future developers do not have to ask the same question again.
My question is: How do I represent the different actors in the state diagram and their intervention in each of them?
Do I need to create a different state diagram for each actor?
Is there a diagram to do this that you do not know?
Thanks.
This is my example diagram and how an actor can pass from stateX to stateY
You try to oversimplify your model.
Each actor has certain system functionality that they can run. These single functionalities are called Use Cases (UC) and you present them on a Use Case diagram. This diagram shows which Actor can perform what Use Case but it does not show a relation to a state. While each Use Case can have pre-conditions defining what has to be true before the UC can be performed and post-conditions declaring what will be true if the UC ends successfully (which in your case would both probably be something like "System is in State A"), UC diagram does not support showing pre- and post-conditions. You can always add them in the notes attached to a UC.
To have a clear view of the system State Machine you can use two diagrams. One will be UC diagram, the other one will be State Machine Diagram or to be more specific Protocol State Machine. Then on State Machine you depict which UC causes what system State change while UC diagram provides information which Actor is eligible for running specific UC.
Finally you can use Sequence Diagram if you want to model how specific flow of interactions in the system impact changes of the system state. You can present states and actors on a single diagram here, but it is not designed, cannot and should not be used to depict all possibilities on a single diagram.
Disclaimer
Next part of my answer is opinion based
/Disclaimer
Most probably I would use UC diagram and SM diagram together according to information you've provided.
On the notation
A side note to your diagram - ovals are used only on UC diagram and represent Use Cases. They are not associated with each other, only with Actors.
States are presented as rectangles with rounded corners (both in State Machine Diagram and Sequence Diagram).
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.
I am new to the world of UML and have so far learnt the basics of use case, activity and deployment UML diagrams. I have a requirement of where users interact with a system e.g. user sending an email, which is then processed by a system and then sent to an agent (person) who then responds and interacts once again with a system.
I am having a hard time picturing these requirements and whether it should be a combination of use case, activity or deployment. Can I intermingle them? What is standard practice?
As you know, use cases are used to capture requirements. When identifying and detailing use cases, you look at the problem from the perspective of users. Only focus on what an actor expects the system to do. First step is to identify the use cases and actors and then detail the use case flows.
1- Identify the use cases and actors
In your example send email could be a use case initiated by the end user (your actor). What happens next (e.g system sending a notification to the agent) could be modeled as part of the flow of this use case.
Another use case could be the agent actor handling what they have to do after receiving the notification from the system (a prerequisite of this use case could be that a notification has been received).
Note that you could combine these two use cases together and have the agent as a secondary actor (secondary actor interacts with the use case but does not initiate it). Whether you do this or not, is a modeler's choice and depends on the size of use cases, number of use cases and many other things.
2- Detail the use cases
After identifying use cases and actors, you should detail use cases. The most important part is to detail the use case flow (step by step interactions of actor and system). This can be written as text or drawn as an activity diagram.
So to answer your question: yes it is possible and very common to combine activity diagrams and use cases; that is an activity diagram drawn to show the flow of steps of a use case.
Deployment diagrams on the other hand are totally irrelevant to the requirement elicitation phase. They model the physical structure of the system and how hardware components and software components interact.
In fact, it is very odd that you have learned component diagrams before class diagrams, sequence diagrams, state diagrams and many other diagrams.