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

Пример 1 (Actor 1)
Самый простой пример - ВИ "Получить справочную информацию" - расширяющий и конкретный.
Если вызывать из другого ВИ то это контекстная справка по конкретной функции (открывается нужная страница справки).
Если вызывать самостоятельно, то это просмотр полной справки

Пример 2 (Actor 2)
Общее поведение, которое используется опционально в нескольких вариантах использования, но самостоятельно не вызывается пользователем.
Вернуть книгу и Зарегистрировать новую книгу могут быть расширены общим поведением - Проверить очередь желающих почитать данную книжку.

Пример 3 (Actor 3)
Выносим альтернативный поток событий отдельно с одной лишь целью - не усложнять описание базового варианта использования. В том случае когда альтернатива громоздка и может содержать в себе много проверок, альтернатив и взаимодействие с новыми акторами.
Например дополнительная проверка требующая обращения во внешнюю систему с описанием обработки ошибок разрыва связи и таймингов, причем проверка опциональная при определенном условии или желании пользователя. Абстрактным будет потому, что сам по себе такой поток событий не представляет интереса и вызывается только из базового варианта использования.

Абстрактный вариант использования - читай ВИ который невозможно инициировать самостоятельно, которые не сможет выполниться сам по себе без помощи других вариантов использования.

Мне кажется, в данном случае понятие абстрактный используется несовсем корректно. Что значит иницироваться самостоятельно? Любой ВИ кто-то инициирует. Его инициирует непосредственно действующее лицо, либо он инициируется из другого ВИ (вероятно самой системой) для обеспечения интересов какой-то из сторон.

Как в статье: назначить штраф не иницируется самим билиотекарем, а иницируется событием или условием - текущая дата больше, чем дата предельного срока сдачи книг.

Причем же тут абстрактность? Абстракность - это когда конкретное поведение ВИ не может быть инстацировано

Все верно Эд, только ВИ со штрафом должен быть абстрактным, так как сам по себе инстансом не может быть.

Абстрактность имеет смысл использовать только для показа некоторого обобщения, которое специализируется уже конкретными ВИ (может быть на других диаграммах).

Абстрактный вариант использования - читай ВИ который невозможно инициировать самостоятельно, которые не сможет выполниться сам по себе без помощи других вариантов использования.

Это откуда такое определение?
Абстрактный - эначит нет прямых экземпляров. Больше ничего. Возможность или невозможность иниициировать тут не при чем.

Абстрактный - эначит нет прямых экземпляров. Больше ничего.

Правильно. Нет экземпляров, т.е. не может существовать самостоятельно, только в виде наследников или в виде "куска" другого ВИ. Абстрактный можно инициировать, но инстанс будет не сам ВИ, а совокупность неабстрактных шагов данного ВИ и подмены его абстрактных шагов конкретными из наследника. Другими словами когда инициируешь вариант использования уже работаешь с объектами и их взаимодействиями, а не с вариантами использования. Все абстрактное перерождается в конкретное, подменой или соединением шагов.

А фраза - это моя интерпретация мыслей откуда-то из произведений Айвара Джакобсона и Ko

... т.е. не может существовать самостоятельно, только в виде наследников или в виде "куска" другого ВИ. Абстрактный можно инициировать, но инстанс будет не сам ВИ, а совокупность неабстрактных шагов данного ВИ и подмены его абстрактных шагов конкретными из наследника. Другими словами когда инициируешь вариант использования уже работаешь с объектами и их взаимодействиями, а не с вариантами использования. Все абстрактное перерождается в конкретное, подменой или соединением шагов.

Мне кажется очень много философии:)

Лично я, Виталий, твои объяснения принять не могу.
Под абстрактным ВИ ничего нет. Ни самого маленького "кусочка" реализации (сценария). Абстракции служат, чтобы уменьшить сложность. Абстрактный ВИ - хороший тому пример (как и абстрактное ДЛ, кстати).

Мне кажется очень много философии:)

Лично я, Виталий, твои объяснения принять не могу.
Под абстрактным ВИ ничего нет. Ни самого маленького "кусочка" реализации (сценария). Абстракции служат, чтобы уменьшить сложность. Абстрактный ВИ - хороший тому пример (как и абстрактное ДЛ, кстати).

Денис, наверное я не умею доходчиво объяснять . Только не я являюсь источником этих идей. Я лишь выступаю в роли пророка и пытаюсь донести (может и криво) идеи Овергаарда, Джакобсона и Арлоу, которые об этом пишут в своих книгах. И в книге, которую последнее время часто упоминают на форуме, все это четко прописано, если немного детальнее ее поизучать. С одиниковостью абстракций вариантов использования и действующий лиц я не соглашусь, так как это по природе своей разные вещи - один сущность, второй поведение. Возможно я не знаю многих деталей UML, но последнее время я смотрю все больше в сторону текстового описания и использую модель лишь для собственного понимания системы и ее границ. UML это помощник нам в нашей работе, если он начинает усложнять мне жизнь, то я просто от него отказываюсь, придерживаясь принципа KISS

Как ты ранее писал:

Абстрактный - эначит нет прямых экземпляров. Больше ничего. Возможность или невозможность иниициировать тут не при чем.

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

Арлоу. UML2 и унифицированный процесс
...Если в родительском прецеденте нет потока событий или поток событий не завершен, это абстрактный прецедент

Поскольку в абстрактных прецедентах поток событий отсутствует или является не полным, они не могут быть выполнены системой

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

Расширяющие прецеденты обычно не являются полными прецедентами, поэтому, как правило, их экземпляр не может быть создан

Автор четко говорит о том, что неполные варианты использования не имею экземпляров, а следовательно являются абстрактными. Если описанное выше противоречит UML значит авторы его не знают. И им прежде чем писать книги, стоило бы наверное самим подучиться.
Если в дополнение к этому сослаться на Овергаарда, то мы увидим абсолютно схожую картину.

Может быть в нашу Дискуссию включить и Арлой с Овергаардом?
Можно им написать и спросить что же они имели в виду под абстрактными ВИ, но с ними должен спорить Денис, как человек знающий досконально спецификацию

Ай яй яй Виталий. Как не хорошо так порочно цитировать Арлоу, и сваливать на него вопросы абстракции ВИ.

1. Не надо приводить цитаты вне контекста их использования! А контекст там - использование обобщения.

2. На мой взгляд ты сделал неверный логический вывод, сопоставив похожие рассуждения о неполноте базового ВИ (в случае наличия включения). Неполный - незавершенный <> абстрактный.

Назначить штраф вполне можно осуществить и после, между прочим:)

Ай яй яй Виталий. Как не хорошо так порочно цитировать Арлоу, и сваливать на него вопросы абстракции ВИ.

Процитировал я слово в слово. Контекст там очевиден. Останусь при своей точке зрения.

ЗЫ ИМХО Варианты использования в UML недостаточно полно покрыты, поэтому Арлоу все время приходится оговариваться, что в UML этого нет. На практике люди ищут пути решения проблем расширяя и дополняя имеющиеся нотации. Если бы например использовал только UML при описании ВИ - они получились бы далеки от совершенства. Не удивлюсь если через пару лет в каком-нибудь uml3 будет существенное расширения вариантов использования (Джекобсон вводит четкое описание классификтора ВИ), ибо там только человечки, овальчики и никому не понятные extend и include .
ЗЫЗЫ Я не против UML я за рациональное его использование - решение проблем в разработке ПО . Оттачивать знания можно бесконечно как и спецификацию требований...

Abstract and Concrete Use Cases
A 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.
When two or more use cases have a sequence of the same steps, these steps are extracted and put into a common use case. This common, or abstract, use case is then available to be included in any other use case within the system. Abstract use cases eliminate redundancy and promote reuse, a goal of object-oriented systems design.

Because an abstract use case contains only a subset of the steps in a flow of events, it may not make sense as a standalone use case. An abstract use case is included as part of one or more concrete use cases in order to represent a complete flow of events.

Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development, Third Edition by Craig Larman
30.2. Terminology: Concrete, Abstract, Base, and Addition Use Cases
A concrete use case is initiated by an actor and performs the entire behavior desired by the actor [RUP]. These are the elementary business process use cases. For example, Process Sale is a concrete use case. By contrast, an abstract use case is never instantiated by itself; it is a subfunction use case that is part of another use case. Handle Credit Payment is abstract; it doesn't stand on its own, but is always part of another story, such as Process Sale.

A use case that includes another use case, or that is extended or specialized by another use case is called a base use case. Process Sale is a base use case with respect to the included Handle Credit Payment subfunction use case. On the other hand, the use case that is an inclusion, extension, or specialization is called an addition use case. Handle Credit Payment is the addition use case in the include relationship to Process Sale. Addition use cases are usually abstract. Base use cases are usually concrete.

Приходится признать такое понимание абстрактного варианта использования. Поскольку сам создатель нам об этом говорит.

An abstract use case is a use case which is not to be instantiated. Typically, the use case does not provide a complete declaration of a usage. The intention is that the use case is to be used in e.g. generalizations, include relationships or extend relationships.

Abstract use cases are used for declaring commonalities at one place which later can be reused when defining new use cases that share these commonalities, to declare parts of usages (subflows) that are added in a later version of the model, or to model subflows explicitly.

An abstract use case is denoted with an ellipse like an ordinary use case, but with the name italicized. I have a typical example. It is the usual ATM example where the Card Identification use case is abstract and included in the Withdrawal and the Transfer Funds use cases. None will just perform Card Identification. It is not a concrete use case. However, the behavior declared in the Card Identification use case is important in the system, and it is included in multiple use case.

Возможно, что это первая причина когда следует использовать расширения и включения.

Правда я все равно недопонимаю, почему расширяющуие и включаемые ВИ обычно абстрактны. Неполната или зависимость от другого поведения не делает их абстрактными автоматически.

Вот ситуация. Предположим что создать клиента (информацию) можно только в ходе создания заказа.
Иначе создать клиента нельзя. Править данные по клиенты тоже можно только из заказа.
Почему так сложилось не суть.

Исходя из правил того же Ивара, получается, что ВИ Создать клиента абстрактен, поскольку к нему нет прямого доступа. В чем тут абстрактность?

Абстрактность основного действующего лица? В том смысле что это может быть менеджер заказов, менеджер доставки или кто-то еще кто может в заказе создавать править данные по клиенту?

Лично мне понятна такая абстракция, когда есть некое скелетное описание действий, но конкретное их наполнение наполняется адаптивно в контексте базового ВИ. Хотя и эту ситуацию представить сложно

Да... Приходится признать.

"Крамольное предположение": если исходить из тезиса Якобсона о том, что "Abstract use cases are used for declaring commonalities at one place which later can be reused when defining new use cases that share these commonalities, to declare parts of usages (subflows) that are added in a later version of the model, or to model subflows explicitly." то может быть полезно было бы использовать нотацию aggregation(composition) для описания отношений между ВИ (хотя это и не соответствует спецификации)?

Агрегация и композиция не подходят. ВИ не состоит из частей. ВИ - это есть целое + кусочек из другого ВИ (в случае зависимостей).