Содержание к диссертации
Введение
1. Анализ особенностей интерфейса пользователя в java 15
1.1 Системы для встроенных и мобильных устройств 15
1.1.1 Классификация систем интерфейса пользователя 17
1.1.2 Интерфейс пользователя для мобильных устройств 20
1.1.3 Интерфейс пользователя для встроенных устройств 26
1.1.4 Интерфейс пользователя на базе распознавания/синтеза речи 31
1.2 Требования к разрабатываемой библиотеке 35
1.3 Постановка задачи 37
1.4 Выводы 38
2. Разработка библиотеки 39
2.1 Определение функций библиотеки 40
2.1.1 Критерий выбора функций. 40
2.1.2 Основные функции библиотеки 41
2.2 Принципы функционирования библиотеки 46
2.2.1 Осуществление запроса приложения к системе 47
2.2.2 Задание обработчика и разбор ответа пользователя 48
2.2.3 Отмена запроса и информационный запрос 50
2.2.4 Управление активностью приложения 51
2.3 Элементы библиотеки 54
2.3.1 Эчемент контекст работы приложения 54
2.3.2 Элемент ТИП запроса и его вспомогательные элементы 56
2.3.3 Эчемент ответ пользователя и его обработчик 58
2.3.4 Элемент АПИ приложение 60
2.4 Выводы 63
3. Принципы реализации библиотек и 64
3.1 Интерпретатор запроса 66
3.1.1 Понятие и задачи интерпретатора 66
3.1.2 Универсальный и татформозависимый интерпретаторы 68
3.1.3 Особенности составления и разбора запроса 70
3.1.4 Оптимизация работы интерпретатора 73
3.2 Особенности реализации интерпретатора 15
3 2.1 Реализация для систем ГИП с расширенными возможностями 75
3.2.2 Реаіизация дія систем на базе распознавания/синтеза речи 82
3.3 Выводы 87
Заключение 88
Литература 91
- Интерфейс пользователя на базе распознавания/синтеза речи
- Задание обработчика и разбор ответа пользователя
- Универсальный и татформозависимый интерпретаторы
- Реализация для систем ГИП с расширенными возможностями
Введение к работе
Пользовательский интерфейс - одна из важнейших частей практически любого программного комплекса, обеспечивающая взаимодействие человека с вычислительной машиной. За последние десятилетия был достигнут огромный прогресс как в значительном расширении возможностей ввода и вывода информации, так и в методах разработки пользовательских интерфейсов. Начав с программирования взаимодействия с интерфейсными устройствами ввода/вывода в машинных кодах для каждой новой программы, разработчики пользовательских интерфейсов стали активно переходить ко всё более высоким уровням абстракции - от использования драйверов до специальных библиотек компонент пользовательского интерфейса (Motif, MFC, Qt, GTKht.h.).
Задача создания абстрактного пользовательского интерфейса (АПИ) неоднократно обсуждалась в академических и коммерческих проектах. При этом в понятие абстрактности интерфейса зачастую вкладывался разный смысл в зависимости от конкретной цели применения. В общем случае АПИ - это описание пользовательского интерфейса, которое не связано с конкретным контекстом его применения. Так, например, его описание средствами Java позволяет обеспечить единый графический интерфейс приложения, например, на платформах Windows ХР и Solaris.
Активное исследование этого понятия в приложении к интерфейсу пользователя (ИП) началось в связи с общим стремлением к созданию платформонезависимого программного обеспечения. Отметим несколько характерных примеров (см. также рис. 1):
абстракция для аппаратуры ввода-вывода. Например, драйвер интерфейсного устройства ввода/вывода имитирует взаимодействие с некоторым абстрактным (обобщенным) устройством, скрывает детали взаимодействия с конкретным устройством. Платой за обобщённость является потеря гибкости во взаимодействии; так, возможно, что некоторые передовые функции конкретного устройства окажутся недоступны;
создание обобщенных компонент пользовательского интерфейса. Обобщённые компоненты позволяют создавать ИП из блоков, абстрагируясь от особенностей низкоуровневого общения. Примерами абстракции подобного вида являются XI1 [8] и Win32 API [9], или более высокоуровневые MFC [10] и Motif [44];
абстракция для различных платформ. Обеспечение полной платформенной независимости приложения подразумевает возможность создания интерфейсов взаимодействия с пользователем, которые обеспечивают идентичную функциональность на разных платформах. Примерами такого направления абстракции являются GTK [43] и соответствующие пакеты Java — Abstract Window Toolkit (AWT) [11], Swing [12].
абстрактный интерфейс высокого уровня (SWING)
абстрактный интерфейс низкого уровня (AWT)
платформозависимый интерфейс высокого уровня (MFC)
платформозависимый интерфейс низкого уровня (win32)
виртуальный драйвер
аппаратура
Рис. 1. Уровни абстракций в системе ИП для настольных компьютеров.
Следует отметить, что в контексте ПЭВМ использование вышеупомянутых подходов позволило значительно облегчить работу по созданию программного обеспечения, и, тем самым, косвенно ускорило прогресс развития в этой области. Этот успех основан, в частности, на том факте, что настольные компьютеры используют традиционный набор интерфейсных средств ввода/вывода для ИП, а именно монитор,
клавиатуру и двухмерный указатель (мышь), для которых разработаны соответствующие абстракции.
Миграция информационных технологий в мир встроенных и мобильных вычислительных устройств (группа embedded and mobile devices) поставила новые задачи перед разработчиками ИП. Устройства данного класса представляют собой полноценную вычислительную машину со своим микропроцессором, операционной средой и программным обеспечением. Однако в отличие от настольных компьютеров данные платформы выделяются широким (и постоянно расширяющимся) спектром разнообразных средств управления, взаимодействие с которыми плохо укладывается в традиционные системы абстракций пользовательского интерфейса. Так, в одних устройствах вывод информации может осуществляться с применением графического дисплея, при этом характеристики дисплеев имеют принципиальные различия (например, размер экрана может отличаться на порядок), в других устройствах вывод осуществляется системой генерации речи. Стандартную клавиатуру заменили телефонные клавишные панели, всё большую популярность набирают также системы распознавания письма и речи и т.д. На рис. 2 приведены примеры таких устройств: а) -устройство с жидкокристаллическим дисплеем, основной и дополнительной клавиатурой, б) - устройство с цветным экраном и вводом на базе распознавания письма, в) - устройство с монохромным экраном и телефонной контрольной панелью.
а) б) в)
Рис. 2. Примеры современных пользовательских устройств.
Каждый новый тип подобных устройств требует разработки собственного программного обеспечения. При этом, как правило, существуют жесткие временные рамки разработки до выхода на рынок. Соответственно, необходимо выбирать среду разработки и исполнения приложений, которую отличали бы хорошая переносимость, удобные изобразительные возможности исходного и платформенная независимость
исполняемого кода. Для этого хорошо подходит Java в качестве защищенной операционной среды для встроенных и мобильных вычислительных устройств. В последние годы Java нашла широкое применение для данного класса устройств, происходит постоянное развитие интерфейсов взаимодействия Java-приложений с различными системами операционной среды, контролируемое стандартизирующей организацией Java Community Process (). Поэтому, говоря о разработке абстракций пользовательского интерфейса для данного класса устройств, целесообразно рассматривать именно технологии на базе Java [7, 13].
Наибольший практический успех в создании платформонезависимых АПИ в контексте встроенных и мобильных вычислительных устройств достигнут технологией Java 2 Platform, Micro Edition (J2ME) [14]. Однако предлагаемые данной технологией модели взаимодействия ориентированны на пользовательские устройства с вполне определёнными типами интерфейсных средств ввода/вывода. Как следствие, приложение, даже будучи разработанным для указанной технологии, не является переносимым из-за различий в применяемых средствах ввода/вывода.
/ интерактивное приложение %*
г *
Рис. 3. Структура приложения, адаптированного для различных устройств.
Существует два типа задач, для которых данный факт создаёт определённую проблему. Первый - это разработка пользовательских приложений общего назначения, таких как адресная книга, органайзер, календарь и так далее. Приложения такого типа востребованы в большинстве пользовательских устройств, при этом разработанная на Java основная часть приложения остаётся платформонезависимой, однако необходимо адаптировать его в части работы с ИП для каждого типа интерфейсных средств
ввода/вывода (см. рис. 3). Второй тип задач обусловлен тем фактом, что в мире компьютеризированных пользовательских устройств уже не редкость сложные системы, функциональность которых определяется набором системных приложений. Например, это системы управления домом (интеллектуальный дом) [15] или системы, применяемые в автомобилях [16]. Соответствующее математическое обеспечение разрабатывается в рамках создания базовой технологии для её последующей адаптации к конфигурации системы от определённого производителя. Указанные системные приложения могут требовать взаимодействия с пользователем, что в свою очередь делает необходимым разрабатывать соответствующий программный код для каждого конкретного типа интерфейсных устройств ввода/вывода.
Таким образом, перед разработчиком программного обеспечения для встроенных и мобильных вычислительных устройств встаёт целый ряд проблем в части программирования взаимодействия с пользователем:
разработчику приходится иметь опыт использования множества различных интерфейсов (библиотек), соответствующих различным системам ввода/вывода, при этом число таких интерфейсов постоянно увеличивается;
даже в рамках работы с одной библиотекой необходимо учитывать определённые характеристики целевого устройства. Например, ИП на базе библиотеки из Mobile Information Device Profile (MIDP) [17], разработанный для сотового телефона с небольшим экраном и клавишной панелью, в большинстве случаев будет малопригоден для применения в электронной записной книжке {personal digit assistant) с большим экраном и средствами ввода на базе системы распознавания письма;
становится невозможным повторное использование уже разработанного пакета системных и пользовательских приложений, т.к. одна система может применяться в серии устройств с различными интерфейсными средствами ввода/вывода, а значит, потребуется адаптация этих приложений для каждого типа устройств в части работы с ИП.
Решению указанного круга проблем посвящена данная диссертационная работа.
Актуальность темы. Несовместимость систем для встроенных и мобильных вычислительных устройств при работе с интерфейсом пользователя требует адаптации приложений для каждой конкретной системы. В результате увеличивается стоимость разработки новой системы и время выхода её на рынок.
Для разрешения этой проблемы необходима разработка специальной библиотеки пользовательского интерфейса, представляющей собой абстракцию более высокого уровня для существующих систем ИП, применяемых в вычислительных устройствах с различными интерфейсными средствами ввода/вывода. В связи с этим становятся актуальными задачи, связанные с разработкой такой библиотеки и принципов её реализации в различных системах. Соответственно, указанную разработку предлагается назвать библиотекой абстрактного пользовательского интерфейса.
Целью диссертационной работы является разработка и исследование новой модели взаимодействия приложения с пользователем, разработка на её основе библиотеки АПИ, а также анализ проблем, связанных с реализацией этой библиотеки в различных системах и их практическое решение. Исходя из поставленной цели, в работе решаются следующие задачи:
исследование существующих библиотек ИП, представленных в технологии Java для встроенных и мобильных вычислительных устройств, анализ их задач и принципов работы, а также возможности применения наработок из этих библиотек;
определение требований к библиотеке АПИ для встроенных и мобильных вычислительных устройств в условиях независимости от средств ввода/вывода;
разработка новой модели взаимодействия приложения с пользователем и её проецирование на язык программирования - создание интерфейсов библиотеки;
разработка общих принципов реализации библиотеки АПИ;
разработка принципов реализации библиотеки АПИ для различных систем;
оценка выполнения требований, предъявленных к разрабатываемой библиотеке.
Предмет исследования составляют различные аспекты разработки библиотеки АПИ и её реализации для среды Java 2 Platform, Micro Edition:
модели взаимодействия, предоставленные в существующих библиотеках ИП;
возможность проекции разработанной модели на язык программирования;
способы реализации библиотек ИП и их пригодность в случае библиотеки АПИ;
особенности реализации библиотеки АПИ в различных системах ИП;
степень выполнения требований, предъявленных к библиотеке АП.
Методы исследования относятся к области системного программирования и технологии разработки программного обеспечения. Применимость разработанного интерфейса для создания приложений оценивалась посредством анализа выполнения требований к библиотеке АПИ. Эффективность принятых решений оценивалась посредством сравнительного анализа организации и процесса функционирования интерпретатора запроса (как средства реализации библиотеки АПИ) и приложения на базе низкоуровневой библиотеки ИП.
Научная новизна работы заключается в обобщении задач существующих систем ИП для встроенных и мобильных вычислительных устройств, разработке новой модели взаимодействия приложения с пользователем в условиях неопределённости интерфейсных средств ввода/вывода, разработке на её основе библиотеки абстрактного пользовательского интерфейса и принципов её реализации для различных систем:
разработаны общие требования к библиотеке АПИ, а также предложен обобщённый критерий отбора её функций;
определены задачи и принципы функционирования этой библиотеки, а также способ её реализации, состоящий в динамическом построении конечного ИП по абстрактному описанию, т.е. применении интерпретатора;
разработан метод оптимизации процесса функционирования библиотеки АПИ для случая вывода приложением текстовой информации;
разработаны принципы представления контейнера запросов для различных систем, а также различные типы контейнера для повышения применимости интерфейса.
Практическая ценность результатов работы состоит в том, что на основе результатов анализа и обобщения задач ИП и создания соответствующей модели взаимодействия была разработана библиотека АПИ для встроенных и мобильных
вычислительных устройств с различными интерфейсными средствами ввода/вывода. Библиотека была реализована для различных систем на базе графического интерфейса пользователя (ГИП) и системы на базе голосового управления для технологии J2ME. Успешное выполнение всех предъявленных к библиотеке требований подтвердило её пригодность для решения проблемы адаптации большого класса приложений для различных систем ИП. Результаты проведённого исследования носят общий характер, поэтому их применение не ограничено системами на базе технологии Java.
Основные практические результаты, выносимые на защиту.
На защиту выносятся следующие основные практические результаты, полученные в ходе выполнения диссертационной работы:
1) Задачи и принципы работы библиотеки АПИ:
обобщённый критерий отбора задач библиотеки АПИ;
запрос на взаимодействие как главный принцип функционирования;
принципы осуществления запроса к системе и обработки ответа пользователя;
понятие информационного запроса для повышения применимости библиотеки;
понятие обновляемого запроса для оптимизации работы библиотеки;
понятие запроса на взаимоисключающий или множественный выбор.
2) Принципы реализации библиотеки АПИ:
применение интерпретатора для динамического построения конечного ИП по переданному абстрактному описанию;
преимущества применения низкоуровневого интерпретатора;
принципы составления и разбор правильности запроса;
принципы обработки обновляемого запроса;
принципы обработки контейнера запросов различных типов;
особенности реализации в системе на базе голосового управления.
На основе разработанной модели была создана библиотека абстрактного пользовательского интерфейса и осуществлена её реализация для систем на базе ГИП и на базе распознавания/синтеза речи, а именно:
в системе на базе Personal Java 1.0 (для последующего переноса на конфигурацию CDC 1.0, профиль РВР 1.0) для ГИП с черно-белым экраном с разрешением 192x96;
в системе на базе Personal Java 1.0 для ГИП с цветным экраном (256 цветов) с разрешением 320x420;
в системе на базе Personal Java 1.0 для ИП, основанного на механизме распознавания/синтеза речи фирмы Fonix.
Разработанные библиотека АПИ и её реализация для указанных систем вошли в состав опытного продукта, созданного в рамках проекта Java Telematics Technology (JTT) фирмой Sun Microsystems в 2000-2002 годах. Реализованная библиотека АПИ была адаптирована и использована для работы в составе:
эмулятора пользовательского интерфейса клиентской части JTT;
эталонной реализации (reference implementation) клиентской части JTT для платформы x86/windows 2000;
опытной реализации клиентской части JTT для платформы Super HitachHIVxWorkslPersonal Java 1.0.
Разработанное программное обеспечение прошло этап опытной эксплуатации в фирмах Sun Microsystems, ЗАО "МЦСТ" и показало хорошие результаты.
В дальнейшем возможно использование результатов работы в составе программного обеспечения для серии устройств одного типа, базирующихся на определённой конфигурации J2ME и имеющих различия в доступном интерфейсе пользователя. Кроме того, предложенные решения носят достаточно универсальный характер, что позволяет применять их при разработке библиотеки АПИ для встроенных и мобильных вычислительных устройств на базе технологий, отличных от технологии Java 2 Platform, Micro Edition.
Публикации.
По теме диссертации опубликованы 7 работ:
Беляев В.К., Афремов П.Н. Принципы организации абстрактного пользовательского интерфейса в Java 2 Platform, Micro Edition II Тезисы докладов XLV научной конференции МФТИ, ч\ - М.: МФТИ, 2002. С. 45-47 [1].
Беляев В.К., Мухин И.А. Поддержка абстрактного пользовательского интерфейса в Java 2 Platform, Micro Edition II Труды XLVI научной конференции МФТИ, ч.І - М.: МФТИ, 2003. С. 55-56 [2].
Беляев В.К. Особенности реализации абстрактного пользовательского интерфейса в J2ME // Компьютеры в учебном процессе, № 1, 2004. С. 79-98 [3].
Забелин СВ., Беляев В.К. Абстрактный пользовательский интерфейс в Java 2 Platform, Micro Edition: определение, задачи, принципы работы // Информационные технологии, № 3, 2004. С. 30-38 [4].
Беляев В.К. Оптимизация работы интерпретатора запроса при реализации абстрактного пользовательского интерфейса // Тезисы докладов XXX Международной молодежной научной конференции Тагаринские чтения", т. 5 - М.: "МАТИ"-РГТУ им. К.Э. Циолковского, 2004. С. 8 [5].
Беляев В.К., Афремов П.Н, Мухин И.А. Абстрактный пользовательский интерфейс в Java 2 Platform, Micro Edition: библиотека и её поддержка // Информационные технологии, № 7, 2004. С. 35-42 [6].
Беляев В.К., Некрестьянов И.С. Методы описания абстрактного пользовательского интерфейса // Высокопроизводительные вычислительные системы и микропроцессоры. Сб. научн. трудов, вып. 6 - М.: ИМВС РАН, 2004. С. 86-96 [7].
Апробация.
Результаты работы докладывались и обсуждались на XLV, XLVI научных конференциях Московского Физико-Технического Института, на XXX Международной молодёжной конференции "Гагаринские чтения", а также семинарах ЗАО "МЦСТ" и ИМВС РАН.
Краткое содержание работы.
В главе 1 проводится анализ существующих библиотек для разработки интерфейса пользователя для встроенных и мобильных вычислительных устройств, определяется область применения библиотеки АПИ, а также определяются требования к этой библиотеке.
Для определения целевых систем ИП в разделе 1.1.1 проводится классификация таких систем, применяемых в современных встроенных и мобильных вычислительных устройствах. По результатам проведённой классификации делается вывод, что в диссертационной работе должны рассматриваться системы на базе ГИП и системы на базе распознавания/синтеза речи.
Интерфейс пользователя на базе распознавания/синтеза речи
В отличие от систем графического интерфейса пользователя, в системах на базе распознавания/синтеза речи применяется стандартный набор устройств ввода/вывода — это микрофон и динамик (и иногда одна или несколько клавиш). Т.е. можно было бы ожидать для этого типа систем довольно простую модель взаимодействия и, как следствие, простой интерфейс для программирования приложений. Однако в данном случае модель взаимодействия определяется больше задачами, решаемыми этим типом систем - их спектр довольно широк, а сами системы распознавания/синтеза речи представляют собой достаточно сложный комплекс. Рассмотрим эти задачи.
Одна из главных функций системы генерации речи — это создать наиболее естественно звучащую речь на основе переданной ей информации, включающей в себя текст для вывода и определённую разметку (например, интонация, паузы и т.д.). Соответственно, часть усилий разработчиков таких систем лежит в области создания универсальных средств представления этой информации.
Решение задачи распознавания речи требует определения некоторого словаря, слова из которого будут произноситься пользователем, а также правил произношения этих слов (например, в какой последовательности эти слова должны произноситься, чтобы быть распознанными). Также существует особый режим работы распознавания речи - режим диктанта, для которого определяются особые условия распознавания, как правило, на уровне самой системы. Одной из основных характеристик системы распознавания речи является её производительность - качественная обработка голосовой информации является трудоёмким процессом, соответственно, такие системы представляют компромисс между качеством распознавания и производительностью.
Одним из примеров абстрактных интерфейсов для работы с этими системами является библиотека Java Speech API 1.0 (JSAPI) [48]. В основе используемой в ней модели взаимодействия лежит понятие машины (engine), главные сущности которого предназначены для распознавания и синтеза речи. На рис. 8 показаны различные состояния машины, связанные с процессом захвата/освобождения ресурсов для распознавания/синтеза речи. Разработчикам приложений предоставляются соответствующие интерфейсы для создания машины и управления её состояниями. текста и дополнительной информации в систему генерации речи в JSAPI был определён язык разметки - Java Speech Markup Language (JSML) [49]. Отметим, что в его организацию заложена поддержка различных языков, однако такой документ не должен содержать описания на нескольких языках одновременно, т.е. в случае многоязыковой поддержки приложению требуется предоставлять системе вариант документа, соответствующий требуемого языку. Работа с генерацией речи не ограничивается созданием документа на JSML. В библиотеке JSAPI предоставлено более десятка классов и интерфейсов для взаимодействия с соответствующей машиной - это довольно сложная система.
Ещё более сложный интерфейс предоставляется для интеграции в приложение работы с распознаванием речи. Более тридцати различных классов и интерфейсов отвечают за подготовку грамматики, получение и обработку событий изменения её состояния, получение и обработку событий от соответствующей машины, и т.д. Отметим также, что спецификация JSAPI позволяет не реализовывать поддержку диктанта, которая требует значительных системных ресурсов. Соответствующая этому режиму грамматика: обычно использует большой словарь; является встроенной в машину для распознавания; является общей или зависящей от предметной области; может поддерживать непрерывную или дискретную речь. Итак, описанная библиотека является абстракций низкого уровня для существующих систем распознавания/синтеза речи, т.е. она неприменима для систем другого типа. При этом она является довольно-таки сложной для применения в простых пользовательских приложениях — преследуя цель обобщить работу с существующими системами распознавания/синтеза речи для различных платформ, её разработчики не позаботились о простоте использования полученной библиотеки. Отметим также некоторые различия при разработке ИП для данных систем и для систем на базе ГИП. Основной особенностью речевой информации является её мимолетность, т.е. эта информация может обрабатываться только в момент её предоставления. Графическая информация в большинстве случаев является постоянной, т.е. она видима на экране до некоторого события, как правило — отклика пользователя. При разработке ГИП можно предоставить пользователю некоторый объём информации, при этом время её восприятия пользователем в целом неограниченно, что гарантирует выполнение задачи. Способность большинства людей к восприятию мимолётной информации весьма ограниченна, т.е. пользователи смогут запомнить ограниченное число переданной информации, например, только несколько вариантов выбора из списка, и наоборот, во время диктанта они часто забывают точные слова, которые только что произнесли
Задание обработчика и разбор ответа пользователя
Как уже было определено, при асинхронном запросе приложение должно предоставлять системе метод-обработчик ответа пользователя. Этот обработчик задаваться приложением при каждом запросе, что позволит использовать модульный подход при разработке приложения.
Усложним рассматриваемое приложение. Пусть оно делает запрос на ввод имени пользователя. Не будем сейчас уточнять, каким именно способом приложение сообщает пользователю, что от него требуется ввести имя. При ответной реакции пользователя на запрос приложение должно получить не только уведомление, что ввод пользователя состоялся, но и содержание этого ввода. Соответственно, библиотека должна предоставлять средство описания ввода пользователя (в рассматриваемом примере это текст, введенный пользователем в качестве имени). Итак, последовательность работы приложения теперь будет такая: приложение подготавливает обработчик ответа пользователя; приложение осуществляет запрос на ввод имени пользователя, определяя при этом обработчик ответа на запрос; приложение ожидает ответа на запрос, при этом ни один поток не блокируется приложением; после того, как пользователь осуществил (неизвестным приложению способом) свой ввод, приложение получает этот ответ пользователя — система вызывает заданный мекод-обработчик ответа у приложения; в этом методе приложение разбирает ответ пользователя и принимает решение о том, что делать дальше (например, затребовать повторный ввод или осуществить следующий запрос).
Отметим, что в реализации библиотеки АПИ должен учитываться данный порядок работы приложения. Особенно важно отметить тот факт, что приложение может осуществить следующий запрос к системе из метода-обработчик ответа, который должен вызываться этой системой. Это означает, что на момент вызова этого метода у приложения система должна полностью закончить работу по предыдущему запросу, освободить захваченные для этого запроса ресурсы и быть готовой к обработке нового запроса от приложения.
Предложенные принципы функционирования библиотеки АПИ являются основными при построении модели взаимодействия. Однако можно предложить для неё ряд дополнительных особенностей. Для этого рассмотрим различные сценарии работы приложения.
Итак, приложение может быть разработано таким образом, что при возникновении каких-либо внешних событий в системе (например, просто по событию от счетчика времени) оно должно осуществить новый запрос, не дожидаясь ответа пользователя на текущий. Как уже было определено, пока не получен ответ на текущий запрос, все последующие запросы отклоняются системой. При этом период времени до ответа пользователя не определён - пользователь может дать ответ в течение нескольких секунд, через несколько минут или не дать ответ вообще (например, затребовав доступным способом у системы закончить работку текущего приложения).
Приведенный сценарий показывает, что в библиотеке АПИ должна предоставляться возможность отменить текущий запрос. Такую возможность можно реализовать введением в модель метода-отмена запроса. При этом, т.к. система может обрабатывать только один запрос в момент времени, такой метод не требует определять, что именно ему нужно отменить.
Введение метода-отмена запроса дает две возможные ситуации дальнейшей работы приложения после вызова этого метода. Первая ситуация предполагает, что система вызовет метод-обработчик ответа после отмены запроса, определив при этом для приложения ответ, что запрос был отменен. В этом методе приложение подготавливает и осуществляет следующий запрос. Такой вариант необходимо было бы реализовать в случае, когда системе требуется время для окончания обработки текущего запроса и освобождения ресурсов. Поэтому асинхронная схема отмены запроса была бы актуальной в силу причин, описанных ранее. Однако было выдвинуто предположение, что система может прекратить обработку запроса и освободить ресурсы практически мгновенно с точки зрения работы ИП. Это предположение получило практическое подтверждение после реализации библиотеки для различных систем ИП. В результате для модели был выбран второй вариант, т.е. возврат из метода-отмена запроса происходит после того, как система подготовилась к следующему запросу, и приложение может осуществлять следующий запрос сразу же после отмены предыдущего. При этом, понятно, система не вызывает метод-обработчик ответа.
Вернёмся теперь к основному варианту рассматриваемого приложения, когда оно просто предоставляет информацию пользователю. Очевидно, что никакого ответа от пользователя приложение в этом случае не ожидает. Получаем, что всякий раз, когда приложение захочет сделать новый запрос, оно должно отменять текущий запрос, даже если на него не ожидается ответа. В такой ситуации для упрощения работы библиотеки было предложено автоматически отменять запросы на предоставления информации {информационные запросы) в случае осуществления следующего запроса любого типа, т.е. они не требуют отмены с помощью метода-отмена запроса. Рассматривая различные варианты возможных реализаций этого сценария, было принято считать любой запрос информационным, если для него не был определён (задан) обработчик ответа
Универсальный и татформозависимый интерпретаторы
Одной из главных задач при создании интерпретатора является минимизация соответствующих затрат и обеспечение эффективной работы интерпретатора - это соответствует выполнению требования простоты и эффективности реализации, предъявленному к библиотеке АПИ. Для решения этой задачи рассмотрим два возможных подхода к организации интерпретатора запроса приложения. При первом подходе создаётся интерпретатор высокого уровня, который является некоторым образом универсальным для широкого ряда систем ИП. При этом каждая конкретная система должна реализовывать его собственные вспомогательные интерфейсы адаптации. На рис. 14 показана схема обработки запроса на ввод текста при использовании такого интерпретатора.
Преимуществом такого подхода является возможность повторного использования кода (не нужно заново создавать интерпретатор для очередной системы). Главными недостатками являются ограниченное использование всех средств конкретной системы и добавление ещё одного уровня интерпретации, что несколько снижает производительность работы реализации. Действительно, как уже говорилось, создание, активация и обработка событий определённого для данной системы элемента являются платформозависимыми действиями. Поэтому только разработанный под конкретную систему интерпретатор может выполнить их наиболее эффективным способом.
Соответственно, второй подход предлагает использовать платформозависимую реализацию интерпретатора, который лишён указанных выше недостатков. В свою очередь, недостатком могло бы являться требование создавать такой интерпретатор для каждой системы "с нуля". Однако, результаты разработки интерпретатора показали, что простота и однотипность его структуры позволяет реализовывать его с минимальными затратами, устраняя описанный недостаток. В реализации библиотеки применён именно такой тип интерпретатора. На рис. 15 представлен архитектурный стек при реализации библиотеки АПИ Необходимо провести оценку эффективности работы библиотеки АПИ, реализованной таким способом. Такая оценка производится на основе следующих соображений. Рассмотренный порядок работы интерпретатора показывает, что его основная задача — это нахождение, создание, активация элементов пользовательского интерфейса системы, а также обработка событий от этих элементов. Любое приложение на базе платформозависимого ИП решает такие же задачи. Другими словами, интерпретатор, по сути, является платформозависимым приложением, Соответственно, эффективность его работы соизмерима с эффективностью работы такого приложения, что доказывает пригодность такого подхода. Данные выводы были подтверждены практически после реализации библиотеки для различных систем пользовательского интерфейса.
Аналогичные соображения позволяют также оценить объём и сложность работ при осуществлении реализации библиотеки АГТИ на новой системе. Например, в системе на базе ГИП (CDC/PP) с ограниченными возможностями вывода достаточно было бы разработать приложение, которое оперирует всего тремя графическими элементами — Text Fie Id, List и Label, определить соответствующие обработчики событий и управлять, свойством видимый этих двух элементов, другими словами — разработать одно приложение средней сложности. Очевидно, что это потребует гораздо меньших затрат, чем перенос на новую систему ИП пакета готовых приложений. Данные выводы также были подтверждены практически после реализации библиотеки. Например, объём исходного кода интерпретатора на языке Java для системы на базе ГИП с ограниченными возможностями составляет примерно 600 строк.
В предыдущей главе при разработке элементов библиотеки АПИ был оставлен открытым вопрос, каким образом должны описываться элементы тип запроса на языке программирования Java. Действительно, для традиционного способа реализации библиотеки ИП могло бы потребоваться объявить элементы этого типа как интерфейсы или абстрактные классы. Выбор интерпретатора запросов как средства реализации библиотеки определил, что эти элементы должны описываться как final классы на языке Java, т.е. не предполагается их наследование. Исходя из этого можно определить ряд особенностей составления и разбора запроса.
Рассмотрим вопрос проверки правильности составления запроса и способов информировании приложения в случае ошибок. Существуют три различных способа
Реализация для систем ГИП с расширенными возможностями
Сделаем на данном примере уточнение к последнему пункту предлагаемых принципов работы с элементом контейнер. При работе рассматриваемого примера в системе на базе ГИП с расширенными возможностями интерпретатор может попытаться разместить все элементы, входящие в корневой контейнер (типа "А") на экране одновременно. В случае неудачи пользователю был бы предоставлен список элементов типа "В". При дальнейшем выборе пользователем одного из этих элементов система снова попыталась бы разместить на экране одновременно все элементы, входящие в выбранный контейнер, и т.д.
При использовании элемента контейнер существует особенность работы приложения, требующая пояснения. Допустим, что в рассмотренном примере пользователь выбрал действие "сохранить номер" для определённого звонка. Такой выбор является идентичным выбору для любого другого звонка, т.е. необходимо предоставлять приложению информацию, в каком именно запросе был осуществлён выбор пользователя. Поэтому в библиотечный элемент отклик пользователя был добавлен дополнительный метод, позволяющий получить информацию о том, на какой именно "вопрос" получен ответ пользователя. Это позволило избежать неопределённости при разборе отклика для описанного случая.
С другой стороны, простой корректировки элемента отклик пользователя может быть недостаточно. Приложение может добавлять один и тот же экземпляр в качестве дочернего в разные контейнеры при одном запросе, чтобы избежать создания копий данного экземпляра, требующихся в разных ветках запроса. Понятно, что такое действие можно запретить при использовании библиотеки АПИ, считая запросы с повторяющимися экземплярами некорректными. Однако такая оптимизация при разработке сложного приложения имеет смысл [35, 37], поэтому в качестве указанной выше информации предлагается применять полный путь от корневого контейнера до листового запроса, на который получен ответ.
В рассмотренном примере приложение предлагало пользователю сделать взаимоисключающий выбор. Т.е. пользователь сначала должен выбирать из списка протоколов определённую группу звонков, далее выбрать какой-нибудь номер и затем решить, что делать с этим номером - удалить, запомнить или набрать. Однако существуют другие задачи, для которых такой тип запроса не является удобным. Например, рассмотрим запрос, который может осуществляться при составлении новой записи для адресной книги. На рис. 20 представлен пример дерева запросов, подразумевающего множественный выбор пользователя.
Поддержка такого типа запроса требует решения двух задач — введение метода сообщения всех сделанных выборов приложению и задание специального типа контейнера, подразумевающего множественный выбор - которые решаются довольно просто. Для решения первой задачи было предложено, что экземпляр элемента ответ пользователя по-прежнему описывает выбор, сделанный при обработке одного элемента тип запроса. Но в случае множественного выбора в метод-обработчик ответа приложения передается не один, а несколько таких элементов (в строгом соответствии с количеством элементов, требовавших отклик пользователя), объединенных в массив или список.
Для решения второй задачи было предложено определять тип контейнера при его создании. При этом существует два различных способа интерпретации заданного типа. В первом случае предлагается считать, что если в экземпляре контейнер задан множественный тип выбора, то все дочерние контейнеры автоматически принадлежат этому типу, т.е. система обязана предоставить пользователю все элементы, подразумевающие ввод, одновременно, по частям или по отдельности. Однако второе предложение обладает большей гибкостью для составления запроса, хотя и требует дополнительных действий от приложения, поэтому мы останавливаемся на нём. Второе предложение состоит в том, чтобы строго задавать тип запроса в каждом контейнере. При этом контейнер для множественных выборов может содержать контейнеры для взаимоисключающего выбора в качестве дочерних элементов.
Таким образом, в результате анализа возможных проблем реачизации библиотеки АПИ в системах на базе ГИП с расширенными возможностями и анализа логики работы приложений было подтверждена необходимость использовать ещё один элемент библиотеки — контейнер запросов. Применение этого элемента значительно упрощает разработку приложений на базе библиотеки АПИ, а также способствует повышению выразительности конечного интерфейса. Были разработаны дополнительные изменения в библиотеке, отвечающие использованию этого элемента, а также предложены его различные типы для улучшения применимости интерфейса. При этом, была решена задача определения основных принципов обработки такого элемента. Однако необходимо ещё раз подчеркнуть, что окончательный выбор способа представления контейнера является исключительно платформозависимым, т.е. определяет разработчиками интерпретатора для определённой системы.
При реализации библиотеки АПИ для системы на базе распознавания/синтеза речи возникает ряд проблем, специфичных для систем этого типа. Далее приводится анализ этих проблем, а также предлагается их решение.
В ряде случаев необходимо организовать синхронизованный доступ к устройству аудио-вывода системы. Механизмы работы с речью и проигрывания аудио-ресурсов могут являться независимыми частями системы, не предусматривающими конкурентный доступ к средствам аудио-вывода. В целях достижения наибольшей производительности они работают напрямую с драйверами соответствующих устройств. Соответственно, в таких системах задача организации санкционированного доступа к этим устройствам должна решаться вне механизма распознавания/синтеза речи. Для её решения предлагается создание простого арбитра доступа, схема использования которого представлена на рис
