А можно тогда пример отношения включения?

Самы распространенный пример: "Проверить пин код" включен в большое количество ВИ банкомата, например, в "Просмотреть счет", "Снять наличные"...

Отношение включения имеет смысл только тогда, когда ВИ включается в несколько ВИ.

Не всегда....

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

Смотря что. Но Вигерс с Кобероном - это то что должно быть прочтено обязательно и в начале.

Вот я лезу в раздел FAQ на сайте, смотрю книги... и вижу разделы "Наиболее интересные книги по UML:", "Наиболее интересные книги по Требованиям:"... Вигерс и Коберн как раз во втором разделе, и что, значит все остальные книги по UML уже не книги? Или UML от книги становится другим? Семантика то не должна меняться в зависимости от книги, даже из того списка, который выложен на сайте! Неужели я неправ? К примеру, я читаю книгу Леоненкова, в соответствии с этим и пишу здесь, а оказывается, это неправильная книга, то есть не книга по Требованиям и тем более не книга Вигерса и Коберна?
Извините, накипело.
Наверное тогда не имеет смысла продолжать эту ветку, я не читал книгу Вигерса.

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

StUtk, к сожалению в литературе по uml приведена только нотация ВИ, в них никогда толком не рассказывают, что такое варианты использования и с чем их нужно "есть". Основная часть ВИ (об этом кстати немного заикаются) это его описание (текст или диаграмма деятельности). На ДВИ выносят ВИ лишь для того, чтобы структурировать их и показать первое видение модели ВИ и функциональности системы.
Если вы хотите более подробно узнать о ВИ почитайте Коберна. Он рассматривает их исключительно как текстовое описание, изредка обращаясь к модели. Для большего понимания моделирования ВИ я рекомендую книгу Овергаарда Use Case Patterns and Blueprints (в ней и модели и описание). Для того как использовать ВИ в процессе разработки рекомендую почитать Леффингула. На русском есть 1 и 3 книги. Вигерса тоже стоит почитать, но у него  внимание уделено всем типам требований одинаково
Книга Леоненкова неплохая, но ИМХО, это переведенная спецификация UML2

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

Да рассказывают...)

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

Абсолютно согласен.

Книга Леоненкова неплохая, но ИМХО, это переведенная спецификация UML2

Близость к источнику, чем плохо? А потом, у него, кстати, очень неплохо разжёвываются основные понятия с конкретными примерами.

Близость к источнику, чем плохо? А потом, у него, кстати, очень неплохо разжёвываются основные понятия с конкретными примерами.

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

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

Любая теория без практики малоэффективна.

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

Да кто бы спорил...))

Самы распространенный пример: "Проверить пин код" включен в большое количество ВИ банкомата, например, в "Просмотреть счет", "Снять наличные"

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

Вот здесь, например:
http://www.intuit.ru/department/pl/umlbasics/4/2.html

Дело в том, что сам банкомат не в состоянии "проверить ПИН код".

А пошло это гулять от самого Коберна.

Гриша,

Так не понятно - на приведенной тобой ДВИ правильно изображен ВИ "Проверка ПИН-Кода ..."?? ИМХО по твоей логике правильно.
Но хотелось бы заметить, что есть типы карточек, на которых зашит сам ПИН-Код и вроде даже остаток на Счету, и Банкомату необязательно обращаться в Банк для списания и проверки ДС.

1. ВИ "авторизация"
цель:
- получения доступа к ресурсам сайта
краткое описание:
- пользователь запрашивает форму авторизации
- система предлагает ввести логин/пароль
- пользователь вводит данные
- система обрабатывает данные и предоставляет или отказывает в доступе

2. ВИ "регистрация"
цель:
- возможность авторизоваться
краткое описание:
- пользователь запрашивает форму регистрации
- система предоставляет форму
- пользователь вводит данные
- система регистрирует пользователя

1. ВИ "Авторизоваться"
цель:
- получения доступа к ресурсам сайта
краткое описание:
- пользователь идентифицирует себя в системе
- система обрабатывает данные идентификации и
   если данные верны предоставляет доступ к ресурсам сайта
   иначе предлагает "Пройти регистрацию" (точка расширения Пользователь системе неизвестен или введены ошибочные данные)
Результат: в интересах пользователя - получен доступ к ресурсам
                в интересах держателей системы -  не предоставлен доступ к ресурсам неизвестному посетителю
Т.е. подключение ВИ пройти регистрацию возникает при возникновении определенной ситуации

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

Обратите внимание, что я устранил даже намек на реализацию. Нет форм, нет требуемых данных. Предположим об этом подумают на стадии проектирования ВИ. Показано только ЧТО делает пользователь и ЧТО делает система.



А вообще процесс разработки итерационный

Гриша,

Так не понятно - на приведенной тобой ДВИ правильно изображен ВИ "Проверка ПИН-Кода ..."?? ИМХО по твоей логике правильно.
Но хотелось бы заметить, что есть типы карточек, на которых зашит сам ПИН-Код и вроде даже остаток на Счету, и Банкомату необязательно обращаться в Банк для списания и проверки ДС.

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

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

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

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

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

   если данные верны предоставляет доступ к ресурсам сайта
   иначе предлагает "Пройти регистрацию" (точка расширения Пользователь системе неизвестен или введены ошибочные данные)

Трудно не согласиться.

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

Будет ли создан четкий математический аппарат позволяющий четко и конкретно определить - это математически верный ВИ, а это не. Думаю вряд ли.

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

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

Хорошо или нет сказать: Пользователь вводит данные для авторизации?
С одной стороны вроде хорошо - мы не стесняем проектировщика в средствах - пусть сам определяет ЧТО это за данные
Но ... а как проверить что данные авторизации достаточны? Разве не определеннее и не яснее сказать Пользователь вводит Логин и Пароль, а в доптребования написать Логин - строка не менее 6 символов только латинского алфавита
Пароль - строка не менее 8 символов
Резонный вопрос, а куда пользователь вводит данные каким способом?

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

Более того многие авторы (авторитеты) призывают не описывать ВСЕ ВИ, или не описывать все ВИ одинаково.

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

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

Для начала нужно договориться о том, что такое функция системы ... я в данном случае не рассматриваю автоматизированную систему в терминах ГОСТ 34. Если принять что функция, это нечто, что делает СИСТЕМА, предположительно на основании ТРЕБОВАНИЙ к ней. То юзкейс, это однозначно НЕ ФУНКЦИЯ. Юзкейс - тогда скорее то, как функции этой системы будут задействованы для достижения цели пользователя. Например, у вас в программе есть функция фильтрации данных, отображаемых в гриде. Пользователь фильтрует данные не ради фильтрации, а скорее ради сравнения строк или нахождения нужной строки. Т.о. пользователь выполняет ряд действий для нахождения нужной информации, используя функцию фильтрации. Он может для достижения этой же цели воспользоваться более точным поиском по условию (использовать другую функцию).
Получается, что ВИ - это ничто иное, как функции системе в КОНТЕКСТЕ ИХ ИСПОЛЬЗОВАНИЯ, т.е. взгляд на систему из-за ее пределов. В то время как функция системы - это взгляд на мир из системы.

Отвечая на данную тему, задумался и пришел к выводу - не прав тот, кто задает вопросы, не правы и те, кто отвечает.

К счастью - те, кто отвечает не правы меньше.

Теперь несколько слов об основах.

1. Диаграмма Ви должна быть максимально простой
2. Чтобы быть простой она должна содержать как можно меньше структурных элементов(инклюд, экстенд, обобщение)
3. Инклюд означает, что базовый вариант не может быть исполнен без включение сопутствующего ВИ
4. Чаще всего ВИ включамый бывает неполным - т.е. не  может иметь экземпляров, но бывает и полным - т.е. вполне самостоятельным
5. Расширяющие ВИ чаще всего бывают неполными
6. Расщиряемые ВИ не зависимы от расширяющих, если сравнивать с инклюдами
7. Расширяющие ВИ чаще все-таки неполные, т.е. не имеют экземпляров

Резюме. В обсуждаемом случае лучше иметь два независимых ВИ: авторизация и регистрация. ЭТо не инклюд 100%, но и как расширение тоже не тянет. Просто регистрация - есть предусловие для авторизации