Объектно-ориентированная модель информационной подсистемы для туристической фирмы

В данном курсовом проекте разработана объектно-ориентированная модель информационной подсистемы для туристической фирмы. Данная модель разработана с помощью программного продукта Rational Rose 2000 Enterprise Edition, с помощью языка UML.

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

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

В третьем разделе данной работы рассматривается создание диаграммы последовательности (sequence diagrams) и кооперативные диаграммы (collaboration diagrams). Данная диаграмма предназначенная для моделирования процесса обмена сообщениями между объектами.

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

В разделе пять описывается диаграмма классов для прецедента «Ввод данных о клиенте».

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

В седьмом разделе приводится и описывается диаграммы состояний для класса Zakaz. В этом же разделе приводится описание диаграммы компонентов для прецедентов информационной подсистемы «Составление заявки».

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

В девятом разделе пояснительной записки приводится и описывается порядок генерации программного кода на языке С++ для данной информационной подсистемы.

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

В приложение вынесены листинги кода проектируемой программы, сгенерированные Rational Rose.

1. КРАТКАЯ ХАРАКТЕРИСТИКА ПРЕДМЕТНОЙ ОБЛАСТИ

1.1 Общая характеристика

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

1.2 Актуальность разрабатываемой подсистемы

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

1.3 Формулировка задач проектирования

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

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

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

2. СОЗДАНИЕ ДИАГРАММЫ ПРЕЦЕДЕНТОВ

На рисунке 2.1 приведена диаграмма использования, спроектированная в среде RationalRose. Основным действующим лицом (актером) является турагент.

Рисунок 2.1 — Диаграмма прецедентов Выводы

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

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

3. СОЗДАНИЕ ДИАГРАММЫ ПОСЛЕДОВАТЕЛЬНОСТИ

Рассмотрим вариант использования «Создание нового заказа». Диаграмма последовательности приведена на рисунке 3.1.

Рисунок 3.1 — Диаграмма последовательности для варианта использования «Создание нового заказа»

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

1. Турагент принимает новый заказ.

2. При этом он открывает необходимую форму для ввода данных о клиенте.

3. Вводит все необходимые поля в открытую форму.

4. Нажимает на клавишу «Сохранить».

5. При этом информация отправляется в СУБД, которая обозначена на диаграмме как «управляющий заказами».

6. СУБД создает новую пустую запись.

7. Генерирует изменяет значения полей в соответствии с введенными оператором ПК данными.

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

9. Система управления транзакциями осуществляет транзакцию.

10. Система управления транзакциями возвращает сообщение об успешности проведения транзакции или ошибке при её выполнении.

Выводы

1. Была разработана диаграмма последовательности для варианта использования «создание нового заказа». Этот вариант использования является наиболее важной и наиболее сложно реализуемой задачей информационной подсистемы.

2. При создании диаграммы были созданы пять классов: два управляющих, два «граничных"(Boundaries) и один «сущность».

4. СОЗДАНИЕ ДИАГРАММЫ СОТРУДНИЧЕСТВА

В курсовом проекте была разработана диаграмма сотрудничества, описывающая составление заказа турагентом (рисунок 4.1).

Рисунок 4.1 — Диаграмма сотрудничества

Выводы

1. Была спроектирована диаграмма сотрудничества для варианта использования «Ввод данных о клиенте». Во многом от правильности выполнения этого прецедента будет зависеть в дальнейшем успешность оперативного учета и функционирования всей системы в целом.

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

5. СОЗДАНИЕ ДИАГРАММЫ КЛАССОВ

Ознакомившись с классами модели, для более наглядного представления, они были сгруппированы по стереотипу (рисунок 5.1).

Рисунок 5.1 — Диаграмма пакетов

Диаграмма классов показана на рисунке 5.2.

Рисунок 5.2 — Диаграмма Классов «Ввод нового заказа»

В пакет «Boundaries» были добавлены следующие классы: класс Form (форма ввода данных о клиенте) и класс Options (выбор варианта формы).

Рисунок 5.3 — Главная диаграмма Классов пакета Boundaries

Классы — сущности (entity classes) отражают основные понятия (абстракции) предметной области и, как правило, содержат хранимую информацию. В данный пакет были добавлен класс Zakaz (рисунок 5.4).

Рисунок 5.4 — Главная диаграмма Классов пакета Entities

Управляющие классы (control classes) отвечают за координацию действий других классов. Обычно у каждого варианта использования имеется один управляющий класс, контролирующий последовательность событий этого варианта использования. В данном проекте данную функцию выполняет класс Control, а также ControlTranz (рисунок 5.5).

Рисунок 5.5 — Главная диаграмма Классов пакета Control

Выводы

1. В процессе разработки диаграммы классов был применен механизм пакетов. Были созданы три основных пакета, объединяющих классы по стереотипам.

2. Была разработана диаграмма пакетов, являющаяся одной из форм диаграммы классов.

6. ДОБАВЛЕНИЕ ДЕТАЛЕЙ К ОПИСАНИЯМ ОПЕРАЦИЙ И ОПРЕДЕЛЕНИЕ АТРИБУТОВ КЛАССОВ

база данное последовательность операция

После того как была, разработана диаграмма классов для варианта использования «Составление заявки», начинается ее заполнение. В качестве языка программирования был выбран C++, что позволило добавить к классам параметры операций, типы данных и типы возвращаемых значений.

Для определения атрибутов и операций классов было произведено обращение к потоку событий. В результате к классам были добавлены дополнительные атрибуты и связи между классами (рисунок 6.1).

Рисунок 6.1 — Диаграмма классов для сценария «Составление заявки»

Как видно из диаграммы, для добавления составление заявки, необходимо ввести следующую информацию (атрибуты класса Zakaz):

— FIO: String — фамилия имя отчество клиента;

— datazakaza: Date — дата заявки;

— travel: String — данные о путешествии;

Назначение и описание основных методов классов были рассмотрены выше, в третьем и четвертом разделах.

В рамках этого раздела также был создан новый класс ZakazItem.

Также для окончательного завершения построения Ассоциации сценария «Составление заявки» с помощью кнопки панели инструментов Unidirectionsl Association (Однонаправленная ассоциация) были проведены связи между классами и добавлены значения множественности (рисунок 6.2).

Рисунок 6.2 — Добавление связей между классами

Выводы

1. Была разработана диаграмма классов для сценария «составление заявки». Как видно из диаграммы, между классами существует определенная семантическая связь.

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

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

На рисунке 7.1 приведена диаграмма состояния для класса Zakaz.

Рисунок 7.1 — Диаграмма Состояния для класса Zakaz

Была также создана диаграмма компонентов, отображающая распределение классов и объектов по компонентам при физическом проектировании (рисунок 7.2).

Рисунок 7.3 — Диаграмма Компонентов Выводы

1. Была создана диаграмма состояний для класса Zakaz. Согласно этой диаграмме объекты класса Zakaz могут находиться в одном из четырех состояний: инициализации, приостановки, отмены и завершения. Была также разработана диаграмма компонентов, разделяющая систему на 2 компонента: клиент и сервер.

2. Из диаграммы компонентов видно, что разрабатываемая подсистема будет работать по технологии «клиент — сервер». К клиентской части приложения относятся классы Form и Options и объекты этих классов. К серверной части приложения отнесены все остальные классы и объекты этих классов.

8. СОЗДАНИЕ ДИАГРАММЫ РАЗМЕЩЕНИЯ

Диаграмма размещения, разработанная в проекте представлена на рисунке 8.1.

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

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

9. ГЕНЕРАЦИЯ ПРОГРАММНОГО КОДА C++

Язык C++ является одним из наиболее широко применяемых на практике объектно — ориентированных языков. Rational Rose интегрируется с C++ посредством генерации кода и обратного проектирования. В Rational Rose 2000 предусмотрена возможность генерации программного кода C++.

При генерации с помощью Rational Rose 2000 Enterprise Edition программного кода на стандартном C++ необходимо:

1. Создать компоненты;

2. Определить компоненты для классов;

3. Установить свойства генерации программного кода;

4. Выбрать класс или компонент для генерации на диаграмме Классов или Компонентов;

5. Выбрать в меню: Tools > C++ > Code Generation

6. Выбрать в меню: Tools > C++ > Browse Header или Browse Body для просмотра сгенерированного программного кода.

Первый этап процесса генерации программного кода — создание компонентов для классов. Это файлы с расширениями *. cpp (файл реализации) и *. h (заголовочный файл). В С++ данный этап не является обязательным. Если не описать компоненты, Rational Rose сгенерирует файлы *. cpp и *. h для каждого класса. Тем не менее, рекомендуется создавать компоненты, что позволит управлять отображением классов на компоненты и моделировать зависимости между компонентами.

Следующим шагом является установка свойств генерации программного кода для классов, компонентов и других элементов модели.

Рисунок 9.1 — Окно выбора компонентов и классов программы Выводы

1. На основании созданных моделей компонентов, представленных в проекте была произведена генерация программного кода на языке C++.

2. Листинги сгенерированного Rational Rose 2000 Enterprise Edition кода приложения для туристической фирмы на языке С++ приведены в Приложении А. Число сгенерированных файлов 12, а их общий размер составляет 15,7 кбайт.

ЗАКЛЮЧЕНИЕ

В результате выполнения курсового проекта была разработана объектно — ориентированная модель информационной подсистемы для туристической фирмы. Данная разработка написана с помощью языка UML, с использованием среды разработки — программного продукта Rational Rose 2000.

Были разработаны следующие диаграммы:

— диаграмма прецедентов;

— диаграмма последовательности;

— диаграмма сотрудничества;

— диаграмма классов;

— диаграмма состояния для классов;

— диаграмма компонентов;

— диаграмма размещения.

Основным действующим лицом является турагент.

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

Информационная подсистема туристической фирмы построена на технологии «клиент — сервер». Это позволяет организовать одновременный доступ нескольких операторов ПК к базе данных.

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

Были сгенерированы 12 файлов кода на языке С++ общим размером 15,7 кбайт.

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

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

БИБЛИОГРАФИЧЕСКИЙ СПИСОК

1. Буч Г., Рамбо Д., Джекобсон А. Язык UML для пользователя: Пер. с англ. — М.: ДМК, 2000. — 432 с., ил. (Серия «для программистов»).

2. Боггс У., Боггс М. UML и Rational Rose: Пер. с англ. — М.: Издательство «Лори», 2000. — 581 с., ил.

3. Буч Г., Рамбо Д., Джекобсон А. UML: специальный справочник. — СПб.: Питер, 2002. — 432 с., ил.

4. Ларман К. применение UML и шаблонов проектирования: Пер. с англ. — М.: Издательский дом «Вильямс», 2001. — 496 с., ил.

Приложение А

Листинг кода приложения на языке С++

А.1 Листинг файла Options. h

//## begin module%1.2%.codegen_version preserve=yes

// Read the documentation to learn more about C++ code generator

// versioning.

//## end module%1.2%.codegen_version

//## begin module%475B099200EA.cm preserve=no

// %X% %Q% %Z% %W%

//## end module%475B099200EA.cm

//## begin module%475B099200EA.cp preserve=no

//## end module%475B099200EA.cp

//## Module: Options%475B099200EA; Package specification

//## Subsystem: Boundaries%475B08210242

//## Source file: C: Program FilesRationalRose 2000C++sourceBoundariesOptions.h

#ifndef Options_h

#define Options_h 1

//## begin module%475B099200EA.additionalIncludes preserve=no

//## end module%475B099200EA.additionalIncludes

//## begin module%475B099200EA.includes preserve=yes

//## end module%475B099200EA.includes// Form

#include «BoundariesForm.h»

//## begin module%475B099200EA.declarations preserve=no

//## end module%475B099200EA.declarations

//## begin module%475B099200EA.additionalDeclarations preserve=yes

//## end module%475B099200EA.additionalDeclarations

//## begin module%475B099200EA.epilog preserve=yes

//## end module%475B099200EA.epilog

#endif

Листинг файла Options. cpp

//## begin module%1.2%.codegen_version preserve=yes

// Read the documentation to learn more about C++ code generator

// versioning.

//## end module%1.2%.codegen_version

//## begin module%475B09AA031C.cm preserve=no

// %X% %Q% %Z% %W%

//## end module%475B09AA031C.cm

//## begin module%475B09AA031C.cp preserve=no

//## end module%475B09AA031C.cp

//## Module: Options%475B09AA031C; Package body

//## Subsystem: Boundaries%475B08210242

//## Source file: C: Program FilesRationalRose 2000C++sourceBoundariesOptions.cpp

//## begin module%475B09AA031C.additionalIncludes preserve=no

//## end module%475B09AA031C.additionalIncludes

//## begin module%475B09AA031C.includes preserve=yes

//## end module%475B09AA031C.includes

// Options

#include «BoundariesOptions.h»

//## begin module%475B09AA031C.declarations preserve=no

//## end module%475B09AA031C.declarations

//## begin module%475B09AA031C.additionalDeclarations preserve=yes

//## end module%475B09AA031C.additionalDeclarations

//## begin module%475B09AA031C.epilog preserve=yes

//## end module%475B09AA031C.epilog