I have the following use case about a video rental store which has the following actors:

  • Member (Gold, Ordinal)
  • Assistant
  • Supplier
  • Clerk

The system is a desktop application for renting and reserving videos, and the shop has a range of videos in stock for members

  • gold members can borrow a maximum of 10 videos, while ordinal members 5
  • Assistants add members to the club once they have provided proof of identity
  • a member can come to the shop and ask the assistant in the shop to rent a video
  • the assistant checks for the availability and the limit of the member
  • Gold Members can opt to have an extended hire period
  • The member returns the video when he/she finishes with it (if return time beyond the hire period the member will have to pay a fine)
  • members can also make phone calls to make a reservation, in this case, the assistant will do the same process as for rent a video (check availability, identify and check member limit)

The video shop has gone online and now:

  • members can browse the catalog online
  • the clerk makes the order for a new video and also adds them to the catalog when they are received from the supplier

I have made an illustration of the use-case.

1 - Is it correct that the user has an association with the rent a video and reserve a video use-cases along with the assistant?

2 - where can i add the supplier when the clerk makes an order


updated use-case model:

  • removed make order and receive order
  • added verification use-case that is included in both (rent and reserve)

use case updated

  • I would avoid wide open questions like are there any flaws, people will point out flaws anyways. The more specific your questions are, the better (is there a correct answer?)
    – Martin K
    Commented Feb 5, 2020 at 21:46
  • @MartinK thank you, i have edited my question
    – Ali Kleit
    Commented Feb 5, 2020 at 21:49
  • Are there still video rental stores? Commented Feb 6, 2020 at 20:35

1 Answer 1


1. Multiple associations:

It is normal that the actor Member has association with several use-cases. However each association is usually shown as a straight direct line since associations are binary. The "multiplexing" of a part of the line looks confusing IMHO.

It is also normal that several actors are associated with the same use-case: it means that they are both involved: so for Reserve a video both the Member and the Assistant would be involved. If assistant is not always involved, you should use a multiplicity to make clear that this actor is optional.

2. Indirect actors

The use-case is not a business process model. It shows which actor are involved in the use case. And the use-case is about the system under consideration. If the vendor never uses the system, then the vendor is not an actor.

For clarify purpose you could make a note in your UC diagram to explain in plaintext that the clerk interacts for this use-case upon receipt of vendor delivery.

Of course, if your system is interacting with a vendor system for some kind of e-ordering system, you could show this remote system as an actor. But sill, you would not show the vendor because the vendor does not interact with your system.

3. Additional thoughts:

  • Business use-case

    Ivar Jacobson, the inventor of use cases, suggests in his book "The object advantage" that use-cases can also be used for business modelling. In this case there is a semantic shift: the system under consideration is no longer the IT system, but the company. In such a use case, you could show the vendor as an actor. But this is completely different from what you are trying to achieve.

  • Use-case diagrams are meant to show the big picture: So keep it simple

    Psychological studies have shown that any diagram with more than 6-7 elements are difficult to grasp for most of the people (if I understood well, it's about the limitation of short term memory in our brain, and some people manage to overcome this limitation by mentally grouping items).

    This is why, you can split your UML diagrams in different views, with different focus. Several diagrams can show different parts of the same model.

    But in your case, you could start the simplification, by removing the different check this, verify that, etc... While some could argue that these are sub-goals of the user, I would strongly suspect these to be just a functional decomposition of the use case. Is it necessary to show them here ? are they reused womewhere else ? aren't there other checks performed ?

  • thank you for your explanation, I have updated my model and added an additional case verification and removed supplier's cases as he is not included in the system, regarding the verification use case I have used include can I use inheritance instead or would you recommend something better?
    – Ali Kleit
    Commented Feb 6, 2020 at 10:38
  • 2
    @AliKleit I’d avoid inheritance between use cases. Including verification use case several times is perfectly ok. It means that this UC is always performed as part if the including UCs. I’d not show the more specialised verifications, because it seems to detailed. But if you have to as part of an exercise, it’s ok.
    – Christophe
    Commented Feb 6, 2020 at 10:48

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.