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