Suppose a customer needs to approach a staff member to register her. To model this, I have drawn the image below. However, I am not sure if what I have drawn, actually means both of them can register customer, not that a customer must first approach the staff. Could you let me know? Thanks

PS. The customer will provide personal information to the staff member. This is important as in the sequence diagram, messages are exchanged between the two.

enter image description here

5 Answers 5


The UML specifications explain that the exact meaning of several actors associated with the same use case is unspecified:

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 (...).
- UML 2.5.1 page 640

To the typical examples of the specs, I'd add to the situation where one actor or the other gets involved, which is imho by far more frequent.

Such a use case is ambiguous useless without at least a short description of the behavior at stake allowing to infer the nature of the involvement of the different actors.


If you handed me that use case diagram, I would interpret it as both the Staff and the Customer would be able to interact with the software to carry out the actions associated with "Register". It is ambiguous as to if either actor can initiate the action or if both are required to interact with the system to carry it out.

The first step is to figure out the boundaries of the system that you are modeling. Modeling the software elements of a system will yield different results than modeling the whole system.

If you are modeling the software system, then the customer would not be on the model (based on your description of the system) since they do not interact with the software, while the staff does.

If you are modeling a broader system, then you need to ask further questions. Perhaps the staff is part of the system being modeled, so the customer would have a relationship with the "Register" use case. Perhaps the customer will interact with the staff and not directly with the "Register" use case.


UML use case diagrams have a very restricted semantics "by design". They can only express that "Staff" and "Customer" are both involved in the registering process, but do not show any further details.

Hence, to make these diagrams useful, one has to provide a description for each use case (for example, in text form, or by making use of other kind of UML diagrams like activity or sequence diagrams). For example, a textual description could contain the information

  • who initiates the "Registering" use case

  • who calls whom by which communication channels (email, phone, chat, web form, ...)

  • which kind of personal information needs to be provided by the customer

  • if the registering process requires something like an acknowledgement email from the customer to get their confirmation for storing and processing their data

  • what happens if the registring process could not be completed within a certain time frame

and so on.


Disclaimer: I have read multiple times through the UML specification in search of this specific semantics and while it technically can be derived by combining at least 3 if not more sections it is super unclear in the specification itself. Yet, the notation I provide below is expected to be understood in a way I describe it as a part of the official UML certification path by OMG so I would treat that as a confirmation that such understanding is the intention of UML specification creators.

The association between a Use Case and an Actor indicates only, that the Actor is somehow involved in the Use Case. It does not clarify, who is initiator. So based on your diagram both Actors: Staff and Customer have to be involved in the realisation of the Use Case Registration. It is not clear, which one initiates it and which is involved in other way.

Here starts the part that I base on exams rather than specification (i.e. you can interpret specification this way but I would never guess it if I weren't told so while preparing for the exam, this notation is also indicated during the exam itself).

You can specify who initiates Use case by using the navigability of the association between the Use Case and Actor. If the Actor initiates the Use Case, you can indicate it by making the association navigable for the Actor (i.e. draw the association as an arrow with an open head on the side of the Use Case). If on the other hand the Actor is involved in the Use Case but doesn't initiate it, the association needs to be navigable for the Use Case, so the arrow should be in the opposite direction, with open head on the side of an Actor.

I want to be very clear - this semantics is not explained directly, you need to read between lines of few section so I can't imagine anyone reading UML specification only would guess that. Yet, you can see this notation used in the exam as if it is clearly understandable from the specification.

You can also check my comment to this answer


Given that the box presumably depicts "the system" and given the fact the "Customer" does not actually interact with "the system" as described, the "Customer" is not relevant to the interactions with "the system" and should not be part of the use case.

With that said, it seems that "workflow" is an essential part of the overall function of "the system" in which the use case diagram would not be the mechanism for specifying, but rather an Activity Diagram, for example.

Aside from that, I'd also suggest that the "Staff" is operating as a Trained Customer Proxy to the "Customer" with additional training of how to interact with "the system" on behalf of the customer. In this case, "Trained Customer Proxy" should be considered a subclass of "Staff" and represented as the only actor is this case.

One final alternative, consider the possibility that the "Staff" is actually a component of "the system" and therefore reduces the use case to a "Customer" interacting with "the system".

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.