ОРГАНИЗАЦИЯ ИНТЕРФЕЙСА ПОЛЬЗОВАТЕЛЯ В ВЕБ-ПРИЛОЖЕНИЯХ НА ОСНОВЕ СИТУАЦИОННО-ОРИЕНТИРОВАННЫХ БАЗ ДАННЫХ С ИСПОЛЬЗОВАНИЕМ ИЕРАРХИЧЕСКИХ ВИДЖЕТОВ тема диссертации и автореферата по ВАК РФ 05.13.11, кандидат наук Канашин Виталий Владленович

• Канашин Виталий Владленович
• кандидат наук
• 2015

Оглавление диссертации кандидат наук Канашин Виталий Владленович

ВВЕДЕНИЕ

ГЛАВА 1. АНАЛИЗ СУЩЕСТВУЮЩИХ ПОДХОДОВ ПОСТРОЕНИЯ ВЕБ-ПРИЛОЖЕНИЙ И ПОСТАНОВКА ЗАДАЧИ ИССЛЕДОВАНИЯ

1.1 Современные тенденции в области разработки баз данных

1.2 Современные подходы к созданию веб-приложений

1.3 Ситуационно-ориентированные базы данных

1.4 Выводы к первой главе

ГЛАВА 2. ОРГАНИЗАЦИЯ ИНТЕРФЕЙСА ПОЛЬЗОВАТЕЛЯ В ВЕБ-ПРИЛОЖЕНИЯХ НА ОСНОВЕ СОБД. КОНЦЕПЦИЯ ИЕРАРХИЧЕСКИХ ВИДЖЕТОВ

2.1 Построение интерфейса пользователя в динамической модели СОБД

2.2 Концепция иерархических виджетов СОБД

2.3 Интерпретация виджет-элементов в СОБД

2.4 Пример использования виджет-элементов в сложно-структурированных веб-приложениях на основе СОБД

2.5 Выводы ко второй главе

ГЛАВА 3. ВВОД И КОНТРОЛЬ ДАННЫХ ПОЛЬЗОВАТЕЛЯ В ВЕБ-ПРИЛОЖЕНИЯХ НА ОСНОВЕ СОБД

3.1 Процедура контроля пользовательских данных в веб-приложениях на основе СОБД

3.2 Пример использования элемента контролёра в веб-приложении на основе СОБД

3.3 Алгоритмы контроля данных пользователя в веб-приложениях на основе СОБД

3.4 Выводы к третьей главе

ГЛАВА 4. ПРИМЕНЕНИЕ ИЕРАРХИЧЕСКИХ ВИДЖЕТОВ В ВЕБ-ПРИЛОЖЕНИИ НА ОСНОВЕ СОБД

4.1 Сравнение HSM-моделей без использования и с использованием виджета в СОБД

4.2 Сравнение ХБЬ-трансформации без использования и с использованием виджетов в веб-приложениях на основе СОБД

4.3 Количественная оценка востребованности виджетов при построении веб-приложений на примере одного состояния динамической модели СОБД

4.4 Выводы к четвертой главе

ЗАКЛЮЧЕНИЕ

СПИСОК СОКРАЩЕНИЙ И УСЛОВНЫХ ОБОЗНАЧЕНИЙ

СПИСОК ЛИТЕРАТУРЫ

Приложение А. Сведения о практическом использовании результатов

Приложение Б. Свидетельство о регистрации программы для ЭВМ

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

Введение диссертации (часть автореферата) на тему «ОРГАНИЗАЦИЯ ИНТЕРФЕЙСА ПОЛЬЗОВАТЕЛЯ В ВЕБ-ПРИЛОЖЕНИЯХ НА ОСНОВЕ СИТУАЦИОННО-ОРИЕНТИРОВАННЫХ БАЗ ДАННЫХ С ИСПОЛЬЗОВАНИЕМ ИЕРАРХИЧЕСКИХ ВИДЖЕТОВ»

ВВЕДЕНИЕ

Актуальность темы исследования. Современные веб-приложения - это сложные многопользовательские системы распределенной обработки данных в информационно-коммуникационной сети Интернет, включающие серверную часть (веб-сервер) - сервер приложений и сервер баз данных, - а также клиентскую часть - множество веб-браузеров пользователей. В Уфимском Государственном Авиационном Техническом Университете (УГАТУ) развивается новый подход к построению веб-приложений на основе ситуационно-ориентированных баз данных (СОБД). В основе СОБД лежит динамическая модель предметной области, с состояниями которой ассоциированы хранимые данные в формате XML [71]. Состояния динамической модели СОБД используются для управления данными, которые отображаются пользователю и принимаются от него.

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

1) сформировать HTML-код, задающий структуру и содержание изображения на экране, который пересылается в браузер пользователя вместе с CCS-кодом, задающим параметры внешнего вида изображения, и JavaScript-кодом, задающим активность на стороне клиента;

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

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

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

Во многих областях прикладной информатики показал свою эффективность подход к снижению трудоемкости программирования, состоящий в использовании компактных декларативных спецификаций обработки данных, интерпретируемых на этапе компиляции или исполнения программы [71]. Основываясь на этом подходе, была высказана идея декларативного задания в динамической модели СОБД иерархии спецификаций интерфейса пользователя, названных иерархическими виджетами. Идея иерархических виджетов является новой, в научной и технической литературе для нее отсутствуют концепции, модели, методы, алгоритмическое, программное обеспечение [71]. Поэтому создание научно обоснованного подхода к построению пользовательских интерфейсов веб-приложений на основе иерархических виджетов представляется актуальной научно-технической задачей.

Степень разработанности темы. Веб-приложения появились и получили широкое распространение в процессе развития Интернета усилиями специалистов корпораций Netscape, Macromedia, Microsoft, IBM и др., и продолжают развиваться усилиями многочисленных разработчиков и исследователей под координацией консорциума W3C. XML (Extensible Markup Language -«расширяемый язык разметки») - «язык с простым формальным синтаксисом, удобный для создания и обработки документов программами и одновременно удобный для чтения и создания документов человеком, нацеленный на использование в Интернете» - создан усилиями D. Connolly, J. Bosak, M. Spilberg-McQueen, J. Clark и др. и широко используется в веб-приложениях как на стороне сервера, так и на стороне клиента [71].

В УГАТУ вопросы использования встроенных динамических моделей исследовались с 80-х гг. В. В. Мироновым и Н. И. Юсуповой. Различные аспекты построения иерархических ситуационных моделей и их применения в задачах управления техническими объектами, производственными системами, электронными документами рассматривались в диссертациях О.Н. Сметаниной, Ю.Б. Головкина, Р.А. Ярцева, Л.Е. Гончар, А.Н. Ситчихина, Р.Ф. Ахметшина, Я.А. Олейника, Т.А. Гарифуллина, В.Э. Яфаева.

Данная работа отталкивается от исследований по применению встроенных иерархических ситуационных моделей на базе XML в качестве основы для управления веб-приложениями, начатых в работах В. В. Миронова и К. Э. Маликовой [75-76]. Понятие СОБД, сочетающей иерархические ситуационные модели и XML-документы, впервые введено в работах В. В. Миронова, Н. И. Юсуповой и Г. Р. Шакировой [81]. Вопросы обработки XML-документов в СОБД на базе концепции динамических DOM-объектов исследовались в работах В. В. Миронова и А. С. Гусаренко [80], а вопросы отображения данных из СОБД пользователю в виде сводных таблиц - в работах В. В. Миронова и Е. С. Макаровой [82].

Объект исследования - процесс организации интерфейса пользователя в веб-приложениях на базе СОБД.

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

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

Задачи исследования:

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

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

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

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

Новизна разработанной модели виджет-элементов (в составе динамической модели СОБД) и алгоритма их интерпретации (в составе общего алгоритма обработки динамической модели СОБД) заключается в том, что данные виджет-элементы в динамической модели соответствуют фрагментам интерфейса веб-приложения и позволяют разработчику задавать с помощью атрибутов способ и параметры формирования результирующего HTML-кода, устанавливать связи типа «родитель-потомок» с другими виджет-элементами, таким образом объединяя виджет-элементы в иерархию. При этом контенты дочерних виджет-элементов формируют глобальный контент родительского виджет-элемента для вывода в выходной поток.

Новизна разработанной модели элементов контроля данных пользователя (в составе виджет-элемента) и алгоритмов их интерпретации (в составе общего алгоритма обработки динамической модели СОБД) заключается в том, что в элементах-виджетах предусматриваются: элементы-контролёры, задающие

условия спецификации пользовательских данных; элементы-приемники, необходимые для помещения введенных данных в буферный DOM-объект; и элементы-фиксаторы ошибок, предназначенные для выявления и записи ошибок в данных. При этом в ходе обработки динамической модели производится синтаксический разбор атрибутов элементов-контролёров, к элементу пользовательских данных применяется заданное декларативным способом условие проверки (уникальность, неравенство, регулярное вырожение и др.). Результат помещается в DOM-буфер вместе со сведениями об обнаруженных ошибках, а выявленные ошибки в спецификациях записываются в массив ошибок интерпретатора; учет ошибок при управлении текущим состоянием динамической модели осуществляется путем проверки содержимого DOM-буфера и массива ошибок.

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

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

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

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

Методология и методы исследования. В работе использовались методы теории графов, технологии объектно-ориентированного программирования, системного анализа, ситуационного управления, иерархических моделей, объектной модели документа DOM, инструментарии кэшированной XML и XSLT на платформе PHP.

Положения, выносимые на защиту:

1) Модель виджет-элементов в составе динамической модели СОБД и алгоритм их интерпретации в составе общего алгоритма обработки динамической модели СОБД, отличающиеся тем, что:

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

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

2) Модель элементов контроля данных пользователя в составе виджет-элемента и алгоритмы их интерпретации в составе общего алгоритма обработки динамической модели СОБД, отличающиеся тем, что:

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

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

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

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

Разработанное программное обеспечение внедрено в Государственном комитете Республики Башкортостан по предпринимательству и туримзу (см. рисунок А.1), в научно-производственной фирме «РД-технология» (см. рисунок А.2), в коммерческой фирме ООО «ИмперияПлюс», занимающейся профессиональной разработкой веб-приложений, и в учебном процессе ФГБОУ ВПО «УГАТУ» (см. рисунок А.3). Акты-внедрения от вышеуказанных организаций представлены в Приложении А.

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

Результаты получены в рамках плановых исследований в области СОБД, проводимых на кафедре автоматизированных систем управления УГАТУ при поддержке РФФИ (гранты №№ 10-07-00167 и 13-07-00011).

Список публикаций по теме исследования включает 8 работ общим объемом 6 печатных листов, среди них 4 статьи в рецензируемом научном журнале из перечня ВАК, 4 публикации без соавторов. Получено свидетельство о государственной регистрации программы для ЭВМ (см. рисунок Б.1).

ГЛАВА 1. АНАЛИЗ СУЩЕСТВУЮЩИХ ПОДХОДОВ ПОСТРОЕНИЯ ВЕБ-ПРИЛОЖЕНИЙ И ПОСТАНОВКА ЗАДАЧИ ИССЛЕДОВАНИЯ

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

1.1 Современные тенденции в области разработки баз данных 1.1.1 Развитие баз данных. Реляционные и объектно-реляционные СУБД

История развития компьютерных баз данных (БД) насчитывает ни одно десятилетие. Исторически сложившееся противостояние между иерархическими и реляционными моделями данных в 80-х годах XX века привели к доминированию последних на рынке и, как следствие, в приложениях. Соответственно системы управления базами данных (СУБД), базирующиеся на реляционной модели данных, в настоящее время стали преобладающими на рынке баз данных [3]. На рисунке 1.1 показана статистика использования различных СУБД на серверах одной из крупнейших хостинг-платформ мира - американской компании Jelastic [37].

Как видно из рисунка СУБД MySQL и MariaDB, построенные на реляционной модели данных, работают по совокупности в 77% веб-приложений, работающих на данной хостинг-платформе. Этот показатель впечатляет, однако совсем недавно он составлял почти 90%. Динамика использования различных СУБД [33], представленная на рисунке 1.2, показывает, что за последние 2 года реляционные СУБД не дали особого прироста использования в отличие от систем управления, использующих другие модели данных.

Рисунок 1.1 - Статистики использования различных СУБД хостинг-провайдером

Jelastic

Рисунок 1.2 - Динамика использования СУБД

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

MySQL и её сестра MariaDB - классические реляционные СУБД подходящие для большинства малых и средних веб-приложений и имеющих соответственно все достоинства и недостатки реляционной модели данных.

MySQL входит в состав таких серверов, как WAMP, AppServ, LAMP и в портативные сборки серверов Денвер, XAMPP. Обычно MySQL используется в качестве сервера, к которому обращаются локальные или удалённые клиенты, однако в дистрибутив входит библиотека внутреннего сервера, позволяющая включать MySQL в автономные программы. Гибкость СУБД MySQL обеспечивается поддержкой большого количества типов таблиц: пользователи могут выбрать как таблицы типа MylSAM, поддерживающие полнотекстовый поиск, так и таблицы InnoDB, поддерживающие транзакции на уровне отдельных записей. Более того, СУБД MySQL поставляется со специальным типом таблиц EXAMPLE, демонстрирующим принципы создания новых типов таблиц. Благодаря открытой архитектуре и GPL-лицензированию, в СУБД MySQL постоянно появляются новые типы таблиц [47].

MariaDB - ответвление СУБД MySQL, разрабатываемое сообществом [56]. Ведущий разработчик - Майкл Видениус [32], автор оригинальной версии MySQL и основатель компании Monty Program AB. В MariaDB произошел отказ от подсистемы хранения данных InnoDB и ее замена на XtraDB [54].

В основе остальных популярных СУБД лежат совершенно разные модели данных. Нет ни малейшего сомнения в том, что основой современной технологии баз данных является реляционная модель, именно благодаря наличию этой основы данная отрасль знаний становится наукой1. Однако доминирование реляционных СУБД начинают прерывать такие СУБД, как PostgreeSQL, MongoDB, CouchDB и др. PostgreSQL - это СУБД в основе которой лежит объектно-реляционная модель данных [59], собравшая в себя технологии, реализующие объектно-ориентированный подход (объекты, классы и наследование реализованы в структуре баз данных и языке запросов), и которые выполняются в рамках табличного (реляционного) представления данных. Таким образом таблицы могут наследовать характеристики и наборы полей от других

1 Дубровин А.С. Модели и методы комплексного обеспечения надежности информационных процессов в системах критического применения: дис. канд. тех. наук: 05.13.17 // Дубровин Анатолий Станиславович. -Воронеж, 2011. - С. 58.

таблиц (родительских). При этом данные, добавленные в порождённую таблицу, автоматически участвуют (если это не указано отдельно) в запросах к родительской таблице.

Первое появление систем объектных баз данных на рынке вызвало большую активность в этом направлении развития научной мысли. Ожидалось, что такие системы смогут вскоре полностью вытеснить реляционные системы. Однако, как показала практика и прошедшие годы, объектные системы подходят только для определенного, достаточно ограниченного круга задач, вследствие чего они так и не смогли занять сколько-нибудь значительную часть рынка баз данных. В результате чего стали появляться системы, в которых была произведена попытка объединения объектной и реляционной технологии в целях воплощения наилучших свойств обеих систем. Иными словами, объектно-реляционные системы - это подлинно реляционные системы, отличительной особенностью которых является то, что они позволяют пользователям определять их собственные типы [4]. Использование таких СУБД перспективно для сложных приложений в таких областях, как:

- системы автоматизированного проектирования и автоматизированного управления производством (САПР/АСУП);

- системы комплексного автоматизированного управления технологическими процессами;

- системы автоматизированной разработки программного обеспечения;

- геоинформационные системы;

- системы хранения и выборки документов и т.д.

Доля в 11% от общего количества использования различных СУБД по данным рисунка 1.1 иллюстрирует тот факт, что такие системы применяются в определенных случаях для решения специфических задач, где у традиционного реляционного подхода могут быть затруднения.

Аналогичная ситуация с двумя оставшимися СУБД из рисунка 1.1 -MongoDB и CouchDB, созданными на основе документо-ориентированной модели данных.

1.1.2 Развитие баз данных. NoSQL направление

MongoDB и CouchDB являются документо-ориентированными системами управления базами данных [58], не требующими описания схем данных и реализованные в рамках NoSQL подхода в проектировании баз данных. Таким образом, документо-ориентированная база данных (ДОБД) не хранит данные и связи в таблицах. Вместо этого каждая база данных - набор независимых документов. Каждый документ содержит свои собственные данные и независимую схему. Приложение может получить доступ к нескольким базам данных, например, хранящейся на мобильном телефоне пользователя и на сервере

[15].

В основе документо-ориентированных СУБД лежат документные хранилища (англ. document store), имеющие структуру дерева (иерархическая модель данных) [21]. Структура дерева начинается с корневого узла и может содержать несколько внутренних и листовых узлов. Листовые узлы содержат данные, которые при добавлении документа заносятся в индексы, что позволяет даже при достаточно сложной структуре находить место (путь) искомых данных. API для поиска позволяет находить по запросу документы и части документов. В отличие от хранилищ типа ключ-значение, выборка по запросу к документному хранилищу может содержать части большого количества документов без полной загрузки этих документов в оперативную память. С точки зрения разработчика ПО документо-ориентированные данные (данные без жесткой схемы) являются более простыми и значительно более гибкими в управлении, нежели реляционные данные. Документы создаются индивидуально и могут хранить любую необходимую информацию [2].

Сам термин NoSQL является обобщением нереляционных СУБД нового поколения. Он стал общим термином для различных баз данных и хранилищ, но он не обозначает какую-либо одну конкретную технологию или продукт [26].

Их появление связано с необходимостью создания параллельных распределённых систем для высоко-масштабируемых интернет-приложений,

таких как поисковые системы [26]. Сегодня масштабирование становится одной из важнейших характеристик информационных систем в целом, в том числе распределенных систем хранения данных и баз данных, и здесь начинаются проблемы. Главное достоинство реляционных СУБД состоит в технологиях обеспечения надежного хранения с минимальными издержками на резервирование, но оказывается, что те же самые технологии становятся препятствием к масштабированию - они неудобны для терабайтных объемов данных [70]. Как следствие, большие корпорации, работающие по своей специфики с большими объемами данных, такие как Google (поисковые сервисы), Amazon (товары) и т.п., стали разрабатывать собственные системы хранения нереляционного типа, где масштабирование достигается за счет использования тысяч идентичных серверов, по которым данные распространяются сегментировано [29]. Теоретическая обоснованность и возможность распределенного подхода закрепила теорема CAP (известная также как теорема Брюера), которая утверждает, что в любой реализации распределённых вычислений возможно обеспечить не более двух из трёх следующих свойств [64]:

- согласованность данных (англ. consistency) - во всех вычислительных узлах в один момент времени данные не противоречат друг другу;

- доступность (англ. availability) - любой запрос к распределённой системе завершается корректным откликом;

- устойчивость к разделению (англ. partition tolerance) - расщепление распределённой системы на несколько изолированных секций не приводит к некорректности отклика от каждой из секций.

Системы NoSQL весьма разнообразны по своим функциональным возможностям, от простейших - с распределенным кэшированием (Memcached, [57]), до сложных - с распределенными таблицами (Google BigTable и MapReduce [44]). Каждая из систем демонстрирует преимущества тех или иных технологических решений. Одним из главных особенностей всех технологий в рамках данного подхода является попытка уйти от строго определенной схемы данных, подобно тому, как сама информация во множестве распределенных узлов

является слабоструктурированной. Хотя направление NoSQL активно развивается [68], уже становится понятно, что применение данных технологий подходит не для каждой области применения. Гибкая структура документов важна для областей применения, в которых данные могут храниться в произвольном формате, сохраняя при этом соответствие единой базовой модели. Например, задача хранения данных визитных карточек. Как это часто бывает, у одного человека на визитной карточке есть информация, например, о факсе или электронный адрес. У другого такой информации может не быть. Таким образом, на каждой визитной карточке данные могут быть представлены в разном формате и в разном составе. Этот классический пример иллюстрирует разность реляционного и документо-ориентированного подходов. В первом случае необходимо жесткое документирование модели данных. Что в итоге приведет к множеству записей в таблице с пустыми полями. Кроме того, в реляционных СУБД требуется определение типов атрибутов и количества выделенных под этот тип байт памяти. В документо-ориентированных СУБД задача хранения визитных карточек решается проще, т.к. нет жесткой структуры данных, что обеспечивает высокую гибкость такой БД. Документ может содержать любой набор данных разного формата (INTEGER число, текст TEXT/VCHAR, логический BOOLEAN). Однако NoSQL БД плохо подходят на роль хранения обычных структурированных данных, кроме того, выполнение требований ACID с NoSQL приходится встраивать в пользовательский код, тем самым усложняя работу [35].

Список литературы диссертационного исследования кандидат наук Канашин Виталий Владленович, 2015 год

Список

Иванов

Петров

Сидоров

i

(xhtmQ-л

Иванов v

dv class = "FuncTitle" ...............■

select class = "FuncSelector" select class = "StudentSelector" div class = "StudentsList" '-Mi class = "Students"

-input class = "StudentSelector1 -span class = "StudentFio"

-dv class = "FuncTitle"

select class = "FuncSelector" select class = "StudentSelector" div class = "StudentDetail" L-o-Jl class = "StudentDetail" -span class = "StudentFio" -span class = "StudentRating"

б

[sta| Студенты

BSjmp> Функция targs = "Студенты Предметы" ^—EHJ ВыборФункции ... Bsubl Студенты

gsta СписокСтудентов Sjmp> ВыбранСтудент

^—ЕШ ВыбранСтудент ... gjmp> ВыбранСтудент ctrlPost = "StudentSelector"

^дот СписокСтудентов

Echo pass = "2" method = "xslt"

stylesheet = "СписокСтудентов"

4sta ВыбранСтудент

кодСт proPost = "кодСт"

Sj^^ СписокСтудентов

^—ESI ВыбранСписок ...

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

^^cA Echo pass = "2" method = "xslt"

stylesheet = "УспеваемостьСтудента" а

в

Рисунок 2.2 - Попытка построения интерфейса с множественным доступом к функциям: а - фрагменты изображения для двух состояний; б - требуемая структура НГМЬ-кода; в - динамической модель (безуспешная) для реализации

интерфейса

>

>

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

Для реализации интерфейса, множественного доступа (см. рисунок 2.2) к данным студента, следует, в зависимости от состояния динамической модели формировать HTML-код, аналогичный представленному на рисунке 2.26. Панель управления размещена в div-блоке FuncTitle, а основная информация - в div-блоках StudentSelector и StudentDetail. Раскрывающиеся списки реализуются с помощью HTML-элементов select [76].

При попытке построить динамическую модель, обеспечивающую генерацию необходимого ИТМЬ-кода согласно рисунку 2.2в контент, генерируемый внутри состояния sta:СписокСтудентов, автоматически будет размещаться внутри ^-контейнера 81еёеП:8Ы81:, а не внутри контейнера БипсТШе, как требуется [76]. Данное затруднение возникает потому, что только когда интерпретатор динамической модели обрабатывает состояния sta:СписокСтудентов или sta:ВыбранСтудент, определяется содержимое выпадающих списков 8ШёеП:8е1ес1:ог и 81иёеПОе1а11. Таким образом, происходит ситуация, предсказанная в п. 2.1.3, когда контент, отображаемый на верхних уровнях НТМЬ-структуры интерфейса пользователя, приобретает содержимое на более низких уровнях иерархии.

2.1.5 Варианты решения представленных затруднений

Затруднения подобного рода приводят к тому, что построение динамической модели теряет свою привлекательность с точки зрения наглядности соответствия бизнес-логики работы приложения. Разработчик вынужден менять структуру в соответствии со структурой пользовательского интерфейса, что может привести к усложнению модели простого приложения, имеющего при этом сложный интерфейс пользователя. Динамическая модель будет изменена ради формы представления данных, а не логики решаемой задачи [76]. Это противоречит принятой концепции МУС, которая подразумевает большую независимость дизайна (структуры приложения) от конкретных данных. В случае с имеющимися механизмами работы СОБД этого достичь удается не всегда.

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

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

Таким образом, возникает необходимость в дополнении существующих механизмов построения пользовательского интерфейса в СОБД более гибкими и удобными средствами разработки, которые позволили бы более гибко, формировать структуру НТМЬ-кода отображаемой страницы в ходе интерпретации динамической модели, размещать интерфейсные элементы, данные, CSS-и JavaScript-код более независимо от структуры динамической модели [76].

2.2 Концепция иерархических виджетов СОБД

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

2.2.1 Особенности виджетов

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

виджета выводятся специфицированные данные: разметка HTML, код JavaScript и CSS, а также интерфейсные элементы управления (кнопки, селекторы и др.) [76].

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

HTML-код результата обработки интерпретатором дочерних виджетов предлагается встраивать в результирующую HTML-структуру родительского виджета. Из этого следует, что каждый виджет включает в себя локальный результат виджета, полученный в следствии непосредственной обработки интерпретатором данного виджет-элемента, и глобальный результат виджета, который генерируется путем обработки всех дочерних виджетов и конкатенации их локальных результатов. Корневому виджету (самому верхнему в иерархии, не ссылающемуся на родителя) соответствует результирующий HTML-код, включающий все результаты виджетов-потомков, полученные после обхода интерпретатором всех текущих состояний и подсостояний. С этой точки зрения иерархию виджетов можно считать динамической: HTML-код виджета зависит от его потомков, а место вывода на экран - от располложения родителя. Результат иерархии виджетов зависит от текущих подсостояний корневого виджета (в зависимости от текущих состояний динамической модели корневой виджет использует различные виджеты-потомки для формирования результата) [76].

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

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

2.2.2 Задание виджетов в динамической модели СОБД

Для дальнейшего развития идеи динамических виджетов определим синтаксис и семантику виджет-элементов. На рисунке 2.3 представлена синтаксическая диаграмма виджет-элемента, предложенная автором в работе [76].

Каждый виджет-элемент должен иметь свое название (Имявиджет-элемента), которое одновременно является его идентификатором. Следовательно, имя должно быть уникальными среди всех встречающихся имен виджетов или среди всех видимых имен виджетов из текущего состояния, в данный момент времени. Последнее условие также очень важно, т.к. дает возможность разработчику комбинировать с расположением даже корневого виджета в зависимости от текущего состояния. Например, в состоянии А меню веб-приложения, формируемое иерархией виджетов с корневым виджетом МЕНЮ, может распологаться в верху, а в состоянии Б меню переносится, например, в правый блок. Для этого разработчику достаточно просто позаботиться о том, чтобы в состоянии Б находился виджет с таким же названием МЕНЮ, а

одноименный виджет из состояния А не был виден интерпретатору (не был обработан).

Виджет-элемент

Имя_виджет-элемента -о type = "Тип_виджет-элемента" -о parent = "Имя_родителя" -о insert = "Метод_вставки" о dom = "Имя_йОМ-элемента" о stylesheet = "Таблица _стилей" о params = "Параметры_стиля" о path = "Путь_к_документу" о doc = "Идентификатор_документа"

Рисунок 2.3 - Синтаксическая диаграмма виджет-элемента

Каждый виджет имеет свой набор атрибутов, позволяющий гибко специфицировать его связи с другими виджетами, документами, ранее извлеченными данными (DOM-объектами), XSLT-шаблонами трансформации и таблицами стилей. Кроме того, разработчик имеет возможность заранее определять формат локального результата виджета: HTML-код или результат XSLT-трансформации. С помощью предопределенных значений атрибута insert разработчик может задать спецификацию размещения результата дочернего виджета в составе глобального результата своего родителя (перед родительским контентом или после), с которым установлена связь через атрибут parent.

2.3 Интерпретация виджет-элементов в СОБД

Согласно работам [75-77, 80]: "Для обработки динамической иерархической модели (HSM), используется интерпретатор (HSMI), который «проходит» модель дважды. На первом проходе интерпретатор обрабатывает динамическую модель,

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

2.3.1 Затруднения и особенности общей процедуры интерпретации виджет-

элементов

Основное затруднение, которое необходимо преодолеть при реализации концепции, связано с тем, что как на первом, так и на втором проходах интерпретации выполняется рекурсивный обход модели «сверху-вниз», т.е. от родительских состояний к дочерним, в то время как формирование глобального результата виджета требует обхода «снизу-вверх», т.е. от дочерних виджетов к родительским [76]. Это означает, что HTML-результаты виджетов-потомков могут быть сгенерированы и подсоединены к глобальному HTML-коду родительского виджета уже после того, как будет сгенерирован локальный HTML-код родительского виджета, в случае, если виджеты потомки были объявлены в динамической модели ниже, чем родительский виджет. Такое ограничение естественно не дает предлагаемой концепции никаких преимущество относительно существующих механизмов построения интерфейса пользователя. Рассматривается два варианта решения данной проблемы: 1) модификация

традиционного алгоритма интерпретации динамической модели дополнительным восходящим проходом при интерпретации дочерних элементов каждого состояния; 2) сохранение каждого локального результата в буфере и дополнительная (вторичная) обработка виджет-элементов при интерпретации дочерних элементов для сборки глобального результата [76].

Первый вариант решения предусматривает добавление третьего восходящего прохода интепретации модели, на котором будет происходить вывод всего сгенерированного НТМЬ-контента в результирующий поток. Таким образом результаты дочерних виджетов при «всплытии» будут подцепляться к результатам своих родительских виджетов. Из недостатков, первого подхода следует отметить необходимость разработчику адаптировать к таким способам вывода «снизу-вверх» абсолютно всех элементов, которые могут быть задействованы в модели. Это противоречит логике работе веб-браузеров, которые обрабатывают принимаемые НТМЬ-страницы «сверху-вниз». Соответственно такое перестроение «с ног на голову» повлечет за собой изменение принципов построения динамической модели и самой структуры веб-приложения, что скажется на наглядности представления иерархии данных [76].

Во втором варианте решения предполагается на втором проходе интепретатора для каждого виджета создавать отдельный ЭОМ-буфера, который будет хранить его локальный ИТМЬ-результат. После завершения обхода интепретатором динамической модели имплементируется вторичная обработка созданных DOM-буферов: результат из DOM-буферов дочерних виджетов подсоединяются в родительские DOM-буферы в соответствии с указанными разработчиком спецификациями. В качестве недостатков данного подхода стоит выделить ситуацию, когда хотя бы один дочерний виджет-элемент объявлен в динамической модели раньше, чем его виджет-родитель. Данная ситуация приводит к тому, что дочерние виджеты не имеют родительского DOM-буфера для вывода в него своих DOM-буферов, до погружения интепретатора до определенного состояния. Решением данного затруднения может стать

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

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

Очевидно, что второй подход потребует меньшей модернизации общей процедуры интерпретации, не затронет основные принципы формирование контента, более прост в реализации, а также хорошо соотносится с концепцией динамических DOM-объектов, предложенной в работах [71, 80]. Поэтому автором предлагается взять его за основу для реализации предложенной концепции иерархических виджет-элеметов.

2.3.2 Алгоритм интерпретации виджет-элемента

На рисунке 2.4 показана структура модуля второго прохода интерпретации из работы [76]. Здесь отображен процесс обработки интерпретатором виджет-элементов и генерирования результирующей HTML-страницы, которая будет отправлена с ответом сервера в браузер клиента.

В модуле предствлена работа рекурсивной функции Pass2. Принимая в качестве списка входных параметров ($s) состояние обрабатываемой субмодели (исходной динамической модели HSM и соответствующей ей памяти текущего состояния CSM [76]). Работа данной функции описывается автором в работе [76].

Блоки, выделенные серой заливкой (1-4, 11) присутствуют в традиционном, алгоритме интерпретации. Белой заливкой выделены новые блоки, предлагаемые

к введению для расширения функциональности и внедрения функционала виджетов.

(~Pass2 ($s))

.2. For each

child element

.6. For each

child element

(^Return ^

П-4-

Pass2 (Submodel ($c))

П-5-

Content to DOM

—^Другие элементы

гт-9-

Null-

Content to Output

„10.

Not "Null"

Content

into Parent

Рисунок 2.4 - Алгоритм второго прохода интерпретации, модифицированный с

учетом иерархических виджетов2

Таким образом, данная функция производит обход динамической модели, в результате которого для каждой субмодели и подсостояния текущего состояния происходит циклическая обработка всех дочерних элементов. Для виджетов при первой обработке (блок 5) формируется локальный результат, который сохраняется в DОM-буфер. Содержащие текущие локальные результаты DOM-буферы, будут сформированы, для всех виджетов после завершения первичной обработки дочерних элементов текущего состояния (блок 2).

2 Используемый здесь и далее «иерархический» способ представления блок-схемы имеет отличия от традиционного: вход в очередной блок того же уровня вложенности происходит по соединительной линии сверху или справа; выход всегда снизу; вход в первый дочерний (внутренний) блок из данного блока - справа; если внутренний блок последний в цепочке (не имеет соединительной линии снизу), то по его завершении происходит возврат в родительский блок. Такая нотация в большей степени соответствует конструкциям современных процедурных языков высокого уровня [76]

Вторичная обработка (блок 6) дочерних виджет-элементов (блоки 6, 7) выполняется для генерации глобальных результатов и их вывода в выходной поток [76]. Следовательно, содержимое DOM-буфера дочернего виджета вставляется в содержимое DOM-буфера родительского виджета (блок 9) только в том случае, если обрабатываемый виджет имеет связь через значение атрибута parent с другим виджетом (блок 8).

Корневым мы назовем виджет, у которого не указан родитель (не заполнен атрибут parent, блок 8). Результат такого виджета (глобальный результат) выводится непосредственно в выходной поток (блок 10).

2.3.3 Пример последовательности формирования контента иерархического виджета в процессе интерпретации динамической модели

На рисунке 2.5 иллюстрируется последовательность формирования результирующего контента иерархического виджета из работы [76].

Согласно [76]: "Динамическая модель содержит корневое состояние sta:A, которое включает в себя два корневых виджета (wdg:A_1, wdg:A_2) и два подсостояния (sta:B и sta:C), расположенных где-то на более низких уровнях иерархии, которые,в свою очередь, содержат дочерние виджеты wdg:B_1, и wdg:C_1 соответственно. Виджет А_1 генерирует HTML-код div-блока, содержащего кнопку (Кнопка А), а виджет А_2 - код div-блока, содержащий текст (Текст А). Виджеты wdg:B_1 и wdg:C_1 формируют div-блоки, содержащие соответственно кнопку и текстовый блок (Кнопка В и Текст С)".

Рассмотрим пример обработки второго прохода интепретации, условившись, что состояния В и С являются попеременно текущими.

А

нЗЗЭ а_1

Н© А_2

-feta в

^Swdg

-feta с

^Swdg

В_1 parent = "А_1" insert = "append"

С_1 parent = "А_2" insert = "prepend"

-div А 1

Кнопка А

-div А_2..........

;---div С_1......

I Текст С

•div В 1

Кнопка В

J

Текст A

Рисунок 2.5 - Этапы формирования результирующего контента иерархического виджета [76]

Первичная обработка динамической модели происходит «сверху-вниз» и начинается с виджета wdg:A_1, в результате чего будет создан DOM-объект, содержащий HTML-код div A_1 и HTML-код кнопки А. Это локальный результат wdg:A_1. Далее схожим образом интерпретатор обработает wdg:A_2. В итоге локальный результат данного виджета (div А_2 и текстовый блок А) будет записан в DOM-буфер. После чего интерпретатор совершит «погружение» в подсостояния динамической модели. Обработка состояния sta:B приведет к формированию DOM-буфера вложенного в него виджета wdg:B_1 с HTML-кодом кнопки B. Однако пока этот HTML код находится в DOM-элементе локального результата виджета wdg:B_1. Схожим окажется результат обработки последнего состояния -sta:C, которое содержит виджет wdg:C_1. Будет создан DOM-объект, содержащий div С_1 с текстовым блоком C.

Вторичная обработка, напротив, выполняется по принципу «снизу-вверх». В результате произойдет сбор локальных результатов дочерних виджетов в

глобальный результат родительских виджетов. Так, при обработке виджета, wdg^_1 интерпретатор в соответствии со значением атрибута parent поместит HTML-код div В_1 из DOM-буфера В_1 в родительский DOM-буфер А_1 виджета. Так как спецификация insert установлена как append HTML-код дочернего виджета будет помещен сразу после HTML-кода родительского виджета (Кнопка В после Кнопки А). Аналогичным образом интепретатор обработает состояние sta:C В результате содержимое DOM-буфера виджета wdg^_1 согласно, спецификации, parent переместится из дочернего DOM-объекта С_1 в родительский DOM-объект А_2 перед уже имеющимся контентом (Текст С будет предшествовать Тексту А).

После завершения обработки дочерних виджетов интерпретатор произведет «всплытие» и вернется к обработке верхнего уровня корневого состояния sta^. В DOM-буферы виджетов А_1 и А_2 к этому моменту уже будут вставлены результаты дочерних виджетов В_1 и С_1. Так как виджеты А_1 и А_2 не имеют родителей (значение атрибута parent не задано), они считаются корневыми, следовательно, содержимое их DOM-буферов будет выведено в выходной поток.

2.3.4 Совместимость с традиционным подходом

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

2.4 Пример использования виджет-элементов в сложно-структурированных

веб-приложениях на основе СОБД

Для иллюстрации использования виджетов рассмотрим пример интернет-приложения из работы автора [76]. С помощью приложения можно получить список студентов, сдаваемых предметов и перекрестные данные о результатах сдачи студентами предметов. Для того, чтобы более наглядно сравнить существующий и предлагаемый подход к построению интерфейса веб-приложений на основе СОБД, исходные данные для примера были взяты из работы [80]. Данное приложение позволяет отображать данные с двух точек зрения: 1) с точки зрения студентов и успеваемости студентов по предметам; 2) с точки зрения предметов и результаты сдачи предметов студентами. С помощью специализированного меню навигации пользователь может переключать вышеперечисленный типы отображения информации. Стиль такого отображения частично обсуждался выше (см. рисунок 2.2а).

2.4.1 Параметры динамической модели

Рассмотрим на рисунке 2.6 динимическую модель данного приложения, представленную автором в работе [76]. Модель имеет набор состояний, размещенных на трех уровнях вложенности: 1) корневое состояние sta:Студенты-Предметы; 2) два состояния 2-го уровня, размещенные в субмодели sub:Студенты-Предметы ^а:Студенты и sta: Предметы); 3) четыре состояния 3-го уровня, размещенные в двух субмоделях: sub:Студенты и sub:Предметы ^а:СписокСтудентов, sta:ВыбранСтудент, sta:СписокПредметов,

sta:ВыбранПредмет) [76].

ffta Студенты-Предметы —wg Главный type = "html" path = "HTML/main.html" —Wg Панель parent = "Главный" type = "html" path = "HTML/panel.html" Hfflg Детали parent = "Главный" type = "html" path = "HTML/detail.html"

L-ЩЗ Студенты-Предметы

"МенюФункций==Предметы"

Студенты

ЧШр Предметы genPost =

-^Hm СписокСтудентов

МенюФункций parent = "Панель" type = "html" path = "HTML/func-stud.html"

^-ЩЗ Студенты

-^Qa СписокСтудентов

—ВыбранСтудент genPost = "МенюСтуд<>Список"

—(Jdg МенюСтуд parent = "Панель"

type = "xslt" dom = "СписокСтудентов" stylesheet = "МенюСтуд-Список"

—<Wdg СписокСтуд parent = "Детали"

type = "xslt" dom = "СписокСтудентов" stylesheet = "СписокСтудентов"

'-^Qa ВыбранСтудент

—НШр СписокСтудентов genPost = "МенюСтуд==Список"

—НШр ВыбранСтудент genPost = "МенюСтуд<>Список"

—CSI кодСт proPost = "кодСт" genPost = "МенюСтуд"

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

—МенюСтуд parent = "Панель"

type = "xslt" dom = "СписокСтудентов" stylesheet = "МенюСтуд-Выбран" СдачиСтудента parent = "Детали" type = "xslt" dom = "УспеваемостьСтудента" stylesheet = "УспеваемостьСтудента" paramsVar = "кодСт"

Предметы

-ВИР Студенты genPost = "МенюФункций==Студенты"

4P СписокПредметов

/wgg МенюФункций parent = "Панель"

type = "html" path = "HTML/func-pred.html"

^-ЩЗ Предметы

^ja СписокПредметов

—ВШр ВыбранПредмет genPost = "МенюПред<>Список"

—Wg МенюПред parent = "Панель"

type = "xslt" dom = "СписокПредметов" stylesheet = "МенюПред-Список" —(Wdg СписокПред parent = "Детали"

type = "xslt" dom = "СписокПредметов" stylesheet = "СписокПредметов"

'-ffla ВыбранПредмет

—ВШр СписокПредметов genPost = "МенюПред==Список" —ВШр ВыбранПредмет genPost = "МенюПред<>Список" —CSI кодПр proPost = "кодПр" genPost = "МенюПред" УспеваемостьПоПредмету

Hjflg МенюПред parent = "Панель"

type = "xslt" dom = "СписокПредметов" stylesheet = "МенюПред-Выбран" L-Wg СдачиПоПредмету parent = "Детали"

type = "xslt" dom = "УспеваемостьПоПредмету" stylesheet = "УспеваемостьПоПредмету" paramsVar = "кодПр"

Рисунок 2.6 - Динамическая модель интернет-приложения

Согласно основному принципу построения приложений с помощью СОБД сами данные хранятся в специализированных ХМЬ-файлах, которые размещаются в папке ассоциированных данных СОБД. Схожим образом файлы в1:иё.хт1, ргеёт.хт! и sdacha.xml являются файлами данных о студентах, предметах и сдачах соответственно. Извлекаемые данные обрабатываются и стилизуются посредством ХБЬТ-трансформации согласно правилам, описанным в специальных файлах БШё.хБ^ шреувШё.хБ^ ргеёт.хБ1, шреургеёт.хв1.

Как видно из рисунка 2.6, в корневом состоянии модели объявляются три виджета: 1) виджет wdg: Главный - является корневым для всего сайта, вбирает в себя весь контент веб-приложения; 2) виджет wdg:Меню - является виджетом-

потомком wdg-.Главный, предназначен для формирования контента меню приложения; 3) виджет wdg-.Детали является виджетом-потомком wdg-.Главный, предназначенный для формирования основного контента приложения. Соответственно эти три виджета являются самыми иерархически высокоуровневыми, следовательно, они будут видны всем нижележащим виджетам динамической модели. Контент каждого виджета может быть изначально заполнен HTML - структурой (например, требуемыми по дизайну дополнительными div-блоками, ссылками и т.п.), а полученный виджетом, вследствии обработки и XSLT-преобразования каких-либо XML-данных, результат встроен в начальную заданную HTML-структуру. Такие начальные HTML-структуры для данных виджетов подключаются посредством отдельных файлов widget.html, menu.html и details.html соответственно. Таким образом, в файле menu.html по умолчанию прописано наличие области выпадающего списка (select) с именем МенюКатегорий c двумя вариантами (options): Студенты и Предметы.

Состояние sta-.Студенты-Предметы является корневым состоянием модели. В нем декларируются ассоциированные данные: три документа XML, четыре стиля трансформации XSL, библиотека макросов, а также 3 виджета, после чего выполняется погружение в субмодель следующего уровня иерархии [76]. Разъясним основную структуру данного приложения:

1. Состояния sta.-Студенты и sta-.Предметы задаются в субмодели sub-.Студенты-Предметы. Соответственно для первого состояния информация представляется «с точки зрения» студентов, во втором - предметов. Перейти из одного состоения в другое позволяют специальные jmp-элементы. Они активизируются интепретатором при обработке входящего массива POST, полученного от клиента вместе с URL (нажатие на один из вариантов выпадающего меню МенюКатегорий приводит к отправке данных и перезагрузке страницы). Далее интепретатор в соответствии с динамической моделью заполняет виджет Меню соответствующими данными: списком студентов или

списком предметов. Затем в зависимости от текущего состояния с помощью элементов происходит погружение в субмодель sub:Студенты или sub:Предметъl.

2. Последующие субмодели третьего уровня (sta:СnисокСтудентов, sta:ВыбранСтудент для субмодели ¿•«¿/Студенты; $\&:СписокПредметов, sta:ВыбранПредмет для субмодели sub:Предметы) задают состояния нижнего уровня иерархии. Интерпретатор производит заполнение виджета wdg:Детали соответствующими данными. Аналогично предыдущему пункту для осуществления перехода между состояними пользователю необходимо активировать ]шр-элементы нажатием на соответствующие кнопки: «Успеваемость студента», «К студентам», «Успеваемость по предмету», «К предметам». На рисунке 2.7 из работы [76] размечены области отображения результатов виджетов.

Предметы *■ | В Теория систем ■» д А

Теория систем - успеваемость:

• Иванов -5

• Петров -4

К предметам

< V

Рисунок 2.7 - Области виджетов [76]

Пользователю доступна область меню вверху страницы (А - виджет Панель), где отображается два выпадающих списка: Меню категорий (Студенты/Предметы, виджет МенюФункций) и Меню Студентов/Предметов (Б -виджет Меню). В зависимости от их выбора происходит изменение главной контентной области страницы (В - виджет Детали), где отображается информация об успеваемости выбранного студента или успеваемости по

выбранному предмету из верхнего меню. При начальной загрузке страницы в главной контентной области отражаются радио-кнопки выбора студентов. Все эти области (А, Б, В) являются дочерними по отношению к виджету Виджет [76]. На рисунке 2.8 наглядно отражается тот факт, что виджеты являют собой перекрывающиеся области интефейса и могут иметь неограниченный уровень вложенности. Представлены 4 экранные формы, сгенерированные интернет-приложением в ходе выполнения работы.

Студенты " Иванов

О Иванов О Петров О Сидоров

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

J

Предметы- Теориясистем"

® Теория систем О Матлогика О Криптография

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

Студенты ' Петров

¡Иванов

Петров

Иванов - успевае

• Теория систел [Сидоров

• Матлогика-4

• Криптография - 5

J

Предметы)'» Теория систем » Теория систем - успеваемость:

• Иванов - 5

• Петров - 4

I

>1

а

б

в з

Рисунок 2.8 - Экранные формы: а - список студентов с возможностью выбора отдельного студента; б - список предметов с возможностью выбора отдельного предмета; в - список сдач выбранного студента; г - список сдач по

выбранному предмету [76]

Пользователь может перейти из формы А к форме В кликнув на кнопку, «Успеваемость студента», которая отображается в интерфейсе, когда приложение находится в состоянии я1а:Студенты. Если же необходимо вывести данные успеваемости конкретного студента, то переход осуществялется при выборе студента из списка в меню, которое формируется виджетом Меню и меняется в

зависимости от выбранной категории (МенюКатегорий): Студенты или Предметы. Аналогичная ситуация складывается при работе с прелметами (см. рисунок 2.8 Б и Г).

2.4.2 Процесс формирования результата

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

На рисунке 2.9 [76] представлена схема иерархии виджет-элементов. Интерпретатор начинает обработку модели с инициализации виджета Главный, который является корневым виджетом (не имеет родителей). Интерпретатором для этого виджета автоматически создается DOM-объект, в который изначально будет загружена НТМЬ-структура файла main.html (см. рисунок 2.6) с уже установленным HTML-кодом МенюКатегорий.

Виджеты wdg:Меню и wdg:Детали интепретируются следующими, так как, являются дочерними для wdg:Главный. Их данные добавляются в созданный DOM-объект для определения, куда именно добавлять данные из дочерних виджетов wdg:Меню и wdg:Детали, и других виджетов, если таковые встретятся далее в модели.

При погружении далее в субмодель второго уровня, интерпретатор попадает в состояние Студенты, где формируется перечень студентов, который затем выводится в виджет Меню (см. рисунок 2.7Б и рисунок 2.9, 3), который представлен соответствующей размеченной областью в DOM-объекте, созданном для родительского виджета Главный. Переход в параллельное состояние Предметы (см. рисунок 2.9, 4) осуществляется по выбору пункта Предметы из выпадающего списка МенюКатегорий. После чего из состояния Студенты происходит погружение в субмодель третьего уровня в состояние СписокСтудентов (см. рисунок 2.9, 6), где формируется содержимое виджета Детали. В данном случае - список студентов с возможностью выбора.

39 Главный

<33Э Панель

-1-или.

'—МенюФункций (Студенты) МенюФункций (Предметы)

МенюСтуд (Список) МенюСтуд (Выбран)

МенюПред (Список) МенюПред (Выбран)

СписокСтуд —<339 СдачиСтудента (кодСт)

СписокПред —<339 СдачиПоПредмету (кодПр)

Рисунок 2.9 - Схема иерархии виджет-элементов

Таким образом, когда приложение находится в исходном состоянии, последнее состояние, которое будет обработано интепретатором - sta: СписокСтудентов, где производится обработка DOM-буффера корневого виджета Главный. При выборе какого-либо студента из перечня студентов интерпретатор получает идентификатор данного студента в наборе параментром POST вместе с URL и проходит все стадии повторно. При этом различия проявляются только в субмодели третьего уровня, где кнопкой «Выбран студент» активизируется jmp-элемент перехода в альтернативное состояние sta-.ВыбранСтудент. В этом состоянии формируется информация об успеваемости выбранного студента по всем предметам их перечня. Эта информация, как было сказано выше, обрабатывается и заносится в DOM-объект корневого виджета Главный. По схожему принципу интерпретатором обрабатываются состояния из «ветки» Предметов и успеваемости.

2.5 Выводы ко второй главе

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

Каждый виджет-элемент представляет собой некий участок пользовательского интерфейса веб-приложения, который может задаваться в любом состоянии динамической модели, где происходит его ассоциация с данными. Кроме того, виджет-элемент может иметь начальный шаблон своей структуры в виде HTML, Javascript и CSS, который заполняется данными из специального DOM-объекта или в результате XSLT-трансформации данных. Каждый виджет-элмент может содержать дочерние виджеты. При этом любой виджет-элемент может не иметь виджета-родителя. Выходной результирующий код дочерних виджетов (локальный результат виджета) аккумулируется в

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

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

ГЛАВА 3. ВВОД И КОНТРОЛЬ ДАННЫХ ПОЛЬЗОВАТЕЛЯ В ВЕБ-ПРИЛОЖЕНИЯХ НА ОСНОВЕ СОБД

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

Материалы данной главы были опубликованы автором в работах [84,85].

Интерфейс практически любого веб-приложения основывается на HTML и CSS [22, 31]. Для организации интерактивного интерфейса пользователя приложение должно получать или отслеживать какие-то переменные, чтобы знать, какое действие совершил пользователь и чем приложение должно ответить на него. При ручном программировании приложения программист вручную определяет условия переходов, контент, который будет меняться при определенном событии и блок вывода результата. Однако условия для выполнения того или иного действия отслеживаются с помощью глобальных массивов POST или GET, а также с помощью событий javascript, если выполнение сценария возложено на браузер пользователя. Для получения данных от пользователя традиционно используются такие HTML-элементы как input. При ручном программировании каждый такой элемент необходимо обработать:

- предусмотреть проверку на корректность вносимых данных;

- предусмотреть запись в соответствующую переменную после получения массива POST или GET;

- предусмотреть вывод результатов в соответствии со значением полученной переменной (или нескольких переменных).

В русле СОБД подхода особую роль играет динамическая модель. Её заполнение и написание является основной задачей разработчика. Поэтому инструменты, которые она может предложить разработчику, непосредственно позволяют ускорить разработку и облегчить программисту рутину программирования тривиальных функций. Такими тривиальными функциями являются функции приема и обработки информации, вводимой пользователем. С помощью иерархических виджетов в браузере пользователя формируются экранные формы с элементами управления (полями ввода, кнопками, переключателями и т.п.), состояние которых, измененное пользователем, необходимо учитывать на стороне сервера. Для этого в серверном сценарии требуется предусмотреть программы контроля пользовательских данных на предмет отсутствия ошибок или злонамеренных инъекций, а также обработки данных для приведения их к требуемому формату и сохранения в базе. В случае обнаружения ошибочных данных необходимо указать на это пользователю и организовать их повторный ввод. Все эти задачи вполне решаются и традиционными средствами, но требуют достаточно объемного и рутинного программирования.

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

3.1 Процедура контроля пользовательских данных в веб-приложениях на

основе СОБД

Контроль введенных пользователем данных в процессе формирования интерфейса пользователя происходит в соответствии со следующим алгоритмом :

Шаг 1: С помощью DOM-элементов динамической модели в специальном DOM-объекте подготавливаются данные для первичного отображения пользователю.

Шаг 2: Осуществляется процедура XSL-трансформации содержимого DOM-объекта, а с помощью виджет-элементов динамической модели происходит формирование исходного кода фрагмента интерфейса, содержащего input-элементы для ввода данных пользователем (поля ввода текста и т. п.)

Шаг 3: Выполняется отправка кода фрагмента интерфейса в браузер пользователя и получение ответных данных. Обслуживается стандартными веб-протоколами обмена данными.

Шаг 4: Осуществляется проверка корректности полученных данных пользователя и выявление ошибок.

Шаг 5: При обнаружении в DOM-объекте ошибок выполняется подготовка возврата введенных пользователем некорректных данных для отображения с учетом ошибок и возврат к шагу 2. Если ошибок нет - переход к следующему шагу.

Шаг 6: Сохранение (если требуется) введенных пользователем данных, или другая их обработка

Стоит отметить, что шаги 1-3 успешно выполняются существующими средствами СОБД, в отличии от шагов 4-6, которые на данном этапе развития СОБД требуют «ручного» программирования соответствующих функций в АЪ. Наша задача - ввести новые и расширить имеющиеся средства построения ШМ так, чтобы от ручного программирования перейти к возможности спецификации на декларативном уровне.

3.1.1 Контролёр входных данных

Автором предлагается ввести в состав динамической модели HSM новый элемент - контролёр входных данных СИ (inp - от англ. input, вход), предназначенный для проверки входных данных пользователя на первом проходе интерпретации динамической модели [84]. Контролёр закрепляется за определенным элементом входных данных и задает:

- адрес контролируемого элемента данных;

- адрес, по которому значение элемента данных сохраняется в определенном DOM-объекте;

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

Из вышеуказанного следует, что к каждому элементу пользовательских данных, который был получен при заполненнении пользователем HTML-формы, должен быть привязан отдельный элемент-контролер. Интепретатор проходит элементы динамической модели и обработывает элементы-контролеры, сохраняя при этом в DOM-объекте результаты обработки: значение, введенное пользователем в контролируемый элемент, и сведения об обнаруженных ошибках, если они были найдены. На основе анализа заполненности DOM-объекта результатами проверки может быть организован переход к последующей обработке принятых от пользователя данных или же произведен возврат введенных с ошибками значений и запрос пользователю на повторный ввод данных.

На рисунке 3.1 представлен фрагмент динамической модели HSM -контролёр входных данных. Элемент-приемник А ссылается на одноименный элемент массива POST (в массиве POST сохраняются данные, содержащиеся в пришедшей на сервер форме при использовании платформы PHP) и привязан к указанному DOM-объекту [84]. В качестве внутренних элементов контролёр может содержать элементы-приемники специальных типов: ele (элемент), att

(атрибут) и err (ошибка). Первый элемент-приемник, приведенный на рисунке 3.1, имеет тип ele. Он записывает в DOM-объект значение А в виде нового XML-элемента, дочернего для узла, путь к которому задан в атрибуте path. Если бы этот приемник имел тип att, то значение А было бы записано в DOM-объект в качестве XML-атрибута [84].

fSSP А doc = "post" dom = "..."

'—ЕЭ name path = "..." '—ED® err1 reg = "..." —ED® err2 unique = "..."

Рисунок 3.1 - Контролёр входных данных

Для выполнения проверки значения элемента данных и вывода информации о выявленных ошибках в DOM-объект используются элементы-приемники типа err (второй и третий). В спецификации к этим элементам разработчик может устанавливать тип проверки. Например, если проверку необходимо провести по регулярному выражению, то оно задается атрибутом reg (см. рисунок 3.1). Если данные не прошли проверку, соответствующий код ошибки будет записан в DOM-объект по определенному адресу (соответствующие атрибуты опущены).

Если необходимо проверить полученное значение на уникальность используется атрибут unique и Xpath-вырожение для его предопределения (само XPath-выражение на рисунке 3.1 опущено). Если ошибка обнаружена, то соответствующий ей код err2 сохраняется в DOM-объекте. В контролёре может быть задано несколько фиксаторов ошибок. Таким образом будет обеспечиваться возможность декларативного управления процессом проверки входящих данных.

3.1.2 Обнаружение ошибок в данных, принятых от пользователя

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

1. диапазон допустимых значений, атрибут between - введенное пользователем значение проверяется на принадлежность заданному диапазону допустимых значений;

2. список допустимых значений, атрибут list - введенное пользователем значение проверяется на принадлежность заданному списку допустимых значений;

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

4. уникальность, атрибут unique - введенное пользователем значение проверяется на отсутствие в списке значений, сформированных с помощью заданного XPath-выражения, примененного к указанному DOM-объекту;

5. пользовательская функция, атрибуты func, param - к проверяемому значению применяется указанная AFL-функция (возможно, с заданными параметрами), которая возвращает логический результат, свидетельствующий о наличии или отсутствии ошибки.

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

3.1.3 Фиксация ошибок в DOM-объекте

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

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

Например, можно условиться, что сведения об обнаруженной ошибке заносятся в поддерево inpErrs корневого элемента DOM-объекта в виде элемента inpData, в котором XML-атрибуты name и errCode содержат соответственно имя ошибочного элемента данных и код ошибки, а текстовое содержимое -ошибочное значение (см. рисунок 3.2).

_____de

Рисунок 3.2 - Информация в DOM-объекте об обнаруженных ошибках (синтаксис

XML-схемы из работы [10])

(xml) dom::Output ^^Root

— Content

ы

inpErrs

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

3.1.4 Использование контролёра для организации смены состояний

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

На рисунке 3.3 приведены два варианта применения контролёра для изменения текущего состояния.

Контроль

Проверка А

"ЕТ

-ВШр Ошибки трЕгЮот = "ОфиГ -ПШр Продолжение

Ошибки Продолжение

5 Р Контроль

Проверка

Продолжение А

■—ПШр'

Пр Ошибки Ошибки Продолжение

Рисунок 3.3 - Использование контролёра входных данных для смены текущего

состояния: а - в состоянии; б - в переходе

а

б

В первом варианте элемент-контролёр тр:А (см. рисунок 3.3а) располагается непосредственно в элементе-состоянии sta:Проверка, а во втором -в элементе-переходе jmp:Продолжение.

Состояние sta:Проверка предназначено для проверки элементов данных пользователя (в данном случае - элемента А), состояние sta:Ошибки - для обработки обнаруженных ошибок (повторной отправки формы пользователю с указанием ошибок - содержимое не детализовано), а состояние sta:Продолжение - для обработки корректных данных (сохранение в базе документов - не детализовано) [84].

В первом варианте (см. рисунок 3.3а) для смены состояния требуется, чтобы элемент-переход проверял наличие записей об ошибках в DOM-объекте. Стандартным путем это можно было произвести, запрограммировав для перехода функцию-предикат, которая обращается к определенному DOM-объекту и проверяет наличие в нем поддерева записей об ошибках. Для уменьшения трудоемкости такого «ручного» программирования целесообразно передать эту функцию интерпретатору, предусмотрев для элемента-перехода атрибут трЕпООМ, задающий имя проверяемого DOM-объекта. Присутствие данного атрибута в переходе указывает интерпретатору на обязательность исполнения такого рода проверки в заданном СОМ-объекте. Во втором варианте (см. рисунок 3.3б) надо сделать так, чтобы элемент-контролёр сам по себе мог использоваться в качестве вложенного предиката элемента-перехода. Для этого условимся, что в качестве результата интерпретации элемент-контролёр возвращает значение «истина», если при обработке вложенных фиксаторов не было найдено ни одной ошибки. Данный подход предоставляет более удобные решения, когда смену состояния необходимо выполнить по результатам проверки одного элемента данных пользователя.

3.2 Пример использования элемента контролёра в веб-приложении на основе

СОБД

На рисунке 3.4 предъявлен эпизод динамической модели, а на рисунке 3.5 показаны экранные формы, которые видит пользователь, когда соответствующие состояния становятся текущими.

Студенты

СписокСтудентов ■—Hup НовыйСтудент genPost = "МенюСтуд==Новый" •—Hup ВыбранСтудент genPost = "МенюСтуд<>Список&Новый"

•—МенюСтуд parent = "Панель" type = "xslt" dom = "СписокСтудентов" stylesheet = "МенюСтуд-Список" —<WB9 СписокСтуд parent = "Детали" type = "xslt" dom = "СписокСтудентов" stylesheet = "СписокСтудентов"

НовыйСтудент

—Hup СписокСтудентов genPost = "МенюСтуд==Список" ■—Hup ВыбранСтудент genPost = "МенюСтуд<>Список&Новый" ■—Hup СписокСтудентов ctrlPost = "btn:Cancel" •—Студент

•—ОбновСтуд

•—Hup СписокСтудентов substate = "ОбновСтуд==ОК"

•—МенюСтуд parent = "Панель" type = "xslt" dom = "СписокСтудентов" stylesheet = "МенюСтуд-Список" —Wg БланкСтуд parent = "Детали" type = "xslt" dom = "Студент" stylesheet = "Студент"

ВыбранСтудент ■—Hup СписокСтудентов genPost = "МенюСтуд==Список" •—Hup ВыбранСтудент genPost = "МенюСтуд<>Список&Новый" •—СЭИ кодСт proPost = "кодСт" genPost = "МенюСтуд" ■—Студент

•—<Q0g МенюСтуд parent = "Панель" type = "xslt" dom = "СписокСтудентов" stylesheet = "МенюСтуд-Выбран" ВыбранСтудент ПоказСтудента

•—Wg ПоказСтудента parent = "Детали" type = "xslt" dom = "Студент"

stylesheet = "СведСтуд" paramsVar = "кодСт" —Hup РедСтудента ctrlPost = "btn:Update"

РедСтудента

■—Wg РедСтудента parent = "Детали" type = "xslt" dom = "Студент"

stylesheet = "РедСтуд" paramsVar = "кодСт" •—Hup ПоказСтудента ctrlPost = "btn:Cancel"

ОбновСтуд

—Hup ПоказСтудента substate = "ОбновСтуд==ОК"

Рисунок 3.4 - Модель состояний, предусматривающих вставку и обновление

данных пользователя

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

3.2.1 Состояния динамической модели веб-приложения

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

- состояние sta:СписокСтудентов отвечает за работу с данными имеющихся студентов (это состояние есть в предыдущей версии модели);

- состояние sta:НовыйСтудент гарантирует запись в базу данных о новом студенте (новое состояние, обеспечивающее новую функциональность);

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

Для увеличения рабочих характеристик последнее состояние дополнено субмоделью, в которой находятся такие подсостояния:

- состояние sta:ПоказСтудента гарантирует отображение пользователю конкретных данных по выбранному студенту - о сданных студентом дисциплинах и поставленных преподавателями баллах (состояние находится в ранней модели);

- состояние sta:РедСтудента гарантирует новую функцию редактирования пользователем данных выбранного студента (новое состояние).

Экранные формы состояний формируются с помощью виджет-элементов, предусмотренных в составе каждого состояния. В состоянии sta:СписокСтудентов пользователь получает данные о зарегистрированных студентах (см. рисунок 3.5а). Верхняя часть документа содержит два раскрывающихся списка-меню.

Левый список-меню одинаков на всех документах этого образца и предназначен для выбора типа отображения («Студенты» или «Предметы»). Он наполняется виджет-элементом, расположенным в вышестоящем состоянии динамической модели.

Студенты V

о 5001 Иванов О б002 Петров О 5003 Сидоров

Детали

Новый

Список V

Список

Новый

Иванов

Петров

Сидоров

к

Студенты V

Иванов

9001 Иванов - успеваемость:

• Теория систем - 5

• Матлогика - 4

• Криптография - 5

Редактировать

а

б

к

Студенты V

Новый

Фамилия:

Сохранить

Отменить

Новый студент - ввести данные: Код:

к

21

Студенты V

Иванов

Иванов - редактировать данные: Код:

Фамилия:

5001

Иванов

Сохранить Отменить

к

>

>

>

>

в г

Рисунок 3.5 - Формы пользовательского интерфейса для различных состояний динамической модели: а - список студентов (в состоянии sta:СписокСтудентов); б - детальные сведения о выбранном студенте (в состоянии sta:ПоказСтудента); в - форма нового студента (в состоянии sta:НовыйСтудент); г - форма редактирования (в состоянии sta:РедСтудента)

Правое меню применяется для выбора режима отображения сведений о студентах, это состояние соответствует опции «Список». Эта часть комплектуется виджет-элементом wdg:МенюСтуд путем XSL-трансформации содержимого DOM-объекта dom:СписокСтудентов (dom-элемент, порождающий этот DOM-объект, размещен в состоянии вышестоящей ступени динамической модели).

В структуре расположен список студентов (показаны лишь идентификаторы и ФИО студентов). В нижней части документа расположены кнопки управления, дублирующие работоспособность правой части. Реестр и кнопки комплектуются виджет-элементом wdg:СписокСтуд путем XSL-трансформации содержимого DOM-объекта dom:СписокСтудентов.

Переходы из этого состояния обеспечиваются элементами jmp. Элемент jmp:НовыйСтудент совершает переход в состояние sta:НовыйСтудент, когда в правой части выбирается опция «Новый». Подобным образом элемент jmp:ВыбранСтудент совершает переход в состояние sta:ВыбранСтудент, когда в правой части документа выбирается опция, соответствующая одному из студентов реестра.

В состоянии sta:НовыйСтудент для пользователя показывается форма, куда следует вводить данные о новом студенте (только код-идентификатор нового студента и его ФИО, см. рисунок 3.5в). Меню в верхней строке формируется как в предыдущем состоянии, а форма - с помощью виджет-элемента wdg:БланкСтуд -путем XSL-трансформации содержимого СОМ-объекта dom:Студент. Этот СОМ-объект порождается одноименным dom-элементом dom:Студент, расположенном в этом состоянии.

Элемент jmp:ВыбранСтудент совершает переход в конкретное состояние, когда выбирается в правой части один студент из списка. Первые два элемента jmp:СписокСтудентов совершает переход, когда пользователь выбирает в правом меню опцию «Список» и когда нажимается кнопка «Отменить» (btn:Cancel). Третий элемент jmp:СписокСтудентов совершает переход, когда субмодель sub:ОбновСтуд расположена в состоянии «ОК». Погружение в субмодель sub:ОбновСтуд совершает div-элемент div:ОбновСтуд. В состоянии sta:ВыбранСтудент пользователю отображаются конкретные данные о выбранном студенте: либо для просмотра (см. рисунок 3.56), либо для редактирования в зависимости от подсостояния (см. рисунок 3.5г). Меню в верхней строке комплектуется как в предыдущих состояниях. Идентификатор выбранного

студента хранится в переменной var:КодСт, а данные о выбранном студенте - в DOM-объекте dom:Студент, созданным одноименным dom-элементом. Элемент jmp:СписокСтудентов совершает переход, когда пользователь в правом части выбирает опцию «Список». Элемент jmp:ВыбранСтудент совершает обновление состояния, когда пользователь выбирает другого студента. Подсостояния этого состояния заданы в субмодели sub:ВыбранСтудент.

В подсостоянии sta:ПоказСтудента пользователю с помощью виджета wdg:ПоказСтудента показываются конкретные данные о выбранном студенте путем XSL-трансформации содержимого СОМ-объекта dom:Студент (см. рисунок 5б). Элемент jmp:РедСтудента совершает переход состояния, когда пользователь нажимает кнопку «Редактировать» (btn:Update).

В подсостоянии sta:РедСтудента пользователю с помощью виджета wdg:РедСтудента показывается документ редактирования конкретных данных (см. рисунок 5г). Элемент jmp:ПоказСтудента совершает переход, когда пользователь нажимает кнопку «Отменить» (btn:Cancel). Dive-элемент div:ОбновСтуд совершает погружение в субмодель sub:ОбновСтуд, по результатам которого второй элемент jmp:ПоказСтудента совершает переход в состояния, когда субмодель находится в состоянии «ОК».

3.2.2 Контроль вводимых данных

Пользователь вносит данные в двух состояниях: в состоянии sta:Новый-Студент - сведения о новом студенте; в состоянии sta:РедСтудента - когда изменяются данные уже имеющегося студента. В обоих вариантах необходима проверка вносимых данных, в связи с этим, она реализована с помощью единой субмодели sub:ОбновСтуд (см. рисунок 3.6).

В основе субмодели sub:ОбновСтуд находится модифицированная модель контроля данных всех пользователей и обработка ошибок с применением элемента-контролёра (см. рисунок 3.3).

•—

ОбновСтуд Исходное

fEp Тест mode = "regular" ctrlPost = "btn:Save"