Главная Полезно Рефераты‹ Ссылки Статьи Контакты

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


Разработка программы по учету продаж авиабилетов на java

СОДЕРЖАНИЕ

ВВЕДЕНИЕ  3

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

1.1 Город  5

1.2 Рейс  5

1.3 Пассажир  5

1.4 Билет  5

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

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

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

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

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

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

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

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

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

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

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

ЛИТЕРАТУРА  34

ПРИЛОЖЕНИЯ  35



ВВЕДЕНИЕ


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

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

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

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

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

Целью работы является разработка программы учета и регистрации продаж авиабилетов. Программа должна быть организована согласно принципам архитектуры «клиент-сервер», клиент должен взаимодействовать с сервером по протоколу TCP/IP. Данные должны храниться посредством СУБД Sybase 9.0..


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


Приведем краткое описание рассматриваемой предметной области.

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

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

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

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

  1. Город – информация о городах назначения авиарейсов.
  2. Пассажир – сведения о покупателях авиабилетов.
  3. Рейс – сведения о рейсах.
  4. Билет – сведения о проданных пассажирам на определенные рейсы билетах.

1.1 Город


Сущность содержит информацию о городах назначения авиарейсов и характеризуется названием города.

1.2 Рейс


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

- уникальный номер рейса;

- город назначения;

- дата вылета;

- общее количество мест на рейс;

- оставшееся количество мест;

- стоимость билета на данный рейс.

1.3 Пассажир


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

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

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

1.4 Билет


Содержит в себе информацию о купленных пассажирами билетах на определенные рейсы и имеет следующие атрибуты:

- пассажир;

- рейс;

- номер места купленного билета.



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


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

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

Например:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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


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


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

  • выбрать и провести краткий аналитический обзор литературных источников по используемым технологиям и средствам (программирование на Java и архитектура клиент-сервер, моделирование BpWin, ErWin и UML, СУБД Sybase);
  • разработать методы и модели представления системы;
  • разработать информационную модель подсистемы (структуру базы данных) учета продаж авиабилетов;
  • наполнить разработанную БД соответствующей информацией о городах, авиарейсах, пассажирах и продажах билетов;
  • разработать серверную часть приложения;
  • разработать клиентскую часть приложения по учету продаж авиабилетов;
  • протестировать программу с использованием разработанной БД;
  • описать алгоритмы программных модулей;
  • описать тестовый пример, руководство пользователя;
  • описать полученные результаты;
  • оформить пояснительную записку;
  • сделать выводы по ходу выполнения курсовой работы.


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


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

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

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

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

Б. Хичков SYBASE: Настольная книга администратора [2]. Книга содержит подробное изложение основных операций администрирования серверов Sybase, полезные подсказки, конкретные советы. Рассматривается Sybase SQL Server версий 4.9.2, System 10 и System 11.

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


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


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

  • должна быть реализована добавления и удаления записей о городах назначения;
  • должна быть реализована добавления, удаления и редактирования записей о покупателях билетов (пассажирах);
  • должна быть реализована добавления, удаления и редактирования записей о предстоящих рейсах;
  • должна быть реализована добавления и удаления записей о продажах билетов на рейсы;
  • должна быть предусмотрена возможность сортировки записей о пассажирах по полному имени пассажира;
  • должна быть реализована возможность поиска записей о пассажирах по подстроке полного имени пассажира;
  • должна быть реализована возможность поиска записей о продажа билетов на определенный рейс;
  • должна быть реализована возможность удаленной работы с данными в архитектуре клиент-сервер;
  • хранение данных должно быть обеспечено средствами СУБД Sybase;
  • для доступа к данным сервер должен использовать протокол JDBC;
  • взаимодействие клиента и сервера должно осуществляться посредством протокола TCP/IP.


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


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

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

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

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

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

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

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

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

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

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

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

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

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

Цель модели – моделирование процесса учета и регистрации продаж авиабилетов.

Точка зрения модели – работник авиационных касс (кассир).

Рис. 1 Контекстная диаграмма модели


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

  1. Входы:

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

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

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

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

- деньги – процесс покупки билета требует оплаты билета пассажиром.

  1. Выходы:

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

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

  1. Контрольные дуги:

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

  1. Дуги механизмов:

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

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

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

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

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

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

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




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


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

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

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

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

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

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

  • связи (идентифицирующая/ неидетифицирующая), полная/неполная категория, специфическая связь);
  • родительская сущность;
  • дочерняя (зависимая) сущность;
  • мощность связи (cardinality);
  • допустимость пустых (null) значений.

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

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

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

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

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

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

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

В ходе построения модели было предложено следующее решение:

Рис.2 Моделирование IDEF1x – логический уровень

В модели присутствуют 3 идентифицирующих связи «один-ко-многим». Данные связи были выбраны по следующим соображениям:

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

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

3. На один и тот же рейс может быть продано несколько билетов, но каждый билет действителен только для одного и того же, единственного рейса.


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


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

  • Enterprise Architect
  • JBuilder 7.0.

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

Enterprise Architect объединяет в себе силу языка UML 2.0 с высокоэффективным, понятным интерфейсом. Данная программа дает возможность расширенного моделирования на рабочем столе, разработки и созданию групп. Поддержка для всех 13 UML 2.0.

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

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



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

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



Рис. 3. Алгоритм работы клиента


Рис. 4. Алгоритм работы сервера



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


Для запуска разработанного программного средства вначале необходимо зарегистрировать при помощи Sybase Central базу данных приложения «tickets.db» и создать сетевой сервис, обслуживающий подключения к базе данных при помощи JDBC.

Затем для запуска сервера и клиента, соответственно, необходимо использовать bat-файлы «server.bat» и «client.bat» в директориях сервера и клиента. Дополнительно в файле «server.bat» необходимо прописать ряд дополнительных параметров командной строки для соединения с базой данных:

<server_host>      - имя хоста, на котором запущен сервер баз данных Sybase

<server_port>      - номер порта, на котором сервер БД Sybase ожидает клиентские подключения

<database_name>    - название базы данных

[user]             - необязательный параметр, имя пользователя для соединения с БД (dba - умолчание)

[password]         - необязательный параметр, пароль для соединения с БД (sql - умолчание)

[port]             - необязательный параметр, задает порт, на котором наш сервер ожидает клиентские подключения (5678 - умолчание)

<обязательные параметры>

[опциональные параметры]

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

При запуске клиента появляется окно, показанное на рис. 5.

На рис. 5 видны возможности, которыми обладает клиент. Функциональные возможности приложения обеспечиваются двумя списками и выпадающим списком:

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

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

Рис. 5. Стартовое окно клиента «Учет продаж авиабилетов»

Для добавления города необходимо нажать кнопку «Добавить…» справа от списка городов. Откроется диалог добавления города:

Рис. 6. Диалог добавления города

После добавления города список городов будет обновлен.

Для удаления города необходимо нажать кнопку «Удалить» справа от списка городов (кроме города будут удалены сведения обо всех отправляющихся в данный город рейсах и проданных на эти рейсы билетах).

Для добавления рейса необходимо нажать кнопку «Добавить…». Откроется диалог добавления рейса:

Рис. 7 Диалог добавления рейса

Аналогичный диалог, только содержащий уже заполненные поля, появляется при изменении атрибутов рейса. Для этого необходимо выделить нужную строку в списке рейсов и нажать кнопку «Изменить…».

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

Будет открыт диалог добавления сведений о продаже билета и работы со списком пассажиров:

Рис. 7 Диалог для работы со списком пассажиров

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

Также существует возможность поиска записей по подстроке ФИО пассажира и их сортировки по ФИО пассажира – как по убыванию, так и по возрастанию.

Для изменения записи необходимо выделить требуемую строку в списке пассажиров – данные о пассажире будут занесены в элементы управления диалога и станут доступными кнопки редактирования/удаления записи.

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

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

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

Рис. 8. Поиск сведений о проданных на рейс билетах

Для изменения настроек соединения с сервером используется диалог настроек (рис. 9). Для вступления изменений в силу требуется перезапуск приложения.

Рис. 9. Диалог настроек

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


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


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

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

      1. Возможность формирования скидок для постоянных клиентов.
      2. Регистрация билетов на различные классы (1-й, бизнес и т.п.).
      3. Возможность предварительного заказа завтрака/обеда в ходе полета в процессе оформления продажи билета.
      4. Печать квитанций о проданных билетах и т.п.

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

Дополнительно в результате выполнения данного курсового проекта были получены и закреплены на практике навыки в работе с языком  JAVA, UML, методиками проектирования IDEF0, IDEF1x, СУБД SyBase .


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


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

Разработанное ПС реализовано с использованием языка программирования Java на основе технологии  «клиент-сервер».

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

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

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

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


ЛИТЕРАТУРА


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

2. Б. Хичков SYBASE: Настольная книга администратора. – Лори, 2000 г. 448 с.

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