Разработка, управляемая моделями (Модельно-ориентированный инжиниринг, MDE)

В подобном подходе, высокоуровневые модели преобразовываются в низкоуровневые модели с целью преобразованиях их действующую (функционирующую) систему [27]. Адаптация V-модели разработки информационных систем [19] к MDE (разработке, управляемой моделями) изображена на рисунке 1.2[АШ21].

 

Преобразование модели

Функционирую-щая система

Высокоуровне-вые модели

Высоко-уровневые модели

Функциониру- ющая система

 

Рисунок 1.2 - Адаптация V-модели разработки информационных систем к MDE

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

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

Совместимость между системами увеличивается, что позволяет совмещать прошлые, настоящие и будущие технологии [14].

MDE - мощная парадигма с доказанными результатами. Тем не менее, она является мишенью для критиков [14]. У разработчиков, как правило, возникают проблемы с самими моделями. Поскольку определение точного типа моделей, а также количество моделей и детализированность описания [АШ23] может быть сложной задачей. Заранее определенные стандарты помогли бы решить эту проблему. Разработчики будут знать, какие модели нужны для описания проблемы и поиска решения. Тем не менее, для эффективности необходимо гарантировать качество моделей, от более высокого к более низкому уровню. Как показано ранее, качество модели зависит от разработчика. Внедрение автоматизации в процесс трансформации модели будет гарантировать качество промежуточных моделей, поскольку звено разработчик при таком подходе будет отсутствовать, количество несоответствий и ошибок значительно сократиться. Конечный результат будет более качественный, с меньшим количеством ошибок.

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

В сообществе программной инженерии данный подход обычно применяется к созданию бизнес-логики и представлению данных [25][АШ24] приложений.

1.2.2 Разработка пользовательского интерфейса на основе моделей (MBUID)[АШ25]

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

Cameleon Reference Framework широко используется в качестве стандартной архитектуры для MBUID. Он определяет четыре основных уровня моделирования [37].

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

2. Абстрактный пользовательский интерфейс (AUI) - описание пользовательского интерфейса в терминах абстрактных единиц взаимодействия или абстрактных объектах взаимодействия и их соответствующих связей [37]. Абстрактные объекты, [АШ26] позволяют представить пользовательский интерфейс независимо от технологии и методики.

3. Конкретный пользовательский интерфейс (CUI) - описание пользовательского интерфейса в терминах единиц конкретного взаимодействия или конкретных объектов взаимодействия [38], определяющих компоновку и навигацию интерфейса. CUI зависят от методики и описывают стиль оформления пользовательского интерфейса.

4. Final User Interface (FUI) - описание пользовательского интерфейса с точки зрения исходного кода. Исходный код может быть, как в программировании, так и в языке разметки. Выполняемый пользовательский интерфейс может быть интерпретирован или выполнен после компиляции кода.

Подход MBUID нацелен на разработку пользовательских интерфейсов, в которых модель является абстракцией пользовательского интерфейса. Более конкретно, он намерен [АШ27] сократить количество времени и усилий, затраченных на разработку пользовательских интерфейсов, при обеспечении их качества [24]. Тем не менее, пользовательский интерфейс несколько неоднородно развивается во времени и в разных культурах. Его можно интерпретировать по-разному, в зависимости от вычислительных платформ, рабочих сред, конечных пользователей и языков программирования. Пользовательский интерфейс, сгенерированный согласно модели MBUID, как правило, критикуют за неудачный жизненный цикл и слабую поддержку различных платформ и устройств [17]. Возможное решение дополнить подход MBUID ресурсами для различных платформ или устройств, однако проблема качества на этом не заканчивается. Автоматизация имеет тенденцию оказывать негативное влияние на качество пользовательского интерфейса. Балансировка уровня автоматизации с вмешательством разработчика может способствовать итеративному уточнению интерфейса, тем самым улучшая качество созданного пользовательского интерфейса.

MBUID - это аналогичная MDE методология, направленная на автоматизацию создания пользовательских интерфейсов. В MBUID часто используются подробные модели для определения различных аспектов пользовательского интерфейса. Эта зависимость от интерфейсных моделей вносит ограничения в данный подход, поскольку затраты на моделирование значительно возрастают [29].

Средства разработки MBUID

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

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

Чем более автоматизирован процесс, тем меньше времени на него затрачивается. Примером инструментов первого поколения является MECANO [25]. Несмотря на использование моделей интерфейса, другими словами моделей, которые описывают либо интерфейс в целом, либо один или несколько его компонентов, MECANO фокусируется на использовании моделей предметной области в качестве универсальной декларативной модели.

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

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

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

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

Макет пользовательского интерфейса и динамическое поведение создаются на основе модели диалога, диалогового графика и таблиц взаимодействия, модели домена и задачи. Сам процесс генерации состоит из семи этапов и похож на GENIUS [19].

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

В этом случае в виде диаграмм связей сущностей и диалоговых сетей.[АШ28] Тем не менее, модель данных недостаточна для структурирования информации вокруг пользовательских задач. Представления определены,[АШ29] и для каждого представления создается окно с макетом по умолчанию. Эти свойства по умолчанию помогают улучшить согласованность пользовательского интерфейса, ускоряя создание. Это демонстрирует, что обращение к содержимому по умолчанию, созданному из интерпретируемых данных, может оказать общее положительное влияние на созданный пользовательский интерфейс. В конце концов, окончательная компоновка создается с правильным расположением ее различных компонентов.

С течением времени изобретаются новые интерактивные платформы и устройства, что создает новые проблемы в области пользовательских интерфейсов. Третье поколение инструментов MBUID посвящено борьбе с этими ограничениями. TERESA [22] является типичным примером этого поколения. Инструмент использует модели задач высокого уровня для создания пользовательского интерфейса для разных платформ / устройств. Чтобы решить новые проблемы, связанные с необходимостью развертывания приложения на нескольких платформах, спецификация должна обращаться к нескольким платформам использования, зависящим от контекста. Разработчик должен создать и адаптировать модель задачи для различных платформ.

Поскольку TERESA - это ориентированный на веб-приложение инструмент, он может прибегать к внешним технологиям, таким как Javascript и CSS3. Они могут значительно увеличить совместимость между различными устройствами и платформами во время выполнения [36]. Интеграция этих технологий может быть альтернативой спецификации контекста. Инструмент TERESA анализирует отношения задачи, из модели задачи, для создания абстрактного пользовательского. Из абстрактного пользовательского интерфейса и целевой платформы генерируется финальный пользовательский интерфейс. Этот процесс включает целый ряд автоматических решений, от полной до низкой автоматизации. Различные уровни взаимодействия могут позволить применить некоторые весьма значимые изменения.

Четвертое поколение средств MBUID сосредоточено на двух основных проблемах: развитие мультиплатформенной разработки [10] (особого внимание удостоены мобильные устройства) и интеграции с уже существующими веб-службами.

1.3 Предметная область приложения в веб-интерфейсах [АШ30]

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

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

Рисунок 1.2 – Примеры схожих веб-приложений предметной области электронная коммерция

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

В соответствии с данным анализом предлагается классификация на основании предметной области[АШ32]:

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

· Тип «Блог». Веб-приложения, основное содержимое которых — регулярно добавляемые записи, содержащие текст, изображения или мультимедиа.

· Тип «Промо-сайт». Веб-приложения, содержимое которых презентации и реклама определенного продукта, компании и т.п.

· Тип «Электронная коммерция». Веб-приложения, предназначенные для торговли определенным продуктом, группой продуктов или услугами.[АШ33]

1.3.1 Тип «Веб-Форум»

Тип «Веб-форум» - веб-приложение, посвященных онлайн-дискуссиям. Пользователи создают тему с ее последующим обсуждением. Т.е. каждая тема может состоять из множества сообщений, отправленных пользователями. Обсуждение может касаться конкретного предмета или группы предметов, в зависимости от темы. Темы одной тематики объединяются, для удобства в соответствующие Разделы и, таким образом, самая распространённая иерархия веб-форума: Разделы → Темы → сообщения (посты). На рисунке 1.3. представлен пример веб-приложения типа «Веб-форум».

Рисунок 1.3 - веб-приложение с типом «Веб-форум»

1.3.2 Тип «Блог»

Тип «Блог» - веб-приложения[АШ34], основное содержимое, которого - регулярно добавляемые записи, содержащие текст, изображения или мультимедиа, в которых один или несколько пользователей пишут сообщения о своем мнении, о товаре, о политике и т.д. В большинстве случаев приложения, относящиеся к этому типу, позволяют посетителям или подписчикам комментировать опубликованные сообщения [10]. Тип «Блог» аналогичен типу Forum, однако, в отличие от него, он ориентирован на публикацию нового контента. На рисунке 1.4 представлен пример веб-приложения с типом «Блог».

Рисунок 1.4 - веб-приложение с типом «Блог»

1.3.3 Тип «Промо-сайт»

Тип «Промо-сайт», предназначен для презентации или рекламы определенного продукта, услуги или предприятия. Их основная цель - предоставить информацию о продукте клиенту. Большинство этих веб-приложений содержат средства доступа к основным или другим сайтам, связанным с самим продуктом, например, электронным магазином, блогом и другими [10]. В основном они распространяют информацию о продукте, чтобы сформировать приятное впечатление у возможного потребителя, побудить его к покупке или подписке. На рисунке 1.5 представлен пример веб-приложения с типом «Промо-сайт».

Рисунок 1.5 - веб-приложение с типом «Блог»

1.3.4 Тип «Электронная коммерция»

Тип «Электронная коммерция» - веб-приложения, предназначенные для торговли конкретного продукта, группы товаров или услуг через Интернет. Пользователи могут зарегистрироваться для приобретения продуктов. Они могут искать и приобретать товары [10]. В некоторых приложениях пользователям разрешено торговать своей продукцией или услугами.На рисунке 1.6 представлен пример веб-приложения с типом «Электронная коммерция».

Рисунок 1.6 - веб-приложение с типом «Электронная коммерция»

Вывод по главе[АШ35]

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

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

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

 

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