Проблема и цель проекта
Функциональная область системы
Архитектура Travel-Collab
Серверное развертывание
Упрощенная модель данных вокруг поездки
Авторизация и роли
REST API и проверка backend
Карта и маршруты
Модуль расходов
Алгоритм балансов и взаиморасчетов
WebSocket-чат
Тестирование и CI
Скриншоты сервиса - главный экран
Скриншоты сервиса – раздел «Карта маршрута»
Скриншоты сервиса – раздел «Расходы»
Скриншоты сервиса – раздел «Расходы»
Скриншоты сервиса – раздел «Чат»
Скриншоты сервиса – Android APK
Итог и ограничения
5.04M

защита презентация new

1.

МИНОБРНАУКИ РОССИИ
ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ БЮДЖЕТНОЕ ОБРАЗОВАТЕЛЬНОЕ
УЧРЕЖДЕНИЕ
ВЫСШЕГО ОБРАЗОВАНИЯ
“ВОРОНЕЖСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ”
Факультет компьютерных наук
Кафедра программирования и информационных технологий
Разработка системы совместного планирования путешествий - Travel-Collab
Студент: Кузнецов В.А., ПиИТ, 4 курс
Руководитель: Вахтин А.А., доцент

2. Проблема и цель проекта

При групповой поездке маршрут, карта,
обсуждение и расходы часто ведутся в разных
приложениях. Из-за этого участники получают
разрозненные данные: точки лежат в карте,
договоренности — в чате, а расходы — в
таблице или отдельном сервисе.
Цель Travel-Collab — объединить эти
сценарии в одной рабочей области поездки.
2

3. Функциональная область системы

Основная сущность системы — поездка.
Внутри нее связаны участники, роли,
маршруты, точки интереса, сообщения и
расходы.
Такой подход нужен, чтобы чат, маршрут и
финансовые записи не существовали
отдельно друг от друга, а всегда относились к
конкретному trip_id.
3

4.

Технологический стек проекта
4

5. Архитектура Travel-Collab

Система построена как клиент-серверное
приложение. Web-браузер, мобильный браузер и
Android APK используют один frontend и
обращаются к одному backend.
Внешний доступ идет через публичный домен,
reverse proxy принимает HTTPS/WSS-запросы и
перенаправляет их к frontend или backend.
5

6. Серверное развертывание

Публичная версия сервиса работает на VPS.
Компоненты разделены на контейнеры:
frontend, backend, PostgreSQL/PostGIS и Caddy.
Caddy отвечает за внешний доступ, HTTPSсертификат и маршрутизацию запросов. База
данных хранится в отдельном контейнере с
постоянным volume и резервным
копированием.
6

7. Упрощенная модель данных вокруг поездки

База данных построена вокруг таблицы trips.
Пользователь получает доступ к поездке
через trip_members, а маршруты, точки,
сообщения и расходы всегда связаны с
конкретным trip_id.
Такой подход упрощает проверку доступа:
backend всегда понимает, к какой поездке
относится действие.
7

8. Авторизация и роли

JWT используется только для определения
пользователя. Права внутри поездки
проверяются отдельно через trip_members.
Это важно, потому что один пользователь
может быть владельцем одной поездки,
редактором в другой и участником с правами
просмотра в третьей.
8

9. REST API и проверка backend

Основные endpoint-ы работают не с глобальными объектами, а с ресурсами внутри поездки. Например,
маршруты, точки, расходы и сообщения доступны через trip_id.
Это помогает изолировать данные разных поездок и выполнять проверку доступа по единому принципу.
9

10. Карта и маршруты

Точки интереса хранятся с координатами в PostGIS и отображаются на карте через Leaflet и OpenStreetMap.
Маршрут в Travel-Collab — это пользовательский порядок посещения точек, а не автомобильная навигация.
Пользователь может менять порядок точек, а frontend показывает линию маршрута.
10

11. Модуль расходов

Расход хранит не только описание и сумму, но и структуру оплат и распределения. В payments фиксируется,
кто сколько оплатил, а в shares — какая часть расхода относится к каждому участнику.
Перед сохранением backend проверяет суммы, участников, дубли и принадлежность связанных маршрутов
или точек той же поездке.
11

12. Алгоритм балансов и взаиморасчетов

Backend рассчитывает баланс каждого участника как разницу между оплаченной суммой и его долей расходов.
Если баланс положительный, участнику должны компенсировать деньги; если отрицательный — он должен
другим.
После этого система строит список переводов от должников к кредиторам.
12

13. WebSocket-чат

Чат реализован через WebSocket Hub. Каждая поездка имеет отдельную комнату по trip_id, поэтому
сообщения не смешиваются между разными поездками.
Перед подключением backend проверяет JWT, участие пользователя в поездке и Origin. В публичной версии
соединение работает через WSS.
13

14. Тестирование и CI

Проверка проекта состоит из автоматических и ручных этапов. Backend-тесты покрывают финансовую логику,
security-настройки и middleware.
Frontend проходит production build, а GitHub Actions автоматически повторяет проверки при изменениях в
репозитории. Дополнительно вручную проверялись web-версия, мобильный браузер и APK.
14

15. Скриншоты сервиса - главный экран

15

16. Скриншоты сервиса – раздел «Карта маршрута»

16

17. Скриншоты сервиса – раздел «Расходы»

17

18. Скриншоты сервиса – раздел «Расходы»

18

19. Скриншоты сервиса – раздел «Чат»

19

20. Скриншоты сервиса – Android APK

20

21. Итог и ограничения

В результате разработан публично доступный сервис для совместного планирования поездок. Travel-Collab
объединяет карту, маршруты, участников, чат и расходы в одной рабочей области.
Дополнительно подготовлены production-развертывание, HTTPS/WSS, CI-проверки, backup базы и Android APK.
Ограничения текущей версии: нет refresh-токенов, push-уведомлений, offline-режима, мониторинга и реальных
платежей.
21

22.

МИНОБРНАУКИ РОССИИ
ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ БЮДЖЕТНОЕ ОБРАЗОВАТЕЛЬНОЕ
УЧРЕЖДЕНИЕ
ВЫСШЕГО ОБРАЗОВАНИЯ
“ВОРОНЕЖСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ”
Факультет компьютерных наук
Кафедра программирования и информационных технологий
https://travel-collab.ru/
Студент: Кузнецов В.А., ПиИТ, 4 курс
Руководитель: Вахтин А.А., доцент
English     Русский Правила