Use case generalization versus extension

Question

UML Use Case Diagrams allow for two seemingly equivalent ways to show that a given use case might be realised in several different ways namely use case generalizations as opposed to use case extensions. I have seen the following basically example modelled using either approach with equal frequency, sometimes within a single source.

To my mind an extension is a weaker relationship than generalization as a direct substitution of the specialised use case for the base case must be possible in generalization but not necessarily in extensions.

It seems to me that generalisation implies a polymorphic implementation is desired while extension implies some branching structure is to be used.

void makePayment(const PaymentDetails* pd)
{
   pd->pay();
}

as opposed to

void makePayment(const PaymentDetails* pd)
{
   switch(pd->type)
   {
       case EFT:
                payViaEFT(pd); 
                break;
       case PAYPAL:
                payViaPayPal(pd); 
                break;
       case CREDITCARD:
                payViaCreditCard(pd); 
                break;
   }
}

Isn't the Use Case stage far too early for such implementation specific concerns to be modelled? There are much more appropriate UML diagrams for that. Is there a hard and fast rule regarding which of the two to use and if so what is it?

Answer 1

To my mind an extension is a weaker relationship than generalization as a direct substitution of the specialised use case for the base case must be possible in generalization but not necessarily in extensions.

That is true.

It seems to me that generalisation implies a polymorphic implementation is desired while extension implies some branching structure is to be used.

The diagram does not dictate any implementation. You can interpret a hint from the diagram for yourself, though. UML remains independent of language and solution there.

Isn't the Use Case stage far too early for such implementation specific concerns to be modelled?

Well, as indicated above, UML does not enforce any specific kind of implementation. However, you are gathering some important functional requirements here that might greatly influence your time schedule and workload. ("Pay with credit card" is way more complex to handle than "pay in advance by bank transfer"). So you'd strive to capture that but remain open to different solution approaches.

There are much more appropriate UML diagrams for that.

You can really use them in parallel :) as they are different views on the same subject.

Is there a hard and fast rule regarding which of the two to use and if so what is it?

I prefer the generalization in this case because in fact the extensions falsely suggest there could be a way of paying without using any of the three named options. As you indicated yourself.