Давайте немного подождем до момента, когда я подойду к включениям и расширениям.

Пока у меня есть впечатление, что вы путаете эти два понятия: включение и расширение.

Разница в следующем.
Базовый ВИ, ВКЛЮЧАЮЩИЙ другой фрагмент, не может быть завершен без включения последнего. Это как require в рнр или Си

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

Если же условия возникли и расширяющий фрагмент включается в поток, то он самом деле не включается в основной поток - а порождает альтернативный поток, в отличии от случая ВКЛЮЧЕНИЯ

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

Для вас Расширения = Альтернативные потоки? Иначе зачем вы ответили про расширения, когда Виталий писал про альтернативные потоки?

И что вы подразумеваете под "фрагментом"?

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

У нас в анализе действует правило постепенности и итеративности описания требований.

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

Делить альтернативные потоки на успешные и неуспешные — это уже детализация, до которой на уровне вводной статьи доходить не стоит.

Думаю, такой "перекрёстный обстрел" может сильно понизить желание писать какие-либо статьи.

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

Мы в компании именно с помощью wiki это решаем. Хочешь поспорить - пиши/дописывай. Если же писать не хочешь или не можешь - значит, несогласие несущественно.

----

Моё личное мнение по поводу "исключений", и вообще по поводу сверхдетального описания всего и вся в UC: сложно, не работает. Не читают. Всё равно делают по-своему.

Если есть какой-то важный, но простой альтернативный поток - можно написать в UC. Ну а сколь-нибудь сложную логику я обычно описываю в activity, statechart, иногда даже sequence, прикреплённых к этому UC.

Если что-то опустил/упустил - при нормально налаженных рабочих и человеческих отношениях, программисты всегда переспросят "а как нужно-то"? А при отсутствии таких отношений даже сверхдетальный документ тоже слабо помогает. Разве что потом, при "разборе полётов", чтобы стало понятно, кого наказывать... Но ведь цель не наказать за то, что неправильно сделали, а сделать правильно.

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

У нас в анализе действует правило постепенности и итеративности описания требований.

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

Делить альтернативные потоки на успешные и неуспешные — это уже детализация, до которой на уровне вводной статьи доходить не стоит.

Денис, ни о каком "рубилове" и речи нет! Я считаю, что подобное обсуждение - это нормальный процесс, и профессионал никогда не будет уклоняться от дискуссий на тему того, что он пишет/утверждает.

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

Безусловно, за каждым остаётся право писать всё, что ему взбредёт в голову, и не считаться ни с чьим мнением. К тому же автор уже сказал, что он пишет для того, чтобы самому учиться и для удовольствия, хотя изначально (исходя из наименования статьи) я предположил, что она адресована практикам.

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

Думаю, такой "перекрёстный обстрел" может сильно понизить желание писать какие-либо статьи.

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

Мы в компании именно с помощью wiki это решаем. Хочешь поспорить - пиши/дописывай. Если же писать не хочешь или не можешь - значит, несогласие несущественно.

----

Моё личное мнение по поводу "исключений", и вообще по поводу сверхдетального описания всего и вся в UC: сложно, не работает. Не читают. Всё равно делают по-своему.

Если есть какой-то важный, но простой альтернативный поток - можно написать в UC. Ну а сколь-нибудь сложную логику я обычно описываю в activity, statechart, иногда даже sequence, прикреплённых к этому UC.

Если что-то опустил/упустил - при нормально налаженных рабочих и человеческих отношениях, программисты всегда переспросят "а как нужно-то"? А при отсутствии таких отношений даже сверхдетальный документ тоже слабо помогает. Разве что потом, при "разборе полётов", чтобы стало понятно, кого наказывать... Но ведь цель не наказать за то, что неправильно сделали, а сделать правильно.

Как это не работает? По моему, от аналитика зависит, работает или не работает. Кто "не читают"? Кто эти спецификации должен читать и что делать на их основании?

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

Почему "на порядок важнее"? Обоснуйте. А то у нас на форуме не принято верить на слово.

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

И будут бедные практики, как и прежде, блуждать в потёмках.

Писать бы статьи в виде публикаций wiki

Саша, читаешь мысли. За то время, что мы тут потратили на перепалку, вполне можно было написать уже всё в вики.

профессионал никогда не будет уклонятся

мягкий знак?

Денис, советую перечитать мои сообщения выше, потому что повторяться не хочется... Альтернативные потоки и исключения - разные артефакты.

С каких пор потоки стали артефактами?

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

С какой стати неуспешные завершения важнее успешных?

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

мягкий знак?

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

Практики на то и практики, что статей не читают, а всё на своём опыте изучают — методом проб и ошибок.

А вообще вот так хорошо сидеть и желать. Если вам настолько интересна эта тема — напишите про важность исключений (терминальных потоков) хотя бы заметку.

Почему "на порядок важнее"? Обоснуйте. А то у нас на форуме не принято верить на слово.

Написал выше, даже цитаты привёл =)

И будут бедные практики, как и прежде, блуждать в потёмках.

Зачем же блуждать в потёмках, когда можно прочитать того же Вигерса или Коберна.

Почему в статье ничего не написано про исключения (Exception)?

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

1. Потому что исключения имеют непосредственное отношение к спецификации варианта использования.
2. Потому что исключения даже более важны, чем альтернативные потоки, про которые вы не преминули написать (если конечно, вы не подразумеваете исключения как частный случай альтернативного направления). 
3. В конце концов потому, что статья называется "Рекомендации по написанию спецификаций вариантов использования".
P.S.
Расширения = альтернативные потоки?
Вы вообще это пишете для последующего практического применения специалистами или для чего?

Где, какие противоречия, Velarix? Я заметил неточность (на мой взгляд) в сообщении Виталия и ему ответил. Вы тоже вступили в дискуссию. А потом стали утверждать, что Вас проигнорировали и перевели разговор на иную тему. Ну Вы можете иметь такую точку зрения...

Я сказал, что буду еще писать дальше...

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

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

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

Объяснить это можно тем, что основной поток часто лежит на поверхности, а вот извлечение "подводных" потоков, не очевидных и сразу не распознаваемых, довольно сложно и показывает профессионализм аналитика.

Саша, читаешь мысли. За то время, что мы тут потратили на перепалку, вполне можно было написать уже всё в вики.

Григорий, может изучить возможность прикручивания wiki к Joomla (есть разные пути) и продумать предложения?

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

мягкий знак?

Да, это вы правильно заметили. Торопился, отвечал уже перед уходом, и случайно пропустил мягкие знаки. Уже исправил, приношу извинения.

С каких пор потоки стали артефактами?

Глоссарий.ru:
Артефакт исследования - процесс, явление, образование, не свойственные изучаемому объекту как таковому и возникающие в ходе его исследования вследствие применения теорий, методов, инструментов, организационных приемов.

Г Буч, Д Рамбо, А Джекобсон ("Язык UML Руководство пользователя" второе издание):
Артефакт - элемент информации, используемый или порождаемый в процессе разработки программного обеспечения.

Моделирование взаимодействия пользователя с системой является порождением новых элементов информации. Приведите своё определение.

С какой стати неуспешные завершения важнее успешных?

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

Практики на то и практики, что статей не читают, а всё на своём опыте изучают — методом проб и ошибок.

Греч. praktike, от praktikós - деятельный, активный. Соответственно под словом "практик" я подразумеваю человека, который практически использует обсуждаемые знания.

А вообще вот так хорошо сидеть и желать. Если вам настолько интересна эта тема — напишите про важность исключений (терминальных потоков) хотя бы заметку.

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

Где, какие противоречия, Velarix? Я заметил неточность (на мой взгляд) в сообщении Виталия и ему ответил. Вы тоже вступили в дискуссию. А потом стали утверждать, что Вас проигнорировали и перевели разговор на иную тему. Ну Вы можете иметь такую точку зрения...

Виталий написал:
Exeption - это частный случай альтернативного потока событий, который приводит к завершению варианта использования.

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

Вопрос: почему, когда Виталий говорил об альтернативных потоках, вы ответили про расширения?

Исключение - это нарушение основного потока, следовательно, альтернативный путь, возникший в результате возникновения исключения.

Исключения касаются не только основного потока, но и альтернативных. Или вы считаете, что в альтернативных потоках не может быть исключений?

Вот такие дискуссии и приводят к реальным результатам.
Кто-то выше спрашивал про удачное и неудачное завершение вариантов использования.
Вариант использования всегда имеет цель - цель пользователя.
1. Если пользователь достиг свою цель полностью (или частично) такой сценарий называется удачным.
2. Если пользователь не достиг своей цели - сценарий считается неудачным и ВИ завершается "отрицательно".

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

Далее спускаемся с небес на землю и понимаем, что чудес не бывает. Начинаем описывать исключения к основному потоку событий для того, что реализовать его корректно и в продакшине сценарий "не слетел" с сообщением типа "Fatal error! java.exeption... "

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

О том как их записывать и разделять или нет - это дело вкуса. ИМХО, даже спорить не нужно.
Я лишь советую помечать исключения или писать отдельно только для того, что так удобней работать программистам - проверено на практике.  Они сразу видят как надо реализовать exceptions.

А Эду отдельный респект за статью. Осталось дописать сюда как вклинивать в описание вариантов использования включения и расширения и возможность стартовать и заканчивать в нескольких точках. Я себя отношу к данной школе описания ВИ . Старая школа считает, что точка входа может быть всего одна.

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

Velarix, посмотрите топик про описание системных вариантов использования здесь и про сценарии здесь
Связанные вещи.

Исключения касаются не только основного потока, но и альтернативных. Или вы считаете, что в альтернативных потоках не может быть исключений?

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