Форум Сообщества Аналитиков
Общий раздел => Примеры => Задачи студентов => Тема начата: ThorLovesFreya от 28 Ноября 2010, 20:48:28
-
Цель работы: осуществить объектно-ориентированный анализ и объектно-ориентированное проектирование предметной среды средствами UML (Unified Modeling Language)
Вот предметная задача (предметная среда - таксопарк):
Осуществить объектно-ориентированный анализ и объектно-ориентированное проектирование программы, моделирующей работу автотранспортного предприятия (автопарка). Моделирующая программа включает часы, которые в начале моделирования устанавливаются в 0, а затем отчисляет такты времени до момента завершения процесса моделирования Основные события, происходящие во время работы автопарка, такие. Автопарк имеет набор одинаковых автомобилей для осуществления перевевозок пассажиров. Каждый автомобиль имеет свой идентификационный номер. Каждый водитель является обладателем автомобиля. Автопарк работает по предварительным вызовами клиентов. Планировщик программы случайным образом генерирует появление заказа клиента. При получении заказа диспетчер фиксирует время его приема, пункт назначения и адрес клиента. Заказы принимаются не ранее, чем за час до его исполнения. После получения заказа на перевозку диспетчер определяет машину и водителя, которые будут выполнять заказы. Диспетчер осуществляет выбор машины из тех, чо нахдятся в данный момент в автопарке. Если простаивают несколько машин, то преимущество на выполнение заказа имеет тот водитель, который находится в состоянии ожидания больший срок. Если свободных машин на время получения диспетчером заказов нет, то заказ становится в очередь невыполненых заказов и ждет момента исполнения. В этом случае диспетчер обзванивает все машины, имеющиеся на маршрутах и ищет ту, которая находится ближе к месту расположения клиента. Найдена машина предназначается для выполнения заказа. Каждый рейс приносит в кассу автопарка определенную денежную сумму. После окончания процесса моделирования планировщик программы вы-водит на экран сумму выручки за день. Кроме того, планировщик программы должен выводить на экран сообщения о событиях, которые происходят в моделируемой системе. Результаты объектно-ориентированного анализа представить в виде сценария работы физического объекта и перечня существительных, глаголов, претендующих на названия классов, атрибутов и методов классов; результаты объектно-ориентированного проектирования представить в виде диаграмм прецедентов, объектов и классов. Сгенерировать код интерфейсов классов, построить проект (на каждый класс - по два файла: заглавный и срр), добавить в проект код сгенерированных классов.
-
Вот мои диаграммы:
http://i.piccy.info/i5/58/29/772958/Use-Case.png
http://i.piccy.info/i5/66/29/772966/Class.png
генерация кода выдает кучу ошибок, но я не могу понять что и в какой диаграмме неправильно
Спасибо за любую помощь
Прошу прощения за любые неудобства связанные с подачей информации, я новичок, но постараюсь быстро освоится)
-
Говорите, если что-то еще надо предоставить
-
1. Структурируйте пожалуйста своё описание задачи.
2. Из диаграммы неясны границы системы. Автопарк? Система автоматизации исполнения заказов?
Диаграмма способов применения предназначена для фиксации результатов, получаемых контрагентами. «Проверить» не является результатом, также как и «Подождать».
3. Если вы действительно делали «анализ предметной среды», то на диаграмме классов упущены множество понятий, описанных вами текстом.
-
Вот диаграмма прецедентов с границами системы
http://i.piccy.info/i5/62/40/774062/Use_Case_2.png
Да, автопарк, система автоматизации исполнения заказов
Сейчас займусь структуризацией постановки задачи
-
Цель работы: осуществить объектно-ориентированный анализ и объектно-ориентированное проектирование предметной среды средствами UML (Unified Modeling Language)
Задача:
Осуществить объектно-ориентированный анализ и объектно-ориентированное проектирование программы, моделирующей работу автотранспортного предприятия (автопарка).
Результаты объектно-ориентированного анализа представить в виде сценария работы физического объекта и перечня существительных, глаголов, претендующих на названия классов, атрибутов и методов классов; результаты объектно-ориентированного проектирования представить в виде диаграмм прецедентов, объектов и классов. Сгенерировать код интерфейсов классов, построить проект (на каждый класс - по два файла: заглавный и срр), добавить в проект код сгенерированных классов.
-
План
1)Моделирующая программа включает часы, которые в начале моделирования устанавливаются в 0, а затем отчисляет такты времени до момента завершения процесса моделирования.
2)Автопарк имеет набор одинаковых автомобилей для осуществления перевозок пассажиров.
2.1)Каждый автомобиль имеет свой идентификационный номер.
2.2)Каждый водитель является обладателем автомобиля.
3)Автопарк работает по предварительным вызовами клиентов.
3.1)Планировщик программы случайным образом генерирует появление заказа клиента.
4)При получении заказа диспетчер фиксирует время его приема, пункт назначения и адрес клиента.
4.1)Заказы принимаются не ранее, чем за час до его исполнения.
4.2) После получения заказа на перевозку диспетчер определяет машину и водителя, которые будут выполнять заказы.
4.2.1) Диспетчер осуществляет выбор машины из тех, что находятся в данный момент в автопарке.
- Если простаивают несколько машин, то преимущество на выполнение заказа имеет тот водитель, который находится в состоянии ожидания
больший срок.
- Если свободных машин на время получения диспетчером заказов нет, то заказ становится в очередь невыполненых заказов и ждет момента
исполнения. В этом случае диспетчер обзванивает все машины, имеющиеся на маршрутах и ищет ту, которая находится ближе к месту
расположения клиента. Найденая машина предназначается для выполнения заказа.
5)Каждый рейс приносит в кассу автопарка определенную денежную сумму. После окончания процесса моделирования планировщик программы выводит на экран сумму выручки за день.
6)Кроме того, планировщик программы должен выводить на экран сообщения о событиях, которые происходят в моделируемой системе.
-
Вот попробовал структурировать описание задачи, вскоре пришлю сценарий работы моделируемой системы.
-
Если я правильно вас понял то "Проверить наличие водителя" надо заменить на "Передать водителю заказ".
А прецедент "Подождать" стоит убрать.
В то-же время "Проверить время вызова" стоит убрать и соединить расширением прецеденты "Вызов" (Клиента) и "Получить вызов" (Диспетчера) соединить расширением.
Аналогичную операцию проделать с прецедентами "Отменить вызов" (Клиента) и "Удалить вызов" (Диспетчера).
Верно?
-
Как здесь, да?
http://i.piccy.info/i5/98/43/774398/Use_Case_2,1.png
-
Результаты объектно-ориентированного анализа представить в виде:
1) сценария работы физического объекта и
2) перечня существительных, глаголов, претендующих на названия классов, атрибутов и методов классов;
И где же 1) СЦЕНАРИЙ и 2) ПЕРЕЧЕНЬ?
-
Давайте кратко пройдемся по диаграмме классов.
1. Не вполне понятно, что все-таки требуется сделать - систему автоматизации исполнения заказов, либо некий симулятор для, скажем, моделирования процесса обслуживания клиентов в подобной системе? Если именно систему автоматизации, то класса вроде Scheduler с его Generate_Call и т.п. в бизнес-логике и вовсе нету. Там реальный клиент вместо него будет. Если же верно второе, то такой класс допустим.
2. Водитель-авто - связь строго один-к-одному? Не знаю, соответствует ли это истине в реальном таксопарке, но для простоты пока будем считать, что это так.
3. Явно видна сущность 'Заказ' с атрибутами 'Время приема', 'Пункт назначения', 'Адрес клиента', и, возможно (если задача учебная), 'Стоимость'. Если задача реальная, со стоимостью все будет значительно сложнее.
4.У вас класс Dispatcher описывает, видимо, реального диспетчера таксопарка. А почему он из водителей состоит?... В смысле, агрегация-то там, наверно, не нужна.
Прилагаю набросок.
-
Вот сценарий:
1) Часы вычисляет очередной такт.
2) Клиент звонит в автопарк.
3) Диспетчер получает заказ если время удовлетворяет условию задачи (вызов не ранее чем за час до его выполнения).
3.1) Если есть свободный водитель, то диспетчер передает ему заказ согласно условию задачи (время простоя водителя).
Если нет свободного водителя, то диспетчер записывает заказ в очередь заказов и обзванивает свободные машины с маршрута
(положение водителя в городе).
4) Если клиент отменяет заказ, то диспетчер удаляет заказ из базы данных.
5) Водитель выполняет заказы, двигаясь городу (длина пути записывается на счетчик).
6) После окончания рейса в кассу начисляется сумма в соответствии с длиной пройденого за рейс пути, а водитель возвращается в парк.
7) Если следующий такт времени не является конечным, то диспетчер выводит сообщение, система переходит к шагу "1)), если следующий такт конечный, то диспетчер выводит сумму выручки за день, а система завершает работу.
-
Вот ссылка на перечень http://depositfiles.com/files/0qtdvs0k9 (http://depositfiles.com/files/0qtdvs0k9)
-
До завтра разобраться попытаюсь с предоставленным наброском - у самого кое-какие идеи появились...
-
Вот новая диаграмма классов http://i.piccy.info/i5/07/60/806007/Class_1.2.png
В данной задаче дейсвует принцип "1 водитель - 1 машина" (для упрощения) поэтому класс Driver у меня представляет не водителя-"работника парка" (который может пересесть с машини на машину, уволится, заболеть и т д), а водителя "прикрученого" к машине и являщегося машиной собственно говоря
Задача учебная, поэтому стоимость упрощена (как-то зависит от пути - на данном этапе - неважно как)
-
Вы так и не уточнили границы системы. Будем строить догадки. По косвенным признакам можно предположить, что все-таки планируется делать некую систему моделирования бизнес-процессов автопарка... Ну с целью, скажем, иметь возможность прокрутить в режиме ускоренной перемотки работу автопарка за сутки и спрогнозировать выручку.
В любом случае введите класс Заказ или Рейс - перенесите сумму, время, пункты отправления и назначения туда. Многое станет проще.
Пока не улавливаю особого смысла ввода класса Autopark, но если развивать дальше тему моделирующей системы - может, он и появится.