Use case diagram and actor generalization: different use case diagrams for unlogged user and logged users

Question

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)

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:

18.1.3.1:
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:

18.1.3.1:
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.