Система бронирования мест в отелях города

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

Рубрика Программирование, компьютеры и кибернетика
Вид дипломная работа
Язык русский
Дата добавления 15.06.2012
Размер файла 2,9 M

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

Если говорить о серверной составляющей, то тут положительным для приложения будет являться, если оно будет кроссплатформенным. Тем не менее, следует определить, на какую ОС установка будет оптимальной. Система Windows не очень хороша в качестве сервера услуг Интернет. На момент написания работы самым распространенным сервером для хранения Web-узлов на платформе Windows является IIS (Internet Information Service). Его последние версии существенно усовершенствованы, но он по-прежнему страдает от множества изъянов в области безопасности, а системные администраторы считают его ненадежным и неустойчивым. Кроме того, Windows - это слишком ресурсоемкая среда для обслуживания Internet. Из 2 Гбайт памяти 512 Мбайт может отводиться для работы операционной системы с ее различными службами и лишь 64 Мбайта могут реально использоваться для работы Web-сервера. Операционная система Unix является более экономичной и надежной. Ее не так просто настроить, но она работает несравнимо быстрее и устойчивее, требуя при этом гораздо меньше ресурсов. Итак, поскольку ОС Unix превосходит Windows и по скорости и по надежности, то окончательный выбор именно за ней. Конкретно выберем операционную систему ASPLinux 9.0. Данная ОС из семейства UNIX, является бесплатной, свободно распространяемой, имеет достаточно высокий уровень надежности, защищенности, хорошо поддерживается в нашей стране. Также в поставке с ней идет большое количество приложений обеспечивающих полноценную работу данной ОС в качестве Web-сервера, сервера баз данных, файлового сервера и т.п.

2.2 Выбор системы управления базами данных

Сервер базы данных может быть физически установлен на другой машине, и выбор таких серверов достаточно широк. Среди возможных вариантов: PostgreSQL, MySQL, Oracle, Informix, DB2, Microsoft SQL Server, SUP DB и многие другие. Все эти варианты достаточно хороши. Поскольку серверы баз данных не имеют выхода в Интернет, вопросы безопасности при их выборе не играют ключевой роли. Если брандмауэр настроен правильно, то все серверы баз данных являются одинаково безопасными. Все эти серверы являются достаточно надежными и быстрыми. Реальные различия в производительности зачастую определяются структурой базы данных, а не особенностями самого сервера.

Во-первых, этот сервер является, наверное, самым широко распространенным после MySQL.

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

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

Перед тем как приступить к окончательному выбору СУБД, необходимо выделить набор факторов, которые необходимо учитывать.

Приведем перечень наиболее часто используемых факторов оценки СУБД:

· требуемые объемы основной и дисковой памяти;

· трудоемкость разработки программных средств окружения СУБД;

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

· затраты на обучение персонала;

· стоимость эксплуатации, информационной системы;

· возможность совмещения разработки БД с ранее выполненными программными реализациями;

· прогнозируемые сроки реализации информационной системы.

На основе анализа проведенного в предыдущем разделе, а также, учитывая вышеперечисленные факторы, наиболее подходящими в качестве сервера баз данных являются СУБД PostgreSQL и Mysql, так как они обладает высокой надежностью, защищенностью, хорошей производительностью, а также открытостью. Кроме того, они являются одними из наиболее распространенных.

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

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

2.3 Выбор технологии реализации

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

1) Запрос. Клиент, с помощью web-броузера инициирует запрос к серверу по протоколу HTTP.

2) Обработка запроса. После получения запроса web-сервер проводит обработку запрашиваемого ресурса. Если запрашиваем ресурс является статическим, таким как html страница, то процесс обработки фактически сводится к нулю. В противном случае, запрос отправляется соответствующему контейнеру web-приложений, где и происходит дальнейшая работа.

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

4) Формирование результата. После того, как запрос обработан, информация, подготовленная для пользователя, форматируется для протокола HTTP.

5) Передача данных клиенту. После формирования, данные передаются клиенту в качестве ответа. Ответ содержит данные (обычно HTML код, либо двоичные данные), а также дополнительные параметры, передаваемые в заголовках HTTP ответа.

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

ISAPI - Internet Server Application Programming Interface. Интерфейс ISAPI используются для непосредственного управления поведением Web-сервера. Так, ISAPI позволяет осуществлять доступ к функциям и службам Web-сервера Internet Information Server (IIS) фирмы Microsoft. В каждом отдельном случае применения интерфейса пишется программный код, который вызывается Web-сервером как выходная пользовательская процедура (user exit routine) или "закладка" (user hook). Процедуры вызываются в некоторых заданных (опубликованных) точках программного кода Web-сервера и записываются не в виде отдельных программ, а в виде набора библиотечных функций, действующих в качестве расширения Web-сервера.

ASP (англ. Active Server Pages - "активные серверные страницы") - технология от Microsoft, позволяющая легко разрабатывать приложения для World Wide Web. ASP работает на платформе операционных систем линии Windows NT и на веб-сервере IIS. ASP не является языком программирования - это лишь технология предварительной обработки, позволяющая подключать программные модули во время процесса формирования Web-страницы. Относительная популярность ASP основана на простоте используемых языков сценариев (VBScript или JScript) и возможности использования внешних COM-компонент.

ASP.net является составной частью платформы Microsoft.net и развитием более старой технологии Microsoft ASP. На данный момент последней версией этой технологии является ASP.net 2.0. Эта версия имеет серьезные отличия от своей предшественницы. Microsoft полностью перестроила ASP.net, основываясь на Common Language Runtime (CLR), который является основой всех приложений Microsoft.net. Программисты могут писать код для ASP.net, используя различные языки программирования, поддерживаемые в.net Framework, обычно (коммерческие) Visual Basic.net, JScript.net или C#, а также "открытые" языки, например, Perl и Python.

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

JSP (JavaServer Pages) - технология, позволяющая веб-разработчикам динамически генерировать HTML, XML и другие веб-страницы. Является составной частью единой технологии создания бизнес-приложений J2EE. Технология позволяет внедрять Java-код, а также EL (expression language) в статичное содержимое страницы. Также могут использоваться библиотеки JSP тегов для внедрения их в JSP-cтраницы. Страницы компилируются JSP-компилятором в сервлеты, представляющие собой Java-классы, которые выполняются на сервере. Весь код страницы транслируется в java-код сервлета с помощью компилятора JSP страниц Jasper, и затем компилируется в байт-код виртуальной машины java (JVM). Сервлет-контейнеры (Tomcat), способные исполнять JSP страницы, написаны на платформонезависимом языке Java, который может работать под различными операционными системами и платформами. Сервлет-контейнеры могут работать как полноценные самостоятельные web-серверы, работать поставщиком страниц для другого web-сервера или интегрироваться в J2EE сервер приложений. Web-контейнер обеспечивает обмен данными между сервлетом и клиентами, берет на себя выполнение таких функций, как создание программной среды для функционирующего сервлета, идентификацию и авторизацию клиентов, организацию сессии для каждого из них.

Perl (Перл). Само слово Perl - аббревиатура, которая расшифровывается как Practical Extraction and Report Language (практический язык извлечений и отчётов, отчего сначала язык назывался PEARL, но затем буква "A" "потерялась"). Основной особенностью языка считаются его богатые возможности для работы с текстом, реализованные при помощи регулярных выражений.

PHP (англ. PHP: Hypertext Preprocessor - "PHP: Препроцессор Гипертекста") - скриптовый язык программирования, созданный для генерации HTML-страниц на веб-сервере и работы с базами данных. В настоящее время поддерживается подавляющим большинством представителей хостинга. Входит в LAMP - "стандартный" набор для создания вебсайтов (Linux, Apache, MySQL, PHP (Python или Perl)). PHP отличается наличием ядра и подключаемых модулей, "расширений": для работы с базами данных, сокетами, динамической графикой, криптографическими библиотеками, документами формата PDF и т.п. Любой желающий может разработать своё собственное расширение и подключить его. Существуют сотни расширений, однако в стандартную поставку входит лишь несколько десятков хорошо зарекомендовавших себя. Интерпретатор PHP подключается к веб-серверу либо через модуль, созданный специально для этого сервера (например, для Apache или IIS), либо в качестве CGI-приложения. Кроме этого, он может использоваться для решения административных задач в операционных системах UNIX, Linux, Windows и др. Однако в таком качестве он не получил распространение.

CGI (от англ.common Gateway Interface - "общий интерфейс шлюза") - стандарт интерфейса, служащего для связи внешней программы с веб-сервером. Программу, которая работает по такому интерфейсу совместно с веб-сервером, принято называть шлюзом, хотя многие предпочитают названия скрипт (сценарий) или CGI-программа. Сам интерфейс разработан таким образом, чтобы можно было использовать любой язык программирования, который может работать со стандартными устройствами ввода/вывода. Такими возможностями обладают даже скрипты для встроенных командных интерпретаторов операционных систем, поэтому в тех случаях, когда нет нужды в сложной функциональности, могут использоваться даже такие простые командные скрипты. Отличается от остальных рассматриваемых технологий тем, что является наиболее низкоуровневой и является стандартом интерфейса, который служит для связи внешней программы с web-сервером.

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

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

Для дальнейшего выбора технологии воспользуемся исследованиями, предоставленными в открытый доступ [6].

В тестировании принимали участие:

· Tomcat (internal web server);

· mod_php 4.0b2;

· mod_perl 1.21;

· JRun 2.3.3/Apache 1.3.9;

· ServletExec 2.2/Apache 1.3.9;

· CGI using Perl.

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

· сервер - 300 Mhz Pentium II, RedHat 6.0/64 Мб оперативной памяти;

· клиент - 300 Mhz Celeron, RedHat 6.0/32 Мб оперативной памяти.

Используемые тесты:

File. В данном тесте производилось чтение и передача небольшого (311 байт) статичного файла - т.е. тестирования СТ в качестве обычного web-сервера.

Servlet. Для измерения "накладных расходов" работы СТ использовалась тестовая программа "Hello, World". Другими словами, как бы эффективно ни была написана ваша серверная программа, вы никогда не получите более высокие показатели производительности, нежели в этом тесте.

Hello. Тест, практически во всем аналогичный тесту Servlet, с тем отличием, что применялся для тестирования PHP, Perl`a и ASP, тогда как Servlet относился лишь к Java СТ.

Loop. Тест выводящий "Hello, World" в цикле суммарным объемом около 64 кб. Этот тест, особенно в сравнении с тестом Big дает довольно грубое представление о производительности базовых функций.

Big. В данном тесте производилась отправка сравнительно большого (около 64 кб) массива статичной информации.

DB. Простейший запрос к базе данных (два запроса Select). Дает оценочное представление о производительности цепочки web-сервер - СТ - сервер базы данных (точнее драйвер базы данных - сервер базы данных, даже если драйвер встроенный). Для JAVA тестов во второй части, первое число в таблице означает результаты тестирования с использованием драйвера org. gjt.

MySql. Второе число - результат тестирования с применением драйвера Caucho. В общем случае данный метод двойного тестирования демонстрирует важность драйвера базы данных для быстродействия системы в целом.

Cache. Тот же тест что и DB, но в заголовке страницы указывался "срок давности" (Expires) плюс 15 секунд от времени исполнения.

Таблица 2.1 - производительность (операций в секунду). Более высокие показатели означают большую производительность. Тест для одного пользователя.

Технология

File

Servlet

Hello

Big

DB

Cache

Mod_PHP/Apache

561

291

52

117

117

Mod_Perl/Apache

550

365

92

111

111

ServletExec/Apache/IBM

536

98

103

59

59

Tomcat/IBM

129

100

94

20

50

50

CGI Perl/Apache

550

67

28

7

7

JRun/Apache/JDK1.2

531

69

37

25

25

Tomcat/JDK 1.2

37

62

37

12

24

24

Как видно из таблицы PHP и Perl в разы опережают своих конкурентов по всем тестам, кроме "File". Поэтому мы убираем из дальнейшего рассмотрения такие технологии как сервлеты, JSP и CGI. Следует отметить, что из рассмотрения были вычеркнуты технологии на базе Resin web Server, которая является значительно более скоростной, в силу наличия ряда уязвимостей. Так, злоумышленник, согласно журналу "Хакер", после некоторых манипуляций может просмотреть JSP исходный код и получить доступ к ограниченным директориям.

Далее была проведена еще одна серия тестов. Суть их осталась прежней. Единственное существенное отличие состояло в том, что была эмулирована одновременная работа нескольких пользователей - 4 клиента и один сервер. Число четыре было выбрано неслучайно. Учитывая малое время выполнения одного теста, одновременное выполнение четырех запросов представляется, по мнению автора, вполне достаточным и отражает загрузку среднепосещаемого по российским меркам, сервера. (Предположительно около 20000 запросов в течение суток, 50% которых приходится на обед) - получаем пиковую загрузку порядка 10000 запросов в час, или 2,8 запроса в секунду. Также в тестирование была добавлена технология ASP.

Таблица 2.2 - производительность (операций в секунду). Более высокие показатели означают большую производительность. Тест для четырех пользователей.

Технология

File

Hello

Loop

Big

DB

Mod_Perl/Apache

801

385

11

97

93

ASP/IIS

1654

385

1.4

80

-

Mod_PHP/Apache

869

342

13

44

141

Для начала сравним PHP и Perl. Исходя из тестов видно, что Perl более чем в 2 раза быстрее работает с большими блоками статической информации, а PHP более чем в полтора раза опережает Perl по скорости взаимодействия с базой данных. Но именно тест "BD" мне кажется более важным, поскольку каждое обращение пользователя к приложению будет инициировать обращение приложения к базе данных. Кроме того, программы, написанные на PHP достаточно легко читаемые в отличие от Perl-программ. Исходя из вышесказанного, я делаю выбор в пользу PHP среди этих двух технологий.

Теперь сделаем последний выбор: ASP - PHP. В пользу ASP говорит ее большая производительность, но на данный момент, ASP в полном объеме существует только для платформы Windows. Разработки по переносу на другие системы ведутся, но еще не завершены и их будущие результаты трудно оценить. Что касается разработки сайтов, то ASP сильно привязана к серверу IIS, и, хотя архитектура позволяет перенести приложения ASP на другую платформу, на данный момент реальная возможность отсутствует. Таким образом важнейшее - многоплатформенность пока еще не может быть удовлетворено платформой ASP.net, а значит ее использование для такой системы пока не оправдано. Однако необходимо отметить, что такая система должна иметь возможности интеграции с платформой.net (особенно Web - сервисы), поскольку ее будущее широкое использование не вызывает сомнений.

Итак, окончательный выбор сделан в пользу PHP.

2.3.1 О достоинствах и недостатках PHP

Достоинства:

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

· бесплатен;

· в связке с MySQL является кроссплатформенной технологией;

· постоянно совершенствуется;

· допускает работу с большинством СУБД;

· объектно ориентирован;

· поддерживает все популярные протоколы (HTTP, FTP, IMАР, NNTP, POPS, net sockets и другие);

· наиболее популярен в мире и в России в частности.

PHP используется такими компаниями как "Zend", "MySQL", "Бегун", "РДВ-Медия", "Хронопей", "RU-CENTER", "АВТОВАЗ", "Microsoft", а также разработчиками "Мамбы", "МойКруг", "RedTram", "РБК" и многими другими. И, главное, именно на php написаны самые дорогие и сильные, по мнению большинства web разработчиков, системы управления контентом UMI. CMS и Bitrix.

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

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

2.4 Выбор дополнительного программного обеспечения

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

После выбора платформы мы оказываемся перед не столь широким ассортиментом Web-серверов. Для Unix остается несколько возможных вариантов: Apache, Zeus, AOL Server и Pi3Web.

С учетом того, что ранее мы уже остановили свой выбор на PHP, установленном как интегральная часть Web-сервера (SAPI), практически безальтернативным выбором является сервер Apache. Он используется на 70% Web-серверов во всем мире, и показал себя очень надежным и быстрым вариантом. Более того, мы существенно упростим себе жизнь при выборе провайдера, т.к. этот Web-сервер установлен практически у каждого отечественного провайдера.

Следует отметить, что тип используемого Web-сервера никак не влияет на синтаксис PHP, в отличие от операционной системы. Поэтому смена провайдера не повлияет на работоспособность приложения, даже при смене типа Web-сервера.

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

Сервер Apache во многом обязан своим появлением компании Netscape. В 1994 года в Netscape перешел Роб Мак-Кул (Rob McCool), который до этого работал в NCSA (National Center for Supercomputing Applications - Национальный центр суперкомпьютерных приложений) и создал Web-сервер NCSA. После его ухода из NCSA процесс разработки сервера приостановился, поэтому Web-мастера стали сами дорабатывать сервер и устранять ошибки. Несколько таких разработчиков объединили свои усилия и начали распространять свои наработки по всему миру (отсюда и название: "apatchy'' означает "защита").

Проект “Apache" - это совместные усилия по разработке программного обеспечения, нацеленное на создание оптимальной, коммерческой, многофункциональной, и свободно-распространяемой реализации HTTP сервера. Проект совместно управляется группой добровольцев, расположенных по всему миру. Коммуникация членов проекта происходит по средствам Интернет, с целью консолидирования усилий в развитии и планировании сервера и его документации. Эти добровольцы известны как Apache Group. Кроме того, сотни пользователей сети внесли свои идеи и труд в развитие и усовершенствование проекта.

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

2.5 Разработка структуры системы

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

Во-первых, системное программное обеспечение. Данный компонент представляет программное обеспечение, как на стороне клиента, так и на стороне сервера. К системному программному обеспечению относятся операционные системы, под управлением которых будет функционировать разрабатываемая CMS. В соответствии с разделом 2.1, в котором производился выбор операционных систем, были выбраны две операционный системы: Windows XP (ОС для рабочих станций), ASPLinux 9 (ОС для серверов).

Во-вторых, система управления базами данных Mysql. Данный компонент представляет программное обеспечение на стороне сервера. В соответствии с выводами, сделанными в разделе 2.2, данный продукт был выбран в качестве СУБД для проектируемой системы. Собственно, сама проектируемая база данных будет являться подкомпонентом СУБД MySQL.

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

1) Web-браузер. Программное обеспечение, находящееся на стороне клиента, и обеспечивающее доступ к СУБД посредством Web-интерфейса;

2) Web-сервер Apache. Дополнительное программное обеспечение, находящееся на стороне сервера. Web-сервер обеспечивает механизм связи удаленного клиента и СУБД, посредством протокола HTTP.

3) Интерпретатор PHP. Данное программное обеспечение находится на стороне сервера, и обеспечивает работу PHP-скриптов, реализующих интерфейс пользователя.

Рис.2.1 - Архитектура системы управления сайтом

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

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

Очевидно, что серверная часть должна состоять как минимум из сервера баз данных.

Сервер баз данных должен включать в себя СУБД (в нашем случае это MySQL), и соответственно, базу данных, содержащую информацию.

Поскольку было принято решение об использовании Web-интерфейса, то и сервер должен быть настроен в соответствии с требованием обеспечения безопасности подключения. Все ненужные возможности соединения с сервером БД должны быть отключены.

При подключении пользователя к СУБД посредством web-интерфейса используется обычное TCP/IP соединение. Поэтому сервер тоже должен быть настроен соответствующим образом.

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

Основными составляющими Web-сервера являются:

· cобственно Web-сервер (в нашем случае это Apache);

· интерпретатор PHP. Он необходим для выполнения PHP-скриптов, реализующих интерфейс пользователя;

· библиотеки PHP, которые, помимо всего прочего, должны включать набор функций, обеспечивающих доступ к серверу СУБД;

· PHP-скрипты - реализуют интерфейс пользователя.

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

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

Рассмотрим теперь структуру программного обеспечения со стороны клиента. Клиенты могут работать посредством Web-интерфейса. Со стороны клиентов находится только Web-браузер. Им может быть Internet Explorer, Opera, Mozilla и т.п.

Рассмотрим основные механизмы взаимодействия описанных компонентов информационной системы.

Удаленный пользователь, работающий посредством Web-интерфейса, взаимодействует с Web-сервером через протокол HTTP.

При этом запрос к базе данных передается Web-серверу, тот в свою очередь, принимает его и обрабатывает в соответствии с кодом, написанным в PHP-скриптах, и соответственно генерирует SQL запрос к серверу СУБД.

Web-сервер взаимодействует с сервером СУБД через протоколу TCP/IP.

Сервер СУБД, приняв запрос, формирует ответ, и передает результат обратно Web-серверу. После этого в соответствии с кодом PHP-скрипта, выполнявшего данный запрос, и полученных данных, формируется ответ пользователю в виде html-страницы. Данная страница передается Web-серверу, и после этого сервер передает ее клиенту.

3. Разработка системы управления сайтом и заявками на бронирование номеров

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

· Основной функционал, затребованный заказчиком в самом начале;

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

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

3.1 Разработка базового функционала системы управления сайтом и заявками на бронирование

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

3.1.1 Разработка системы доступа к административной части

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

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

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

Основным элементом сеанса является его идентификатор (session identifier), который однозначно определяет сеанс. Сгенерированный и отправленный клиенту при первом запросе идентификатор сеанса должен быть уникальным и в то же время достаточно защищенным, чтобы злоумышленник не мог легко его подделать.

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

3.1.1.1 Обеспечение повышенной безопасности

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

а) Использование временных интервалов истечения срока:

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

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

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

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

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

3.1.1.2 Разработка структуры пользовательских сеансов

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

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

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

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

Название

Тип данных

Описание

id_session

int

Идентификатор сессии. Первичный ключ

id_user

int

Идентификатор пользователя. Указывает непосредственно на зарегистрированного пользователя, к которому относится сессия

ascii_session_id

varchar (32)

32-символьный идентификатор сессии

logged_in

bool

Флаг, говорящий о том, авторизовался ли пользователь под этой сессией

last_impression

datetime

Время и дата последнего запроса к странице в течение сеанса

created

datetime

Время создания сессии

user_agent

varchar (255)

Содержит информацию о пользовательском агенте (броузер и пр.)

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

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

Название

Тип данных

Описание

id_session

int

Идентификатор сессии. Указывает на сессию, к которой относится переменная

id_variable

int

Идентификатор переменной. Первичный ключ

variable_name

varchar (70)

Имя переменной

variable_value

text

Значение переменной

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

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

Название

тип данных

Описание

id_user

int

Идентификатор пользователя. Первичный ключ.

username

varchar (32)

Имя пользователя (логин).

md5_pw

varchar (32)

Пароль

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

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

Название

тип данных

Описание

id_user

int

Идентификатор пользователя. Указывает на пользователя, к которому относятся права

to_access

int

Идентификатор раздела, к которому осуществляется доступ. Указывает на раздел, к которому относятся права.

access_level

int

Уровень доступа

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

Название

тип данных

Описание

to_access

int

Идентификатор раздела, которому можно настроить права доступа. Первичный ключ

name

varchar (20)

Имя раздела.

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

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

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

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

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

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

Название

тип данных

Описание

id_hotel

int

Идентификатор гостинцы. Первичный ключ.

id_adress

int

Идентификатор адреса. По нему находится адресная информация о гостинице.

id_meta

int

Идентификатор мета-данных. По нему находится информация о мета-тегах гостиницы.

id_created

int

Идентификатор создания. По нему находится информация о первом внесении информации о гостинице в базу данных.

id_modify

int

Идентификатор изменений. По нему находится информация о последних изменениях данных о гостинице.

id_hotel_type

int

Идентификатор типа гостиницы. По нему находится информация о типе гостиницы (гостиница/отель…).

id_service

int

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

id_reserving

int

Идентификатор бронирования. По нему находится информация об условиях бронирования гостиницы.

id_publish

int

Идентификатор публикования. По нему находится информация о необходимости размещения информации о гостинице в общий доступ.

name

varchar (70)

Название гостиницы.

stars

int

Категории гостиницы (уровень звездности).

numbers

int

Общее количество номеров в гостинице.

description

text

Описание гостиницы.

sort_num

int

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

Важными не только для описания гостиниц являются таблицы publish (таблица 3.7), modify (таблица 3.8), created (таблица 3.9), metas (таблица 3.10). Ссылки на них будут встречаться и в дальнейшем.

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

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

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

Название

тип данных

Описание

id_publish

int

Идентификатор публикования. Первичный ключ.

publish

bool

Флаг публикования. Ноль - не выводить на сайте.

publish_start

datetime

Время с которого можно выводить информацию на сайте (если publish=1).

publish_finish

datetime

Время до которого можно выводить информацию на сайте.

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

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

Название

тип данных

Описание

id_modify

int

Идентификатор изменений. Первичный ключ.

id_user

bool

Идентификатор пользователя. Указывает на пользователя, внесшего соответствующее изменение.

modify_date

datetime

Время последнего изменения.

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

Название

тип данных

Описание

id_created

int

Идентификатор создания. Первичный ключ.

id_user

bool

Идентификатор пользователя. Указывает на пользователя, внесшего соответствующее изменение.

create_date

datetime

Время создания.

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

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

Название

тип данных

Описание

id_meta

int

Идентификатор мета-данных.

title

bool

Заголовок Интернет-страницы.

keywords

datetime

Ключевые слова Интернент-страницы.

description

Описание Интернет страницы.

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

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

Название

тип данных

Описание

id_reserving

int

Идентификатор условий бронирования. Первичный ключ.

conditions

varchar (255)

Условия бронирования

annulation

varchar (255)

Условия аннуляции.

arrival_time

datetime

Время и дата прибытия (заезда).

departure_time

datetime

Время и дата выезда.

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

Название

тип данных

Описание

id_service

int

Идентификатор списка услуг. Первичный ключ.

excurtion

bool

Заказ экскурсий.

24hour_service

bool

24ч обслуживание в номерах.

car_parking

bool

Автостоянка.

currency_exchange

bool

Обмен валюты.

hairdressing

bool

Парикмахерская.

safe

bool

Сейф у администратора.

ticket_reservation

bool

Заказ авиа и ж/д билетов.

baggage_room

bool

Камера хранения багажа.

smoking

bool

Курение в номере.

dry_cleaner

bool

Химчистка.

shops

bool

Магазины.

guard_station

bool

Пост охраны.

transport_reservatuion

bool

Заказ транспорта.

internet_access

bool

Доступ в Интернет.

jacuzzi

bool

Джакузи.

wash_house

bool

Прачечная.

first_aid_post

bool

Медпункт.

additional

varchar (255)

Дополнительные услуги, которые не входят в заранее определенный список.

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

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

Структура адреса гостиниц (рисунок 3.3) является универсальной, она не привязана непосредственно к гостиницам и может использоваться где угодно.

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

Центральным элементом в структуре адреса выступает таблица address (таблица 3.13). Она включает в себя, на первый взгляд, избыточную связь с таблицей city (таблица 3.15), но это сделано специально, т.к. ряд городов просто не имеет районов.

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

Название

тип данных

Описание

id_adress

int

Идентификатор адреса. Первичный ключ.

Id_region

int

Идентификатор региона.

Id_city

int

Идентификатор города.

Id_street_type

int

Идентификатор типа улицы (улица/проспект/переулок…).

Street_name

varchar (70)

Название улицы.

House

int

Номер дома.

Building

int

Корпус.

Apartment

int

Номер квартиры.

Post_index

int

Почтовый индекс.

Таблицы country (таблица 3.14), city (таблица 3.15) и region (таблица 3.16) служат для описания страны, города и района соответственно.

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

Название

тип данных

Описание

id_country

int

Идентификатор страны. Первичный ключ.

country

varchar (70)

Название страны.

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

Название

тип данных

Описание

id_city

int

Идентификатор города. Первичный ключ.

id_country

int

Идентификатор страны. Указывает на страну, к которой относится город.

city

varchar (70)

Название города.

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

Название

тип данных

Описание

id_region

int

Идентификатор раона. Первичный ключ.

id_city

int

Идентификатор города. Указывает на город, к которому относится район.

region

varchar (70)

Название района.

В таблице street_type (таблица 3.17) хранится информация о типе улицы. Например: улица, проспект, переулок, шоссе и т.д.

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

Название

тип данных

Описание

id_street_type

int

Идентификатор типа улицы. Первичный ключ.

name

varchar (70)

Название типа улицы.

На основе описанной структуры созданы соответствующие классы, главным из которых является класс Adress. Его код представлен в приложении.

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

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

Рисунок 3.4 - ER-диаграмма телефонов гостиницы

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

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

Название

тип данных

Описание

id_phone

int

Идентификатор телефона. Первичный ключ.

id_phone_type

int

Идентификатор типа телефона.

code

int

Код телефона.

number

int

Номер телефона

description

varchar (255)

Описание телефона

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

Название

тип данных

Описание

id_phone_type

int

Идентификатор типа телефона. Первичный ключ.

name

varchar (10)

Название типа телефона.

Многие гостиницы имеют несколько телефонов, поэтому для обеспечения связи "многие ко многим" используется дополнительная таблица hotel_phone (таблица 3.20), а для того, чтобы различать телефоны между собой можно хранить описание телефонов в таблице phone.

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

Название

тип данных

Описание

id_hotel

int

Идентификатор гостиницы.

id_phone

int

Идентификатор телефона.

Основным классом, использующимся для описания этой структуры, является класс Phone. Его код можно найти в приложениях.

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

По желанию заказчика система предусматривает введение информации о различных номерах гостиницы. Соответствующую этому ER-диаграмму можно увидеть на рисунке 3.5.

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

Естественно, здесь главным элементом выступает таблица number (таблица 3.21). Именно в ней заложена связь номеров с соответствующими им гостиницами (поле id_hotel). В структуре присутствуют уже встречавшиеся ранее таблицы publish (таблица 3.7), modify (таблица 3.8) и created (таблица 3.9). Они предназначены для определения необходимости вывода информации о номере, хранения информации о последних изменениях и о создании соответственно.

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

Название

тип данных

Описание

id_number

int

Идентификатор номера. Первичный ключ.

id_hotel

int

Идентификатор гостиницы. Указатель на гостиницу, к которой относится номер.

id_publish

int

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

id_created

int

Идентификатор создания. По нему находится информация о первом внесении информации о номере в базу данных.

id_modify

int

Идентификатор изменений. По нему находится информация о последних изменениях данных о номере.

name

varchar (70)

Название номера.

num_of_numbers

int

Количество номеров соответствующего типа.

description

text

Описание номера.

list_num

int

Сортировочный номер. Требуется для сортировки номеров в списке между собой.

Для хранения информации о стоимости каждого из номеров требуется 2 таблицы: period (таблица 3.22) и price (таблица 3.23). Дело в том, что в различные периоды спрос на гостиницы различен, а значит различны и цены, поэтому за счет таблицы period задается интервал, которому будет соответствовать цена, а за счет таблицы price уже непосредственно сама стоимость проживания.

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

Название

тип данных

Описание

id_period

int

Идентификатор периода. Первичный ключ.

id_hotel

int

Идентификатор гостиницы. Указывает, к какой гостинице относится данный период.

start_date

date

Дата с которой будут вступать в действие соответствующие периоду цены.

finish_date

date

Дата до которой будут действительны соответствующие периоду цены.

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

Название

тип данных

Описание

id_price

int

Идентификатор цен. Первичный ключ.

id_number

int

Идентификатор номера. Указывает, к какому номеру относятся цены.

id_period

int

Идентификатор периода. Указывает на период к которому относятся цены.

price

int

Стоимость одноместного размещения.

price2

int

Стоимость двухместного размещения.

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

3.1.3 Разработка структуры представления заявок

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

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

Центральным элементом в структуре выступает таблица demand (таблица 3.24). Она содержит в себе всю необходимую информацию или ссылки на нее. В частности в ней содержатся идентификаторы бронируемых гостиницы и номера в ней. Это не избыточные связи. Дело в том, что бывают случаи, когда клиент выбрал гостиницу, но не определился с номером в ней.

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

Название

тип данных

Описание

id_demand

int

Идентификатор заявки. Первичный ключ.

Id_person

int

Идентификатор личности. Указатель на информацию о человеке, сделавшем заказ.

Id_phone

int

Идентификатор телефона. Указатель на информацию о телефоне для связи.

Id_status

int

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

id_price_type

int

Идентификатор типа оплаты. Определяет предпочитаемый клиентом способ оплаты.

Id_transfer

int

Идентификатор трансфера. Определяет требуются ли клиенту трансферные услуги.

Id_hotel

int

Идентификатор гостиницы. Указывает на гостиницу, в которой желает поселиться клиент.

Id_number

int

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

Id _connection_type

int

Идентификатор типа связи. Определяет предпочитаемый клиентом способ связи (e-mail, телефон и прочие).

Comments

varchar (255)

Комментарии, которые может оставить к заявке администратор.

Min_price

int

Минимальная цена, которую готов платить клиент за проживание.

Max_price

int

Максимальная цена, которую готов платить клиент за проживание.

Wishes

text

Дополнительные пожелания клиента.

В таблице demand содержится ряд указателей на таблицы, которые помимо идентификатора содержат лишь поле name: transfer (таблица 3.25), status (таблица 3.26), price_type (таблица 3.27), connection_type (таблица 3.28). Все эти таблицы содержат строго определенный заказчиком перечень значений, который представлены в соответствующих таблицах (список значений может быть расширен).

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

Название

тип данных

Описание

id_transfer

int

Идентификатор трансфера. Первичный ключ.

name

varchar (40)

Возможные значения: “Без трансфера”, “От аэропорта до гостиницы”, “От вокзала до гостиницы”.

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

Название

тип данных

Описание

id_status

int

Идентификатор статуса заявки. Первичный ключ.

name

varchar (40)

Возможные значения: “Не рассмотрена”, “Отклонена”, “В обработке”, “Выполнена”.

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

Название

тип данных

Описание

id_price_type

int

Идентификатор типа оплаты. Первичный ключ.

name

varchar (70)

Возможные значения: “Наличными”, “Перевод от физического лица”, “Перевод от юридического лица”.

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

Название

тип данных

Описание

id_connection_type

int

Идентификатор типа связи. Первичный ключ.

name

varchar (20)

Возможные значения: “По телефону”, “По электронной почте”, “С помощью icq”.

Также для полного описания заявки используется описанная ранее таблица phone (таблица 3.18) и таблица person (таблица 3.29), содержащая необходимую информацию непосредственно о клиетне.

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

Название

тип данных

Описание

id_person

int

Идентификатор личности. Первичный ключ.

id_city

int

Идентификатор города. Указывает на город, из которого приезжает клиент.

surname

varchar (70)

Фамилия клиента.

name

varchar (70)

Имя клиента.

email

varchar (150)

Электронный адрес клиента.

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

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

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

3.2.1 Разработка структуры фотогалереи


Подобные документы

Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д.
PPT, PPTX и PDF-файлы представлены только в архивах.
Рекомендуем скачать работу.