Смесь русского с английским - это нормально?

Наверное, не очень. В данном случае "cancel" даже не слово, а некий символ, как "ОК".

А вообще, в жизни такой диаграммы для UC быть не может. Некоторые действия отменять нет необходимости. UC описывает последовательность взаимодействий, значит д.б. минимум 2 раздела - Actor и система. Если считать, что запуск UC - одно из предусловий, то первое действие: "Система отображает главное окно UC". В этом окошке где-то справа внизу кнопочка "Cancel". Пока ее нет, ничего отменить нельзя!

Кроме того, в большинстве случаев нужно сохранять сведения о сеансе по различным причинам. Правда, такое указание м.б. в описании действия "Отмена всех действий". Например: "Система сохраняет текущее состояние информации формы ввода." (продажа, прием заказа, для анализа статистики обращений клиентов). "Система готова ..." и т.д.
 

Как я это делаю...Критикуйте!!!

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

Если Вам, вашим клиентам и разработчиком понятно, то критиковать нечего. Мне кажется, я понял, что Вы хотели сказать этой иллюстрацией.

Но ...

... это не UML, увы.

Нужно ли изучать и моделировать на UML - это Ваш выбор. Многие обходятся без этого.

Если Вам, вашим клиентам и разработчиком понятно, то критиковать нечего. Мне кажется, я понял, что Вы хотели сказать этой иллюстрацией.

Но ...

... это не UML, увы.

Нужно ли изучать и моделировать на UML - это Ваш выбор. Многие обходятся без этого.

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

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

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

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

Сегодня наиболее распространенный язык общения в разработке ПО - это UML.
Для того, чтобы рассказывать (описывать) и понимать описания UC, достаточно уметь пользоваться двумя диаграммами: Use Case и Activity.
Ваша иллюстрация заведомо менее понятна и менее информативна.

Потратьте пару часов, найдите в интернете какую нибудь книжку. Это будет много эффективнее, чем обсуждать вашу "кустарную" нотацию.

Помните про Костю, который поступал в литературный институт? На приемном экзамене на вопрос: "Что вы читали Пушкина?" он ответил "Костя не читатель. Костя писатель!".

Только не обижайтесь на меня!

Как я это делаю...Критикуйте!!!

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

Если следовать вашей диаграмме, то, боюсь, многое мне было бы непонятно, а, главное, и неправильно.

Смотрите, если вы используете классическую блок-схему, то и используйте ее правильно.
Овальный прямоугольник в начале и конце - это НАЧАЛО или КОНЕЦ программы или ее законченного участка (функции или процедуры).
Комментарий на классических блок-схемах записывается сбоку, вне фигур в квадратной скобке -[это комментарий
В случае условного перехода используется ромб (Да или Нет)
Параллельности в обычных блок-схемах нет (если я не ошибаюсь)

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

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

lnew, книги я, конечно же читаю, но стараюсь анализировать предлагаемые стандарты описания и формировать свой удобный инструмент на основе стандартов, который будет понятен всем. Стандарт UML не является широко используемым в нашей компании, поэтому, повторюсь: главным для меня является корректное формулирование ВИ.
Изначально у меня были проблемы с изображением некоторых моментов на диаграмме. Например, отмены на любом шаге (в текстовом описании такая проблема легко решается). Кроме того, остались проблемы, по которым я формулирую вопросы ниже.

Я сейчас сформирую текстовое описание того, что изображено (просто напишу по картинке) и может быть мы попробуем обсудить его?

Опускаю описание абстрактного прецедента "Добавить товар"
Наименование ВИ: Добавить товар
Краткое описание ...
Участники: ...
Предусловия: ...
Постусловия: ...
Основной сценарий: ...
Альтернативные сценарии: ...
Бизнес-правила: ...

Здесь мы обобщенного опишем процедуру добавления товара (независимо от того штука это или единица упаковки)

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

Наименование ВИ: Добавить базовую единицу
Краткое описание: Добавление базовых единиц товара в каталог.
Участники: Публикатор.
Предусловия: нет предварительных условий (хотя здесь можно написать, что публикатор успешно авторизовался, но мне кажется это излишним)
Постусловия: товар добавлен и зарегистрирован [Комментарий: см. вопрос дальше]
Основной сценарий:
1. Публикатор запускает действие добавления базовой единицы товара.
2. Система предлагает форму для заполнения данных о товаре.
[Комментарий: Здесь на блок-схеме в пунктирном прямоугольнике значится точка расширения - это означало наличие точки расширения в будущих релизах на этом месте. Т.е. мы бы написали здесь: точка расширения: подменить пустую форму.]
3. Публикатор заполняет данные о товаре.
4. Публикатор инициирует Зарегистрировать товар Вопрос: Тут мы уходим в выполнение другого сценарий (сценарий, который может быть выполнен самостоятельно, но полагаю на диаграмме ВИ, необходимо изобразить include). Целью сценария "Добавить товар" было добавления товара в чистовики, сценарий "Зарегистрировать товар" преследует цель перевода товара из черновиков в чистовики. При успешном выполнении вызываемого сценария мы достигаем цель, т.е. выполнены постусловия. Верно?
Альтернативные сценарии:
3а Публикатор прерывает выполнение сценария.
    3а1 Система выдает запрос на сохранение изменений.
    3а2 Публикатор подтверждает сохранение изменений. [Комментарий: здесь можно было бы использовать комбинацию Если...иначе]
          3а2а Публикатор отклоняет сохранение изменений.
          3а2b Публикатор отменяет прерывание выполнения сценария. Возвращается к шагу 2.
4а Публикатор сохраняет товар в черновики.
    4а1 Система проверяет товар.
    4а2 Система сохраняет товар в черновики. Вопрос: Стоит ли использовать "минимальные гарантии успеха" для того, чтобы зафиксировать, что сохранение в черновики - это тоже частичное выполнение сценария?
          4а2а Система выдает публикатору сообщение об ошибке.
4b Публикатор инициирует Добавить упаковку. Вопрос: Здесь у меня возникает проблема: публикатор хочет запустить выполнение другого сценария, но системе предварительно необходимо произвести некоторые действия. Как это можно зафиксировать. При этом, опять же достигается выполнение сохранения товара в черновики, но не главная цель.

        

Извините, Павел.
Я консультант по UML. Если Вы будете использовать UML, я готов Вам помочь.

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

До свидания на новом, более высоком уровне Ваших знаний и желаний!

Я понял, что Вы используете свою нотацию вместо Activity не потому, что она не подходит, а потому, что Вы ее не знаете, или знаете плохо. А учится не хотите. А для аналитика такая ситуация - смерть!

Павел, я присоединяюсь к lnew и тоже бесконечно удивлен, почему Вы не хотите использовать то, что наработано человечеством? Что Вас не устраивает?

Далее, Павел, Вы наверное удивитесь, но стандарт UML умалчивает о том, как следует описывать варианты использования. Поскольку UML - это объектно-ориентированный язык моделирования, а UC - это отдельно стоящее, хотя и активно использующееся в технологиях ориентированных на варианты использования и UML - такие как ICONIX и RUP.

2. Система предлагает форму для заполнения данных о товаре.

а почему форму? а не страницу, не документ? Это уже почти навязывание реализации. Может просто:
Система предлагает заполнить данные о товаре (кстати а чем товар отличается от базовой единицы товара?)

[Комментарий: Здесь на блок-схеме в пунктирном прямоугольнике значится точка расширения - это означало наличие точки расширения в будущих релизах на этом месте. Т.е. мы бы написали здесь: точка расширения: подменить пустую форму.]

Совершенно не понятно на каком основании тут точка расширения? и чего собственно расширяется? Почему расширяется? Что такое подменить пустую форму? Разве это не реализация? Чего хочет пользователь (публикатор), какое его или чей-то (ну других участников вы не указали) защищает этот шаг?

4. Публикатор инициирует Зарегистрировать товар Вопрос: Тут мы уходим в выполнение другого сценарий (сценарий, который может быть выполнен самостоятельно, но полагаю на диаграмме ВИ, необходимо изобразить include). Целью сценария "Добавить товар" было добавления товара в чистовики, сценарий "Зарегистрировать товар" преследует цель перевода товара из черновиков в чистовики. При успешном выполнении вызываемого сценария мы достигаем цель, т.е. выполнены постусловия. Верно?

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

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

ВИ - это точная цель пользователя и описание ее достижения и возможно препятствий мешающих этому

Вопросы ко всем

RUP рекомендует использовать для моделирования рабочего потока UC диаграмму деятельности (Activity Diagram).

А если язык реализации не ООП, а процедурный? Возможно ли рисовать такую диаграмму активности для UC в которой бы преобладали activity и они же постепенно раскладывались на диаграммы активности на более низком уровне опускаясь до реализации.
Мой инструмент(VP) упорно не хочет из шагов в текстовом описании создавать Activity, он их трактует как Action.
Всё таки хочется понять технологию трансформации ВИ в реализацию.
Или услышать рекомендации.

4. Публикатор инициирует Зарегистрировать товар Вопрос: Тут мы уходим в выполнение другого сценарий (сценарий, который может быть выполнен самостоятельно, но полагаю на диаграмме ВИ, необходимо изобразить include). Целью сценария "Добавить товар" было добавления товара в чистовики, сценарий "Зарегистрировать товар" преследует цель перевода товара из черновиков в чистовики. При успешном выполнении вызываемого сценария мы достигаем цель, т.е. выполнены постусловия. Верно?

если такая ситуация верна то какое отношение у этих двух ВИ? в каком случае отношением  будет "включить", а в каком "Зарегистрировать товар" является под целю "Добавить товар", то есть на более низком уровне. Оба способа я нарисовал на диаграммах.

Вопросы ко всемА если язык реализации не ООП, а процедурный? Возможно ли рисовать такую диаграмму активности для UC в которой бы преобладали activity и они же постепенно раскладывались на диаграммы активности на более низком уровне опускаясь до реализации.
Мой инструмент(VP) упорно не хочет из шагов в текстовом описании создавать Activity, он их трактует как Action.
Всё таки хочется понять технологию трансформации ВИ в реализацию.
Или услышать рекомендации.

Никаких ограничений на использовании ДД для описнаия структуруного подхода в програмиирования нет. вообще не вижу тут никакой проблемы.

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

если такая ситуация верна то какое отношение у этих двух ВИ? в каком случае отношением  будет "включить", а в каком "Зарегистрировать товар" является под целю "Добавить товар", то есть на более низком уровне. Оба способа я нарисовал на диаграммах.

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

Немного изменил варианты использования. Суть в том что
ВИ "Получить товар" более абстрактный чем ВИ "Заказать товар".

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

Тогда получается, что более логично выглядит последняя картинка с двумя ДВИ на разных уровнях.
Или это не соответствует стандартам?

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

А как тогда показать(или может описать) взаимосвязь между этими ВИ на БВДИ и ДВИ?

А как тогда показать(или может описать) взаимосвязь между этими ВИ на БВДИ и ДВИ?

Здесь нарушение на логическом уровне. Нельзя смешивать БВИ и СВИ. Но взаимосвязь показать можно зависимостью например.

Смотрите Заказать товар - что это такое? в каком контексте? Цель какова? Очевидно чтобы получить товар.
Т.е. бизнес-процесс для получения товара включает заказ товара. Если Вы автоматизируете заказ товара, то имеет смысл только ВИ Заказать товар. Хотя возможно в вашей галактике уже существует телепортация или вы живете в полностью информационном обществе и товар производится непосредственно дома, достаточно получить программу изготовления, но в нашей галактике мы еще не научились этого делать. Поэтому ВИ Получить товар к сожалению нет. Можно Получить извещение о получении товара (на почте например)

Да действительно телепорт лучше сделать отдельной системой. Чтобы его можно было использовать не только для получения товара

А если представить что последняя картинка это не ДВИ для разрабатываемой системы, а БДВИ для организации.
Неужели в этом случае "Получить товар" и "Заказать товар" оба будут находится на верхнем уровне(то есть в предельной области действия), где "Получить товар" включает "Заказать товар"? Может организация например допускает что можно просто Зарезервировать товар (или есть какой то другой ВИ который является под целю  для "Получить товар", так же как и "Заказать товар"). То есть для БВДИ последняя картинка логичная?

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

Последняя с какого края (верхняя али нижняя)?

Неужели в этом случае "Получить товар" и "Заказать товар" оба будут находится на верхнем уровне то есть в предельной области действия), где "Получить товар" включает "Заказать товар"?

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

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

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

Может организация например допускает что можно просто Зарезервировать товар (или есть какой то другой ВИ который является под целю  для "Получить товар", так же как и "Заказать товар"). То есть для БВДИ последняя картинка логичная?

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