CC BY
72
Сер. 10. 2009. Вып. 3
ВЕСТНИК САНКТ-ПЕТЕРБУРГСКОГО УНИВЕРСИТЕТА
УДК 004.434:004.42
А. Н. Иванов, Д. В. Кознов, М. Г. Тыжгеев
МОДЕЛИРОВАНИЕ ИНТЕРФЕЙСА ПОЛНОФУНКЦИОНАЛЬНЫХ WEB-ПРИЛОЖЕНИЙ, интенсивно работающих С ДАННЫМИ*)
Введение. В настоящее время активно развивается рынок Web-приложений. Все больше различных услуг предоставляется через Интернет, классические информационные системы в различных компаниях также становятся Web-приложения ми, предоставляя для своих сотрудников и партнеров доступ к ресурсам компании не только из локальной сети, но и из произвольной точки Интернета.
Все это привело к созданию концепции полнофункциональных Web-приложений (Rich Internet Applications, RIA), которые по возможностям пользовательского интерфейса не уступают настольным (desktop) приложениям, имеют данные и бизнес-логику на стороне клиента, умеют своевременно обновлять экран, перерисовывая его лишь частично (в том месте, где произошли изменения), функционировать как с подключенным Интернетом, так и без него [1, 2]. Сейчас активно развиваются технологии для создания и функционирования RIA-приложений - AJAX, MacroMedia Flash/Flex, Microsoft SilverLight и др. Однако существенно отстают высокоуровневые средства разработки и моделирования, как отмечалось в работах [3, 4].
Сегодня стандартом де-факто в области Web-моделирования является подход WebML [5], включающий в себя ряд моделей, шаблоны проектирования и пакет WebRatio [6], поддерживающий автоматическую кодогенерацию. (Обзор и анализ других подходов к моделированию Web-приложений можно найти, например, в работе [3].) В последнее время язык WebML расширен средствами моделирования RIA-приложений [4, 7]. Однако в нем отсутствуют средства задания полнофункциональных интерфейсов - даже для небольших HTML-ориентированных приложений гипертекстовые модели, на которых в WebML задается пользовательский интерфейс, получаются очень громоздкими, их трудно создавать и еще труднее анализировать, изучать, обсуждать.
Иванов Александр Николаевич — научный сотрудник НИИ ИТ математико-механического факультета Санкт-Петербургского государственного университета. Количество опубликованных работ: 15. Научные направления: разработка Web-приложений, баз данных, визуальное моделирование программного обеспечения. E-mail: [email protected].
Кознов Дмитрий Владимирович — доцент кафедры системного программирования математикомеханического факультета Санкт-Петербургского государственного университета. Количество опубликованных работ: 35. Научные направления: визуальное моделирование программного обеспечения, разработка Web-приложений, электронное обучение. E-mail: [email protected].
Тыжгеев Михаил Григорьевич — студент кафедры системного программирования математикомеханического факультета Санкт-Петербургского государственного университета. Количество опубликованных работ: 1. Научные направления: визуальное моделирование программного обеспечения, разработка Web-приложений. E-mail: [email protected].
+ ) Работа выполнена при частичной финансовой поддержке Российского фонда фундаментальных исследований (грант № 05-0951/07).
© А. Н. Иванов, Д. В. Кознов, М. Г. Тыжгеев, 2009
Для удобства задания пользовательского интерфейса WebML интегрируется с методом RUX [8]. Однако RUX делает акцент на объединении аспекта баз данных и мультимедиа [9], не предлагая высокоуровневых абстракций для задания полнофункциональных интерфейсов. Вместе с тем RUX предоставляет средства для создания детальной модели пользовательского интерфейса в стиле редакторов экранных форм. Подобные редакторы имеются сейчас практически в любой среде разработки программного обеспечения, например в среде Microsoft Visual Studio. Тем не менее трудоемкость разработки пользовательского интерфейса для крупных систем (а именно в эту сторону двигаются RIA-приложения) требует введения дополнительных модельных абстракций, позволяющих задавать емкие, лаконичные, хорошо читаемые модели пользовательского интерфейса с последующей эффективной кодогенерацией.
Разработка модельно-ориентированных средств создания пользовательских интерфейсов программных приложений ведется давно (их обзор можно найти, например, в [10]). Однако главными проблемами здесь оказываются сложность и громоздкость моделей для реальных систем, а также негибкость средств автоматической кодогенера-ции. В результате на практике использование этих подходов не дает выигрыша в производительности, что привело к упадку исследований в данной области.
При разработке технологии REAL-IT [10-13] мы во многом решали именно такую проблему. Для этого был сужен класс целевых приложений, а именно он был ограничен массовыми информационными системами, имеющими базу данных и интерфейс для ее заполнения/просмотра/редактирования. Интерфейс таких приложений был типизирован, а пользователю была предложена, помимо классических модельных средств (несколько видов диаграмм языка UML [14] для задания базовой архитектуры приложения), система диалоговых мастеров, позволяющих по базовым моделям создавать модель пользовательского интерфейса с последующей автоматической кодогенерацией. То есть за счет сужения класса задач удалось создать простые абстракции и эффективный способ их использования, дающий выигрыш в реальной разработке [10].
В настоящей работе рассматривается частный случай RIA-приложений, совпадающий по функциональности с системами, на которые ориентирована технология REAL-IT. При этом полнофункциональность Web-приложений понимается как наличие в их интерфейсах разнообразных элементов управления, максимально приближающих Web-интерфейс к интерфейсу настольных систем. Для возможностей моделирования таких приложений с помощью подхода WebML мы расширяем последний следующим образом:
• дополняем модель данных WebML п-арными отношения с атрибутами;
• вводим в гипертекстовую модель WebML новый тип контент-модуля для задания фильтров с зависимыми полями;
• вводим в WebML специальную модель ограничений, описанную в [15], чтобы задать дополнительные зависимости на данные для использования при автоматической генерации экранных форм;
• предлагаем специальный шаблон проектирования для задания формы-отношения «многие-ко-многим» [10].
Предлагаемые расширения формально специфицированы в XML-формате, а именно в формате DTD, который применяется авторами WebML для формального описания языка.
1. Контекст.
1.1. Подход WebML/WebRatio. Данный подход развивается в Политехническом институте города Милана, Италия, с 2000 г. О нем опубликовано несколько десятков работ, подход реализован в виде программного средства WebRatio, поддерживающего автоматическую генерацию кода по диаграммам для платформы JEE/Tomcat и СУБД Oracle/MS SQL Server, а последняя версия продукта интегрирована со средой разработки Eclipse. Язык моделирования WebML состоит из следующих частей.
Модель данных (data model) - средство моделирования структуры базы данных, является вариантом модели сущность-связь. Можно задавать данные, хранимые как на сервере, так и на клиенте.
Модель запросов (derivation model) - средство для расширения модели данных вычислимыми конструкциями, такими как конструкция языка SQL под названием view, а также вычислимыми атрибутами и связями. Эта модель является текстовым языком запросов к модели данных, ее конструкции используются в двух следующих типах моделей для связи интерфейсных модулей и операций с моделью данных.
Гипертекстовая модель (hypertext model) служит для задания схемы интерфейса Web-приложения, т. е. позволяет определить страницы, находящиеся на них элементы управления - контент-модули (content units), их связь с базой данных и навигацию между ними. Детали внешнего вида интерфейса (вид отображения элементов управления, их цвета, геометрические размеры и пр.) задаются с помощью стилей уже на уровне модельного инструмента. Бизнес-логика Web-приложения задается с помощью модели контента (см. ниже), которая в действительности составляет с гипертекстовой моделью неразрывное целое. Контент-модули можно группировать в страницы (pages), а те, в свою очередь, в области (areas) и рабочие места системы (site views), например рабочее место администратора, неавторизованного пользователя, авторизованного пользователя. Таким образом, WebML поддерживает структурную декомпозицию. Страницы и контент-модули можно соединять связями (links), которые могут передавать управление и/или данные.
Модель контента (content model) определяет дополнительные конструкции - операции (operation units), которые можно применять в гипертекстовой модели для задания поведения экранных форм. Операции не могут присутствовать на странице, но их можно соединять со страницами находящимися на страницах контент-модулями и друг с другом при помощи связей (links).
Операции могут объединяться в транзакции, выполняться на сервере и на клиенте.
Спецификация WebML, представленная в [16], состоит из неформальной части с примерами и формальной части в двух вариантах - в виде грамматики в форме Бэкуса-Науора и DTD-схемы. Авторы утверждают, что это эквивалентные представления языка, но они содержат разный набор конструкций. DTD-вариант оказывается «богаче» и точнее. Ряд конструкций не попадает никуда и описан как возможности продукта WebRatio. Кроме того, формальная спецификация не содержит некоторые важные параметры, например видимые пользователем имена отдельных элементов интерфейса. В качестве формальной основы в данной работе нами выбрано DTD-описание WebML.
Опишем кратко используемые в статье элементы нотации DTD-схемы. Каждая значимая конструкция языка представляется именованной сущностью. Приведем пример
*) URL: http://www.webml.org/.
описания именованной сущности ENTITY - одной из основных конструкций модели данных WebML:
<!ELEMENT ENTITY (ATTRIBUTE*, RELATIONSHIP*, PROPERTY*, COMMENT?)>
<!ATTLIST ENTITY id ID #REQUIRED name CDATA #IMPLIED superEntity IDREF #IMPLIED value CDATA #IMPLIED>
Как видно из этого примера, именованная сущность обладает параметрами - связями с другими именованными сущностями. Такие связи могут иметь множественность: ’*’ обозначает 0 или много, ’?’ - 0 или 1. Почти у каждой именованной сущности есть стандартные параметры - PROPERTY (набор свойств, используемых пакетом WebRatio и не определяемых на уровне языка WebML) и COMMENT (комментарий). Далее может следовать описание типизированных атрибутов сущности. Каждый атрибут содержит модификатор типа и модификатор обязательности. Встречаются следующие типы атрибутов: ID (для уникального идентификатора сущности), CDATA (для произвольных текстовых данных), IDREF (нетипизированная ссылка на другую именованную сущность), перечислимый тип. Модификатор обязательности может иметь два значения - #REQUIRED (обязательный, т. е. значение атрибута должно быть всегда определено) и #IMPLIED (не обязательный, т. е. значение атрибута может быть не установлено, например пользователь языка создал сущность этого типа и сохранил, но значение данного атрибута пока не определил).
1.2. Технология REAL-IT. Технология REAL-IT предназначена для быстрой разработки (моделирования и автоматической генерации) приложений, бизнес-логика которых целиком определяется схемой данных. В этом случае все целевое приложение является только лишь средством заполнения и редактирования данных и не содержит сложных функций по их обработке. Интерфейс таких систем удается типизировать следующими видами экранных форм: карточка, список, форма-отношение «многие-ко-многим».
1.2.1. Типовые экранные формы. Экранная форма «карточка» предназначена для задания и редактирования атрибутов некоторой сущности (таблицы) из модели данных (пример см. на рис. 1, а). Если у сущности есть связь с множественностью противоположного конца большей, чем единица, то в карточке появляется список объектов другой сущности, связанных с этим экземпляром данной сущности. Список может быть встроенным в карточку и вынесенным. Пример вынесенного списка показан на рис. 1, в.
Связи «многие-ко-многим» между таблицами переходят в формы-отношения. Пусть в модели данных есть несколько сущностей, связанных отношением «многие-ко-многим» арности п, где п>=2. Тогда часто возникает потребность предоставить интерфейс для добавления/удаления связей объектов этих сущностей. Общий подход к построению соответствующей экранной формы выглядит так. Множество связанных данным отношением объектов разделяется на два подмножества, называемых f -сторона (fixed) и e-сторона (editing). Первое позволяет зафиксировать объекты п - 1 конца п-арного отношения «многие-ко-многим». Второе - это объекты оставшейся стороны. Именно их можно добавлять/удалять в связь для зафиксированных п - 1 объектов f-стороны. На объекты f-стороны могут быть наложены фильтры, которые отображаются связными полями выбора (comboboxes).
II Order [Listl - 5 records liiliiilll::
ШМ
Fmd by order штЬеп
т
31 Open iTopen 51 Open
¡02.21.2003 j 30 jhouse numbe Kirovskiy j Prospect Ctachek..........¡Efimov
j:02.21.2003 ji 0 j house numbe Rzhevka j Dybenko Street : Maksimov
j 02.21.2003:...... 0^ Strelyna ji Saint-Petersburg pros \ Maksimov
239[Open 1:07.07.2004 ii 239; ^Central jiNevskiyprospect ¡Braun
j: Vasiiiostrov \ I iine of VI j Braun
Рис. 1. Типовые экранные формы REAL-IT: карточка а; форма-отношение б; список в
в
District:
Vasiliostrovskiy
Another Streets
Bolysheohtinskiy prospect Bolyshoy prospect Botanicheskaya street Camennoostrovskiy prospect Dybenko street Flower street Krasny prospect Nevskiy prospect Prospect Bolyshevicov Prospect Nepokorennyh Prospect Stachek Saint-Petersburg prospect
StfÊèts in District !
1 line of VI
2 line of VI
3 line of VI
4 line of VI
5 line of VI
6 line of VI
7 line of VI
Bolyshoy prospect of VI
Окончание рис. 1.
Объекты e-стороны можно представить в виде контент-модуля WebML под названием IndexUnit - списка с кнопками выбора (checkboxes), а также двух списков с кнопками перемещения, как показано на рис. 1, б.
Рассмотрим пример, приведенный на рис. 1, б. Сущность District связана отношением «многие-ко-многим» с сущностью Street - в одном районе может быть несколько улиц, а одна улица может пролегать через несколько районов. В поле выбора District мы выбираем какой-то определенный район, и после этого в списке справа, сразу под ним, отображаются все улицы, которые к нему относятся. А в списке слева показываются остальные улицы (т. е. все содержимое сущности Street), и из него вправо можно что-то добавить. И, наоборот, слева можно что-то удалить. Это и будет редактированием связей в данном отношении «многие-ко-многим».
Составная часть форм-отношений и списков - фильтр; например, на рис. 1, б поле выбора District является фильтром. Фильтр может быть сложным (пример представлен на рис. 1, в). Тогда он содержит целый набор полей выбора, некоторые из которых связаны друг с другом. Так, при выборе определенного
района (поле выбора District) в поле выбора Street будут предложены для выбора только те улицы, которые связаны с этим районом, а не вообще все улицы города.
Выше был рассмотрен фильтр-представление, осуществляющий фильтрацию набора данных для их предъявления пользователю с последующим использованием в запросах к базе данных. Существует другой вид фильтра - фильтр ввода, который предназначен для ввода данных на основе уже существующих значений. Он также состоит из полей выбора и в зависимости от выбора в одном поле в другом предлагаются определенные значения.
1.2.2. Ограничения на модель данных. Классическая схема данных, выполненная с помощью диаграмм сущность-связь, оставляет много неопределенностей. Например, многие объекты не могут быть одновременно соединены друг с другом всеми возможными по схеме связями. В таких случаях, чтобы убрать лишние возможности, на схему можно накладывать ограничения, например, с помощью языка OCL [14]. Но этот язык гораздо богаче, чем те возможности, которые требуются здесь в данном случае. Вместе с тем хотелось бы иметь ограничения на схему в наглядном, графическом виде. Формально язык ограничений на данные REAL-IT описывается в [15], здесь же проиллюстрируем его примерами.
a
Рис. 2. Пример ограничений в ИЕАЬ-1Т а - схема данных; б - ограничение 1: городских районов нет; в - ограничение 2: городские районы есть.
На рис. 2, а представлен фрагмент схемы данных для адреса сотрудника компании. Адрес включает два разных случая: (1) сотрудник проживает в большом городе, и его адрес содержит район этого города; (11) сотрудник проживает либо в маленьком городе, либо в сельской местности, и тогда район в адресе отсутствует. Эти ситуации изображены на рис. 2, б, в, являющихся диаграммами объектов UML и задающих
конфигурацию реальных записей и их связей в базе данных, в рамках которой должна быть определенная связь. Такая связь помечается словом «limited». В нашем примере ею является связь адреса и улицы. То есть для двух записей из таблиц Address и Street связь между ними реализуется, если в базе данных есть одна из конфигураций записей, соединенных между собой, как показано на рис. 2, б, в. В случае, представленном на рис. 2, б, связи между районом и адресом не должно быть.
Если возникает потребность определить аналогичные ограничения для отношения между районом и населенным пунктом (сущностями CityDistrict и Settlement), то нужно создать аналогичные диаграммы ограничений, определяющие контекст и альтернативы именно для этого отношения.
Модель ограничений позволяет сформулировать условия связности на зависимые поля в фильтрах и автоматически сгенерировать сответствующий программный код.
1.2.3. Процесс разработки. Модель данных в REAL-IT задается с помощью диаграмм классов UML. Ограничения на эту модель определяются с помощью диаграмм объектов, реализующих язык ограничений из [15]. Модель пользовательского интерфейса строится с помощью специальных программных инструментов, позволяющих задать, для каких таблиц нужны карточки, по каким связям создавать списки, а по каким - формы-отношения, а также задать различные параметры этих экранных форм. Основываясь на данной информации, REAL-IT автоматически генерирует диаграммы классов UML, описывающие созданную модель интерфейса. По UML-моделям REAL-IT автоматически генерирует схему базы данных на SQL/DDL, объектно-ориентированный программный интерфейс к ней на языках Microsoft C++ и VisualBasic, а также экранные формы и код приложения [13].
1.2.4. Об эффективности REAL-IT. На практике встречается достаточно много приложений, которые можно разрабатывать в REAL-IT. Во-первых, существует большое количество небольших информационных систем, полностью попадающих в этот класс. Во-вторых, почти все крупные информационные системы включают в себя подобные подсистемы. В то же время интерфейсы таких систем содержат десятки и сотни однотипных экранных форм, которые непросто создавать и поддерживать. REAL-IT позволяет здесь значительно снизить трудозатраты, заменив процесс программирования на работу с UML-моделями. Это оказывается быстрее, надежнее, требует меньшей программистской квалификации. Технология REAL-IT была успешно применена в ряде промышленных проектов. Статистика использования генератора форм REAL-IT для одного из этих приложений, попадающих в целевой класс REAL-IT, представлена в таблице.
Статистика использования REAL-IT в одном из промышленных проектов
Тип форм Полностью сгенерирована С «ручными» изменениями Сопровождаются «вручную» Всего
Список 69 16 6 91
Карточка 37 21 16 74
Отношение 17 1 4 22
Другое 0 0 6 6
Всего 128 38 32 193
Первый столбец представляет количество экранных форм, полностью сгенерированных в ИЕАЬ-1Т и вошедших в целевой код системы без изменений (63,7%). Во втором столбце приведены формы, которые были изменены после генерации, но эти изменения удалось «поднять» в технологию (19,7%). Третий столбец показывает количество
форм, которые изначально генерировались, но после этого дорабатывались «вручную» (13,5%). Тип форм «Другое» обозначает количество форм, которые не удалось стандартизовать средствами ИЕАЬ-1Т, и они полностью разрабатывались «в ручную», т. е. их не удалось отнести ни к одному из типов ИЕАЬЛТ (3,1%). Подробнее эффективность использования ИЕАЬ-1Т обсуждается в работах [10, 13].
2. Расширение модели данных. Авторы WebML не используют п-арные отношения и сущности-отношения, хотя во многих вариантах диаграмм сущность-связь они есть (например, в модели классов UML [14]). Эти конструкции повышают выразительную силу модели и могут применяться при автоматической генерации кода. Мы предлагаем ввести их в модель данных WebML. В процессе концептуального моделирования при появлении п-арных связей становится возможным задавать их непосредственно, а не «реализационно». Например, факт наличия у преподавателя ученой степени удобно определять как наличие связи между тремя сущностями - преподавателем, видом наук (общественных, технических и т. д.) и видом степени (кандидат наук/доктор наук). Кроме того, единое, высокоуровневое представление п-арных отношений «многие-ко-многим» с возможностью задавать атрибуты этого отношения через сущность-отношение позволяют определить единый шаблон для формы-отношения «многие-ко-многим».
* *
Студент Экзамен
! 1
I
Оценка
Рис. 3. Пример сущности-связи «многие-ко-многим»
На рис. 3 приведен пример сущности-отношения. Сущности «Студент» и «Экзамен» связаны отношением «многие-ко-многим»: один экзамен могут сдавать многие студенты, а один студент - много разных экзаменов. У данной связи есть атрибут - оценка, полученная студентом по экзамену. Мы предлагаем поместить его в специальную сущность, связанную с отношением (в данном случае это сущность «Оценка») .
Бинарное отношение «многие-ко-многим» можно представить через дополнительную сущность и пару отношений «один-ко-многим» такой сущности с прежними. Тогда атрибуты этого отношения будут содержаться в новой сущности. Однако п-арное отношение, где п >2, так не представляется, а между тем такие отношения удобны, встречаются на практике и по ним также требуется создавать формы «многие-ко-мно-гим» - все сущности, кроме одной, помещаются в фильтр, а оставшаяся редактируется. Предложенные идеи формализуем следующим образом.
В начальное описание модели данных WebML добавим новую сущность - сложное отношение (COMPLEXRELATЮN):
*) При этом пользуемся тем же способом, что и в модели классов UML — там такая конструкция называется класс-ассоциацией [14].
<!ELEMENT Structure (DOMAIN*, ENTITY*, COMPLEXRELATION*)>
<!ELEMENT COMPLEXRELATION (ATTRIBUTE*, ROLE*, PROPERTY*,
COMMENT?)> <!ATTLIST COMPLEXRELATION id ID #REQUIRED
name CDATA #IMPLIED>
Сложное отношение содержит набор атрибутов (ATTRIBUTE*) - например, оценка на рис. 3, а также набор ролей, через которые отношение соединяется с разными сущностями. Роль задаем так:
<!ELEMENT ROLE (PROPERTY*, COMMENT?)> <!ATTLIST ROLE id ID #REQUIRED
name CDATA #IMPLIED
to IDREF #REQUIRED
minCard CDATA #REQUIRED
maxCard CDATA #REQUIRED>
Наша роль по составу атрибутов похожа на роль обычного бинарного отношения в WebML (конструкция RELATIONSHIP), т. е. содержит ссылку на сущность, участвующую в отношении (атрибут to), и диапазон множественности (атрибуты minCard и maxCard).
3. Моделирование фильтров и связных полей ввода.
3.1. Контент-модуль ComplexFilterUnit. В языке WebML хотелось бы иметь средства для моделирования сложных фильтров с зависимыми полями. Фильтры в WebML можно задавать с помощью контент-модуля EntryUnit, но при этом нет возможности задать также зависимости между полями. Для задания фильтров с зависимыми полями введем новый контент-модуль ComplexFilterUnit. В DTD-схеме WebML есть возможность определять новые контент-модули. Воспользуемся ею и перейдем к описанию самого модуля:
<!ELEMENT COMPLEXFILTERUNIT (ATTRIBUTEFIELD*, RELATIONFIELD*,
LINK*, PROPERTY*, COMMENT?)> <!ATTLIST COMPLEXFILTERUNIT id ID #REQUIRED
name CDATA #IMPLIED
mainCaption CDATA #IMPLIED
source IDREF #REQUIRED
filterType (browse | input) #REQUIRED>
Опишем атрибуты такой конструкции:
• name - это модельное имя конструкции, имеющей тип COMPLEXFILTERUNIT;
• mainCaption - имя группы зависимых полей фильтрации, отображаемое в итоговом, сгенерированном по данной конструкции, фрагменте интерфейса и видимое пользователем;
• filterType определяет вид фильтра. Возможны два варианта: (i) значение browse, задает фильтр-представление; тогда значения его полей используются как параметры селекторов выбора в других модулях модели; (ii) значение input, задает фильтр ввода; тогда информация, выбранная пользователем Web-интерфейса в полях конструкции COMPLEXFILTERUNIT, заносится в базу данных Web-приложения;
• source - это ссылка на сущность, которую фильтрует данный фильтр. Каждый COMPLEXFILTERUNIT фильтрует объекты одной сущности - по ее атрибутам и/или связям. От этой сущности сложный фильтр, по отношениям в модели данных, может «захватить» для фильтрации некоторый фрагмент самой модели.
Далее конструкция COMPLEXFILTERUNIT включает набор фильтрующих полей, каждое из которых является ограничением на выборку объектов из сущности source. Фильтруемые поля задаются параметрами ATTRIBUTEFIELD (фильтрация по атрибуту сущности) и RELATIONFIELD (фильтрация по отношению). Каждое поле фильтра определяет поле выбора в Web-интерфейсе, где пользователь совершает выбор - единичный или множественный. Таким образом, каждое поле выдает одно значение или коллекцию. Они все являются выходными параметрами COMPLEXFILTERUNIT, которые используются другими модулями в соответствии с типом фильтра.
Поле фильтрации по атрибуту задается так:
<!ELEMENT ATTRIBUTEFIELD (PROPERTY*, COMMENT?)> <!ATTLIST ATTRIBUTEFIELD
id ID #REQUIRED
fieldCaption CDATA #IMPLIED
sourceAttribute IDREF #REQUIRED
format CDATA #IMPLIED
attributeOperation CDATA #REQUIRED>
Опишем атрибуты такой конструкции:
• fieldCaption - статический текст, который служит именем фильтрующего поля и отображается в целевом интерфейсе рядом с полем. Фильтрующее поле является тем значением, которое пользователь интерфейса вводит сам и которое задает исходную точку фильтрации. Например, выдать список студентов, фамилии которых начинаются с «Вас...». Если конструкция ComplexFilterUnit состоит всего лишь из одного поля, то fieldCaption не нужен - его роль выполняет атрибут mainCaption;
• sourceAttribute - ссылка на атрибут сущности, который фильтруется данным полем фильтра;
• format - формат отображения результатов фильтрации, например способ отображать десятичные числа (с точкой или запятой), формат даты и т. д.;
• attributeOperation - выражение (на языке SQL), которое задает условие фильтрации атрибута сущности. Как правило, это набор бинарных операций >, <, ==, != и т. д., соединенных конъюнкцией.
Поле фильтрации по отношению задается так:
<!ELEMENT RELATIONFIELD (ATTRIBUTEFIELD*, RELATIONFIELD*,
PROPERTY*, COMMENT?)> <!ATTLIST RELATIONFIELD id ID #REQUIRED
fieldCaption CDATA #IMPLIED
sourceRelation IDREF #REQUIRED
display CDATA #REQUIRED
format CDATA #IMPLIED
relationOperation CDATA #REQUIRED>
Атрибуты format, fieldCaption и relationOperation аналогичны подобным атрибутам у ATTRIBUTEFIELD. Опишем остальные:
• sourceRelation - ссылка на связь фильтруемой сущности, которая фильтруется данным полем: либо на конструкцию WebML RELATIONSHIP (связь бинарная), либо на нашу конструкцию ROLE (связь п-арная);
• display - селектор (выражение на языке SQL), который указывает, какой именно атрибут (набор атрибутов) той, другой, сущности или связанных с ней нужно показывать в списке результатов фильтрации. Например, если из сущности «Группа» фильтруются студенты, имеющие академическую задолжность (т. е. фильтруется связь из сущности «Группа» в сущность «Студент»), то показывать нужно не ID студентов, а их фамилии, имена, отчества.
На отношение можно накладывать дополнительные ограничения по фильтрации, используя другие связи фильтруемой второй сущности, соединенной этим отношением с первой, фильтруемой. То есть с полем фильтрации по связи можно соединять дополнительные поля, что отражено параметрами ATTRIBUTEFIELD и RELATIONFIELD. Рассмотрим пример сложного фильтра для формы, представленной на рис. 4:
<COMPLEXFILTERUNIT id="1" name="AddressFilter" source=
"Идентификатор класса Address" filterType="browse">
<ATTRIBUTEFIELD id="2" fieldCaption="Building" sourceAttribute=
"Идентификатор атрибута BuildingNumber" attributeOperation="equal"/> <RELATIONFIELD id="3" fieldCaption="Street" sourceRelation=
"Идентификатор связи Address-Street" display="SELECT Name FROM Street" relationOperation="in">
<RELATIONFIELD id="4" fieldCaption="City" sourceRelation=
"Идентификатор связи Street-City" display="SELECT Name FROM City" relationOperation="in"/>
</RELATIONFIELD>
</COMPLEXFILTERUNIT>
3.2. Модель ограничений. Эту модель добавим к существующим в WebML моделям следующим образом:
<!ELEMENT WebML (Structure, Navigation, Mapping, Constraint*)>
<!ELEMENT CONSTRAINT (OBJECT*, RELINSTANCE*, PROPERTY*, COMMENT?)>
<!ATTLIST CONSTRAINT
id ID #REQUIRED
name CDATA #IMPLIED>
Ограничение состоит из набора объектов (экземпляров соответствующих сущностей) и экземпляров п-арных отношений (это задается параметром RELINSTANCE), участвующих в ограничении. Отдельный объект определим следующим образом:
<!ELEMENT OBJECT (PREDICATE*, OBJECTLINK*, PROPERTY*, COMMENT?)>
<!ATTLIST OBJECT
id ID #REQUIRED
name CDATA #IMPLIED
entity IDREF #IMPLIED>
Экземпляр п-арного отношения задается так:
<!ELEMENT RELINSTANCE (PREDICATE*, PROPERTY*, COMMENT?)> <!ATTLIST RELINSTANCE
id ID #REQUIRED
name CDATA #IMPLIED
complexRelation IDREF #IMPLIED>
Предикат будем рассматривать как произвольное условие-ограничение, выраженное блоком текста. Его формальное определение очевидно, и мы его опустим.
Рис. 4. Пример экранной формы, созданной на основе модуля ComplexFilterUnit
Связь объекта с другими объектами обозначается параметром OBJECTLINK и является аналогом ROLE для отношения между сущностями в модели данных. Определим ее следующим образом:
<!ELEMENT OBJECTLINK (PROPERTY*, COMMENT?)> <!ATTLIST OBJECTLINK id ID #REQUIRED
name CDATA #IMPLIED relationship IDREF #REQUIRED inverse IDREF #REQUIRED negative (yes | no) "no" slave (yes | no) "no">
Возможны два варианта значений атрибутов relationship и inverse: в случае бинарной связи первый ссылается на RELATIOSHIP, а второй - на OBJECTLINK другого конца связи; в л-арной связи первый ссылается на ROLE, а второй - на RELINSTANCE. Кроме того, у OBJECTLINK есть два логических флага, определяющих, является
ли она отрицательной связью (атрибут negative) или определяет зависимую связь (атрибут slave) [15]. Оба атрибута имеют значение по умолчанию «no».
4. Карточки и списки. Полнофункциональные карточки и списки можно легко строить, используя различные конент-модули WebML, а также введенный модуль COMPLEXFILTERUNIT.
5. Шаблон для реализации формы-отношения «многие-ко-многим». В данном случае создаем шаблон проектирования, а не новую конструкцию, как было в случае с COMPLEXFILTERUNIT. Нам удалось сделать этот шаблон компактным, независимым от параметров его участников - в частности, арности связи «многие-ко-многим». Данный шаблон представлен на рис. 5.
Рис. 5. Шаблон для формы-отношения «многие-ко-многим»
Он состоит из одной страницы, на которой размещается соответствующая экранная форма, и одной транзакции, которая включает в себя все операции по обработке ввода данных в эту форму. Страница содержит три элемента:
• Filer, имеющего тип COMPLEXFILTERUNIT; он включает в себя f-сторону формы-отношения;
• AlreadySelected, имеющего тип Selector; этот элемент делает запрос к базе данных и выдает все объекты e-стороны, которые уже связаны с f-стороной;
• MultySelector, имеющего тип IndexUnit; он включает в себя е-сторону формы-отношения; т. е. здесь показываются результаты запроса к базе данных на основе выборки фильтра Filter - объекты е-стороны; на этот список «накладываются» результаты выборки AlreadySelected и либо в кнопках выбора (checkboxes) появляются галочки для уже выбранных объектов, либо выбранные объекты отображаются в окне справа, а не выбранные - в окне слева, как показано на рис. 1, б.
После того, как пользователь добавил/удалил какие-то связи в MultySelector, управление передается операции MustBeDeleted, которая удаляет связи из базы данных для удаленных пользователем объектов. При успешном выполнении этой операции управление передается операции Connect, добавляющей в базу данных связи для тех объектов, которые пользователь добавил. При неуспешном выполнении одной из таких операций управление снова передается форме MultySelector.
Предложенный нами шаблон более функционален, чем рассмотренный в [17]. Он позволяет создавать более сложные фильтры, корректно работает со связями (при добавлении новых связей прежние, оставшиеся, не удаляются, чтобы быть созданными заново), инвариантен относительно того, как представлено отношение «многие-ко-многим» - в обычном или «раскрытом» виде (через отношения «один-ко-многим»). Наш шаблон позволяет также задать форму-отношение для п-арной связи «многие-ко-многим» и для цепочки таких отношений. Это достигается усложнением фильтра, причем сам шаблон не меняется.
6. Заключение. Предложенный в работе подход может быть интегрирован с гипертекстовыми моделями других модельно-ориентированных методов к разработке Web-приложений (обзор таких методов можно найти в [3]), а также с подходом RUX [9] в качестве более высокоуровневой надстройки над ним для решения более узкого класса задач.
Расширение языка WebML выполнено максимально формально с целью обеспечить автоматическую генерацию кода по спецификациям на языке. Для этой цели, например, были введены в язык и те имена конструкций, которые отображаются в самом интерфейсе. Более того, по нашему мнению, WebML должен быть строже формализован еще и для того, чтобы из языка-лидера университетских разработок превратиться в широко используемый практический подход. Для этого нужна качественная формальная спецификация языка.
Литература
1. Duhl J. White paper: Rich Internet Applications. Tech. report. IDC. November 2003. 52 p.
2. Paulson L. D. Building Rich Web Applications with Ajax // Computer. 2005. Vol. 38, N 10. P. 14—17.
3. Preciado J. C., Trigueros M. L., Sanchez F. et al. Necessity of methodologies to model Rich Internet Applications // WSE. 2005. P. 7—13.
4. Bozzon A., Comai S., Fraternali P. et al. Conceptual modeling and code generation for rich internet applications // ACM Intern. Conf. Proc. Series. Vol. 263. Proc. of the 6th Intern. Conf. on Web Engineering. 2007. P. 353-360.
5. Rossi G., Pastor O., Schwabe D. et al. Web Engineering: Modelling and Implementing Web Applications. Berlin: Springer, 2007. 464 p.
6. Acerbis R., Bongio A., Brambilla M. et al. WebRatio 5: An Eclipse-Based CASE Tool for Engineering Web Applications // LNCS. 2007. Vol. 4607. Berlin; Heidelberg: Springer, 2007. P. 501-505.
7. Toffetti C. G. Modeling data-intensive Rich Internet Applications with server push support // Intern. workshop Model-Driven Web Engineering in conjunction with ICWE. Como (Italy), 2007. P. 26-48.
8. Preciado J. C., Linaje M., Comai S. et al. Designing Rich Internet Applications with Web Engineering Methodologies Web Site Evolution // WSE. 2007. 9th IEEE Intern. Workshop. 5-6 Oct. 2007. P. 23-30.
9. Linaje M., Preciado J. C., Shnchez-Figueroa F. A Method for Model Based Design of Rich Internet Application Interactive User Interfaces// ICWE. 2007. LNCS 4607. P. 226-241.
10. Ivanov A., Koznov D. REAL-IT: Model-Based User Interface development Environment // Proc. of IEEE/NASA ISoLA 2005. Workshop on Leveraging Applications of Formal Methods, Verification, and Validation. Loyola College Graduate Center Columbia, Maryland, USA, 23-24 September 2005. P. 31-41.
11. Терехов А. Н., Романовский К., Кознов Д. и др. REAL: методология и CASE-средство для разработки систем реального времени и информационных систем // Программирование. 1999. № 5. С. 44-51.
12. Иванов А. Н. Технологическое решение REAL-IT: создание информационных систем на основе визуального моделирования // Системное программирование / под ред. А. Н. Терехова, Д. Ю. Булычева. СПб.: Изд-во С.-Петерб. ун-та, 2004. С. 89-100.
13. Иванов А. Н., Стригун С. А. Технологическое решение REAL-IT: Моделирование и генерация пользовательского интерфейса // Системное программирование / под ред. А. Н. Терехова, Д. Ю. Булычева. СПб.: Изд-во С.-Петерб. ун-та, 2004. С. 124-147.
14. Буч Г., Якобсон А., Рамбо Дж. UML. Изд. 2-е / пер. с англ.; под ред. С. Орлова. СПб.: Питер, 2006. 735 с.
15. Иванов А. Н. Графический язык описания ограничений на диаграммы классов UML // Программирование. 2004. № 4. С. 204-208.
16. WebML User Guide WebRatio 4.WS. 2005. 90 p.
17. Advanced Features Tutorial WebRatio 4.3. 2005. 60 p.
Статья рекомендована к печати проф. А. Н. Тереховым.
Статья принята к печати 5 марта 2008 г.
