главная полезно рефераты ссылки сатьи контакты

Внимание!!!
Все материалы сайта защищены авторским правом, содержат на момент размещения не менее 60% оригинального текста. Материалы предназначены только для выполнения собственной студенческой работы. Любое воспрозведение или иное использование запрещено законом
Кроме того, просим терпимее относиться ко всем видам рекламы на сайте. Так как за счет её и существует наш проект. Спасибо за понимание и удачи вам в поиске нужной информации.


Разработка подсистемы учёта и регистрации бронирования авиабилетов (Программирование на Java)

СОДЕРЖАНИЕ

 

ВВЕДЕНИЕ. 2

1. ОПИСАНИЕ ПРЕДМЕТНОЙ ОБЛАСТИ И КЛАССИФИКАЦИЯ СУЩНОСТЕЙ РЕШАЕМОЙ ЗАДАЧИ.. 4

1.1. Пассажир. 5

1.2. Место отдыха (пункт назначения) 5

1.3. Резервация. 5

1.4. Этапы организации хранилища информации о бронировании авиабилетов  6

2. ПОСТАНОВКА ЗАДАЧИ.. 9

3. ОБЗОР ЛИТЕРАТУРНЫХ ИСТОЧНИКОВ.. 10

4. ТРЕБОВАНИЯ К СИСТЕМЕ. 12

5. РАЗРАБОТКА МЕТОДОВ И МОДЕЛЕЙ ПРЕДСТАВЛЕНИЯ СИСТЕМЫ.. 13

6. РАЗРАБОТКА И ПОСТРОЕНИЕ ИНФОРМАЦИОННОЙ МОДЕЛИ   18

7.ОБОСНОВАНИЕ ПРИНИМАЕМЫХ РЕШЕНИЙ ПО ВЫБОРУ ТЕХНИЧЕСКИХ И ПРОГРАМНЫХ СРЕДСТВ РЕАЛИЗАЦИИ.. 22

8. ОПИСАНИЕ АЛГОРИТМОВ ПРОГРАММНЫХ МОДУЛЕЙ   24

9. ОПИСАНИЕ ТЕСТОВОГО ПРИМЕРА И РУКОВОДСТВА ПОЛЬЗОВАТЕЛЯ   26

10. ОПИСАНИЕ ПОЛУЧЕННЫХ РЕЗУЛЬТАТОВ.. 33

ВЫВОДЫ И ЗАКЛЮЧЕНИЯ.. 34

ЛИТЕРАТУРА.. 35

ПРИЛОЖЕНИЯ.. 36


ВВЕДЕНИЕ

 

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

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

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

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

Разрабатываемая подсистема должна быть реализована на основе современных технологий, а именно технологий, предоставляемых J2EE. Их использование позволяет существенно повысить производительность, надежность, расширяемость и масштабируемость разрабатываемого программного обеспечения.

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

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

Из современных технологий в ходе разработки необходимо использовать EJB, JSP, Servlets, SYBASE 9.0, сервер приложений SunApp Server 8.0 и DHTML (Java script).


1. ОПИСАНИЕ ПРЕДМЕТНОЙ ОБЛАСТИ И КЛАССИФИКАЦИЯ СУЩНОСТЕЙ РЕШАЕМОЙ ЗАДАЧИ

 

Кратко рассмотрим предметную область автоматизируемой задачи.

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

Бронирование билета осуществляет продавец авиакасс.

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

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

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

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

1) пассажир приходит в авиакассы и сообщает о своем желании забронировать определенное количество билетов

2) продавец уточняет существование рейса в требуемый пассажиру город, уточняет наличие свободных мест на требуемый рейс на нужное число

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

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

 

1.1. Пассажир

Данная сущность содержит информацию о пассажирах и содержит следующие атрибуты:

- полное имя пассажира,

- номер паспорта пассажира.

1.2. Место отдыха (пункт назначения)

Данная сущность содержит данные о местах отдыха и характеризуется названием пункта назначения.

1.3. Резервация

В данной сущности храниться данные о бронировании полетов.

Сущность имеет следующие атрибуты:

- пассажир, бронирующий билет

- конечный пункт назначения

- дата бронирования,

- дата вылета

- номер регистрации.


1.4. Этапы организации хранилища информации о бронировании авиабилетов

 

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

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

Например:

1.     Пассажир называет вслух свои паспортные данные.

2.     Кассир записывает данные пассажира в журнал.

3.     Кассир производит поиск свободных мест на рейсе,  просматривая журнал и т.п.

В данном случае возможными «узкими местами» могут быть:

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

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

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

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

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

Обследование – подразумевает сбор данных и полный анализ бизнес-процессов. 

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

Реализация проекта – разработка подсистемы учёта и регистрации бронирования авиабилетов.

Тестирование проекта – необходимо при разработке ПО такого уровня.

Внедрение подсистемы учета и регистрации бронирования авиабилетов – в данной ситуации предпочтительнее всего производить внедрение силами разработчика. Надежность системы бронирования не должна страдать из-за возможного недостатка компетенции отделов и служб автоматизации аэропорта (авиакасс).

Обучение пользователей – для подобной задачи является неотъемлемой частью процесса внедрение ПО.

Эксплуатация и сопровождение – основная стадия использования ПО в модели жизненного цикла ПО.

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

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

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

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

 


2. ПОСТАНОВКА ЗАДАЧИ

 

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

·                    проанализировать предметную область, задачи которой подлежат автоматизации;

·                    провести моделирование бизнес-процессов рассматриваемой предметной области в рамках методологии IDEF0 с использованием BpWin;

·                    разработать информационную модель системы (структуру базы данных)  при помощи подхода ER и инструментального средства ErWin;

·                    создать базу данных подсистемы бронирования и наполнить ее начальной информацией;

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

·                    провести моделирование процесса работы подсистемы учета бронирования авиабилетов с использованием языка моделирования UML;

·                    определить требуемые для реализации приложения технологии в рамках архитектуры J2EE;

·                    выбрать и провести краткий аналитический обзор литературных источников;

·                    Разработка подсистемы учета и регистрации бронирования авиабилетов;

·                    протестировать программу с использованием разработанной БД;

·                    описать алгоритмы программных модулей;

·                    описать тестовый пример, разработать руководство пользователя;

·                    описать полученные результаты в виде пояснительной записки;

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


3. ОБЗОР ЛИТЕРАТУРНЫХ ИСТОЧНИКОВ

 

1. Дейтел П.Дж., Дейтел Х.М.  Как программировать на Java. Книга 2. Файлы, сети, базы данных [5] ориентирована на тех читателей, у которых уже есть определенный (хотя бы элементарный) опыт программирования на языке Java. В книгу включены не только главы, относящиеся к «стандартной» тематике, которая обычно не рассматривается в начальных курсах по Java (сюда можно отнести управление исключениями и параллельными потоками, работу с файлами), но и главы, посвященные вопросам, считающимся специальными или «углубленными». Это главы по сетевому программированию (организация систем типа клиент/сервер), связи с базами банных посредством унифицированной схемы JDBC. Обсуждаются также некоторые вопросы и приемы программирования мультимедиа (анимации и звука). Весь изучаемый материал сопровождается содержательными примерами «живого кода. В необязательных разделах глав дается обзор типичных объектно-ориентированных схем проектирования и последовательно разрабатывается пример объектно-ориентированного проектирования большой системы на основе унифицированного языка моделирования (UML).

2. Фельдман С.К. Система программирования Java без секретов: Как создать безопасное приложение с "нуля" [4] простое и доступное пособие по языку программирования Java. В книге изложены не только тонкости языка программирования Java, но и в систематизированном виде рассматриваются технологии создания Интернет-приложений на основе этого языка, поэтому данное издание также окажет помощь пользователям ПК, которые специализируются на создании приложений для Интернет в системе программирования Java.

3. Р. Мюллер. Базы данных и UML: Проектирование [3]. Книга посвящается использованию универсального языка моделирования UML (одобренный стандарт группы по управлению объектами) для проектирования баз данных. Подробно, шаг за шагом, раскрыт процесс разработки: от анализа требований к генерации схемы. Особо уделяется внимание вопросу выражения потребностей заказчиков в диаграммах вариантов использования UML и ролей. Книга раскрывает вопрос преобразования сущностей UML в компоненты базы данных, преобразования полученный проект в реляционные, объектно-реляционные и объектно-ориентированные схемы для основных продуктов DBMS.

Раскрыты практические примеры проектов для Oracle, Microsoft, Sybase, Informix, Object Design, POET и других систем управления базами данных.

4. «Mastering Enterprise JavaBeans» Ed. Roman, Scott Ambler. Книга предназначена для программистов, интересующихся разработкой и внедрением J2EE-приложений. Здесь описаны основные компонентные технологии, составляющие платформу J2EE, а также как разработать и установить J2EE-компоненты, используя инструментарий разработчика J2EE SDK.

Электронный ресурс [8] детально описывает особенности разработки методов, объявления массивов, организации циклов, ввода вывода, создания классов и пр., что, безусловно, очень сильно помогло в написании курсового проекта (разработке кода).

 


4. ТРЕБОВАНИЯ К СИСТЕМЕ

 

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

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

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

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

·                    должна быть реализована возможность получать обработанные результаты в виде отсортированных или сгруппированных записей;

·                    должна быть реализована возможность поиска записей о бронировании билетов по дате вылета рейса;

·                    должна быть реализована возможность удаленной работы с приложением (веб-клиент) посредством Интернет-браузера клиента;

·                    целевая операционная система – произвольная, допускающая установку сервера приложений Sun (сервер) и JSDK 1.4 или более поздней (сервер);

·                    возможность работы с системой при помощи произвольного распространенного на сегодняшний день Интернет-браузера – Netscape, IE, Opera, Mozilla, Maxton и т.п.

·                    подсистема бронирования билетов должна опираться на технологии EJB, JSP, Servlets, DHTML;

·                    в качестве базы данных должна использоваться SQL SYBASE 9.0;

·                    в качестве J2EE-сервера  должен использоваться сервер приложений SunApp Server 8.1.


5. РАЗРАБОТКА МЕТОДОВ И МОДЕЛЕЙ ПРЕДСТАВЛЕНИЯ СИСТЕМЫ

 

В работе проводится моделирование с использование IDEF0(BPWin), UML (Enterprise Archtect), IDEF1x (ErWin).

1. Важная роль отводится процессу функционального проектирования.

Для регламентирования создания функциональных моделей ПС предназначен стандарт IDEF0 (Integrated Definition Function Modeling), который и реализован в пакете BpWin.

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

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

В основе IDEF0 лежит три базовых принципа:

1) принцип функциональной декомпозиции – любая функция может быть разбита (декомпозирована) на более простые функции (более понятен термин детализация);

2) принцип ограничения сложности – количество блоков на диаграмме должно быть не менее двух, но не более шести (условие удобочитаемости);

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

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

Под субъектом понимается сама система, при этом необходимо точно установить, что входит в систему, а что является внешним воздействием на систему. Т. е. первоначально нужно определить область моделирования. Описание области как системы в целом, так и ее компонентов является основой построения модели.

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

Для примера рассмотрим далее контекстную диаграмму модели процесса учета и регистрации бронирования авиабилетов.

Модель строилась на основании точки зрения (предполагаемой, в связи с нехваткой данных) кассира авиакасс.


На модели изображены следующие:

1)    Входы:

- пожелания пассажира – пожелание пассажира по поводу пункта назначения, времени и дате рейса и т.п.

- сведения о пассажире – паспортные данные пассажира.

- список рейсов – список рейсов авиакомпаний, билеты на которые можно забронировать или приобрести в кассах

- время – все этапы процесса учета бронирования требуют времени. Поэтому Даная дуга является туннельной со скрытым приемником.

 

2)    Выходы:

- запись о забронированном билете – сведения о бронировании учтены

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

3)    Контрольные дуги:

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

4)    Дуги механизмов:

- пассажир – определяет нужный рейс и т.п.

- кассир – регистрирует сведения о пассажире, учитывает бронирование или продажу билета и т.п.

 

Рис. 1. Контекстная диаграмма модели IDEF0 процесса учета бронирования авиабилетов

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

Дадим некоторые пояснения касательно диаграммы. Контроль – правила бронирования авиабилетов – изображены в виде туннельной дуги со скрытым приемником. Это означает, что дуга будет отсутствовать на дочерней диаграмме, но согласно правилам стандарта IDEF0, она будет считать КОНТРОЛЬНОЙ дугой ДЛЯ ВСЕХ блоков дочерней диаграммы, хотя дуга и отсутствует на ней. Такие туннельные дуги используются для упрощения понимания диаграмм.

Входная дуга «Время» также является дугой со скрытым приемником. Это обусловлено тем, что все этапы процесса бронирования билета требуют времени и дуга должна подаваться на вход СЕХ блоков дочерней диаграммы. Пометка этой дуги как туннельной и удаление ее в связи с этим с дочерней диаграммы упрощает восприятие модели.

2. Унифицированный язык моделирования (UML - Unified Modeling Language) является стандартным инструментом для создания пассажирированных каркасов ("чертежей") программного обеспечения. С помощью UML можно визуализировать, специфицировать, конструировать и пассажирировать процесс разработки программных систем.

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

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

В приложении продемонстрированы диаграммы последовательности, диаграмм классов, кооперирования, состояния и использования.

Рассмотрим, например, диаграмму вариантов использования разрабатываемой подсистемы:

 

 

Рис. 2. Диаграмма вариантов использования подсистемы учета и регистрации бронирования авиабилетов

 

На диаграмме отображены возможности, предоставляемые пользователю системы (кассиру) разрабатываемым программным средством. Данная диаграмма вариантов использования относится к пакету Use case model и содержит описание возможностей, предоставляемых конкретному пользователю системы ПРОГРАММНЫМ СРЕДСТВОМ (не бизнес-модель)/

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

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

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


6. РАЗРАБОТКА И ПОСТРОЕНИЕ ИНФОРМАЦИОННОЙ МОДЕЛИ

 

При построении информационной модели применялся стандарт IDEF1x, поддерживаемый инструментальной средой Erwin фирмы LogicWorks . ERWin‑ средство разработки структуры базы данных (БД). ERwin сочетает графический интерфейс Windows, инструменты для построения ER-диаграмм, редакторы для создания логического и физического описания модели данных и прозрачную поддержку ведущих реляционных СУБД и настольных баз данных.

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

Диаграмма ERwin строится из трех основных элементов - сущностей, атрибутов и связей. Если рассматривать диаграмму как графическое представление правил предметной области, то сущности являются существительными, а связи — глаголами.

Сущность - логическое понятие. Сущности соответствует таблица в реальной СУБД. В ERwin сущность визуально представляет 3 основных вида информации:

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

·                   не ключевые атрибуты;

·                   тип сущности (независимая/зависимая).

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

·                   связи (идентифицирующая/ неидетифицирующая), полная/неполная категория, специфическая связь);

·                   родительская сущность;

·                   дочерняя (зависимая) сущность;

·                   мощность связи (cardinality);

·                   допустимость пустых (null) значений.

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

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

Целевая СУБД, имена объектов и тины данных, индексы составляют второй (физический уровень модели Erwin).

Процесс построения информационной модели состоит из следующих шагов:

·                   определение сущностей;

·                   определение зависимостей между сущностями;

·                   задание первичных и альтернативных ключей;

·                   определение атрибутов сущностей;

·                   приведение модели к требуемому уровню нормальной формы;

·                   переход к физическому описанию модели - назначение соответствий: имя сущности — имя таблицы, атрибут сущности — атрибут таблицы; задание триггеров, процедур и ограничений;

·                   генерация базы данных.

 

В процессе разработки информационной модели системы первым делом должен был быть осуществлен импорт (import) функциональной модели (точнее, словаря сущностей, атрибутов и информацию предметной области) из Bpwin в Erwin. Далее необходимо было установить связи между сущностями и определить ключевые атрибуты.

Однако, в связи с нежелательностью использования русских букв в названиях таблиц и атрибутов, процесс создания информационной модели производился НЕЗАВИСИМО от модели BpWin.

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

1.     Passanger – сведения о пассажирах.

2.     City – сведения о пунктах назначения.

3.     Reservation – сведения о бронировании авиабилетов определенными пассажирами.

В качестве связей между таблицами были определены:

- связь «один-ко-многим» пассажир-бронирование – пассажир может бронировать несколько билетов на разные места одного рейс или одинаковые места разных рейсов, но каждый билет бронируется только одним пассажиром.

- связь «один-ко-многим» город-бронирование – каждый билет имеет только один пункт назначения, но могут быть забронированы разные билеты с одним и тем же пунктом назначения.

Атрибуты таблиц соответствуют описанных в ходе анализа предметной области атрибутам сущностей.

Дополнительные ограничения целостности кроме ограничений NOT NULL для всех атрибутов и ограничений UNIQUE индексов первичных и внешних ключей не создавались.

После разработки информационной структуры в ErWin было осуществлено подключение к базе данных Sybase и генерация в форме forward engineering базы данных, хранящей таблицы, содержащие информацию о бронировании билетов.


7. ОБОСНОВАНИЕ ПРИНИМАЕМЫХ РЕШЕНИЙ ПО ВЫБОРУ ТЕХНИЧЕСКИХ И ПРОГРАМНЫХ СРЕДСТВ РЕАЛИЗАЦИИ

 

В ходе общения с коллегами к программным средствам, выбранным для решения поставленной перед задачи, были выбраны:

·                    Enterprise Architect

·                    Sun AppServer 8

·                   IDE NetBeans 5.5

Enterprise Architect - это набор UML-инструментов для разработки программного обеспечения через стадии анализа, модели дизайна, испытания и внедрения. Как показал собственный опыт, Enterprise Architect очень удобен в использовании и полностью поддерживает синтаксис UML 2.0.

Одним из наилучших подходов при разработке сложных корпоративных предложений является выбор для разработки платформы J2EE.

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

Платформо-независимые, основанные на компонентах J2EE-решения больше не привязаны к продуктам и API какого-либо одного производителя. Производители и пользователи обладают свободой выбора продуктов и компонентов, которые наиболее полно удовлетворяют их деловые и технологические требования. Поэтому в  качестве сервера был выбран свободно распространяемый сервер приложений от создателей языка Java - Sun AppServer 8.

Объединяет все компоненты платформы J2EE язык программирования JAVA — весьма популярный в настоящее время язык программирования, обладающий большой гибкостью и обеспечивающий поддержку объектно-ориентированного программирования. Самым главным его козырем является платформенная независимость, т.е. код, написанный в среде Windows, без всяких изменений будет работать в среде Linux и т.п. Это обеспечивается тем, что скомпилированные файлы JAVA представляют собой не самостоятельно исполняемый код, а так называемый байт-код, который исполняется виртуальной машиной JAVA, индивидуальной для каждой платформы.

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


8. ОПИСАНИЕ АЛГОРИТМОВ ПРОГРАММНЫХ МОДУЛЕЙ

        

Обобщенный алгоритм работы клиента показан на рис. 1.

Рис. 3. Обобщенный алгоритм работы

Алгоритм обработки действий пользователя:

o        Пользователь вводит в браузере адрес страницы или нажимает на гиперссылку

o        Браузер посылает запрос на сервер

o        В случае доступности сервера вызывается соответствующая JSP-страница

o        Страница обращается к серверным компонентам бизнес-уровня, отвечающим за работу с данными

o        Страница отображает результаты обработки данных (поиск, результаты удаления и т.п.)

o        Клиент просматривает результаты действия в окне браузера.

 

 


9. ОПИСАНИЕ ТЕСТОВОГО ПРИМЕРА И РУКОВОДСТВА ПОЛЬЗОВАТЕЛЯ

 

Для запуска разработанного программного средства вначале необходимо зарегистрировать в настроить connection pool для сервера базы данных с именем reservationPool и JNDI-name для базы с именем jdbc/reservation.

Подключение производиться по url:

http://localhost:8080/reservation/index.jsp

Работать осуществляется в поддерживающем JavaScript 1.2 Интерне-браузере.

При запуске клиента появляется окно, показанное на рис. 4. На данном рисунке видны возможности, которыми обладает клиент.

Рис. 4. Основное окно веб-клиента.

Логика приложения организована следующим образом. Отображены 3 сущности с соответствующими им кнопками управления:

1.     Список пунктов назначения

2.     Список пассажиров

3.     Проведенные регистрации

Возможности добавления, корректировки и удаления записей реализуется по средствам кнопок (рис.5).

Рис. 5. Выбор добавления мест отдыха.

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

Рис. 6. Форма заполнения данных по месту отдыха.

Результат ввода представлен на рис. 7.

Рис. 7. Отображение результатов ввода.

Выберем запись для корректировки (рис.8).

Рис.8. Выбор записи для корректировки.

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

Рис. 9. Корректировка записи.

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

Рис. 10. Результат корректировки записи.

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

Рис. 11. Форма, подтверждения удаления записи.

Чтобы  добавить новую запись по пассажиру, необходимо нажать на 1-ую кнопку из перечня кнопок, реализующим работу с записями по ювелирным пассажиру (рис. 12).

Рис.12. Добавление записи по пассажиру

Как только мы нажали кнопку, мы переходим на форму ввода новых данных (рис.13).

Рис. 14. Добавление новой записи по пассажиру

Результат ввода представлен на рис. 14.

Рис. 14. Результат добавления пассажира.

Чтобы откорректировать запись о пассажире необходимо нажать соответствующую кнопку (рис. 15).

Рис. 15. Выбор для корректировки записи о пассажире.

Чтобы удалить запись необходимую запись, выбираем строку в таблице и нажимаем на кнопку удаления (рис. 16).

Рис. 16. Выбор записи для удаления.

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

Рис. 17. Данные по удаляемой записи.

Вывод регистрации пассажиров осуществляется 3-мя способами:

1.     Вывод всех регистраций по месту отдыха (рис. 18)

2.     Вывод всех регистрации по пассажиру (рис. 19)

3.     Вывод всех регистрации по месту отдыха и пассажиру (рис. 20)

Рис. 18. Вывод всех регистраций по мест отдыха.

Рис. 19 Вывод всех регистрации по пассажиру.

Рис. 20. Вывод всех регистрации пассажиров по месту отдыха и пассажиру.

Для поиска записей о бронировании билетов по дате бронирования билета или дате вылета можно воспользоваться соответствующими текстовыми полями и кнопкой «Поиск по датам».

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

Рис. 21. Добавление данных по регистрациям.

Как только мы нажали данную кнопку, мы переходим на форму ввода новых данных (рис.22).

               

Рис. 22.Добавление записи.

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

Рис. 23. Выбор удаления записи.

 


10. ОПИСАНИЕ ПОЛУЧЕННЫХ РЕЗУЛЬТАТОВ

 

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

Разработка подсистемы велась в строгом соответствии с разработанными до этого моделями представления подсистемы – BpWin, ErWin и UML.

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

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

1.           Возможность формирования скидок для постоянных клиентов.

2.           Регистрация билетов на различные классы (1-й, бизнес и т.п.).

3.           Возможность предварительного заказа завтрака/обеда в ходе полета в процессе бронирования.

4.           Печать квитанций о заказанных билетах и т.п.

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

Дополнительно в результате выполнения данного курсового проекта были закреплены на практике навыки в работе с языком  JAVA, UML, методиками проектирования IDEF0, IDEF1x, приемами использования СУБД SQL Anywhere 9 и технологией EJB .


ВЫВОДЫ И ЗАКЛЮЧЕНИЯ

 

В ходе выполнения курсового проекта была разработана подсистема учёта и регистрации бронирования авиабилетов. Программа реализована с использованием языка программирования Java, технологий J2EE и Sun AppServer 8 / SQL Anywhere 9. Реализован веб-клиент.

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

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

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

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

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

 


ЛИТЕРАТУРА

 

1. Леоненков. «Самоучитель UML».

2. http://www.ianywhere.com/

3. Р. Мюллер. Базы данных и UML: Проектирование.– Лори, 2002г. 432 с.

4. Фельдман С.К. Система программирования Java без секретов: Как создать безопасное приложение с "нуля". – Новый издательский дом" , 2005 г. , 347 с.

5. Дейтел П.Дж., Дейтел Х.М.  Как программировать на Java. Книга 2. Файлы, сети, базы данных. – "Бином" · 2005 г., 672 с.

6. http://www.avacco.ru/page.asp?code=electronniy_arhiv

         7.

 


Внимание! Для данной работы приложения платные. С их описанием и стоимостью можно ознакомиться здесь

Описание приложений!



Скачать курсовую

Задать вопрос                                                      




Если у вас появилось непреодолимое желание пожертвовать средства на развитие сайта или отблагодарить владельца за бесценный материал :), можете перевести любую сумму на кошелек R200818721914 или Z890150328460.

© studlight 2011-2014