Содержание к диссертации
Введение
1 Анализ технологий и методов Web-разработки 19
1.1 Анализ технологий серверной стороны 23
1.1.1 Иерархическая модель инструментариев 23
1.1.2 Языки программирования 26
1.1.3 Динамические платформы FastCGI и CGI 28
1.2 Использование декларативных и предметно-ориентированных языков на серверной стороне 28
1.2.1 Общие сведения 28
1.2.2 Язык WebDSL 29
1.2.3 Язык Spicey 30
1.3 Требования к этапам формирования нового предметно ориентированного языка 31
1.3.1 Общие принципы 31
1.3.2 Требования к стадии принятия решения 32
1.3.3 Требования к стадии анализа 35
1.3.4 Требования к стадии проектирования 37
1.3.5 Требования к стадии внедрения 39
1.4 Выводы по первой главе 41
1.4.1 Постановка цели и задач исследования 41
2 Разработка методики декларативного программирования Web-узлов и приложений 42
2.1 Разработка структуры методики и выявление базовых компонентов 42
2.2 Разработка компоненты «Модель» 45
2.3 Разработка компоненты «Локация» з
2.4 Разработка компоненты «Набор» 48
2.5 Разработка компоненты «Блок» 54
2.5.1 Классифицирование блоков 54
2.5.2 Разработка атрибутов блока 54
2.5.3 Разработка базовых и составных блоков с их атрибутами 60
2.5.4 Разработка файловых блоков и их атрибутов 73
2.6 Разработка унифицированного метода разграничения прав доступа к данным 82
2.6.1 Построение авторизационного набора и метода учёта пользователей 82
2.6.2 Построение набора групп 83
2.6.3 Разработка функционала прав доступа на блоки и экземпляры набора 84
2.7 Разработка унифицированного метода получения пользовательских данных с учётом их характерных особенностей 86
2.7.1 Алгоритм обработки чтения пользовательских данных идемпо-тентного запроса 86
2.7.2 Алгоритм сохранения пользовательских данных модифицирующего запроса 87
2.7.3 Алгоритм приёма данных при взаимодействии с BML 88
2.8 Разработка алгоритмов взаимодействия с шаблонизатором 90
2.8.1 Алгоритм получения данных от интерпретатора 90
2.8.2 Алгоритм обработки ошибок валидации данных 90
2.9 Разработка критерия оптимальности выбора релевантного объекта в задаче динамической маршрутизации Web-адресов, идентифицируемых шаблоном 93
2.9.1 Алгоритм упрощения регулярного выражения 94
2.9.2 Алгоритм вычисления мощности в пересекаемых множествах 97
2.9.3 Алгоритм поиска фактора неопределённости 97
2.10 Выводы по второй главе 98
3 Разработка метода комплексной оценки инструментов императивной и декларативной разработки динамических Web-узлов 100
3.1 Разработка обобщённой оценочной модели 101
3.2 Определение итоговой величины стоимости критерия оценки 106
3.2.1 Применение метода анализа иерархий 106
3.3 Вычисление количественных показателей программного кода методом Холстеда 110
3.3.1 Тестирование набора рецептов 113
3.4 Выводы по главе 3 118
4 Разработка программного комплекса интерпретатора языка BML и визуального редактора BlockSet 119
4.0.1 Требования к языку программирования и динамической платформе 119
4.0.2 Анализ динамической платформы CGI 120
4.0.3 Анализ динамической платформы FastCGI 121
4.0.4 Нагрузочное тестирование динамических платформ 121
4.1 Разработка архитектуры и компонентов программного комплекса интер претатора 125
4.1.1 Построение структуры 125
4.1.2 Исследование синтаксических анализаторов XML 127
4.2 Архитектура абстрактной фабрики блоков 129
4.2.1 Альтернативные решения 132
4.3 Выбор шаблонизатора 134
4.3.1 Особенности программирования шаблонизатора 135
4.4 Разработка архитектуры программного комплекса синхронизатора 137
4.4.1 Обоснование целесообразности разработки 137
4.4.2 Разработка общего алгоритма работы 138
4.4.3 Анализ технологий межпроцессного взаимодействия 138
4.4.4 Проведение нагрузочного тестирования 140
4.4.5 Разработка алгоритма сетевого взаимодействия 140
4.4.6 Разработка структуры базы данных и алгоритма ее перестроения 143
4.4.7 Разработка алгоритма синхронизации отношений таблиц с наборами144
4.5 Разработка интерфейсов визуального редактора построения структур декларативного языка BML 146
4.5.1 Разработка мастера создания нового проекта 147
4.5.2 Разработка интерфейса редактора набора 147
4.5.3 Разработка интерфейса редактора блока 147
4.5.4 Разработка интерфейса редактора локации и модели 148
4.5.5 Разработка интерфейса редактора прав доступа 148
4.6 Выводы по главе 4 148 Заключение 159
Список литературы 163
- Использование декларативных и предметно-ориентированных языков на серверной стороне
- Разработка базовых и составных блоков с их атрибутами
- Применение метода анализа иерархий
- Проведение нагрузочного тестирования
Использование декларативных и предметно-ориентированных языков на серверной стороне
Большинство языков Web-программирования интерпретируемые, то есть весь программный код сохранён в явном виде в текстовых файлах — скриптах, а специализированная программа, называемая интерпретатором, построчно считывает исходный код и исполняет его «на лету» каждый раз во время поступления запроса от пользователя на соответствующий модуль. Интерпретируемые языки являются противоположностью компилируемым языкам, где компилятор преобразует программный код на языке высокого уровня в исполняемый модуль в двоичном виде, который, в свою очередь, может быть исполнен напрямую машиной.
Преобладание интерпретируемых языков в сфере Web-программирования обусловлено спецификой отрасли: программы на таких языках не требуют постоянной перекомпиляции, что позволяет разработчику менять логику работы приложения лишь изменяя соответствующие скриптовые файлы. У подобного удобства есть и обратная сторона — интерпретируемый код исполняется на несколько порядков медленнее компилируемого. Основной целью разработчиков интерпретаторов является уменьшение накладных расходов и, как следствие, технологического разрыва по скорости между компилируемыми и интерпретируемыми языками. Для этого применяются различные акселераторы и интеллектуальные алгоритмы повторного использования кода. Такая же цель стоит и перед системными архитекторами, разрабатывающими архитектуру Web-сервера и внедряющие кэширование как на клиентской, так и на серверной сторонах. Рзработчики на интерпретируемых языках программирования также оптимизируют код, перенося, по возможности, рутинную логику на существующие бинарные модули интерпретатора, выполняющиеся на несколько порядков быстрее.
Все известные интерпретируемые языки Web-программирования используют интерпретаторы, реализованные либо в виде подключаемых модулей и динамически загружаемые Web-сервером, либо в виде отдельного программного модуля, запуска 27 ющегося через системный вызов. В первом случае интерпретатор, таким образом, становится частью Web-сервера. Это устраняет накладные расходы на запуск и инициализацию внешнего программного модуля, требующийся в первом случае, т.к. интерпретатор работает внутри Web-сервера, который уже запущен и ожидает новых подключений. В случае, если требуется запускать интерпретатор в виде отдельного программного модуля, используются специализированные интерфейсы-посредники CGI или FastCGI.
Наиболее распространённые языки программирования, применяемые на серверной стороне, также являются предметно-ориентированными, однако зачастую их область применения выходит далеко за пределы Web, поэтому граница между предметно-ориентированным языком и языком общего назначения здесь весьма условна. Например, язык Perl (англ. Practical Extraction and Report Language, практический язык извлечения данных и составления отчётов) изначально был разработан как эффективный инструмент обработки текстовых данных с поддержкой гибкой работы регулярных выражений. Чуть позже язык предстал в качестве скриптового языка оболочки операционных систем семейства UNIX, а с появлением стандарта CGI в 1993 году язык Perl стал одним из первых языков, используемых при разработке Web-приложений.
Язык Python, будучи также императивным интерпретируемым и одновременно компилируемым языком, разрабатывался, как язык общего назначения для широкого спектра задач. На сегодняшний день Python используется в качестве интегрируемого скриптового языка в различных проектах. Это обусловлено его простым синтаксисом. Также, как и Perl, язык используется в качестве скриптов оболочки. Язык также широко используется в прикладном программировании. Завоевал он популярность и в качестве языка, используемого в Web-разработке. Для Python реализовано большое количество дополнительных библиотек, реализующих основные функции для полноценной работы Web-приложения. К таким библиотекам относятся Django, Pylons, Pyramid, Zope и другие. Помимо всего прочего, существуют библиотеки, реализующие собственное решение промежуточного интерфейса взаимодействия интерпретатора и Web-сервера — WSGI [45].
Единственным широко-используемым языком программирования, изначальной целью которого было использование в качестве языка для Web-разработки, стал язык PHP (англ. PHP: Hypertext Preprocessor, PHP: препроцессор гипертекста), о чём говорит его аббревиатура. В этом языке на уровне интерпретатора реализована работа с протоколом HTTP, получение данных методами GET и POST, обработка HTTP Cookie, сессий, загружаемых файлов. Тем не менее, язык давно вышел за пределы своей предметной области и используется для решения широкого спектра задач.
Подводя итоги обзора языков программирования, важно отметить, что большинство языков программирования серверной стороны являются интерпретируемыми языками общего назначения. Это говорит об их гибкости с одной стороны и повышенной сложностью освоения с другой.
Разработка базовых и составных блоков с их атрибутами
Локация или расположение (элемент Location) представляет собой динамическую страницу, описывающую индивидуальную логику работы. У локации, как и у модели, прямыми потомками могут быть только наборы. Большинство атрибутов у наборов и блоков, присутствующих в модели, могут быть переопределены в локации, либо определены вновь. Существуют также атрибуты, характерные только для локации. То есть локация задаёт уточняющие свойства обработки тех или иных данных. Исходя из этого, можно утверждать, что локации в парадигме MVC соответствуют контроллерам.
Локация идентифицируется шаблоном адреса. Шаблон адреса представляет собой часть URI, идентифицирующую путь, и содержащую динамические вставки, на место которых подставляются данные определённого типа, фигурирующие в генерации динамической страницы. Шаблон адреса динамической страницы задаётся атрибутом base (базовый адрес). Допустимо указывать несколько шаблонов в атрибуте, разделив их запятой.
Интерпретатор находит нужную локацию по двум алгоритмам на выбор. Первый алгоритм заключается в том, что все документы языка BML считываются по имени файла в алфавитном порядке, в них ищется сначала модель, затем первая локация, шаблон которой совпадает с текущим путем, указанным пользовательском URL. Если исходный путь в URL совпадает с шаблоном локации, исполняется логика работы этой локации. Дальнейшая обработка оставшихся локаций интерпретатором не производится.
Второй алгоритм отличается от первого тем, что сначала считывается значение атрибута base у каждой из локаций, затем, в случае возникновения противоречий, вычисляется количество всех возможных комбинаций подстановок шаблона. Например, если на месте динамической вставки ожидается число (например, год), а у другой локации точно такой же шаблон, но в этой же динамической вставке ожидается строка (например, имя пользователя), то выполнится локация с меньшим количеством комбинаций, т.е. та, где ожидается число (в данном случае, год). Такой алгоритм позволяет пользователю не заострять внимание на порядке следования локаций в коде BML. Подробнее этот алгоритм разобран в разделе 2.9.
Вставки, применяемые в локациях могут быть следующего вида: [set:block] — где set является именем набора, а block — именем блока. Захваченное значение из данной вставки будет проверено на соответствие своему типу данных, указанному для блока в модели, и будет использоваться при выборке экземпляра набора. Кириллические символы в URL будут транслитированы, согласно стандарту BGN/PCGN[40]. Знаки препинания, не участвующие в формировании структуры URL, а также символы латиницы будут сохранены в первозданном виде. Остальные символы будут заменены на нижнее подчёркивание. [set@page] — ключевое слово page сообщает о том, что в данный шаблон будет подставлено число, которое интерпретатор задействует при выборке номера страницы множества экземпляров набора с именем set. Ключевое слово page остается в структуре шаблона и не изменяется. [set@id] — ключевое слово id сообщает о том, что в данный шаблон будет подставлен идентификатор набора, который интерпретатор задействует при выборке из набора с именем set. Ключевое слово id также не изменяется. @all — определяет локацию, логика которой исполняется вместе с любыми другими локациями. Другие атрибуты локации: template — устанавливается основной шаблон для данной локации. На основе шаблона и выходных данных с помошью шаблонизатора будет сгенерирован конечный документ. output — устанавливается направление потока генерируемых выходных данных локации. Допустимые значения: std – поток будет сгенерирован стандартно, в браузер клиент, email – поток будет сгенерирован и отправлен по указанному адресу элек 48 тронной почты. В последнем случае необходимо взаимодействие с атрибутом send у блока email. allowed – задаёт перечень групп, которым разрешён доступ к данной локации. В качестве указания пользователя используется его численный идентификатор. disallowed – задаёт перечень групп, которым запрещён доступ к данной локации. В качестве указания пользователя используется его численный идентификатор. onsuccess — значением атрибута является URL, на который произойдёт перенаправление в случае, если операция создания, обновления или удаления хотя бы одного или нескольких экземпляров набора выполнена успешно. Динамические вставки допустимы двух видов: те, что уже были использованы в этой же локации в атрибуте base, либо те, что относятся к создаваемому или изменяемому экземпляру набора. В первом случае значение подстановки будет скопировано из значения, ранее захваченного в base. В последнем случае динамическая вставка будет заменена на значение блока успешно изменённого или вновь добавленного экземпляра набора в данной локации. Если в обеих случаях задействован один и тот же набор, то приоритетным является второй случай. Значение none будет означать, что результат выполнения будет отправлен в ту же локацию. По умолчанию: none.
onfail — то же, что и onsuccess, но перенаправление произойдёт в случае неуспешного выполнения операции. Допустимы только динамические вставки, задействованные в base. Стоит также отметить, что если перенаправление происходит в другую локацию (т.е. при любом значении атрибута, отличным от none), код ошибки не передаётся. По умолчанию: none.
Применение метода анализа иерархий
Помимо стандартных значений атрибутов, допустимо задать действие на определённые наборы и блоки. Для этого необходимо перед названием набора или блока подставить специальный символ # для набора и : для блока. Например: #someset, :someblock.
В языке BML предусмотрен также атрибут without для исключения из-под действия текущих прав доступа определённого набора или блока.
Стоит обратить внимание, что группы, установленные в правах доступа, суммируются. То есть если, к примеру, для одного блока прав доступа установлена группа "user"(авторизованный пользователь), а для другого блока присутствуют права с явно установленной группой "moder"(модератор) и текущий пользователь входит в обе группы, то при пересечении этих двух прав доступа применится группа с более высоким приоритетом. При этом если стоят индивидуальные права на конкретного пользователя, то они всегда имеют наивысший приоритет. Наглядно механизм действия прав доступа показан в разделе 4.5.5.
Как предписывают стандарты [27, 56], взаимодействие пользователя с сервером происходит путём отправки на него данных с помощью HTML-форм. Так как BlockSet является высокоуровневой технологической прослойкой между Web-сервером, имена полей ввода в формах регламентируются определёнными правилами. Для того, чтобы понять, как получать пользовательские данные, необходимо определить, для каких целей осуществляется их получение.
Если при выборке данных не производится никаких изменений, а входные данные являются лишь критериями выборки, целесообразно использовать HTTP-метод GET. Данный метод характеризуется свойством идемпотентности. Это означает, что при повторном обращении к ресурсу указанным методом с теми же самыми входными данными, пользователь получит тот же самый результат (разумеется, если данные не будут изменены побочным воздействием). Для задания путём пользовательского ввода критериев выборки экземпляров того или иного набора существует два способа [79]. В первом способе необходимо задать имена зависимых от пользовательского ввода блоков выбираемого набора в динамических вставках базового адреса локации. Данный способ был описан в разделе 2.3. В таком случае, выбираемое значение будет частью URL. Второй способ подразумевает приём данных через строку запроса (англ. Query String). В этом случае необходимо в атрибуте condition нужного блока указать значение input, которое будет ссылаться на параметр запроса, переданного на Web-сервер HTTP-методом GET. В качестве имени параметра запроса используется имя набора и имя блока, разделённые точкой. Однако имя набора можно опустить и указывать только имя блока, если в таком наборе атрибут nameskip имеет значение, отличное от нуля. Однако в таком случае стоит учитывать, что включение указанного атрибута у нескольких наборов, содержащих одинаковые имена блоков, вызывает неоднозначность и, как следствие, ошибку интерпретации.
Пример строки URL, заданной таким способом: /search?articles.subject=Biology&articles.year=1995. Здесь статично задана локация search в которой считываются два параметра для блоков subject и year, устанавливающих критерии выборки из набора articles. В том случае, когда задействованы оба описанных способа получения данных для одного и того же блока, возникает противоречие, разрешаемое в пользу базового адреса, в то время как соответствующее значение строки запроса будет проигнорировано.
Для передачи параметров, модифицирующих данные на сервере, загрузки файлов, передачи скрытых данных, спецификация протокола HTTP предписывает использование метода POST. В методики BlockSet методом POST отправляются все данные, связанные с созданием новых и модификацией существующих экземпляров набора, а также с аутентификацией пользователя (частный случай: модификация авторизационного набора). Формат передачи данных аналогичен идемпотентному запросу: при создании экземпляра набора или модификации существующего передаются пары «ключ-значение», где ключ состоит из названия набора и блока, между которыми стоит точка (название набора может опускаться, если включена опция nameskip). Основное отличие в том, что все данные передаются в теле запроса. Второе отличие в необходимости задействовать служебный атрибут act, в котором необходимо задать тип действия: create — создание экземпляра набора или update — изменение существующего экземпляра набора. В случае последнего, вместе с изменяемыми данными требуется передача соответствующего ключа-идентификатора, роль которого выполняет атрибут id. Значение идентификатора не может быть перезаписано ни при каких условиях.
Для обеспечения обмена данными блокам добавлены следующие атрибуты: – onread – для передачи идемпотентных данных – oncreate, onupdate, ondelete, onauth – для передачи данных модифицирующих запросов создания, обновления и удаления контента, авторизации и выхода соответственно
Эти атрибуты могут принимать следующие значения, которые определяют, откуда блок будет принимать данные: – @input – данные, которые должны прийти от клиента – @default – данные берутся из атрибута “default” При этом их допустимо комбинировать со строками. Для переключения режима приёма данных для набора вводится свойство "act". Оно определяет, каким образом должен обрабатываться набор. Значением свойства может быть явно заданный метод обработки, или же значение брать значение “@input”, которое говорит о том, что режим доступа будет задан из запроса. Это позволяет создавать гибкие локации, которые могут выполнять обработку схожих данных разными способами. Например, можно реализовать редактирование или создание новых статей на ресурсе при помощи одной локации.
Прием данных в проекте BlockSet реализован следующим образом: данные модифицирующих запросов могут быть приняты только методом POST, в то время как идемпотентные данные клиент может передавать как методом POST, так и методом GET. В случае, если одинаковые данные передаются обоими методами, конфликт разрешается с помощью системы приоритетов (рис. 2.3): если модифицирующие данные были обнаружены в запросе, то искать идемпотентные данные мы будем уже среди GET-данных. Если модифицирующих данных не было, то сначала будет произведен поиск информации идемпотентного запроса среди POST данных и, только в случае, если там ничего не было обнаружено, будет произведен поиск среди GET-данных.
Проведение нагрузочного тестирования
Итак, язык PHP выберем в качестве основного в отрасли Web-разработки, и именно относительно него будем проводить исследования разработанного в предыдущей главе языка BML. Основная цель исследования – доказать эффективность разработанного языка, по сравнению с незыблемыми стандартами на примере языка PHP. Основная проблема заключается в том, что BML является декларативным языком и не имеет потока управления, в то время, как классические методы основаны либо на анализе графа потока управления (метрика МакКейба, метрика Майерса), либо в целом подразумевают наличие потока управления (метрика Джилба). Именно по этой причине данные метрики не подходят для анализа декларативного языка.
Помимо озвученных, классическим методом оценки программного кода являются метрики Холстеда. Согласно автору метода, программа представляет собой алгоритм, рассматриваемый как набор токенов, подразделяющихся на операторы и операнды. Иными словами, программа состоит из операторов и связанных с ними операндов. Метрики Холстеда основаны на подсчёте этих токенов. Предполагается задействовать этот метод при оценке BML и PHP, но если с PHP всё в целом понятно, то с BML возникает ряд вопросов. Главный из них – что считать «оператором», а что «операндом» в данном языке? Авторы работы [31] пытаются адаптировать классические метрики с декларативным языком XSLT. Поскольку и XSLT, и BML основаны на синтаксисе XML, методику из представленной работы можно применить и для BML. Авторы предлагают считать операндами переменные, параметры и константы, при этом элементы (теги) языка и названия атрибутов этих элементов считаются операторами. ДДобавим также, что значения всех атрибутов мы считаем операндами, за исключением некоторых сложных значений, которые могут содержать конструкции, подразумевающие дополнительное деление на операторы и операнды. Подобным же образом предлагают поступить и авторы работы [54].
Входными данными метода Холстеда являются следующие характеристики: 1 – количество уникальных операторов программы, включая имена функций, знаки операций, а также для BML: имена элементов, атрибутов и части значений некоторых атрибутов. 2 – количество уникальных операндов программы. Для BML это либо значение атрибута полностью, либо отдельные части значения. 1 – общее количество встречающихся в исходном коде операторов. 2 – общее количество встречающихся в исходном коде операндов. Все остальные характеристики основаны на указанных выше значениях. Длина (N) программы P расчитывается по формуле: =1 +2 (3.1) Словарь (n) программы P: = 1 +2 (3.2) Теоретическая длина программы по Холстеду вычисляется с помощью следующей формулы:
Однако, позже Х. Дженсеном и К. Вайраваном была разработана формула [60], показавшая более точные оценочные характеристики на примере некоторых императивных языков. Формула теоретической длины программы по Дженсену имеет вид: = (21)! + (22)! (3.4) В работах [10, 39] вводится коэффициент правильности исходного кода вычисленному эталону. Рассчитывается он следующим образом: (-) =1- = (3.5) Согласно этому коэффициенту, отношение теоретической длины программы к реальной должно стремиться к единице. Согласно работе [16], формулы 3.3 и 3.4 наиболее точно отражают характеристику небольшой программы или отдельной процедуры большого проекта. Но поскольку разбиение на условные процедуры в декларативном языке затруднительно, для упрощения мы будем считать отклонение коэффициента правильности до 0,1 в пределах допустимого интервала.
Объём программы определяется Холстедом в своей книге [22] как: 1. Подходящая метрика размера любой реализации любого алгоритма; 2. Количество возможных вариантов реализации программы. Число V вычисляется по следующей формуле: = 2 (3.6) Уровень качества программы P показывает, насколько эффективно выполнен программный код. Вычисляется уровень следующим образом: P = 22 (3.7) 1 2
Критерий P отражает уровень эффективности реализации того или иного функционала. Общеизвестно, что один и тот же функционал можно реализовать различными способами. Таким образом, данная характеристика применима для сравнения между двумя одинаковыми алгоритмами, выполненными на одном и том же языке программирования с помощью разных подходов. Значение критерия лежит на отрезке [0; 1]. Рецепты, представленные в работе, предназначены для сравнения между языками программирования и проверены идентичным составом экспертов. Мы будем считать, что данные рецепты выполнены являются эталонными для каждого языка программирования, выполнены на высоком уровне. По этой причине в наших расчётах примем P =1.
Кроме того, учёный в области визуальных языков Дж. Никерсон в своей работе [46] отмечает, что визуальные языки устроены таким образом, что большая часть функционала возложена на предопределённые функции. И принятие единичного уровня программы не противоречит понятиям метрик Холстеда.