Детальная информация
| Название | Разработка сервиса по аренде водного транспорта: выпускная квалификационная работа бакалавра: направление 02.03.02 «Фундаментальная информатика и информационные технологии» ; образовательная программа 02.03.02_02 «Информатика и компьютерные науки» = Development of a Water Transport Rental Service |
|---|---|
| Авторы | Немчинов Иван Михайлович |
| Научный руководитель | Шмаков Владимир Эдуардович |
| Организация | Санкт-Петербургский политехнический университет Петра Великого. Институт компьютерных наук и кибербезопасности |
| Выходные сведения | Санкт-Петербург, 2026 |
| Коллекция | Выпускные квалификационные работы ; Общая коллекция |
| Тематика | аренда водного транспорта ; бронирование ; backend ; REST API ; Go ; PostgreSQL ; Docker ; модульный монолит ; расписание ; верификация ; water transport rental ; booking ; modular monolith ; schedule ; verification |
| Тип документа | Выпускная квалификационная работа бакалавра |
| Язык | Русский |
| Уровень высшего образования | Бакалавриат |
| Код специальности ФГОС | 02.03.02 |
| Группа специальностей ФГОС | 020000 - Компьютерные и информационные науки |
| DOI | 10.18720/SPBPU/3/2026/vr/vr26-1850 |
| Права доступа | Доступ по паролю из сети Интернет (чтение) |
| Дополнительно | Новинка |
| Ключ записи | ru\spstu\vkr\42507 |
| Дата создания записи | 21.08.2026 |
Разрешенные действия
–
Действие 'Прочитать' будет доступно, если вы выполните вход в систему или будете работать с сайтом на компьютере в другой сети
| Группа | Анонимные пользователи |
|---|---|
| Сеть | Интернет |
Данная работа посвящена разработке прототипа backend-части сервиса по аренде водного транспорта. Разрабатываемый сервис предназначен для автоматизации процесса подбора судна, проверки его доступности, расчёта стоимости аренды, оформления бронирования и предоставления актуального расписания участникам процесса. Необходимость разработки обусловлена тем, что в рассматриваемой предметной области все заявки обрабатывается вручную через разрозненные каналы. Это приводит к увеличению нагрузки на менеджера, риску конфликтов расписания и недостаточной прозрачности процесса бронирования для клиента. Задачи, которые решались в ходе исследования: 1. Провести анализ предметной области аренды водного транспорта и существующих решений. 2. Определить основных участников процесса аренды и описать типовой процесс бронирования. 3. Сформулировать бизнес-правила, функциональные и нефункциональные требования к разрабатываемой системе. 4. Спроектировать архитектуру backend-приложения и схему базы данных. 5. Разработать прототип backend-части сервиса. 6. Провести верификацию разработанного прототипа и выполнить анализ полученных результатов. В ходе работы были рассмотрены особенности процесса аренды водного транспорта, включая выбор судна, проверку вместимости, расчёт стоимости, управление доступностью и жизненный цикл бронирования. Были выделены основные роли пользователей системы: клиент, менеджер, капитан и администратор. На основании анализа предметной области были сформулированы требования к сервису, определены границы прототипа и выбрана архитектура модульного монолита. В результате был разработан прототип backend-части сервиса, включающий модули аутентификации, управления пользователями, судами, тарифами, расписанием, бронированиями, административными приглашениями и ограниченным контуром капитана. Верификация прототипа проводилась на нескольких уровнях: модульном, интеграционном и функциональном. Были проверены ключевые бизнес-правила системы. Также была выполнена проверка производительности основных операций. Результаты тестирования подтвердили, что разработанный прототип соответствует основным функциональным и нефункциональным требованиям. Для достижения данных результатов в работе были использованы следующие информационные технологии, программное обеспечение, базы данных и прочие ресурсы: язык программирования Go, стандартная библиотека Go, REST API, формат обмена данными JSON, система управления базами данных PostgreSQL, драйвер PostgreSQL pgx, Docker и Docker Compose для контейнерного запуска приложения и базы данных, Git для контроля версий, среда разработки GoLand, Postman для ручной проверки API, а также встроенные средства Go testing и net/http/httptest для автоматизированного тестирования.
This thesis is dedicated to the development of a prototype for the backend component of a water transport rental service. The service under development is designed to automate the process of selecting a vessel, checking its availability, calculating the rental cost, processing reservations, and providing up-to-date schedules to all parties involved. The need for this development stems from the fact that, in the subject area under consideration, all requests are processed manually through disparate channels. This leads to an increased workload for the manager, the risk of scheduling conflicts, and a lack of transparency in the booking process for the customer. Tasks addressed during the research: 1. Analyze the water transport rental domain and existing solutions. 2. Identify the key participants in the rental process and describe a typical booking process. 3. Formulate business rules, as well as functional and non-functional requirements for the system under development. 4. 5. 6. Design the backend application architecture and database schema. Develop a prototype of the service’s backend component. Verify the developed prototype and analyze the results obtained. The project examined the specifics of the water transport rental process, including vessel selection, capacity verification, cost calculation, availability management, and the booking lifecycle. The main user roles within the system were identified: client, manager, captain, and administrator. Based on the analysis of the subject area, service requirements were formulated, the scope of the prototype was defined, and a modular monolith architecture was selected. As a result, a prototype of the service’s backend was developed, including modules for authentication, user management, vessel management, pricing, scheduling, bookings, administrative invitations, and a restricted captain’s interface. Prototype verification was conducted at several levels: modular, integration, and functional. The system’s key business rules were tested. Performance testing of core operations was also performed. The test results confirmed that the developed prototype meets the primary functional and non-functional requirements. To achieve these results, the following information technologies, software, databases, and other resources were used: the Go programming language, the Go standard library, REST API, the JSON data exchange format, the PostgreSQL database management system, the PostgreSQL pgx driver, Docker and Docker Compose for containerized deployment of the application and database, Git for version control, the GoLand development environment, Postman for manual API testing, as well as the built-in Go testing and net/http/httptest tools for automated testing.
| Место доступа | Группа пользователей | Действие |
|---|---|---|
| Локальная сеть ИБК СПбПУ | Все |
|
| Интернет | Авторизованные пользователи СПбПУ |
|
| Интернет | Анонимные пользователи |
|
- ВВЕДЕНИЕ
- Глава 1. Анализ предметной области и существующих решений
- 1.1. Общая характеристика предметной области
- 1.2. Участники процесса аренды водного транспорта
- 1.3. Типовой процесс бронирования
- 1.4. Проблемы существующего процесса бронирования
- 1.5. Анализ сайтов операторов и агентов
- 1.6. Анализ сервиса AQUABOOK
- 1.7. Анализ платформы Boatsetter
- 1.8. Сравнительный анализ существующих решений
- 1.9. Требования, следующие из анализа предметной области
- Глава 2. Формализация бизнес-требований и выбор технологического стека
- 2.1. Подход к формализации требований
- 2.2. Заинтересованные стороны системы
- 2.3. Бизнес-цели разработки системы
- 2.4. Границы разрабатываемой системы
- 2.5. Основные сущности предметной области
- 2.6. Бизнес-правила системы
- 2.7. Жизненный цикл бронирования
- 2.8. Функциональные требования
- 2.8.1. Требования к аутентификации и управлению пользователями
- 2.8.2. Требования к управлению судами
- 2.8.3. Требования к тарифам
- 2.8.4. Требования к расписанию
- 2.8.5. Требования к бронированиям
- 2.8.6. Требования к капитанам
- 2.8.7. Требования к программному интерфейсу
- 2.9. Нефункциональные требования
- 2.9.1. Производительность
- 2.9.2. Надёжность и целостность данных
- 2.9.3. Безопасность
- 2.9.4. Сопровождаемость
- 2.9.5. Переносимость и развёртывание
- 2.9.6. Наблюдаемость
- 2.10. Выбор архитектурного подхода
- 2.11. Выбор языка программирования Go
- 2.12. Выбор средств реализации REST API
- 2.13. Выбор PostgreSQL
- 2.14. Выбор драйвера PostgreSQL
- 2.15. Выбор Docker
- 2.16. Выбор Git
- 2.17. Postman
- 2.18. Итоговый технологический стек
- Глава 3. Проектирование и разработка приложения
- 3.1. Общая архитектура системы
- 3.2. Архитектурный стиль приложения
- 3.3. Декомпозиция приложения на функциональные модули
- 3.3.1. Модуль Auth
- 3.3.2. Модуль User
- 3.3.3. Модуль Vessel
- 3.3.4. Модуль Tariff
- 3.3.5. Модуль Schedule
- 3.3.6. Модуль Booking
- 3.3.7. Модуль Admin
- 3.3.8. Модули Manager и Captain
- 3.4. Проектирование схемы базы данных
- 3.5. Проектирование REST API
- 3.6. Проектирование аутентификации и авторизации
- 3.7. Основные сценарии взаимодействия компонентов
- 3.8. Реализация прототипа backend-части сервиса
- 3.8.1. Общая организация проекта
- 3.8.2. Конфигурация и запуск приложения
- Глава 4. Верификация программы и анализ результатов
- 4.1. Методика верификации
- 4.2. Среда тестирования
- 4.3. Модульное тестирование
- 4.3.1. Проверка пересечения временных интервалов
- 4.3.2. Проверка вместимости судна
- 4.3.3. Проверка расчёта стоимости
- 4.3.4. Проверка переходов состояний бронирования
- 4.3.5. Проверка истечения временной блокировки
- 4.4. Интеграционное тестирование
- 4.4.1. Проверка целостности связей
- 4.4.2. Проверка уникальности
- 4.4.3. Проверка защиты от двойного бронирования
- 4.5. Тестирование HTTP API
- 4.5.1. Проверка успешных ответов
- 4.6. Функциональное тестирование REST API
- 4.6.1. Сценарий регистрации и входа клиента
- 4.6.2. Сценарий управления судном
- 4.6.3. Сценарий бронирования
- 4.6.4. Сценарий конфликта расписания
- 4.7. Проверка ролевой модели
- 4.8. Проверка производительности
- 4.9. Трассируемость требований
- 4.10. Анализ достигнутых результатов
- 4.11. Ограничения прототипа
- 4.12. Направления дальнейшего развития
- ЗАКЛЮЧЕНИЕ
- СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ
- ПРИЛОЖЕНИЕ А. Код программы