Specification of extending use case - uml

Question

I'm trying to figure out how to specify an extending use case.
For example, suppose I have a use case Pay described in the normal flow by the point:
1. User select the product
2. User make the payment
3. System validates the payment
This flow is included in a specification table (that include actors, pre-condition, post-condition etc..)
Now I want to refer this user case in the specification of an extending use case like PayWithCreditCard without repeating all equal step; How can I do this?
In this case the only step I need to extend is step 2. and it is extended in someway like:
2.1 User choose payament with credit card
2.2 User insert credit card
2.3 User insert Pin
But how can I put this in a specification without to repeat step 1 and step 3?
Or there is another way to handle with this?

Answer 1

If use-case PayWithCreditCard extends use-case Pay, then Pay should identify explicitly extension-points where the extension will insert its behavior.
This is also (or especially ?) true for the tabular specification of a use-case: the specification shall list potential extension points and identify these in the flow of events. For example Spence & Bittner suggest to use curly brackets to identify the extension points (see their book Use-Case modelling, chapter 7).
In your case, this would look like this:
Use-Case: Pay
Actors: Buyer
Extension-points: Provide payment details
Validate payment
Basic flow:
1. Buyer selects the product
2. Buyer makes payment
2.1. Buyer selects the payment method
2.2. { Provide payment details }
3. System validates payment
3.1. { Validate payment }
3.2. Inform buyer that the payment was accepted
Pre-conditions: ...
The extension points would be defined in the extension. Dependeing on the selected payment method, the { validate payment } extension point could for example trigger an immediate credit card transaction with the bank, or wait for a delayed manual confirmation by an accountant that the incoming wire transfer was received.
For identifying the alternate flows, you could then use:
At { Validate payment }, if rejection or time-out: ....
It is important to be aware that an extension use-case, may need to know about the extension points of the use-case that it extends. This is different from an include relation, where the included UC is understood to be independent of the use-case that includes it.

Answer 2

Basically a use case shall only show added value a system under consideration delivers to one of its actors. Often people tend to start functional decomposition by misusing extends/includes. However, sometimes it's kind of useful to show variations like here when adding different payment methods that extend the payment procedure.
First of all "Pay" is no use case (it's verb only). Even "Pay product" is not a use case. I doubt the actor will see that as added value - it's more the opposite. The use case (I'd guess) is rather "Purchase product" which is a big difference. The actor wants to have the product and it's obvious that something in exchange is needed to get the product (in almost all cases that would simply be money). Now that you have this use case you want to show options (!) which you put into bubbles. These are basically no use cases per se. They just extend an existing use case. "Pay per credit card" and "Pay cash" are such extensions. (Unfortunately UML does not make a difference in the graphics for real and such pseudo use cases.)
Now, in your textual description you would have a decision at the point where you make the payment and where you would branch accordingly. Eg.
Select payment method
2.1 If credit card: Perform use case "Pay with credit card"
2.2 Else if cash: Perfom use case "Pay with cash"
Handling exceptions proves to be tricky here (in graphical as well as textual notation). So you might need to continue
If payment refused resume at ...
or the like.
A UC diagram would look like