Автоматизация продажи авиабилетов "JP Airlines"

Содержание:

Введение

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

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

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

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

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

1. Основная часть

1.1. Цели

• Формирование интегрированной информационной среды, обеспечивающей автоматизированную поддержку информационных процессов по бронированию и продаже билетов компании "JP Airlines";
• Создание единого информационного поля компании, позволяющего отслеживать функционирование компании в целом.

1.2. Задачи

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

1.3. Описание предметной области

Авиакомпания занимается "JP Airlines" авиаперевозками пассажиров. Также она устанавливает маршруты полетов. Рейсы осуществляются по установленным маршрутам согласно расписанию. На каждый рейс существует определенное количество билетов. Продажа билета пользователю осуществляется при отправке запроса на бронирование, при условии, что данный билет до сих пор есть в наличии. Приобретя билет, пользователь предоставляет информацию о себе и становится пассажиром. Совершеннолетние пассажиры обязаны иметь занесенные в БД паспортные данные. Несовершеннолетние обязаны иметь занесенные в БД данные из свидетельства о рождении. Администраторы системы могут ограничивать или расширять доступ пользователей и сотрудников к предоставляемой информации. Система создаётся для обслуживания следующих групп пользователей:

• пользователи, приобретающие билеты на рейсы и осуществляющие их поиск;
• администраторы, осуществляющие контроль за пользователями и функциональностью системы;

Абсолютно каждая авиакомпания использует определенную систему дистрибуции. Наиболее развитые используют GDS (глобальные дистрибьюторские системы, которые формируются из основных международных компьютерных систем резервирования). В итоге сервисы продаж авиабилетов при поиске информации пользуются ресурсами глобальных дистрибьюторских систем. Однако доступ к GDS является не бесплатным, поэтому в роли дистрибутивной системы для разрабатываемого продукта будет выступать БД, созданная в MS SQL Server 2012[1].

В БД должна храниться информация:

• о маршрутах;
• о рейсах;
• о пользователях;
• о билетах;
• об авиакомпаниях;
• о сотрудниках;
• о пассажирах.

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

2. Анализ процессов предметной области

Модель IDEF0 представляет собой блок действия в виде прямоугольника с четырьмя различными типами стрелок, окружающим блок. Блок представляет функцию или деятельность, описанную в словесной фразе, а стрелки представляют (1) «Вход» (слева); (2) «Выход» (справа); (3) «Управление» (сверху); и (4) «Механизм» (внизу) и называются (I(input)C(control)O(output)M(mechanism)), описанный в именной фразе для объяснения поведения функции. Модель также поддерживает иерархическую декомпозицию действий для соответствующей абстракции системы. Стоит отметить, что первые три бизнес-элемента могут поддерживаться IDEF0. Например, модель IDEF0 может быть разработана с точки зрения конкретного клиента и контекста - первый элемент. Деловая активность является частью системной деятельности - второй элемент. Механизм в ICOM включает актеров - третий элемент.

Контекстная диаграмма изображается прямоугольником с входными и выходными величинами. В отличие от модели типа "Черный ящик" в прямоугольнике контекстной диаграммы указывается не название системы, а ее основная функция (цель системы). Входы и выходы контекстной диаграммы распределены не по двум, а по четырем сторонам прямоугольника. Назначение этих сторон таковы:

• левая сторона отвечает входам системы (input), величинам, которые поступают в систему и перерабатываются ней в выходные величины.
• верхняя сторона отвечает входам по управлению (control), т.е. различным управляющим действиям, командам, стратегиям поведения, процедурам, документам, регламентирующих выполнение работы и тому подобное. Эти величины не изменяются, а служат только для управления.
• правая сторона отвечает выходам системы (output), продуктам ее деятельности, результатам преобразования входных величин, вредным выделением, отходам и тому подобное.
• нижняя сторона отвечает механизмам (mechanism), а именно средствам, ресурсам, с помощью которых выполняются указанные в прямоугольнике функции.

Функциональная модель является дальнейшей детализацией (декомпозицией) контекстной диаграммы. Сначала функция системы в целом (цель, назначения, главная задача) разбивается на несколько отдельных функций (задач, работ, целей). Таких функций рекомендуется выбирать от 2 до 6. Эти функции (их иногда называют работами) (activity) изображаются на отдельном листе декомпозиции в виде функциональных блоков. Каждый функциональный блок (работа), которым выступает отдельная функция (работа, цель или задача), изображается прямоугольником. Стороны прямоугольников работ (функциональных блоков) имеют такое же назначение, что и рассмотренные выше стороны контекстной диаграммы. между отдельными функциональными блоками устанавливают связи, соответствующие логике функционирования системы. Связи между функциональными блокам изображаются стрелками (Arrow) (часто их называют дугами). Каждая дуга (стрелка) соответствует передаче от блока к блоку какого-то конкретного объекта (предмета, вещества, документа, а иногда и устного распоряжения) или их совокупности.

Дуга, которая образовалась при слиянии других дуг, соответствует всем объектам, которые содержатся в дугах к их слиянию. После разветвления дуга может соответствовать всем объектам или части из них. Для того, чтобы указать, каким именно объектам соответствует дуга, на ней ставят метку, присваивают название и сопровождают описанием объектов. Установка меток дуг, присвоение им названия и описание объектов, которым они соответствуют, должны удовлетворять определенным правилам, которые будут рассмотрены далее.

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

• вход - выход,
• управления,
• выход - механизм,
• обратная связь по управлению,
• обратная связь по входу.

Перед определением и описанием порядка построения модели следует сделать несколько замечаний:

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

2. SADT модели требуют, чтобы система рассматривалась все время с одной точки зрения, поскольку изменение точки зрения может сделать модель неадекватной. Точка зрения диктует подбор нужной информации и способ ее подачи.

3. SADT модели строятся с верхнего уровня "с головы". У них диаграммы низшего уровня являются детализированными диаграммами верхнего уровня. Конечный результат это иерархическая структура диаграмм.

В начале построения функциональной модели необходимо четко определить:

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

Цель является направлением деятельности и критерием законченности модели. Определяя цель, следует различать:

• цель системы, для которой строят функциональную модель и
• цель моделирования.

Цель системы определяет содержание модели ее конкретное наполнение.

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

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

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

На рис.2.1-2.2 представлена модель бизнес-процессов оформления продажи авиабилетов компании "JP Airlines" «КАК-ЕСТЬ».

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

Стрелы входа – заявка клиента на бронирование авиабилета;

Стрелы выхода – оформленный авиабилет;

Механизмы – менеджер авиакомпании;

Контроль – нормативные документы авиакомпании, инструкции, устав организации;

Основные процессы: Оформить клиента, Оформить бронирование, Получить оплату, Оформить авиабилет.

Рис.2.1. Главная контекстная диаграмма

Рис.2.2. Декомпозиция главной контекстной диаграммы

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

Предлагается разработка информационной системы, которая автоматизирует бизнес-процессы по оформлению бронирования и продажи авиабилетов компании. Диаграмма IDEF0 (рис.2.3) интерпретирует конечные функции после проведения декомпозиции со стороны программного продукта, где:

Стрелы входа – заявка клиента;

Стрелы выхода – оформленный авиабилет;

Механизмы – менеджер компании, ИС компании;

Контроль – нормативные документы авиакомпании, инструкции, устав организации;

Рис.2.3 – Главная родительская функция

Таблица с описанием всех объектов модели на первом уровне представлена ниже (таблица 2.1).

Таблица 2.1 - Описание объектов предметной области модели IDEF0

Элемент нотации	Имя объекта	Краткое описание объекта
1	2	3
Стрела входа	Заявка клиента	ФИО клиента, дата заказа, дата вылета, рейс, номер, статус билета.
Стела выхода	Оформленный авиабилет	ФИО клиента, дата вылета въезда, дата выезда, тип номера, стоимость проживания
Стрела контроля	Нормативные документы	Данные о правилах оформления заявок на бронирование и продажу авиабилетов
Стрела механизма	Менеджер авиакмпании	Фамилия, имя, отчество и телефон менеджера
	ИС авиакомпании

Иллюстрация декомпозиции родительской функции представлена на рис.2.4.

Рис.2.4. Декомпозиция родительской функции

Следующим аспектом функциональной модели является отображение потоков данных с помощью диаграмм DFD (Data Flow Diagramming). Эти диаграммы в функциональной модели могут дополнять то, что уже показано в IDEF0 диаграммах. Они описывают потоки данных между отдельными работами системы. Под потоками данных в данном случае понимается как материальные так и информационные потоки. Материальные потоки - это, например, сырье, материалы, заготовки, продукты производства, оборудование, транспортные средства и др. Информационные потоки - это информация о заказ, данные о состоянии рынка, о наличии сырья, запасных частей, запасы на складах, выполненные работы, узкие места в производстве,

изготовленная продукция, информация о стоимости, команды управления и др.

Диаграммы DFD - это второй из трех типов диаграмм функциональной модели, позволяющей построить программный пакет BPwin. Эти диаграммы относятся к функциональным моделей, поскольку основными элементами в них являются работы, а данные выступают как интерфейсы, которые связывают работы между собой. В отличие от IDEF0 диаграмм в них большее внимание уделяется потокам данных. Оставаясь функциональными моделями, они позволяют более детально отразить информационную сторону системы, а именно потоки данных в системе, их декомпозиции и последовательность передачи и хранения данных. Как правило, эти диаграммы включают в функциональную модель как дополнение к IDEF0 диаграмм на более низком уровне декомпозиции. Такое дополнение делает более понятными функции системы, расширяет их, детализирует в информационном аспекте.

Основные элементы диаграммы потоков данных DFD такие:

• работы (функции обработки информации);
• потоки данных (дуги входных и выходных величин)
• хранилища данных;
• внешние сущности.

Работы в DFD - диаграммы изображают функции преобразования данных в системе, в том числе материальных объектов и информации. По своей сути они совпадают с работами IDEF0 - диаграмм. Они изображаются прямоугольниками с закругленными краями. Работы в IDEF0 - диаграммах они имеют входы и выходы, но не поддерживают управления и механизмов.

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

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

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

По правилам синтаксиса дуги входных и выходных величин в DFD - диаграммы могут присоединяться к любой грани прямоугольника работы, но рекомендуется, по возможности, придерживаться установленных ранее правил, а именно, дуги входных величин изображать слева (сверху), а выходных величин - справа.

Хранилища данных служат для описания данных, которые временно не используются, находятся в неизменном, неподвижном состоянии, хранятся некоторое время. Они изображаются разомкнутым прямоугольником с отделенной правой частью.

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

Внешние сущности изображают объекты, являющиеся источниками входных и выходных величин системы. Их изображают прямоугольником с тенью, подчеркивает нахождения объекта будто вне плоскости диаграммы. Внешние сущности в диаграмме соединяют дугами подобно тому как и другие объекты (Работы и хранилища), они могут также соединяться дугами между собой. Обозначают внешние сущности буквой Е (External Reference).

Диаграммы DFD можно строить как самостоятельную модель системы или как составную часть функциональной модели. Как самостоятельную модель диаграмму DFD строят, начиная с контекстной диаграммы. В большинстве случаев диаграммы DFD включают как дополнение к функциональной модели на низких уровнях декомпозиции. Такое дополнение детализирует функциональную модель в информационном аспекте. Но следует иметь в виду, что DFD диаграммы являются функциональными диаграммами, поскольку главное внимание в них обращено на функции системы, изображаются блоком.

Рис. 2.5. Родительская диаграмма DFD

Иллюстрация родительского процесса Оформление бронирования и продажи авиабилетов представлена на рис.2.5.

Рис.2.6. Детализация родительского процесса

Иллюстрация детализации родительского процесса на три подпроцесса (подсистемы) представлена на рис.2.6.

Описание всех объектов модели на втором уровне представлены в таблице 2.2.

Таблица 2.2 - Описание объектов подсистем предметной области модели DFD

Элемент нотации	Имя объекта	Краткое описание объекта
Поток данных	Заявка клиента	Даннные клиента и заявка на бронирование и продажу билета
Внешняя сущность	Клиент	Оставляет заявку на бронирование авиабилета
	Менеджер	Осуществляет оформление заявки клиента
Хранилище данных	Реестр заявок	Содержит информацию о заявках клиентов
	Реестр клиентов	Содержит информацию о клиентах авиакомпании
	Реестр рейсов	Содержит информацию о рейсах авиакомпании
	Реестр билетов	Содержит информацию о проданных билетах

Детализация 3-4 уровней модели DFD представлены на рисунках 2.7-2.8.

Рис.2.7. Декомпозиция подпроцесса А1

Рис.2.8. Декомпозиция подпроцесса А12

3.Разработка структуры ИС

Разрабатываемая система должна содержать в себе следующие подсистемы:

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

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

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

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

3.1. Требования, свойства, ограничения ИС.

Информационная система, должна соответствовать следующим очевидным требованиям: информационная среда должна быть надежной, гибкой, легко модифицируемой, расширяемой, простой в управлении и сопровождении.[3 с.55].

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

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

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

Производительность – возможность максимальной обработки информации в единицу времени.

Оперативность – возможность работы в режиме “on-line” для осуществления мобильного доступа к информационным ресурсам и достоверного отражения текущего состояния организации.

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

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

Безопасность включает в себя несколько аспектов:

- защита данных от потерь. Реализуется на организационном, аппаратном и системном уровнях.

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

- предотвращение несанкционированного доступа. Решается комплексно организационными мероприятиями, операционной системой и прикладными системами, т.е. среда должна иметь развитые средства администрирования [5 с.93].

- предотвращение несанкционированного доступа к данным извне. – Эффективность – улучшение экономических и других целевых показателей автоматизируемого объекта.

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

Кроме этого, подразумевает возможность не только трансформации данных, но и подключение компьютеров, узоров и внешних ИС (информационных систем). [6 с.87].

3.2 Основные модули ИС

Физическая модель разработанного приложения в виде диаграммы компонентов, представленная на рисунке 3.1. Она показывает разбиение программной системы на структурные единицы и зависимости между представленными компонентами. В качестве физических компонентов могут выступать файлы, библиотеки, модули, исполняемые файлы, пакеты и т. п. Компоненты связываются через зависимости, когда соединяется требуемый интерфейс одного компонента с имеющимся интерфейсом другого компонента. Таким образом, иллюстрируются отношения клиент-источник между двумя компонентами. Зависимость показывает, что один компонент предоставляет сервис, необходимый другому компоненту [13].

Рис.3.1. Диаграмма компонентов

Диаграмма развертывания системы представлена на рисунке 3.2.

Рис.3.2. Диаграмма развертывания

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

Были разработаны классы программы, представленные на диаграмме классов (рисунок 3.3). Диаграммы классов являются центральным звеном методологии объектно-ориентированных анализа и проектирования. Диаграмма классов показывает классы и их отношения, тем самым представляя логический аспект проекта. Отдельная диаграмма классов представляет определенный ракурс структуры классов [14].

Рис.3.3 Диаграмма классов

Основные функциональные назначения каждого из классов представлены в таблице 3.1.

Таблица 3.1 – Описание разрабатываемых классов

Имя класса	Функциональное назначение
AdminForm	Класс реализует главную форму администратора системы
UsersForm	Класс реализует форму пользователя системы
AuthorizationForm	Класс реализует форму авторизации в системе
ChangePasswordForm	Класс реализует форму для смены пароля
ClientTableForm	Класс реализует форму для отображения приобретенных пользователем билетов
ChangeColorStyle	Класс реализует форму для изменения цветовой гаммы системы
PaymentForm	Класс реализует форму для бронирования билета
FlightSearchForm	Класс реализует форму для поиска информации о билетах
RegistrationForm	Класс реализует форму для регистрации нового пользователя

Основной функцией разработанной информационной системы является реализация авиабилетов. Алгоритм работы данного прецедента показан при помощи диаграммы последовательности. Данный вид диаграмм используется, когда возникает необходимость не только представить процесс изменения ее состояний, но и детализировать особенности алгоритмической и логической реализации выполняемых системой операций. На рисунке 3.4 изображена диаграмма последовательности.

Рис.3.4 Диаграмма деятельности для прецедента «Продажа авиабилета»

В данной главе была описана реализация серверного программного обеспечения на стороне сервера журнализации событий. Основные задачи, описанные в предметной области были выполнены.

4. Структура базы данных (БД)

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

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

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

Физическая модель данных оперирует категориями, касающимися организации внешней памяти и структур хранения, используемых в данной операционной среде. В настоящий момент в качестве физических моделей используются различные методы размещения данных, основанные на файловых структурах: это организация файлов прямого и последовательного доступа, индексных файлов и инвертированных файлов, файлов, использующих различные методы хеширования, взаимосвязанных файлов. Кроме того, современные СУБД широко используют страничную организацию данных. Физические модели данных, основанные на страничной организации, являются наиболее перспективными [12]. Логическая и физическая модели базы данных информационной системы продажи авиабилетов представлены на рисунках 4.1 и 4.2, соответственно.

Рис.4.1. Логическая модель базы данных продажи авиабилетов

Рис.4.2. Физическая модель базы данных продажи авиабилетов

5. Графический интерфейс

На основе постановки задачи были разработаны следующие экранные формы:

• форма авторизации для входа в систему;
• форма регистрации для занесения данных нового пользователя в базу данных;
• форма поиска информации по рейсам и билетам;
• форма для осуществления бронирования билета;
• форма администрирования информационной системы, доступная пользователям группы «Администратор»;
• форма «Личный кабинет», доступная пользователям группы «Обычный пользователь».

На рисунке 5.1 представлена форма авторизации.

Рис.5.1. Форма авторизации в систему

Форма регистрации нового пользователя системы представлена на рисунке 5.2.

Рис.5.2. Форма регистрации нового пользователя

Форма поиска информации по билетам представлена на рисунке 5.3.

Рис.5.3. Форма поиска информации в системе

Форма осуществления бронирования билета представлена на рисунке 5.4.

Рис.5.4. Форма осуществления бронирования билета

На рисунке 5.5 представлена форма, предназначенная для администрирования информационной системы.

Рис.5.5. Форма для администрирования системы

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

Рис.5.6. Личный кабинет пользователя

Заключение

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

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

• авторизация пользователя;
• регистрация пользователя;
• поиск билетов для бронирования;
• бронирование билета;
• редактирование БД продаж авиабилетов, доступное пользователям группы «Администратор»;
• распределение прав доступа пользователей, доступное пользователям группы «Администратор»;
• личный кабинет пользователя, содержащий статистику по совершенным покупкам.

В ходе тестирования разработанной информационной системы было продемонстрировано, что система выполняет все поставленные задачи в соответствии со сформированными требованиями в разделе «Постановка задачи на разработку», демонстрируя корректную работу.

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

1. Электронный билет (воздушный транспорт) [Электронный ресурс] – Режим доступа:http://ru.wikipedia.org/wiki/Электронный_билет_(воздушный_транс порт) (Дата обращения: 05.06.2020).

2. Системы бронирования авиабилетов [Электронный ресурс] – Режим доступа: http://www.flyworld.ru/stati/sistemy-bronirovaniya-aviabiletov/ (Дата обращения: 05.06.2020).

3. Amadeus [Электронный ресурс] – Режим доступа: http://support.nemo.travel/ru/Amadeus (Дата обращения: 05.06.2020).

4. Travelport (Galileo) [Электронный ресурс] – Режим доступа: http://support.nemo.travel/ru/Travelport_(Galileo) (Дата обращения: 05.06.2020).

5. Авиабилеты.IT системы бронирования [Электронный ресурс] – Режим доступа: https://habrahabr.ru/company/buruki/blog/192384/ (Дата обращения: 05.06.2020).

6. Возможности Немо [Электронный ресурс] – Режим доступа: https://nemo.travel/bazovye-vozmozhnosti-nemo.html (Дата обращения: 05.06.2020).

7. Либерти, Дж. Создание .NET приложений Программирование на C#. – СПб.: Орейли, 2006.

8. Троелсен Э. C# и платформа .NET. Библиотека программиста. – СПб.: Питер, 2007.

9. Клайн К. SQL справочник. 2-е издание. – М.: «КУДИЦ-ОБРАЗ», 2006.

10. Р. Фрост, Д. Дей, К. Ван Слайк; пер. с англ. А.Ю. Кухаренко. Проектирование и разработка баз данных. Визуальный подход – М.: НТ Пресс, 2007.

11. Лекция 3. Архитектура ИС [Электронный ресурс] – Режим доступа: http://it-claim.ru/Education/Course/ISDevelopment/Lecture_3.pdf (Дата обращения: 06.06.2020).

12. ERwin Data Modeler [Электронный ресурс] – Режим доступа: https://ru.wikipedia.org/wiki/ERwin_Data_Modeler (Дата обращения: 06.06.2020).

13. Фаулер М. UML в кратком изложении. Применение стандартного языка объектного моделирования / Фаулер М., Скотт К. – М.: «Мир», 1999.

14. Крэг Л. Применение UML и шаблонов проектирования. – М.: Издательских дом «Вильямс», 2004.