How to portray visibility in Use Case Diagram

Question

Context

Imagine an Event Management website where event planners can post events. Say we have three Actors: a non-registered user, registered user and an Event Planner. Event planner can post events which can be public (non-registered users can see them) or private (only registered user can see them).

Question

How can I portray the fact that all users can see public events and only registered users can see private events?

Additional question: Should I separate "See upcoming events" and "See past events" into two different Use Cases or should I have one "See events" use case?

Some ideas I got

The following diagrams are some potential solutions that I thought of but I am not sure how correct they are.

Having separate Use Cases

Using extend

Having "See events" as an umbrella use case

Answer 1

Either you go with Geert's suggestion and use just a See events use case or you should stay with your first one. Whether you split the See events into private/public heavily depends on the system you are designing. So, taken that there is a need for a split (since both events will be looked at very differently) you should go with your first sketch. Here it's clear who can deal with which UC. With just a single UC you could attach a constraint like {only registered user can see private events}.

Your 2nd one does not seem to make sense. The «extend» is superfluous as the actor already has direct relation to the use case. The relation would mean that the extending use case is optinally performed in the course of events. So somewhere while seeing private events there's a path to also seeing public events.

The last suggestion is just functional decomposition. A use case that has no connection to an actor is no use case since it does not bring added value. You could use generalized use cases (private/public are specializations of See event) but I always recommend to not use that construct. Generalization of UCs is somewhat of an oxymoron. A UC shall show a unique added value brought to an actor of the system under consideration. But if you can generalize then it's not really unique. And unlike class generalization where attribute/operation overrides are clearly defined the UCs lack such a description and it's lot of interpretation which needs to be done.