Return to Answer

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

• unregistered visitor, who could only see items and register
• registered users, who could login, see items (whether logged in or not), and buy (only if logged).

Or you could consider:

• visitor who could see items
• 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 rather on the inner state 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.

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.

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

In your specific case, I'd suggest not to use the generalization: it would mean that a logged user could login (without logging out) and even more confusing, that a logged user could register again.

I'd keep the two actors, but draw two more links (logged user to see item and item detail) instead of the generalization: this would be crystal clear.

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

• unregistered visitor, who could only see items and register
• registered users, who could login, see items (whether logged in or not), and buy (only if logged).

Or you could consider:

• visitor who could see items
• 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 rather on the inner state 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.

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.

In your specific case, I'd suggest not to use the generalization: it would mean that a logged user could login (without logging out) and even more confusing, that a logged user could register again.

I'd keep the two actors, but draw two more links (logged user to see item and item detail) instead of the generalization: this would be cristal clear.

In your specific case, I'd suggest not to use the generalization: it would mean that a logged user could login (without logging out) and even more confusing, that a logged user could register again.

I'd keep the two actors, but draw two more links (logged user to see item and item detail) instead of the generalization: this would be crystal clear.