Историки об Елизавете Петровне: Елизавета попала между двумя встречными культурными течениями, воспитывалась среди новых европейских веяний и преданий...
Двойное оплодотворение у цветковых растений: Оплодотворение - это процесс слияния мужской и женской половых клеток с образованием зиготы...
Топ:
Комплексной системы оценки состояния охраны труда на производственном объекте (КСОТ-П): Цели и задачи Комплексной системы оценки состояния охраны труда и определению факторов рисков по охране труда...
Генеалогическое древо Султанов Османской империи: Османские правители, вначале, будучи еще бейлербеями Анатолии, женились на дочерях византийских императоров...
Марксистская теория происхождения государства: По мнению Маркса и Энгельса, в основе развития общества, происходящих в нем изменений лежит...
Интересное:
Подходы к решению темы фильма: Существует три основных типа исторического фильма, имеющих между собой много общего...
Инженерная защита территорий, зданий и сооружений от опасных геологических процессов: Изучение оползневых явлений, оценка устойчивости склонов и проектирование противооползневых сооружений — актуальнейшие задачи, стоящие перед отечественными...
Как мы говорим и как мы слушаем: общение можно сравнить с огромным зонтиком, под которым скрыто все...
Дисциплины:
2017-06-29 | 708 |
5.00
из
|
Заказать работу |
|
|
В процессе проведения анализа существующих решений для автоматической генерации пользовательских интерфейсов веб-приложений не было обнаружено подходов, которые бы полностью удовлетворяли нуждам и отвечали современным стандартам проектирования пользовательских интерфейсов. Предложена модель процесса «КАК-ДОЛЖНО-БЫТЬ», которая является модификацией модельно-ориентированного подхода и основана на алгоритме генерации пользовательских интерфейсов веб-приложений.
В соответствии с исследуемой предметной областью в среде 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] универсального шаблона пользовательского интерфейса, определяющий стандартный интерфейс для каждого типа веб-приложения.
Конфигуратор внешнего дизайна отвечает за улучшение внешнего вида интерфейса, задает общий дизайн пользовательского интерфейса. Однако настройка этого блока является необязательной.
Генератор компонентов пользовательского интерфейса отвечает за создание пользовательского интерфейса веб-приложения. Каждый из компонентов создается на основании описаний, вычисленных интерпретатором данных, в соответствии с настройками конфигуратора внешнего дизайна. Этот блок должен обеспечить гибкость пользовательских интерфейсов, избегая жесткого и повторяющегося автоматического процесса.
|
|
Общие условия выбора системы дренажа: Система дренажа выбирается в зависимости от характера защищаемого...
Поперечные профили набережных и береговой полосы: На городских территориях берегоукрепление проектируют с учетом технических и экономических требований, но особое значение придают эстетическим...
Индивидуальные очистные сооружения: К классу индивидуальных очистных сооружений относят сооружения, пропускная способность которых...
Таксономические единицы (категории) растений: Каждая система классификации состоит из определённых соподчиненных друг другу...
© cyberpedia.su 2017-2024 - Не является автором материалов. Исключительное право сохранено за автором текста.
Если вы не хотите, чтобы данный материал был у нас на сайте, перейдите по ссылке: Нарушение авторских прав. Мы поможем в написании вашей работы!