ПРОЕКТИРОВАНИЕ ФУНКЦИОНАЛЬНОЙ И ИНФОРМАЦИОННОЙ МОДЕЛЕЙ P2P-ПЛАТФОРМЫ АРЕНДЫ СПОРТИВНОГО ИНВЕНТАРЯ

ВВЕДЕНИЕ

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

Спортивный инвентарь представляет собой физический объект с местоположением, техническим состоянием и ограниченным временным ресурсом. Пользователь выбирает конкретный экземпляр, который должен быть свободен в заданный период и пригоден к эксплуатации. В связи с этим проектирование платформы требует согласования функциональных требований, жизненного цикла аренды, структуры данных и серверных механизмов контроля целостности. Подходы инженерии требований, архитектурного проектирования и платформенной экономики рассматриваются в работах [1; 3; 4].

Цель исследования состоит в проектировании функциональной и информационной моделей P2P-платформы аренды спортивного инвентаря. Для её достижения определены роли участников, пользовательские сценарии, состояния арендной операции, ключевые сущности базы данных и бизнес-правила. Научно-практический результат работы заключается в согласованной модели, пригодной для подготовки технического задания, проектирования REST API и серверной бизнес-логики.

МАТЕРИАЛЫ И МЕТОДЫ

Материалом исследования является концептуальный проект мобильной клиент-серверной системы, реализующей P2P-взаимодействие арендаторов и владельцев спортивного инвентаря. На этапе постановки требований выделены три роли: арендатор, владелец и администратор. Для каждой роли определены функции, доступные действия и контрольные события, влияющие на состояние бронирования и физического экземпляра.

Использованы методы инженерии требований, сценарного анализа, моделирования средствами UML и построения ER-модели. Сценарная модель применена для описания последовательности поиска, выбора периода, оплаты, выдачи и возврата; элементы диаграммы состояний — для определения допустимых переходов между статусами; информационная модель — для выявления сущностей и связей хранилища [2; 4; 5; 6]. При проектировании соблюдён принцип разделения карточки предложения и физического экземпляра: первая содержит общие характеристики, а второй — внутренний код, состояние, дату обслуживания и фактическую доступность.

РЕЗУЛЬТАТЫ И ОБСУЖДЕНИЕ

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

Ключевой пользовательский сценарий начинается с выбора точки и позиции каталога. До создания заказа сервер проверяет график работы, статус экземпляра и занятость указанного периода. Если свободный экземпляр найден, формируется заявка и резервируется временной интервал; после успешной оплаты бронирование переходит к этапу выдачи. Передача и возврат могут подтверждаться одноразовым QR-кодом, связанным с идентификатором операции. Такой механизм фиксирует значимые события внутри платформы и сокращает зависимость от неформальных договорённостей.

Статусная модель включает состояния «создано», «ожидает оплаты», «оплачено», «ожидает выдачи», «выдано», «возвращено», «завершено» и «отменено». Переходы выполняются только при наступлении заданных событий. Например, статус «выдано» недопустим без оплаты и подтверждения владельцем, а завершение невозможно без фиксации возврата. Для исключения двойной брони интервалы [t1, t2) и [t3, t4) считаются пересекающимися, если одновременно выполняются условия t1 < t4 и t2 > t3. Проверка должна выполняться сервером в транзакции, поскольку последовательная проверка на клиенте не защищает от конкурентных запросов.

Информационная модель включает подсистемы пользователей, точек аренды, каталога и операций. Сущность users хранит идентификационные данные, роль и статус учётной записи; sessions и user_devices поддерживают авторизацию и уведомления; user_documents используются для верификации владельцев. Точка аренды представляется сущностью rental_points с координатами, адресом, режимом работы, статусом модерации и признаком видимости. В отдельной структуре целесообразно хранить рабочие и закрытые интервалы, что упрощает проверку фактической доступности.

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

Таблица 1.

Бизнес-правила обеспечения целостности арендных операций

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

ЗАКЛЮЧЕНИЕ

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

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