Расширяемый инструментарий для разработки пользовательского интерфейса, основанный на методах искусственного интеллекта

Размещено на http://www.allbest.ru/

Расширяемый инструментарий для разработки пользовательского интерфейса, основанный на методах искусственного интеллекта

Существующий инструментарий для разработки интерфейса (Построители интерфейса, Системы управления пользовательским интерфейсом, Моделеориентированные средства для разработки интерфейса) не отвечает в полной мере указанным требованиям. Анализ инструментария с точки зрения требований представлен в работе [Грибова, 2005a. Так, ни одно из указанных средств не имеет специальных средств для расширения инструментария. Именно эта причина, как отмечается, например, в [Puerta, 1996, «тормозит» развитие современных инструментальных средств для разработки пользовательских интерфейсов. Для создания инструментария, удовлетворяющего всем перечисленным выше требованиям, предложен новый подход к разработке пользовательского интерфейса на основе онтологий [Gribova et al., 2003 .

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

1. Основные положения концепции разработки пользовательского интерфейса на основе онтологий

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

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

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

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

3. Система понятий для определения сценарий диалога. Она определяет абстрактные термины для описания реакций на события (наборы действий, выполняемых при возникновении событий, источники событий, вид режимов переходов между окнами, способы выбора экземпляров окна и др.).

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

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

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

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

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

Для обеспечения расширяемости средств проектирования предлагается:

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

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

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

Онтология - явное описание концептуализации. Она может иметь различные формы, но обязательно включает словарь терминов, спецификацию их смысла, а также описание связей между терминами [Uschold, 1998 . В работах [Грибова, 2005b, [Gribova, 2004, [Gribova, 2006 описаны модели онтологий, по которым формируется модель пользовательского интерфейса.

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

Рис. 1 Базовая архитектура инструментального комплекса для разработки интерфейса и сопровождения инструментария

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

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

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

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

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

Для обеспечения расширяемости средств оценивания предлагается:

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

- на основе онтологии сформировать базу знаний о дефектах интерфейса, связав ее с одним или несколькими элементами ОГПИ (в зависимости от правила вычисления дефекта);

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

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

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

Рис. 2 Обобщенная архитектура системы оценивания интерфейса

Онтология дефектов состоит из следующих основных компонентов.

1.Название дефекта (симптом, что наблюдается).

2.Тип дефекта: дефект элемента представления или дефект композиции (отложенный дефект). Если дефект обнаруживается в процессе проектирования интерфейсного элемента, то такой дефект называется дефектом представления. Если дефект обнаруживается после проектирования совокупности фрагментов интерфейса, то такой дефект называется дефектом композиции.

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

4. Суперкласс - имя класса-родителя. Суперкласс - также метатермин ОГПИ.

5. Параметр(ы) - параметры, которые обнаруживают дефект. Названия параметров совпадают с соответствующими названиями параметров класса интерфейсного элемента из ОГПИ.

6. Метод обнаружения - вычисление дефекта.

7. Критика, совет - сообщение, выдаваемое пользователю.

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

4. Опыт использования инструментального средства для разработки пользовательских интерфейсов

пользовательский интерфейс онтология

В настоящее время в отделе Интеллектуальных систем Института автоматики и процессов управления ДВО РАН разработан прототип инструментального средства, ведутся работы по его опытной эксплуатации.

Одним из применений данного средства является разработка пользовательского интерфейса для Системы интеллектуальной поддержки обследования больных для врача уролога. Назначение системы - обеспечить интеллектуальную поддержку врачу-урологу при формировании и ведении историй болезни, а также организовать компьютерный архив историй болезни, предназначенный для статистической обработки и создания отчетов. История болезни формируется на основе модели предметной области (базы наблюдений) в области урологии [Нагорный, 2002a, [Нагорный, 2002b. База наблюдений содержит более 500 терминов и около 3000 вариантов значений. База наблюдений подвержена частым изменениям - вводятся новые термины, изменяются существующие, перерабатывается структура модели предметной области. Эти изменения требуют модификации интерфейса, поэтому разработка пользовательского интерфейса для данного программного средства с помощью традиционных средств является крайне трудоёмкой и затратной. Применение инструментального средства, представленного в данной работе, позволило значительно сократить трудоемкость разработки и упростить последующее сопровождение интерфейса системы, при этом максимально вовлечь экспертов предметной области в процесс разработки и сопровождения пользовательского интерфейса.

Список литературы