Проектирование информационной системы для продажи авиабилетов в рамках курсовой работы

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

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

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

В системе продажи авиабилетов можно выделить три основные роли:

• Пассажир (Клиент): Основной пользователь, цель которого — найти подходящий рейс, забронировать место и оплатить билет.
• Кассир: Сотрудник авиакомпании или агентства, который осуществляет продажу и возврат билетов, консультирует клиентов и работает с базой данных заказов.
• Администратор: Технический специалист, отвечающий за стабильную работу системы, управление правами доступа пользователей, а также за архивирование и восстановление данных.

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

2. Выбор технологического стека, или на чем мы будем строить систему

После того как мы определили, «что» и «для кого» мы делаем, пора выбрать инструменты — технологический стек. Для курсовой работы важно выбрать современные, востребованные и хорошо документированные технологии. Предлагаемый стек является сбалансированным решением, идеально подходящим для учебного проекта.

1. Система управления базами данных (СУБД): PostgreSQL. Это мощная, надежная и бесплатная реляционная СУБД. Она отлично подходит для хранения структурированных данных о рейсах, пассажирах, билетах и заказах, обеспечивая целостность и быстрый доступ к информации.
2. Серверная часть (Backend): Node.js с фреймворком Express. Node.js позволяет писать серверную логику на JavaScript, что упрощает разработку, если вы уже знакомы с этим языком. Express — это минималистичный и гибкий фреймворк, который ускоряет создание API (программного интерфейса) для взаимодействия между клиентской частью и базой данных.
3. Клиентская часть (Frontend): React или Angular. Оба фреймворка являются лидерами в разработке современных пользовательских интерфейсов. React — это библиотека от Facebook, известная своей гибкостью и огромным сообществом. Angular — это полноценный фреймворк от Google, предлагающий более структурированный подход. Выбор между ними часто зависит от личных предпочтений, но оба позволят создать быстрый и отзывчивый интерфейс, который будет удобен для пользователей.

Такой стек технологий не только актуален на рынке труда, но и имеет огромное количество учебных материалов, что делает его идеальным выбором для самостоятельного изучения и реализации курсового проекта.

3. Формализация требований через пользовательские сценарии и Use Case диаграммы

Когда предметная область проанализирована и инструменты выбраны, необходимо формализовать требования — точно описать, что система должна делать. Для этого в языке моделирования UML используется понятие «прецедент» (Use Case), которое описывает один из сценариев взаимодействия пользователя с системой для достижения конкретной цели.

Давайте определим основные прецеденты для каждой роли:

• Пассажир:
  • Поиск билета (с выбором маршрута, даты, типа билета)
  • Регистрация в системе
  • Бронирование места на рейсе
  • Оплата заказа онлайн
  • Просмотр истории своих заказов
• Кассир:
  • Обработка заказов и бронирований
  • Оформление продажи билета
  • Оформление возврата билета
  • Просмотр статистики продаж
• Администратор:
  • Управление расписанием рейсов
  • Управление учетными записями пользователей
  • Назначение и разграничение прав доступа

Эти сценарии визуализируются с помощью диаграммы прецедентов (Use Case Diagram). На ней акторы (Пассажир, Кассир, Администратор) изображаются в виде человечков, а прецеденты — в виде овалов. Линии, соединяющие их, наглядно показывают, какие функции доступны каждой роли. Такой подход позволяет четко структурировать функциональные требования и служит отправной точкой для дальнейшего, более детального проектирования.

4. Проектирование логики системы с помощью диаграмм последовательности и деятельности

Мы определили, что система должна делать. Теперь нужно спроектировать, как она будет это делать внутри. Для детализации сложных сценариев используются другие виды UML-диаграмм. Возьмем ключевой процесс — «Бронирование и покупка билета» — и посмотрим, как его можно описать.

Для визуализации взаимодействия между различными компонентами системы во времени идеально подходит диаграмма последовательности (Sequence Diagram).

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

1. Пользователь нажимает кнопку «Забронировать» в интерфейсе.
2. Интерфейс отправляет запрос на сервер с данными о рейсе и пассажире.
3. Сервер обращается к базе данных, чтобы проверить наличие свободных мест на данном рейсе.
4. База данных возвращает ответ.
5. Если места есть, сервер резервирует место и отправляет в интерфейс запрос на переход к оплате.
6. После успешной онлайн-оплаты сервер снова обращается к базе данных, чтобы сохранить информацию о заказе и билете.
7. Интерфейс получает подтверждение и показывает пользователю информацию о купленном билете.

В свою очередь, сам алгоритм действий, особенно если в нем есть условия и ветвления, удобно визуализировать с помощью диаграммы деятельности (Activity Diagram). Она наглядно покажет логику процесса: начало операции, проверка наличия мест, ветвление (если мест нет — сообщить об ошибке, если есть — перейти к резервированию), переход к оплате, подтверждение и завершение процесса. Эти диаграммы переводят словесное описание в четкие, формализованные схемы, понятные любому разработчику.

5. Создание модели данных, или как правильно спроектировать базу данных

Любая информационная система работает с данными, и для их надежного хранения нужна грамотно спроектированная база данных (БД). В реляционных БД, таких как PostgreSQL, данные хранятся в таблицах, которые представляют собой сущности предметной области. Каждая сущность имеет атрибуты (поля), а между сущностями устанавливаются связи.

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

• Flights (Рейсы): атрибуты могут включать ID_рейса, номер_рейса, аэропорт_вылета, аэропорт_прилета, дата_и_время_вылета, общее_кол-во_мест.
• Passengers (Пассажиры): ID_пассажира, ФИО, паспортные_данные, контактная_информация.
• Tickets (Билеты): ID_билета, ID_рейса, ID_пассажира, номер_места, стоимость, статус.
• Bookings (Бронирования): ID_брони, ID_рейса, ID_пассажира, дата_бронирования, статус_оплаты.
• Users (Пользователи системы): ID_пользователя, логин, пароль, роль (Пассажир, Кассир, Администратор).

Связи между этими таблицами определяют логику всей системы. Например, между рейсами и билетами будет связь «один ко многим» (один рейс может иметь много проданных билетов). Точно так же один пассажир может иметь много билетов. Для визуализации этих сущностей и связей между ними используется ER-диаграмма (Entity-Relationship Diagram). Такие диаграммы удобно строить в специальных CASE-средствах, например, в ERWin. Правильно спроектированная модель данных — это залог стабильности, производительности и масштабируемости будущей системы.

6. Структура пояснительной записки по ГОСТ как каркас вашей курсовой

Проектная часть завершена. Теперь необходимо облечь всю проделанную работу в академическую форму — пояснительную записку. Чтобы не тратить время на изобретение структуры, следует придерживаться стандарта, который обычно соответствует требованиям ГОСТ. Это обеспечит логичность и полноту изложения.

Стандартная структура курсовой работы выглядит следующим образом:

1. Титульный лист: Оформляется по шаблону вашего учебного заведения.
2. Реферат: Краткое изложение содержания работы (1-2 абзаца), включающее ключевые слова, объект, цель и полученные результаты.
3. Содержание (Оглавление): Перечень всех разделов и подразделов с указанием номеров страниц.
4. Введение: Обоснование актуальности темы, постановка цели и задач исследования.
5. Основная часть: Самый объемный раздел, который обычно делится на главы. Например, теоретическая/аналитическая глава (анализ предметной области) и проектная глава (описание разработки, диаграммы, схемы).
6. Заключение: Подведение итогов, выводы о достижении поставленной цели и выполнении задач.
7. Список литературы (или список использованных источников): Перечень всех книг, статей и веб-ресурсов, на которые вы ссылались.

Следование этой проверенной структуре не только упростит написание работы, но и покажет вашу академическую грамотность.

7. Написание введения и заключения, которые задают тон и подводят итоги

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

Для введения рекомендуется использовать следующую структуру:

• Актуальность темы: Объясните, почему выбранная вами тема важна сегодня (например, рост потребности в автоматизации для повышения качества услуг).
• Постановка цели: Четко сформулируйте главный результат, который вы хотите достичь. Например: «Целью курсовой работы является проектирование информационной системы для автоматизации процесса продажи авиабилетов».
• Постановка задач: Разбейте путь к цели на конкретные шаги. Например:
  1. Проанализировать предметную область продажи авиабилетов.
  2. Выбрать и обосновать технологический стек.
  3. Спроектировать UML-диаграммы, описывающие логику системы.
  4. Разработать модель базы данных.

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

8. Наполнение основной части отчета, где теория встречается с практикой

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

Предлагается следующая структура основной части:

• Глава 1. Анализ предметной области и существующих решений. Здесь вы описываете бизнес-процессы, которые выявили на этапе анализа. Можно также провести краткий обзор существующих на рынке систем продажи билетов, чтобы обосновать свои проектные решения.
• Глава 2. Проектирование информационной системы. Это ключевая глава, куда вы помещаете все разработанные артефакты:
  • Обоснование выбора архитектуры и технологического стека.
  • Диаграммы прецедентов (Use Case), описывающие функциональные требования.
  • Диаграммы последовательности и деятельности, детализирующие ключевые алгоритмы.
  • ER-модель и описание структуры базы данных (таблицы, поля, связи).
• Глава 3. Описание пользовательских интерфейсов (если требуется). В этом разделе можно разместить эскизы или скриншоты основных экранов приложения и описать, как пользователь будет с ними взаимодействовать.

Каждый рисунок, диаграмма или таблица должны быть пронумерованы и иметь подпись. В тексте обязательно должны быть ссылки на них (например, «…как показано на Рисунке 2.1…»). Это превратит набор разрозненных материалов в целостный и убедительный технический отчет.

9. Финальное оформление и форматирование работы по всем правилам

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

• Нумерация страниц: Должна быть сквозной для всей работы. Номер страницы обычно ставится в центре нижней части листа без точки в конце. Титульный лист включается в общую нумерацию, но номер на нем не ставится.
• Оформление иллюстраций и таблиц: Все рисунки и таблицы должны быть пронумерованы арабскими цифрами (например, «Рисунок 1», «Таблица 2»). Нумерация может быть сквозной по всей работе или поглавной (например, «Рисунок 2.1»). У каждой иллюстрации и таблицы должна быть подпись, а в тексте — обязательная ссылка на нее.
• Оформление формул: Если в работе есть формулы, они нумеруются арабскими цифрами в круглых скобках справа. Пояснения всех символов приводятся сразу под формулой.
• Список литературы: Оформляется в соответствии с ГОСТ в алфавитном порядке.
• Содержание: В самом конце перепроверьте, соответствуют ли номера страниц в содержании их фактическому расположению в документе.

Внимательное отношение к этим, казалось бы, мелочам демонстрирует вашу аккуратность и уважение к академическим стандартам.

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

1. ГОСТ 34-601.89г.
2. ГОСТ 2.119-73
3. Майкл Богс «UML и Rational Rose»
4. Вендров A.M. Проектирование программного обеспечения информационных систем, 2008г.
5. Г. Смирнова. Проектирование экономических информационных систем, 2002 г.
6. Верников Г. Основные методологии обследования организаций. Стандарт IDEF0.
7. Bpwin система моделирования бизнес процессов.
8. Вендров А.М., Малышко В.В. Объектно-ориентированный анализ и проектирование с использованием языка UML , 2008г
9. Маклаков С.В. Моделирование бизнес-процессов с BPwin 4, 2006г.
10. Сибилев В.Д. Учебное пособие «Модели и проектирование БД», 2006г.