I'm developing a software that manages a shop.

Anyone can visit the shop as unlogged user (aka visitor). If you want to buy something you have to login first (you become a logged user) and then you can buy).

The logger user is child of the unlogged user.

How can I describe this situation in a use-case diagram? Here some ideas:

  1. I remove the logged user and mark Buy item action with a note "only if the user already logged in"
  2. The logged user will be connected to the action Buy item while the unlogger user won't (see diagram below)

enter image description here

  • 1
    How would you do it for different roles, such as manager and employee? Same thing. Visitor and User are different roles. Commented May 25, 2017 at 15:40
  • Ok, but they share part of the diagram. Visitor can 1. see item, 2. see item detail and User can 1., 2., 3. buy item. Do I have to duplicate the cases (I suppose I shouldn't)
    – incud
    Commented May 25, 2017 at 15:44
  • You mean like this? en.wikipedia.org/wiki/Use_case_diagram#/media/… Commented May 25, 2017 at 15:46
  • Not exacly. The User is also a Visitor because he can still visit the shop. The waiter is not a client because he can't eat food
    – incud
    Commented May 25, 2017 at 15:47
  • Both ways are valid, but the 2nd one is more clean. What's the problem?
    – Vlad
    Commented May 25, 2017 at 16:58

1 Answer 1


First thoughts

If you'd use the generalization here, a logged user could do everything that a visitor can do: so a logged user could login (without logging out) and even register again.

So my first advice would be to use alternative 1 or alternative 3: keep the two actors distinct and unrelated, but draw two more links (logged user to see item and see item detail). This would clarify who can do what.

Additional thoughts on the use-case semantics

The UML standard suggests that the use-case diagram should be independent of the inner state of the system:
UseCases define the offered Behaviors of the subject without reference to its internal structure.

But the difference between a visitor and a logged user seems to be completely dependent to the system state. So you're not really showing distinct user roles but more different user states. Of course, you could disagree with this viewpoint, because the semantic of a role is not formally defined in the UML standard:
NOTE. The term “role” is used informally here and does not imply any technical definition of that term found elsewhere in this specification.

Nevertheless, I'd suggest to consider a more user centric approach in the definition of the actors. You could for example distinguish:

  • visitor who could see items whether he's logged or not
  • unregistered user who's a visitor and can in addition register
  • registered user who's a visitor and can login, and buy

Focusing on the user instead of the inner state of the system has the advantage of highlighting a requirement of every successful web-shop: what if a visitor browses the items, find an item he wants to buy but forgot to log in ? These kind of issues remain completely unspotted if the actors are to be understood as state dependent. Yet these are among the main reasons why customers don't finish online transactions.

Suggested reading: How to Avoid Use-Case Pitfalls it's a little bit old and uses some earlier diagramming version of UML, but most of the advices are still relevant.


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.