Автор работы: Пользователь скрыл имя, 29 Апреля 2014 в 17:16, дипломная работа
Web-приложение – клиент-серверное приложение, в котором сервером выступает web-сервер, клиентом программа или устройство, способное получить доступ к web-серверу. Логика web-приложения распределена между сервером и клиентом, хранение данных осуществляется преимущественно на сервере, обмен информацией происходит по сети.
Web - сервер — это сервер, принимающий HTTP-запросы от клиентов, обычно веб-браузеров, и выдающий им HTTP-ответы, обычно вместе с HTML-страницей, изображением, файлом, медиа-потоком или другими данными.
CMS (Content management system) – компьютерная система или программа, используемая для обеспечения и организации совместного процесса создания, редактирования и управления текстовыми и мультимедиа документами.
Обозначения и сокращения 6
Определения 7
Введение 9
1. Описание основных используемых технологий и языков программирования 10
1.1. Общие сведения 10
1.2. Язык программирования PHP 10
1.3. Web-сервер Apache 11
1.4. СУБД MySQL 12
1.5. Язык программирования JavaScript 12
1.6. Технология AJAX 13
1.7. Таблица стилей CSS 14
1.8. Общая схема работы web-приложения 14
2. Описание системы «1С – Битрикс: Управление сайтом» 16
2.1. Общие сведения 16
2.2. Преимущества и недостатки системы 16
2.3. Целесообразность использования системы 18
2.4. Сравнение с другими системами 19
3. Описание API системы «1С – Битрикс: Управление сайтом» 21
3.1. Общие сведения 21
3.2. API модуля «Главный модуль» 21
3.3. API модуля «Информационные блоки» 23
4. Формирование требований к сценариям работы web-приложения 26
4.1. Общие сведения 26
4.2. Список требований 26
5. Диаграмма информационных блоков 29
5.1. Общие сведения 29
5.2. ER – диаграмма данных web-приложения 29
5.3. Определение информационных блоков 31
6. Описание программных компонентов 34
6.1. Создание общей структуры страниц web-приложения 34
6.2. Реализация структуры страниц web-приложения, физическая структура 36
6.3. Список программных компонентов 39
6.3.1. Компонент «Список всех игр» 39
6.3.2. Компонент «Список новых и выходящих игр» 40
6.3.3. Компонент «Список лучших игр» 42
6.3.4. Компонент «Список 100 лучших игр» 43
6.3.5. Компонент «Фильтр по играм» 44
6.3.6. Компонент «Поиск по играм» 45
6.3.7. Компонент «Автоподсказки в поиске» 46
6.3.8. Компонент «Список обзоров к игре» 47
6.3.9. Компонент «Детальная страница игры» 48
6.3.10. Компонент «Форма поиска» 48
6.3.11. Компонент «Страница разработчика игры» 49
6.3.12. Компонент «Список лучших игр за год» 50
6.4. Диаграмма связей между страницами web-приложения и компонентами 51
6.5. Особенности реализации сценариев работы web-приложения. 51
6.5.1. Общие сведения 51
6.5.2. Сохранение состояния страниц при использовании AJAX – запросов 52
6.5.3. Обработка событий панели управления. 55
7. Резервное копирование данных web-приложения. Система управления версиями 59
7.1. Общие сведения 59
7.2. Реализация резервного копирования 59
7.3. Система управления версиями 62
7.3.1. Описание системы Subversion 62
7.3.2. Настройка Subversion для работы с web-приложением 64
8. Нагрузочное тестирование 69
8.1. Общие сведения 69
8.2. Техника проведения нагрузочного тестирования 69
8.3. Оценка результатов тестирования 71
Заключение 76
Список использованных источников 77
Приложение A. Принцип работы системы «1С – Битрикс: Управление сайтом» 78
А.1. Общие сведения 78
А.2. Модульная структура системы 78
А.2.1. Главный модуль 79
А.2.2. Модуль «Управление структурой» 79
А.2.3. Модуль «Информационные блоки» 80
А.3. Компоненты 81
А.3.1. Общие сведения 81
А.3.2. Файловая структура компонента 81
А.3.3. Схема обмена данными между файлами компонента 85
А.3.4. Публичный раздел системы 87
А.3.4.1. Порядок загрузки страницы web-приложения 87
А.3.4.2. Подключение модулей системы 87
А.3.4.3. Подключение шаблонов web-приложения 88
А.3.4.4. Подключение компонентов web-приложения 88
Приложение Б. Требования заказчика к работе web-приложения и дизайн-концепция 90
Приложение В. Исходные коды программных компонентов 95
В.1. Компонент games.calendar 95
В.2. Компонент games.raiting 99
В.3. Компонент games.filter 102
В.4. Компонент games.search 113
В.5. Компонент games.detail 117
В.6. Компонент search_autocomplete 121
В.7. Компонент reviews.list 126
Метод разбивает результат выборки на страницы.
void NavPrint(string title, bool show_always=false, string text_css_class="text", string template_path=false)
Метод выводит ссылки для постраничной навигации.
Класс CModule.
CModule – класс для работы с модулями.
bool IncludeModule(string module_id)
Метод проверяет установлен ли модуль module_id и если установлен, подключает его. Возвращает "true", если модуль установлен, иначе - "false".
Класс CBitrixComponent.
CBitrixComponent – класс для работы с компонентами web-приложения.
bool StartResultCache(int cacheTime, string additionalCacheID, string cachePath)
Метод поддержки внутреннего кэширования компонента. Если кэш действителен, метод отправляет на экран его содержимое. Если кэш недействителен, метод возвращает true, кэширование завершается и кэш сохраняется.
void AbortResultCache()
Метод отменяет кэширование в компоненте.
bool ClearResultCache(string additionalCacheID, string cachePath)
Метод очищает кэш компонента. В случае успешного выполнения очистки возвращает true.
void IncludeComponentTemplate(
Метод инициирует и подключает шаблон компонента.
Программный интерфейс данного модуля предназначен для работы с информационными блоками web-приложения. В первую очередь с помощью классов и функций данного API можно получить необходимые данные из информационных блоков, обработать или изменить их.
Можно выделить следующий список классов и их методов, использованных при разработке web-приложения.
Класс СIBlock.
CIBlock – класс для работы с информационными блоками.
СDBResult GetList(array arOrder = array("SORT"=>"ASC), array arFilter)
Метод возвращает список информационных блоков по фильтру arFilter, отсортированный в порядке arOrder.
CDBResult GetByID(int ID)
Метод возвращает информационный блок по его ID.
Класс CIBlockElement.
CIBlockElement – основной класс модуля
«Информационные блоки». Данный
класс предоставляет набор
CIBlockResult GetList(array arOrder = array("SORT"=>"ASC"), array arFilter = array(), mixed arGroupBy = false, mixed arNavStartParams = false, array arSelectFields = array())
Возвращает список элементов по фильтру arFilter, отсортированных в порядке arOrder. Элементы могут быть группированы по правилам, указанным в массиве arGroupBy, ограничены по количеству по правилам, указанным в массиве arNavStartParams. Могут быть выбраны только поля и свойства, указанные в массиве arSelectFields.
bool SetPropertyValueCode(int ELEMENT_ID, string PROPERTY_CODE, string PROPERTY_VALUE)
Метод устанавливает свойству с кодом, равным PROPERTY_CODE, элемента с ID, равным ELEMENT_ID, значение PROPERTY_VALUE.
Класс CIBlockSection.
CIBlockSection – класс для работы с разделами информационных блоков.
CIBlockResult GetList(array arOrder = array("SORT"=>"ASC"), array arFilter = array(), bool bIncCnt = false)
Метод возвращает список разделов информационных блоков, отсортированный в порядке arOrder и отфильтрованный по правилам, заданным в arFilter.
CIBlockResult GetNavChain(int IBLOCK_ID, int SECTION_ID)
Метод возвращает путь по дереву от корня до раздела SECTION_ID.
Класс CIBlockResult.
CIBlockResult - вспомогательный класс
для работы с объектами
void SetUrlTemplates(string DetailUrl = "", string SectionUrl = "", string ListUrl = "")
Метод устанавливает шаблоны путей для элементов, разделов и списка элементов вместо тех, которые указаны в настройках информационного блока.
_CIBElement GetNextElement()
Метод возвращает из выборки объект _CIBElement,
и передвигает курсор на следующую запись.
Если достигнута последняя запись (или
в результате нет записей), функция вернет
false.
Класс _CIBElement.
_CIBElement - вспомогательный класс для работы с объектами, которые возвращает CIBlockResult::GetNextElement.
array GetFields()
Метод возвращает массив значений полей элемента.
array GetProperties(arOrder = array(), arFilter = array())
Метод возвращает значения свойств текущего элемента информационного блока.
В системе «1С – Битрикс: Управление сайтом» функциональность web-приложения определяется функциональностью программных компонентов, которые разрабатываются в зависимости от требований заказчика к работе web-приложения. Как правило, заказчик предоставляет подробное словесное (не содержащее технических деталей) описание работы страниц web-приложения, которое должно быть обработано проектировщиком, и на основе которого должны быть выделены конкретные требования к работе web-приложения, определены основные сценарии и последовательность их вызова. При этом заказчик имеет возможность внести свои замечания в разрабатываемую программную модель на любом этапе и сделать вывод о том, что модель полностью его удовлетворяет, и имеет смысл переходить к следующему этапу непосредственной реализации спроектированной модели.
Специфика разработки web-приложения такова, что при построении программной модели немаловажную роль играет так называемая дизайн-концепция, т.е. представление внешнего вида страниц web-приложения, которое разрабатывается специалистом в области дизайна и прикладывается к требованиям заказчика. Вид сформированных специалистом в области дизайна страниц web-приложения позволяет разработчику определить связи между страницами web-приложения и дополнить список параметров и шаблонов компонентов.
В нашем случае в начале работы над web-приложением заказчиком были предоставлены как описание работы будущего web-приложения, так и дизайн концепция, на основании которых можно поэтапно разработать программную модель работы web-приложения. Требования заказчика и дизайн-концепция находятся в приложении Б.
В процессе анализа присланных заказчиком документов можно выделить следующий список требований к web-приложению:
Рисунок 2 – список требований к сценариям работы web-приложения
На рисунке 2 приведены все требования к работе web-приложения и указана связь между отдельными требованиями. Следует заметить, что не все требования в дальнейшем будут представлять собой программные компоненты. Часть требований подразумевает конфигурацию системы, часть требований будет реализована в логике работы компонента, реализующего другие требования.
При формировании информационных блоков независимо от того, как конкретно реализуется в системе хранение данных, следует сначала разработать модель данных, воспользовавшись диаграммой «Сущность - связь».
Проанализировав требования, можно выделить четыре основных сущности:
Сущность «Игра».
В состав сущности «Игра» можно включить следующие основные атрибуты:
Ключевым атрибутом сущности является атрибут «Код».
Сущность «Обзор».
В состав сущности «Обзор» входят следующие основные атрибуты:
Сразу выделить ключевой атрибут сущности сложно, так как вполне возможно появление в системе абсолютно идентичных по значениям атрибутов экземпляров данной сущности. Возможно, в процессе реализации, придется ввести искусственный уникальный идентификатор.
Сущность «Разработчик».
В состав сущности «Разработчик» входят следующие основные атрибуты:
Ключевым атрибутом сущности является атрибут «Наименование».
Сущность «Платформа».
В состав сущности «Платформа» входят следующие основные атрибуты:
Ключевым атрибутом сущности является атрибут «Название».
Таким образом, можно построить диаграмму:
Игра |
Код Название Уменьшенная обложка Обложка Английское название Метаоценка Официальный сайт Дата выхода в России Жанр Системные требования |
Платформа |
Название Иконка Большая иконка
|
Рисунок 3 – Диаграмма «Сущность - связь»
После того, как сформирована ER-диаграмма, можно приступить к непосредственному определению информационных блоков, их полей и свойств. Наиболее простым решением данной задачи было бы создание для каждой из сущностей «Игра», «Разработчик», «Обзор», «Платформа» информационного блока и указания его полей и свойств.
Тем не менее, если проанализировать возможности, которые предоставляет система «1С – Битрикс: Управление сайтом» в модуле «Информационные блоки», можно сделать вывод, что наиболее удобно было бы сущности «Игра» и «Платформа» объединить в одном информационном блоке, сопоставив сущности «Игра» элемент информационного блока, сущности «Платформа» - раздел информационного блока. Взаимосвязь разделов и элементов информационного блока обеспечивает возможность реализации связи, предусмотренной между сущностями «Игра» и «Платформа». Причем, обеспечивается как обязательность связи, так и отношение «многие ко многим».
В итоге получаем первый информационный блок – «Игры». Часть атрибутов сущности «Игра» может быть представлена в виде полей информационного блока, часть - с помощью свойств. То же самое можно сказать и об атрибутах сущности «Платформа», только здесь будут использованы поля и свойства раздела информационного блока. В системе, как уже сказано выше, предусмотрен внутренний механизм связи между разделами и элементами информационных блоков, поэтому введения дополнительных идентификаторов при реализации связей между сущностями не предполагается. Среди свойств элементов информационного блока необходимо предусмотреть свойство, с помощью которого будет реализована связь с информационном блоком, реализующем сущность «Разработчик». Значением данного свойства будет наименование разработчика, при этом связь обязательна.
Для реализации сущности «Обзор» следует предусмотреть еще один информационный блок «Обзоры». Экземпляры сущности «Обзоры» реализуются в информационном блоке посредством элементов, атрибуты сущности - посредством полей и свойств элемента. Среди свойств следует предусмотреть поле, которое будет являться внешним ключом и обеспечивать связь информационным блоком «Игры». Это поле будет содержать идентификатор элемента информационного блока «Игры», причем у каждого элемента это поле должно быть заполнено (обязательность связи).