Автор Анна Евкова
Преподаватель который помогает студентам и школьникам в учёбе.

Разработка регламента выполнения процесса «Транспортная доставка заказов» (Транспортная доставка заказов)

Содержание:

Введение

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

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

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

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

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

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

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

Объект исследования – предприятие общественного питания ДавайЗакажем.рф.

Целью данной работы является Разработка регламента выполнения процесса «Обеспечение послепродажного обслуживания».

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

- развернутое (подробное) описание предметной области;

- диаграмму вариантов использования;

- диаграмму деятельности;

- диаграмму последовательности;

- диаграмму состояний;

- диаграмму классов.

транспортная доставка заказов

ДавайЗакажем.рф – это онлайн-сервис по заказу и доставке готовых блюд из ресторанов и кафе, не имеющих собственную службу доставки.

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

Компания ДавайЗакажем.рф осуществляет исключительно посреднические услуги между заведениями общественного питания и клиентами. То есть запуск проекта не подразумевает создание производства.

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

На текущий момент доставка еды является самым быстрорастущим сегментом ресторанного бизнеса. Согласно статистике действующего сервиса Delivery Club, а также данным аналитического агентства РБК.Research:

  • 150 тыс. заказов с доставкой на дом ежедневно оформляют россияне;
  • 76,6% россиян хотя бы один раз пользовались услугой доставки еды на дом;
  • 59% россиян заказывают еду на дом через интернет;
  • $1,5 млрд – объем российского рынка доставки готовой еды.

На основании этих данных можно сделать вывод, что рынок спроса на доставку готовой еды растет бурными темпами. Это приводит к возникновению спроса, который остается неудовлетворённым как по количеству, так и по качеству выполняемых услуг. Сложившаяся ситуация создает объективные внешние предпосылки для создания такого бизнеса как служба доставки[3].

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

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

Основными преимуществами запуска бизнеса по модели компании «Давай закажем» являются:

  • Уникальность. Подобные единые сервисы существуют только в больших городах с высоким уровнем спроса;
  • Низкая конкуренция. В распоряжении сервиса десятки кухонь и тысячи блюд на любой вкус;
  • Отсутствие конъюнктурных и финансовых рисков. Даже в ситуации кризиса люди не отказываются от готовой пищи;
  • Легкость ведения бизнеса. Все бизнес – процессы отлажены и прописаны.

Инвестиии в проект – 354 900 тыс. рублей.

Срок окупаемости проекта – 4 месяца.

Прибыль после налогообложения, начиная с 4 месяца работы составляет 130312 руб.

Описание бизнеса, продукта или услуги

Служба доставки состоит из call – центр и штата водителей. Такой минимальный набор предполагает регулярные ежемесячные затраты: заработная плата сотрудникам, расходы на коммуникацию, оплата бензина и ремонт используемых транспортных средств. Помимо этого, для полноценной работы необходимо создание интернет-сайта c услугами интернет-магазина, который нуждается в обслуживании специалистом. Таким образом, служба доставки – это отдельное бизнес-подразделение.

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

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

«ДавайЗакажем.рф» предлагает оптимальное решение сложившейся ситуации. Для этого у компании есть все необходимые ресурсы: интернет-сайт, программное обеспечение для обработки заказов, программисты, call-центр и курьеры. Налаженная работа каналов привлечения обеспечивает регулярный поток клиентов, делающих десятки и сотни заказов каждый день. Это, в свою очередь, позволяет сохранять выгодные цены на доставку.

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

При сотрудничестве со службой доставки они получают ряд преимуществ:

  • Быстрый запуск нового направления;
  • Отсутствие издержек на содержание собственной службы доставки;
  • Привлечение нового сегмента рынка потребителей;
  • Бесплатная реклама на сайте.

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

3. Описание рынка сбыта

Целевая аудитория

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

Целевую аудиторию можно представить в виде нескольких категорий:

Мужчины трудоспособного возраста от 23 до 45 лет. Заказывают обеды и ужины, так как не хватает времени на самостоятельное приготовление еды. Частота заказа – от 3 до 7 раз в неделю.

Женщины трудоспособного возраста от 23 до 35 лет. Преимущественно не замужние. Заказывают обеды и ужины, так как основную часть времени предпочитают посвящать работе и встречам с друзьями. Частота заказа – от 2 до 5 раз в неделю.

Компании, заказывающие корпоративный обед. Частота заказа – 5 раз в неделю.

Семьи с детьми / без детей, желающие в выходные порадовать себя чем – то новым. Частота заказа – от 1 до 3 раз в неделю.

Школьники и студенты, устраивающие вечеринку. Частота заказа – 1 раз в неделю.

Любая категория населения, отмечающие праздники и не желающие тратить время на приготовление пищи.

При выходе на рынок «ДавайЗакажем.рф» использует стратегию новатора. Компания обладает преимуществом первопроходца и по мере развития старается удерживать ведущую конкурентную позицию. Основная задача в рамках стратегии – предоставлять качественные услуги и пристальное внимание уделять контролю качества. Для компании стратегически важно иметь ресурсы для быстрого расширения по мере роста рынка сбыта. Для этого создаются резервные фонды.

Описание бизнес-процесса.

1.Комплектация (комиссионирование) заказов. Этот процесс предполагает выполнение следующих важных мероприятий: получение заказов клиентов и оформление отборочного листа; отбор товара каждого наименования по заказу клиента и его комплектация; укладка отобранного товара в тару, на товароноситель; документальное оформление подготовленного заказа; формирование отдельных заказов в партию отправки; погрузка товаров в транспортное средство и оформление транспортных накладных.

2. Транспортировка заказов потребителям.

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

После оплаты заказа и согласования сроков доставки с покупателем, менеджер по продажам создает документ "Доставочная карточка". Документ "Доставочная карточка" вводится на основании документа "Реализация товаров и услуг". В документе "Доставочная карточка" должен быть указан склад отправитель, получатель с адресом доставки и желаемая дата доставки. Бизнес-процесс "Доставка товаров покупателям" должен стартовать при проведении документа "Доставочная карточка".

Задача "Утверждение логистом заявки на доставку".

После старта бизнес-процесса, логист должен проверить заявку и выбрать дальнейшие действия с заявкой. Логист в организации единственный.
Менеджер может: 1) Отменить заявку. При отмене заявки логист должен указать причину отмены. БП должен перейти в статус "Отменен" и должен завершиться.
2) Отправить автору на согласование. При отправке заявки на согласование клиенту, менеджер должен указать текст замечаний для клиента.

Уточнять заявку на доставку должен именно клиент. БП должен перейти в статус "На согласовании".

3) Отправить заказ на кухню.

При отправке заказа на кухню, менеджер должен указать:

а) Дату доставки.

б) Водителя.

Менеджером заявка должна рассматриваться до 1 часа.
Задача "Уточнение заявки на доставку".

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

Задача "Комплектация заказа для отправки".

Менеджер комплектует заказ

Задача сборки заказа должна оставаться открытой на весь период решения вопросов.

Задача "Подготовка отгрузочных документов". 

После проверки сборки менеджер должен распечатать пакет сопроводительной документации. После печати менеджер должен нажать "Готово". БП должен перейти в статус "Готово ". Подготовить комплект документов менеджер должен за 30 минут.

Задача "Отправка машины ". 

После погрузки машины и отправки заказа, менеджер должен загрузить в программу номера отправленных накладных.

Задача "Получение товара покупателем".

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

Создание главной диаграммы прецедентов

По умолчанию в представлении Вариантов Использования уже существует главная диаграмма прецедентов (Main)[1].

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

Для нашей предметной области мы выделили следующих актеров:

Таблица 1 Актеры

Актер

Краткое описание

Оператор

Отвечает на звонок клиента и перенаправляет звонок соответствующему специалисту

Менеджер

Сотрудник, который занимается комплектацией заказов и проверкой выполнения доставки

Водитель

Сотрудник, который занимается доставкой заказов


Рассмотрим теперь, какие возможности должна предоставлять наша система[5]:

  • актер Оператор использует систему для приема и распределения звонков и управления информацией о клиентах предприятия;
  • актер Менеджер использует систему для определения просмотра перечня необходимых для клиента продуктов и ведения информации о снабжении;
  • актер Водитель использует систему для получения заданий на доставку заказов [1].

На основании вышеизложенного можно выделить следующие прецеденты:

Таблица 2 Прецеденты

Прецедент

Краткое описание

Прием звонка

Запускается оператором. Позволяет вносить, изменять, удалять или просматривать заявку.

Управление информацией о клиенте

Запускается оператором. Позволяет добавлять, изменять или удалять клиентов, а также просматривать информацию о клиентах.

Управление информацией о заказах

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

Доставка

Запускается Водителем. Позволяет просматривать информацию о клиентах и времени доставки.

Оплата

Запускается Водителем. Позволяет просматривать информацию о клиентах и оплате доставки.

Рис.1 Диаграмма прецедентов

Поток событий для прецедентов главной диаграммы прецедентов
Потоки событий для прецедентов будем описывать по следующему шаблону:

  • Х.1 предусловия;
  • Х.2 главный поток;
  • Х.3 под-потоки;
  • Х.4 альтернативные потоки;
  • Х.5 постусловия.

где Х - число от единицы до количества прецедентов[6].

Поток событий для прецедента «Прием звонка».

    1. Предусловия.

Если поступает звонок от нового клиента, то под-поток добавить нового клиента (Add a New Client) прецедента Управление информацией о клиенте должен быть выполнен перед его началом.

    1. Главный поток.

Прецедент начинает выполняться, когда оператор подключается к системе и вводит свое имя и пароль. Система проверяет правильность пароля (Е-1) и выводит возможные варианты действий: выбрать специалиста, добавить (Add), изменить (Change), удалить (Delete), просмотреть (View) или выйти (Exit),.

    1. Под-потоки.

S-1: выбрать водителя

Система отображает диалоговое окно, содержащее поле, в котором оператор должен выбрать специалиста для решения проблемы клиента.

S-1: добавить новый заказ (Add a New Order)

Система отображает диалоговое окно, содержащее поля для заполнения Оператор заполняет поля (E-2). Система запоминает введенные данные и распечатывает счет для оплаты. Затем прецедент начинается сначала[6].

S-2: изменить заказ (Change Order)

Система отображает диалоговое окно, содержащее список заказов и поле для ввода номера заказа. Оператор выбирает необходимый заказ из списка или вводит номер заказа в поле (Е-3). Система отображает информацию о данном заказе. Оператор делает необходимые изменения (Е-2). Система запоминает введенные данные. Затем прецедент начинается сначала.

S-3: удалить заказ (Delete Order)

Система отображает диалоговое окно, содержащее список заказов и поле для ввода номера заказа. Оператор выбирает необходимый заказ из списка или вводит номер заказа в поле (Е-3). Система удаляет выбранный заказ (Е-4). Затем прецедент начинается сначала.

S-4: просмотреть заказ (View Order)

Система отображает диалоговое окно, содержащее список заказов и поле для ввода номера заказа. Оператор выбирает необходимый заказ из списка или вводит номер заказа в поле (Е-3). Система отображает информацию о выбранном заказе. Когда Оператор просмотрит информацию, прецедент начнется сначала.

Поток событий для прецедента «Управление информацией о клиенте».

2.1 Предусловия.

2.2 Главный поток.

Прецедент начинает выполняться, когда Оператор подключается к системе и вводит свое имя и пароль. Система проверяет правильность пароля (Е-1) и выводит возможные варианты действий: добавить (Add), изменить (Change), удалить (Delete), просмотреть (View) или выйти (Exit).

2.3 Под-потоки.

S-1: добавить нового клиента (Add a New Client)

Система отображает диалоговое окно, содержащее поля для ввода данных о новом клиенте. Пользователь заполняет поля (Е-2). Система запоминает введенные данные. Затем прецедент начинается сначала.

S-2: изменить данные о клиенте (Change Client Data)

Система отображает диалоговое окно, содержащее список клиентов и поле для ввода номера клиента. Оператор выбирает необходимого клиента из списка или вводит его номер в поле (Е-3). Система отображает информацию о данном клиенте. Оператор делает необходимые изменения (Е-2). Система запоминает введенные данные. Затем прецедент начинается сначала.

S-3: удалить клиента (Delete Client)

Система отображает диалоговое окно, содержащее список клиентов и поле для ввода номера клиента. Оператор выбирает необходимого клиента из списка или вводит его номер в поле (Е-2). Система удаляет выбранного клиента (Е-4). Затем прецедент начинается сначала.

S-4: просмотреть данные о клиенте (View Client Data)

Система отображает диалоговое окно, содержащее список клиентов и поле для ввода номера клиента. Оператор выбирает необходимого клиента из списка или вводит его номер в поле (Е-3). Система отображает информацию о выбранном клиенте. Когда Оператор просмотрит информацию, прецедент начнется сначала.

Поток событий для прецедента «Управление информацией о заказах.»

3.1 Предусловия.

3.2 Главный поток.

Прецедент начинает выполняться, когда менеджер подключается к системе и вводит свое имя и пароль. Система проверяет правильность пароля (Е-1) и выводит возможные варианты действий: добавить (Add), отметить (Mark) или выйти (Exit).

3.3 Под-потоки.

S-1: внести поступившие заказы (Add a New Components)

Система отображает диалоговое окно, содержащее поля для ввода наименования комплектующих, их количества, поставщика. Завскладом заполняет указанные поля (Е-2). Система запоминает введенные данные. Затем прецедент начинается сначала.

S-2: сделать отметку о комплектации заказа (Change Order)

Система отображает список блюд, приготовленных на кухне. Менеджер напротив нужных блюд вводит количество (Е-3). Система запоминает введенные данные. Затем прецедент начинается сначала[5].

Поток событий для прецедента «Доставка заказа».

4.1 Предусловия.

4.2 Главный поток.

Прецедент начинает выполняться, когда Водительподключается к системе и вводит свое имя и пароль. Система проверяет правильность пароля (Е-1) и выводит возможные варианты действий: просмотреть (View), отметить (Mark) или выйти (Exit).

4.3 Под-потоки.

S-1: Просмотреть наряд на доставку

Система отображает диалоговое окно, содержащее список нарядов и поле для ввода номера наряда. Водитель выбирает необходимый наряд из списка или вводит его номер в поле (Е-2). Система отображает информацию о выбранном наряде. Когда водительр просмотрит информацию, прецедент начнется сначала[6].

S-2: сделать отметку о доставке заказа

Система отображает диалоговое окно, содержащее список нарядов. Возле необходимого заказа водитель делает отметку о доставке по данному наряду. Затем сохраняет изменения. Затем прецедент начинается сначала.

Создание диаграммы классов

Создание диаграммы классов для сценария "Выполнить доставку заказа" прецедента "Доставка заказов"
Создадим классы-сущности Заказ, Клиент, Водитель. Поскольку в один заказ может входить много разных блюд, и одно блюдо может входить во много заказов, то введем еще один класс-сущность Строка заказа. Опишем каждый класс[7].

Таблица 3 Класс Клиент

Параметр

Значение

Комментарий

Класс, представляющий собой клиента фирмы

Атрибуты

name : String - наименование клиента

address : String - адрес клиента

phone : String - телефон клиента

Все атрибуты имеют модификатор доступа - private

Операции

AddClient() - добавление нового клиента

RemoveClient() - удаление существующего клиента

GetInfo() - получить информацию о клиенте

Все операции имеют модификатор доступа - public

Таблица 4 Класс Водитель

Параметр

Значение

Комментарий

Класс, представляющий собой водителя

Атрибуты

name : String - наименование водителя

address : String - адрес водителя

phone : String - телефон водителя

Все атрибуты имеют модификатор доступа - private

Операции

AddClient() - добавление нового водителя

RemoveClient() - удаление существующего водителя

GetInfo() - получить информацию о водителе

Все операции имеют модификатор доступа - public

Таблица 5. Класс Заказ:

Параметр

Значение

Комментарий

Класс, представляющий собой заказ на готовый обед

Атрибуты

entryNumber : Integer - номер заказа

entryDate : Date - дата оформления заказа

entryComplete : Date - дата выполнения заказа

idМaster водитель, выполняющий заказ

Все атрибуты имеют модификатор доступа - private

Операции

Create() - создание нового заказа

SetInfo() - занести информацию о заказе

GetInfo() - получить информацию о заказе

Все операции имеют модификатор доступа - public

Таблица 6 Класс СтрокаЗаказа

Параметр

Значение

Комментарий

Класс, представляющий собой пункт заказа

Атрибуты

itemNumber : Integer - номер пункта заказа

quantity : Integer - количество блюд

price : Double - цена за единицу

Все атрибуты имеют модификатор доступа - private

Операции

Create() - создание новой строки заказа

SetInfo() - занести информацию о строке заказа

GetInfo() - получить информацию о строке заказа

Все операции имеют модификатор доступа - public

Результат создания классов-сущностей показан на рис. 3:

Рисунок 3. Созданные классы-сущности

Добавим отношения между классами (рис. 4):

Рисунок 4. Итоговая диаграмма классов

Диаграммы состояний

Диаграммы состояний применяются, как правило, для моделирования поведения классов, прецедентов или системы в целом.

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

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

Диаграмма состояний для класса Entry представлена на рис.5:

Рисунок 5. Диаграмма состояний для класса Заказ

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

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

В состоянии Доставка заявка передается водителю

В состояние Отменен заказ переходит из состояния Открыт при наступлении события "заказ отменен". При выходе из него выполняется действие выхода "Сохранить дату отмены". При переходе из этого состояния в конечное выполняется действие "* OderItem.Delete()" (удаление пункта заказа). Здесь также стоит "*", поскольку это действие будет выполняться много раз.

Создание диаграмм деятельности.

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

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

Для создания диаграммы действий необходимо щелкнуть правой кнопкой мыши по Представлению Вариантов Использования и в появившемся меню выбрать пункт New > Activity Diagram, ввести ее имя, после чего дважды щелкнуть по ней в браузере, чтобы открыть ее. Результат построения диаграммы показан на рис. 6:

Рисунок 6. Диаграмма деятельности бизнес-процесса

Создание диаграммы последовательности

Создание диаграммы последовательности для сценария "Добавить новую заявку" прецедента " Ремонт техники "

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

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

На диаграмме последовательности объект изображается в виде прямоугольника, от которого вниз проведена пунктирная вертикальная линия. Эта линия называется линией жизни (lifeline) объекта. Она представляет собой фрагмент жизненного цикла объекта в процессе взаимодействия.

Каждое сообщение представляется в виде стрелки между линиями жизни двух объектов. Сообщения появляются в том порядке, как они показаны на странице сверху вниз. Каждое сообщение помечается как минимум именем сообщения. При желании можно добавить также аргументы и некоторую управляющую информацию. Можно показать самоделегирование (self-delegation) – сообщение, которое объект посылает самому себе, при этом стрелка сообщения указывает на ту же самую линию жизни.

Рисунок 7. Итоговая диаграмма последовательности

Создание диаграммы кооперации для прецедента "Транспортная доставка заказов"

Для создания диаграммы кооперации необходимо щелкнуть правой кнопкой мыши по пакету Диаграммы взаимодействия и в появившемся меню выбрать пункт New > Collaboration Diagram, ввести ее имя, после чего дважды щелкнуть по ней в браузере, чтобы открыть ее (рис. 8).

Рисунок 8. Итоговая диаграмма кооперации

Заключение

В результате выполнения курсовой работы была выполнена разработка регламента выполнения процесса «Транспортная доставка заказов». Были изучены и построены следующие диаграммы:

  • диаграмма вариантов использования;
  • диаграмма деятельности;
  • диаграмма последовательности;
  • диаграмма состояний;
  • диаграмма классов
  • диаграмма прецедентов.

Список литературы

  1. Кознов Д.В Языки визуального моделирования: проектирование и визуализация программного обеспечения. Учебное пособиеСПб.: Изд-во СПбГУ, 2004, 143 с
  2. Буч Г., Якобсон А., Рамбо ДжUML 2.0СПб.: Питер, 2006, 735 с
  3. UML 2.0 Infrastructure SpecificationMarca D.A., McGowan C.LSADT Structured Analysis and Design Technique McGraw-Hill, 1988
  4. Якобсон А., Буч Г., Рамбо Дж Унифицированный процесс разработки програмСПб.: Питер, 2002, 492 с
  5. Фаулер М., Скотт К UML. ОсновыСПб.: Символ, 2006, 184 с
  6. Леоненков А.ВОбъектно-ориентированный анализ и проектирование с использованием UML и IBM Rational Rose М.: Интернет-Университет Информационных Технологий; БИНОМ. Лаборатория знаний, 2006, 319 с
  7. Павлинов А., Кознов Д., Перегудов А., Бугайченко Д., Казакова А., Чернятчик Р., Фесенко Т., Иванов АО средствах разработки проблемно-ориентированных визуальных языков. Сб. «Системное программирование», Вып. 2
  8. Гамма Э., Хелм Р., Джонсон Р., Влиссидес ДжПриемы объектно-ориентированного проектированияИзд-во Питер, 2005, 368 с