Разработка мобильного приложения «Регистрация заказов в службе доставки». Исследование и ее проектирование 4 1 Формулировка и описание и задачи 4

Название	Исследование и ее проектирование 4 1 Формулировка и описание и задачи 4
Анкор	Разработка мобильного приложения «Регистрация заказов в службе доставки
Дата	06.09.2022
Размер	1.94 Mb.
Формат файла
Имя файла	27062(1).docx
Тип	Исследование #664482
страница	3 из 4

1 2 3 4

Организация информационной базы

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

Рисунок 1 – Структура разработанного приложения

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

cities – города доступные для работы;
profile – данные пользователя;
location – геоданные пользователя;
activeOrders – выполняемые пользователем заказы;
availableOrder – доступные пользователя заказы;
balance – данные по балансу пользователя;
messagesFAQ – информационные материалы о работе;
notifications – системные уведомления для пользователя.

Для работы с API серверов был реализован соответствующий класс. Все запросы к API серверу осуществляются через протокол https. Метод loadCities загружает список городов обращаясь к базовому API серверу – московскому. Все остальные запросы отправляются к API серверу, соответствующему выбранному для работы городу – у каждого города есть свой API сервер.

Помимо обращения к API серверу данные на мобильное устройство могут прийти с push-уведомлением. В уведомлении содержится тип данных, чтобы на мобильном устройстве можно было понять, как их обработать, например orderPublished, и сами данные. Для работы с данными был реализован класс NotificationManager.

Приложения, написанные на React Native, не сохраняют своего состояния после выключения, поэтому при запуске приложения общее хранилище будет пустым. Преимущество такого поведения в том, что приложение будет занимать минимум памяти, необходимой для хранения данных на устройстве. Однако есть ряд данных, которые должны храниться на устройстве и быть доступными при запуске приложения без обращения к серверу. Например, токен для аутентификации, выбранный для работы город, данные пользователя и т.д. Для таких данных React Native предоставляет AsyncStorage –это хранилище, в которое можно добавлять, удалять и извлекать данные, но, в отличие от общего хранилища, данные в AsyncStorage будут сохранены после выключения приложения или телефона и будут доступны при следующем запуске. Для работы с AsyncStorage был реализован класс Storage.

Интерфейс пользователя реализован через классы представлений:

MesageForCourierView – страница с системным уведомлением для пользователя;
SelectCityView – страница со списком городов, доступных для работы;
ManageBalanceView – страница с управления балансом курьера:

просмотр текущего баланса, пополнение баланса и просмотр списка операций с балансом;

PhoneConfirmationView – страница ввода номера при регистрации;
CodeConfirmationView – страница ввода кода подтверждения номера при регистрации;
FAQVIew – страница с информацией о работе;
AvailableOrdersView – страница со списком доступных заказов;
ActiveOrdersView – страница со списком выполняемых заказов.

2.4 Программное обеспечение задачи

Для моделирования бизнес-процессов можно использовать различные технологии, например: интегрированная s-bpm модель процесса, методология классификации бизнес-процессов организации PCF APQC, Методология функционального моделирования SADT (IDEF0, IDEF3, IDEF1X), Методология моделирования бизнес-процессов ARIS, Методология моделирования бизнеспроцессов BPMN. [26-29, 39-42].

Система (Информационная система автоматизации процесса заказа и доставки бутилированной питьевой воды) предназначена для автоматизации процесса сбора, обработки, оплаты и выполнения заявок на доставку бутилированной питьевой воды. Данная система создаётся для автоматизации процесс обработки и выполнения заказов на доставку бутилированной питьевой воды. На рисунке 2 представлен обобщённый процесс обработки заказа, не зависящий от типа заказа.

Рисунок 2 – Обобщенная диаграмма обработки всех типов заказов

В системе предусмотрено три типа заказа:

 уличный (У);

 экспресс (Э);

 стандартный (С).

Все типы заказов имеют некоторую общую часть данных и специфические данные. Заказы типов «Экспресс» и «Стандартный» также имеют:

 Общую часть данных (адресность заказа, возможность отмены, срочность доставки).

 Специфические данные (касающиеся срока выполнения заказа и его подтверждения).

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

Таблица 1 – Описание статусов заказа

№	Статус	Тип статуса	Целевой	Тип заказа			Примечания
№	Статус	Тип статуса	Целевой	У	Э	С	Примечания
1.	Новый	Начальный	-	-	+	+
2.	В работе	Промежуточный	-	-	+	+
3.	Выполнен	Финальный	+	+	+	+	Он же начальный для типа заказа «Уличный»
4.	Не принят	Финальный	-	-	+	-
5.	Отменён	Финальный	-	+	+	+
6.	Не выполнен	Финальный	-	-	+	+

Как видно из таблицы 1 статусы заказа имеют несколько типов:

 Новый – Стандартный заказ, созданный «Клиентом», но еще не обработанный «Диспетчером». Стандартный заказ и экспресс-заказ, созданный «Диспетчером», не назначенный на начавшийся рейс. Экспресс-заказ, созданный «Клиентом», но еще не принятый «Водителем» или «Диспетчером».

 В работе – Стандартный или экспресс-заказ, назначенный на начавшийся рейс. Экспресс-заказ (созданный «Клиентом»), принятый «Водителем» или «Диспетчером» в работу.

 Отменен – Заказ, отмененный «Клиентом» или «Диспетчером» до его выполнения «Водителем». Требует указания причины.

 Выполнен – Заказ, успешно выполненный «Водителем».

 Не выполнен – Заказ, не выполненный «Водителем». Требует указания причины.

 Не принят – Экспресс-заказ, не принятый ни одним «Водителем», и ни одним «Диспетчером» в течении срока ожидания принятия заказа.

Переходы между статусами:

 Начальным статусом заказа может быть либо «Новый», либо «Выполнен».

 «Выполнен» – целевое финальное состояние заказа. Автоматический переход из него в другой статус – невозможен.

 Из статуса «Новый» заказ может перейти в статусы: «Отменён», «Не принят» или «В работе».

 Заказ в статусе «В работе», может быть переведён в статусы: «Отменён», «Не выполнен», «Выполнен».

Данные обо всех изменениях статуса «Заказа» автоматически фиксируются в «Истории изменения» «Заказа», данная сущность представляет собой запись об изменении статуса «Заказа» и обстоятельствах этого изменения.

Существуют различные типы заказов:

 «Уличный».

 «Экспресс».

 «Стандартный».

Заказ тип «Уличный» – доставка данного вида заказа не планируется. Она происходит по решению «Водителя». Другие пользователи в обработке данного типа заказа не участвуют.

На рисунке 3 ниже представлена диаграмма процесса обработки заказа типа «Уличный».

Рисунок 3 – Диаграмма обработки заказа типа «Уличный»

Специфика обработки данного типа заказа: имеет укороченный жизненный цикл, состоящий из одного статуса «Выполнен». Исполняется моментально. Создаётся сразу с агрегатами: «Позиция заказа», «Оплата», «Доставка». Не может быть переведён в нецелевые статусы.

Экспресс-заказ имеет полный цикл обработки. В его обработке принимают участие: «Клиент», «Диспетчер», «Водитель».

Он может быть создан:

 «Диспетчером»;  «Клиентом».

В зависимости от пользователя, создавшего «Заказ», возможны варианты его обработки:

 В случае создания «Клиентом» «Заказ» автоматически передаётся «Водителям» службы доставки, находящимся в радиусе доступности от адреса доставки. Здесь возможны два варианта:

Если ни один из «Водителей» не принимает «Заказ» за установленное для приёмки время, то он передаётся на приёмку «Диспетчеру».
Если он не принят «Диспетчером» за установленное для приёмки время, ему автоматически присваивается статус «Не принят». Дальнейшая обработка «Заказа» не производится.
В случае принятия «Заказа» («Диспетчером» или «Водителем») ему присваивается статус «В работе». В «Заказе» указывается «Рейс», который сейчас выполняет водитель, принявший «Заказ», или «Рейс», выбранный Диспетчером при принятии «Заказа».

 В случае создания «Диспетчером», диспетчер назначает выполняемый рейс для выполнения «Заказа». Назначенный заказ поступает водителю, выполняющему рейс. «Заказу» присваивается статус «В работе». После того как «Заказу» назначен «Рейс» и статус у него «В работе», «Водитель», выполняющий этот «Рейс» может:

 выполнить «Заказ», с созданием записи об «Оплате»;

 отметить «Заказ» как «Не выполненный» с указанием причины.

До изменения «Заказ» водителем, «Заказ» может быть отменён:

 «Клиентом», создавшим заказ;

 «Диспетчером»;

также возможно:

 переназначение «Заказа» на другой «Рейс» «Диспетчером» (до перевода этого заказа в одно из финальных состояний);

 изменение данных «Заказа» «Диспетчером» (до перевода этого заказа в одно из финальных состояний): o Адреса доставки (улицу, дом, квартиру, подъезд, этаж). o Номер телефона (при условии, что заказ не связан с Покупателем). o Даты доставки. o Времени доставки.

o Примечания. o Способ оплаты и набор позиций заказа (при условии, что еще не

произведена оплата заказа).

 изменение «Диспетчером» статуса «Заказа» из одного финального состояния в другое (вне рамок бизнес процесса осуществления доставки).

На рисунке 4 представлен процесс обработки заказа типа «Экспресс». При выполнении заказа водителем, система автоматически создаёт запись о доставке, с указанием координат и водителя, выполнившего «Заказ».

Специфика обработки и выполнения данного типа заказа:

«Стандартный Заказ» может быть создан:

 Гостем.

 Диспетчером. При этом «Диспетчер» может (в случае наличия соответствующей настройки) корректировать автоматически рассчитанную сумму заказа.

 Клиентом. При этом может быть произведена предоплата заказа банковской картой.

Рисунок 4 – Диаграмма обработки заказа типа «Экспресс» Далее «Заказ» обрабатывается «Диспетчером», который устанавливает «Район» и «Тип рейса» для выполнения этого «Заказа». Заказу присваивается статус «В работе». Водитель, приступая к выполнению «Рейса», соответствующему указанным «Диспетчером» параметрам, получает данный «Заказ». Он может:

 Выполнить «Заказ», с созданием записи об «Оплате» (если «Заказ» не предоплачен).

 Отметить «Заказ» как «Не выполненный» с указанием причины.

До изменения «Заказа» «Водителем» «Заказ» может быть отменён:

 «Клиентом», создавшим заказ.

 «Диспетчером».

также возможно:

 Переназначение «Заказа» на другой «Рейс» «Диспетчером» (до перевода этого заказа в одно из финальных состояний).

 Изменение данных «Заказа» «Диспетчером» (до перевода этого заказа в одно из финальных состояний):

Адреса доставки (улицу, дом, подъезд, этаж, квартиру/офис). o Номер телефона (при условии, что заказ не связан с Покупателем). o Даты доставки. o Времени доставки.
Примечания. o Способ оплаты и набор позиций заказа (при условии, что еще не

произведена оплата заказа).

 Изменение «Диспетчером» статуса «Заказа» из одного финального состояния в другое (вне рамок бизнес процесса осуществления доставки).

Изменение позиций и суммы заказа на этом этапе невозможно. При выполнении «Заказа» Водителем, Система автоматически создаёт запись о «Доставке», с указанием координат и «Водителя», выполнившего «Заказ».

1 2 3 4