Доброго времени суток.
1. Действие "Отмена" доступно пользователю на протяжении всего ВИ. Как зафиксировать данный момент? У Коберна встречал такую практику: на первом шаге описывается расширение со словами "В любой момент до ... пользователь может отменить ...". Не очень понравился такой способ, есть ли ещё какие-нибудь варианты?
2. На некотором шаге ВИ возможным продолжением для пользователя является запуск другого ВИ (при этом обратно пользователь уже не возвращается). В данном случае я не фиксирую связей на диаграмме прецедентов, а в первоначальном ВИ создаю шаг альтернативного (на самом деле может быть и основным, полагаю) сценария, в котором прописываю "Публикатор иницирует Зарегистрировать ...". Верным ли является данный подход?
3. Наконец, я документирую ВИ используя блок-схемы, а не текстовое описание (при этом я стараюсь следовать стандартам текстовых описаний). Возможен ли такой подход? +/- такого решения, на ваш взгляд?

С терминологией могу немного плавать.

P.s. Вкратце о себе: работаю системным аналитиком 2 года, слежу за сообществом уже давно. Вот, наконец, решил включиться в активное общение.

Если вопросы придутся по душе, попробую задать ещё несколько 

1. Т.к. Коберн принципиально "не видит" диаграммы UML применительно к UC, он использует единственно возможный метод. И очень удачный.
1-3. Если использовать UML: RUP рекомендует использовать для моделирования рабочего потока UC диаграмму деятельности (Activity Diagram). Если Ваша блок-схема - это диаграмма деятельности UML, то я могу посоветовать, как поступить в каждом из описанных случаев. Если нет - кто же знает, что Вы рисуете?

1. За действием "Отмена" могут быть разные алгоритмы. Можно условится, что мы отменяем какое либо запущенное действие. А запущенное действие приводит к достижению результата ВИ.
То есть тут даже не сколько важен факт нажатия кнопки "Отмена", сколько реакция системы после нажатия. Поэтому я бы описал шаги так

Код: [Выделить]

 3. Система блокирует на счету пользователя нужную сумму
Если пользователь отменил покупку:
  4. Система возвращает заблокированную сумму.

Но обычно делаю по другому:

Код: [Выделить]

Если пользователь сделал заказ:
  3. Система блокирует на счету пользователя нужную сумму
Иначе:
  3a. Система возвращает заблокированную сумму.
2. А может ли измениться цель пользователя при прохождении в основном потоке ВИ, чтобы перейти к другому ВИ для завершения потока?
3. Было бы неплохо увидеть пример такого описания, может и мне понравится. Сейчас пользуюсь средством Visual Paradigm оно накладывает ограничение на описание ВИ. Насколько я разобрался там ВИ описываются и как текстовые шаги и как Activity, причем они между собой взаимосвязаны.

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

3. Было бы неплохо увидеть пример такого описания, может и мне понравится. Сейчас пользуюсь средством Visual Paradigm оно накладывает ограничение на описание ВИ. Насколько я разобрался там ВИ описываются и как текстовые шаги и как Activity, причём они между собой взаимосвязаны.

Извините, чуть в сторону.
Мой первый инструмент UML был Paradigm+ от Platinum (ныне, кажется, в составе CA). Это оно?

1. Действие "Отмена" доступно пользователю на протяжении всего ВИ. Как зафиксировать данный момент? У Коберна встречал такую практику: на первом шаге описывается расширение со словами "В любой момент до ... пользователь может отменить ...". Не очень понравился такой способ, есть ли ещё какие-нибудь варианты?

Я понял так, что имеется ввиду отмена всего, сделанного в рабочем потоке UC, Или только последнего действия? Реакция системы (и способ описания) существенно разные!

Извините, чуть в сторону.
Мой первый инструмент UML был Paradigm+ от Platinum (ныне, кажется, в составе CA). Это оно?

Нет, это совершенно новый продукт. Восходящая звезда Гонконга. http://visual-paradigm.com

Доброго времени суток.
1. Действие "Отмена" доступно пользователю на протяжении всего ВИ. Как зафиксировать данный момент? У Коберна встречал такую практику: на первом шаге описывается расширение со словами "В любой момент до ... пользователь может отменить ...". Не очень понравился такой способ, есть ли ещё какие-нибудь варианты?

Посмотрите такой вариант. Пример 5 и 7. Не подойдет?

Нет, это совершенно новый продукт. Восходящая звезда Гонконга. http://visual-paradigm.com

Спасибо, Эдуард!

Посмотрите такой вариант. Пример 5 и 7. Не подойдет?

Ага) что-то похожее на Коберна, но чуть симпатичнее.
P.s имел ввиду отмену всего, что было сделано в рабочем потоке UC

Ага) что-то похожее на Коберна, но чуть симпатичнее.
P.s имел ввиду отмену всего, что было сделано в рабочем потоке UC

Но и у Коберна, и в представленном примере, так и есть. 
Если ВИ рассматривать как некий протокол взаимодействия актора и системы (а так оно и есть), то описывая разные постусловия, мы указываем возможные состояния системы после исполнения ВИ.
Ясно, что будет некое явное целевое состояние и какие-то побочные. Помните у Коберна - минимальные гарантии успеха. Т.е. что должно быть в самом худшем раскладе.
Отмена исполнения ВИ в процессе его реализации - это по сути откат транзакции, откат к исходному состоянию, к предусловию. Вам нужно это как-то указать. Это некое требование, причем, если вдуматься, негласное требование самого ВИ. Любой ВИ состоит из собственно себя - т.е. цели использования системы актором и описанием варианта использования (UCD - как говорят буржуи, причем эти буржуи всегда проводят грань между UC и UCD). В описании ВИ всегда должен присутствовать типичный сценарий событий. Отмена - тоже вполне типичный, но все-таки альтернативный сценарий. При этом словами с помощью описания это можно сделать очень просто, а графически изображать - надумаешься.

1-3. Если использовать UML: RUP рекомендует использовать для моделирования рабочего потока UC диаграмму деятельности (Activity Diagram). Если Ваша блок-схема - это диаграмма деятельности UML, то я могу посоветовать, как поступить в каждом из описанных случаев. Если нет - кто же знает, что Вы рисуете?

Гм. Попробую сформулировать свое понимание диаграмм деятельности. Поправляйте.
С помощью диаграммы деятельности удобно моделировать поведение системы: порядок выполнения действий/ операций. Еще можно, используя эти диаграммы, описать порядок выполнения ВИ.
С другой стороны, ВИ - как игра в настольный теннис. Здесь есть последовательные действия системы и действия актора. Поэтому затрудняюсь ответить: являются ли мои блок- схемы - диграммой деятельности.
Я постараюсь в ближайшее время показать каким образом выглядит мое описание ВИ. Тогда можно будет более детально оценить, покритиковать:)

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

Павел, Вам уже дал ответ Леонид Борисович, сославшись на такой компетентный источник как RUP, в котором он безусловно дока. Известно, что RUP создан теми же персонажами, которые приложили руку к UML. Отсюда следует, что по сути и то и другое создавалось одновременно.

Я не знаток RUP, т.е. не такой глубокий знаток. И, наверняка, ошибаюсь. Но мне не совсем нравится делать описание варианта использования с помощью диаграмм деятельности.
1. это сложнее (Вы же сами обратились, а подумайте что делать, если последовательность некоторых шагов не важна? Как это изобразить?)
2. это менее понятно окружающим
3. это требует от окружающих тонкого владения концепций UML и диаграммы деятельности в частности
4. это невольно заставляет усложнять описание вариантов использования и затруднять их понимание
5. я не понимаю модели (или механизма) трансформации диаграммы деятельности (правда и текстового описания) в реализацию варианта использования
---Потому все это личный выбор, дело личного опыта и собственной практики, способ, который по душе Вам и которому Вы сумели обучить окружающих (с учетом пунктов 1-4)

PS Знакомство с UML я начал с книги Джозефа Шмуллера (в 2001 году, если не ошибаюсь) в ней предлагался такой подход.
1. вы берете интервью и изображаете основной бизнес-процесс (важную деятельность) с помощью ДД
2. в ходе ее изображения у вас может появится потребность какую-то часть деятельностей свернуть - получите некий параллельный БП
3. обязательно виды деятельностей нужно раскидать по персоналиям - это также позволяит выделить какие-то параллельные БП или деятельности
4. Среди этих видов деятельностей какие-то и будут целью автоматизации
5. они сами по себе или после декомпозиции их на части станут вариантами использования
6. описание ВИ было словесным, но кратким и далее сразу предлагалось переходит к реализации ВИ (аналитической сначала)

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

Это все же не альтернативный, а параллельный сценарий.
Вот вариант:

Вот вариант:

Прекрасный вариант, снимаю шляпу.

Можно вопрос? А decision node после деятельности (или действия) Отмена нужен для того, чтобы обеспечить непрерывность правого потока? Какой вопрос задается в этом случае? Почему на ветки альтернативы еще приходится писать слово [cancel]? Смесь русского с английским - это нормально?

Я в первом варианте ошибся, спешил.
Если хочешь, нарисую, как перейти безвозвратно к другому UC. Но завтра уже.