Содержание к диссертации
Введение
ГЛАВА 1. Пользовательский интерфейс и инструментальные средства для его разработки. обзор литературы 14
1.1. Пользовательский интерфейс. Основные понятия 14
1.2. Жизненный цикл разработки пользовательского интерфейса 16
1.3. Современные парадигмы автоматизации разработки пользовательского интерфейса 20
1.3.1. Дизайнерская парадигма автоматизации разработки пользовательского интерфейса 20
1.3.2. Моделеориентированная парадигма автоматизации разработки пользовательского интерфейса 23
1.4. Критика современных инструментальных средств и парадигм разработки пользовательского интерфейса 35
1.5. Обеспечение качества пользовательского интерфейса 36
1.6. Выводы из обзора 48
ГЛАВА 2. Онтологии пользовательского интерфейса 52
2.1. Онтологический подход к автоматизации профессиональной деятельности 52
2.2. Системы понятий пользовательского интерфейса 55
2.3. Модели онтологии пользовательского интерфейса 76
2.3.1. Модель онтологии пользователя 76
2.3.2. Модели онтологии для представления информации 79
2.3.3. Модель онтологии сценария диалога 91
2.3.4. Модель онтологии связи интерфейса с прикладной программой 94
2.4. Обсуждение 96
ГЛАВА 3. Проект пользовательского интерфейса 98
3.1. Проект пользовательского интерфейса. Определение и компоненты 98
3.2. Формальное описание проекта интерфейса 118
3.3. Обсуждение 132
ГЛАВА 4. Модель генерации программного кода пользовательского интерфейса и контекстно зависимой помощи по его проекту 13 5
4.1. Общий подход к автоматической генерации программного кода пользовательского интерфейса по его проекту 135
4.2. Структура программного кода пользовательского интерфейса 137
4.3. Модель генерации кода 148
4.4. Генерация контекстно-зависимой помощи 184
4.5. Обсуждение 189
ГЛАВА 5. Обеспечение качества пользовательского интерфейса 190
5.1. Поддержка качества процесса проектирования пользовательского интерфейса 190
5.2. Оценивание интерфейса 201
5.4. Обсуждение 202
ГЛАВА 6. Методы реализаідпи интегрированного инструментального комплекса для разработки, сопровождения и автоматической генерации пользовательского интерфейса 205
6.1. Требования к интегрированному инструментальному комплексу 205
6.2. Архитектура инструментального комплекса для разработки пользовательского интерфейса 206
6.3 Методы реализации инструментального комплекса для разработки и автоматической генерации пользовательского интерфейса 213
6.4. Соответствие инструментального комплекса требованиям 242
6.5. Обсуждение 246
ГЛАВА 7. Технология разработки пользовательского интерфейса с помощью интегрированного инструментального комплекса и ее экспериментальное исследование 250
7Л. Технология разработки пользовательского интерфейса 250
7.2. Технология сопровождения инструментария разработчика 264
7.3. Экспериментальное исследование интегрированного инструментального комплекса 271
7.4. Обсуждение 279
Основные результаты и выводы 281
Глоссарий 285
Список литературы
- Дизайнерская парадигма автоматизации разработки пользовательского интерфейса
- Модели онтологии пользовательского интерфейса
- Структура программного кода пользовательского интерфейса
- Архитектура инструментального комплекса для разработки пользовательского интерфейса
Введение к работе
Актуальность проблемы. Пользовательский интерфейс является неотъемлемой составляющей подавляющего большинства программных средств Как правило, пользователи судят о программном средстве в целом и «пригодности» его к использованию по тому, насколько удобен пользовательский интерфейс и в какой мере он отвечает их требованиям При этом требования пользователей весьма разнообразны и определяются как личными предпочтениями и особыми запросами, так и назначением интерфейсов, особенностями представления информации в различных предметных областях, условиями и средой использования Эти факторы требуют создания интерфейсов для различных платформ с поддержкой множества типов диалогов (основанных на экранных формах или WIMP'-интерфейсах, текстах, графических образах, речи, с использованием различных цветовых схем, анимации и мн др ) При этом важным критерием является их качество В результате проектирование, разработка, модифицирование и сопровождение пользовательского интерфейса оказываются чрезвычайно сложными и связаны со значительными затратами времени, поскольку требуют учета множества факторов, тесно взаимосвязанных между собой и зачастую противоречащих друг другу По оценкам различных специалистов на пользовательский интерфейс уходит не менее половины времени, требуемого на разработку программного средства
В связи с вышесказанным актуальными являются исследования, направленные на решение проблем уменьшения трудоемкости проектирования, прототипирования, реализации и сопровождения пользовательского интерфейса, с поддержкой различных типов диалога, и обеспечения качества его разработки -юзабилити (usability) Большой вклад в решение указанных проблем внесли российские и зарубежные ученые Т А Гаврилова, О Л Перевозчикова, Э В Попов, П И Соснин, В Ф Хорошевский, Р Castells, J Foley, М Ivory, С Janssen, J Lowgren, В Myers, A Puerta, G Singh, P Sukavinya, P Szekely и многие другие На основе современных достижений в данной области сформировались две основные парадигмы автоматизации разработки пользовательского интерфейса дизайнерская и моделеориентированная
В рамках дизайнерской парадигмы разработаны методы высокоуровневого проектирования визуального представления пользовательских WIMP-интерфейсов (основанных на экранных формах) и автоматической генерации кода на некоторый язык программирования (Pascal, С#, C++, Java и др) для визуального представления Проектирование интерфейса, основанного на дизайнерской парадигме, осуществляется с помощью Построителей интерфейсов (Interface
' Windows, Icons, Menus, Pointing devices
Концепция разработки пользовательских интерфейсов, ориентированная на максимальное психологическое и эстетическое удобство для пользователя
4 Builder), входящих в состав интегрированных пакетов и CASE-средств Данные средства используют специализированные редакторы, основанные на технологии WYSIWYG3, значительно снижающие трудоемкость проектирования визуального компонента пользовательского интерфейса Они легки в применении, особенно для построения простых интерфейсов
В рамках моделеориентированной парадигмы разработаны методы раздельного проектирования и реализации интерфейса и прикладной программы, предложен принцип замены проектирования и сопровождения интерфейса проектированием и сопровождением его модели, разработаны методы автоматической генерации кода пользовательского интерфейса по его модели и связывания этого кода с прикладной программой
Проектирование интерфейса, основанного на моделеориентированной парадигме, осуществляется с помощью моделеориентированных средств (Model-Based Interface Development Environment) Mastermind, Mecano, ITS, Tellach и др Основным информационным компонентом моделеориентированной системы (МОС) является модель интерфейса, которая разбивается на несколько составляющих Некоторые МОС являются интегрированными комплексами и включают в свой состав не только средства проектирования и реализации пользовательского интерфейса, но и средства создания помощи и оценки качества интерфейса
Однако каждая парадигма имеет ряд нерешенных проблем Так, дизайнерская парадигма поддерживает проектирование и автоматическую генерацию только визуального компонента пользовательского интерфейса, в результате проектирование, реализация и сопровождение других компонентов остается трудоемким, обеспечивает поддержку только одного типа диалога, не поддерживает обеспечение качества интерфейса (юзабилити) и создание помощи пользователю Для оценки качества интерфейсов, разработанных с помощью Построителей интерфейса, используют либо методы неавтоматизированного оценивания (аналитическое, экспертное, оценивание на основе опыта и исследования), либо независимые от среды разработки средства автоматизированного оценивания интерфейса (верификация характеристик юзабилити, моделирование деятельности конечных пользователей, результирующее оценивание) Этот процесс является трудоемким даже в случае автоматизированного оценивания из-за сложности формирования информации, необходимой таким системам Средства помощи конечному пользователю интерфейса (помощь является важным критерием его юзабилити) также реализуются сторонним инструментарием (например, с помощью Microsoft Winhelp, Microsoft Compressed HTML Help, HTML Help 2 0, AP Help 1 0 и др ) Она, как правило, является контекстно-независимой, а ее создание и сопровождение является очень дорогой и трудоемкой задачей (при изменении программного средства необходимо модифицировать и систему помощи)
3 What You See Is What You Get
В моделеориентированной парадигме также остались нерешенными ряд проблем и в настоящее время она не получила широкого практического применения Основная причина - сложность инструментария, основанного на данной парадигме, из-за чего он устаревает уже к моменту выхода на рынок, во многих МОС от разработчика требуется знание различных специализированных языков (что значительно увеличивает трудоемкость разработки), а также поддерживается только один тип диалога Для автоматизации оценивания юзабилити в некоторых МОС применяются средства автоматизации дизайна, «советники разработчика», «критики дизайна», средства поддержки разработки контекстно-зависимой помощи Однако, их «встроенность» в инструментальные средства, затрудняет расширение таких средств и приводит к быстрому устареванию
Таким образом, анализ парадигм автоматизации разработки и сопровождения интерфейсов, оценивания их юзабилити и генерации помощи вьивил ряд нерешенных проблем, главными из которых являются поддержка только одного типа диалога, жесткая встроенность компонентов инструментария в его код, что затрудняет расширение инструментария в процессе жизненного цикла, трудоемкость разработки и сопровождения интерфейса (в Построителях интерфейса обеспечивается поддержка разработки и сопровождения только одного компонента интерфейса, в МОС требуется либо изучение специализированного языка, либо нескольких формализмов для проектирования модели интерфейса) Это определяет актуальность теоретических и прикладных исследований диссертации, направленных на решение крупной научной и практической проблемы автоматизации разработки и сопровождения пользовательских интерфейсов
Целью диссертационной работы является разработка концепции, моделей, методов и интегрированного инструментария для проектирования, реализации и сопровождения пользовательских интерфейсов с поддержкой нескольких типов диалога, обеспечением качества интерфейса, а также механизмов сопровождения самого интегрированного инструментария
Для достижения указанной цели в работе используются методы искусственного интеллекта и онтологический подход к автоматизации профессиональной деятельности В соответствии с целью диссертационной работы поставлены следующие задачи исследования
Разработка концепции автоматизации проектирования, реализации и сопровождения пользовательского интерфейса на основе онтологического подхода
Разработка моделей онтологии пользовательского интерфейса для каждой группы специалистов, осуществляющих его проектирование, реализацию и сопровождение
Разработка формальной модели проекта пользовательского интерфейса на основе моделей онтологии
Разработка формальной модели генерации программного кода пользо-
вательского интерфейса и контекстно-зависимой помощи по модели его проекта
Разработка методов обеспечения качества пользовательского интерфейса, использующих базы знаний
Разработка методов реализации расширяемого интегрированного инструментального комплекса для проектирования интерфейса, сопровождения проекта, обеспечения его качества, автоматической генерации по проекту кода пользовательского интерфейса и контекстно-зависимой помощи, а также содержащего механизмы сопровождения самого комплекса
Разработка технологии проектирования и сопровождения пользовательского интерфейса с использованием интегрированного инструментального комплекса и ее экспериментальное исследование
Методы исследования. Проводимые в работе теоретические и практические исследования базируются на методах искусственного интеллекта, теории графов, теории множеств, теории формальных языков и порождающих грамматик, технологии программирования
Научная новизна работы. В результате проведенных исследований разработаны
концепция автоматизации проектирования, реализации и сопровождения пользовательского интерфейса, основанная на онтологическом подходе и являющаяся дальнейшим развитием моделеориентированной парадигмы,
модели онтологии пользовательского интерфейса, соответствующие системам понятий специалистов, участвующих в его разработке, и задачам, которые они решают, не зависящие от языка реализации интерфейса и платформы, поддерживающие разработку интерфейсов, основанных на экранных формах, текстах, графических статических и динамических сценах,
компоненты проекта интерфейса и структура каждого компонента проекта в терминах модели онтологии, информация в которых достаточна для генерации интерфейсов на различные платформы и языки программирования, а также для реализации диалогов, основанных на экранных формах, текстах, статических и динамических сценах, при этом обеспечивается повторное использование компонентов проекта для разработки других интерфейсов,
формальная модель генерации проекта интерфейса в программный код, являющаяся языково- и платформенно-независимой,
методы автоматической генерации расширяемой контекстно-зависимой помощи по проекту интерфейса,
методы обеспечения качества проекта пользовательского интерфейса, поддерживающие его проектирование и оценивание, основанные на использовании расширяемых базы отображений и метрик юзабилити,
механизмы расширения инструментария для проектирования и реализации пользовательского интерфейса, средств его оценивания и генерации контекстно-
7 зависимой помощи, основанные на использовании баз знаний и онтологии
Практическая ценность работы заключается
в разработке расширяемого интегрированного инструментального комплекса для проектирования, реализации, сопровождения пользовательского интерфейса, обеспечивающего поддержку нескольких типов диалога, генерацию контекстно-зависимой помощи, автоматическую генерацию пользовательского интерфейса по его проекту, оценку его юзабилити, а также сопровождения самого комплекса,
в разработке базы метрик юзабилити, как результата систематизации и обобщения рекомендаций по проектированию пользовательского интерфейса,
в использовании разработанного инструментального комплекса для реализации интерфейсов
- программного средства, обеспечивающего мониторинг передвижения
поездов и отображение маршрутов их движения на карте железных дорог РФ
(интерфейс, основанный на графических динамических сценах),
- программного средства для моделирования характеристик, внешнего вида
автомобилей японского производства, оценки полученного результата (интерфейс,
основанный на графических статических сценах и экранных формах),
- Системы интеллектуальной поддержки обследования больных для врача-
уролога (интерфейс, основанный на экранных формах, текстах, система понятий
диалога состоит из 700 терминов и около 5000 вариантов значений),
- экспертной системы для предметной области «Косметология» (интерфейс,
основанный на графических статических сценах),
в использовании разработанного инструментального комплекса в учебном процессе для реализации дипломных и курсовых работ,
в использовании теоретических и практических результатов диссертационной работы при чтении курса лекций по дисциплинам «человеко-машинный интерфейс» и «web-дизайн», а также в учебно-методическом комплексе по данным дисциплинам на факультете математики и компьютерных наук Дальневосточного государственного университета
Обоснование и достоверность полученных результатов. Обоснование и достоверность научных положений, выводов и практических результатов подтверждена результатами экспериментального исследования инструментального средства, а также практическим использованием предложенных в диссертационной работе моделей, методов и алгоритмов
Апробация работы. Основные положения и результаты диссертационной работы докладывались и обсуждались на следующих конференциях и семинарах Вторая Международная научно-техническая конференция "Интерактивные системы проблемы человеко-компьютерного взаимодействия" (Ульяновск, 1997), Шестая Международная конференция "Знание-Диалог-Решение" (Ялта, 1997),
8 Первая Дальневосточная конференция студентов и аспирантов по математическому моделированию (Владивосток, 1997), Региональная естественнонаучная конференция студентов, аспирантов и молодых ученых (Владивосток, 1997), Дальневосточная математическая школа-семинар им акад Е В Золотова (Владивосток, 1997-2007), Международная школа-семинар "Диалог-98" (Казань, 1998), Международная научно-практическая конференция «Компьютерные технологии в науке, производстве, социальных и экономических процессах» (Новочеркасск, 2000), Pacific Asian Conference on Intelligent systems (Korea, 2001), The 10th International Manufacturing Conference (China, 2002), X-International Conference "Knowledge-Dialog-Solution" (Bulgaria, 2003), IX национальная конференция по искусственному интеллекту с международным участием (Тверь, 2004), Интеллектуальные и многопроцессорные системы (Таганрог, 2004), II Международная конференция «Параллельные вычисления и задачи управления» (Москва, 2004), V Международная конференция «Идентификация систем и задачи управления» (Москва, 2005), XI-th International conference "Knowledge-dialog-solution" (Bulgaria, 2005), Первая международная конференция "Системный анализ и информационные технологии" (Пере-славль-Залесский, 2005), Интеллектуальные и многопроцессорные системы-2005 (Таганрог, 2005), Научная сессия МИФИ-2006, X национальная конференция по искусственному интеллекту с международным участием (Обнинск, 2006), Интеллектуальные и многопроцессорные системы-2006 (Таганрог, 2005), III Международная конференция «Параллельные вычисления и задачи управления» (Москва, 2006), IX международная конференция «Интеллектуальные системы и компьютерные науки» (Москва, 2006), Xlll-th International conference "Knowledge-dialog-soluhon" (Bulgaria, 2007), семинары отдела интеллектуальных систем ИАПУ ДВО РАН и базовой кафедры программного обеспечения ЭВМ ДВГУ (1998-2007), семинар Российской ассоциации искусственного интеллекта (2007)
Публикации. Основные результаты диссертации изложены в 41 печатная работа.
Структура и объем работы. Диссертация состоит из введения, семи глав, заключения, списка литературы и шести приложений Основное содержание работы изложено на 308 страницах машинописного текста, содержит 78 рисунков, список использованной литературы из 226 наименований
Личный вклад. Все результаты, составляющие основное содержание диссертации, получены автором самостоятельно В работах [1,6] автором выполнена реализация комплекса и прикладной программы, разработанной на ее основе, в работах [2-4,11,12] выполнено формальное описание моделей, в работах [7-9,15,21,22,28] выделены основные компоненты модели и их состав, выполнены формальные описания моделей, в работе [16] разработана система понятий, мета-онтология, в работах [19,20,23,24,30,33,35,40] выполнены постановки задач, разработаны основные теоретические положения, в работе [37] описана архитектура и основные задачи блока управления разработкой пользовательского интерфейса
Дизайнерская парадигма автоматизации разработки пользовательского интерфейса
В настоящее время общепризнанно, что пользовательский интерфейс имеет большое значение для любого программного средства, поскольку пользователи судят о программном средстве в целом и «пригодности» его к конкретному применению по тому, насколько удобен пользовательский интерфейс и в какой мере он отвечает требованиям конкретного пользователя. Профессионально выполненная разработка пользовательского интерфейса приводит к эффективному использованию заложенной в программном средстве функциональности; уменьшению длительности обучения пользователей; снижению количества ошибок и стоимости сопровождения; уменьшению потерь продуктивности работников при внедрении программного средства; уменьшению расходов на редизайн пользовательского интерфейса по требованию пользователей [79,91,97,127,113].
Вместе с тем, проектирование, разработка, модификация и сопровождение пользовательского интерфейса достаточно сложны и требуют значительных затрат времени, так как необходимо учитывать множество факторов, тесно взаимосвязанных между собой и зачастую противоречащих друг другу. Так, по оценкам специалистов, например, 50% времени, требуемого на разработку программного средства, уходит на пользовательский интерфейс; он занимает в среднем 48% программного кода [180].
В настоящее время существует множество определений пользовательского интерфейса [22,62,75,103], детализирующих различные аспекты взаимодействия пользователя с прикладной программой, его состав, функции и т.п. Однако в любом определении под пользовательским интерфейсом понимается среда, через которую пользователь взаимодействует с прикладной программой.
Взаимодействие пользователя с прикладной программой осуществляется в соответствии с заданным в интерфейсе типом диалога. Тип диалога (структура диалога) определяет форму передачи сообщений в интерфейсе [69,75].
В настоящее время наибольшее распространение получил диалог, основанный на экранных формах, или так называемый WIMP-интерфейс (Windows, Menus, Icons, Pointing Devices). Данный тип диалога основан на представлении сообщений (информации о входных/выходных данных, функциях, интеллектуальной поддержке пользователя) в виде графических компонентов экрана — окнах, меню, кнопках, списках и т. п. Распространение получают и другие типы диалога - основанные на графических сценах, текстах, речи и т. п., или так называемые SILK- интерфейсы (Speech, Image, Language, Knowledge), иногда в литературе их называют post-WIMP-интерфейсы [ 15,62].
Диалог пользователя с прикладной программой осуществляется на основе сценария диалога. Сценарий диалога описывает все возможные состояния диалога и пути перехода из одного состояния в другое.
Основными функциями пользовательского интерфейса являются [75]: ввод исходных данных, вывод результатов работы прикладной программы, интеллектуальная поддержка пользователя во время его работы с программным средством, управление процессами ввода-вывода информации.
Однако, как отмечается в [185,223,225,226], сложность и функцио 16 нальность программных средств за последнее время значительно возросли, и в ряде случаев функцией пользовательского интерфейса является также генерация объяснений результатов работы программного средства, что до недавнего времени было лишь функцией одного из классов программных средств - экспертных систем. При этом формирование содержимого таких объяснений обычно возлагалось на машину логического вывода: объяснение формировалось на основе анализа протокола (трассировки) решения задачи [82,107,220]. В настоящее время генерация объяснений часто возлагается на пользовательский интерфейс.
Жизненный цикл разработки пользовательского интерфейса Процесс разработки пользовательского интерфейса состоит из четырех основных этапов [78]: - сбор и анализ информации от пользователей; - проектирование пользовательского интерфейса; - реализация пользовательского интерфейса; - подтверждение качества пользовательского интерфейса.
Первый этап - сбор и анализ информации, поступающей от пользователей, разбивается на следующие шаги.
Определение профиля пользователей (позволяет разработчикам составить представление о возрасте, образовании, особых запросах и предпочтениях, получить другую необходимую информацию).
Анализ стоящих перед пользователями задач (определение того, что хотят пользователи и каким образом они собираются решать свои задачи).
Сбор требований, предъявляемых пользователями (помогает определить особенности проекта и структуру пользовательского интерфейса). Анализ рабочей среды пользователей (определяет характеристики среды, которые могут оказывать влияние на выполнение пользователями своей работы). Соответствие требований стоящим перед пользователями задачам (проверка требований на реалистичность: насколько они соизмеримы выполняемым задачам, не превышают ли возможности продукта действительным потребностям пользователей). Результатом первого этапа является описание требований к интерфейсу, к функциональности программного средства, которая определяет пользовательский интерфейс в целом. Второй этап — проектирование (спецификация) пользовательского интерфейса. Проектирование пользовательского интерфейса - самый трудоемкий этап жизненного цикла. Он требует значительных затрат времени и ресурсов и состоит из нескольких шагов: Концептуальное проектирование. Концептуальный проект представляет собой обзорную презентацию программного средства и сопровождается как самостоятельный документ или вводная глава спецификации высокоуровневого проекта. Он содержит указание основных функций программного средства и пользовательского интерфейса (общего стиля, ключевых принципов функционирования, организации, структуры и т.п.). Концептуальный проект- это перспективный взгляд на предназначение программного средства. Основная его задача - определить какие функции возлагаются на пользователя, какие на прикладную программу [97].
Высокоуровневое проектирование (высокоуровневая проектная спецификация) — описывает структуру пользовательского интерфейса, основные экраны, их поведение, а также детализированное поведение и возможности программного средства.
Детализированный проект (детализированная проектная спецификация) дополняется описанием возможностей и методов, которые не требовались на предыдущих этапах проектирования. Это могут быть, например, нечасто используемые экраны, детализированные определения полей, специфическая помощь пользователю и специфические сообщения.
Модели онтологии пользовательского интерфейса
Таким образом, системой понятий, в терминах которой дизайнеры интерфейса проектируют его визуальное представление, задают интерфейсные элементы, их расположение на экране, цвет, форму, размер и другие параметры, является система понятий о средствах представления информации; в работе выделены система понятий WIMP-интерфейсов, система понятий для формирования текстов, система понятий графических сцен.
В. Система понятий, связанная со сценарием диалога. Любой диалог пользователя с программным средством ведется в соответствии с некоторым сценарием, который зависит от типа пользователей, их требований, функций прикладной программы и является, соответственно, компонентом пользовательского интерфейса. Сценарий диалога может изменяться в жизненном цикле программного средства в зависимости от типов пользователей и их пожеланий, изменения функций прикладной программы. Его разработку осуществляют, как правило, когнитивные психологи и эргономисты.
Система понятий, связанная со сценарием диалога, определяет множество возможных состояний диалога и действий, которые выполняются в каждом состоянии. Состояние диалога определяется событием, которое возникает в элементе интерфейса. Действия задают последовательность инструкций, которые выполняются в ходе реакции на событие (изменение значений параметров элементов интерфейса, вызов функций, предоставляемых прикладной программой, преобразование входных/выходных данных прикладной программы и др.).
Анализ пользовательских интерфейсов показал, что в любом интерфейсе можно выделить множество стандартных инструкций, которые можно представить в виде функций (каждая функция характеризуется именем, типом возвращаемого значения и множеств параметров). Такие инструкции будем называть стандартными функциями диалога. Их можно разделить на четыре основных класса [48]: функции сравнения на равенство (к данному классу относятся операции сравнения на равенство значений различных типов - строковых, целых, вещественных, логических); логические функции (к данному классу относятся операции над значениями логического типа); математические функции (к данному классу относятся операции над значениями целого и вещественного типа); функции преобразования типов данных (к данному классу относятся операции преобразования значений одного типа в значения другого типа).
При выполнении последовательности инструкций (действий) в некотором состоянии диалога, часто требуется информация, полученная в результате выполнения инструкций в других состояниях диалога. Эта информация передается через переменные различных типов.
Таким образом, системой понятий, в терминах которой описывается поведение интерфейса, является система понятий сценария диалога.
Г. Система понятий для описания связи интерфейса с прикладной программой. При раздельном проектировании интерфейса и прикладной программы интерфейс не имеет доступа к коду прикладной программы. Непосредственное взаимодействие между ними происходит с помощью вспомогательных объектов, которые предоставляют интерфейсу и прикладной программе доступ к функциям друг друга. Эта информация (система понятий) является компонентом модели интерфейса, ее описание осуществляют разработчики прикладной программы.
Информация, в терминах которой осуществляется связь между прикладной программой и пользовательским интерфейсом определяет множество программных интерфейсов, предоставляемых прикладной программой. Каждый программный интерфейс описывает модель взаимодействия с программой (определяется именем модели взаимодействия и множеством параметров), а также список функций, предоставляемых данным интерфейсом (характеризуется типом возвращаемого значения и множеством параметров, также определяемых типом). Множество моделей взаимодействия, определенное в работе, состоит из локальной и распределенной модели взаимодействия. Локальная - это модель взаимодействия, при которой интерфейс и прикладная программа находятся на одном компьютере, являются частями одного и того же программного средства, и взаимодействуют между собой посредством локальных вызовов. Распределённая - это модель взаимодействия, при которой интерфейс и прикладная программа находятся на разных компьютерах и взаимодействуют между собой посредством сетевых вызовов, используемый при этом протокол зависит от реализации.
В пункте 2.2 были представлены системы понятий, в терминах которых ведется проектирование и модификация пользовательского интерфейса. В соответствии со вторым положением онтологического подхода к автоматизации разработки пользовательского интерфейса для каждой системы понятий построим модель онтологии. При описании моделей используется теоретико-множественная нотация.
Модель онтологии пользователя состоит из двух моделей онтологии: модели онтологии системы понятий диалога и модели задач пользователя.
Модель онтологии системы понятий диалога. Модель онтологии системы понятий диалога (ОСПД) описывает структуру терминов системы понятий диалога и виды связей между ними, ОСПД= ИмяСистемыПонятий, ГруппыТерминов , где ИмяСистемыПонятий - имя системы понятий диалога, ГруппыТерминов - множество групп терминов, ГруппыТерми termgroupcount нов= {ГруппаТерминові} =
Каждая группа терминов ГруппаТерминов; характеризуется тройкой, ГруппаТерминові= ИмяГруппьіі, ГруппыТерминов;, Терминьіі , где ИмяГруппы; - имя группы терминов (все имена групп терминов в модели онтологии должны быть различны), ГруппыТерминов; - множество групп терминов внутри данной группы, ГруппыТерминов; = ГруппыТерминов, Термины; - множество терминов внутри данной группы, Термины;= {Термину} а""". Группы терминов предназначены для объединения терминов в концептуально связанные группы.
Каждый термин Термин характеризуется парой, ТермиНу= ИмяТер-минау, ТипЗначениЯу , где ИмяТерминац - имя термина (все имена терминов в модели онтологии должны быть различны), ТипЗначениЯу - тип значения, который может быть составным (т.е. состоящим из множества вложенных терминов), количественным, качественным или строковым, ТипЗначениЯу- є ТипыЗначений, ТипыЗначений = {Составное, Количественное, Качественное, Строковое}, где Составное - составное значение, Количественное -количественное значение, Качественное - качественное значение, Строковое - строковое значение.
Составное значение описывает множество атрибутов, Составное = {Атрибут;} «Ьшесит. Каждый атрибут Атрибут; описывается парой, Атрибут; = ИмяАтрибутаь ТипЗначения; , где ИмяАгрибута; - имя атрибута (в модели онтологии имена всех атрибутов принадлежащих одному и тому же термину/атрибуту должны быть различны, при этом имена атрибутов принадлежащих различным терминам/атрибутам могут совпадать), ТипЗначения; -тип значения атрибута, ТипЗначения; є ТипыЗначений. Атрибуты предназначены для описания существенных, неотъемлемых свойств терминов.
Структура программного кода пользовательского интерфейса
Прямые отображения используются в некоторых МОС следующим образом: значениям параметров интерфейсных элементов присваиваются понятия предметной области либо задачи пользователя из соответствующих компонентов модели интерфейса. Однако при их изменении приходится заново осуществлять компиляцию интерфейса. В данной работе вместо явного присваивания значений параметрам элементов интерфейса указываются ссылки на понятия предметной области либо задачи пользователя, поэтому при их изменении также происходят изменения и в проекте представления, перекомпиляция интерфейса при этом не требуется.
Фрагментарные отображения также используются в некоторых МОС. В этом случае разработчики определяют окно (множество окон) и информацию из модели задач либо предметной области, которая должна быть помещена в каждое окно. Далее автоматически выбираются представления для соответствующей информации. С одной стороны, такой подход уменьшает время разработки модели представления, но с другой стороны, основная проблема, с которой столкнулись разработчики -сложность сопровождения при таком способе формирования модели представления. Известно, что, во-первых, задачи пользователя и объекты предметной области подвержены частым изменениям, во-вторых, любое автоматизированное представление требует последующего «ручного» постредактирования. В случае модифицирования объектов предметной области или задач пользователя все изменения, произведенные постредактированием, теряются. В результате сопровождение становится очень трудоемким. Были предприняты попытки сохранять настройки постредактирования, однако, они не привели к положительному результату, так как не была решена основная проблема: что делать с настройками в случае появления новых объектов или задач, либо удаления существующих. В данной работе так же, как и в случае прямых отображений, вместо явного присваивания значений параметрам элементов интерфейса указываются ссылки на понятия предметной области либо задачи пользователя, при этом отображения производятся в соответствии с метриками юзабилити (см. гл. 5). Вычислимые ссылки используются во многих МОС.
Еще одной проблемой, не указанной в литературе, является трудоемкость формирования и особенно сопровождения Проекта представления для предметной области, система понятий диалога которой доходит до нескольких тысяч. Автор диссертационной работы принимал участие в разработке интерфейсов для таких предметных областей [37,59, 16]. Создание интерфейсов и особенно их сопровождение стандартными средствами крайне трудоемко. Для решения данной проблемы предложен способ отображения, основанный на регулярных ссылках. В МОС такой способ отображения не используется.
Все компоненты проекта интерфейса могут повторно использоваться при проектировании других интерфейсов прикладных программ для решения задач в той же предметной области, но с другой функциональностью (проект системы понятий диалога, задач пользователя), либо в различных предметных областях, имеющих схожую функциональность (проект представления, сценария диалога, связи интерфейса с прикладной программой). В большинстве МОС повторное использование компонентов затруднено, поскольку при формировании модели интерфейса явно определяются значения между компонентами модели.
Принципиальным отличием компонентов проекта интерфейса, предложенных в диссертационной работе, от других средств, является отсутствие в них специфики платформ и языков реализации, что позволяет использовать один проект интерфейса для генерации интерфейсов на различные языки реализации и платформы.
В настоящей главе решается задача разработки формальной модели генерации программного кода пользовательского интерфейса и контекстно-зависимой помощи по его проекту.
Общий подход к автоматической генерации программного кода пользовательского интерфейса по его проекту
Разработка пользовательского интерфейса и прикладной программы, в соответствии с онтологическим подходом (так же, как и в моделеориентиро-ванном), осуществляется раздельно, поэтому программный код (далее код) программного средства состоит из: кода прикладной программы; кода пользовательского интерфейса; кода связи пользовательского интерфейса с прикладной программой.
Код прикладной программы описывает реализацию тех программных интерфейсов (вычисления, анализ, обработку данных и пр., необходимые для решения задач пользователя), с которыми пользовательский интерфейс взаимодействует локально. Данный исходный код предоставляется разработчиком прикладной программы. В случае распределенного взаимодействия, вместо исходного кода разработчик прикладной программы предоставляет данные, необходимые для получения сетевого доступа к реализации прикладной программы.
Код пользовательского интерфейса в общем случае состоит из кода, реализующего диалог, основанный на: экранных формах (WIMP-интерфейс); текстах; графических сценах (статических и динамических).
Архитектура инструментального комплекса для разработки пользовательского интерфейса
Среди множества параметров отношения выделяется основной или управляющий параметр. Его значения вставляются в генерируемый текст, если параметр описывается в конструкции выводимое множество, при этом задается порядок, в котором они помещаются в тексте.
Множество значений управляющего параметра DirectivePar (см. пп. 2.3.3) определяется следующим образом. Пусть S - список всех значений j элемента отношения (выходных данных прикладной программы) с именем NameRel, элементом которого является управляющий параметр.
Если в данном списке имеются какие-либо два элемента с одинаковыми значениями, то вычеркиваем тот из них, порядковый номер которого больше. Выполняем данную процедуру до тех пор, пока в списке не будет ни одной пары одинаковых элементов. Полученный таким образом список назовем множеством значений управляющего параметра DirectivePar, при этом порядок значений управляющего параметра будет соответствовать порядку их следования в результатах прикладной программы. Если в условии Condition (см. пп. 2.3.3.) определено, что значения должны быть упорядочены по алфавиту, то значения из полученного таким образом множества значений DirectivePar упорядочивается по алфавиту. Если Condition задано в виде Condition= valb val2,...,valx , то список значений управляющего параметра DirectivePar формируется следующим образом. Сначала располагаются значения DirectivePar в порядке их следования в Condition, затем располагаются остальные значения данного параметра в порядке их следования в результатах прикладной программы.
Значениями параметров являются значения аргументов отношения с именем NameRel в результатах прикладной программы, порядковые номера параметров отношения из результатов прикладной программы должны соответствовать порядковым номерам параметров, объявленных в OutDatAn - условии анализа результатов. Для каждого значения управляющего
При задании конструкции цикл, мощность множества значений управляющего параметра определяет количество повторений цикла, а также содержание изменяемых частей в теле цикла. Каждому значению управляющего параметра соответствует множество подмножеств значений вспомогательных параметров.
В описании условий анализа определено, что третий параметр отношения является управляющим (назовем его «с»), остальные -вспомогательные (назовем их «а», «в» и «d», соответственно). В этом случае значения управляющего параметра с={С1,С2,СЗ}.
При значении с=С1, дополнительные параметры а, в, d принимают следующие подмножества из множества своих значений а={А1, А2}, в={В1, B3},d={Dl,D2}.
Если один цикл является вложенным в другой цикл, то значения управляющего параметра определяются не только по результатам прикладной программы, но также и в соответствии с множеством значений вспомогательных параметров, которые они получили во внешних циклах (пример формального задания цикла и определение количества его повторений в зависимости от результатов прикладной программы см. примеры в п. 3.2).
Основная конструкция альтернатива служит для того, чтобы сформировать текст в зависимости от условий альтернативы. Если некоторое условие из множества условий истинно, то выполняется вариант, которому соответствует истинное условие. Условиями в описании альтернативы являются: конкретные значения управляющего параметра, либо мощность множества его значений. Правила определения множества значений управляющего параметра соответствуют правилам определения его в конструкциях выводимое множество и цикл. Если альтернатива является вложенной в другие циклы либо альтернативы, то на значения управляющего параметра влияют значения вспомогательных параметров внешних циклов либо альтернатив (см. примеры в п. 3.2.).
Для диалога, основанного на графических сценах, создается проект графических сцен на плоскости. Проект графических сцен на плоскости является конкретизацией онтологии графических статических и динамических сцен на плоскости, которые используются в графическом диалоге для генерации графической сцены (для вывода результатов прикладной программы в виде графических сцен) и/или для распознавания графической сцены и перевода ее в необходимый формат (для ввода исходных данных пользователем).
Проект графических сцен на плоскости удобно представить размеченным ориентированным графом без циклов с единственной корневой вершиной. Корневая вершина помечена именем предметной области, для которой разрабатывается графический диалог. Проект графических сцен на плоскости может повторно использоваться при проектировании других интерфейсов прикладных программ для решения задач в той же предметной области, но, возможно, с другой функциональностью.
Остальные вершины графа имеют метки одного из следующих типов. Описание базы (MBase). В графе возможна только одна вершина данного типа, поскольку любая графическая сцена содержит одно и только одно базовое изображение. Описание базы состоит из имени базового изображения, ее образа, точки отсчета, а также масштаба расстояний, масштаба времени и формата времени.
