Курсовой проект на тему «Разработка информационной системы продажи железнодорожных билетов»

Введение

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

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

Целью настоящей работы является разработка проекта и прототипа информационной системы для автоматизации продажи железнодорожных билетов.

Для достижения поставленной цели необходимо решить следующий ряд задач:

• Провести детальный анализ предметной области.
• Сформулировать функциональные и нефункциональные требования к системе.
• Спроектировать архитектуру и базу данных будущей ИС.
• Разработать ключевые программные модули системы.

Объектом исследования выступает процесс продажи железнодорожных билетов. Предметом исследования являются методы и средства проектирования и разработки информационных систем для автоматизации этого процесса.

1. Анализ предметной области и формирование требований к системе

Первым шагом в создании любой сложной системы является глубокий анализ существующих бизнес-процессов (модель «as-is»). В нашем случае процесс начинается с момента, когда клиент инициирует поиск билета, и заканчивается получением отчетности администратором системы. Он включает в себя консультации с кассиром, проверку наличия мест, ручное оформление документов и проведение оплаты. Этот процесс требует четкой формализации для последующей автоматизации.

В рамках предметной области можно выделить трех ключевых акторов (участников) системы:

1. Пассажир (Клиент): Конечный пользователь, который ищет, бронирует, оплачивает и при необходимости возвращает билеты.
2. Кассир/Менеджер: Сотрудник компании, который управляет заказами, консультирует клиентов, обрабатывает сложные случаи возврата и имеет доступ к расширенной информации о рейсах.
3. Администратор: Технический специалист, отвечающий за стабильность работы системы, управление пользователями и их правами доступа, а также за генерацию сводных отчетов.

На основе анализа их ролей и задач формируется перечень требований к будущей системе.

Функциональные требования

Функциональные требования определяют, что именно система должна делать. Ключевые функции ИС по продаже билетов включают:

• Управление пользователями: Регистрация, аутентификация и авторизация пользователей с разными ролями.
• Поиск рейсов и мест: Предоставление пользователю удобного интерфейса для поиска билетов по заданным критериям (дата, направление, класс вагона).
• Бронирование билетов: Возможность временного резервирования выбранных мест до момента оплаты.
• Обработка платежей: Интеграция с платежными шлюзами для безопасного проведения онлайн-оплаты.
• Управление заказами: Просмотр истории заказов, печать и скачивание электронных билетов.
• Процедура возврата: Автоматизированный механизм возврата билетов с учетом установленных правил и штрафов.
• Генерация отчетов: Формирование отчетов по продажам, пассажиропотоку и финансовым показателям для администраторов.

Нефункциональные требования

Нефункциональные требования описывают, какой система должна быть, то есть ее атрибуты качества:

• Надежность: Система должна обеспечивать высокую степень отказоустойчивости и работать в режиме 24/7.
• Производительность: Высокая скорость обработки транзакций, особенно в моменты пиковых нагрузок.
• Безопасность: Защита персональных данных пользователей и финансовых транзакций с помощью шифрования и строгой аутентификации.
• Удобство использования (Usability): Интуитивно понятный и адаптивный пользовательский интерфейс, обеспечивающий кроссплатформенную совместимость (корректное отображение на ПК, планшетах и смартфонах).

2. Проектирование архитектуры и логики системы с использованием UML и DFD

После сбора и формализации требований наступает этап проектирования, на котором абстрактные требования преобразуются в конкретные модели будущей системы. Для этого используются общепринятые в индустрии стандарты моделирования, такие как UML (Unified Modeling Language) и DFD (Data Flow Diagrams), позволяющие визуализировать структуру и поведение системы.

Выбор этих методологий обусловлен их способностью комплексно описать систему: DFD отлично показывает потоки данных, а UML — статическую структуру и динамику взаимодействия объектов.

Диаграмма вариантов использования (Use Case Diagram)

Эта диаграмма является отправной точкой в UML-моделировании. Она наглядно демонстрирует взаимодействие акторов (Пассажир, Менеджер, Администратор) с основными функциями системы. Например, актор «Пассажир» связан с вариантами использования «Поиск билета», «Бронирование билета» и «Оплата заказа», что четко очерчивает границы и возможности системы с точки зрения пользователя.

Диаграммы потоков данных (DFD)

DFD используется для моделирования функциональной стороны системы. Эти диаграммы показывают, как информация поступает в систему, как она обрабатывается различными процессами и где сохраняется. Например, DFD может иллюстрировать, как запрос на поиск рейса от пользователя (внешняя сущность) поступает в процесс «Обработка поискового запроса», который обращается к «Хранилищу данных о рейсах» и возвращает результат.

Диаграмма классов (Class Diagram)

Это ключевая диаграмма для объектно-ориентированного проектирования и основа для последующей разработки базы данных. Она определяет основные сущности системы в виде классов, их атрибуты (поля) и методы (операции), а также связи между ними.

Для нашей системы можно выделить следующие основные классы:

• Пользователь (User): с атрибутами `id`, `login`, `password`, `role`.
• Рейс (TrainRoute): с атрибутами `route_number`, `departure_station`, `arrival_station`, `departure_time`.
• Билет (Ticket): с атрибутами `ticket_number`, `seat_number`, `price` и связями с классами `Пользователь` и `Рейс`.
• Заказ (Order): с атрибутами `order_id`, `status` и связью «один-ко-многим» с классом `Билет`.

Эта диаграмма служит фундаментом для проектирования реляционной базы данных и объектной модели программного кода.

3. Разработка реляционной модели базы данных

На основе диаграммы классов, разработанной на предыдущем этапе, создается модель данных, которая будет физически хранить всю информацию системы. В качестве системы управления базами данных (СУБД) для данного проекта была выбрана MySQL. Этот выбор обоснован ее широким распространением, высокой производительностью, надежностью и тем, что она является бесплатным решением с открытым исходным кодом.

Логическая модель данных (ER-диаграмма)

Логическое проектирование начинается с создания ER-диаграммы (Entity-Relationship). Она визуально представляет сущности (например, «Пользователи», «Рейсы», «Билеты»), их атрибуты и связи между ними. Например, между сущностями «Заказы» и «Билеты» устанавливается связь «один-ко-многим» (один заказ может содержать много билетов), а между «Пользователи» и «Заказы» — аналогичная связь (один пользователь может сделать много заказов).

Физическая модель данных

Далее логическая модель преобразуется в физическую — конкретный набор таблиц для СУБД MySQL. Каждая сущность становится таблицей, а атрибуты — ее полями с определенными типами данных.

Пример структуры ключевых таблиц:

• `users`: `id` (INT, PRIMARY KEY), `username` (VARCHAR), `password_hash` (VARCHAR), `role` (ENUM).
• `routes`: `id` (INT, PRIMARY KEY), `route_number` (VARCHAR), `departure_point` (VARCHAR), `arrival_point` (VARCHAR).
• `orders`: `id` (INT, PRIMARY KEY), `user_id` (INT, FOREIGN KEY to `users.id`), `status` (VARCHAR), `created_at` (TIMESTAMP).
• `tickets`: `id` (INT, PRIMARY KEY), `order_id` (INT, FOREIGN KEY to `orders.id`), `route_id` (INT, FOREIGN KEY to `routes.id`), `seat_number` (INT), `price` (DECIMAL).

Важным шагом является нормализация схемы данных. Проектируемая база данных приведена к третьей нормальной форме (3NF). Это позволяет устранить избыточность данных и избежать потенциальных аномалий при их обновлении, вставке или удалении, обеспечивая целостность и согласованность хранимой информации.

4. Описание технологического стека и программной реализации ключевых модулей

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

Для данного проекта был выбран следующий стек технологий:

• Серверная часть (Backend): Язык программирования Python с использованием фреймворка Django. Этот выбор обусловлен высокой скоростью разработки, большим количеством готовых библиотек (в том числе для аутентификации и работы с БД) и сильным сообществом.
• База данных (Database): MySQL, как было обосновано ранее.
• Клиентская часть (Frontend): Стандартная связка HTML, CSS и JavaScript. Для повышения интерактивности и удобства пользовательского интерфейса может быть использован фреймворк React или Vue.js.

Общая архитектура приложения — трехзвенная (клиент-сервер-база данных). Клиентская часть отвечает за отображение информации и взаимодействие с пользователем, серверная — за бизнес-логику и обработку данных, а СУБД — за их надежное хранение.

Примеры реализации ключевых функций

Рассмотрим фрагменты логики для некоторых важных модулей.

Алгоритм поиска доступных билетов.
При получении запроса от пользователя с параметрами (дата, станция отправления, станция прибытия) серверный скрипт выполняет SQL-запрос к базе данных. Запрос выбирает все рейсы, соответствующие критериям, а затем для каждого найденного рейса выполняется подзапрос, который подсчитывает количество уже проданных билетов. На основе этой информации формируется ответ клиенту со списком доступных рейсов и количеством свободных мест.

Механизм аутентификации пользователя.
При попытке входа система получает от пользователя логин и пароль. Пароль не хранится в открытом виде, а преобразуется в хэш с использованием «соли». Полученный хэш сравнивается с тем, что хранится в таблице `users`. В случае совпадения для пользователя создается сессия, и он получает доступ к защищенным разделам системы. Этот подход обеспечивает высокий уровень безопасности учетных данных.

Аналогичным образом реализуются и другие функции, такие как обработка платежей через API платежного шлюза, где сервер выступает посредником, обеспечивающим безопасную передачу данных между клиентом и платежной системой.

Заключение

В ходе выполнения курсовой работы была достигнута ее основная цель — разработан комплексный проект и прототип информационной системы для автоматизации процесса продажи железнодорожных билетов.

Все поставленные задачи были успешно решены. Был проведен системный анализ предметной области, на основе которого сформулированы четкие функциональные и нефункциональные требования. С использованием стандартных методологий UML и DFD была спроектирована логическая архитектура системы. Разработана нормализованная реляционная модель базы данных, готовая к физической реализации. Наконец, были описаны ключевые аспекты программной реализации, включая выбор технологического стека и алгоритмы работы основных модулей.

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

Разработанный прототип обладает значительным потенциалом для дальнейшего развития. Возможные пути для улучшения и расширения функционала включают:

• Разработку нативного мобильного приложения для платформ iOS и Android.
• Внедрение программы лояльности для постоянных клиентов.
• Создание B2B-модуля для работы с туристическими агентствами.
• Добавление функционала «листа ожидания» с автоматическим выкупом билетов при их появлении.

Список использованных источников

1. Буч Г., Рамбо Д., Якобсон И. Язык UML. Руководство пользователя. — 2-е изд. — М.: ДМК Пресс, 2006. — 496 с.
2. Дейт К. Дж. Введение в системы баз данных. — 8-е изд. — М.: Вильямс, 2005. — 1328 с.
3. Макконнелл С. Совершенный код. Мастер-класс. — М.: Русская Редакция, 2010. — 896 с.
4. Гамма Э., Хелм Р., Джонсон Р., Влиссидес Дж. Приемы объектно-ориентированного проектирования. Паттерны проектирования. — СПб.: Питер, 2001. — 368 с.
5. ГОСТ Р ИСО/МЭК 12207-2010. Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств.
6. Фаулер М. Архитектура корпоративных программных приложений. — М.: Вильямс, 2004. — 544 с.
7. Грегор Хопе, Бобби Вульф. Шаблоны интеграции корпоративных приложений (Enterprise Integration Patterns). — М.: Вильямс, 2007. — 672 с.
8. Кравченко А.В. Основы проектирования информационных систем. — М.: Горячая линия — Телеком, 2017. — 320 с.
9. Официальная документация Python. [Электронный ресурс]. URL: https://docs.python.org/3/
10. Официальная документация MySQL. [Электронный ресурс]. URL: https://dev.mysql.com/doc/

Список использованной литературы

1. ГОСТ 34.602-89 «Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы»
2. ГОСТ 34.601-90 «Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания»
3. Гультяев А. К., «Microsoft Office Project 2007. Управление проектами: практическое пособие. » — СПб.: КОРОНА-Век, 2008 – 480с, ил.
4. Атре Ш. Структурный подход к организации баз данных. – М.: Финансы и статистика, 1998.
5. Вендров А.М. CASE – технологии. Современные методы и средства проектирования информационных систем. – М.: Финансы и статистика, 1998.
6. Вендров А.М. Проектирование программного обеспечения экономических информационных систем.- М.: Финансы и статистика, 2000.
7. Дейт К. Дж. ведение в системы баз данных. — 6-е изд. — Киев: Диалектика, 1998. — 784 с.
8. Маклаков С.В. BPWin, ERWin. CASE – средства разработким информационных систем. – М.: Диалог – МИФИ , 1999.
9. Липаев В.В. Проектирование программных средств. – М.: Высшая школа, 1990.
10. Методическое руководство по проектированию ИС CASE средствами Platinum Technology (Login Work) BPWin, ERWin. – Пермь: ПГТУ, ГНИИМС, 2002.
11. Алексунин В.А., Родигина В.В. «Электронная коммерция и маркетинг в Интернет.» — Учебное пособие. — М.: «Дашков и К0», 2005
12. Балабанов И.Т. – «Торговля через виртуальный магазин» / «Электронная коммерция»/ 2004 г. С. 195–197.
13. Дронов В. «PHP, MySQL и Dreamweaver MX 2004. Разработка интерактивных Web-сайтов.» – СПб.: БХВ-Петербург, 2005.
14. Карпова Т.С. – «Базы данных: Модели, разработка, реализация» СПб.: Питер, 2002. – 304 с.: ил.
15. Кавторева Я. «Интернет магазин. «Организация, налогообложение, учет.» — Фактор, 2009 — 119 с.
16. Костяев Р.А. «Бизнес в Интернете: финансы, маркетинг, планирование» / Р.А Костяев – СПб. БХВ-Петербург, 2002. – 630 с.: ил.
17. Лора Томсон, Люк Веллинг, «Разработка Web – приложений с помощью PHP и MySQL». Издательство “Вильямс” 2003г. Москва Санкт – Петербург, Киев.
18. Орлов Л. «Как создать электронный магазин в Интернет», 2_е изд., М.: Бук. пресс, 2006. — 384 с.
19. Разработка и поддержка Интернет — магазинов http://www.betagroup.ru/shop
20. Харрис Э. «PHP/MySQL для начинающих.» Пер. с англ. – М.: Кудиц – Образ,2005. – 384 с.