Содержание к диссертации
Введение
ГЛАВА 1. Анализ существующих подходов построения веб приложений и постановка задачи исследования 12
1.1 Современные тенденции в области разработки баз данных 12
1.2 Современные подходы к созданию веб-приложений 22
1.3 Ситуационно-ориентированные базы данных 34
1.4 Выводы к первой главе 42
ГЛАВА 2. Организация интерфейса пользователя в веб приложениях на основе собд. концепция иерархических виджетов 45
2.1 Построение интерфейса пользователя в динамической модели СОБД 45
2.2 Концепция иерархических виджетов СОБД 51
2.3 Интерпретация виджет-элементов в СОБД 55
2.4 Пример использования виджет-элементов в сложно-структурированных веб приложениях на основе СОБД 62
2.5 Выводы ко второй главе 69
ГЛАВА 3. Ввод и контроль данных пользователя в веб приложениях на основе СОБД 70
3.1 Процедура контроля пользовательских данных в веб-приложениях на основе СОБД 72
3.2 Пример использования элемента контролёра в веб-приложении на основе СОБД 78
3.3 Алгоритмы контроля данных пользователя в веб-приложениях на основе СОБД 87
3.4 Выводы к третьей главе 101
ГЛАВА 4. Применение иерархических виджетов в веб приложении на основе СОБД 103
4.1 Сравнение HSM-моделей без использования и с использованием виджета в СОБД 105
4.2 Сравнение XSL-трансформации без использования и с использованием виджетов в веб-приложениях на основе СОБД 116
4.3 Количественная оценка востребованности виджетов при построении веб приложений на примере одного состояния динамической модели СОБД 124
4.4 Выводы к четвертой главе 126
Заключение 127
Список сокращений и условных обозначений 130
Список литературы 133
- Современные подходы к созданию веб-приложений
- Концепция иерархических виджетов СОБД
- Пример использования элемента контролёра в веб-приложении на основе СОБД
- Количественная оценка востребованности виджетов при построении веб приложений на примере одного состояния динамической модели СОБД
Современные подходы к созданию веб-приложений
История развития компьютерных баз данных (БД) насчитывает ни одно десятилетие. Исторически сложившееся противостояние между иерархическими и реляционными моделями данных в 80-х годах XX века привели к доминированию последних на рынке и, как следствие, в приложениях. Соответственно системы управления базами данных (СУБД), базирующиеся на реляционной модели данных, в настоящее время стали преобладающими на рынке баз данных [3]. На рисунке 1.1 показана статистика использования различных СУБД на серверах одной из крупнейших хостинг-платформ мира – американской компании Jelastic [37].
Как видно из рисунка СУБД MySQL и MariaDB, построенные на реляционной модели данных, работают по совокупности в 77% веб-приложений, работающих на данной хостинг-платформе. Этот показатель впечатляет, однако совсем недавно он составлял почти 90%. Динамика использования различных СУБД [33], представленная на рисунке 1.2, показывает, что за последние 2 года реляционные СУБД не дали особого прироста использования в отличие от систем управления, использующих другие модели данных.
Связано это не с тем, что были разработаны более совершенные модели данных, а с тем, что развитие веб-приложений привело к тому, что для каждого конкретного веб-приложения разработчику нужно определять, какую базу данных и СУБД использовать, чтобы лучше решить поставленные задачи.
MySQL и её сестра MariaDB – классические реляционные СУБД подходящие для большинства малых и средних веб-приложений и имеющих соответственно все достоинства и недостатки реляционной модели данных. MySQL входит в состав таких серверов, как WAMP, AppServ, LAMP и в портативные сборки серверов Денвер, XAMPP. Обычно MySQL используется в качестве сервера, к которому обращаются локальные или удалённые клиенты, однако в дистрибутив входит библиотека внутреннего сервера, позволяющая включать MySQL в автономные программы [47]. Гибкость СУБД MySQL обеспечивается поддержкой большого количества типов таблиц: пользователи могут выбрать как таблицы типа MyISAM, поддерживающие полнотекстовый поиск, так и таблицы InnoDB, поддерживающие транзакции на уровне отдельных записей. Более того, СУБД MySQL поставляется со специальным типом таблиц EXAMPLE, демонстрирующим принципы создания новых типов таблиц. Благодаря открытой архитектуре и GPL-лицензированию, в СУБД MySQL постоянно появляются новые типы таблиц.
MariaDB – ответвление СУБД MySQL, разрабатываемое сообществом [56]. Ведущий разработчик – Майкл Видениус [32], автор оригинальной версии MySQL и основатель компании Monty Program AB. В MariaDB произошел отказ от подсистемы хранения данных InnoDB и ее замена на XtraDB [54].
В основе остальных популярных СУБД лежат совершенно разные модели данных. Нет ни малейшего сомнения в том, что основой современной технологии баз данных является реляционная модель, именно благодаря наличию этой основы данная отрасль знаний становится наукой. Однако доминирование реляционных СУБД начинают прерывать такие СУБД, как PostgreeSQL, MongoDB, CouchDB и др. PostgreSQL – это СУБД в основе которой лежит объектно-реляционная модель данных [59], собравшая в себя технологии, реализующие объектно-ориентированный подход (объекты, классы и наследование реализованы в структуре баз данных и языке запросов), и которые выполняются в рамках табличного (реляционного) представления данных. Таким образом таблицы могут наследовать характеристики и наборы полей от других таблиц (родительских). При этом данные, добавленные в порождённую таблицу, автоматически участвуют (если это не указано отдельно) в запросах к родительской таблице. Первое появление систем объектных баз данных на рынке вызвало большую активность в этом направлении развития научной мысли. Ожидалось, что такие системы смогут вскоре полностью вытеснить реляционные системы. Однако, как показала практика и прошедшие годы, объектные системы подходят только для определенного, достаточно ограниченного круга задач, вследствие чего они так и не смогли занять сколько-нибудь значительную часть рынка баз данных. В результате чего стали появляться системы, в которых была произведена попытка объединения объектной и реляционной технологии в целях воплощения наилучших свойств обеих систем. Иными словами, объектно-реляционные системы - это подлинно реляционные системы, отличительной особенностью которых является то, что они позволяют пользователям определять их собственные типы [4]. Использование таких СУБД перспективно для сложных приложений в таких областях, как: - системы автоматизированного проектирования и автоматизированного управления производством (САПР/АСУП); - системы комплексного автоматизированного управления технологическими процессами; - системы автоматизированной разработки программного обеспечения; - геоинформационные системы; - системы хранения и выборки документов и т.д. Доля в 11% от общего количества использования различных СУБД по данным рисунка 1.1 иллюстрирует тот факт, что такие системы применяются в определенных случаях для решения специфических задач, где у традиционного реляционного подхода могут быть затруднения. Аналогичная ситуация с двумя оставшимися СУБД из рисунка 1.1 -MongoDB и CouchDB, созданными на основе документо-ориентированной модели данных.
Концепция иерархических виджетов СОБД
В практической основе данного подхода лежит программная платформа Node.js [42], превращающая JavaScript из узко специализированного языка в язык общего назначения, транслируя его в машинный код. Таким образом, на языке, применяемом на клиентской стороне приложения, стало возможно создавать и программировать действия серверной части веб-приложения (см. примеры [5]). Изменяется сама философия веб-приложения. Привычным потокам противопоставляются события. Все операции асинхронны (в том числе файловый ввод/вывод). При написании приложения часто используется автоматное программирование, когда приложение или его фрагменты (модули) могут использоваться как конечные автоматы или автоматы сложной структуры [6]. Явным образом выделяется главный цикл программы, состоящий из двух частей: выборки события и обработки события [66]. «Цель Node – предоставить простой путь к построению масштабируемых веб-приложений ... даже не эксперты в области программирования способны создавать быстрые системы (с Node)» [41]. Главной особенностью данного подхода и технологий называется возможность быстрого масштабирования приложения. Однако методы, которые предлагаются разработчиками, не универсальны. Приложение должно вписываться в событийную модель и без проблем разбиваться на асинхронные потоки. Что касается масштабируемости, то в исследовании [46] говорится том, что «потоки исполнения могут обладать сильными сторонами событийной модели, включая поддержку высокого параллелизма, низкие накладные расходы, а также простую модель параллелизма». Эти рассуждения получают свое продолжение в работе [23], где выдвигается тезис о том, что нельзя противопоставлять потоки событиям (детально этот вопрос рассматривается в статье [20]) и предлагаются пути объединения двух подходов в гибридный: программирование на основе событий и программирование на основе потоков [19].
На основе приведённых выводов можно заключить, что событийно-ориентированное программирование – это современный подход к созданию высоконагруженных высоко-масштабируемых систем. Это особое направление развития таких систем, как социальные сети, почтовые сервисы, поисковые системы и т.п. Использование нового подхода дает хорошие результаты производительности, новые возможности программирования, в частности реализацию обмена сообщений между пользователями с асинхронным уведомлением: - не нужно обновлять страницу, чтобы получить информацию от сервера о новом сообщении; - не нужно ставить таймер для формирования запроса к базе данных с определенной периодичностью, чтобы получить информацию о новом сообщении; - пользователь получает новое сообщение, генерируется соответствующее новое событие и автоматически происходит его обработка; получатель может видеть уведомление (выполнение подобного сценария на традиционных системах может привести к повышенной нагрузке на сервер в следствие постоянных запросов к базе данных).
Когда речь идет о группе событий – возникает ситуация. В рамках научной школы Уфимского государственного авиационного технического университета «Теория и практика разработки информационных систем» уже более 10 лет ведутся научные исследования в области нового класса баз данных – ситуационно-ориентированных БД.
CMS описанные выше (п. 1.2.1) нельзя назвать полностью успешными способами автоматизировать процесс разработки приложений. В рамках тенденции к абстрагированию при построении прикладных программ была разработана концепция Model-Driven Architecture (Разработка, управляемая моделями [24]). Концепция предлагает описывать бизнес-процессы приложения на более высоком абстрактном уровне и делает модели данных основными звеньями разработки, из которых генерируются коды программ и другие звенья («Model-Driven Development» [24]). Это соотносится с парадигмой «Model-View-Controller» («модель-представление-поведение» [28]), которая предлагает как можно более обособленно разделять модель данных, графическую составляющую и логику приложения. Таким образом, изменения, вносимые, например, в модель данных, должны оказывать минимальное воздействие на графическую составляющую и на логику приложения. Происходит разделение логики от представления.
На слиянии этих двух подходов был предложен ситуационно-ориентированный подход к проектированию веб-приложений [76, 79, 81]. C точки зрения разработчика приложения суть данного подхода заключается в абстрагировании от программирования функций и узлов к разработке динамической модели приложения, в соответствии с которой интерпретатор динамической модели будет осуществлять переходы между ситуациями. Модель можно упрощённо представить в виде конечного графа, где узлы – это состояния, а переходы – это возможные действия пользователя (набор событий), которые приводят к переходу из одного состояния в другое.
На рисунке 1.6 представлена мнемосхема процесса построения работы веб-приложения на основе ситуационно-ориентированного подхода с точки зрения разработчика. Разработчик, как было сказано выше, проектирует ситуационную модель бизнес-процесса. Определяются состояния и условия переходов между состояниями.
Пример использования элемента контролёра в веб-приложении на основе СОБД
Модуль выполнен в виде рекурсивной функции Pass2, список входных параметров $s которой представляет состояние обрабатываемой субмодели (исходной динамической модели HSM и соответствующей ей памяти текущего состояния CSM). Интерпретация начинается путем вызова функции Pass2 (блок 1) для корневого состояния динамической модели, которое всегда является текущим и продолжается для текущих состояний внутренних субмоделей путем рекурсивного погружения (блок 4).
Для обрабатываемого состояния $s выполняется первичная циклическая обработка всех дочерних элементов (блок 2) в зависимости от их типов (блок 3). Если дочерний элемент является субмоделью (sub) или ссылкой на нее (div), функция рекурсивно вызывается (блок 4) для обработки этой субмодели с ее текущего состояния (функция Submodel); это обеспечивает обход всей текущей иерархии модели. Веткой «Другие элементы» обозначена обработка других традиционных дочерних элементов состояния, таких как акция (act), dom-элемент (dom) и т. д. Если дочерний элемент является виджет-элементом (wdg), вызывается функция (блок 5) формирования локального результата виджета. Результат сохраняется в DOM-объекте. Таким образом, по завершении первичной обработки дочерних элементов состояния (блок 2) для всех виджет-элементов (как дочерних, так и их потомков более глубоких уровней, соответствующих текущим внутренним состояниям) будут сформированы DOM-объекты, содержащие локальные результаты виджетов. Вторичная обработка (блок 6). Для формирования глобальных результатов и вывода их в выходной поток выполняется повторная обработка дочерних виджет-элементов (блок 6, 7). Если обрабатываемый виджет-элемент является дочерним для другого виджет-элемента (непустой атрибут parent, блок 8), то содержимое DOM-объекта вставляется в содержимое родительского DOM-объекта (блок 9). Если виджет является корневым (пустой атрибут parent, блок 8), то сформированное содержимое DOM-объекта (глобальный результат) выводится в выходной поток (блок 10).
Алгоритм вставки в родительский DOM-объект (блок 9) предусматривает следующие действия: 1) по значению атрибута parent отыскивается родительский DOM-объект, соответствующий родительскому виджет-элементу; 2) по значению атрибута corner отыскивается в родительском DOM-объекте родительский элемент для вставки контента; 3) содержимое DOM-объекта обрабатываемого виджет-элемента вставляется в качестве дочернего в найденный родительский элемент после уже имеющихся детей ("append") или перед ними ("prepend") в соответствии со значением атрибута insert. Пример последовательности формирования контента иерархического виджета в процессе интерпретации динамической модели
Этапы формирования результирующего контента иерархического виджета Динамическая модель содержит состояние sta:A, непосредственно в котором размещены виджет-элементы wdg:A_1 и wdg:A_2. Виджет А_1 формирует код div-блока, содержащего элемент управления в виде кнопки (Кнопка А), а виджет А_2 – код div-блока, содержащего текст (Текст А). Потомками состояния А являются состояния sta:В и sta:С, расположенные в субмоделях где-то на более низких уровнях иерархии и содержащие виджет-элементы wdg:В_1 и wdg:С_1 соответственно. Эти виджеты формируют div-блоки, содержащие кнопку и текстовый параграф (Кнопка В и Текст С). Рассмотрим второй проход интерпретации, предполагая, что указанные состояния являются текущими.
В ходе первичной обработки вложенных элементов состояния sta:A интерпретатор сначала обработает виджет wdg:A_1 и создаст соответствующий DOM-объект, куда поместит div-элемент А_1 с элементом управления «Кнопка А». После этого аналогичным образом будет обработан виджет wdg:A_2 и создан DOM-объект с div-элементом А_2, содержащим параграф «Текст А». Далее, в ходе первичной обработки субмоделей состояния sta:A будет обработано состояние sta:В с вложенным виджетом wdg:В_1 и создан DOM-объект, содержащий div-элемент В_1 с элементом управления «Кнопка В». Аналогичным образом будет обработано состояние sta:С с вложенным виджетом wdg:С_1 и создан DOM-объект, содержащий div-элемент С_1 с параграфом «Текст С». Вторичная обработка сначала выполняется для самых низких уровней иерархии.
В ходе вторичной обработки вложенных элементов состояния sta:В интерпретатор обработает виджет wdg:В_1и в соответствии с атрибутом parent поместит div-элемент В_1 из DOM-объекта В_1 в родительский DOM-объект А_1. При этом в соответствии с атрибутом insert размещаемый div-элемент будет вставлен после уже имеющегося контента (Кнопка В будет следовать за Кнопкой А). Аналогичным образом в ходе вторичной обработки вложенных элементов состояния sta:С интерпретатор обработает виджет wdg:С_1 и в соответствии с атрибутом parent поместит div-элемент С_1 из DOM-объекта С_1 в родительский DOM-объект А_2. При этом в соответствии с атрибутом insert размещаемый div-элемент будет вставлен перед уже имеющимся контентом (Текст С будет предшествовать Тексту А).
Таким образом, к моменту вторичной обработки дочерних элементов состояния sta:А в DOM-объекты А_1 и А_2 будут вставлены результаты виджетов-потомков В_1 и С_1. В ходе вторичной обработки, не обнаружив атрибутов parent, интерпретатор выведет в выходной поток div-элемент А_1, а в след за ним div-элемент А_2.
В традиционном варианте работы интерпретатора динамической модели данные выводятся последовательно по мере прохождение интерпретатором узлов динамической модели. В предлагаемой концепции наличие хотя бы одного виджета в модели требует, чтобы все данные модели выводились в конце обхода, т.е. после прохода интерпретаторам всех узлов модели. При этом у разработчика есть возможность самостоятельно выбирать, какому подходу следовать и даже использовать виджеты при традиционном подходе. Однако в этом случае их содержимое будет выведено на страницу по мере встречи их интерпретатором.
Для иллюстрации использования виджетов рассмотрим интернет-приложение, предназначенное для отображения пользователю сведений о студентах, о предметах и о сдачах студентами предметов. Исходные данные примера базируются на работе [80] с целью продемонстрировать различия традиционного подхода и предлагаемого, основанного на использовании иерархических виджетов. В данном примере предполагается, что одни и те же исходные данные по желанию пользователя требуется предоставлять различными способами:
Количественная оценка востребованности виджетов при построении веб приложений на примере одного состояния динамической модели СОБД
Введем в составе динамической модели HSM новый элемент - контролёр входных данных СИ (inp - от input, вход), предназначенный для проверки входных данных пользователя на первом проходе интерпретации динамической модели. Контролёр закрепляется за определенным элементом входных данных и задает: - адрес контролируемого элемента данных; - адрес, по которому значение элемента данных сохраняется в определенном DOM-объекте; - условия, которым должно удовлетворять значение элемента данных, и адреса, по которым записываются коды ошибок в случае нарушения условий.
Таким образом, на каждый элемент пользовательских данных, содержащихся в заполненной пользователем форме, нужно предусмотреть отдельный элемент-контролер. В результате интерпретации контролёра как элемента динамической модели значение контролируемого элемента данных и сведения об обнаруженных ошибках будут сохранены в DOM-объекте. На основе этой информации можно организовать дальнейшую обработку правильно введенных пользовательских данных или повторный запрос данных у пользователя с указанием допущенных ошибок.
На рисунке 3.1 представлен фрагмент динамической модели HSM – контролёр входных данных. Здесь обработчик по имени А ссылается на одноименный элемент массива POST (в массиве POST сохраняются данные, содержащиеся в пришедшей на сервер форме при использовании платформы PHP) и привязан к указанному DOM-объекту. В качестве внутренних элементов контролёр может содержать элементы-приемники специальных типов: ele (элемент), att (атрибут) и err (ошибка). Первый элемент-приемник, приведенный на рисунке 3.1, имеет тип ele. Он записывает в DOM-объект значение А в виде нового XML-элемента, дочернего для узла, путь к которому задан в атрибуте path. Если бы этот приемник имел тип att, то значение А было бы записано в DOM-объект в качестве XML-атрибута. СЯ A doc = "post"
Второй и третий элементы-приемники имеют тип err - это фиксаторы ошибок, выполняющие проверку значения элемента данных и запись в DOM-объект информации об ошибках. Первый фиксатор проверяет данные, применяя к значению элемента данных регулярное выражение, заданное атрибутом reg (само регулярное выражение на рисунке 3.1 опущено). При обнаружении ошибки ее код err1 сохраняется в DOM-объекте по определенному адресу (соответствующие атрибуты опущены). Второй фиксатор проверяет данные на уникальность среди множества значений, заданных XPath-выражением в атрибуте unique (само XPath-выражение на рисунке 3.1 опущено). При обнаружении такой ошибки ее код err2 сохраняется в DOM-объекте. В контролёре может быть задано несколько фиксаторов ошибок.
Способ выявления ошибок в данных, введенных пользователем, задается в атрибутах фиксатора ошибки. Можно предусмотреть следующие возможности задания правил обнаружения ошибок в проверяемых данных: 1) диапазон допустимых значений, атрибут between - введенное пользователем значение проверяется на принадлежность заданному диапазону допустимых значений; 2) список допустимых значений, атрибут list – введенное пользователем значение проверяется на принадлежность заданному списку допустимых значений; 3) регулярное выражение, атрибут reg – к проверяемому значению применяется заданное регулярное выражение, которое возвращает логический результат, свидетельствующий о наличии или отсутствии ошибки; 4) уникальность, атрибут unique – введенное пользователем значение проверяется на отсутствие в списке значений, сформированных с помощью заданного XPath-выражения, примененного к указанному DOM-объекту; 5) пользовательская функция, атрибуты func, param – к проверяемому значению применяется указанная AFL-функция (возможно, с заданными параметрами), которая возвращает логический результат, свидетельствующий о наличии или отсутствии ошибки. Применимость первых трех способов ограничена простыми случаями, когда для выявления ошибки достаточно проанализировать само проверяемое значение без сопоставления его с другими значениями из базы данных. При этом третий способ по своим возможностям перекрывает первые два, но более сложен как в плане задания, так и в плане исполнения. Четвертый способ предназначен для проверки уникальности значения введенного пользователем идентификатора среди других значений, уже занесенных в базу.