Формальная постановка решения проблемы

На основании предложенной концепции обобщенная постановка решения задачи автоматической генерации пользовательского интерфейса веб-приложений имеет вид:

Дано: X – диаграмма классов предметной области; Y - предметная область веб-приложения; Z - информация о конфигурации внешнего дизайна

Требуется разработать алгоритм G для получения финального пользовательского интерфейса:[АШ46]

FUI=G (E_m, MMod_e, Ent_r, S, Mod_nav, Mod_gen),

где FUI – финальный пользовательский интерфейс,

G – алгоритм генерации финального пользовательского интерфейса веб-приложения,

MMod_e – метамодель в формате ecore,

Ent_r- маппинг сущностей и стандартных классов данной предметной области,

S - настройка конфигурации внешнего дизайна,

Mod_nav - модель контентно-навигационной карты веб-приложения,

Mod_gen - модель генератора промежуточных компонентов.

2.4 Алгоритм и методика анализа модели бизнес-логики

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

Алгоритм объединения сущности со стандартным классом, проиллюстрирован на рисунке 2.4, он основан на идентификации шаблонов отношений. Шаблон отношений определяет набор общих архитектурных взаимодействий, которые обычно существуют между стандартным классом и классам определенной предметной области приложения. В начале каждая сущность считается возможным решением для ассоциации (A). Когда паттерн стандартного класса идентифицируется для сущности (1), он считается допустимым решением для ассоциации (B). Если для паттерна (или паттернов) не выполняется сопоставление, стандартный класс игнорируется, полагаем, что он не представлен в модели.

Рисунок 2.4 – Алгоритм ассоциации сущности и стандартного класса

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

entity (E).

relation (R, F, T, L, U).

Данное утверждение указывает на существование взаимосвязи между двумя объектами: R (Relation) - название отношения; F (From) начальная сущность; T (To) конечная сущность; L (LowBorder) нижняя граница и U (UpperBorder) верхняя граница количества элементов T в отношении.

ecommerce_address_pattern (A): -

entity (A), % Сущность Адрес

relation (_R, U, A, _M, _N), % У пользователя есть адрес

has_at_least (O, A, 1) % У заказа есть минимум 1 адрес

Пример описания правила для шаблона стандартного класса Address предметной области «Электронная коммерция». Класс пользователь U (User) должен иметь адреса, класс заказ O (Order) должен иметь по крайней мере один адрес A (Address).

2.5 Модель контентно-навигационной карты интерфейса веб-приложения

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

Навигация будет отображаться как переходы между представлениями. В соответствии со спецификаций методологии UML было предложено адаптировать диаграмму состояний следующим образом:

Состояние. Представляет собой страницу, компонент, секцию или режим отображения сущности. Типы, связанные с этим компонентом, различаются по их идентификаторам или их расположению на диаграмме. Если состояние принадлежит к области другого состояния, оно представляет собой раздел страницы, как показано на рисунке 2.5. Компоненты обозначаются символом «_», режимы отображения сущностей обозначаются символами «<» и «>», как показано на рисунке 2.5 соответственно в 3) и 4). [АШ47] Остальные состояния обозначают представления. У состояний есть атрибуты для представления вспомогательной информации, описание атрибутов приведено в таблице 4.1[АШ48].

Конечное состояние. Выход из-за определенного состояния, как показано на рисунке 2.5 5). Это означает, что переход будет осуществлен только в том случае, если состояние, в котором происходит переход, не соответствует ни одному из идентификаторов, присутствующих в этом состоянии.

Начальное состояние. Начальное состояние указывает стартовую страницу пользовательского интерфейса, как показано на рисунке 2.5 6). Обычно это первое представлением, с которым пользователь взаимодействует во время выполнения приложения.

Переход. Переход указывает переход или замену, или композицию в зависимости от целевого элемента, как показано на рисунке 2.5. 7). Переход на страницу представляет собой изменение страницы. Переход на компонент представляет собой замену содержимого целевого элемента. При переходе в режим отображения происходит композиция компонентов.

Условие. Условие содержит идентификаторы, участвующие в переходе, как показано на рисунке 2.5 8). Используется только для дополнения конечного состояния.

Рисунок 2.5 - Фрагмент модели контентно-навигационной карты

Таблица 4.1 – описание атрибутов контентно-навигационной карты

Название	Состояние	Описание
link	компонент/представление	Указывает относительный путь ссылки
repeat	компонент/представление	Указывает количество повторений
order	компонент/представление	Указывает очередь состояния в интерфейсе
redirect	компонент/представление	Это указывает на переход на определенный элемент
name	представление	Указывает название представления
template	представление	Указывает шаблон представления
display	отображение	Указывает название режима отображения
type	отображение	Указывает тип режима отображения

2.6 Алгоритм генерации финального пользовательского интерфейса

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

Шаг 1. Преобразование диаграммы классов в ecore метамодель для дальнейшей обработки.

Шаг 2. Сопоставление сущностей предметной области со стандартным классом в соответствии с алгоритмом, описанным в разделе 2.4. Результат данного шага – маппинг стандартных классов и классов предметной области.

Шаг 3. На основании информации о конфигурации внешнего дизайна обновляются все файлы стилей препроцессора CSS, отвечающие за дизайн компонентов интерфейса, в соответствии с пожеланием пользователя ИС. Шаг не является обязательным.

Шаг 4. В соответствии с Y-предметной областью [АШ49] и маппингом, полученном на шаге 2, строится модель контентно-навигационной карты, по правилам, которые описаны в разделе 2.5. На основании данной модели определяется содержание интерфейса веб-приложения, представления, которые будут сгенерированы, а также взаимодействия между представлениями и компонентами сайта.

Шаг 5. На данном шаге происходит формирование расположения блоков относительно друг друга, настройка видимости тех или иных компонентов интерфейса веб-приложения. Если данный шаг не выполняется, то отображение и расположение будет сформировано на основании шаблона по умолчанию.

Шаг 6. Генерация финального пользовательского интерфейса на основании результатов, полученных на шагах 1-5 представленного алгоритма.

Выводы по главе

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

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

- подход

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

- алгоритм и методика анализа модели бизнес-логики;

- модельно контентно-навигационной карты интерфейса веб-приложения;

- алгоритм генерации финального пользовательского интерфейса.

 

 

Глава 3. Проектирование и реализация программной системы генерации пользовательских веб-интерфейсов

3.1 Проектирование системы генерации пользовательских интерфейсов веб-приложений

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

На рисунке 3.1 представлена архитектура программной системы проектирования пользовательских интерфейсов веб-приложений. Архитектура ИС будет состоять из 6 модулей: обработчик Ecore модели, идентификатор стандартных классов, настройка CSS-фреймворка, интерпретатор контента и навигационной карты, генератор промежуточных компонентов пользовательского интерфейса, генератор финального пользовательского интерфейса. Каждый модуль представлен цифрами с метками, отображающими потоки взаимодействия.

Рисунок 3.1 – Архитектура ИС

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

Первым модулем является обработчик Ecore модели (рисунок 3.1-1), он отвечает за валидацию модели бизнес-логики и извлечение данных об объектах.

Второй модуль - это идентификатор стандартных классов (рисунок 3.1 - 2), модуль отвечает за сопоставление сущностей бизнес-модели предметной области со стандартными классами с помощью a) шаблонов отношений и b) баз данных семантических знаний, для идентификации соответствующих сущностей предметной области.

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

Четвертый модуль – интерпретатор контента и навигационной карты (рисунок 3.1 - 4) отвечает за извлечение схемы пользовательского интерфейса из c) абстрактной модели интерфейса для заданной предметной области.

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

Шестой модуль – генератор финального пользовательского интерфейса, отвечает за формирование конечного пользовательского интерфейса.

3.2 Разработка системы генерации пользовательских интерфейсов веб-приложений

Конечный результат должен представлять собой плагин для IDE Eclipse, соответственно средой разработки была выбрана IDE Eclipse.

Языки программирования: Java, Prolog, HTML, CSS.

Функциональные требования к системе представлены в виде диаграммы вариантов использования (рисунок 3.2).

Рисунок 3.2 – Диаграмма вариантов использования системы автоматической генерации пользовательских интерфейсов веб-приложений

Объектно-ориентированный подход. Для представления структуры модели системы в терминологии классов объектно-ориентированного программирования построены диаграммы классов основных функциональных модулей. Диаграмма классов UML модуля «Обработчик Ecore» представлена на рисунке 3.3.

Рисунок 3.3- Диаграмма классов UML обработки модели ecore [АШ50]

Диаграммы классов UML модулей «Настройщик CSS фреймворка» и «Идентификатор стандартных классов» представлены на рисунках 3.4. и 3.5 соответственно.

Рисунок 3.4 - Диаграмма классов процесса определения стиля интерфейса

Рисунок 3.5. - Диаграмма классов процесса ассоциации стандартных классов

Шаги работы с системой генерации пользовательских интерфейсов веб приложений:[АШ51]

Первым шагом является построение или импорт диаграммы классов с помощью инструмента Ecore Tool. После того, как диаграмма классов импортируется (или строится) можно запустить плагин, сначала происходит обработка ecore модели ИС. Если проверка не выполняется, среда IDE открывает документ с соответствующими сообщениями об ошибках (рисунок 3.6), если ошибок не найдено инициализируется главное меню (рисунок 3.7), где пользователь может задать предметную область и настроить внешний дизайн.

Рисунок 3.6 – Пример ошибки при проверке в ecore файле

Предметную область можно выбрать из ранее определенных в главе 1. Также пользователь может выбрать CSS-фреймворк и стиль внешнего веб-дизайна – «Flat» - плоский дизайн компонентов или «Gradient» - веб-компоненты будут иметь градиентную заливку. Также у пользователя есть возможность выбора адаптивного интерфейса. В ввиду ограниченного времени на разработку цветовая схема была задана по умолчанию без возможности выбора, однако в соответствии с описанной архитектурой и модулем «Настройщик CSS-фреймворка», решение можно масштабировать и добавить функционал по выбору цветовой схемы.

Рисунок 3.7 – Главное меню ИС для выбора предметной области и настроек внешнего дизайна

Если же фреймворк не был выбран, то будет сгенерирован промежуточный результат (рисунок 3.8).

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

Также для каждого стандартного класса доступен список настраиваемых атрибутов на рисунке 3.9b представлен набор атрибутов для класса «Адрес». Поиск соответствий атрибутов происходит по аналогии с классами.

 

Рисунок 3.8 – Пример промежуточного результата генерации пользовательского веб-интерфейса на основе моделей

Рисунок 3.9 – Сопоставление ассоциаций стандартных классов (а, слева) и атрибутов (b, справа)

Третий шаг - настройка контента и навигационной карты. Инструмент ставит в соответствие подходящий контент и навигационную карту в зависимости от предметной области приложения и выполняет базовую интерпретацию. Окно настроек представлено на рисунке 3.10. Оно представляет собой название шаблона, а также диаграмму для обобщения ее содержимого. На диаграмме перечислены представления, которые будут сгенерированы: Домашняя страница (Homepage), Категория, Продукт, Вход, Регистрация, Корзина, Выход, Настройки, Мои адреса, Мои заказы, Мой профиль, FAQ, О нас, Контакты. Это помогает пользователю получить краткий обзор контента и навигационной карты, используемой для создания пользовательского интерфейса. При желании пользователь может изменить модель интерфейса с помощью кнопки «Обновление», которая запускает открытие графического редактора, предоставленного IDE.

Рисунок 3.10 – Управление контентом и навигацией

Финальным шагом эксперимента является настройка расположения элементов и блоков относительно друг друга для каждого представления. По умолчанию все элементы расположены согласно шаблону, который был выбран по умолчанию. Текущая реализация позволяет сделать видимым или невидимым каждый блок в представлении, однако возможность изменения расположения отсутствует. (Рисунок 3.11)

После того, как конфигурация макетов завершена, конечный пользовательский интерфейс построен.

Папка проекта создается в корневом каталоге проекта Ecore Tools и затем открывается через файловый менеджер операционной системы.

Рисунок 3.11 – Управление расположением блоков в представлении

В этой папке хранится финальный пользовательский интерфейс, стоящий из:

· «layouts» - папка, которая содержит файлы расположения элементов и блоков в формате HTML

· «partials» - папка, которая содержит partial файлы в формате HTML

· «views» - папка, которая содержит файлы представлений в формате HTML

· «src» - папка, которая содержит файлы фронтэнд фреймворка.

Представление «Домашняя страница» финального пользовательского интерфейса изображено на рисунке 3.12

Рисунок 3.12 – Пример представления «Домашняя страница» созданного автоматически системой генерации пользовательских интерфейсов веб-приложений

Выводы к главе

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

 

 

Глава 4. Оценка качества решения, полученного с использованием ИС

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

1) Разработку опросника для проведения юзабилити-тестирования;

2) прохождение опроса контрольной группой лиц;

3) разработку тест-кейсов для проведения юзабилити тестирования;

4) прохождение тест-кейсов одним экспертом;

5) выводы, агрегирование результатов, оценка качества пользовательского интерфейса.