While developing use cases, the designer often faces a confusing situation to name the use case, while this is associated by multiple actors. For instance, a salesman sells a concert ticket to the customer. In this case there are two actors salesman, customer and one use case. What will be the use case name??? “Sell a ticket” ? or “Buy a ticket”? Since both actors are associated, how we can recognize specifically which actor is buying or selling the ticket? Well from my point of view there are couple of solutions, based on the situation:
1. Initiator: the use case name should be given according to the initiator actor. For instance, in the ticket sells use case, if the sells man is the initiator, then the use case name should be “Sell a ticket”.
However there may be another new use case that can be associate with <<include>>/<<exclude>> relationship with this use case. In this case to show the association of the corresponding actor with the new use case, we need to explicitly mention this association. For example if there is a new use case is included “attend the concert” with the “Sell a ticket” use case, we don’t EXACTLY know who is attending the concert. Well putting a simple association with “Customer” actor and “attend the concert” use case says the customer will going to attend the concert.
2. Split the use case: if we want to show the responsibilities among the actors specifically, in that case we have to divide the functionality into two use cases. In our example: we can split the “ticket sells” functionality into two use cases: one is “sell a ticket”, which is associated with the “Salesman” actor and the other one is “buy a ticket” which is associated with the “Customer” actor. However to express the total functionality we have to associate these two use cases.
Any following use case from any of two use cases can automatically reflect the association of the corresponding actor of the first use case, with the current following use case. For example: If the “buy a ticket” use case follows or includes a new use case “attend the concert”, it automatically says or associates the “customer” actor, as it is associated with “buy a ticket”. However we can still associate “customer” with the “attend the concert” use case if we wish, which is semantically correct.
Notes:
Initiator: In a use case diagram, there are the common situations, where actor begins a use case and then the use case interacts with other use cases. However in this case we need to specify the initialization process. This can be done in two ways, either by using the <<initiates>> stereotype in the corresponding association line, or we can use a arrow head line, rather using simple association notation among the actor and the use case.
Use case generalization: As it is possible to generalize a use case with another use case, we should consider all the actors and use case related to the inheriting use case will be implemented to the inherited use case.