« А. П. Частиков Т. А. Гаврилова Д. Л.Белов РАЗРАБОТКА ЭКСПЕРТНЫХ СИСТЕМ. СРЕДА CLIPS Санкт-Петербург «БХВ-Петербург» 2003 ...»

Необходимость разработки теоретических основ науки о методах разработки систем, основанных на знаниях — инженерии знаний — обосновывается в работах Д. А. Поспелова, Э. В. Попова, В. Л. Стефанюка, Р. Шенка, М. Минского — ведущих специалистов в области ИИ в России и за рубежом. Первые шаги в создании методологии (работы Г. С. Осипова, В. Ф. Хо­рошевского, А. М. Яшина, В. Wielinga и др.) фактически являются пионерскими и чаще всего ориентированы на определенный класс задач, моделируемых в рамках конкретного программного инструментария.

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

2.6.1. Теоретические предпосылки

Стадия концептуального анализа или структурирования знаний традицион­но является (наряду со стадией извлечения) "узким местом" в жизнен­ном цикле разработки интеллектуальных систем [Adeli, 1994J. Методология структурирования близка к современной теории больших систем [Гиг, 1981] или сложных систем [Courtois, 1985], где традиционно акцент делается на процессе проектирования [Bertalanffy, 1950; Boulding, 1956]. Большой вклад в эту теорию внесли классики объектно-ориентированного анализа [Буч, 1992].

Разработку интеллектуальных систем с уверенностью можно отнести к дан­ному классу задач, поскольку они обладают основными признаками слож­ности (иерархия понятий, внутриэлементные и межэлементные связи и пр.). Аналогичные концепции, но связанные не с общесистемными исследова­ниями, а рассматривающие информационные процессы в системах, таких как связь и управление, положили начало кибернетике как самостоятельной науке [Винер, 1958; Эшби, 1959]. Позднее, в 1960-х гг. были получены но­вые результаты по развитию математической теории систем высокого уров­ня общности [Месарович, Такахара, 1978]. Существенный вклад в теорию систем и основы структурирования внесли отечественные исследователи [Моисеев, 1981; Глушков, 1964; Ивахненко, 1971; Поспелов, 1986] и др.

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

Проектирование сложных систем и методы структурирования информации традиционно использовали иерархический подход [Месарович, Такахара, 1978] как методологический прием расчленения формально описанной сис­темы на уровни (или блоки, или модули). На высших уровнях иерархии ис­пользуются наименее детализованные представления, отражающие только самые общие черты и особенности проектируемой системы. На следующих уровнях степень подробности возрастает, при этом система рассматривается не в целом, а отдельными блоками.

На каждом уровне вводятся свои представления о системе и элементах. Элемент k-го уровня является системой для (k — 1) уровня. Продвижение от уровня к уровню имеет строгую направленность, определяемую стратегией проектирования — дедуктивную нисходящую "сверху вниз" (top-down) или индуктивную восходящую "снизу вверх" (bottom-up).

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

Рис. 2.21 иллюстрирует дуальную концепцию при проектировании Sf для ЭС помощи оператору энергетического блока

Рис. 2.21. Дуальная стратегия проектирования

Нисходящая концепция (top-down) декларирует движение от п => п + 1, где n — п-й уровень иерархии понятий ПО (предметной области) с последующей детализацией понятий, принадлежащих соответствующим уровням.

STRtd : Pin, …, Pin+1 => Pkin+1

где:

• п — номер уровня порождающего концепта;
• i — номер порождающего концепта;
• ki — число порождающих концептов, сумма всех ki по i составляет общее число концептов на уровне п + 1.

Восходящая концепция (bottom-up) предписывает движение п => п — 1 с последовательным обобщением понятий.

STRbu : Pin, …, Pkin+1 => Pin-1

где:

• п — номер уровня порождающих концептов;
• i — номер порождаемого концепта;
• ki — число порождающих концептов, сумма всех ki по i составляет общее число концептов на уровне п.

Основанием для прекращения агрегирования и дезагрегирования является полное использование словаря терминов, которым пользуется эксперт, при этом число уровней является значимым фактором успешности структурирования.

В целом существующие подходы к проектированию сложных систем можно разделить на два больших класса:

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

В структурном анализе [Yourdon, 1989] разработано большое число выразительных средств для проектирования, в том числе графических [Буч, 1991]:

• диаграммы потоков данных (DFD, data-flow diagrams), структурирован­ные словари (тезаурусы), языки спецификации систем, таблицы решений;
• стрелочные диаграммы "объект-связь" (ERD, entity-relationship diagrams), диаграммы переходов (состояний);
• деревья целей;
• блок-схемы алгоритмов (в нотации Насси— Шнейдермана, Фестля и др.);
• средства управления проектом (PERT-диаграммы, диаграммы Ганта и др.).

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

Объектный (объектно-ориентированный) подход (ООП) был разработан в 1979 году [Jones, 1979], а затем развит в работах [Peters, 1981; Shaw, 1984; Буч, 1993].

ООП, возникший как технология программирования больших программных продуктов, базируется на основных элементарных понятиях [Буч, 1993]:

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

ООП имеет систему условных обозначений и предлагает набор моделей для проектирования сложных систем. Широкое распространение объектно-ориентированных языков программирования C++, CLOS, Smalltalk и др. успешно демонстрируют жизнеспособность и перспективность этого подхода. В последнее время этот подход успешно применяется и в CASE-средствах не только для проектирования программ, но и для моделирования бизнес-процессов. Особенную популярность приобретает язык UML (Unified Modelling Language) [Буч, Рамбо, Джекобсон, 2000], и программный инстру­ментарий на нем основанный, например Rational Rosex [Боггс, 2001].

2.6.2. Объектно-структурный подход (ОСП)

В качестве базисной парадигмы структурного анализа знаний и формирования поля знаний pz можно предложить обобщенный объектно-структурный подход (ОСП) [Гаврилова, 1995].

Основные постулаты этой парадигмы заимствованы из ООП и расширены:

1. Системность (взаимосвязь между понятиями).
2. Абстрагирование (выявление существенных характеристик понятия, которые отличают его от других).
3. Иерархия (ранжирование на упорядоченные системы абстракций).
4. Типизация (выделение классов понятий с частичным наследованием свойств в подклассах).
5. Модульность (разбиение задачи на подзадачи или "возможные миры").
6. Наглядность и простота нотации.

Использование пятого постулата ОСП в инженерии знаний позволяет стро­ить глобальные БЗ с возможностью выделить локальные задачи с помощью горизонтальных и вертикальных сечений (см. ниже) на отдельные модули пространства-описания предметной области.

Шестой постулат внесен в список последним, но не по значимости. В инженерии знаний формирование pz традиционно является критической точ­кой [Гаврилова, Червинская, Яшин, 1988; Гаврилова, Червинская, 1992], т. к. создаваемая неформальная модель предметной области должна быть предельно ясной и лаконичной. Традиционно языком инженерии знаний были диаграммы, таблицы и другие графические элементы, способствующие наглядности представлений. Именно поэтому предлагаемый подход к струк­турированию связан с возможной визуализацией процесса проектирования.

ОСП позволяет наглядно и компактно отобразить объекты и отношения предметной области на основе использования шести постулатов.

Объектно-структурный подход подразумевает интегрированное использова­ние сформулированных выше постулатов от первой до последней стадий разработки БЗ интеллектуальных и обучающих систем. На основе ОСП предлагается алгоритм объектно-структурного анализа (ОСА) предметной области, позволяющего оптимизировать и упорядочить достаточно размы­тые процедуры структурирования знаний.

Стратификация знаний

Основы ОСА были предложены автором еще в работах [Гаврилова, 1989; Гаврилова, Красовская, 1990], и успешно применялись при разработке ЭС МИКРОЛЮШЕР [Гаврилова, Тишкин, Золотарев, 1989] и АВЭКС [Гаврилова, Минкова, Карапетян,1992].

ОСА подразумевает дезагрегацию ПО, как правило, на восемь страт или слоев (табл. 2.1 и 2.2).

Таблица 2.1. Стратификация знаний предметной области

Страта	Вид знаний страты	Уровни страты
s_2	ЗАЧЕМ-знания	Стратегический анализ: назначение и функции системы
s_2	КТО-знания	Организационный анализ: коллектив разработчиков системы
s 3	ЧТО-знания	Концептуальный анализ: основные концепты, понятийная структура
s_4	КАК-знания	Функциональный анализ: гипотезы и модели принятия решения
s_5	ГДЕ-знания	Пространственный анализ: окружение, оборудование, коммуникации
s_6	КОГДА-знания	Временной анализ: временные параметры и огра­ничения
s_7	ПОЧЕМУ-знания	Каузальный или причинно-следственный анализ: формирование подсистемы объяснений
s 8	СКОЛЬКО-знания	Экономический анализ: ресурсы, затраты, прибыль, окупаемость

Объектно-структурный анализ подразумевает разработку и использование матрицы ОСА (табл. 2.2), которая позволяет всю собранную информацию дезагрегировать последовательно по слоям-стратам (вертикальный анализ), а затем по уровням — от уровня проблемы до уровня подзадачи (горизон­тальный анализ). Или наоборот — сначала по уровням, а потом по стратам.

Таблица 2.2. Матрица объектно-структурного анализа

Уровни страты	Уровень области u1	Уровень проблемы u2	Уровень задачи u3	Уровень подзадачи u4	...	un
Стратегический анализ s1	Е11	Е12	Е13	Е14		Е1n
Организационный анализ s2	Е21
Концептуальный анализ s3	Е31
Функциональный анализ s4	Е41
Пространственный анализ s5	E51
Временной анализ s6	Е61
Каузальный анализ s7	Е71
Экономический анализ s8	Е81
……					Еij
sm	Еm1					Еmn

При необходимости число страт может быть увеличено. В свою очередь знания каждой страты подвергаются дальнейшему ОСА и декомпозируются на составляющие \\етn\\, где т — номер уровня, п — номер страты, а етп принадлежит множеству К всех концептов (понятий) предметной области.

Алгоритм ОСА (объектно-структурного анализа)

Алгоритм ОСА предназначен для детального практического структурирова­ния знаний предметной области (ПО). В основе ОСА заложен алгоритм за­полнения ОСА-матрицы Етп. Алгоритм содержит последовательность ана­литических процедур, позволяющих упростить и оптимизировать процесс структурирования. Алгоритм разделяется на две составляющие:

• А_I: Глобальный (вертикальный) анализ, включающий разбиение ПО на методологические страты (Что-знания, Как-знания и т. д.) на уровне всей ПО. В результате заполняется первый столбец матрицы.
• А_II: Анализ страт (горизонтальный), включающий построение многоуровневых структур по отдельным стратам. Число уровней п определяется особенностями стратифицированных знаний ПО и может существен­но отличаться для разных страт. С точки зрения методологии n<3 свидетельствует о слабой проработке ПО.

Первый уровень соответствует уровню всей ПО (предметной области). Второй — уровню проблемы, выделенной для решения. Третий — уровню кон­кретной решаемой задачи. Дальнейшие соответствуют подзадачам, если имеет смысл их выделять.

При этом возможно как последовательное применение восходящей (bottom-up) и нисходящей концепции (top-down), так и их одновременное приме­нение.

Глобальный анализ

Технология глобального анализа сводится к разбиению пространства основ­ной задачи структурирования ПО на подзадачи, соответствующие особенно­стям ПО. Для разработки интеллектуальных систем существует минималь­ный набор s-страт, обеспечивающий формирование БЗ. Минимальный на­бор включает три страты:

• s3, — формирование концептуальной структуры Sk;
• s4 — формирование функциональной структуры Sf,
• s5 — формирование подсистемы объяснений S0.

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

Алгоритм А__1 глобального анализа может быть кратко сформулирован сле­дующим образом:

• А_1__1: Собрать все материалы, полученные по результатам извлечения знаний.
• А_1_2: Выбрать набор страт N, подлежащих формированию (Nmin= 3).
• А_1__3: Отобрать всю информацию по первой выбранной страте (i= 1, где i — номер из выбранного набора страт N).
• А_1_4: Повторить шаг А_1_3 для i + 1 для всех выбранных страт до i <= N.
• А_1_5: Если часть информации останется неиспользованной, увеличить число страт и повторить для новых страт шаг А_1_3; иначе перейти к последовательной реализации алгоритмов горизонтального анализа страт А_2.

Анализ страт

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

Ниже предлагается алгоритм ОСА для одной из обязательных страт s3, (ЧТО-анализ), результатом которого является формирование концептуаль­ной структуры предметной области Sk.

• А_2_3_1: Из группы информации, соответствующей ЧТО-страте, выбрать все значимые понятия и сформулировать соответствующие концепты.
• А_2_3_2: Выявить имеющиеся иерархии и зафиксировать их графически в виде структуры.
• А_2_3_3: Детализировать концепты, пользуясь нисходящей концепцией (top-down).
• А_2__3__4: Образовать метапонятия по восходящей концепции (bottom-up).
• А_2_3_5: Исключить повторы, избыточность и синонимию.
• А_2_3_6: Обсудить понятия, не вошедшие в структуру Sf, с экспертом и перенести их в другие страты или исключить.
• А_2_3_7: Полученный граф или набор графов разделить на уровни и обозначить согласно матрице ОСА.

2.6.3. Практические методы структурирования

Методы извлечения знаний, рассмотренные выше, являются непосредст­венной подготовкой к структурированию знаний. Данный раздел посвящен изучению практических методов структурирования знаний.

Алгоритм для "чайников"

В качестве простейшего прагматического подхода к формированию поля знаний начинающему инженеру по знаниям можно предложить следующий алгоритм для "чайников" (рис. 2.22):

1. Определение входных {X} и выходных {Y\ данных. Этот шаг совершенно необходим, т. к. он определяет направление движения в поле знаний —от X к Y. Кроме того, структура входных и выходных данных существенно влияет на форму и содержание поля знаний. На этом шаге определение может быть достаточно размытым, в дальнейшем оно будет уточняться.
2. Составление словаря терминов и наборов ключевых слов N. На этом шаге проводится текстуальный анализ всех протоколов сеансов извлечения знаний и выписываются все значимые слова, обозначающие понятия, явления, процессы, предметы, действия, признаки и т. п. При этом следует попытаться разобраться в значении терминов. Важен осмысленный словарь.
3. Выявление объектов и понятий {А}. Производится "просеивание" словаря N и выбор значимых для принятия решения понятий и их признаков. В идеале на этом шаге образуется полный систематический набор терминов из какой-либо области знаний.

4. Построение пирамиды знаний. Под пирамидой знаний мы понимаем иерархическую лестницу понятий, подъем по которой означает углубле­ние понимания и повышения уровня абстракции (обобщенности) поня­тий. Количество уровней в пирамиде зависит от особенностей предмет­ной области, профессионализма экспертов и инженеров по знаниям.
5. Определение отношений {RA}. Отношения между понятиями выявляются как внутри каждого из уровней пирамиды, так и между уровнями. Фак­тически на этом шаге даются имена тем связям, которые обнаруживают­ся на шагах 4 и 5, а также обозначаются причинно-следственные, лингвистические, временные и другие виды отношений.
6. Определение стратегии принятия решения (Sf). Определение стратегии принятия решения, т. е. выявление цепочек рассуждений, связывает все сформированные ранее понятия и отношения в динамическую систему поля знаний. Именно стратегии придают активность знаниям, именно они "перетряхивают" модель М в поиске от X к У.
7. Завершающее структурирование поля. Подразумевает упорядочивание полученной структуры, удаление дублирующих или лишних деталей, кор­ректировку и уточнение всех конструкций.

Однако на практике при использовании данного алгоритма можно столк­нуться с непредвиденными трудностями, связанными с ошибками на стадии извлечения знаний и с особенностями знаний различных предметных об­ластей. Тогда возможно привлечение других, более "прицельных" методов структурирования. При этом на разных этапах схемы (см. рис. 2.22) воз­можно использование различных методик.

При этом, естественно, для таких простых и очевидных шагов, как опреде­ление входных и выходных понятий или составление словаря терминов, ни­каких искусственных методов предлагаться не будет.

Методы выявления объектов, понятий и их атрибутов

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

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

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

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

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

Все методы выявления понятий мы разделили на :

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

Если первые достаточно хорошо освещены в литературе, то вторые пока менее известны.

Интересный эксперимент по выявлению понятий описан в [Кук, Макдональд, 1986]. Тридцати студентам, имеющим права на вождение автомобиля, предложили составить словарь терминов предметной области с помощью

четырех методов:

• формирования перечня понятий (17%);
• интервьюирования специалистов (35%);
• составление списка элементарных действий (18%);
• составления оглавления учебника (30%).

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

Таблица 2.3. Данные концептуализации

Категории терминов	Процент от общего числа терминов	Процент от общего числа терминов, полученный соответствующим методом
		Перечень понятий	Интервьюи­рование	Список операций	Составление оглавления
Объяснение	6	5,5	7,2	7,0	4,9
Общие правила	22,0	43,6	18,9	36,8	4,9
Режимные	9,0	9,8	8,4	11,6	6,6
правила
Понятия	42,0	18,4	38,9	8,5	77,7
Процедуры	9,0	5,1	9,5	25,6	1,2
Факты	9,0	15,0	12,5	8,9	1,2
Прочие понятия	3,0	2,6	4,6	1,6	3,5

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

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

Методы выявления связей между понятиями

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

В работах по теории ИИ все больше внимания уделяется взаимосвязанности структур знаний. Так, в [Шенк, Бирнбаум, Мей, 1989] введено понятие сценария (script) как некоторой структуры представления знаний. Основу сценария составляет КОП (Концептуальная Организация Памяти) и мета-КОПЫ — некоторые обобщающие структуры.

Сценарии, в свою очередь, делятся на фрагменты — или сцены (chunks). Связи между фрагментами — временные или пространственные, внутри фрагмента — самые различные: ситуативные, ассоциативные, функциональные и т. д.

Все методы выявления таких связей можно разделить на две группы:

• формальные;
• неформальные (основаны на дополнительной работе с экспертом).

Неформальные методы выявления связей придумывает инженер по знаниям для того, чтобы вынудить эксперта указать явные и неявные связи между понятиями. Наиболее распространенным является метод "сортировка карто­чек" в группы [Волков, Ломнев, 1989; Rabbits, Wright, 1987], широко приме­няемый и для формирования понятий. Другим неформальным методом яв­ляется построение замкнутых кривых. В этом случае эксперта просят обвес­ти замкнутой кривой связанные друг с другом понятия [Olson, Reuter, 1987]. Этот метод может быть реализован как на бумаге, так и на экране дисплея. В данном случае можно говорить о привлечении элементов когнитивной графики [Зенкин, 1991].

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

Методы выделения метапонятий

и детализация понятий (пирамида знаний)

Процесс образования метапонятий, т. е. интерпретации групп понятий, по­лученных на предыдущей стадии, как и обратная процедура — детализация (разукрупнение) понятий, — видимо, принципиально не поддающиеся формализации операции. Они требуют высокой квалификации экспертов, а также наличия способностей к "наклеиванию" лингвистических ярлыков. Если на рис. 2.23 показаны схемы обобщения и детализации на тривиаль­ных примерах, то в реальных предметных областях эта задача оказывается весьма трудоемкой. При этом независимо от того, формальными или не­формальными методами были выявлены понятия или детали понятий, при­своение имен которым или интерпретация их — всегда неформальный про­цесс, в котором инженер по знаниям просит эксперта дать название неко­торой группе понятий или отдельных признаков.

Рис. 2.23. Обобщение и детализация понятий

Это не всегда удается. Так, в системе АВТАНТЕСТ [Гаврилова, 1984] при образовании метапонятий, полученных методами кластерного анализа, ин­терпретация заняла несколько месяцев. Это связано с тем, что формальные методы иногда выделяют "искусственные" концепты, в то время как нефор­мальные обычно — практически используемые и потому легко узнаваемые понятия.

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

Построение пирамиды знаний может быть основано и на естественной иерархии предметной области, например связанной с организационной структурой предприятия или с уровнем компетентности специалистов (рис. 2.24).

Методы определения отношений

Если на стадии 4 (см. рис. 2.22) мы выявили связи между понятиями и использовали их на стадиях 5 и 6 для получения пирамиды знаний, то на ста­дии 7 мы даем имена связям, т. е. превращаем их в отношения.

В [Поспелов, 1986] указывается на наличие более 200 базовых видов раз­личных отношений, существующих между понятиями. Предложены различ­ные классификации отношений [Келасьев, 1984; Поспелов, 1986]. Следует только подчеркнуть, что помимо универсальных отношений (пространст­венных, временных, причинно-следственных) существуют еще и специфи­ческие отношения, присущие той или иной предметной области [Гаврилова, Червинская, Яшин, 1988].

Интересные возможности к структурированию знаний добавляют системы когнитивной графики. Так, в системе OPAL [Olton, Musen, Combs et al., 1987] эксперт может манипулировать на экране дисплея изображениями простейших понятий и строить схемы лечения заболеваний, обозначая от­ношения явными линиями, которые затем именуются.

Скудность методов структурирования объясняется тем, что методологиче­ская база инженерии знаний только закладывается, а большинство инжене­ров по знаниям проводит концептуализацию, руководствуясь наиболее до­рогими и неэффективными способами — ad hoc (применительно к случаю), или "по наитию", т. е. исходя из соображений здравого смысла.

Визуальное структурирование

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

В разд. 2.7.7 было предложено определение поля знаний, которое позволяет инженеру по знаниям трактовать форму представления поля достаточно широко, в частности семантические сети или понятийные карты (concept maps) являются возможной формой представления. Это означает, что сам процесс построения семантических сетей помогает осознавать познаватель­ные структуры.

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

Рис. 2.25. Пример семантической сети

Нами разработано несколько версий АРМа (Автоматизированное Рабочее Место) инженера по знаниям KEW (Knowledge Engineering Workbench) [Гаврилова, 1995, Гаврилова, Воинов, 1995—1997], которые наряду с такими программами, как SemNet [Fisher, 1992], Learning Tool [Kozma, 1987], TextVision [Kommers, 1989] или Inspiration, дают возможность ученикам, экспертам или аналитикам связать между собой изучаемые ими понятия в многомерные сети представлений и описать природу связей между всеми входящими в сеть понятиями.

Одна из версий KEW, созданная совместно с А. В. Воиновым, получила первую премию на выставке программных систем IV Национальной конфе­ренции по искусственному интеллекту в 1994 году в разделе программных инструментариев разработки интеллектуальных систем. KEW демонстрирует жизнеспособность технологии автоматизированного проектирования интел6лектуальных систем (АПРИС) или CAKE (Computer Aided Knowledge Engineering), впервые описанной в работе [Гаврилова, 1992]. Последняя вер­сия САКЕ-2 создана Т. Е. Гелеверей и успешно применяется на практике (www.csa.ru/ailab).

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

Центральным блоком KEW является графический структуризатор знаний, который поддерживает последовательную графическую реализацию ОСА (см. разд. 2.6.2) и автоматическую компиляцию БЗ из графической специ­фикации.

Интерфейс KEW состоит из трех основных частей (рис. 2.26):

• панель концептуальной структуры;
• панель гипертекста;
• панель функциональной структуры.

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

Рис. 2.26. Интерфейс АРМ инженера по знаниям.

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

Основное назначение панели функциональной структуры Sf — представить наглядно в форме строк таблицы причинно-следственные и другие функ­циональные взаимосвязи между понятиями концептуальной структуры, на основании которых эксперт принимает решения. Столбцы таблицы форми­руются простейшей операцией drag-and-drop из понятий на панели концеп­туальной структуры.

После того как модели Sk и Sf созданы, KEW автоматически компилирует базу знаний на Прологе из созданной графической спецификации и моде­лирует работу экспертной системы. Это удобно для быстрого наглядного прототипирования ЭС и для отладки БЗ совместно с экспертом.

ЧАСТЬ II.Общие понятия.

Глава 3. Что такое CLIPS?

Глава 4. Обзор возможностей CLIPS.

ГЛАВА 3. Что такое CLIPS?.

Первоначально аббревиатура CLIPS была названием языка — С Language Integrated Production System (язык С, интегрированный с продукционными системами), удобного для разработки баз знаний и макетов экспертных сис­тем. Теперь CLIPS представляет собой современный инструмент, предна­значенный для создания экспертных систем (expert system tool). CLIPS со­стоит из интерактивной среды — экспертной оболочки со своим способом представления знаний, гибкого и мощного языка и нескольких вспомога­тельных инструментов. Сейчас, благодаря доброй воле своих создателей, CLIPS является абсолютно свободно распространяемым программным продуктом. Всем желающим доступен как сам CLIPS последней версии, так и его исходные коды. Официальный сайт CLIPS располагается по адресу: http://www.ghg.net/clips/CLIPS.html (рис. 3.1). Этот сайт поможет вам получить как сам CLIPS, так и всевозможный материал для его изучения и освоения (документацию, примеры, советы специалистов, исходные коды и многое другое).

Сейчас на рынке доступно не так уж много экспертных оболочек (инстру­ментов, предназначенных для создания экспертных систем). Несмотря на то, что CLIPS распространяется бесплатно, он весьма успешно конкурирует даже с самыми известными коммерческими проектами. Количество пользо­вателей CLIPS растет из года в год. Об этом можно судить по активности посещения сайтов, форумов и конференций, посвященных CLIPS. Если вы еще не установили CLIPS на свой компьютер — возможно, самое время сделать это. А пока, для того чтобы лучше понять философию CLIPS, его возможности и особенности, погрузимся в историю создания этой системы.

Рис. З.1. Домашняя страница CLIPS

3.1. История создания CLIPS

Появление языка CLIPS можно датировать 1984 г., место рождения CLIPS — космический центр Джонсона NASA. Именно в это время отдел искусственного интеллекта (теперь Software Technology Branch) разработал множе­ство прототипов экспертных систем, использующих современное программ­ное и техническое обеспечение. Однако, несмотря на большой потенциал экспертных систем, не многие из этих приложений дошли до конечного потребителя. Эта неудача обуславливалась технологией создания экспертных систем, которой в то время оперировали в NASA. Основные ограничения накладывал язык LISP, используемый в качестве базового языка для разра­ботки экспертных систем. В качестве главных недостатков языка LISP можно выделить следующие три:

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

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

Прототип CLIPS был разработан весной 1985 г., немногим более чем за два месяца. Особое внимание было уделено созданию языка, совместимого с языками, использующимися в NASA в тот момент. Таким образом, син­таксис языка CLIPS был сделан очень похожим на синтаксис экспертной оболочки ART, разработанной корпорацией Inference. Несмотря на то, что ART послужил прообразом, CLIPS разрабатывался совершенно без помощи Inference или доступа к исходным кодам системы ART.

Основной целью прототипа CLIPS было создание языка, способного решать задачи, опираясь на концепцию знаний. Версия 1.0 продемонстрировала выполнимость концепций проекта. После дополнительной разработки стало очевидно, что CLIPS может стать дешевым инструментом для создания экс­пертных систем, моделирования и обучения. После еще одного года разра­ботки и внутреннего использования CLIPS заметно улучшил такие свойст­ва, как портативность, производительность и функциональность. Версия CLIPS 3.0 была выпущена летом 1986 г.

Дальнейшее усовершенствование преобразовало CLIPS из инструмента тре­нировки в инструмент, незаменимый при проектировании, разработке и эксплуатации экспертных систем. Версии CLIPS 4.0 и 4.1 были реализованы соответственно летом и осенью 1987 г. Их характерными особенностями были: сильно увеличенная производительность, усовершенствованные воз­можности интеграции с внешними языками и увеличение потенциальных возможностей. Версия CLIPS 4.2, реализованная летом 1988 г., была пол­ностью переписанной версией CLIPS, позволяющей модульную обработку кода. Кроме того, с этой версией поставлялся справочник по архитектуре, предоставляющий детализированное описание архитектуры CLIPS, а также вспомогательная программа для верификации программ, базирующихся на правилах. Версия CLIPS 4.3 вышла летом 1989 г. и добавила системе еще большую функциональность.

Первоначально CLIPS использовал только методологию обработки данных посредством правил. CLIPS версии 5.0, вышедший весной 1991 г., ввел в CLIPS две новые парадигмы программирования: процедурное программирование (подобное используемому в языках С или Ada) и объектно-ориен­тированное программирование (похожее на языки Common Lisp Object System — CLOS или Smalltalk). Объектно-ориентированный язык програм­мирования, предоставляемый системой CLIPS, называется CLIPS Object-Oriented Language (COOL). Версия CLIPS 5.1, вышедшая осенью 1991 г., улучшала поддержку разработок с использованием новых возможностей CLIPS и усовершенствовала интерфейс CLIPS для X Window, MS-DOS и Macintosh. Версия CLIPS 6.0, вышедшая 1993 г., предоставляла поддержку разработки модульных программ и тесную интеграцию объектно-ориентиро­ванных возможностей CLIPS и возможностей, базирующихся на правилах.

Так как CLIPS обладал портативностью, расширяемостью, мощностью и низкой стоимостью, он получил широкое распространение в государствен­ных организациях, индустрии и учебных заведениях. Разработка CLIPS по­могла усовершенствовать возможности технологии производства экспертных систем среди широкого диапазона приложений. Система CLIPS использует­ся большим числом организаций, включая все отделения NASA, военные ведомства США, множество федеральных, правительственных и государст­венных организаций, университеты и большое число частных компаний.

CLIPS версии 6.1 был выпущен летом 1998 г. Очередная версия содержала несколько существенных улучшений. Во-первых, исходный код CLIPS стал совместим с C++. Теперь для его компиляции можно использовать любой ANSI С- или С++-компилятор. Во-вторых, в систему были добавлены не­сколько новых команд, предоставляющие возможность профилирования по времени выполнения конструкторов языка или определенные пользователем функций.

Последняя, доступная сейчас версия CLIPS 6.2, вышла в свет 31 марта 2002 г. Основными отличиями новой версии CLIPS являются поддержка разработки встроенных приложений, использующих CLIPS, и улучшенный интерфейс для Windows-версии, оптимизированный для использования на платформах Windows 95/98/NT.

Благодаря тому, что CLIPS является свободно распространяемым про­граммным продуктом с доступными исходными кодами, в последнее время было выпущено множество программ и библиотек, усовершенствующих и дополняющих возможности CLIPS. Некоторые из этих продуктов являются собственностью выпустивших их компаний и предназначены для внутреннего использования или коммерческого распространения, другие, как и сам CLIPS, распространяются свободно. В качестве самых известных примеров подобных проектов можно привести DLL/OCX-библиотеку, позволяющую использовать механизм логического вывода CLIPS в ваших приложениях, FuzzyCLIPS, CLIPS++, CLIPS code generator. Большинство перечисленных продуктов, а также различная полезная информация доступна по адресу: http://ourworld.compuserve.com/homepages/marktoml/clipstuf.htm (рис. 3.2).

Рис. 3.2. Домашняя страница CLIPS DLL/OCX

3.2. Работа с CLIPS

Для демонстрации примеров, используемых в этой книге, будет применяться Windows-версия CLIPS 6.2. Несмотря на полную совместимость с Apple Macintosh и UNIX-версиями, при работе с данной книгой желательно ис­пользовать именно Windows-версию среды CLIPS. Внешний вид главного окна CLIPS показан на рис. 3.3.

Windows-версия среды CLIPS полностью совместима с базовой специфика­цией языка. Ввод команд осуществляется непосредственно в главное окно CLIPS. Однако по сравнению с базовой Windows-версия предоставляет множество дополнительных визуальных инструментов (например, менедже­ры фактов или правил, речь о которых пойдет в гл. 5 и 6), значительно облегчающих жизнь разработчика экспертных систем.

Экспертные системы, созданные с помощью CLIPS, могут быть запущены тремя основными способами:

• вводом соответствующих команд и конструкторов языка непосредствен­но в среду CLIPS;
• использованием интерактивного оконного интерфейса CLIPS (например для версий Windows или Macintosh);
• с помощью программ-оболочек, реализующих свой интерфейс общения с пользователем и использующих механизмов знаний и логического вывода CLIPS.

Рис. 3.3. Главное окно CLIPS

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

• -f <имя-файла>
• -f2 <имя-файла>
• -l <имя-файла>

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

Опция -f2 идентична -f, но, в отличие от опции -f, она использует коман­ду batch*. Файл, заданный этой опцией, также выполняется после запуска CLIPS, но результаты выполнения команд не отображаются на экране.

Опция -l задает текстовый файл, содержащий конструкторы CLIPS, кото­рые тут же запускаются на выполнение. Использование этой опции эквива­лентно использованию команды load сразу после запуска CLIPS.

Создание программ-оболочек, использующих возможности CLIPS, выходит за рамки этой книги. Желающим использовать эту возможность CLIPS можно рекомендовать обратиться к книге "CLIPS Reference Manual, Volume II, Advanced Programming Guide ".

Основным методом общения с CLIPS, используемым в данной книге, явля­ется применение командной строки. После появления в главном окне CLIPS приглашения — CLIPS > — команды пользователя могут вводиться в среду непосредственно с клавиатуры. Команды могут быть вызовами сис­темных или пользовательских функций, конструкторами различных данных CLIPS и т. д. В случае вызова пользователем некоторой функции, она не­медленно выполняется, и результат ее работы отображается пользователю. Для вызова функций или операций CLIPS использует префиксную нота­цию — аргументы всегда следуют после имени функции или операции. При вызове конструкторов CLIPS создает новый объект соответствующего типа, так или иначе представляющий некоторые знания в системе. При вводе в среду имени созданной ранее глобальной переменной CLIPS отобразит ее текущее значение. Ввод в среду некоторой константы просто приведет к ее немедленному отображению в главном окне CLIPS. В качестве примера введите в среду следующие команды (листинг 3.1).

Листинг 3.1. Пример команд CLIPS

(+ 3 4)

(defglobal ?*x* = 3)

?*х*

red

Результат выполнения этих команд приведен на рис. 3.4.

Первой командой данного примера вызывается функция арифметического сложения двух чисел: 3 и 4. Результат работы этой функции — 7 сразу же отображается на экран. После этого, с помощью конструктора defglobal (см. гл. 7), создается глобальная переменная ?*х*, которая инициализируется значением 3. При вводе в командную строку имени глобальной переменной ?*х* CLIPS отображает ее текущее значение, равное 3. Последней командой была введена некая константа red, значение которой было тут же выведено на экран.

Рис. З.4. Результат выполнения команд листинга 3.1

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

3.3. Синтаксис определений

В качестве базового синтаксиса для определения конструкций языка ис­пользуется стандартная БНФ-нотация. Ниже приведены правила, исполь­зуемые для построения определений.

Слово или выражение, заключенное в угловые скобки, называется нетерми­нальным символом (например, <string>). Нетерминальный символ требует дальнейшего определения. Слова или выражения, не заключенные в угловые скобки, называются терминальными символами, и представляют синтаксис описываемой конструкции языка CLIPS. Терминальные символы (особенно круглые скобки) должны вводиться в командную строку именно так, как показано в определении. Если за нетерминальным символом следует символ *, то это означает, что в данном месте может находиться список из нуля или более элементов этого типа. Если же за нетерминальным символом следует +, то в данном месте может находиться список из одного или более элементов этого типа. Символы * и +, встречающиеся сами по себе (не сле­дующие после нетерминальных символов), являются терминальными. Мно­готочие, как горизонтальное, так и вертикальное, также используется для отображения списка из одного или более элементов. Элементы, заключен­ные в квадратные скобки (например, [<комментарии>]), являются необяза­тельными элементами, которые могут входить в определение. Вертикальная черта, разделяющая два или более элемента определения, указывает на то, что в конструкции необходимо использовать один из перечисленных эле­ментов. Символ ::= используется для обозначения необходимости замены некоторого нетерминального символа. Например, определение:

<lexeme> ::= <symbol> I <string>

обозначает, что нетерминальный символ <lexeme>, встречающийся в некотором определении, должен быть заменен либо на символ <symbol>, либо на символ <string>. Пробелы, символы табуляции, переходы на другую строку используются только для логического разделения элементов определения и игнорируются CLIPS (кроме строк, заключенных в двойные кавычки).

В приложении 1 обобщен список БНФ-определений общих конструкций языка, приведенных в книге.

ГЛАВА 4. Обзор возможностей CLIPS.

Настоящая глава посвящена обзору возможностей CLIPS, а также описанию основных концепций этой системы и терминов, применяемых в данной книге.

4.1. Основные элементы языка

Синтаксис языка CLIPS можно разбить на три основных группы элементов, предназначенных для написания программ:

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

Рассмотрим каждую из этих трех групп более подробно.

4.1.1. Типы данных

CLIPS поддерживает 8 примитивных типов данных: float, integer, symbol, string, external-address, fact-address, instance-name, instance-address.

Для хранения численной информации предназначаются типы float и integer, для символической — symbol и string.

Число в CLIPS может состоять только из символов цифр (0—9), десятичной точки (.), знака (+ или -) и экспоненциального символа (е) с соответст­вующим знаком, в случае представления числа в экспоненциальной форме. Ниже приведены примеры допустимых в CLIPS представлений целых и вещественных типов:

Пример 4.1. Представление чисел в CLIPS

Целые: 237 15 +12 -32

Вещественные: 237еЗ 15.09 +12.0 -32.3е-7

Определение целого значения можно представить таким образом:

Определение 4.1. Представление целого числа

<целое> ::= [+ | -] <цифра>+

<цифра> : := 0 | 1 2 | 3 | 4 5 6 | 7 | 8 | 9

Вещественное значение имеет следующий синтаксис:

Определение 4.2. Представление вещественного числа

<вещественное> ::= <целое> <экспонента> |

<целое>. [экспонента] |

<беззнаковое-целое> [экспонента] |

<целое>. <беззнаковое-целое> [экспонента]

<беззнаковое-целое> ::= <цифра>+

<экспонента> : : = е | E <целое>

Если последовательность символов не соответствует приведенным выше определениям целого или вещественного числа, то данная последователь­ность воспринимается CLIPS как значение типа symbol.

Значением типа symbol может быть любая последовательность символов, начинающаяся с любого не управляющего ASCII-символа. Значение типа symbol заканчивается ограничителем. Ограничителями являются любые не­отображаемые символы (например, пробел, символ табуляции или перехода на другую строку), двойные кавычки, открывающая или закрывающая круг­лая скобка, символы &, |, < и ~. Точка с запятой (;) является символом на­чала комментариев и также может ограничивать значение типа symbol. Сим­волы-ограничители не могут содержаться в значении symbol, за исключени­ем <, который может быть первым символом значения. Значение типа symbol не может начинаться с символа ? или $?, но может содержать эти символы. CLIPS является языком, чувствительным к регистру.

Замечание

Значения типов float и integer являются частным случаем значения типа symbol. Другими словами, они удовлетворяют всем ограничениям, налагаемым на значение типа symbol.

Ниже приведены несколько примеров значений типа symbol:

Пример 4.2. Допустимые значения типа symbol

foo Hello B76-HI bad_value

127A 456-93-039 @+=-% 2each

Значение типа, string представляет собой строку символов, заключенную в двойные кавычки. Символ двойных кавычек также может быть включен в строку. Для этого перед символом " необходимо поставить символ обратной косой черты (\). Для включения в строку символа обратной косой черты необходимо использовать два последовательных символа \. Примеры допустимых значений string приведены ниже:

Пример 4.3. Допустимые значения типа string

"foo" "a and b" "1 number" "a\”quote"

Замечание

Значение "abcd" типа string не эквивалентно значению abcd типа symbol. Не­смотря на то, что они состоят из идентичных символов, они относятся к разным типам.

Значение типа external-address представляет собой адрес структуры дан­ных, возвращенной внешней функцией (например, написанной на языке С или Ada), интегрированной с программой CLIPS. Значение этого типа мо­жет быть создано только посредством вызова внешней функции. Использова­ние внешних функций выходит за рамки данной книги, поэтому вы не найдете примеров создания и использования этого типа. В CLIPS значения данного типа отображаются следующим образом:

Пример 4.4. Значение типа external-address

<Pointer-XXXXXX>

где XXXXXX — число, представляющее внешний адрес.

Подробную информацию о типе external-address можно найти в книге "CLIPS Reference Manual, Volume II, Advanced Programming Guide".

Факт в CLIPS представляет собой список атомарных значений примитив­ных типов, ссылаться на которые можно либо используя порядок определе­ния этих значений, в случае упорядоченных фактов, либо по имени, в случае неупорядоченных фактов или шаблонов. Подробней понятие факта будет описано в гл. 5. Оперировать с фактом можно, используя его адрес (см. разд. 4.2.1). Адрес факта представляет собой значение типа fact-address.

Пример 4.5. Значение типа fact-address

<Fact-XXX>

где XXX представляет собой индекс факта.

Объект в CLIPS представляет собой экземпляр определенного пользовате­лем класса. Для определения класса используется конструктор defclass (см. разд. 11.2). Для создания объекта используется функция make-instance. Ссы­латься на объект можно либо по адресу, либо, в рамках отдельного модуля (см. гл. 12), по имени объекта. Тип instance-name предназначен для хране­ния значения имени объекта. Для представления имени используется зна­чение типа symbol, окруженное квадратными скобками ([ и ]). Ниже приве­дено несколько примеров допустимых значений типа instance-name:

Пример 4.6. Значения типа instance-name

[pump-l] [foo] [+++] [123-890]

Замечание

Квадратные скобки не являются частью имени объекта, а служат своеобразны­ми ограничителями, которые позволяют системе отличать значение типа instance-name от значения типа symbol.

Тип instance-address предназначен для хранения значения, представляю­щего адрес объекта. Значение этого типа может быть получено посредством вызова функции instance-address или в результате выполнения операции сопоставления образцов в правиле (см. гл. 6). Ссылки на объект, с исполь­зованием значения типа instance-address, происходят значительно быстрее, чем ссылки по значению instance-name. Значения типа instance-address отображаются в CLIPS следующим образом:

Пример 4.7. Значение типа instance-address

<Instance-XXX>

где XXX — индекс объекта.

Место для хранения значения одного из примитивных типов в CLIPS назы­вается полем или простым полем. Константа представляет собой неизменяе­мое простое поле, заданное последовательностью символов (с помощью констант нельзя задавать значения типов external-address, fact-address и instance-address — значения этих типов могут быть получены только с по­мощью вызовов соответствующих функций и должны храниться в перемен­ных). Последовательность из 0 или более простых полей образует составное поле. Для вывода составного поля на экран CLIPS группирует данные тако­го поля с помощью круглых скобок. Несколько примеров составных полей приведено ниже:

Пример 4.8. Составные поля

(a) (1 bar foo) () (х 3.0 "red" 567)

Замечание

Составное поле (а) не эквивалентно простому полю а.

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

Переменной является значение некоторого типа, сохраненное в простом или составном поле и имеющее некоторое имя. Переменные используются В конструкторах CLIPS (в частности в defrule, deffunction, defmethod и defmessage-handier). Описания использования переменных в конструкторах приведены в соответствующих разделах.

4.1.2. Функции

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

CLIPS оперирует с несколькими типами функций — определенные пользова­телем внешние функции, системные (внутренние) функции, функции, опреде­ленные в среде CLIPS с помощью конструктора deffunction, родовые функции. Определенные пользователем внешние функции и системные функции соз­даются на внешних языках программирования (например, С), и затем под­ключаются к CLIPS на этапе компилирования или функционирования сре­ды. Системные функции созданы разработчиками среды CLIPS и описаны в руководстве. Описания наиболее важных системных функций приведены в гл. 15 и 16.

Конструктор deffunction позволяет пользователям определять новые функ­ции непосредственно в CLIPS. Функции, созданные таким образом, действуют так же, как внешние или системные функции CLIPS, за исключением того, что вместо непосредственного выполнения (как, например, в случае вызова определенной пользователем внешней функции) вызов такой функции обрабатывается встроенным интерпретатором языка CLIPS. Подробней о функциях, созданных с помощью конструктора deffunction, будет расска­зано в гл. 8.

Родовые функции определяются с помощью конструкторов defgeneric и defmethod. Родовые функции позволяют выполнять различные действия, в зависимости от набора аргументов, заданных при вызове функции. Таким образом функция перегружается различными реализациями (подобный ме­ханизм перегрузки функций можно встретить, например, в языке C++). Бо­лее подробно родовые функции описаны в гл. 10.

Вызов функций в CLIPS имеет префиксную нотацию — аргументы функции всегда следуют после имени функции. При вызове имя функции вместе со всеми аргументами заключается в круглые скобки. Аргументы отделяются друг от друга по крайней мере одним пробелом. Аргументами функций мо­гут быть переменные примитивных типов, константы или вызовы других функций. Ниже приведены примеры использования функций + (арифмети­ческое сложение) и * (арифметическое умножение):

Пример 4.9. Использование функций + и *

(+345)

(* 5 6.0 2)

(+ 3 (* 8 9) 4)

(* 8 (+3 (* 2 3 4) 9) (* 3 4))

Выражением в CLIPS называется неименованный отрезок кода, вызываю­щий функции с некоторым набором аргументов. Фактически предыдущий пример состоит из четырех выражений.

4.1.3. Конструкторы

В CLIPS определены следующие конструкторы: defmodule, defrule, deffacts, deftemplate, defglobal, deffunction, defclass, definstances, defmessage-handler, defgeneric и defmethod. Вызовы всех конструкторов заключаются в круглые скобки. Конструкторы отличаются от встроенных функций по выполняемым ими действиям. Как правило, функции не меняют состояние базы знаний среды CLIPS (за некоторым исключением, например, функ­ций, очищающих среду или загружающих на выполнение некоторый файл). Конструкторы, наоборот, предназначены для добавления в базу знаний но­вых элементов. Кроме того, в отличие от функций, конструкторы не воз­вращают никаких значений.

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

4.2. Абстракции данных

Для представления данных CLIPS использует три основных абстракции дан­ных: факты, объекты и глобальные переменные. В данном разделе подробно описана каждая из этих форм представления информации.

4.2.1. Факты

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

Факт может быть добавлен в текущий список фактов системы (с помощью команды assert), удален из него (команда retract), изменен (modify) или продублирован (duplicate) пользователем, в процессе интерактивной рабо­ты в системе, либо из программы. Количество фактов, которые может содержать список фактов, а также количество информации, содержащейся в каждом факте, ограничено только свободной памятью вашего компьютера. В случае выполнения пользователем попытки добавить в систему факт, точ­но соответствующий уже существующему, данная операция будет игнориро­вана, хотя подобное поведение системы можно изменить (см. гл. 5).

Некоторые команды, такие как retract, modify или duplicate, требуют в качестве параметра некоторого уже существующего факта. Факт может быть задан с помощью значений типа fact-index или fact-address. После созда­ния (или изменения) факт получает уникальный индекс, называемый индексом факта (fact-index). Индекс фактов начинаются с 0 и увеличивается на 1 при каждом добавлении или изменении факта. При выполнении команды reset или clear текущий индекс фактов обнуляется. Для опреде­ления конкретного факта с помощью типа fact-address необходимо полу­чить соответствующее значение от функции, возвращающей значение дан­ного типа (например, assert, modify или duplicate), или некоторого правила.

Для удобства отображения фактов в CLIPS используется понятие идентифи­катора факта. Идентификатор факта состоит из символа f, следующего за ним знака - и индекса факта. Например, идентификатор f-io ссылается на факт с индексом 10.

Для хранения фактов используется один из двух следующих форматов: упо­рядоченные факты и неупорядоченные факты или шаблоны.

Упорядоченные факты

Упорядоченный факт состоит из значения типа symbol и следующей за ним последовательности из нуля или более значений типа symbol. Факт заключа­ется в круглые скобки, а значения в последовательности отделяются друг от друга пробелами. Первое поле упорядоченного факта определяет так назы­ваемое отношение, или связь факта. Например, факт (father-of jack bill) показывает, что отцом Джека является Билл. Ниже приведено несколько примеров упорядоченных фактов:

Пример 4.10. Упорядоченные факты

(the pump is on)

(altitude is 10000 feet)

(grocery-list bread milk eggs)

Поля в упорядоченном факте могут хранить данные любого примитивного типа CLIPS, за исключением первого поля, тип которого должен быть symbol. Следующие слова зарезервированы и не могут быть использованы в качестве первого поля: test, and, or, not, declare, logical, object, exist и forall.

Неупорядоченные факты

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

Конструктор deftemplate задает имя шаблона и определяет последователь­ность из нуля или более полей неупорядоченного факта, называемых сло­тами. Слот состоит из имени, заданного значением типа symbol, и следующим за ним списка полей. Как и факт, слот с обеих сторон ограничивается круглыми скобками. В отличие от упорядоченных фактов слот неупорядо­ченного факта может жестко определять тип своих значений. Кроме того, слоту могут быть заданы значения по умолчанию.

Замечание

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

CLIPS отличает неупорядоченные факты от упорядоченных по первому по­лю факта. Первое поле фактов любого типа должно быть значением типа symbol. Если это значение соответствует имени некоторого шаблона, то факт является неупорядоченным. Как и упорядоченные факты, неупорядоченные ограничиваются скобками.

Пример 4.11. Неупорядоченные факты

(client (name "Joe Brown") (id X9345A))

(point-mass (x-velocity 100) (y-velocity -200))

(class (teacher "Martha Jones") (#-students 30) (Room "37A"))

(grocery-list (#-of-items 3) (items bread milk eggs))

Замечание

Порядок слотов в неупорядоченном факте не важен. Например, все приведен­ные ниже факты считаются идентичными:

(class (teacher "Martha Jones") (#-students 30) (Room "37A"))

(class (#-students 30) (teacher "Martha Jones") (Room "37A"))

(class (Room "37A") (#-students 30) (teacher "Martha Jones"))

В отличие от фактов, приведенных выше, упорядоченные факты из следующего примера не являются идентичными:

(class "Martha Jones" 30 "37А")

(class 30 "Martha Jones" "37A")

(class "37A" 30 "Martha Jones")

Очевидными преимуществами применения шаблонов являются более высо­кая читабельность и независимость слотов от порядка их определения.

Так же как и упорядоченные факты, шаблоны можно добавлять в список фактов и удалять из него. Кроме того, существует возможность модифика­ции и дублирования шаблонов.

Инициализация фактов

Конструктор deffacts позволяет создавать набор фактов, инициализирую­щий базу знаний CLIPS, при каждой очистке системы. При выполнении команды reset текущий список фактов CLIPS очищается, а затем в него добавляются все факты, заданные конструкторами deffacts. CLIPS содер­жит один предопределенный системный конструктор deffacts, который выполняет добавление в систему факта initial-fact. Более подробно особен­ности создания и использования фактов в CLIPS описаны в гл. 5.

4.2.2. Объекты

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

Пример 4.12. Объекты и их классы

Объекты (вид, отображаемый на экран) Классы

Rolls-Royce SYMBOL

"Rolls-Royce" STRING

8.0 FLOAT

8 INTEGER

(8.0 Rolls-Royce 8 [Rolls-Royce]) MULTIFIELD

<Pointer- OOCF61AB> EXTERNAL-ADDRESS

[Rolls-Royce] CAR (класс, определенный пользователем)

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

Объекты примитивных типов неявно создаются и удаляются системой CLIPS в местах, где это необходимо. По ссылке на такой объект можно по­лучить хранящееся в нем значение соответствующего типа. Объекты прими­тивных типов не имеют слотов и, как правило, не имеют имен. Классы, оп­ределяющие эти объекты, являются предопределенными классами CLIPS. Функциональность предопределенных классов, определяющих объекты примитивных типов, подобна функциональности классов, определенных пользователем, за исключением того, что к таким классам нельзя присоеди­нить обработчики сообщений. Это делает не очень удобным использование таких классов в объектно-ориентированном программировании. Основным назначением объектов примитивных типов является использование их в оп­ределении родовых функций. Родовые функции применяют эти объекты в качестве своих аргументов и, по заданному набору, в момент вызова, оп­ределяют, какой именно метод родовой функции должен быть вызван. Бо­лее подробно данный процесс изложен в гл. 10.

Для ссылки на объект класса, определенного пользователем, необходимо использовать имя или адрес объекта. Такие объекты явно создаются или удаляются с помощью сообщений или специальных системных функций. Свойства объекта класса, определенного пользователем, определяются на­бором слотов, заданных при определении класса. Слот объекта имеет имя и может содержать простое или составное значение. Например, объект Rolls-Royce является объектом созданного пользователем класса car. Один из сло­тов такого объекта может, например, содержать цену автомобиля со значе­нием 75 000. Поведение объектов определяется наличием тех или иных об­работчиков сообщений, присоединенных к соответствующему классу. Обра­ботчики сообщений и способы работы с объектами подробно описаны в гл. 11. Все объекты одного класса имеют одинаковые наборы слотов, но могут содержать в этих слотах различные значения. Однако, если два объек­та имеют одинаковые наборы слотов, это еще не означает, что они принадлежат одному классу, т. к. два абсолютно разных класса, теоретически, мо­гут иметь одинаковые наборы слотов.