Здесь и здесь началась и может быть ЗДЕСЬ будет продолжена дискуссия про абстрактные ВИ.

Нужно признать, что мои представления об абстрактности несколько иные, чем у изобретателей UML и, в частности, use cases.
Действительно, кто же как не Ивар должен значть все об абстракции ВИ. Он же их придумал, он же их развивал.

Правда есть другой центр влияния. Он известен нам под именем Алистера Коберна. В русском издании на слово абстрактный нет ни одного совпадения. В английском издании мне встретилось только четыре совпадения, ничего собственно не проясняющие по данному поводу. Правда в русском переводе часто встречается термин обобщение. Что соответствует термину summary level, но никак не abstract.

Насчет понятия абстракция почитайте здесь. И начнем дискуссию

Я пока начинаю собирать коллекцию определений:
1. Essential (Abstract) Use Cases
An essential use case (Constantine and Lockwood 1999), sometimes called a business use case, is a simplified, abstract, generalized use case that captures the intentions of a user in a technology and implementation independent manner. A fully documented essential use case is a structured narrative, expressed in the language of the application domain and of users, comprising a simplified, abstract, technology-free and implementation-independent description of one task or interaction. An essential use case is complete, meaningful, and well designed from the point-of-view of users in some role or roles in relation to a system and that embodies the purpose or intentions underlying the interaction.

2. Abstract and Concrete Use Cases
 concrete use case is a particular type of use case that is directly invoked by an actor and achieves a specific goal. It is self-contained and illustrates a complete flow of events. A concrete use case is a specific instance of using a common set of steps referred to as an abstract use case.
An abstract use case is a particular type of use case that is not directly invoked by an actor but is called by another use case.

3. Concrete and Abstract Use Cases
There is a distinction between concrete and abstract use cases. A concrete use case is initiated by an actor and constitutes a complete flow of events. "Complete" means that an instance of the use case performs the entire operation called for by the actor.
An abstract use case is never instantiated in itself. Abstract use cases are included in, extend into, or generalize other use cases. When a concrete use case is initiated, an instance of the use case is created. This instance also exhibits the behavior specified by its associated abstract use cases. Thus, no separate instances are created from abstract use cases.
The distinction between the two is important, because it is concrete use cases the actors will "see" and initiate in the system.
You indicate that a use case is abstract by writing its name in italics.

Впрочем это Виталий приводил. Собственно больше не нашел.

По-моему все дело в несколько различной трактовке  понятия абстракция для классов, например, и для вариантов использования. Мы привыкли мыслить что абстрактный класс не может иметь экземпляров и используется для того, чтобы наследовать поведение от родителя к потомку (конкретных примеров использования такого механизма очень много).

В вариантах использования же мы описываем поведение системы и здесь понятие абстракции немного отличается от его собрата в классах. Помимо всем известного механизма наследования, понятие "не имеет экземпляра" в вариантах использования как раз и означает, что сам по себе вариант использвоания не иниициируется на прямую действующим лицом. Это скорее всего вытекает из сути самого варианта использования как набора потоков событий (аля "классы"). Экземпляры данных "классов" являются сценариями. Так вот если абстрагироваться и представить, что сценарий не может быть создан из потоков данного варианта использования (без привлечения сторонних ВИ), т.е. "класс" не может иметь экземпляров сам по себе, то такой вариант использования по определению является абстрактным.
Чистый объектно-ориентированный подход.

У Коберна (опять же имхо так как с самим Коберном еще не общались под абстрактным понимается именно esential т.е. такой, в котором описано лишь верхнеуровневое поведение системы, а детали могут быть вынесены в нижний уровень абстракции (аля наследники). Также стоит заметить, что Коберн почти не использует UML и говорит о ВИ как о текстовом описании.
Джекобсон же напротив отталкивается от модели и четкой организации потоков событий, так как использует все это "хозяйство" для проектирования и построения архитектуры, что хорошо прослеживается в его книге Aspect-Oriented Software Development with Use Cases

И все-таки он Якобсон, а не Джекобсон ... и Ивар, а не Айвар :-) ... это все американцы на свой манер хотят скандинавов называть :-). Так же как и Крухтен, а не Кратчен :-) ....

И все-таки он Якобсон, а не Джекобсон ... и Ивар, а не Айвар :-) ... это все американцы на свой манер хотят скандинавов называть :-). Так же как и Крухтен, а не Кратчен :-) ....

Спасибо за исправления . Будем знать

Пока не в качестве ответа, а лишь в качестве некой информации, найденной на просторах рунета.

А.Прозоров. Лекция 3. Моделирование прецедентов

В качестве средства борьбы со сложностью применяют декомпозицию прецедентов, а в качестве средства документирования используют допустимые в нотации UML графические средства, которые называются отношениями между прецедентами. В качестве критерия декомпозиции прицедентов используется критерий обобщения/специализации.

Отношения между прецедентами в UML подразделяются на отношения включения (include) и отношения расширения (extend). Для построения отношения включения используется декомпозиционный критерий обобщения, а для построения отношения расширения, соответственно, критерий специализации.

Кроме задач декомпозиции, выявление и документирование отношений между прецедентами позволяет добиться повторного использования прецедентов с помощью абстрактных прецедентов. Абстрактные прецеденты — это прецеденты, содержащие общие черты поведения проектируемой системы, т.е. они отражают функциональность, общую для нескольких различных прецедентов.

Критериями декомпозиции прецедентов являются:
Критерий обобщения, используемый для моделирования отношений включения. Данный критерий применяется для выноса в самостоятельные прецеденты альтернативных, необязательных и исключающих последовательностей взаимодействий между системой и актерами.
Критерий специализации, используемый для моделирования отношений расширения. Данный критерий применяется для выноса в самостоятельные прецеденты общих последовательностей взаимодействий, характерных для различных прецедентов. Самостоятельные прецеденты, полученные с помощью критерия специализации, при условии отсутствия в них актеров, называются абстрактными прецедентами.

Продолжение тут: https://www.uml-diagrams.org/use-case.html#abstract-use-case
Тема, видимо, неисчерпаемая.