Автоматизированное рабочее место консультанта по туристическим услугам

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Автоматизированное рабочее место консультанта по туристическим услугам



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

программа технический туристический автоматизированный

1.1 Описание и структура туристической фирмы

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

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

– организует сотрудников к способности совместно действовать;

– придает усилиям сотрудников эффективность и сглаживает присущие им слабости;

– сплачивает сотрудников вокруг общей цели (стратегии предприятия).

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

– улучшает профессиональную подготовку сотрудников, создает возможность для карьерного роста.

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

– технологии организации продаж путевок;

– основ управления персоналом;

– форм и методов профессионального обучения;

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

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

– поиск клиентов;

– ведение переговоров с клиентами;

– прием заказов от клиентов;

– заключение договор с клиентами;

– дальнейшее ведение заказа до момента выполнения.

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

Рассмотрим базовые понятия, относящиеся к данной предметной области (таблица 1.1 - Глоссарий предметной области).

Таблица 1.1 - Глоссарий предметной области

№	Термин	Определение термина
1	Туристическая фирма	Организация, занимающаяся комплектацией туров и формированием комплекса услуг для туристов.
2	Клиент	Общее название субъекта, использующего некоторые услуги.
3	Консультант по турам	Занимается работой с клиентами, - предоставлением всей необходимой информации об отдыхе и обучении за рубежом, помощью в выборе тура и пр.
4	Экскурсия	Коллективное или индивидуальное посещение музея, достопримечательного места, выставки и т.п.; поездка, прогулка с образовательной, научной, спортивной или увеселительной целью. Показ объектов происходит под руководством квалифицированного специалиста - экскурсовода, который передает аудитории видение объекта, оценку памятного места, понимание исторического события, связанного с этим объектом.
5	Тур	Посещение различных мест, с какой-либо целью (развлекательной, познавательной, гастрольной и др.), в рамках одной спланированной поездки.
6	Анкета клиента	Документ, который заполняется клиентом для дальнейшего сотрудничества с турфирмой.
7	Виза	Разрешительный документ, являющийся одним из оснований въезда иностранца на территорию государства.
8	Программный продукт (ПП)	Набор компьютерных программ, процедур и, возможно, связанных с ними документов и данных
9	Горящий тур	Это состояние туристической путёвки, которая по каким-либо причинам не была продана в определённые какими-либо факторами (вылет самолёта, отправление поезда, заранее выкупленные места в отеле) фиксированные сроки. Такая путёвка продаётся по более низкой стоимости в связи со сжатыми сроками её реализации; чем ближе конец фиксированного срока, тем дешевле будет стоить путёвка.
10	Гостиница	Имущественный комплекс (дом, здание, часть здания, иные постройки) с меблированными комнатами («номерами») для временного проживания туристов.
11	Загранпаспорт	Официальный документ, удостоверяющий личность гражданина при выезде за пределы и пребывании за пределами страны, а также при въезде на территорию государства из заграничной поездки.

1.2 Разработка бизнес логики программы. Разработка SADT-диаграммы

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

В фазе бизнес-моделирования и разработки требований бизнес-логика может описываться в виде:

- текста;

- концептуальных аналитических моделей предметной области;

- бизнес-правил;

- разнообразных алгоритмов;

- диаграмм деятельности;

- графов и диаграмм перехода состояний;

- моделей бизнес-процессов.

Для описания бизнес логики используем методологию структурного анализа и проектирования SADT. [6] Контекстная SADT диаграмма нулевого уровня «Автоматизация работы консультанта турфирмы по оформлению путевок и работы с клиентами».



Таблица 1.2 - Описание SADT-диаграммы 0 уровня процесса А-0 «Автоматизация работы консультанта турфирмы по оформлению путевок и работы с клиентами»

№	Входные данные	Управление	Исполнитель	Выходные данные
А0	1 анкета клиента 2 регистрационный данные консультанта 3 паспортные данные клиента 4 чек об оплате	1 валидация данных 2 параметры отображения	1 клиент 2 консультант 3 турфирма	1 список туров 2 информация о туре 3 данные туров 4 договор сторон

1.3 Обоснование выбора средств разработки

Yii (Yes It Is!) - это высокопроизводительный веб-каркас, написанный на PHP, и реализующий расширенную парадигму MVC,. Для обоснования выбора проведем сравнение с другими популярными фреймворками. Результаты сравнения находятся в таблице 1.3.

Шаблон проектирования Модель-Представление-Контроллер

Таблица 1.3 - Сравнение PHP-фреймворков

	Yii	Zend	Symfony
Производительность	Высокая	Выше среднего	Ниже среднего
Автоматическое тестирование	+	+	+
Скаффолдинг	+	+	+
Подключение сторонних библиотек	+	+	+
Миграции базы данных	+	+	+
Поддержка интернационализации	+	+	+
Кэширование страниц	+	+	+
Поддержка различных баз данных	+	+	+
Размер	Ниже среднего	Большой	Большой
Сложность установки и настройки	Средняя	Высокая	Высокая
Документация	Отличная	Хорошая	Пишется
Удобство	Высокое	Ниже среднего	Среднее

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

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

программа технический разработка автоматизированный

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

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

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

Приведенные выше два программных продукта по своему хороши, но являются универсальными и платными, поэтому создание АРМ консультанта по туристическим услугам является оправданным. Так же с помощью нашего АРМ можно управлять не только одним отделом, но и сетью, если такая имеется.

1.5 Математическая модель

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

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

(1.1)

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

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

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

- консультант;

- клиент;

- турфирма.

Анализ бизнес-процессов, протекающих в системе, позволил выделить типовые функции (таблица 1.4).

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

№	Бизнес-функция	Консультант	Клиент	Турфирма
1	Создание анкеты	-	-	+
2	Заполнение анкеты	-	+	-
3	Подбор туров	+	-	-
4	Работа с турами	+	-	-
5	Анализ клиентов	+	-	-
6	Создание договора	-	-	+
7	Подписание договора	-	+	-

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

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

- V_N = {N₀, 1, 2, 3, 4, 5, 6} - множество нетерминальных символов;

- V_T = {N_ф} - множество терминальных символов;

- V₀ = {N₀} - множество начальных символов;

- Р - множество порождающих правил;

- A_s = {t_i} - кортежи временных характеристик. Каждый из кортежей определяет ресурсы, необходимые для выполнения бизнес-функции по времени.

- A_n = {К, КЛ, Т} - множество возможных исполнителей бизнес-функций (Консультант, Клиент, Турфирма).

Основываясь на графе вариантов выполнения функций сотрудниками подразделения (см. рисунок 1.4), можно сформулировать следующие порождающие правила (запись 1 {Т} означает, что бизнес-функция 1 (см. таблицу 1.4) выполняется турфирмой):

1) N₀ => 1 {Т} | 5 {К} | 4 {К}

2) 1 {Т} => 2 {КЛ}

3) 2 {КЛ} =>3 {К}

4) 3 {К} => 2 {КЛ} | 4 {К} | 5 {к} | 6 {Т}

5) 4 {К} => 5 {К} | 6 {Т}

6) 5 {К} => 6 {Т} | 4 {К}

7) 6 {Т} => 7 {КЛ}

8) 7 {КЛ} => N_Ф

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

Поэтому на основе экспертной оценки определим затраты ресурсов (таблица 1.5), которые приведены в условных единицах ресурсов времени выполнения бизнес-функции (t) и количества исполнителей (n).

Таблица 1.5 - Затраты ресурсов на выполнение бизнес-функций сотрудниками подразделения

Бизнес-функция	t	n
1 {Т}	1	1
2 {КЛ}	5	1
3 {К}	3	1
4 {К}	2	1
5 {К}	2	1
6 {Т}	1	1
7 {КЛ}	1	1



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

N₀ - 1 {Т} - 2 {КЛ} - 3 {К} - 4 {К} - 5 {К} - 6 {Т} - 7 {КЛ} - N_Ф

N₀ - 1 {Т} - 2 {КЛ} - 3 {К} - 4 {К} - 6 {Т} - 7 {КЛ} - N_Ф

N₀ - 1 {Т} - 2 {КЛ} - 3 {К} - 5 {К} - 6 {Т} - 7 {КЛ} - N_Ф

N₀ - 1 {Т} - 2 {КЛ} - 3 {К} - 6 {Т} - 7 {КЛ} - N_Ф

N₀ - 1 {Т} - 2 {КЛ} - 3 {К} - 5 {К} - 4 {К} - 6 {Т} - 7 {КЛ} - N_Ф

N₀ - 1 {Т} - 2 {КЛ} - 3 {К} - 2 {КЛ} - 3 {К} - 4 {К} - 5 {К} - 6 {Т} - 7 {КЛ} - N_Ф

N₀ - 1 {Т} - 2 {КЛ} - 3 {К} - 2 {КЛ} - 3 {К} - 4 {К} - 6 {Т} - 7 {КЛ} - N_Ф

N₀ - 1 {Т} - 2 {КЛ} - 3 {К} - 2 {КЛ} - 3 {К} - 5 {К} - 6 {Т} - 7 {КЛ} - N_Ф

N₀ - 1 {Т} - 2 {КЛ} - 3 {К} - 2 {КЛ} - 3 {К} - 6 {Т} - 7 {КЛ} - N_Ф

N₀ - 1 {Т} - 2 {КЛ} - 3 {К} - 4 {К} - 5 {К} - 4 {К} - 5 {К} - 6 {Т} - 7 {КЛ} - N_Ф

N₀ - 1 {Т} - 2 {КЛ} - 3 {К} - 4 {К} - 5 {К} - 4 {К} - 6 {К} - 6 {Т} - 7 {КЛ} - N_Ф

N₀ - 1 {Т} - 2 {КЛ} - 3 {К} - 5 {К} - 4 {К} - 5 {К} - 6 {Т} - 7 {КЛ} - N_Ф

N₀ - 1 {Т} - 2 {КЛ} - 3 {К} - 5 {К} - 4 {К} - 6 {Т} - 7 {КЛ} - N_Ф

N₀ - 4 {К} - 5 {К} - 6 {Т} - 7 {КЛ} - N_Ф

N₀ - 4 {К} - 6 {Т} - 7 {КЛ} - N_Ф

N₀ - 4 {К} - 5 {К} - 4 {К} - 5 {К} - 6 {Т} - 7 {КЛ} - N_Ф

N₀ - 4 {К} - 5 {К} - 4 {К} - 6 {Т} - 7 {КЛ} - N_Ф

N₀ - 5 {К} - 6 {Т} - 7 {КЛ} - N_Ф

N₀ - 5 {К} - 4 {К} - 5 {К} - 6 {Т} - 7 {КЛ} - N_Ф

N₀ - 5 {К} - 4 {К} - 6 {Т} - 7 {КЛ} - N_Ф

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

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

(1.2)

где k - количество бизнес-функций, входящих в бизнес-процесс; j - индекс исполнителя бизнес-функции;

. (1.3)

Суммарные оценки вариантов реализации бизнес-процесса представлены в таблице 1.6.

Таблица 1.6 - Оценка времени протекания различных вариантов бизнес-процесса

№	Вариант
1	N0 - 1 {Т} - 2 {КЛ} - 3 {К} - 4 {К} - 6 {Т} - 7 {КЛ} - NФ	13	3
2	N0 - 1 {Т} - 2 {КЛ} - 3 {К} - 6 {Т} - 7 {КЛ} - NФ	11	3
3	N0 - 5 {К} - 4 {К} - 6 {Т} - 7 {КЛ} - NФ	6	3
4	N0 - 4 {К} - 5 {К} - 6 {Т} - 7 {КЛ} - NФ	6	3
5	N0 - 4 {К} - 6 {Т} - 7 {КЛ} - NФ	4	3
6	N0 - 5 {К} - 6 {Т} - 7 {КЛ} - NФ	4	3

Для выделения оптимального варианта необходимо установить отношение предпочтения между рассматриваемыми альтернативами. Для этого удобно использовать метод парного сравнения, согласно которому устанавливаются предпочтения при рассмотрении всех возможных пар альтернатив. Результаты парного сравнения принято представлять в виде матрицы, в которой элемент b_ij = 1, если альтернатива B_i строго предпочтительнее, чем альтернатива B_j. В противном случае b_ij = 0. Согласно методу парного сравнения для выделения альтернатив первого ранга достаточно выявить нулевые столбцы в полученной матрице (таблица 1.7). В нашем случае к альтернативам первого ранга относятся альтернатива 4, 5 и альтернатива 6.

Таблица 1.7 - Результаты парного сравнения альтернативных вариантов

	1	2	3	4	5	6
1	0	0	0	0	0	0
2	1	0	0	0	0	0
3	1	1	0	0	0	0
4	1	1	0	0	0	0
5	1	1	1	0	0	0
6	1	1	1	0	0	0

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



1.6 Разработка технического задания на разработку «Автоматизированного рабочего места консультанта по туристическим услугам»

Основание для разработки

Основанием для разработки является тема индивидуального задания для преддипломной практики «Автоматизированное рабочее место консультанта по туристическим услугам». Спец. часть: Разработка программного обеспечения для организации и ведения базы данных через веб-интерфейс. Индивидуальное задание выдано преподавателем Кравченко В.И.

Назначение разработки

АРМ разрабатывается для автоматизации работы консультанта по туристическим услугам. АРМ позволит сэкономить время работы консультанта по туристическим услугам при: организации туров и работе с клиентами.

Требования к функциональным характеристикам

Программный продукт должен выполнять нижеперечисленные функции:

- хранить и вести базу данных туров;

- сортировать туры;

- удалять туры, вылет на которые закончился «вчера»;

- хранить информацию о клиентах;

- показ информации о туре;

- вход в систему;

- выполнять операции CRUD из личного кабинета;

– предоставлять удобный, интуитивно-понятный интерфейс;

– время выполнения запроса не должно превышать двух секунд;

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

Требования к надежности

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

– устойчиво функционировать и не приводить к сбоям в системе;

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

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

Условия эксплуатации

Условия эксплуатации ПП определяются СанПиН 2.2.2 545-96 «Гигиенические требования к видеодисплейным терминалам, персональным вычислительным машинам и организации работы».

Требования к составу и параметрам технических средств

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

– объем оперативной памяти не менее 256 МБ;

– процессор не ниже AMD Sempron 2000+;

– наличие свободного места на жестком диске в размере не менее 1 Гбайт.

Требования к информационной и программной совместимости

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

Кроме того, для установки данного программного продукта на сервер необходима любая из популярных систем (Windows, Unix и MacOS).

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

– система должна работать на платформах операционных систем Windows, Unix и MacOS.

– браузер с поддержкой JavaScript;

– виртуальный сервер.

Требования к программной документации

Предварительный состав программной документации установлен в соответствии с ГОСТ 19.101-77. Ниже перечислен список программных документов и их содержание.

Текст программы - запись программы с необходимыми пояснениями и комментариями.

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

Программа и методика испытаний - требования, подлежащие проверке при испытании программы, также порядок и методы контроля.

Техническое задание - настоящий документ.

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

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

Технико-экономические показатели

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

Стадии и этапы разработки приведены в таблице 1.8.



Таблица 1.8 - Стадии и этапы разработки АРМ

№	Этап	Содержание	Сроки
1	Техническое задание	Определение и анализ требований для АРМ. Анализ и обоснование актуальности автоматизации рабочего места консультанта по туристическим услугам.
2	Эскизный проект	Документирование бизнес процесса: выделение границ, выявление пользователей системы - консультанта, описание деятельности по управлению бизнес-процессом и его выполнение. Разработка физической и логической модели системы.
3	Технический проект	Выбор средств разработки системы. Реализация рабочей версии проекта с основой функциональностью.
4	Рабочий проект	Реализация методов сбора статистики и обширного поиск. Корректировка и доработка системы.
5	Внедрение	Разработка мероприятий по внедрению и сопровождению проекта. Разработка отчетов; разработка документации.

Порядок контроля и приемки

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

Контроль программного продукта осуществляется в следующем порядке.

1 проверка функциональности разработанного программного продукта на локальной машине;

2 проверка реакции программы на различные действия пользователя;

3 проверка выходных данных;

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



2. Разработка проекта программного комплекса «Автоматизированное рабочее место консультанта по туристическим услугам»

2.1 Разработка логической модели ПП

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

Диаграмма прецедентов - диаграмма, на которой отражены отношения, существующие между актёрами и прецедентами. Основная задача - представлять собой единое средство, дающее возможность заказчику, конечному пользователю и разработчику обсуждать поведение системы. [7]

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

Для организации тура необходимо:

– анкета клиента;

– паспортные данные;

– путевка.

Работа с турами может предполагать:

– добавление тура;

– изменение;

– удаление.

Таблица 2.1 - Описание прецедента «Работа с турами»

Основной исполнитель: консультант
Предусловия: редактировать БД туров
Входные данные: -
Основной успешный сценарий (основной процесс): изменение БД туров
Частота использования: при каждой работе с БД
Постусловия: БД изменена
Выходные данные: -

Таблица 2.2 - Описание прецедента «Поиск тура»

Основной исполнитель: клиент, консультант
Предусловия: выдать список туров по параметрам поиска
Входные данные: параметры поиска
Основной успешный сценарий (основной процесс): составление и вывод списка туров по параметрам поиска
Частота использования: при каждом поиске
Постусловия: список составлен
Выходные данные: -

Таблица 2.3 - Описание прецедента «Вход в систему»

Основной исполнитель: консультант
Предусловия: необходимо зайти в систему
Входные данные: регистрационные данные консультанта
Основной успешный сценарий (основной процесс): войти в систему
Частота использования: при каждом входе
Постусловия: вход выполнен
Выходные данные: -

Таблица 2.4 - Описание прецедента «Организация тура»

Основной исполнитель: консультант
Предусловия: выполнить организацию тура
Входные данные: анкеты клиента, выбор тура из предложенных
Основной успешный сценарий (основной процесс): - проверка анкеты; - паспортные данные клиента; - путевка.
Частота использования: при каждой организации
Постусловия: тур организован
Выходные данные: договор сторон

Таблица 2.5 - Описание прецедента «Просмотр тура»

Основной исполнитель: консультант, клиент
Предусловия: отобразить туры соответствующие поиску
Входные данные: параметры поиска
Основной успешный сценарий (основной процесс): вывод туров на экран
Частота использования: при каждом поиске
Постусловия: поиск завершен
Выходные данные: список туров

Разработка диаграммы классов предметной области «Организация туров консультантом»

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

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

Таблица 2.6 - Обязанности классов

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

Разработка диаграмм последовательностей

Разработаем диаграмму последовательностей для прецедента «Автоматизированное рабочее место консультанта по туристическим услугам».

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

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

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

2.2 Разработка физической модели ПП

Разработка диаграмм классов ПП

Для разработки диаграммы классов «Информационная поддержка деятельности системного администратора машиностроительного техникума» использовал шаблон MVC (Model View Controller).

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

Диаграмма классов ПП приведена на рисунке 2.4, а в таблице 2.7 описаны обязанности классов.



Таблица 2.7 - Обязанности классов

Участник шаблона	Класс	Обязанности с точки зрения шаблона
Model	Tour	Модель предоставляет данные, а также реагирует на запросы, изменяя свое состояние
View	Documents	Отвечает за отображение информации
Controller	Konsultant	Интерпретирует данные, введенные пользователем, и информирует модель и представление о необходимости соответствующей реакции

Модульная структура программного комплекса

Для представления физических сущностей в языке UML применяется специальный термин - компонент (component). Компонент реализует некоторый набор интерфейсов и служит для общего обозначения элементов физического представления модели.

Отношения зависимости на диаграмме компонентов является отношение между различными видами компонентов. Наличие подобной зависимости означает, что внесение изменений в исходные тексты программ или приводит к изменениям самого компонента. [10]

Для работы реализуемого программного продукта компонентом index.php используется компонент tour. MySQL, который представляется форме таблицы базы данных. Также существует абстрагированная зависимость между вводимыми данными в index.html и компонентом index.php. Компонент help.html является справкой программного продукта, используемой компонентом index.php.



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

программа технический разработка автоматизированный

1) Квартальнов В.А. Стратегический менеджмент в туризме

2) Боголюбов В.С., Орловская В.П. «Экономика в туризме»

3) Дурович А., Кабушкин Н., Сергеева Т. «Организация туризма» Учебное пособие. - Минск: Новое знание, 2003. - 632 с.

4) Шаховалов Н.Н. «Интернет технологии в туризме» Учебное пособие. - Барнаул: Издательство АлтГАКИ, 2007. - 251 с.

5) Сокол Т.Г. Організація туристичної діяльності в Україні Навчальний посібник. - К.: «Музична Україна, 2002. - 256 с.

6) Приемы объектно-ориентированного проектирования. Паттерны проектирования / Э. Гамма, Л. Хелм, Р. Джонсон, Дж. Влиссидес. - СПб.: Питер, 2001. - 368 с.;

7) Самоучитель UML 2, Леоненков Александр - Спб.: БХВ Петербург, 2007. - 576 с.

8) Буч, Г. Объектно-ориентированное проектирование с примерами применения / Г. Буч. - К.: Диалектика; М.: Конкорд, 1992. - 519 с.

9) Быков, В.П. Методическое обеспечение САПР в машиностроении / В.П. Быков. - Л.: Машиностроение, 1989. - 255 с.

10) Ларман, К. Применение UML и шаблонов проектирования / К. Ларман. - М.: Вильямс, 2002. - 624 с.

11) И.Н. Парфенова, Ю. А Шабалина Методические указания для студентов направления подготовки 6.050101 «Компьютерные науки» всех форм обучения

12) Юсина Г.Л. Організація роботи студентів з виконання розділу «Охорона праці» дипломних проектів / Г.Л. Юсіна, Л.В. Дементій. - Краматорськ: ДДМА, 2009. - 80 с.

Размещено на Allbest.ru

...