Файл: Анализ работы мобильных систем бронирования.pdf

Отлаженная система взаимодействия между мобильным приложением гостя и web-приложением отельера.^[63]

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

Система XOtelier включает в себя сервис автоматического перевода данных на многие языки. На данный момент интерфейс реализован на английском, русском, немецком, фанцузском, итальянском, испанском, арабском и турецком языках.^[64]

По-минимуму стоимость разработки мобильного приложения составит всего 25 тысяч рублей (для каждой платформы iOS или Android в отдельности). Это единоразовый платеж, в дальнейшем необходимо только оплачивать раз в год хостинг для вебсервера (около 1800 р/год) и перевыпуск сертификата iOS-приложения.

А также есть возможность взять в аренду приложение для отеля или гостиницы - 1500 рублей/мес. (для каждой платформы)^[65].

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

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

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

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

Методология поддержки сеансов базируется на следующем. При первом запросе пользователя генерируется новый сеанс, а все следующие запросы рассматриваются как часть данного сеанса, когда они сгенерированы в масштабах данного промежутка времени (пока не истекло время ожидания сеанса - session timeout).^[66]

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

---

Ключевым элементом сеанса считается его личный номер (session identifier), который несомненно описывает сеанс. Сгенерированный и отправленный клиенту при первом запросе идентификатор сеанса обязан быть оригинальным и вмести с этим довольно защищенным, чтоб преступник не мог с легкостью его подделать.^[67]

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

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

а) Внедрение временных интервалов истечения срока^[68]:

При работе с данными cookie фактически постоянно устанавливается время истечения срока их действия. Впрочем, невозможно точно обещать, что пользователь не уйдет употреблять кофе и вовсе не забудет завершить сеанс. Внедрение временных промежутков ожидания представляет регистрацию временной метки любого запроса и оценивание времени между следующими запросами на протяжении сеанса. При истечении времени надежды (в программе это 5 мин.) прерывается сеанс и потребуется повторная авторизация пользователя. ^[69]

б) Задание предельного срока жизни сессии:

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

в) Проверка пользовательского агента:^[70]

При обращении к приложению оно, к тому же, считывает информацию о пользовательском агенте для этого сеанса работы в Интернет. Это строка, характеризующая производителя Web-браузера, его имя, версию и платформу. При всем этом невозможно обеспечивать неповторимость аналогичной строчки для любого PC.^[71] Впрочем, во всем мире присутствует настолько не мало разных браузеров и их версий, что с высокой возможностью всевозможные компьютеры сгенерируют разные строки агента пользователя. Проверяя при следующих запросах соотношение данных агента пользователя, поддерживается вспомогательная линия защиты против взломов сеансов. Небезынтересно, что строка агента пользователя генерируемая браузером Internet Explorer, быть может изменена в реестре Windows. Системные администраторы имеют все шансы пользоваться данным фактом и сделать отличительные для рабочих станций их сети строки агентов пользователей. Это немного усилит этот механизм обеспечивания безопасности.

---

Исследование структуры пользовательских сеансов.^[72]

ER-диаграмма устройства пользовательской сессии представлена на рисунке 3.1.

Рисунок 3.1 - ER-диаграмма пользовательской сессии

Основу структуры составляет таблица user_session (таблица 3.1^[73]). Она обрисовывает конкретно саму сессию, такую как 32-символьный личный номер, и конкретно через нее исполняется доступ ко всей информации, связанной с сессией.^[74]

Таблица 3.1 - Описание таблицы user_session базы данных

Часто сможет потребоваться хранение дополнительных данных в масштабах какой-либо сессии, к примеру, о посещенных ранее страничках. Для описания и хранения всех аналогичных переменных употребляется таблица session_variable (таблица 3.2).^[75]

Таблица 3.2 - Описание таблицы session_variable базы данных

Регистрационная информация хранится в таблице user (таблица 3.3^[76]). Для обеспечивания большей сохранности пароль хранится в информационной базе в зашифрованном состоянии (используемый способ шифрования - md5), на тот вариант, когда преступник получит доступ к таким данным.

Таблица 3.3 - Описание таблицы user базы данных

Название	тип данных	Описание
id_user	int	Идентификатор пользователя. Первичный ключ.
username	varchar (32)	Имя пользователя (логин).
md5_pw	varchar (32)	Пароль

Структура и еще учитывает дальнейшее расширение функциональности системы, а непосредственно внедрение разных уровней доступа. Чтобы достичь желаемого результата дополнительно спроектированы таблицы access (таблица 3.4) и таблица to_access (таблица 3.5^[77]). Они обрисовывают разделы, к которым возможно настроить права доступа и характеризуют конкретно сам уровень.

Таблица 3.4 - Описание таблицы to_access базы данных^[78]

Таблица 3.5 - Описание таблицы user базы данных^[79]

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

---

Исследование структуры представления гостиниц

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

Рисунок 3.2 - ER-диаграмма гостиницы

Центральным элементом в структуре гостиниц является таблица hotel (таблица 3.6).^[80]

Таблица 3.6 - Описание таблицы hotel базы данных

Актуальными не столько для описания гостиниц считаются таблицы publish (таблица 3.7^[81]), modify (таблица 3.8^[82]), created (таблица 3.9)^[83], metas (таблица 3.10). Гиперссылки на них станут встречаться и в дальнейшем.

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

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

Таблица 3.7 - Описание таблицы publish базы данных^[84]

Таблицы modify и created практически идентичны, в 1 из них хранится информация о изменениях сути, а во 2 о ее существе. И все же принципиально решено разграничить подходящие им сущности для ускорения работы системы.

Таблица 3.8 - Описание таблицы modify базы данных^[85]

Таблица 3.9 - Описание таблицы created базы данных^[86]

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

Таблица 3.10 - Описание таблицы metas базы данных

Дополнительная информация о гостинице хранится в отдельных таблицах. Так, для описания условий бронирования каждой из гостиниц служит таблица reserving (таблица 3.11^[87]), а для описания предоставляемых гостиницей услуг - service (таблица 3.12^[88]).

---

Таблица 3.11 - Описание таблицы reserving базы данных

Кроме того, о чем уже упоминалось для полного описания гостиниц потребуется еще несколько подструктур. На базе данной структуры создан класс Hotel. Его код можно обнаружить в прибавлении А. В нем уже продан базовый перечень возможностей и структурой учтено его последующее расширение^[89].

Заключение

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

Данные системы позволяют решить следующие задачи:

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

Список литературы

1. Аверьянов Б. Путь к звездам отеля.- Сочи, 2016.-231 с.
2. Байлик С.И. Гостиничное хозяйство: организация, управление, обслуживание. - Киев: Альтерпресс, 2017. - 374 с.
3. Вишневская Е.В., Климова Т.Б., Богомазова И.В. Современные проблемы науки и образования. – 2019. – № 6.
4. Ефимова О.П. Экономика гостиниц и ресторанов. -М., 2018. -213 с.
5. Зубков А.А., Чибисов СИ. Справочник работника гостиничного хо­зяйства. – М.: Высшая школа, 2017. – 322 с.
6. Морозов М.А.Информационные технологии в социально-культурном сервисе и туризме. Оргтехника. М.: Издательство «Академия»,2018.-435с.
7. Надежин И.А. Современный ресторан и культурное обслуживание. – М: Экономика, 2019. – 346 с.
8. Чеботарь Ю.М. Туристический бизнес. - М.: Аспект Пресс, 2019.- 123 с.

---