Главный вопрос при составлении задач, который надо держать в голове - это критерии оценки ответа.
Какую оценку вы бы поставили Boatman-у на экзамене за его диаграмму?

Я бы предложил ему место на кафедре

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

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

А если другой студент не укажет на диаграмме регистрацию договора с водителем, то ему оценка будет меньше или такая же? Почему?

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

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

тогда это будет уж совершенно бессмысленно, чистая механическая работа?

Если это задача на анализ - то я с трудом представляю себе ее в рамках экзамена.

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

В тему - глава "О пользе чертежей" из нового курса "Визуальное моделирование: теория и практика": http://www.intuit.ru/department/se/vismodtp/1/

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

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

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

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

Вывод - лучше ничего не спрашивать на экзамене у бедных студентов

Служба такси предоставляет услуги по пассажирским перевозкам. Служба не имеет собственного таксопарка, а работает по договору с водителями, имеющими личный автомобиль. Каждый водитель имеет свой позывной и график работы. Служба имеет несколько точек-стоянок по городу, на которых водитель может дожидаться поступления близлежащего заказа.
С системой работает два диспетчера. Первый диспетчер занимается приемом заказов, второй распределением заказов между водителями. При приеме заказов клиент сообщает свое текущее местонахождение и телефон, а также адрес назначения. Фиксируется время приема заказа, а также время его выполнения. Для определения оптимального маршрута по городу используется геоинформационная система. Клиент может сделать предварительный заказ, т.е. заказать такси в определенное место к определенному времени.
Клиент идентифицируется номером телефона. Система хранит информацию о заказах клиента и вычисляет его рейтинг, что позволяет клиенту со временем получать накопительную скидку. При желании клиент может сообщить о себе дополнительную информацию (ФИО, другие телефоны и т.п.), что позволит его более точно идентифицировать. Если с заказом были какие-либо проблемы (ложный вызов, неоплата и т.п.), этот факт фиксируется, и телефон заносится в черный список.
Бухгалтерия анализирует отчеты о заказах, выполненных каждым водителем, и на основании их проводит денежные расчеты с водителями. Аналогично, заработная плата диспетчеров зависит от количества принятых заказов. Система также должна обеспечивать отчеты о заказах, выполненных за период времени, выполненных конкретным водителем и заказах конкретного клиента.
Нарисовать диаграмму прецедентов (use case diagram) системы автоматизации работы службы такси.

Примерный ход анализа ala Galogen

Выделяем глагольные фразы и переводим их в инфинитивы
ГФ001 Предоставлять услуги по пассажирским перевозкам
ГФ002 Работать по договору
ГФ003 Дожидаться поступления заказа
ГФ004 Принимать заказы
ГФ005 Распределять заказы
ГФ006 Сообщать местонахождение, телефон и адрес назначения
ГФ007 Фиксировать время приема заказа
ГФ008 Фиксировать время выполнения заказа
ГФ009 Оптимизировать маршрут с помощью ГИС
ГФ010 Сделать предварительный заказа
ГФ011 Идентифицировать клиента по номеру телефона
ГФ012 Хранить информацию о заказах клиента
ГФ013 Вычислять рейтинг клиента
ГФ014 Получать накопительную скидку
ГФ015 Сообщить дополнительную информацию о себе
ГФ016 Фиксировать проблемы с вызовом
ГФ017 Занести в черный список
ГФ018 Анализировать отчеты о выполнении заказов водителем
ГФ019 Производить денежные выплаты по выполненным заказам водителю
ГФ020 Обеспечить (предоставить) отчеты о заказах по заданным критериям: выполненные за период времени, выполненные конкретным водителем, сделанных конкретным клиентом
ГФ021 (предположительно) Производить денежные выплаты диспетчеру в зависимости от количества принятых заказов.

Выделяем действующих лиц
ДЛ1 Служба такси
ДЛ2 Водитель
ДЛ3 Диспетчер 1
ДЛ4 Диспетчер 2
ДЛ5 Клиент
ДЛ6 SUD - система автоматизации деятельности
ДЛ7 Бухгалтерия

Связи:
ДЛ1  ГФ001

ДЛ2 ГФ002, ГФ003, ГФ009(?)

ДЛ3 ГФ004,

ДЛ4 ГФ005, ГФ007, ГФ008, ГФ009(?), ГФ016, ГФ017

ДЛ5 ГФ006, ГФ010, ГФ014, ГФ015

ДЛ6 ГФ011,ГФ012, ГФ013

ДЛ7 ГФ018-ГФ021

Рассматриваемый уровень для построения диаграммы вариантов использования (прецедентов) SUD, сюда включаю
регистрацию заказов (в моем случае я определил как принять заказ, подразумевая именно факт ввода данных по новому заказу в систему) - связано с ГФ004, 006, 010 - 015

передачу заказа водителю (определил как распределить заказы + оптимизировать мрашрут)- связано с ГФ005, ГФ007, ГФ009

фиксацию факта выполнения - связано с ГФ008
фиксацию факта не выполнения или
фиксацию проблемы с указанием причины и занесением в черный список - связано с ГФ016-017 - (зарегистрировать выполнение заказа

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

В результате (как правильно заметил Boatman) мысленного, не фиксируемого анализа - и кстати гораздо быстрее, чем это заняло написание - была построена модель поста №1, которая потом несколько эволюционировала

Ты считаешь, что каждый ГФ должен автоматически превращаться в ВИ?
Можно детализировать ход рассуждений там, где происходит переход список ГФ -> список ВИ.

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

ГФ001 - это общая цель службы такси или ее миссия. Это может быть БВИ на контекстной диаграмме

ГФ002 и ГФ003 - я оставил вне рамок автоматизации работы службы на данном уровне рассмотрения. Действительно с одной стороны клиенты - т.е. покупатели услуги, с другой стороны водители - поставщики услуги, между сосбственно диспетчерская служба - магазин услуг перевозок: она покупает услугу у водителя и перепродает ее клиенту. Выгода достигается за счет организации, централизации, уменьшения накладных расходов и т.п.

ГФ004, 006, 010-015 - все эти функции (или глагольные фразы) в целом участвуют в ВИ принять заказа, который по рекомендации тебя, Юры и Дениса(1) нужно сделать системным зарегистрировать заказ. здесь возможно еще можно добавить управление клиентами(ввод, изменения, удаления)

ГФ005, 007 - распределить заказ, или зарегистрировать прием заказа водителем

ГФ009 - я бы вообще исключил пока из рассмотрения, поскольку это будет возможно не функция системы.

ГФ008, 016-017 - зарегистрировать выполнение заказа

ГФ019 и ГФ021 - функции бухгалтера, функция системы будет вероятно произвести расчет денежных начислений за указанный период по указанному водителю или диспетчеру

ГФ018 и ГФ020 - будет скорее всего трансформироваться во что-то типа сформировать (предоставить) отчет

Я бы еще добавил нечто вроде управление водителями (ввод, изменение, удаление) и диспетчерами-сотрудниками

тогда это будет уж совершенно бессмысленно, чистая механическая работа?

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

Да в таком виде безусловно. Однако решая задачу (по химии или физике), разве Вы не анализируете условия, не ищите формулы и решение?

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

Ну почему, эта работа требует умения анализировать описание в свободном формате и выделять из него ВИ, понимания смысла и принципов построения ДВИ. Разве этого мало?

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

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

Все-таки сравнение не корректно. В данном случае перевод - это и есть цель. Проверяется правильность и корректность перевода, правила перевода и т.п. При этом семантическая ценность обоих текстов по идее должна быть равнозначная. А при построении ДВИ такой равнозначности нет. Что получиться, если попытаться имея ДВИ написать постановку? Да мало чего, разве что общие рамки, участников и их задачи.

Хотя я, конечно, предполагал, что при построении ДВИ нужно учитывать только ту информацию, которая есть и которую можно вывести из описания. Но вероятно следует давать более жесткую формулировку задачи. Вот какую Вы сами могли бы предложить в таком случае? Можете написать?

Вот какую Вы сами могли бы предложить в таком случае? Можете написать?

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

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

Спасибо A_K. Интересные изменения.

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

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

вот это: "По информации о длине маршрута система расчитывает стоимость проезда, которая сообщается водителю." это уже усложнение imho. Проще использовать счетчики.  Правда это не хуже фразы, что используется ГИС для оптимизации маршрута. Поскольку трактовать ее можно по-разному. ГИС - может быть совершенно независимым приложением, который использует диспетчер или водитель. Может существовать и явное взаимодействие разрабатываемой нами системы и ГИС через некий интерфейс, через который наша система передает отправную точку и пункт назначения, а получает некий оптимальный маршрут. Вообще я бы в данном случае ГИС бы выкинул, или оставил бы как некую ловушку усилив фразу типа: диспетчер использует ГИС города для расчета оптимального маршрута.

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

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

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

Чтобы дискуссия продолжилась и в другом направлении, посмотрите, пожалуйста, вот в этом направлении, там я публиковал пример билета, которые я лично формулировал и предлагал студентам на экзамене:
http://www.uml2.ru/forum/index.php?topic=137.msg6537#msg6537 (тот что по ОООА)

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

...Я все больше убеждаюсь, что ДВИ малозначима.

ИМХО ДВИ малозначима для описания алгоритмов в виде, достаточно подробном и удобном для кодирования (выше Boatman также указывал на малую информативность ДВИ). Не случайно в средах разработки, допускающих автоматическую генерацию кода по диаграммам, ДВИ и диаграмма деятельности никак не используются для генерации кода.
Но ДВИ, например, может быть очень важной отправной точкой для общения с Заказчиком. Этот момент, к сожалению, в обсуждениях на форуме не всегда ярко проявляется именно вследствие высокого профессионализма участников обсуждения, а также, возможно, малого количества "практикующих Заказчиков" среди обсуждающих. Но даже в этом обсуждении консенсус по поводу общего представления о системе был достигнут не сразу: Денис указал на то, что заказ к клиента принимает не система, а диспетчер. А контекстная диаграмма Воаtman позволила сразу наглядно представить и рамки бизнес-уровня и уровень системы.
1. При общении с заказчиком, который не испытывает потребности в явном описании/проговаривании логики своей работы, ДВИ, как правило, весьма полезна. Бывает, что нужно сначала договориться - мы для целей создания системы считаем, что земля круглая или достаточно будет считать, что она плоская и даже не пытаться развеивать заблуждения закзачика о том, что она стоит на четырех слонах .
В этом смысле ДВИ как минимум отражает топологию взаимодействия действующих/заинтересованных лиц. А топология может оказаться разной для разных способов организации бизнеса (чем он сложнее, тем, как правило, больше возможных вариантов организации взаимодействия).
2. Более того, изображение вариантов использования в виде эллипсов без детализации как бы инкапсулирует всю сложность внутреннего устройства варианта с точки зрения его использования действующим лицом, которое, возможно не понимает (и не должно) понимать всей сложности процессов, которые этот ВИ реализуют. Ведь если воспользоваться параллелями с инженерными дисциплинами, на которые указывал выше Boatman, автомобили-иномарки удобнее в использовании, чем отечественные, хоти и устроены сложнее с точки зрения изготовления и ремонта. Конструктор знаменитого автомата Калашников говорил, что он всю жизнь руководствовался афоризмом одного известного богослова: "Все нужное просто, всё сложное - не нужно...". Жизнь правда требует уточнения: системы должны быть не сколько простыми в изготовлении, как АКМ или Запорожец, сколько просты в использовании. И простота, понятность вариантов использования по идее являются залогом выского уровня юзабилити.

Спасибо Shur за высказывание. Ваши замечание ценны.

Дискуссия весьма полезна.

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

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

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

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

Здесь я вижу большую аналогия ДВИ и DFD диаграммы, где в качестве внешних сущностей следует указывать тех кто поставляет информацию в систему и получает их из системы. Ясно, что с точки зрения клиента или водителя - диспетчер некий компонент системы. У клиента четкая задача : разместить заказа, у водителя: получить заказа, отчитаться о выполнении/невыполнении.

Очень похожая ситуация у Лармана в Применении UML, где есть покупатель и кассир, которые взаимодействуют в процессе варината использоание Оформление продажи. На стр. 123 (3-е русское издание) он на фрагменте ДВИ показывает и покупателя, помечая что кассир исполнитель. Мне это не понятно, так как рассогласуется с его же словами и словами Рамбо и Блаха в книге UML2.0 ОО разработка и моделирование.

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

Дело в том, что с похожей интерпретацией я встречаюсь на защите курсовых и дипломных, когда после показания бизнес-контектса с помощью DFD, строиться DFD системных процессов, в которой ровно все внешние сущности показаны. Я задаю вопрос - а вот эта показанная вами сущность взаимодействует с проектируемой Вами ИС и каким образом. В результате оказывается, что вовсе нет.
К примеру система учета прохождения исполнительного листа в неком госучреждении при судебном органе. Студент показывает в бизнес-контексте как и по каким инстанциями проходит исполнительный лист. Далее изображает системные процессы ИС учета, в которой например налоговая инспекция получает отчет о сумме исполнительного листа. Я спрашиваю, что налоговая инспекция имеет доступ в систему и получает возможность простмотра и получения таких отчетов. Оказывается нет, просто пользователь системы готовит такой отчет для налоговой инспекции и отправляет установленным порядком в бумажном виде или по email. Понятны мои логические блуждания?

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

Вполне вероятно, такая формулировка тоже не очень корректна.

Shur, может быть Вы поможете развеять мои заблуждения?

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

имхо описывая бизнес (задачу) надо в той или иной мере описать все аспекты; более значимые более глубоко и полно.

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

О, Григорий вернулся. Привет, Григорий!

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

Понимаете Григорий, от ДВИ одной мало проку как бизнес-worker, так и разработчику. ДВИ частичка общего артефакта use case model с ней она и должна конечно существовать.

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

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

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

1. Понимаете Григорий, от ДВИ одной мало проку как бизнес-worker, так и разработчику.
2. В реальной практики никто рисовать просто ДВИ не будет, для разных уровней можно выстроить разные ДВИ. Все равно основой будет текст, возможно диаграммы видов деятельности.
3. Просто сразу вспомнил наших тетушек из отдела кадров...
4. Меня раздражает то  факт, что все трактуют правила построения по-разному. Но они то должны быть одни

1. одной возможно, мало и нет - но есть
2. будет текст, пояснение ... но поянять надо то что есть
3. и? я вспомнил техдиректора, который всегда говорит - 'мне лучше увидеть, что <клиент> есть, мы знаем о его существовании (как actor), но он не работает с программой ... зато видим, что он общается с <диспетчер> и они вместе осуществяют <оформление заказа>
4. не надо раздражаться, жизнь не пазл

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

Для целей именно использования системы, возможно, водитель и клиент не должны показываться на «системном уровне» если под «системой» понимать исключительно компьютер. Если же под системой понимать всю компанию такси, элементы которой образует системно организованный бизнес, то без этих лиц не обойтись. В конце концов программная система делается для решения задач бизнес-системы.
В частности, в постановке задаче нигде не сказано, что система должна учитывать интересы клиента и в этом смысле она ничем не отличается от постановки задачи перевозки грузов, решение о транспортировке которых принимает сам диспетчер. В жизни же (на бизнес уровне) приходится учитывать, что не только компания-перевозчик выставляет рейтинги клиентам, но и клиенты выставляют рейтинги компаниям. В городах с населением несколько десятков тысяч жителей, как правило, существует не одна компания такси и нужно выживать в конкурентной борьбе. Поэтому система должна «затачиваться» не только под диспетчера – «экспедитора живого товара», но и под интересы живых пассажиров, для которых, например, может быть критично, насколько оперативно подается машина и тогда нужно выставлять рейтинги не только клиентам, но и водителям, вести статистику времени выполнения заказов, жалоб клиентов и отказываться от услуг водителей с чересчур медленными и часто ломающимися машинами. Задача качественного обслуживания неизбежно потребует учета характеристик заказа клиента – срочности, междугородней поездки, которая может потребовать дополнительных приготовлений от водителя, и пр.  Эти характеристики и свойства могут быть правильно поняты только из бизнес-уровня, соответствующего рамке «Служба такси» на контекстной диаграмме Boatman.
Аналогично с водителем – у него есть очень конкретный вариант использования на бизнес уровне: как минимум оплатить услуги диспетчера.

...К примеру система учета прохождения исполнительного листа в неком госучреждении при судебном органе. Студент показывает в бизнес-контексте как и по каким инстанциями проходит исполнительный лист. Далее изображает системные процессы ИС учета, в которой например налоговая инспекция получает отчет о сумме исполнительного листа. Я спрашиваю, что налоговая инспекция имеет доступ в систему и получает возможность простмотра и получения таких отчетов. Оказывается нет, просто пользователь системы готовит такой отчет для налоговой инспекции и отправляет установленным порядком в бумажном виде или по email. Понятны мои логические блуждания?

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

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

Вполне вероятно, такая формулировка тоже не очень корректна.

Shur, может быть Вы поможете развеять мои заблуждения?

Может быть стоит предлагать студентам строить ДВИ, соответствующие различным уровням описания системы (уровень бизнеса и уровень «системы»)?
А высший пилотаж – это если они еще и покажут как эти уровни ДВИ взаимодействут между собой (типа  контекстной диаграммы Boatman).