I'm so confused about the difference between extension use case and parent use case in Use case diagram. I would like to know when can I use the extend and when can I use the parent use case?
For example :
What's the difference between inherits and extend ?
Image source : https://t4tutorials.com/use-case-diagrams/
All proportions kept to compare the extend and the include + generalizations is like to compare the aggregations a and b + generalizations in :
In your diagram because of the extend the behavior defined in the UC Print Slip can be inserted into the behavior defined by the UC Confirm Order
The generalizations are like they are elsewhere in UML, pay through paypal is a Payment and pay through credit card is a Payment too. The diagram indicates the UC Confirm Order includes the UC Payment or one of the two inheriting UCs. So the behavior of the UC Confirm Order contains unconditionally the behavior of the UC Payment or the behavior of the UC pay through paypal or the behavior of the UC pay through credit card.
There is an example of inheritance between UCs in the norm, see figure 18.11 page 646 in chapter 18.1.5 of formal/2017-12-05
The two blue bubbles right bottom inherit from Payment through the generalization relation. That's, well, not advisable although looking convenient. Unlike for class inheritence which is clearly defined, a UC inheritence is an open field. The UML spec uses a generalization in just one single diagram and makes absolutely no definition of what a generalization for UCs actually means!
A use case is very much in the world of prose and informal language. It (probably, since there's no definition) means that you take the description of the parent UC and replace parts of it (override) with text defined in the inheriting UC. From a context that sometimes partially works. However, paying via credit card and Paypal is very different (you know) and there's not much in common. So a better way would be to «extend» Payment with the various ways to pay. This way you have a fixed payment procedure which optionally can go the credit card or Paypal way (or even a mix if so designed).
N.B.: The above example is just a bad one. It starts functional decomposition. Use cases shall show a single unique added value a system under consideration shall bring to its actor(s). Print slip is definitely a pure function and no real added value (who needs a paper slip these days?). Selection of product just the same: what's the added value here? Calculate... is telling just that it's a function. Basically you have two use cases: Confirm order and Make payment (note that using verb+substantive is mandatory in describing a use case in the title).
As always I shall recommend Bittner/Spence as excellent read about use cases.
