Модели процессов «как-есть» и «как-должно-быть»

В процессе проведения анализа существующих решений для автоматической генерации пользовательских интерфейсов веб-приложений не было обнаружено подходов, которые бы полностью удовлетворяли нуждам и отвечали современным стандартам проектирования пользовательских интерфейсов. Предложена модель процесса «КАК-ДОЛЖНО-БЫТЬ», которая является модификацией модельно-ориентированного подхода и основана на алгоритме генерации пользовательских интерфейсов веб-приложений.

В соответствии с исследуемой предметной областью в среде Bpwin создана модель процессов [8] модельно-ориентированного подхода (МОП) к автоматизации проектирования пользовательского интерфейса.

[АШ36]

Рисунок 2.1 – Модель процесса «КАК-ЕСТЬ» (декомпозиция)

На рисунке 2.1 представлена декомпозированная, т.е. разделенная на подфункции, модель подхода «КАК_ЕСТЬ». Подход представлен совокупностью действий (подфункций), а именно: обработка Ecore модели, поиск соответствий стандартных классов и классов модели, формирование абстрактного пользовательского интерфейса. классификация тональности, отображение результатов. Входными данными является диаграмма классов UML и конфигурация внешнего дизайна, заданная пользователем. Выходными является конечный пользовательский интерфейс.[АШ37]

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

Основные недостатки подхода «КАК-ЕСТЬ»:

1) Отсутствуют расширяемые правила извлечения данных из Ecore модели.

2) «Жесткая» привязка качества интрфейса[АШ38] веб-приложения к качеству модели, поскольку отсутствует возможность на этапе генерации редактировать классы, идентифицировать стандартные классы и классы моделей вручную, сопоставление происходит без участия действия пользователя.

3) Отсутствие возможности настройки правил и/или расширяемого словаря для поиска ассоциаций между стандартными классами и классами модели.

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

5) Отсутствует возможность изменять настройки содержания, расположения и/или отображения компонентов и представлений. Что означает «шаблонизацию» пользовательского интерфейса.

Исключив недостатки и сохранив плюсы, предложен следующий подход (рисунок 2.2):

[АШ40]

Рисунок 2.2 – Модель процесса «КАК-ДОЛЖНО-БЫТЬ» (декомпозиция)

Предложенный подход автоматизации проектирования и разработки пользовательского интерфейса представлен следующей совокупностью подсистем: извлечение данных из метамодели Ecore, настройка внешнего дизайна, настройка карты контента и навигации, генерация промежуточных компонентов интерфейса-веб приложения. Входными данными являются диаграмма классов UML, предметная область веб-приложения, и конфигурация внешнего дизайна, заданная пользователем. Выходными является конечный пользовательский интерфейс[АШ41].

Основные преимущества подхода:

1) Возможность автоматической генерации интерфейса веб-приложений.

2) Пользователь может управлять процессом генерации интерфейса.

3) Пользователю доступно изменение набора классов исходной модели.

4) Поиск ассоциаций стандартного класса и классов метамодели управляется набором правил и словарем синонимов, который можно расширить.

5) Можно настраивать отображение каждого компонента, расположение блоков между собой, содержание.

6) Генерирование индивидуального интерфейса, соответствующего своей предметной области.

2.2 Концептуальная модель

Концептуальную модель предложенного подхода можеть[АШ42] быть представлена следующим образом (рисунок 2.3).

Для запуска процесса необходимы следующие входные данные:

1) Спецификации предметной области.

2) Модель бизнес-логики, представленная в виде UML диаграммы классов[АШ43].

3) Информация о конфигурации внешнего дизайна.

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

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

Интерпретатор данных отвечает за извлечение всей необходимой информации из входных данных, состоит[АШ44] из двух модулей. Одним из модулей является анализатор модели бизнес-логики, другим модулем является вывод[АШ45] универсального шаблона пользовательского интерфейса, определяющий стандартный интерфейс для каждого типа веб-приложения.

Конфигуратор внешнего дизайна отвечает за улучшение внешнего вида интерфейса, задает общий дизайн пользовательского интерфейса. Однако настройка этого блока является необязательной.

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