extends in Use Cases diagram

in the book UML @ Classroom An Introduction to Object-Oriented Modeling is written "Use cases—even included or extending use cases—can always be executed independently. If they can only be executed within the scope of another use case and not independently, they are not use cases and must
not be depicted as such. Their functionality must then be covered in the
description of the use case that uses them.", however all examples of extends relationships my Professor gave to me and I found in internet the extending use cases can only be triggered within the scope of the base use case.
I'm lost, which one is correct ?

I have a mini-project, I ignored the extending use cases that can't be triggered by any actor, should I draw these extending use cases ?

The specification says:

> the extending UseCase typically defines behavior that may not
> necessarily be meaningful by itself.

and

> The extension takes place at one or more specific extension points
> defined in the extended UseCase.

So, uml@classroom is wrong and your professor is right. Extending use cases are not meaningful by itself and cannot exist without an extension point in the extended case.

However, there are good reasons for avoiding the extend relationship.

First of all, the specification contradicts its own definition:

> A UseCase specifies a set of actions performed by its subjects, which
> yields an observable result that is of value for one or more Actors or
> other stakeholders of each subject.

How can a behavior that "may not necessarily be meaningful" be "of value"?

So, maybe the UML should have introduced «secondary» "use cases" for this purpose. Actually, this is how it is done in my company. That is, if the client insists on using «extend» or «include».

In my opinion secondary "use cases" are only needed, if they are your only means to describe common or extending behavior. However, usually you will use other elements to describe the use case, such as activity diagrams or interaction overview diagrams. They can easily and accurately describe such behavior. Extending use cases will simply duplicate the effort without any benefit.

So, even when uml@classroom is formally incorrect, the advice is sound! A use case that is worth the effort is independent!

PS: Much confusion stems from the sloppy use of language: A use case is not executed. A use case happens, when I use a system by invoking some its functions, which will then get executed. The specification never uses this wording. Rather it talks about initiating a use case.

The independence is a practical way to avoid functional decomposition. Considering that functional decomposition is not a bad use-case practice (even if UML specs explicitly allow it), it is a good idea to look for independent use-cases.

Extensions should also follow this rule, but not for the reason you think. By definition, the extension is an additional behavior that makes sense only in the context of the extended use-case:

> UML 2.5.1 - Section 18.1.3.2: An Extend is a relationship from an extending UseCase (the extension) to an extended UseCase (the extendedCase) that specifies how and when the behavior defined in the extending UseCase can be inserted into the behavior defined in the extended UseCase. The extension takes place at one or more specific extension points defined in the extended UseCase.
Extend is intended to be used when there is some additional behavior that should be added, possibly conditionally, to the behavior defined in one or more UseCases.

It is therefore very difficult to have an independent extensiin. Nevertheless, still you shoukd apply the rule of your book: avoid dependent use-cases. Therefore avoid extensions at all. And this is good, because most often extznsions present something very detailed that could as well be explained in the narrative of the extended use-case