ГЛАВА 2. ОНТОЛОГИИ ПОЛЬЗОВАТЕЛЬСКОГО ИНТЕРФЕЙСА

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

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

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

Решение указанных проблем может быть найдено в рамках онтологического подхода к автоматизации профессиональной деятельности. Этот подход, в отличие от наиболее распространенных подходов[1] ориентирован на явное определение систем понятий анализируемой предметной области и предназначен для автоматизации деятельности экспертов по построению и модификации целевых объектов заданного класса [66-68] - в данном случае пользовательского интерфейса, с исключением из этого процесса кодировщиков.

Основные этапы данного подхода заключаются в следующем [38,39, 152,153].

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

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

3. Разработка модели проекта пользовательского интерфейса в терминах моделей онтологий. На данном этапе определяется модель проекта пользовательского интерфейса, которая состоит из конкретизаций моделей онтологий пользовательского интерфейса, т.е. проект пользовательского интерфейса описывает конкретные его характеристики: уточняет множество конкретных характеристик и значений терминов онтологий. Таким образом, на основе моделей онтологий можно построить бесконечное множество моделей проектов пользовательского интерфейса.

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

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

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

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

2.2. Системы понятий пользовательского интерфейса

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

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

А. Система понятий пользователя.

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

Систему понятий пользователя можно разделить на две части: систему понятийдиалога и систему понятий задач пользователя.

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

Так, структура системы понятий WIMP-интерфейсов состоит из мно­жества элементов интерфейса. Каждый элемент интерфейса определяется своим типом, множеством параметров, событий и функций. Тип элемента интерфейса определяется его назначением. Основными элементами интер­фейса, предназначенными для группировки элементов интерфейса в семан­тически связанные группы и представленные в виде прямоугольных областей экрана, являются элементы интерфейса типа «окно-контейнер». Элементы интерфейса, предназначенные для операций ввода/вывода данных и вызова команд, принадлежат типу «элемент управления». И, наконец, тип элемента интерфейса «вспомогательный элемент» используется для описания элементов интерфейса предыдущих двух типов, например, «всплывающая подсказка».

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

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

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

Система понятий для формирования текстов.

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

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

Система понятий для формирования текстов не зависит от предметной области и состоит из конструкций двух типов:

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

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

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

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

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

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

- вспомогательный параметр (указывает на параметр, значения которого формируются на основе значений управляющего параметра);

- анонимный параметр (параметр, значения которого не учитываются при формировании текста).

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

Действиями, выполняемыми после анализа результатов прикладной программы, являются:

- выводимое множество, предназначенное для вставки в генерируемый текст множества значений управляющего параметра;

- цикл, предназначенный для формирования повторяющихся фрагмен­тов текста, но при этом при каждом выполнении несколько видоизмененных (изменения и количество выполнений цикла определяются множеством значений управляющего параметра);

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

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

Система понятий графических сцен

Наиболее эффективным средством представления информации являются графические методы её отображения [10,11]. По сравнению с вербально представленными данными, графические методы передачи информации имеют следующие преимущества [12]: «сжатый, редуцированный формат» по сравнению с обширными вербальными описаниями, простота и высокая скорость интерпретации, ликвидация языковых барьеров «интерпретации сообщений».

В литературе выделены основные характеристики представления информации для ее передачи в виде графических сцен[2] [10,11,13,170-172]:

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

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

- часто наличие основного графического объекта, «обозначаемого отдельной лексемой»;

- разделение основного графического объекта на элементарные составляющие;

- наличие дополнительных «атрибутивных образов», уточняющих признаки основного;

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

- наличие «некоторой грамматики составления» сцены.

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

Анализ предметных областей, а также программных средств различного назначения, в которых используются графические образы для передачи входных/выходных данных (медицина, косметология, криминалис­тика, география, астрономия, рыболовство и др.), позволил выделить классы задач (см. Приложение 1) и систему понятий для разработчика интерфейса, в терминах которых описываются графические сцены для данных классов задач [7,30,34,35].

Графическая сцена состоит из следующих элементов:

1. Базовое графическое изображение;

2. Фрагмент:

· Простой фрагмент;

· Составной фрагмент;

3. Наполнение;

4. Количество;

5. Примитив:

· Предопределенный примитив;

· Строящийся примитив.

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

· Имя – уникальный идентификатор базы, термин предметной области, соответствующий названию рисунка, схемы или эскиза, изображенного на базе;

· Образ – графическое изображение;

· Точка отсчета – координата (пара целочисленных значений), задает координаты точки отсчета;

· Масштаб расстояния – отношение величины графических объектов сцены к реальной величине этих объектов (например: 1см:50м);

· Масштаб времени – отношение временных рамок процесса сцены к реальному времени (например: 1с:100с);

· Формат времени – элемент множества {‘ДД.ММ.ГГГГ’, ‘ЧЧ.ММ.СС’}.

Рис.2.1 Пример базового графического изображения

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

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

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

Рис. 2.2. Пример простого фрагмента

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

Рис. 2.3. Пример составного фрагмента, состоящего из двух простых фрагментов «Локализация сверху, 20°» и «Локализация сверху, 20°-50°»

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

· Имя – уникальный идентификатор наполнения, термин предметной облас­ти, соответствующий названию цвета и текстуры, либо значению атрибута изображенного на простом фрагменте или предопределенном примитиве графического объекта, которое он примет после заливки его наполнением;

· Цвет – цвет заливки;

· Текстура – графическое изображение текстуры.

A)

Б)

Рис. 2.4 Пример наполнений

Количество – количество заполненных наполнением фрагментов, а также количество предопределенных примитивов расположенных на фрагменте. Количество позволяет ответить на вопрос “сколько простых фрагментов заполнено определенным наполнением?” и “сколько примитивов находится на простом или составном фрагменте базы?” в терминах предметной области, например “очень мало”, “мало” или “много” (см. рис. 4 в Приложении 1). Количество имеет следующие атрибуты:

· Имя – уникальный идентификатор количества, термин предметной облас­ти, соответствующий ответу на один из поставленных выше вопросов;

· Левая граница – натуральное число, левая граница отрезка на количест­венной прямой. Под количественной прямой понимается числовая прямая, в которой за единицу взят один заполненный простой фрагмент, либо один предопределенный примитив;

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

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

· Имя – уникальный идентификатор примитива, термин предметной области, соответствующий названию графического объекта;

· Маршрут – упорядоченное множество точек на базе, задающее маршрут движения примитива. Описание точки маршрута приведено ниже;

· Параметры маршрута – задает параметры отображения маршрута, такие как цвет, тип и толщина линий маршрута;

· Авто-поворот – логический атрибут, принимающий значение “да” в тех случаях, когда требуется, чтобы изображение графического объекта автоматически поворачивалось при движении примитива в зависимости от направления движения;

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

Каждая точка маршрута имеет следующие атрибуты:

· Координата – координата точки в локальной системе координат, которая задает местоположение точки на базе;

· Выделение маршрута – логический атрибут, принимающий значение “да” в тех случаях, когда требуется, чтобы маршрут на отрезке от данной точки до следующей отображался на базе;

· Скорость – скорость движения примитива в данной точке;

· Дата – дата прохождения примитива через данную точку. Формат даты должен соответствовать формату времени.

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

Предопределенный примитив – это примитив, в котором изображение графического объекта заранее предопределено (см. рис. 2.5). Предопределенный примитив расширяет примитив следующими атрибутами:

· Образ – графическое изображение;

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

· Координата – координата примитива на базе;

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

· Начальный спрайт – спрайт из множества спрайтов простого фрагмента, соответствующий начальной форме графического объекта, изображенного на фрагменте; если начальный спрайт не задан, то в качестве графичес­кого изображения предопределенного примитива используется его образ;

· Множество трансформаций определяет правила, по которым происходит изменение изображения предопределенного примитива. Каждая трансфор­мация имеет свое уникальное имя, соответствующее названию новой формы графического объекта в предметной области, а также угол, на который нужно повернуть изображение предопределенного примитива, смещение координат, которое нужно сделать и масштаб, который нужно применить для достижения результата (образование новой формы графического объекта);

· Множество областей – поименованная область примитива. Когда объект (примитив) при движении по базе пересекает область другого примитива, он изменяет свое изображение или свойства в соответствии с правилами этой области, если такие имеются.

Область примитива имеет следующие атрибуты:

o Фигура – может принимать одно из значений: прямоугольник или круг;

o Условия – одно или несколько условий, состоящих из проверки текущих состояний примитива, попавшего в область другого примитива при движении; проверка производится на соответствие ситуации, при которой должно выполниться определенное действие; под действием понимается изменение свойств и изображения примитивов.

Рис. 2.5 Пример предопределенных примитивов

Вернемся к примеру «Бородинское сражение», рассмотренному в классе объектов «База». Допустим, Бородинское сражение состояло из нескольких этапов. В первом сражении русская армия потеряла 15000 человек, а французская – 10000. Таким образом, графическая сцена включает следующие предопределенные примитивы: русские и французские войска. Опишем эти объекты:

Имя: Русские войска

Маршрут: <[0, 0], [3, 2]>

Параметры маршрута: цвет – «красный», тип линии – «пунктирная», толщина – «1,5пт»

Авто-поворот: «да»

Количественные характеристики: нет

Свойства: «Количество» – Целое неотрицательное

Множество спрайтов: – имя: Спрайт, изображение:

Имя: Французские войска

Маршрут: <[8, 6], [5, 4]>

Параметры маршрута: цвет – «синий», тип линии – «пунктирная», толщина – «1,5пт»

Авто-поворот: «да»

Количественные характеристики: нет

Свойства: «Количество» – Целое неотрицательное

Множество спрайтов: – имя: Спрайт, изображение:

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

Имя: Первое сражение

Область: - см. рис. 2.6

Координата: [105, 152]

Множество спрайтов: – имя: Спрайт 1, изображение:

– имя: Спрайт 2, изображение:

Начальный спрайт:

Свойства: (нет)

Условия: Если (Русские войска и Французские войска), То {Русские войска.Количество = Русские войска.Количество – 15000, Французские войска.Количество = Французские войска.Количество – 10000, Первое сражение.Спрайт = }

Рис. 2.6 Пример описаний примитивов

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

· Цвет линий – цвет линий контура геометрической фигуры;

· Цвет фона – цвет фона геометрической фигуры;

· Фигура – название строящейся геометрической фигуры.

Рис. 2.7 Пример строящегося примитива

На рисунке 2.8 представлены экранные формы, соответствующие трем тип­ам диалога для одной и той же модели системы понятий пользователя. Фрагмент А) соответствует типу диалога, основанному на экранных формах; на Б) приведен фрагмент текста, описывающий те же данные и сформированный с помощью системы понятий для формирования текстов (с использованием элементов WIMP–интерфейсов); В) соответствует типу диалога, основанному на графических сценах (с использованием элементов WIMP–интерфейсов - окон, кнопок); в этом случае заполнение результатов осмотра больного включает формы с изображением схемы полей зрения и множеством условных обозначений, которые наносятся на эти формы и служат результатами осмотра.

А) Б)

В)

Рис. 2.8 Представление информации из раздела медицины «офтальмология» в различных формах

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

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

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

Анализ пользовательских интерфейсов показал, что в любом интерфейсе можно выделить множество стандартных инструкций, которые можно представить в виде функций (каждая функция характеризуется именем, типом возвращаемого значения и множеств параметров). Такие инструкции будем называть стандартными функциями диалога. Их можно разделить на четыре основных класса [48]:

· функции сравнения на равенство (к данному классу относятся операции сравнения на равенство значений различных типов - строковых, целых, вещественных, логических);

· логические функции (к данному классу относятся операции над значениями логического типа);

· математические функции (к данному классу относятся операции над значениями целого и вещественного типа);

· функции преобразования типов данных (к данному классу относятся операции преобразования значений одного типа в значения другого типа).

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

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

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

Информация, в терминах которой осуществляется связь между прикладной программой и пользовательским интерфейсом определяет множество программных интерфейсов, предоставляемых прикладной программой. Каждый программный интерфейс описывает модель взаимодействия с программой (определяется именем модели взаимодействия и множеством параметров), а также список функций, предоставляемых данным интерфейсом (характеризуется типом возвращаемого значения и множеством параметров, также определяемых типом). Множество моделей взаимодействия, определенное в работе, состоит из локальной и распределенной модели взаимодействия. Локальная – это модель взаимодействия, при которой интерфейс и прикладная программа находятся на одном компьютере, являются частями одного и того же программного средства, и взаимодействуют между собой посредством локальных вызовов. Распределённая – это модель взаимодействия, при которой интерфейс и прикладная программа находятся на разных компьютерах и взаимодействуют между собой посредством сетевых вызовов, используемый при этом протокол зависит от реализации.

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

- система понятий пользователя;

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

- система понятий сценария диалога;

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

2.3. Модели онтологий пользовательского интерфейса

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

Поиск по сайту: