Согласен, не учебник, а справочник .

Эдуард, мой пост ни в коем случае не критика. Просто сейчас распространяются всевозможные гибкие методологии, в которых вместо UC и требований в обычном виде зачастую применяются "пользовательские истории". Простые, конкретные, понятные всем (от программиста до инвестора), проверяемые за полчаса-час демонстрации результатов итерации.

 IMHO взялся писать (уже респект!), попал в ЧаВо - кому как не тебе поддерживать и дополнять ?

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

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

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

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

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

Позволю себе процитировать Карла Вигерса ("Разработка требований к программному обеспечению"):

"Если в процессе сбора информации вы не укажете, как обрабатывать исключение, то возможны два пути:
1. разработчики предложат лучший по их мнению способ обработки исключений;
2. при генерации пользователем неверного условия произойдет сбой системы, так как никто не предусмотрел такой ситуации.
Бьюсь об заклад, что сбои системы не входят в список требований пользователей."

"Иногда исключения рассматриваются как тип альтернативного направления (Cockburn, 2001), однако эти понятия следует разделять. Не обязательно реализовывать каждое альтернативное направление, которое вы определили для варианта использования; кроме того, вы можете отложить его реализацию до следующего выпуска. Однако вы обязаны реализовать исключения, из-за которых завершение сценариев может оказаться неуспешным. Любой, кто когда-либо занимался программированием, знает, что часто именно на работу над исключениями приходится большая часть программирования. Многие недостатки конечного продукта присущи именно обработчикам исключений (или происходят из-за их отсутствия!)".

IMHO взялся писать (уже респект!), попал в ЧаВо - кому как не тебе поддерживать и дополнять ?

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

Насчет пользовательских историй - наверное нужно помещать в ЧАВО, типа как писать требования

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

А почему там должно что-то быть написано?

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

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

Описания правил по структуризации ВИ несколько позже

А почему там должно что-то быть написано?

1. Потому что исключения имеют непосредственное отношение к спецификации варианта использования.

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

3. В конце концов потому, что статья называется "Рекомендации по написанию спецификаций вариантов использования".

P.S.
Расширения = альтернативные потоки?
Вы вообще это пишете для последующего практического применения специалистами или для чего?

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

Описания правил по структуризации ВИ несколько позже

Прекрасно завершаться? Интересно как, только на бумаге?

Вы вообще это пишете для последующего практического применения специалистами или для чего?

Velarix, напишите свою статью. Я уверен, что на uml2.ru её с удовольствием опубликуют.

Velarix, напишите свою статью. Я уверен, что на uml2.ru её с удовольствием опубликуют.

Ничуть не сомневаюсь =) Возможно, месяца через три.

Вы вообще это пишете для последующего практического применения специалистами или для чего?

Причины разные. В том числе получить удовольствие. И возможно научиться. Обучая - учимся.

Интересно как, только на бумаге?

Не очень понял вопроса

Не очень понял вопроса

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

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

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

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

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

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

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