Хочу начать цикл задач по различным UML диаграммам.

Лучший способ обучения, делать и обсуждать, получая рефлексию.

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

Возможный результат построения диаграммы вариантов использования

зря вы пропустили актора Водитель

ps: и ещё в примерах имхо лучше приаттачивать и файл в формате, например, ms visio, чтоб можно было править и выставлять свой вариант.

Григорий, критикуйте по существу и вносите свои изменения и аргументы

Программу я Вам могу скинуть. Если что!

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

зря вы пропустили актора Водитель

Из контеста задачи никак не следует, что водитель что-то делает с системой. Он взаимодействует со вторым диспетчером

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

В этом случае можно было бы написать так:
Участник - Интересы
1.Служба такси - предоставить услуги по пассажирским перевозкам; заключить договор с водителем личного транспорта проблем с заказом

2. Первый диспетчер - принять заказ, принять предварительный заказ; записать дополнительные данные о клиенте; получить денежные выплаты за принятые заказы

3. Второй диспетчер - распределить заказы; определять оптимальный маршрут; работать с водителями; фиксировать факты; получить денежные выплаты за принятые заказы (распределнные заказы)


4. Водитель - получить заказ, получить оптимальный маршрут, выполнить заказа, ожидать заказ (на стоянке), заключить договор, отчитаться о выполнении заказа, получить денежные выплаты за осуществленные заказы

5. Клиент - сделать заказ (в том числе и предварительный), сообщить доп информацию, получить скидку, ехать

6. Бухгалтерия - анализировать отчеты, начислить з/п водителям и диспетчерам

7. ГИС - геоинформационная система - рассчитать оптимальный маршрут по заданным критериям

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

Клиент взаимодействует с первым диспетчером, а не с системой

Водитель взаимодействует со вторым диспетчером и возможно с бухгалтерией сдавая отчеты о выполенении ( в описание этого нет - но можно додумать)

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

Второй диспетчер - передать заказ водителю, принимать сведения о проблемах заказа, формировать черный список, рассчитывать оптимальный маршрут используя ГИС, возможно принимать отчеты о выполнении заказа (фиксировать выполнение и сумму)

Бухгалтерия - анализировать отчеты выполнения и принятия, начислять выплаты

Клиента и водителя я бы добавил, ибо описывать имхо надо для понимания бизнеса

1. Клиент сегодня звонит диспетчеру, а завтра создает заказы по web и ему перезванивает диспетчер; или участвует в ведении статистики по уровню обслуживания
2. Водитель может вести черный список, уведомлять своё текущее месторасположение и факт освобождения ... сегодня он звонит, завтра сбрасывает по мобильнику данные

И, имхо надо быть реальнее:
'ГИС определяет маршрут для диспетчера' - много не реального, аварии, пробки, изменение местонахождения водителя и т.п. -> реальнее водитель определяет и уведомляет о примерном_времени_прибытия_на_место или факте_прибытия

ps: опять же Вы разрабатываете реальную задачу? анализ уже провели или теоритезируете?

Клиента и водителя я бы добавил, ибо описывать имхо надо для понимания бизнеса

А вот тут Вы, Григорий, ошибаетесь, впадая в типичную ошибку смешивания точек зрения.

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

1. Клиент сегодня звонит диспетчеру, а завтра создает заказы по web и ему перезванивает диспетчер; или участвует в ведении статистики по уровню обслуживания

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

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

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

И, имхо надо быть реальнее:
'ГИС определяет маршрут для диспетчера' - много не реального, аварии, пробки, изменение местонахождения водителя и т.п. -> реальнее водитель определяет и уведомляет о примерном_времени_прибытия_на_место или факте_прибытия

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

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

ps: опять же Вы разрабатываете реальную задачу? анализ уже провели или теоритезируете?

Это учебная задача. Ни теория, ни практика. А просто пример возможного анализа, ошибок анализа, хода анализа и результата анализа. задачи выдаются в данном случае студентам
Однако постановка имеет под собой реальную первооснову, но упрощена в целях учебных (не мной )

это упрощение настораживает, сразу вспоминается о слоне и мудрецах.

Galogen, вы лично, сталкивались с работой диспетчерской-то?

ps: теория без практики мертва

Соглашусь с Эдом по поводу двух точек зрения.

Григорий,
Для того чтобы правильно построить ДВИ надо определить scope, т.е. в каком мире/масштабе работаем.
Если берем масштаб бизнеса, то да Клиента и Водитель must be.
Если берем Систему (т.е. происходит взаимодействие Актеров с СИСТЕМОЙ), то водителя убираем, т.к. он НЕ взаимодействует с ней.

отталкиываться надо от заказчика, инакче вы делает нечто для себя.

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

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

Григорий, не все слишком серьезно.

Мы рассматриваем некий образец задания, примера, на базе которого развертывается проверка знаний и умений. Это не реальная задача. Однако таковой может вполне стать. Тем не менее, использования задания на экзамене, в тестовых заданиях или на практических заданиях предполагает:
1. проверку навыков и умений проводить текстуальный анализ. Отталкиваться от текста впервую очередь.
2. делать предположения, но не фантазировать
3. осуществлять построение диаграммы вариантов использования, при этом выделять заинтересованные стороны и пользователей системы, определять задачи, которые выполняют эти пользователи.

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

не отобрадая варианты вы отрезаете от имения_в_виду этих возможностей или варианций возможностей ..

никто и не спорит, предложите Ваш вариант, обсудим.

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

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

Наград не будет, зато будет общественное мнение

Если берем масштаб бизнеса, то да Клиента и Водитель must be.
Если берем Систему (т.е. происходит взаимодействие Актеров с СИСТЕМОЙ), то водителя убираем, т.к. он НЕ взаимодействует с ней.

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

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

Конечно, результат может быть иным. Например, при использовании ГИС - она может мигрировать и за рамки службы такси

Рисунок:

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

А вообще очень странно, что ты начал работу не с контекстной диаграммы бизнеса и не с бизнес-сценариев - видно по обсуждениям, как это помешало эффективной работе. Опять же отсутствие диаграммы классов предметной области смущает, я бы на неё опирался для рисования UC.

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

Эд, что значит "в задаче сказано", "в задаче не сказано"? Если условий не хватает, то типовая деятельность модельера - достроить недостающие условия, зафиксировать их в качестве предположения и работать от них.

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

Григорий, не все слишком серьезно.

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

Эд, запиши меня тоже в "непонявших" )

Без выстраивания бизнес-контекста твой "текстуальный анализ" выглядит так - "Дано: А и Б сидели на трубе. Найти: Сколько лет водителю автобуса?"