Логично, и как это будет потом синхронизироваться с окончательными вариантами вариантов использования?

Ты имеешь в виду описанные сценарии?

Во-первых, я считаю, что диаграммы ВИ и сценарии ВИ прекрасно могут существовать друг без друга. Если я не использую сценарии ВИ для описания требований, я ведь могу использовать ДВИ для их выявления? (Могу, конечно, я так и делаю.) И, на самом деле, use cases на диаграмме и use cases в виде сценариев - это разные вещи, названные одним именем. Я не знаю истории этой диаграммы - возможно, изначально она использовалась именно как "карта сценариев", но возможности её применения гораздо шире.

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

Ну,  если бы надо было описать такое ВИ в спецификации,  это выглядело бы примерно так:

Красиво, спасибо. Но, видимо, мне не удается донести свою мысль.

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

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

Я кажется понимаю куда вы клоните!
По определению, ВИ - это ровно один прецедент использования системы. Т.е. или создание или редактирование или удаление.
При такой декомпозиции очень просто определить основной поток прецедента и альтернативные.
Например, основной поток - удалить расписание. Если расписаний нет - это уже альтернативный поток.

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

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

Это вы спрашивали?

Это вы спрашивали?

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

Ага При этом еще у каждого подпотока ведь могут быть какие-то свои альтернативы, нехарактерные для других.

Конечно.

Просто у меня у самого мало настоящего практического (живого) опыта. Только академический. Хотя студенты играют по-взрослому, но все равно есть искусственность.

У меня с практикой тоже не фонтан. Ни заказчики ни разработчики UML не знают, так что я рисую и пишу не по нотации, а чтобы людям понятно было:)

- случайный дубль

Если вы используете для разработки и поддержки требований систему, в которой диаграмма ВИ жёстко связана со сценариями (каждое "яйцо" является ссылкой на сценарий ВИ), то от этих отношений, наверное, никуда не деться. Но в этом случае диаграмма предназначена уже не столько для людей, сколько для роботов. Это такой механизм поддержки целостности модели требований, приближенный скорее к визуальному программированию.

А если вы не используете никакой системы с поддержкой трассировок? По-моему связи 1-к-1 для людей тоже удобнее, чем многие-ко-многим. Особенно если, к примеру разработчику, нужно будет потом разбираться какая часть спецификации к какому ВИ относится.

Что касается статьи по ссылке, то ВИ "Использовать банкомат" и "Выполнить одну транзакцию" кажутся мне искусственными.

Так и есть. Наследование (генерализация) часто делается именно от абстрактного (искуственного) ВИ. Соответственно абстрактный ВИ выражает абстрактную цель и может снижать сложность понимания модели.

Я не вижу для них практического применения ни со стороны целей пользователя, ни со стороны программной архитектуры.

Как же? Полезность есть как минимум с точки зрения:
1. Отсутствия необходимости изменения сценариев в нескольких местах с описанием общего поведения.
2. Снижения вероятности ошибок при таких изменениях.
3. Снижения вероятности многократной разработки одного и того же функционала.
4. Подсказки разработчикам в части применения нужных абстракций в коде.
5. Устранения необходимости многократного тестирования одного и того же функционала.

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

Я предпочитаю придерживаться мнения Коберна, который считает, что: "Вариант использования описывает ПОВЕДЕНИЕ системы при её ответах на запрос одного из участников, называемого основным дествующим лицом, в различных условиях.". Графическое изображение ВИ, соответственно, даёт общее представление о поведении через обозначение цели эктора.

Прошу передать меня инквизиции если я пишу ересь:) Пока что я уверен в своей позиции:)

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

Полностью согласен!

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

А зачем выявлять требования, но не описывать их? Agile?.

И, на самом деле, use cases на диаграмме и use cases в виде сценариев - это разные вещи, названные одним именем.

Точно так же как Activity на диаграмме и её подробное описание. Это то же самое, только в разных представлениях.

Прошу передать меня инквизиции если я пишу ересь:) Пока что я уверен в своей позиции:)

На костер его, богохульника!

Точно так же как Activity на диаграмме и её подробное описание. Это то же самое, только в разных представлениях.

По стандарту (если я не заблуждаюсь) все это можно считать разным способ реализации варианта использования

Кстати, если кому-то интересны рекомендации RUP по этому вопросы, то сюда

Я предпочитаю придерживаться мнения Коберна, который считает, что: "Вариант использования описывает ПОВЕДЕНИЕ системы при её ответах на запрос одного из участников, называемого основным дествующим лицом, в различных условиях.". Графическое изображение ВИ, соответственно, даёт общее представление о поведении через обозначение цели эктора.

Вариант использования как сценарий, безусловно, описывает поведение.

Диаграмма вариантов использования сама по себе поведение не описывает (хоть UML и относит её к классу bihavior diagram).

Графическое изображение варианта использования (как сценария) - imho это другие диаграммы (activity, sequence, communication в терминологии uml).

А зачем выявлять требования, но не описывать их? Agile?.

Выявлять, но не описывать в виде сценариев. Сценарии ведь не являются единственно возможным вариантом описания требований.

Agile - да, диаграмма ВИ может быть источником user stories.

Кстати, если кому-то интересны рекомендации RUP по этому вопросы, то сюда

Эдуард, спасибо за ссылку.

А зачем выявлять требования, но не описывать их? Agile?.

Нет. Прокурор.

может быть будет кому-то полезно
http://www.sparxsystems.com/resources/uml2_tutorial/uml2_usecasediagram.html

может быть будет кому-то полезно
http://www.sparxsystems.com/resources/uml2_tutorial/uml2_usecasediagram.html

Вот это вообще для меня новость.

Вот студенты выполнили работу над ошибками и сформировали немного иное представление. 
Буду рад замечаниям и предложениям.