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, whileordinal members
5Assistants
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 themember
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, theassistant
will do the same process as forrent 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 thesupplier
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)
Best Answer
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 theMember
and theAssistant
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 ?