Software & Systems

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

Однако существующие средства для разработки интерфейса имеют ряд недостатков. Во-первых, их использование ухудшает модифицируемость ядра ЭС, так как интерфейс в ЭС обычно управляется машиной логического вывода, поэтому для получения приемлемого объяснения и диалога приходится структурировать и расширять базу знаний. Во-вторых, их использование не позволяет легко модифицировать сам интерфейс. Причиной этого также является жесткая зависимость интерфейса от ядра ЭС. В-третьих, процесс создания интерфейса очень трудоемок. Так, Goodall [8] утверждает, что в типичной ЭС приблизительно 70 % времени уходит на разработку интерфейса, который занимает в среднем 44 % кода, в то время как машина логического вывода занимает 8 % кода, база знаний – 22 %. Причинами этого являются наличие большого числа понятий предметной области, характеризующих исходные данные задачи, а также совместное проектирование интерфейса с базой знаний и машиной вывода. В-четвертых, объяснительные способности ЭС не удовлетворяют требованиям конечных ее пользователей. Это связано с тем, что в данный момент не существует универсальной концепции построения объяснения, ориентированной на индивидуальных пользователей ЭС.

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

Анализируя ЭС, существующие средства для их разработки, были сформулированы требования к разработке гибкого интерфейса в ЭС.

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

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

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

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

5. Интерфейс в ЭС должен иметь систему помощи пользователю.

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

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

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

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

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

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

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

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

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

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

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

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

·     формирование системы ввода исходных данных в ЭС в диалоговом режиме с использованием окон и меню по описанию знаний об исходных данных;

·     коррекция системы ввода в соответствии с изменениями в сценарии диалога;

·     редактирование существующей системы ввода в соответствии с требованиями пользователя;

·     формирование общей заставки системы;

·     организация ключа архива;

·     запись сценария диалога в библиотеку сценариев.

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

-    выбор сценария из библиотеки;

-    интерпретация сценария (управление вводом исходных данных);

-    просмотр введенных данных и их редактирование;

-    пополнение значений ключей архива;

-    запись введенных данных в архив с заданным ключом архива;

-    извлечение данных из архива;

-    печать введенных данных в структурированном виде;

-    запись в файл введенных данных в виде кортежей отношений для ввода их в ЭС.

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

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

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

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

Разработка интерфейса для ввода исходных данных последовательно выполняет:

-    формирование базы знаний об исходных данных;

-    представление базы знаний на языке описания сценариев диалога;

-    формирование диалоговой системы ввода исходных данных.

Разработка интерфейса для объяснений последовательно проходит следующие этапы:

-    спецификацию структуры и содержания объяснений;

-    разработку библиотеки алгоритмов формирования объяснений по результатам работы ЭС;

-    разработку библиотеки описаний объяснений для различных пользователей на языке ДОК.

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

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

Применение. Инструментарий для разработки гибкого интерфейса в ЭС использовался при разработке ЭС медицинской диагностики "Консультант-2 "[14], проблемной областью которой является диагностика некоторых острых хирургических заболеваний органов брюшной полости. База знаний ЭС состоит из разделов наблюдений и частной патологии. Знания об исходных данных задачи образует раздел наблюдений базы знаний ЭС, который определяет структуру и содержание вводимой в диалоге информации. Описание объяснения на языке ДОК включает описание истории болезни, предполагаемого диагноза ЭС, а также обоснования диагноза.

Система организации диалогового ввода исходных данных использована как независимое инструментальное средство для разработки системы интеллектуальной поддержки обследования больных [15]. Система предназначена для использования медицинскими учреждениями с целью интеллектуальной поддержки медицинской деятельности, связанной с обследованием больных и ведением их историй болезни. Система содержит разделы базы знаний, содержащие схемы обследования больного следующими специалистами: терапевтом, невропатологом, эндокринологом, хирургом, иммунологом, окулистом, отоларингологом, урологом, гинекологом. База знаний каждого из разделов медицины содержит от 500 до 5500 вершин, а всего – 15500 вершин.

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

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

1. BerryDianne C., Broadbent Donald E. Expert System and the man-machine interface. Part two. The user interface. "Expert System", 1987, 4 № l, 18-28.

2. Clancey W., Richer M. Guidon-Watch: A graphic interface for viewing a knowledge-based system //IEEE Computer Graphics @ Applications.-1985. -№ l1, p.51-64.

3. Cooper M., Kidd A. Man-machine interface issues in the construction and use of an expert system// Int.Joumal of Man-Machin Studies-1885.-p.91-102.

4. Gilbert Nigel Explanation and dialoque//Knowl.Eng.Rev..-1989.-4, № 3 -p.235-247.

5. Hendler J., Lewis C. Introduction: Designing interface for expert systems. In J. Hendler, Expert Systems: the User Interface, Ablex Publishing Corp., 1988, p.1-13.

6. Lane С., J. Walton, E. Shortliffe "Graphical access to medical expert systems: II. Design of an inerface for physicians", Metods of Information in Medicine, 25(3): 143-150, 1986.

7. Lowgren J. The IGNATIUS environment: Supporting the design and development of expert-system user interfaces //IEEE Expert.-1992. V.7. № 4, p.49-57.

8. Goodall A. The Guide to Expert Systems. Learned Information, Oxford, 1985.

9. Betts В., Burlingame D., Fisher G., Foley J., Green M. Goals and objectives for user interface software. Computer Graphics, 21(2): 73-78, 1987.

10. Muers В. User-Interface tools: Introduction and survey. IEEE Software, p. 15-23, Jan., 1989.

11. Грибова В.В., Клещев А.С. Модели диалога для управления исходными данными в ЭС. –Владивосток, 1997. - 25 с.(Препр. ИАПУ ДВО РАН).

12. Грибова В.В., Клещев А.С. Модель объяснения в экспертных системах. – Владивосток, 1997. -34 с. (Препр. ИАПУ ДВО РАН).

13. Грибова В.В., Клещев А.С. Система ДОК формирования документов. Описание языка формирования документов. –Владивосток, 1993. - 40с. (Препр. ИАПУ ДВО РАН).

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

15. Лифшиц А.Я., Онокиенко С.Б., Черняховская М.Ю. Система интеллектуальной поддержки обследования больных для страховой медицины // Теория и практика систем с базами знаний. – Владивосток: ДВО РАН, 1994. С. 223-238.