Формализация метамодели веб-приложения Текст научной статьи по специальности «Компьютерные и информационные науки»

А.А. Пупыкина, A.Е. Сатунина

ФОРМАЛИЗАЦИЯ МЕТАМОДЕЛИ ВЕБ-ПРИЛОЖЕНИЯ

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

Ключевые слова: модель, модельно-ориентированный подход, трансформация, веб-приложение.

Объектом исследования является процесс модельно-ориентированной разработки веб-приложений, в частности, пользовательского интерфейса в Сети1.

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

Методологическую основу предлагаемого подхода составляет метамодель веб-приложения, приведенная на рис. 1.

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

© Пупыкина А.А., Сатунина A.Е., 2014

Рис. 1. Общая схема метамодели веб-приложения

Общая схема механизма трансформации представлена на рис. 2.

Метамодели каждого вида моделей Механизм трансформации Множество исходных моделей в .

Множество исходных моделей пригодном для трансформации виде Множество сгенерированных моделей

Описание правил трансформации

Рис. 2. Общая схема трансформации модели веб-приложения

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

Метамодель веб-приложения

Представим метамодель в формализованном виде для определения состава, структуры и взаимосвязи элементов моделей.

Метамодель веб-приложения можно представить в виде множества:

М = (МЕ, Мв, Мг, ММ, Мс, М3 ) , где

МЕ - модель уровня данных. МЕ = БСЕ, где БСЕ - множество иМЬ-диаграмм классов для моделирования сущностей предметной области:

Осе = }, Ще = 1, МБсе ,

^БСЕ - количество диаграмм классов в модели данных. Мп - модель уровня доступа к данным. Мв=ВСв, где БСП - множество иМЬ-диаграмм классов для моделирования объектов доступа к данным2:

п = {йси } N0 = 1 N0

№ВСП - количество диаграмм классов в модели уровня доступа к данным;

Му - модель пользовательского интерфейса для моделирования наполнения веб-страниц визуальными элементами. Му = Бсу, где БСу - множество иМЬ-диаграмм компонентов:

»су = [Сот }, ^ = 1,

- количество диаграмм компонентов в модели пользовательского интерфейса;

ММ - модель уровня модели интерфейса для представления предметной области наполнения веб-страниц визуальными элементами. ММ = БСМ, где БСМ - множество иМЬ-диаграмм классов:

О = Ысм } N0 = 1 N0

^СМ { " N0^ } ^см ^ 1 у^см

№0СМ - количество диаграмм классов в модели уровня модели интерфейса;

МС - модель управления взаимодействием с пользователем. МС = (ОиС, Бт, 0СС), где БиС - множество иМЬ-диаграмм вариантов использования предназначенных для моделирования верхнего уровня навигационной архитектуры приложения и ролей доступа, Бт - множество иМЬ-диаграмм конечных автоматов для модели-

рования сценариев взаимодействия с пользователем, Всс - множество иЫЬ-диаграмм классов для моделирования классов-контроллеров:

В = {йис } N0 = 1 N0

^ис { " NВис } ^ ^ис х>1 у^ис ,

- количество диаграмм вариантов использования в модели управления взаимодействием с пользователем;

В = 1йш } N0 = 1 N0

^ЪМ { " NDSM } ^ ^ 1 ,

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

В = Ысс } N0 = 1 N0

^сс { " ЪЮСС } ^ ^сс х>1 У1^сс

МВсс - количество диаграмм классов в модели управления взаимодействием с пользователем;

М5 - модель сервисов. М5 = Бсз, где ВС5 - множество иМЬ-диа-грамм классов для моделирования сервисов:

О = {йСБ } N0 = 1 N0

- количество диаграмм классов в модели сервисов.

Для описания моделей представим общую структуру (ЬД)-помеченного Т - типизированного графа диаграммы.

0Шм = (V , е , , гш", Г", тш", !уреш" },

] - 1 ' ^ - 1 '

где

- номер диаграммы модели М;

/дгдм - общее количество вершин графа диаграммы йШм ; Кюм - общее количество ребер графа диаграммы ; V№М - вершина графа диаграммы ¿М!0м; еN°СЕ - вершина графа диаграммы ;

5Л®М : ЕЛ®М ^ ум°М - функция, ставящая в соответствие каждому ребру е™М начальную вершину V ;

: Ем°М ^ ум°М - функция, ставящая в соответствие каждому ребру е ™М конечную вершину V ™М ;

lndm = (vindm: Vndm ^ vlndm , elNDu: ENDm ^ ELND") - функции расстановки меток вершинам и ребрам соответственно;

lndm = (vlndm: Vndm ^ VLndm , elndm: ENDu ^ ELNDu) - функции расстановки ролей вершинам и ребрам соответственно;

lndm = (vindm: Vndm ^ vlndm , elndm: ENDm ^ ELndm) - функции расстановки типов вершинам и ребрам соответственно.

Для представления диаграмм подклассы метакласса Relationship метамодели UML представим в виде типов ребер, прямых или косвенных потомков метакласса ModelElement - в виде типов вершин.

Диаграмма классов модели уровня данных dND^ = .

Определим типы для DN

NDc

= {classentity' attribute, operation};

EC? = {association, dependency, instantiation, ownership}.

Association - тип ребра для описания связи двух классов уровня данных. Association: class _ ^ class _ .

entity entity

Dependency - тип ребра для описания связи вида «зависимость» от класса уровня данных к классу уровня доступа к данным. Dependency: class _ ^ class, „.

^ ^ entity data

Instantiation - тип ребра для описания типов атрибутов и возвращаемых значений операций. Instantiation: attribute ^ classentity, Instantiation: operation ^ class t .

entity

Ownership - тип ребра для описания атрибутов и операций класса. Ownership: attribute ^ class _ , Ownership: operation ^ class _ .

entity entity

Диаграмма классов модели уровня доступа к данным dCD = D

ndcd ndcd .

Определим типы для dndcd : VTam™ = {classdata, attribute, operation};

EC? ={association, generalization, ownership, instantiation}.

Association - тип ребра для описания связи двух классов уровня доступа к данным. Association: classddata ^ classdata.

Generalization - тип ребра для описания связи вида «общее-частное» двух классов уровня доступа к данным. Generalization: class, „ ^ class, „.

data data

Instantiation - тип ребра для описания типов атрибутов и возвращаемых значений операций. Instantiation: attribute ^ classdata, Instantiation: operation ^ classdata.

Ownership - тип ребра для описания атрибутов и операций класса. Ownership: attribute ^ classdata, Ownership: operation ^ class ddata. Диаграмма классов модели уровня модели пользовательского

интерфейса dNDL = D

ND,

cm

Определим типы для Dnd,

cm

VTHCeM = {claSSmodel- interfaCemodel- attribUte, OperatiOn};

ETnam™ = {generalization, dependency, realization, ownership, instantiation}.

Generalization - тип ребра для описания связи вида «общее-частное» двух классов уровня пользовательского интерфейса. Generalization: class ,, ^ class ,,.

model model

Dependency - тип ребра для описания связи вида «зависимость» между двумя моделями пользовательского интерфейса, от класса уровня модели интерфейса к классу уровня сервисов, от класса уровня модели интерфейса к классу сервиса. Dependency:

class ,, ^ class ,,, Dependency: class ,, ^ class . , Dependency:

model model 7 ^ ^ model service 7 г ^

class ,, ^ class,„ .

model data

Realization - тип ребра для описания связи между классом и интерфейсом, при котором класс гарантирует выполнение обязательств интерфейса. Realization: class ,, ^ interface ,,.

model model

Instantiation - тип ребра для описания типов атрибутов и возвращаемых значений операций. Instantiation: attribute ^ classmodel, Instantiation: operation ^ classmodel, Instantiation: operation ^ interface .

model

Ownership - тип ребра для описания атрибутов и операций класса. Ownership: attribute ^ classmodel, Ownership: operation ^ class ,,, Ownership: operation ^ interface ,,.

model model

Диаграмма компонентов интерфейса пользователя dNDcv = DNDcy.

Определим типы для DNDcv :

VT CV = {component };

name t* viewJ'

ET2C ={include}.

Include - тип ребра для описания включения элементов пользовательского интерфейса в составной компонент.

Include: component. ^ component. .

г view г view

Диаграмма классов контроллеров d^ = DNDcc .

Определим типы для DND :

УТ1сес = {classcontroiier- interfac^controller' operation};

ЕТПатС = {generalization, dependency, realization, ownership, instantiation};

Generalization - тип ребра для описания связи вида «общее-частное» двух классов контроллеров. Generalization: classcontroller ^ class „ ,, .

controller

Dependency - тип ребра для описания связи вида «зависимость» от класса контроллера к классу сервиса. Dependency: class „ ,, ^ class . .

controller service

Realization - тип ребра для описания связи между классом и интерфейсом, при котором класс гарантирует выполнение обязательств интерфейса. Realization: class „ ,, ^ interface „ ,, .

controller controller

Instantiation - тип ребра для описания типов атрибутов и возвращаемых значений операций. Instantiation: Instantiation: operation ^ class „ ,, , Instantiation: operation ^ interface „ ,, .

controller controller

Ownership - тип ребра для описания атрибутов и операций класса. Ownership: Ownership: operation ^ classcontroller, Ownership: operation ^ interface . .

service

Диаграмма классов модели сервисов dNSDcs = DNDcs .

Определим типы для DNDcs :

VTNDcs = {class . , interface . , attribute, operation};

name y service service7 7 r 11

ET^D = {generalization, dependency, realization, ownership, instantiation}.

Generalization - тип ребра для описания связи вида «общее-частное» двух классов уровня пользовательского интерфейса. Generalization: class ^ class . .

service service

Dependency - тип ребра для описания связи вида «зависимость» между двумя сервисами, от класса сервиса к классу сущности, от класса сервиса к классу уровня доступа к данным. Dependency: class ^ class . Dependency: class ^ class _ Dependency:

service service, service entity,

class ^ class, „ .

service data

Realization - тип ребра для описания связи между классом и интерфейсом, при котором класс гарантирует выполнение обязательств интерфейса. Realization: class ^ interface . .

service service

Instantiation - тип ребра для описания типов атрибутов и возвращаемых значений операций. Instantiation: attribute ^ class . ,

service

Instantiation: operation ^ class . , Instantiation: operation ^

^ service7 ^

interface . .

J service

Ownership - тип ребра для описания атрибутов и операций класса. Ownership: attribute ^ class . , Ownership: operation ^

r service7 г r

class . , Ownership: operation ^ interface . .

service7 ^ ^ J service

Диаграмма вариантов использования модели навигационных структур dUDuc = DNDuc .

Определим типы для DNDuc :

VTnNarneC = {useCase actor};

ET^f = {association, generalization, include, extend} .

Association - тип ребра для описания связи актора и варианта использования. Association: actor ^ useCase.

Generalization - тип ребра для описания связи вида «общее-частное» двух акторов или двух вариантов использования. Generalization: actor ^ actor, Generalization: useCase ^ useCase.

Include - тип ребра для описания связи вида «включение» двух вариантов использования. Include: useCase ^ useCase.

Extend - тип ребра для описания связи вида «расширение» двух вариантов использования. Extend: useCase ^ useCase.

Диаграмма конечных автоматов модели детализации навигаци-

iSM гч

онных сценариев dNDsM = DNDsm . Определим типы для DNDsm : VTNDsm = {state};

name y '

ETnZlM transition};

Transition - тип ребра для описания перехода от одного состояния к другому. Transition: state ^ state.

Роли и метки

Для вершин графа диаграмм компонентов интерфейса пользователя dNpcv componentview введем роли {actionState, passivState}.

Для вершин графа диаграмм компонентов интерфейса пользователя d'CDcv с ролью activeState введем метки задания соответствия вершин componentview с соответствующим ребром transition

view iSM

диаграммы конечных автоматов dND .

Для вершин графа диаграмм вариантов использования с

типом шеСаве введем метки задания соответствия с соответствующем

щей диаграммой конечных автоматов анп .

Для вершин графа диаграмм конечных ав томатов введем

роли {1топ1Е^81а1е, 8етее31а1е}.

Для вершин графа диаграмм конечных автоматов с ро-

лью 8етее31а1е введем метки задания соответствия вершин состояний с классами диаграммы классов контроллеров dND^ .

Для вершин графа диаграмм конечных автоматов dNDsм с ролью frontEndState введем метки задания соответствия вершин состояний с классами диаграммы классов интерфейса пользовате-

Процессный граф событийно-ориентированного приложения

Описание событийно-ориентированной модели действий в RIA(Rich Internet Applications)-приложениях основывается на объединениях поведенческих операторов. События определяют системные процессы на определенном уровне абстракции и могут делиться на видимые и невидимые. Множеству видимых событий присвоим метки из множества Actv символом т обозначим любое невидимое событие. Одного символа достаточно т, поскольку с точки зрения внешнего наблюдателя нет никакого различия невидимых событий. Тогда через Act = ActV U т выразим множество всех меток событий приложения. Поведенческие операторы отражают фундаментальные понятия, такие как последовательное соединение, альтернативная композиция и параллельная композиция процессов, представляющих поведение систем. Рассмотрим более подробно виды поведенческих операторов.

Неактивное событие 0 описывает завершившийся процесс. Содержит только одну вершину, нет ребер.

Оператор префикса события a.P описывает процесс, который может выполнять а и затем ведет себя, как P. Этот оператор отображает последовательную композицию событий. Представляется в виде вершины Vfl, являющейся корнем для a.P и ребра e( ya-P , VP ).

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

ции. Выбор может быть полностью внутренний, если выполняемые события все невидимые, или выбор будет зависеть от воздействия

внешней среды. Представляется в виде вершины VP1+P2, являющейся корнем для P1 + P2 и множества ребер e( VPl+Р2, VN ) для

каждого ребра e( VP1, VN ) и e( VP2, VN )

Оператор параллельной композиции P1 || P2 определяет процесс, который ведет себя поочередно то как P1, то как P2, с применением множества синхронизованных событий с метками: S С ActV. Событие, не входящее в множество S, выполняется автономно. Синхронизация выполняется принудительно между любыми событиями P1 и Р2, имеющимися в множестве S, и в этом случае результирующее событие имеет такое же имя, как у двух исходных. Когда S = 0, P1 и P2 могут выполняться независимо друг от друга. Когда S = Actv, P1 и P2 должны синхронизироваться по всем видимым событиям. Представляется в виде пары начальных вершин ( VP1,

V0P2), являющейся корнем для P1 || P2 , множества вершин вида

( VP1, VP2), множества ребер e(( VP1, VP2),( VN, VP2 )) если для P1

определено ребро e( VP1, VN ), e(( VP1 ,VP2),( VP1 ,VN )) если для

P2 определено ребро e( VP2 ,VN ), e(( VP1, VP2),( Vм , VN )) если

для P1 определено ребро e( VP1, Vм ) и для P2 определено ребро

e( VP2, VN ).

Оператор сокрытия P / H представляет собой процесс, который ведет себя как Р, в котором каждое событие с меткой H С Actv трансформируется в т. Этот оператор определяет механизм абстракции по отношению к определенным действиям и может быть использован для предотвращения взаимодействия процесса с внешней средой. Представляется в виде графа путем изменения всех меток ребер графа Р, принадлежащих множеству H на т.

Оператор ограничения Р \ L представляет собой процесс, который ведет себя как Р, в котором каждое событие с меткой L С Actv предотвращается от выполнения. Результат этого оператора такой же, как результат оператора параллельной композиции с 0, в которых L используется в качестве множества синхронизованных событий. Представляется в виде графа путем удаления из графа P всех ребер с метками из множества L.

Оператор переименования: P[9] представляет собой процесс, который ведет себя как Р, в котором каждое событие переименовано в соответствии с общей функцией переименования ф: Act ^Act, сохраняющей видимость действий, т. е. ф-1(т) = {т}.

Обозначим через Яе1аЬ множество таких функций переименования. Для удобства одиночное переименование можно записать а ^ Ь, что означает событие, а переименовывается в Ь. Представляется в виде графа путем изменения всех меток ребер графа Р в соответствии с функцией ф.

Рекурсия: гес X : Р представляет собой процесс, который ведет себя как Р, в котором каждое свободное вхождение переменной процесса X заменяется на гес X : Р. Рекурсивная функция называется конечной, если для всех ее переменных процесс вхождения ограничен, в противном случае она считается бесконечной.

Выводы

Применение модельно-ориентированного подхода для разработки веб-приложений, использование декларативного языка спецификации пользовательского интерфейса и средств автоматической генерации приведет к снижению стоимости и времени разработки. Модельно-ориентированный подход к разработке веб-приложения, предоставляющий автоматическую генерацию интерфейса по декларативным, высокоуровневым моделям позволит ослабить технологическую привязку разрабатываемого интерфейса к конкретной платформе. Однако сам процесс разработки правил трансформации требует формализации моделей для применения автоматической верификации и валидации механизмов трансформации. В работе предложена формализованная метамо-дель веб-приложения, рассмотрены некоторые аспекты разработки процессного графа событийно-ориентированного приложения, к которым относятся веб-приложения класса Rich Internet Application (RIA). Аппарат теории графов предоставляет средства для формализованного описания метамодели взаимодействия и обеспечивает предоставление точных математических зависимостей между отдельными ее компонентами.

Примечания

См.: Пупыкина А.А. Анализ современных подходов к автоматизации разработки веб-приложений // Межотраслевая информационная служба № 3. М.: ВИМИ, 2011. С. 12-20.

Cunningham W, Beck K. A Diagram for Object-Oriented Programs [Электронный ресурс] // The ACM Digital Library. URL: http://dl.acm.org/citation. cfm?id=28734 (дата обращения: 07.06.2008).