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

Может, ты и прав. Однако для чего нужно зарегистрировать заказ? наверное, чтобы его принять, а принять, чтобы выполнить, а выполнить, чтобы заработать денег, а заработать денег, чтобы жить, т.е. оплачивать и приобретать разные услуги, и т.д.

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

Клиенту, что нужно? Ему нужно переместиться из пункта А в пункт Б, возможно, быстро и с комфортом. Для этого он нанимает службу такси. Для службы такси это обслужить клиента. При описании бизнес-контекста мы должны указать внешние по отношению к службе сущности: клиент. Возможно сюда можно включить водителя, т.к. служба нанимает водителя, однако я считаю, полагаю, что водитель исполнитель, он внутри службы, он ее часть, значит я его не могу показать как внешняя сущность.

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

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

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

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

Согласен, однако в этом случае нужно описать эти предположения, либо в задании это явно указать. Цель выставления такого задания на суд общественности как раз в том, а нормальна ли такая формулировка и что в ней следует изменить.
Окей, какую деятельность автоматизирует система? Как по твоему нужно пеерефомулировать задачу?

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

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

Эд, запиши меня тоже в "непонявших" )
Без выстраивания бизнес-контекста твой "текстуальный анализ" выглядит так - "Дано: А и Б сидели на трубе. Найти: Сколько лет водителю автобуса?"

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

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

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

1. Эд, предлагаю называть диаграммой вариантов использования а не прецедентов (это в исходном задании) :-)
2. Для всех ... давайте отталкиваться от цели решения задачи. Как я понял, цель не в том, чтобы нафантазтровать кучу возможных ньюансов в бизнес-процессах, а в том, чтобы по бизнес-кейсу студент мог построить модель СИСТЕМНЫХ UC и аргументировать, почему модель именно такая. Оценка работы студента будет проводиться не на соответствие созданной им диаграммы с некой эталонной моделью (которую тут при обсуждении пытаются создать), а на то, как студент рассуждает, анализирует, делает предположения (и фиксирует их как предположения).
3. Качество исходной информации - на мой взгляд вполне нормальное для описанной в предыдущем пункте цели. В конце концов в реальном мире не всегда можно получить на вход ТАКОЕ описание. А скорее это будет уже плод "первичного" анализа.

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

Полностью поддерживаю ...

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

Вот в качестве иллюстрации для тех же студентов -- неплохая задумка -- показать BUC и SysUC и их разницу на КОНКРЕТНОМ примере. Пусть не идеальном, но тем не менее. Но думаю, что имеет смысл показывать переход по классике -- т.е. от модели BUC через из реализацию (с бизнес-вокерами) и к модели SysUC ... т.е. нарисовать 3 картинки.

Вот в качестве иллюстрации для тех же студентов -- неплохая задумка -- показать BUC и SysUC и их разницу на КОНКРЕТНОМ примере. Пусть не идеальном, но тем не менее. Но думаю, что имеет смысл показывать переход по классике -- т.е. от модели BUC через из реализацию (с бизнес-вокерами) и к модели SysUC ... т.е. нарисовать 3 картинки.

Юра, ты имеешь в виду уровень BUC, далее модель бизнес-объектов и уже далее модель SysUC?
Интересно, что будет на уровне BUC? Клиент, служба, водитель?

Может почтенная публика, пройдется (если ей это интересно) по каждому моменту диаграммы с указанием ошибки и аргументации почему здесь сделана ошибка?

Мне, кажется, это будет полезно и всем участникам дискуссии и посетителям сайта, которые заходят сюда в поисках ответов на свои вопросы

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

Прошу высказать Ваши замечания по варианту

Спасибо, Сергей, за интерес к задаче, потраченное время и проделанную "сумасшедшую" работу.

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

Понятная и справедлива твоя мысль по поводу: дано - известная информация, ответ - неизвестная информация.

Насчет условия задачи - это лишь пример возможной задачи на экзамене. Постановка действительно объемная, но почему это плохо? Одна и та же постановка будет встречаться в разных билетах, но с разными вопросами.

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

Отвечаю по порядку.

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

Принято. Единственное, почему следует считать ВИ - законченным действием? или почему следует все-таки использовать глаголы совершенного вида? Почему спрашиваю: дело в том, что в различных книгах существуют разные правила именования. У Лармана - отглагольные существительные, в других книгах - обязательно глагол, выражающий задачу пользователя.

2. можно было бы указать инициаторов каждого прецедента там, где несколько актеров.

А каким образом указывать инициаторов на диаграмме? Следует ли все-таки так скрупулезно относиться к диаграмме ВИ, если многие указывают на незначительную ее роль?

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

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

В школе и институте нас учили, что задача должна выглядеть так, как показано на первом приложенном рисунке. Должно быть ДАНО, должен быть ХОД РЕШЕНИЯ, должен быть ОТВЕТ.

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

В твоем, Эд, случае алгоритм не формализован, а суть задачи такова:
ИЗВЕСТНАЯ ИНФОРМАЦИЯ В ТЕКСТОВОМ ВИДЕ -> ИЗВЕСТНАЯ И ДОДУМАННАЯ ИНФОРМАЦИЯ В ГРАФИЧЕСКОМ ВИДЕ
На мой взгляд ценность второго подхода сомнительна.

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

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

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

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

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

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

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

Ты можешь привести свой ход решения?

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

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

Эд, не надо поклёпов - существительные не у Лармана, а у Шелестова (переводчика).

Обработка продажи (Process Sales)
...
Возврат товара (Handle Returns)
...

Вот такой корявый перевод.

Насчет условия задачи - это лишь пример возможной задачи на экзамене. Постановка действительно объемная, но почему это плохо? Одна и та же постановка будет встречаться в разных билетах, но с разными вопросами.

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

Эд, не надо поклёпов - существительные не у Лармана, а у Шелестова (переводчика).
Вот такой корявый перевод.

Дэн, не надо поклёпов на меня. Может это Шелестов такой плохой, однако:
стр. 120 (3-е издание) Шаг 4 Определение прецедентов. В рамке выделено:
"Как правило, имя прецедента начинается с существительного, описывающего действие"

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