Сергей, нет ли у тебя полного шаблона описания варианта использования.
У меня есть множество различных вариантов, а на каком остановится не знаю. Хотелось бы иметь самый полный или, например, который ты чаще всего используешь и считаешь оптимальным.

По поводу обучения предполагается примерно такая программа:

1 занятие. Семинар - фантазийное формулирование бизнеса на тему, предложенную преподавателем. Командная работа. Метод мозгового штурма. Цель: нафантазировать бизнес в меру своих возможностей. Преподаватель как направляющая сила. Домашнее задание - закончить фантазии и сделать презентацию своих концепций и идей. Срок сдачи за два дня до начала занятия по e-mail или в рабочую папку. Срок 2 недели.

2 занятие. Семинар - обсуждение презентаций. Презентация 10 минут, 20 минут обсуждение. Обнаружить, высказать проблему(ы). Группа выступает аудитория задает вопросы (4 выступление за семинар, не хватит времени перенос на лекцию). Домашнее занятие: уяснение проблемы, причин возникновения проблемы, участников проблемы, негативных последствий проблемы, что изменит в лучшую сторону создание новой системы.
Срок сдачи за два дня до начала занятия по e-mail или в рабочую папку. Срок 2 недели.

3 занятие. Обучение написанию вариантов использования в контексте выявленной проблемы. Примеры, написание варианта использования по каждой теме групповых заданий. Домашнее задание: написание сценариев для выявленных ВИ. Срок сдачи за два дня до начала занятия по e-mail или в рабочую папку. Срок 2 недели.

4 занятие. Работа в UML. построение диаграммы ВИ и диаграммы деятельности.
Домашнее задание: построить диаграммы и подготовить презентацию
Срок сдачи за два дня до начала занятия по e-mail или в рабочую папку. Срок 2 недели.

5 занятие. Семинар-презентаци. Выявление ошибок. Домашнее задание: устранение ошибок, доработка ВИ, диаграмм. Срок сдачи за два дня до начала занятия по e-mail или в рабочую папку. Срок 2 недели.

6-11 занятия. еще не придумал полностью. Модель бизнес-объектов. Переход к системным вариантам использования. Диаграммы последовательности для системных событий (Пользователь - (событие)- Система (По Ларману 2 е издание))

Лично я против чтения диаграмм в таком стиле. Во первых нет уверенности, что ты вытащил всю информацию. А во вторых вообще нет понимания, на какие вопросы в принципе может отвечать диаграмма.

Да ради Бога. Баб Яга всегда против:-) 1. в твоем вопросе описать, что ты видишь на диаграмме, я увидел подколку. Потому абстрагировался от "глубоких" познания UML, а использовал только познания скажем те, которые мне объяснил мой консультант, когда показывал енту самую диаграмму.
Что он мне сказал:
Прямоугольник очерчивает границы вашей зао "рога и копыта". Все что внутри - это ваше устройства бизнеса. Вот эти человечки  - действующие лица, которые чего-то хотят (чего написано внутри овальчиков).
Вот исходя скажим их таких примитивных постулатов я и начинаю исходить.

Ты же мне не написал - проделай полный анализ диаграммы на предмет того-то.  Мы наверное с тобой антагонисты :-) Когда ты задавал мне это вопрос, уже ожидал получить ответ такого вот вида, а я например узрел в этом, что сама по себе диаграмма ВИ неочень информативна, и искренне полагал, что именно это ты мне пытаешся объяснить. Не угадал :-) Опять получил щелбан.

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

Как бы я предложил читать ту диаграмму: надо понимать, что это вполне конечный и определенный набор фактов.

Кажестя повторяться не имеет смысла, а?

3. Существуют описанные цели и сценарии их реализации

И где ты увидал сценарии реализации? Я пока вижу цели и связи

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

А с какой позиции смотреть. Кстати про ОДЛ я вообще ничего не говорил явно, однако. Если закрыть листочком все ЗАО мы увидим - а что мы увидим, Клиента - Черный ящик(с целью получить обслуживание)
По-моему не надо быть Коперником, чтобы понять, что клиент тут чего-то хочет. А хочет он явно получить обслуживание. По-моему ничего противоречащего здравому смыслу и здравой логике тут нет.

Давай найдем отличия твоего прочтения от реально имеющегося в диаграмме...

Давай попробуем.


[

b]Клиент обращается в ЗАО "Рога и копыта", чтобы Получить обслуживание.[/b] (Где написано слово "обращается", откуда известно, что основное действующее лицо - клиент?)

См выше. Если тебе так написать Клиент хочет получить обслуживание в ЗАО. Модель тем и характерна, что она скрывает или убирает второстепеннные элементы, а выпячивает значимые. Т.е. я полагаю, если ты мне нарисовал RLC- цепь, то вероятно в ней индуктивность означает именно индуктивность.

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

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

домыслы не засчитаны, таких фактов нет на диаграмме)

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

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

Это назвается многократный перевод. Такому стилю учать иностранному переводу.
Очевидно можно добавить некие комменты.

Естественно - это все мое частное мнение. Прошу критиковать и обсуждать.

Это не мнение - это декларация своих идей:-))

Мое мнение, думаю, в данной ситуации абсолютно не значимо. Былобы интересно узнать мнения других практикующих людей. Именно практикующих, поскольку мои знания чисто теоретизированы и не подкреплены практикой.

Предлагаю не нагнетать эмоции. если задел - приношу извинения.

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

ОДЛ - это носитель цели и почти всегда инициатор. Если ОДЛ н еинициатор, то это очень четко оговаривается. Так как я не разделял участников на бизнес-актеров и актеров, то они все нарисованы одинаково.

Еще раз повторюсь, я действовал в роли простого обывателя, который видит картинку, особо не зная всех тонкостей, но имеющий все-таки солидный жизненный опыт. Как раз этот опыт мог мне подсказать, что Клиент и есть некое внешнее лицо, желанное для ЗАО "Рога и копыта" и имеющий некий интерес в этом учреждении. Далее я вижу некую роль Продавца. Ассоциация очевидна. Я не знаю что там такое это продавец продает, но судя по названию ЗАО, рога и копыта... Конечно это домыслы, но что еще можно узнать из такой диаграммы?
Ты ответил, что к ней надо было бы подходить с точки зрения семантики UML, т.е. читать схему. Возможно ты и прав...

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

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

Выпадом про мнение ты ставишь меня в тупик... Чем принципиально различно мое мнение и мои идеи?

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

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

Это я уже понял, вернее понимал и раньше и интуитивно использую, просто нет еще навыка делать это скурпулезно.


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


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

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

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

Насчет понятия проблемы, тоже разъянилось. Я тут побеседовал с Юрием Булуем и согласен, что проблема должна исходить от заинтересованной стороны, а не навязываться ей.

Вообщем можно сказать, что конценсус найден :-))

Нужно теперь его закрепить...

[Некробурения приступ]
"Ресторан" является популярным тренажёром -- учебной моделью, на которой якобы можно продемонстрировать подход, возможности нотации и т. п.. При этом считается, что [всю всамделишную] работу ресторана можно хорошо себе представить и считать-узнать в учебной модели. Полагаю это очень сильмым допучением и считаю, что "ресторан-тренажёр" моделирует только наши представления, которые могут соотноситься или не соотноситься с реальностью.
"Ресторан" by Kirill Fakhroutdinov.
"Ресторан" как часть руководства по RUPу от IBM и как исходник рисунков Fakhroutdinov-а.
"Ресторан с красными человечками" by Kirill Fakhroutdinov -- иллюстрация популярных "граблей" при построении BUC-модели.

[Некробурения приступ]
"Ресторан" является популярным тренажёром -- учебной моделью, на которой якобы можно продемонстрировать подход, возможности нотации и т. п.. При этом считается, что [всю всамделишную] работу ресторана можно хорошо себе представить и считать-узнать в учебной модели. Полагаю это очень сильмым допучением и считаю, что "ресторан-тренажёр" моделирует только наши представления, которые могут соотноситься или не соотноситься с реальностью.
"Ресторан" by Kirill Fakhroutdinov.
"Ресторан" как часть руководства по RUPу от IBM и как исходник рисунков Fakhroutdinov-а.
"Ресторан с красными человечками" by Kirill Fakhroutdinov -- иллюстрация популярных "граблей" при построении BUC-модели.

Я бы добавил в копилку Джозефа Шмуллера

Долистало до примера с рестораном. По дороге хотело всё свалить на переводчика-ксенолингвиста, но просмотр оригинала на английском показывает, что книга за прошедшее время сильно разошлась со стандартом UML, которому учит. Ну и изначальные дефекты есть.

Я бы не рекомендовало.

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

"Приключения в ресторане" продолжаются.
Некто поместил в википедию свою версию диаграммы ВИ ресторана. Далее её стали использовать в куче мест. (К слову в самой вики пытаются эту диаграмму читать и как BUC, игноря предупреждения by Kirill Fakhroutdinov с красными человечками, приведённые выше). Например, её использовали создатели рисовалки, не умеющей пунктирные стрелки. Так появилась испорченная версия со сплошными экстендами.  Дальше больше. Испорченную версию ещё больше испортила авторка из Томска и поместила в придуманный ею тест на знание UML. Верхний сплошной экстенд стал сплошным инклюдом (отражая, по мнению авторки из Томска, "Неконсистентность связей между прецедентами с вином и едой: include указывает на то, что заказ вина возможен ТОЛЬКО при заказе еды"). Однозначно ошибочным является только нарушение нотации (непунктирные стрелки расширений и включения). Вероятно ошибочным -- направление инклюда. Замороченность тем, что с чем заказывать, выпивку к закуске или закуску к выпивке, ВИ-диаграмма не в силах прояснить, тут необходимо читать тексты сценариев.

RUP (по неясно откуда взявшейся традиции, называя его UMLем) не только увязывают бегом на месте, но и заявляют, что он тянет аналитиков в прошлое. Так прямо и заявлено в одном выступлении на аналитич-фесте, а затем понабросано на нескольких площадках -- на хабре и далее везде. То есть технология, придуманная NASA-вскими разрабами надёжных программ для шаттлов (а именно они и создали Rational, а значит и RUP), не пускает аналитика в светлое будущее, где проги, с которыми ты вынужен обращаться в обиходе постоянно сбоят, и вместо этого отправляет в тёплое ламповое прошлое, когда надёжность обеспечивалась и за счёт процесса разработки, а не только лишь за счёт личных качеств исполнителей.