Программные продукты и системы

Одной из самых частотных задач при создании любой диалоговой системы является проектирование и реализация ее интерфейсов с пользователем. В общем случае задача разработки интерфейсов распадается на две подзадачи: проектирование собственно интерфейсных элементов (ИЭ), в рамках которого фиксируется внешнее представление единиц общения, и проектирование поведения каждого ИЭ и процесса общения в целом. В настоящее время решение первой подзадачи уже имеет достаточно серьезную инструментальную поддержку практически на всех вычислительных платформах [1, 2, 3]. Качественно другая ситуация с инструментарием для проектирования поведения ИЭ и особенно блоков общения в целом. По существу, разработчикам здесь предлагается использовать либо встроенное поведение ИЭ и на уровне языка программирования проектировать взаимодействие отдельных элементов общения и их проблемную ориентацию, либо опираться на специальные библиотеки классов (например [4]), где в конечном счете все равно приходится "скатываться" к базовому языку программирования. Понятно, что такое положение нельзя считать приемлемым для сколько-нибудь сложных диалоговых систем и особенно для интеллектуальных диалоговых систем, где задача проектирования поведения интерфейсных элементов существенно сложнее, чем собственно их создание. Вот почему одним из базисных инструментов интеллектуальной системы PiES WorkBench [5] является среда интеллектуального проектирования интерфейсов, обсуждению которой и посвящена настоящая работа.

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

Для опросников, используемых в интеллектуальных системах, последнее обстоятельство становится определяющим. Здесь важны и микроповедение (достаточно сложное уже на уровне отдельного ИЭ), и макроповедение (на уровне топологии объединения ИЭ и общего поведения всего интерфейса). Процесс проектирования и реализации диалогов для интеллектуальных систем усложняется и тем, что схемы их "стыковки" с остальными компонентами (в первую очередь с базой знаний и машиной вывода) здесь разнообразнее, чем "классических" диалоговых систем, а подготовка разработчиков в области программного обеспечения слабее их подготовки в предметной области, для работы в которой создается система. В такой ситуации сам инструмент должен быть интеллектуальным и поддерживать все основные этапы жизненного цикла проектирования и реализации диалогов. Вот почему среда интеллектуального проектирования опросников - Questionnaire Development Kit (QDK) инструментальной системы PiES WorkBench - строится как система, основанная на знаниях о моделях диалога и его составляющих, о технологии создания интерфейсов для интеллектуальных систем и знаниях о самом инструменте.

АРХИТЕКТУРА СРЕДЫ QDK

Чтобы быть полезной в качестве инструмента разработчика интеллектуальных систем, среда QDK должна поддерживать:

-          проектирование отдельных ИЭ;

-          проектирование диалогов, состоящих из различных ИЭ;

-          проектирование поведения отдельных ИЭ и диалогов в целом;

-          формирование эксплицитного описания результирующих спецификаций в базе знаний проекта;

-          тестирование спецификаций в процессе их проектирования и верификацию результирующих спецификаций;

-          генерацию исполняемого кода по спецификациям;

-          справки и объяснения в процессе использования инструмента.

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

Учитывая сказанное, архитектура QDK может быть описана Н-диаграммой, представленной на рисунке 1.

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

Рис. 1. Функциональная структура QDK

Собственно проектирование поддерживается в опции Objects.

Опция Options служит для организации просмотра нужных для проектирования баз знаний (Browse), "горячего" тестирования спроектированных фрагментов опросников (Test) и генерации итоговых спецификаций (Generate).

Опция Windows включает "кафельное" (Tile) и каскадное (Cascade) упорядочение на рабочем столе инициированных в процессе работы компонент, упорядочение иконок, соответствующих этим компонентам (Arrange Icons), а также свертку всех активных компонент (Close All).

В опции помощи (Help) собраны блоки гипертекстового описания работы с QDK и объяснения; информация о самой среде QDK и ее базе знаний.

ПРЕДСТАВЛЕНИЕ ЗНАНИЙ В СРЕДЕ QDK

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

Первые две компоненты специфицируют проблемную базу знаний, технология отражается в БЗ метауровня, модель ОГЖ - в инструментальную базу знаний, а последняя компонента — в базу помощи и объяснения.

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

Представление знаний в среде QDK объектно-ориентированное по сути и продукционно-фреймовое по форме. Поэтому в следующих подразделах мы будем опираться на базовые формализмы PiES WorkBench - пакет представления и манипулирования знаниями FRAME/2 [6] и продукционно-фреймовый ЯПЗ PILOT/2 [1], а при обсуждении реализации покажем, как эти знания организованы и функционируют в объектно-ориентированной среде С++.

ПРОБЛЕМНЫЕ ЗНАНИЯ СРЕДЫ QDK

Все опросники можно разделить на два класса. К первому относятся опросники с "отложенной", а ко второму - с "немедленной" реакцией на ответ. Как правило, первые - линейные, а вторые - древовидные или сетевые. Заметим, что здесь не принимается во внимание проверка лексической допустимости ответа, которую почти всегда целесообразно выполнять как немедленную реакцию.

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

Но независимо от типа ИЭ в его общей структуре выделяются вопрос-ответная пара (ВОП) и служебная информация. Представление ВОП зависит от типа ИЭ. Так, например, в случае текстовой ВОП и вопрос, и ответ представляются алфавитно-цифровыми строками; для точечной графической шкалы вопрос состоит из текста и "картинки" со шкалой, а ответ -элемент (Э), удовлетворяющий соотношению min<=9<=max, где min и max - границы шкалы. Служебная информация по своей структуре является общей для всех типов ИЭ и включает внешнее представление каждого из них, а также описание положения данного ИЭ в общей схеме диалога за счет его связей с другими интерфейсными элементами.

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

Поведение ИЭ на этапе проектирования относится к инструментальному разделу БЗ QDK и рассматривается ниже. Здесь же обсуждаются проблемные знания, которые в основном сосредоточены в системе фреймов со следующими прототипами:

Как следует из приведенных спецификаций, каждый из интерфейсных элементов имеет ссылку на «свой» диалог (слот CurrChain) и, быть может, дополнительную информацию (например тип списка выбора и базисный набор альтернатив для ИЭ типа HstQAE). Кроме того, к слотам CurrChain "привязаны" демоны, которые обеспечивают визуализацию соответствующего ИЭ и реализуют полностью его локальные и частично глобальные цели. Все локальные ИЭ являются подклассами фрейма QA-Elem со следующим прототипом:

QA-Elem is_a QAE-Chain; Caption         string;

Question        {string};

NextQAE       frame;

PrevQAE       frame;

Здесь в слоте Question содержатся общая информация о вопросе и ссылки, фиксирующие положение данного ИЭ в диалоге (слоты NextQAE и PrevQAE). А фрейм QAElem в свою очередь связан is_a иерархией с фреймом QAE-Chain, в котором фиксируются текущий ИЭ, ссылки на прототип и экземпляр ответа, а также имя слота, куда должен быть помещен собственно ответ:

QAE-Chain is_a prototype; Caption         string;

 CurrQAE frame; if_added RunQAE (); if_changed RunQAE ();

AnswPrt frame; by_default Questionnaire;

AnswExm frame;

AnswSlot string; by_default "Answer";

По умолчанию имя слота ответа - Answer, a прототип ответа — Questionnaire. В случае ИЭ типа "текст" этот прототип описывается следующим образом:

Questionnaire is_a prototype;

Answer {string};

Отработка глобальных целей диалога осуществляется демоном RunQAE вида:

RunQAE (){

CurrElem = GetValue ("CurrQAE");

if (CurrElem && ExistFrame (CurrElem)){

 CurrChain = GetCurrExmName ();

 Change Value (CurrElem, "CurrChain", CurrChain);

 }

}

Для "запуска" опросника необходимо выполнить оператор, с помощью которого активизируется демон RunQAE ():

AddValue (CurrChainName, "CurrQAE", NameFirstQAE);

Здесь первый параметр задает имя фрейма-экземпляра "отрабатываемого" опросника, второй параметр - стандартное имя слота в этом фрейме, а третий - имя фрейма-экземпляра первого ИЭ.

Приведенные выше описания прототипов ориентированы на линейные опросники с моделью в виде фреймов QA-Elem и QAE-Chain. Понятно, что для древовидных и сетевых опросников потребуется изменить прототип QA-Elem, a также добавить уточняющую информацию в прототипы отдельных подклассов ИЭ. Однако и при этом общая схема описания проблемной БЗ останется прежней.

МЕТАЗНАНИЯ СРЕДЫ QDK

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

Учитывая сказанное, в среде QDK предлагается технологическая схема проектирования опросников, общая структура которой представлена на рисунке 2.

Рис. 2. Технологическая схема проектирования опросников

Из этой схемы следует, что при проектировании интерфейсов в среде QDK на верхнем уровне выделяются три этапа: настройка на базу спецификаций (kBase), собственно проектирование (QA-Chain к QA-Elem), а также сервис проектировщика в широком смысле (Browse, Test и Generate).

На этапе собственно проектирования разработчик интерфейсов может выбрать по своему усмотрению подсхему QA-Chain или QA-Elem. Первая из них - QA-Chain - представлена на рисунке 3. Из этой диаграммы видно, что проектирование QA-Chain также имеет несколько этапов: настройку на проектирование, где задаются шаблоны известных системе QA-Chain и QAElem (SetChainsPat и SetElemsPat), а также фиксируются текущие цепочка и элементы (SelectChain и SelectElems); спецификацию проектируемой цепочки, включая ее топологию (CreateChain, DeleteChain, CopyChain и RenameChain, а также AddAll, Add, Remove и RemoveAll) и просмотр отбираемых для конкретного применения интерфейсных элементов (ViewElem).

Рис.3. Технологическая подсхема проектирования QA-Chain

Рис.4. Технологическая подсхема проектирования QA-Elem

Подсхема QA-Elem показана на рисунке 4. Как и на предыдущей диаграмме, в подсхеме QA-Elem явно выделяются настройка на проектирование и создание текущего интерфейсного элемента. Однако теперь не требуется знания текущей QA-Chain, поэтому в этой диаграмме представлены образцы ИЭ и средства выделения тех из них, которые нужны в данный момент.

Собственно проектирование осуществляется на дугах CreateElem, DeleteElem, RenameElem и CopyElem (здесь разработчик интерфейсов работает с ИЭ как с отдельными объектами) и на дугах Question, txtAnsw, ynAnsw, abcAnsw, scaleAnsw и listAnsw. Дуга Question обеспечивает проектирование первой части вопрос-ответной пары - текстового представления вопроса. Остальные дуги из указанного перечня "отвечают" за выбор типа ответа. Первые три из них простые, а последние две - scaleAnsw и listAnsw - требуют дополнительных параметров, которые задаются на дугах H(orizontal), V(ertical), From, To и Grain для ответов типа "шкала" и S(ingle), M(ultiple) и ListValue для ответов типа "список выбора".

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

ИНСТРУМЕНТАЛЬНАЯ КОМПОНЕНТА ЗНАНИЙ

В соответствии с технологической схемой проектирования опросников в распоряжении разработчика имеется два основных инструмента - модули QA-Chain и QA-Elem. Для обеспечения требуемой гибкости среды QDK необходимо, чтобы эти модули работали автономно, но результаты, полученные в QA-Chain, должны быть доступны в QA-Elem и, наоборот, в динамике проектирования. Это означает, что оба инструмента должны использовать единую базу знаний, а их модели отражать взаимные изменения состояний. Вот почему в среде QDK они "собраны" в единую подсистему фреймов со следующими прототипами:

DesignQAC is_a prototype; lf_added CreateBoxQAC (); ChalnsPattern string; by_default "*";

if_changed UpdateChainsLst (); ChainsDsc         {frame}; if changed

UpdateChainsLst ();

CurrChain frame; CurrElem frame; CreateButton int; by_default INACTIVE; if_changed CreateChain ();

ElemsPattern string; by_default "*";

if_changed UpdateElemsLst (); ElemsDsc {frame}; HlghLightElems {frame}; VlewButton int; by_default INACTIVE; lf_changed ViewElem ();

ButtonOK      int; by_default INACTIVE;

if_changed Close 0; ButtonCancel int; by_default INACTIVE;

if_changed Destroy (); ChainDsc is_a prototype;

WasOhanged int; by_default UNCHANGED; ChainElems {frame}; if .changed WasChange ();

Демон CreateBoxQAC обеспечивает визуализацию инструмента (рис. 5) и начальные установки. Дальнейшее функционирование модуля QA-Chain определяется демонами при остальных слотах фрейма DesignQAC и действиями разработчика в процессе проектирования.

Рис.5. Экранная форма модуля проектирования QA-Chain

Аналогичным образом устроена и модель инструмента QA-Elem. Отличие здесь лишь в том, что работа ведется с отдельными, пока не связанными с определенным опросником ИЭ. В дальнейшем разработчик интерфейса сам определяет, в каких опросниках будут использоваться те или иные интерфейсные элементы. Внешнее представление модуля QA-Elem показано на рисунке 6.

Рис.6. Экранная форма модуля проектирования QA-Elem

РЕАЛИЗАЦИЯ ИНСТРУМЕНТАЛЬНОЙ СРЕДЫ QDK

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

Вместе с тем определенные ограничения при реализации появились в связи с использованием в качестве базового инструмента реализации языка Borland C++ [9] и стандартной библиотеки классов Object Windows [4]. Так, например, отсутствие в базовом языке множественного наследования потребовало нежелательного дублирования некоторых компонент и активного использования механизма дружественных классов, а структура стандартней библиотеки классов, не всегда хорошо "стыкующаяся" со средой Windows, и ее Относительная "бедность" привели к необходимости соответствующих доработок этой библиотеки. Справедливости ради отметим, что некоторые из разработанных нами классов, например "кнопочные" линейки и "статус" бары, уже входят в новую версию среды Borland 4.0.

Вся среда QDK реализуется как MDI-при-ложение графической оболочки Windows. При этом, в соответствии с общепринятыми стандартами таких приложений, на начальном этапе пользователю доступны лишь опции kBase, Quit и Help основного меню. После настройки на определенную базу спецификаций среда "разворачивается" и в процессе проектирования пользователю уже доступны все компоненты основной технологической схемы. При вызове локальных инструментов на рабочем столе среды появляются объекты, каждому из которых соответствует определенный экземпляр класса. Фрагмент иерархии классов, использованной при реализации QDK, приведен на рисунке 7.

Рис.7. Фрагмент иерархии классов среды QDK

С точки зрения инструментальной базы знаний QDK вызов любой ее компоненты связан с созданием фрейма-экземпляра. При этом активизируется демон соответствующего фрейма-прототипа. Так, например, вызов модуля QA-Chain приводит к активизации демона CreateBoxQAC, основной задачей которого является создание объекта TDialogQAC, а по цепочке наследования и всех подчиненных ему объектов. В результате визуализируется уже обсуждавшаяся выше экранная форма (рис. 5). Тот же принцип используется и при вызове других модулей инструментальной среды QDK. Иначе организовано функционирование самих модулей QDK, хотя и здесь основную роль играют демоны, правда, "привязанные" к слотам соответствующих фреймов-экземпляров. Например, при ответе типа "шкала" (кнопка выбора Scale на рисунке 6) значение слота scaleButton в экземпляре фрейма DesignStandartQAE. Специфическим по отношению к уже рассмотренным является демон Close, "привязанный" к слоту ButtonOK. По существу, это верификатор спроектированного ИЭ, задачей которого должна быть проверка допустимости проектных решений пользователя среды QDK. В нашем случае этот демон является продукционной системой на ЯПЗ PILOT/2.

Выше мы обсудили основные моменты объектно-ориентированной реализации среды QDK. В заключение отметим, что общий объем ее инструментальной базы знаний составляет 179 Кб, а объем исходных текстов на языке С++ и ЯПЗ PILOT/2 - 67 Кб. Объем проблемной базы знаний зависит от сложности и размеров проектируемых опросников. Например, при проектировании опросников ЭС Cattell [10] он составил около 200 Кб.

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

1.        Manual on Microsoft SDK, Microsoft, 1990.

2.        Manual on Borland Workshop, Borland International Inc., 1991.

3.        Manual on Development Guide, SUN International, 1993.

4.        Object Windows для С . Киев: Диалог, 1992.

5.        Хорошевский В.Ф. Управление проектами в интеллектуальной системе PiES Workbench // Изв. РАН. - Сер. Техническая Кибернетика. - 1993. - N 5.

6.        Sherstnew W.Yu., Worfolomeew A.N., Aleshin A. Yu., FRAME/2 Application Program Interface for Frame Knowledge Bases, Proc. International Russian-Japan Symposium "Knowledge Based Software Engineering", 1994.

7.        Хорошевский В.Ф., Щенников СЮ. Инструментальная поддержка процессов приобретения знании в системе ПиЭС // Изв. АН СССР. - Сер. Техническая Кибернетика. - 1990. - № 4.

8.        Буч Г. Объектно-ориентированное проектирование с примерами применения. - М.: Конкорд, 1992.

9.        Borland С Manual, Borland International Inc., 1991.

10.       Нарушев Е.С., Хорошевский В.Ф. Программное обеспе чение экспертной системы Cattell (Опыт разработки) // Труды конф. ВКИИ-90. -Т. Выставка, 1990.