Для реализации панели администратора была выбрана библиотека react-admin, позволяющая для создания интерфейса использовать react и его компоненты, а также упрощающая взаимодействие с сервером. Для отображения расписания задач используется компонент react-big-scheduler, который можно настраивать под любые задачи и расширять.
2.3.2.3 Мобильное приложение
Таблица 3
Инструменты для мобильного приложения
|
Библиотека |
Описание |
|
|
androidx |
Библиотека, содержащая в себе основные компоненты для разработки android приложений: элементы интерфейса, навигация. |
|
|
retrofit2 |
HTTP-клиент |
|
|
gson |
Библиотека для сериализации/десериализации JSON |
|
|
paperdb |
Удобное хранилище типа ключ/значение |
Приложение использует стандартную библиотеку androidx для реализации архитектуры и основных экранов. Retrofit2 предоставляет широкие возможности для работы с сервером. Paperdb используется для хранения сессионной информации, например, токена.
Paper.book().write(TOKEN, loginJsonModel.token)
Выводы по главе
В данной главе были составлены требования, сформирована архитектура и выбраны инструменты для разработки.
3. Особенности реализации системы
3.1 Оптимизация
Основная цель данной системы - это оптимизация распределения задач. В основе этой задачи лежит проблема открытого цеха (job shop), которая заключается в следующем: у нас есть m работников, n работ (), состоящих из задач ( - задача работы ), которые должны быть выполнены последовательно. Задача - построить расписание, которое минимизирует продолжительность всего процесса ().
, где
- время начала выполнения задачи
- время, которое нужно на выполнении задачи
Чтобы решить данную проблему, ее представляют в виде дизъюнктивного графа, где
V - множество вершин, соответствующие задачам. Каждая вершина имеет вес, равный времени, необходимому для выполнения задачи. Добавляются также две фиктивные вершины s и t, представляющие начальное и конечное время.
C - множество соединительных дуг между i и (i+1) задачами.
D - множество дизъюнктивных дуг между задачами, которые должны быть обработаны одним и тем же работников.
Продолжительность работ задается самым длинным взвешенным путем от s до t. Данный путь называется критическим.
Задача состоит в том, чтобы найти все направления ребер дизъюнктивного графа таким образом, чтобы в результате получился направленный ациклический граф, у которого самый длинный взвешенный путь от начального времени (s) до конечного (t) был минимизирован.
Математическая модель представляет собой следующее:
, где
- работник, который может выполнять k задачу
S - множество конечных задач для всех работ.
Целевая функция определена в (1). Ограничение (2) означает, что целевая функция должна быть больше или равна общему времени, необходимому для обработки задач из S. Ограничение (3) определяет порядок выполнения задач в работе. Ограничение (4) определяет порядок задач у работников. Начало любой задачи выражено в (5).
В моей системе есть товары и задачи, которые нужно выполнить, чтобы товар был готов. Задачи для товара делятся на обязательные и дополнительные. Основные задачи - это те, без которых товар не является готовым. Дополнительные задачи - это разные версии готового продукта, которые позволяют настраивать товар под конкретного покупателя и его желания.
Основные задачи идут последовательно, администратор выбирает заранее порядок этих задач. Дополнительные задачи должны выполняться после обязательных. Администратор также может выбирать порядок дополнительных задач, и их разветвленность. В отличие от обязательных задач, дополнительные могут не иметь конкретной зависимости, тогда алгоритм автоматически будет их выбирать после обязательных.
Для решения данной оптимизационной задачи используется библиотека OR-Tools. В основе данной библиотеки лежит CP-SAT решатель, который реализует локальный поиск и программирование ограничениями (Constraint programming).
Используя инструменты, которые предоставляет OR-Tools, я выставляю ограничения для нашей системы.
Во-первых, это - ограничения, представленные выше для задачи открытого цеха.
Во-вторых - для обязательных задач мы учитываем зависимости.
, где
- индекс задачи, от которой зависит задача .
- набор задач для работы.
В-третьих, дополнительные задачи должны идти после обязательных и после зависимостей.
и
, где - индекс дополнительной задачи
- индекс задачи, от которой зависит дополнительная задача.
m - индекс обязательной задачи.
3.2 Сервер
Сервер предоставляет на выход 22 точки доступа, их общее описание дано в таблице 5.
Таблица 4
Точки доступа на сервере
|
Путь ресурса |
HTTP-методы |
Назначение |
|
|
users/login |
POST |
Авторизоваться, чтобы получить доступ к остальным ресурсам |
|
|
users/create |
POST |
Создать пользователя |
|
|
users/delete |
DELETE |
Удалить пользователя |
|
|
item-templates |
POST, GET, DELETE, PUT |
Создать, получить, удалить или отредактировать шаблоны товаров |
|
|
task-templates |
POST, GET, DELETE, PUT |
Создать, получить, удалить или отредактировать шаблоны задач |
|
|
orders |
POST, GET, DELETE, PUT |
Создать, получить, удалить или отредактировать заказы |
|
|
items |
GET |
Получить список товаров |
|
|
tasks |
GET |
Получить список задач |
|
|
worker-types |
POST, GET, DELETE, PUT |
Создать, получить, удалить или отредактировать типы работников |
|
|
schedule |
GET |
Получить данные о распределении задач |
На каждый запрос сервер отправляет JSON ответ. Для доступа к ресурсам необходимо сначала авторизоваться и получить токен.
Для создания точки доступа с помощью библиотеки ktor необходимо создать расширение к классу Route. Например, ниже представлен код для обработки метода GET на получение списка шаблона товаров:
const val ITEM_TEMPLATES = "$API_VERSION/item-templates"
@Location(ITEM_TEMPLATES)
class ItemTemplatesRoute
fun Route.itemTemplatesRoute(db: ItemTemplateRepository) {
authenticate("jwt") {
get<ItemTemplatesRoute> {
try {
val itemTemplates = db.getItemTemplates()
call.respond(itemTemplates)
} catch (e: Throwable) {
application.log.error("Failed to get ItemTemplates", e)
call.respond(HttpStatusCode.BadRequest, "Problems getting ItemTemplates")
}
}
}
}
3.3 Панель администратора
Программная система также включает в себя панель администратора, которая позволяет управлять системой: просматривать, создавать, редактировать и удалять данные.
Панель содержит следующие разделы:
Рисунок 6 Меню панели администратора
На экране Заказы можно просматривать и удалять заказы, а также создавать их, составляя список товаров в заказе.
Рисунок 7 Интерфейс создания заказа
На экране “Товары” можно просматривать товары, которые относятся к заказам. На экране “Задачи” отображается список задач, которые нужно выполнить, чтобы товары были готовы. Экран “Типы работников” позволяет создавать и удалять типы работников. “Шаблоны товаров” нужны для создания и удаления шаблонов товаров, которые компания может произвести. “Шаблоны заданий” позволяют создавать шаблоны заданий, относящиеся к товарам.
Рисунок 8 Список шаблонов заданий
Библиотека react-admin делает проще создание необходимых экранов, благодаря использованию react стиля. Например, ниже представлен код для создания таблицы со списком шаблонов заданий.
export const TaskTemplateList = props => (
<List {...props}>
<Datagrid rowClick="edit">
<TextField source="id" />
<ReferenceField label="itemTemplateId" source="itemTemplateId" reference="item-templates">
<TextField source="title" />
</ReferenceField>
<ReferenceField label="taskTemplateDependencyId" source="taskTemplateDependencyId" reference="task-templates">
<TextField source="title" />
</ReferenceField>
<ReferenceField label="workerTypeId" link="show" source="workerTypeId" reference="worker-types">
<TextField source="title" />
</ReferenceField>
<TextField source="title" />
<NumberField source="timeToComplete" />
<BooleanField source="isAdditional" />
</Datagrid>
</List>
);
На экране “Расписание” можно посмотреть распределение задач у работников (задачи отображаются либо по часам, либо по дням). Каждому товару присваивается уникальный цвет, которым выделяются все задачи этого товара. Данное выделение позволяет легче понимать состояние создания товара на экране расписания. Также при составлении расписания учитываются выходные дни, поэтому задачи распределяются только на рабочие часы.
Рисунок 9 Расписание задач
3.4 Мобильное приложение
Мобильное приложение работает в двух состояниях: для продавца и для работника. При авторизации сервер отправит нам данные, в которых указывает, кто вошел в аккаунт.
Продавец с помощью мобильного приложения может просматривать старые заказы, а также создавать новые, выбирая необходимые товары и задачи.
Рисунок 10 Экраны приложения в режиме Продавец
Работник в приложении видит задачи и их подробное описание, которые ему необходимо выполнить, а также он может изменять состояние задач.
Рисунок 11 Экраны приложения в режиме Работник
3.5 Тестирование
Было проведено тестирование каждого из трех компонентов. Для проверки функциональной части я использовал Use case тестирование, которое включало в себя следующие сценарии использования:
1. Продавец создает заказ.
2. Продавец удаляет заказ.
3. Работник запрашивает список задач.
4. Работник меняет статус задачи.
5. Администратор создает шаблон товара.
6. Администратор создает шаблон задания.
7. Администратор создает тип работника.
Оптимизация была проверена на данных из статьи про задачу открытого цеха, у которых заранее была рассчитана оптимальная продолжительность.
На вход были поданы следующие данные
? Работа 0 =
? Работа 1 =
? Работа 2 =
В данном примере каждая работа состоит из списка задач, где первый элемент - это тип работника, а второй элемент - время, необходимое на выполнение задачи.
Мы можем вручную расставить задачи следующим образом и получить решение длиной в 12. Но данное решение не будет оптимальным.
В данном примере, по оси y отображены типы работников.
Разработанная мной система на этих данных смогла найти оптимальное решение, длинной в 11.
Из данной проверки можно сделать вывод, что система способна построить оптимальное распределение задач, чтобы сократить общее время производства.
Выводы по главе
В последней главе были рассмотрены компоненты системы и их особенности.
Заключение
Целью данной работы была разработка системы для оптимизации распределения производственных задач. В рамках данного задания была рассмотрена предметная область и составлены требования. Были изучены технологии, необходимые для разработки компонентов, и продумана архитектура приложений. В результате были получены следующие компоненты:
1. Сервер для хранения и обработки информации (создание заказов, составление расписания).