Search code examples
umlsoftware-designuse-case-diagram

Is it necessary to specialize the actor representing the registered user in customer/seller actor?


I am writing the requirements analysis document for my software engineering project. The project consists in the creation of a sales platform where the user must necessarily be registered and plays both the role of customer and seller. In defining the actors I would like to understand if it makes sense to create an abstract registered user actor as a generalization of customer / seller. Like this:

Example .

Or should I specialize registered user in two different actors Customer and Seller.


Solution

  • Use cases (UC) are in principle related to the goals of the actors, and using generalisation/specialisation can significantly increase the expressivity of your diagram.

    If it's all the same, i.e. sellers and customers participate in the same use cases, have almost identical needs, and will use the system in the same way, keep it as general as possible:

    general UC with general actor. But how to express that users intervene in UC with different roles?

    However, usually on a marketplace system, sellers and customers have different goals despite some commonalities:

    • selling requires to describe items to be sold, and either fix the price or accept a bid;
    • buying requires seeing/searching what is available, etc.
    • both may be interested in viewing their transaction history or presenting themselves on the market.

    Introducing specialisation can then help, even with very general use-cases to remind these differences and better convey the design that is considered:

    enter image description here

    Conclusion:

    • If you feel there's really no difference, keep the actor as general as possible.

    • But especially in the analysis, and user-centric design, it is useful to be aware of different roles and needs .

    • If you introduce a specialisation, use a generalisation set to be more specific. sSow "seller" and "customer" as separate actors both specialising "user". You can then be much more expressive (although this is subjective), and better visualise use cases relevant for:

      • both actors separately (association with the general actor),
      • for one or the other actor (association with only seller or only buyer),
      • or for both actors with different roles (eg. auction needs one seller and several customers).

    Here an hypothetical refinement, where distinguishing seller and customer helped to fine-tune the analysis:

    enter image description here

    CAUTION: If you create the general abstract actor only for a login or logout, stop and take a deep breath. Login / logout and similarly detailed actions are not use-cases, and are better visualised in activity diagrams that detail the flow of actions of a UC.