Клещев А.С., Грибова В.В. 25.03.2001

Интерфейс имеет важное значение для любой программной системы и является неотъемлемой ее составляющей, ориентированной, прежде всего, на конечного пользователя. Именно через интерфейс пользователь судит о прикладной программе в целом; более того, часто решение об использовании прикладной программы пользователь принимает по тому, насколько ему удобен и понятен пользовательский интерфейс. Вместе с тем, трудоемкость проектирования и разработки интерфейса достаточно велика. По оценкам специалистов в среднем она составляет более половины времени реализации проекта [1]. Актуальным является снижение затрат на разработку и сопровождение программных систем или разработка эффективного программного инструментария, где под эффективностью понимается простота разработки, легкость сопровождения и удобство работы с программой [2].

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

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

В литературе не существует единой общепринятой классификации средств для разработки пользовательского интерфейса. Так, в [3] программное обеспечение для разработки пользовательского интерфейса разделяется на две основные группы – инструментарий для разработки пользовательского интерфейса (toolkits) и высокоуровневые средства разработки интерфейса (higher-level development tools). Инструментарий для разработки пользовательского интерфейса, как правило, включает в себя библиотеку примитивов компонентов интерфейса (меню, кнопки, полосы прокрутки и др.) и предназначен для использования программистами. Высокоуровневые средства разработки интерфейса могут быть использованы непрограммистами и снабжены языком, который позволяет специфицировать функции ввода-вывода, а также определять, используя технику непосредственного манипулирования, интерфейсные элементы. К таким средствам авторы относят построители диалога (interface builders) и СУПИ – системы управления пользовательским интерфейсом (User Interface Management Systems – UIMS). Помимо СУПИ, некоторые авторы используют такие термины, как User Interface Development Systems (UIDS) – системы разработки пользовательского интерфейса, User Interface Design Environment (UIDE) – среда разработки пользовательского интерфейса и др.

В [4] инструментарий для разработки интерфейса разделен на три группы, которые определяются следующим образом. В первую группу входит инструментарий для поддержки создания интерфейса написанием кода – UIMS и Toolkits; во вторую – интерактивные инструментальные средства, позволяющие сконструировать интерфейс из “заготовок” (кнопок, меню, полос прокрутки и т.д.), – Interface Builders; третий тип основан на создании интерфейса путем связывания отдельно созданных его компонент – Component Architectures.

Как замечено в [2], терминология данного направления окончательно не сформировалась и в настоящее время также является предметом исследования. Однако в большинстве работ для ссылки на специализированные средства для разработки интерфейса приводится термин СУПИ, который и будет использоваться в данной работе.

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

Можно выделить несколько основных способов спецификации интерфейса [2].

1. Языковой, когда применяются специальные языки для задания синтаксиса интерфейса (декларативные, объектно-ориентированные, языки событий и др.).

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

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

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

Основной концепцией СУПИ является отделение разработки пользовательского интерфейса от остального приложения. В настоящее время идея раздельного проектирования интерфейса и приложения либо закреплена в определении СУПИ, либо является основным его свойством [5].

В [6] состав СУПИ определен как набор инструментов этапа разработки и периода исполнения. Инструменты этапа разработки оперируют с моделями интерфейса для построения их проектов. Они могут разделяться на две группы: интерактивные инструменты, например редакторы моделей, и автоматические инструменты, например генератор форм. Инструменты периода исполнения используют модель интерфейса для поддержки деятельности пользователя, например, для сбора и анализа используемых данных.

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

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

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

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

Смешанная инициатива управления. Данный тип взаимодействия объединяет два предыдущих подхода, при котором пользователь определяет входные данные, но если прикладной программе для решения необходимы дополнительные данные, то она запрашивает их у пользователя.

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

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

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

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

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

Ориентация на конечного пользователя означает, что интерфейс должен иметь возможности для представления исходных данных и результатов в виде, общепринятом в данной предметной области, либо в зависимости от категорий пользователей и их пожеланий: графическом, табличном, вербальном, причем каждое из них также может иметь несколько видов представлений. Иными словами, как отмечено в [10], для одной и той же информации могут существовать различные передающие сообщения, образующие класс эквивалентных сообщений. При этом всегда существует базисная система сообщений, в которой можно выразить любую информацию о предметной области, однозначно понимаемую и интерпретируемую всеми ее представителями, и к которой сводятся все сообщения пользователя. Такой системой сообщений является система понятий предметной области. В терминах системы понятий именуются объекты предметной области, формулируются утверждения о том, что они обладают некими свойствами и характеристиками, которые позволяют устанавливать сходство и различие объекта по отношению к другим объектам, а также указывают на взаимоотношения, в которых объекты находятся между собой. Таким образом, составляющей пользовательского интерфейса является описание информации через систему понятий предметной области, задающей функцию интерпретации сообщений.

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

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

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

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

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

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

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

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

В работах [3,6,12] также предложено начинать проектирование интерфейса с моделирования задачи и предметной области. Для этого пользователю предлагается на неформальном языке описать постановку задачи, из которой автоматически выделяются понятия предметной области и действия с ними. Следующими этапами является формализация полученной постановки задачи путем отсеивания ненужных элементов, организация классов выделенных элементов, задание области и типов их допустимых значений, действий над ними с целью создания полноценной модели предметной области. В качестве преимуществ подобного способа извлечения задачи авторы указывают на снижение степени непонимания между разработчиком и пользователем, вовлечение пользователя в проект с самого начала его реализации и построение им каркаса модели задачи и модели предметной области. Однако вызывает сомнение возможность использования данного подхода для решения задач со сложной моделью предметной области, имеющей большой объем и сложную структуру системы понятий, необходимую для решения задачи, обеспечения пользователя интеллектуальной поддержкой, поскольку каркас и элементы модели (термины и понятия) выделяются на основе неформального описания задачи пользователем. Наш опыт проектирования сложных систем, например экспертной системы “Консультант-2″ [13] и, в частности, ее интерфейса, показал, что процесс формирования системы понятий, бесспорно, должен осуществляться при активном участии высококвалифицированных специалистов предметной области на основе серьезного предшествующего ее анализа с целью последующей формализации. Инструментарий для проектирования интерфейса поэтому должен быть ориентирован скорее на разработчика интерфейса, чем на конечного его пользователя.

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

Следует отметить, что во всех существующих Toolkits отсутствуют специальные средства для проектирования пользовательского интерфейса исходя из его составляющих [4]. Поэтому разработчики интерфейса вынуждены проектировать все его части вместе, явно не отделяя одну составляющую от другой, хотя проектирование различных его составляющих требует использования различных типов понятий и уровней абстракции. Технология разработки интерфейса данными средствами организована таким образом, что разработчик выбирает интерфейсный элемент и “нанизывает” на него содержание интерфейса, а не наоборот, в соответствии со структурой и содержанием (системой понятий) предлагаются формы ее представления (возможно, автоматически формируются). Разрабатывая таким образом интерфейс, его разработчик должен корректировать структуру и содержание исходных данных под формы, предлагаемые в инструментальном средстве.

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

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

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

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

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

Средства генерации объяснений результатов работы программной системы представлены в работе [11]. Для этого разработчикам интерфейса предлагается специальный макроязык, на котором они могут описать шаблон объяснения. Однако данный язык позволяет представить объяснение только в вербальном виде, имеет ограниченные средства по форматированию текста объяснения и содержит ограничение на формат результатов работы программной системы – только в виде кортежей отношений. Множество других систем генерации объяснений ориентированы исключительно на экспертные системы, они зависят от машины логического вывода, а также требуют включения дополнительных знаний в базу зна- ний [5]. В [15] авторы предлагают средства для автоматической генерации средств помощи по представлению базы знаний.

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

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

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

1. Myers B.A. and Rosson M.B. “Survey on User Interface Programming,” Proceedings SIGCHI’92: Human Factors in Computing Systems. Monterrey, CA, May 3-7, 1992. P. 195-202.

2. Клименко С., Уразметов В. Графические интер- фейсы и средства их разработки // Матер. конф.: Инду- стрия программирования – 96. www.uniyar.ac.ru/network/ atm/forum/koi/if/prg/prg96/73/htm.

3. Puerta, A. R. Supporting User–Centred Design of Adaptive User Interfaces Via Interface Models. First Annual Workshop On Real–Time Intelligent User Interfaces For Decision Support And Information Visualization, San–Francisco, January 1998. 10 p.

4. Brad A. Myers. A Brief History of Human Computer Interaction Technology // ACM interactions. Vol. 5, №. 2. March 1998. P. 44-54.

5. Lowgren J. Knowledge–Based Design Support and Discourse Management in User Interface Management Systems. Linkoping Studies in Science and Technology. Dissertations №239, 1989.

6. Puerta, A.R., and Maulsby, D. Management of Interface Design Knowledge with MOBI–D. IUI97: International Conference on Intelligent User Interfaces, Orlando, January 1997. P. 249–252.

7. Pressman R. S. Software Engineering: Practitioners Approach European 3d Rev. ed. McGraw–Hills Inc., 1994. 802 p.

8. Коутс P., Влейминк И. Интерфейс “человек-компьютер”/ Пер. с англ. – М.: Мир, 1990.- 501 с

9. Bruce A. Wooley Explanation Component of Software Systems. www.acm.org/ crossroads/xrds5–1/explain.html.

10. Бауэр Ф. Л., Гооз Г. Информатика. Вводный курс: В 2 ч. /Пер. с нем. –М.: Мир, 1990. – Ч.1. – 336 с., ил.

11. Грибова В.В., Клещев А.С. Инструментальный комплекс для разработки пользовательского интерфейса в экспертных системах // Программные продукты и системы. – 1999. – №1. – С. 30-34.

12. Puerta, A.R. A Model–Based Interface Development Environment. IEEE Software, 14(4), July/August 1997. Р. 41–47.

13. Черняховская М.Ю. Оценка ЭС медицинской диагностики “Консультант–2″ на архивном материале нескольких клиник. – Владивосток, 1989. – 30 с. (Препр. ИАПУ ДВО РАН).

14. Скопин И.Н. Разработка интерфейсов программных систем // Системная информатика. – 1998. – Вып.6. – С.123–173.

15. Foley, J., Kim, W.C., Kovacevic S., Murray, K., UIDE: An Intelligent User Interface Design Environment, in ACM Press, 1991.

Статья опубликована в выпуске №1 международного журнала “Программные продукты и системы” за 2001 год