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

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

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

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

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

Shur, спасибо. Ваши рассуждения понятны. Именно так и происходит.

Удивительно, что из этой моей задумки возникла такая плодотворная дискуссия. Надеюсь она оказалась полезной как ее участникам, так и наблюдателям.

Правда, я бы доработал немного вот эту фразу : "Второй диспетчер обеспечивает взаимодействие с водителями, например распределением заказов между водителями." Так как она может неоднозначно трактоваться.

Примерно так: "Второй диспетчер обеспечивает взаимодействие с водителями, например, распределяет заказы водителям на выполнение."?

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

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

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

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

Но вот какая мысль пришла мне в голову. Зачем изменять формулировку? Может изменить вопрос?
Нарисовать диаграмму вариантов использования (use case diagram) системы автоматизации работы службы диспетчерской такси.
Как Вы думаете, в этом случае достаточно было бы старой формулировки?

Если мы хотим ограничить систему именно обработкой заказов, то вопрос стоит сформулировать так: "Нарисовать диаграмму вариантов использования (use case diagram) системы автоматизации обработки заказов диспетчерской службой такси." Кроме того из формулировки надо выкинуть предложение о расчетах бухгалтерии с водителями на основании отчетов из системы. Так как данный отчет в такой формулировке не может содержать необходимой для расчетов информации. Количество выполненных заказов недостаточно. Один на 20-ти заказах заработал 100 рублей, а другой на одном заказе - 1000 рублей. Эта нелогичность будет запутывать студентов (особенно думающих студентов, которые до нее докопаются). А так как формулировка не содержит информации для ее разрешения, то скорее всего студент просто зря потеряет время и провалит экзамен. С другой стороны недумающий студент нарисует вариант использования "сформировать отчет по водителям" с актером-бухгалтером и будет формально прав. Но система работать не будет

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

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

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

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

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

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

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

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

, потому мой вопрос фурммулируется примерно так:
Построить диаграмму вариантов использования,

Хм, а разве можно построить ДВИ, не выполнив предварительно это:

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

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

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

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

Если мы хотим ограничить систему именно обработкой заказов, то вопрос стоит сформулировать так: "Нарисовать диаграмму вариантов использования (use case diagram) системы автоматизации обработки заказов диспетчерской службой такси." Кроме того из формулировки надо выкинуть предложение о расчетах бухгалтерии с водителями на основании отчетов из системы.

А зачем что-то выкидывать. Если цель - проверка умения студента выделить главное в соответствии с заданным вопросом, то он сам должен убрать бухгалтерию. Тем более если вдуматься, бухгалтерия тут может рассматриваться как система-актор, а никак основное действующее лицо. Можно наверное добавить, что информация о выполненных заказах передается в бухгалтерскую систему - например 1 С.

Мне импонирует подход Boatmana и комментарии Shur, просто в таком виде задачу решать в условиях экзамена сложно, особенно если она не одна.

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

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

Не вопрос. Просто формулировка задания вида "Нарисовать ДВИ, выполнив то-то" подразумевает, что основная задача - нарисовать, а все остальное второстепенно (в смысле требуемого результата). Наверное, правильнее формулировать "Выполнить то-то и нарисовать ДВИ".

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

Я пытался показать, что в такой формулировке задачи заложено противоречие:
Для расчетов с водителями бухгалтерия должна получить данные о выполненной водителями работе. Количество выполненных заказов не является достаточным мерилом работы водителей. Наиболее точным мерилом работы была бы выручка, полученная водителем. В условии задачи не описано, как в систему попадает информация о выручке.
Это противоречие я и пытался устранить. В одном случае добавлением в условие задачи расчета выручки по данным из ГИС, в другом случае - убиранием из условия необходимости расчетов на основании данных из системы.