Actually, an extension point should never be named after an action that is assumed to be performed at the extension point (i.e., by an extension use case), because as part 1 of this article explained, the base use case doesn’t know whether it’s being extended at a given extension point, let alone by which extension use case!
Extension use cases without and with actor involvement
In Jacobson’s example cited in part 1 of this article, the base use case’s initiating actor is unaware of the extension use case, because the extension use case doesn’t require the actor’s involvement. However, there are also extension use cases that do involve the actor. This is fine, as long as the goal of the extension use case is perpendicular to that of the base use case, and the extension use case doesn’t require any of the base use case’s private data. This is illustrated in the following diagram.
After the “Log In” base use case reaches the “User has been authenticated” extension point, the “Advertise Product” extension use case is given control. The extension use case determines whether, during one of its previous executions, the user chose or declined to be informed about the product. If not, the user chooses one of the following options, which causes the extension use case to take the corresponding action.
The extension use case then ends and control returns to the base use case.
This behavior can be modeled as an extension use case because its goal in no way contributes to the base use case’s goal, it requires none of the base use case’s private (local) data (e.g., User Password, Security Questions and Answers) and the data it does require has been defined as public (global) data (i.e., User Id).
This extension use case controls an interaction between the system and the base use case’s initiating actor in pursuit of the “Advertise Product” goal of the off-stage stakeholder that is perpendicular to the “Log In” goal of the on-stage stakeholder.
Extension use cases vis-à-vis event-driven architecture (EDA)
Part 1 of this article noted that an extension use case intersects with a base use case at a single condition or event in the base use case. While this is an event-based relationship, an extend relationship is not suited to represent an event-driven relationship as understood in event-driven architecture because it fails to meet at least the following EDA principles described in .
Reports current events: A publisher use case is modeled to produce an event object that represents an event as it happens or a condition as it is detected. Mediated by an event manager, the event object triggers one or more subscriber use cases that are modeled to consume the event object.
A base use case doesn’t produce an event object, so it’s not a publisher.
An extension use case is neither triggered by nor consumes an event object, so it’s not a subscriber.
Late or no binding: An event publisher and event subscriber are not aware of each other’s identities when they are developed or deployed.
While a base use case is unaware of an extension use case, an extension use case is aware of the base use case and its extension point from the moment the extension use case is modeled because it owns the relationship with the base use case.
Moreover, the relationship between a publisher and a subscriber use case is asynchronous (the latter doesn’t execute as part of the former), whereas the relationship between an extension use case and a base use case is synchronous (the former executes as part of the latter).
My first article  outlines an approach for modeling publisher and subscriber use cases that requires neither extension use cases nor inclusion use cases.
Summary of this article's considerations
The table below summarizes the considerations identified thus far. The concluding article  adds one more consideration, based on the article  that precedes it.
(*) If/when there is a convention for declaring certain of a base use case’s private data as publicly accessible at an extension point, model the behavior as an extension use case.
(**) This implies that the behavior’s goal contributes in some way to the base use case’s goal in the eyes of the use case’s initiating actor.
The term “base use case” only applies in the context of a use case relationship (e.g., in the context of an extend relationship, it refers to the extended use case). For ease of reference, I have used the term here also to refer to a ‘candidate’ base use case, even when, after further consideration, it doesn’t end up being an extended use case.
Don't forget to leave your comments below.
 Ivar Jacobson, Use Cases: Yesterday, Today, and Tomorrow, 20 November 2003, found at http://www.ibm.com/developerworks/rational/library/775.html (page no longer exists; see: http://www.spinsp.org.br/grupo/Future_%20of_Cases.pdf).
 Willem Van Galen, Modeling Loosely Coupled Use Cases, 30 April 2012, http://www.batimes.com/articles/modeling-loosely-coupled-use-cases.html.
 Willem Van Galen, Use Case Goals, Scenarios and Flows, 13 November 2012, http://www.batimes.com/articles/use-case-goals-scenarios-and-flows.html.
 Willem Van Galen, Excavating the extension use case, Part 3, 12 March 2013, http://www.batimes.com/articles/excavating-the-extension-use-case-part-3-nuance.html