Форум Сообщества Аналитиков
Общий раздел => Примеры => Тема начата: Galogen от 27 Декабря 2007, 11:57:20
-
Хочу начать цикл задач по различным UML диаграммам.
Лучший способ обучения, делать и обсуждать, получая рефлексию.
Задача 1.
Требуется разработать модель программной системы автоматизации работы службы такси.
Служба такси предоставляет услуги по пассажирским перевозкам. Служба не имеет собственного таксопарка, а работает по договору с водителями, имеющими личный автомобиль. Каждый водитель имеет свой позывной и график работы. Служба имеет несколько точек-стоянок по городу, на которых водитель может дожидаться поступления близлежащего заказа.
С системой работает два диспетчера. Первый диспетчер занимается приемом заказов, второй распределением заказов между водителями. При приеме заказов клиент сообщает свое текущее местонахождение и телефон, а также адрес назначения. Фиксируется время приема заказа, а также время его выполнения. Для определения оптимального маршрута по городу используется геоинформационная система. Клиент может сделать предварительный заказ, т.е. заказать такси в определенное место к определенному времени.
Клиент идентифицируется номером телефона. Система хранит информацию о заказах клиента и вычисляет его рейтинг, что позволяет клиенту со временем получать накопительную скидку. При желании клиент может сообщить о себе дополнительную информацию (ФИО, другие телефоны и т.п.), что позволит его более точно идентифицировать. Если с заказом были какие-либо проблемы (ложный вызов, неоплата и т.п.), этот факт фиксируется, и телефон заносится в черный список.
Бухгалтерия анализирует отчеты о заказах, выполненных каждым водителем, и на основании их проводит денежные расчеты с водителями. Аналогично, заработная плата диспетчеров зависит от количества принятых заказов. Система также должна обеспечивать отчеты о заказах, выполненных за период времени, выполненных конкретным водителем и заказах конкретного клиента.
Нарисовать диаграмму прецедентов (use case diagram) системы автоматизации работы службы такси.
Возможный результат построения диаграммы вариантов использования
(http://www.isuct.ru/~ivt/foruml2/ticket1.jpg)
-
зря вы пропустили актора Водитель
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.
Если берем Систему (т.е. происходит взаимодействие Актеров с СИСТЕМОЙ), то водителя убираем, т.к. он НЕ взаимодействует с ней.
Тут в задаче явно, конечно, не сказано, какой уровень следует рассматривать.
Хотя неявно условие задачи склоняет нас именно к уровню систему учета заказов, их распределения и выполнения + охватывается уровень бухгалтерии
-
Вот попытался построить модель охватив разные точки зрения, кое-что исправив попутно.
Конечно, результат может быть иным. Например, при использовании ГИС - она может мигрировать и за рамки службы такси
Рисунок:
(http://www.isuct.ru/~ivt/foruml2/anyview.jpg)
-
Эд, я думаю-таки, что "Принять заказ" - это прецедент, который отрабатывается Диспетчером во взаимодействии с Клиентом, а не Системой. Во взаимодействии с Системой он может только "Зарегистрировать заказ".
А вообще очень странно, что ты начал работу не с контекстной диаграммы бизнеса и не с бизнес-сценариев - видно по обсуждениям, как это помешало эффективной работе. Опять же отсутствие диаграммы классов предметной области смущает, я бы на неё опирался для рисования UC.
-
Тут в задаче явно, конечно, не сказано, какой уровень следует рассматривать.
Хотя неявно условие задачи склоняет нас именно к уровню систему учета заказов, их распределения и выполнения + охватывается уровень бухгалтерии
Эд, что значит "в задаче сказано", "в задаче не сказано"? Если условий не хватает, то типовая деятельность модельера - достроить недостающие условия, зафиксировать их в качестве предположения и работать от них.
Ни одна система не висит в воздухе, она автоматизирует какую-то деятельность. Какую деятельность? Можешь ли ты, не понимая этой деятельности, строить систему? Можешь, но это будет конь в вакууме (а не хотя бы в пространстве обоснованных предположений). Чем определяются свойства системы? Надсистемой.
-
Григорий, не все слишком серьезно. :)
Мы рассматриваем некий образец задания.... который.... предполагает:
1. проверку навыков и умений проводить текстуальный анализ. Отталкиваться от текста впервую очередь.
2. делать предположения, но не фантазировать
3. осуществлять построение диаграммы вариантов использования, при этом выделять заинтересованные стороны и пользователей системы, определять задачи, которые выполняют эти пользователи.
...
Вы не поняли назначение поста.
Назначение такое: есть описание задачи - такое какое есть - Вы не в силах его изменить, уточнить, добавить: вы отталкиваетесь от того, что есть.
Эд, запиши меня тоже в "непонявших" )
Без выстраивания бизнес-контекста твой "текстуальный анализ" выглядит так - "Дано: А и Б сидели на трубе. Найти: Сколько лет водителю автобуса?" :)
-
Эд, я думаю-таки, что "Принять заказ" - это прецедент, который отрабатывается Диспетчером во взаимодействии с Клиентом, а не Системой. Во взаимодействии с Системой он может только "Зарегистрировать заказ".
Может, ты и прав. Однако для чего нужно зарегистрировать заказ? наверное, чтобы его принять, а принять, чтобы выполнить, а выполнить, чтобы заработать денег, а заработать денег, чтобы жить, т.е. оплачивать и приобретать разные услуги, и т.д.
Клиент вне всякого сомнения участник процесса, оданко я его могу показать при описании варианта использования в области участники и интересы, или в триггере - поступил звонок от потенциального клиента.
Клиенту, что нужно? Ему нужно переместиться из пункта А в пункт Б, возможно, быстро и с комфортом. Для этого он нанимает службу такси. Для службы такси это обслужить клиента. При описании бизнес-контекста мы должны указать внешние по отношению к службе сущности: клиент. Возможно сюда можно включить водителя, т.к. служба нанимает водителя, однако я считаю, полагаю, что водитель исполнитель, он внутри службы, он ее часть, значит я его не могу показать как внешняя сущность.
Конечно, можно предположить что в данном случае служба такси - это теолько диспетчерская служба, тогда водитель вне ее. Варианты есть. Я сделал свой...
А вообще очень странно, что ты начал работу не с контекстной диаграммы бизнеса и не с бизнес-сценариев - видно по обсуждениям, как это помешало эффективной работе. Опять же отсутствие диаграммы классов предметной области смущает, я бы на неё опирался для рисования 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 Определение прецедентов. В рамке выделено:
"Как правило, имя прецедента начинается с существительного, описывающего действие"
Поскольку оригинала у меня нет, качество перевода сравнить трудно, как и узнать не добавлена ли эта фраза Шелестовым.
-
Главный вопрос при составлении задач, который надо держать в голове - это критерии оценки ответа.
Какую оценку вы бы поставили 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).
-
В реальной практики никто рисовать просто ДВИ не будет, для разных уровней можно выстроить разные ДВИ. Все равно основой будет текст, возможно диаграммы видов деятельности.
Тексты-то тоже разные для разных уровней. ИМХО существует задача превращения представлений "бизнес-уровня" в представления уровня "компьютерной системы". Если система создается коллективом с разделением ролей на разработчиков и бизнес-аналитиков, именно эта проблема может быть главным камнем преткновения. Использование системы нотаций, в которой свободно ориентируются и те и другие, частично облегчает эту задачу. Но все равно остается проблема доведения описания бизнеса до уровня, на котором дальнейшая проектная работа должны "подхватываться" разработчиками и проделанная бизнес-аналитиком работа должна реально облегчать работу разработчикам. И "сращивание" описаний разных уровней, соответствующих разным практикам, разным мышлениям, разным предметным специализациям (Заказчика и разработчиков) - это на самом деле "великое чудо маниту" для каждого конкретного проекта. Мне в этом плане очень понравилась контекстная диаграмма Boatman. Правда для больших проектов такая "многоуровневая диаграмма" иногда получается очень громоздкой, приходится "разводить" представления для разных уровней по разным диаграммам. Тогда могут возникать проблемы на стыке двух уровней.
Я себе очень слабо представляю, как данная диаграмма будет показываться диспетчеру. Просто сразу вспомнил наших тетушек из отдела кадров. Они на тебя смотрят так ласково и говорят: Милок, да не показывай ты нам ничего, все равно мы в твоих картинках ничего не понимаем, ты нам сделай, чтобы удобно и просто работать было, да научи. И учти мы тебя спрашивать будем пока не разберемся.
Меня раздражает то факт, что все трактуют правила построения по-разному. Но они то должны быть одни
ДВИ нужно обсуждать с Заказчиком если мы собираемся "вынимать" из него экспертные знания по его предметной области. Если же он экспертом в данной области не является (а он им не может являться если не обладает хоть в какой-то мере формализованными представления о предметной области) то надо брать экспертизу со стороны или вообще не делать систему, а купить ему готовое решение с инструкцией по нажатию нужных кнопок. Если же Заказчик хоть чуть-чуть эксперт, то схема с эллипсами и человечками ИМХО - в самый раз для начала разговора. :) Надо только начинать разговор не со схемы а с обсуждения его конкретной работы типа: " вот Вы берете этот документ так? несете его директору так? ну, хорошо, бухгалтеру так? вот. Я на картинке это нарисовал, вот Вы, вот бухгалтер, так правильно да?". И дальше в таком же стиле: "за маму, за папу..." это мучительно, но неизбежно...:).
-
Shur, спасибо. Ваши рассуждения понятны. Именно так и происходит.
Удивительно, что из этой моей задумки возникла такая плодотворная дискуссия. Надеюсь она оказалась полезной как ее участникам, так и наблюдателям.
-
Правда, я бы доработал немного вот эту фразу : "Второй диспетчер обеспечивает взаимодействие с водителями, например распределением заказов между водителями." Так как она может неоднозначно трактоваться.
Примерно так: "Второй диспетчер обеспечивает взаимодействие с водителями, например, распределяет заказы водителям на выполнение."?
фраза: "Договор с водителем оформляет бухгалтерия", кажется мне несколько искуственной. Все-таки не дело это бухгалтерии принимать и оформлять договоры. Но пусть будет, для неувеличения сложности.
Во многих мелких фирмах невыгодно иметь отдельного кадровика, и его функции зачастую выполняет бухгалтерия.
вот это: "По информации о длине маршрута система расчитывает стоимость проезда, которая сообщается водителю." это уже усложнение imho. Проще использовать счетчики.
Естественно, это добавление надуманное. Но оно не усложняет задачу, а упрощает. Так как со счетчиками добавляется куча вопросов. Как бухгалтерия узнает выручку по заказам? Надо организовывать процесс сбора и ввода в систему информации со счетчиков. Как сопоставлять информацию со счетчиков заказам, существующим в системе?
Но вот какая мысль пришла мне в голову. Зачем изменять формулировку? Может изменить вопрос?
Нарисовать диаграмму вариантов использования (use case diagram) системы автоматизации работы службы диспетчерской такси.
Как Вы думаете, в этом случае достаточно было бы старой формулировки?
Если мы хотим ограничить систему именно обработкой заказов, то вопрос стоит сформулировать так: "Нарисовать диаграмму вариантов использования (use case diagram) системы автоматизации обработки заказов диспетчерской службой такси." Кроме того из формулировки надо выкинуть предложение о расчетах бухгалтерии с водителями на основании отчетов из системы. Так как данный отчет в такой формулировке не может содержать необходимой для расчетов информации. Количество выполненных заказов недостаточно. Один на 20-ти заказах заработал 100 рублей, а другой на одном заказе - 1000 рублей. Эта нелогичность будет запутывать студентов (особенно думающих студентов, которые до нее докопаются). А так как формулировка не содержит информации для ее разрешения, то скорее всего студент просто зря потеряет время и провалит экзамен. С другой стороны недумающий студент нарисует вариант использования "сформировать отчет по водителям" с актером-бухгалтером и будет формально прав. Но система работать не будет :)
Тут вопрос о границе очень важен. Смотрите, имеет ли смысл вносить бухгалтерию в службу такси? Если понимать под службой такси, именно, получение заказа и его выполнение? Не является в данном контексте бухгалтерия лишней и той ловушкой, по которой будут проверяться студенты?
Согласен. Вопрос о границе первостепенен. Но, как я показал выше, в данной формулировке его нельзя решить. Упомянутый отчет автоматически вводит бухгалтерию в круг пользователей системы. А указанная цель формирования отчета автоматически требует наличия в системе информации о выручке в разбивке по водителям. Откуда эта информация в системе должна появляться - неясно. А ловушки хороши, если из них можно выбраться :) Если заменить предложение "Бухгалтерия анализирует отчеты о заказах, выполненных каждым водителем, и на основании их проводит денежные расчеты с водителями." на "Бухгалтерия проводит денежные расчеты с водителями.", то и ловушка останется (упомянута бухгалтерия, но для системы она не нужна), и нелогичности не будет. Правда остается вопрос с зарплатой диспетчеров...
Я задаюсь вопросом, поскольку формулировка задачи не МОЯ. Безусловно задача вырвана из контекста, в реальности вообще такой постановки как нарисовать ДВИ не было бы. Безусловно был бы анализ и создание модели вариантов использования.
Разумеется, такие задачи должны быть упрощены до искусственности. В задаче по физике вполне приемлемо упоминание сферического коня в вакууме. Иначе студент до утра будет пытаться расчитатьь объем коня, пока не поймет, что задача не содержит необходимых исходных данных :) В полном объеме эта задача (проектирования системы) потянула бы на курсовик, пожалуй :)
Меня до сих пор волнует вопрос, а как отображать на таких ДВИ факт участия того же клиента или водителя. Читая книги (в первую очередь создателей UML) я однозначно читаю, что клиент или водитель показываться не должен, ну нет у них варианта использования нашей системы автоматизации, хотя он и участник.
Я думаю, правильно считаете. Все эти диаграммы нужны для анализа конкретной системы. Если мы рассматриваем систему автоматизации, то актеры - диспетчера и бухгалтер. Если систему диспетчерской службы, то актеры - клиент и водитель. Диспетчера и бухгалтер уже внутри системы. Если рассматриваем систему службы такси, то и водитель оказывается внутри.
По большому счету, если бы в формулировке задачи не упоминался клиент, а было бы написано, что диспетчер при поступлении звонка регистрирует заказ, вводя в систему телефон звонившего, то варианты использования системы не изменились бы. Информация о том, что есть такой субьект, как клиент, важна будет для построения диаграммы классов. Так как в системе будут обрабатываться объекты типа "Клиент".
Далее. В реальной практике, во время обучения, я никогда не предлагаю нарисовать студентам ДВИ, я всегда прелагаю провсети предварительный анализ, используя в качестве рекомендаций рекомендации Коберна. Возможно я интуитивно полагал, хотя наверняка не знал, что просто построить ДВИ малозначимо
ДВИ не малозначима. Это основа, та печка, от которой пляшет весь дальнейший анализ. Именно она опеределяет границы системы, ее функциональную наполненность.
Или вы имеете ввиду малозначимость именно графического представления? Так какая разница. Можно описать и в текстовом виде, просто графически - нагляднее.
Для маленьких систем она может казаться малозначимой, так как ее можно целиком удержать в голове. Но для больших систем гораздо проще один раз вынести эту существенную информацию в ДВИ и легко ее там находить, чем каждый раз листать тома регламентов, записей интервью и прочей неорганизованной исходной информации, что бы определить, например, необходимый набор состояний какого-либо класса.
, потому мой вопрос фурммулируется примерно так:
Построить диаграмму вариантов использования,
Хм, а разве можно построить ДВИ, не выполнив предварительно это:
определив действующих лиц, участников задачи, границы системы и выделив возможные варианты использования уровня цели пользователя.
По-моему, Вы просто расшифровываете студенту суть его задачи. Но он это и так должен знать из курса обучения.
-
не выполнив предварительно это:По-моему, Вы просто расшифровываете студенту суть его задачи. Но он это и так должен знать из курса обучения.
Да поскольку я требую не просто построить диаграмму, а записать все это в текстовом виде и уже далее рисовать диаграмму. Т.е. немысленная работа и фиксация результата
-
Если мы хотим ограничить систему именно обработкой заказов, то вопрос стоит сформулировать так: "Нарисовать диаграмму вариантов использования (use case diagram) системы автоматизации обработки заказов диспетчерской службой такси." Кроме того из формулировки надо выкинуть предложение о расчетах бухгалтерии с водителями на основании отчетов из системы.
А зачем что-то выкидывать. Если цель - проверка умения студента выделить главное в соответствии с заданным вопросом, то он сам должен убрать бухгалтерию. Тем более если вдуматься, бухгалтерия тут может рассматриваться как система-актор, а никак основное действующее лицо. Можно наверное добавить, что информация о выполненных заказах передается в бухгалтерскую систему - например 1 С.
Мне импонирует подход Boatmana и комментарии Shur, просто в таком виде задачу решать в условиях экзамена сложно, особенно если она не одна.
Хотя я в прошлом году давал подобные (правда несколько упрощенные) задачи с явными оговорками, и список вопросов на которые следовало бы ответить.
-
Да поскольку я требую не просто построить диаграмму, а записать все это в текстовом виде и уже далее рисовать диаграмму. Т.е. немысленная работа и фиксация результата
Не вопрос. Просто формулировка задания вида "Нарисовать ДВИ, выполнив то-то" подразумевает, что основная задача - нарисовать, а все остальное второстепенно (в смысле требуемого результата). Наверное, правильнее формулировать "Выполнить то-то и нарисовать ДВИ".
-
А зачем что-то выкидывать. Если цель - проверка умения студента выделить главное в соответствии с заданным вопросом, то он сам должен убрать бухгалтерию.
Я пытался показать, что в такой формулировке задачи заложено противоречие:
Для расчетов с водителями бухгалтерия должна получить данные о выполненной водителями работе. Количество выполненных заказов не является достаточным мерилом работы водителей. Наиболее точным мерилом работы была бы выручка, полученная водителем. В условии задачи не описано, как в систему попадает информация о выручке.
Это противоречие я и пытался устранить. В одном случае добавлением в условие задачи расчета выручки по данным из ГИС, в другом случае - убиранием из условия необходимости расчетов на основании данных из системы.