How can Use Cases be organized using generalization?

A general use case ("Payment") is refined into specific variants ("Cash", "Credit card", "Bill") that share its core flow but each tweak the details — child UC points to parent, same as actors.

Where actor generalization specialises who acts, use-case generalization specialises what is done. The parent captures the common flow; each child is one concrete way of carrying it out:

         Payment (parent)
        /     |     \
     Cash  Credit card  Bill (children)

• Every child inherits the parent's behaviour, then adds or overrides steps (a card payment needs authorization steps that cash doesn't).
• Arrow points from child to parent — identical notation to actor generalization, which is exactly why the two are easy to confuse.

When to use it: when several use cases are variations on one underlying capability. If they instead share a fixed sub-step that always runs, that's <<include>>, not generalization; if a step runs only sometimes, that's <<extend>>. Generalization is for "different flavours of the same goal".