Компоненты и ограничения
Хотя и R1, и MYCIN являются программами, использующими в своей работе порождающие правила, между ними имеется ряд серьезных отличий. Одно из них состоит в том, что в MYCIN процесс решения проблемы направляется гипотезами (hypothesis-driven), т.е. процесс начинается с формулировки определенной цели, а затем она преобразуется в набор подцелей, совместное достижение которых позволяет достичь главной цели (см. об этом в главе 3). В системе R1 главным является подход, предполагающий, что процесс решения направляется данными (data-driven). Сначала программа определяет множество компонентов и далее пытается сконструировать такую конфигурацию этих компонентов, которая удовлетворяла бы ограничениям, вытекающим как из характеристик отдельных компонентов, так и из отношений и связей между ними. Для реализации программы был использован язык OPS5, один из первых языков представления правил, прямой предшественник языка CLIPS.
Для успешной работы программа R1 нуждается в знаниях двух видов:
Знания о компонентах хранятся в базе данных отдельно как от памяти системы порождающих правил, так и от рабочей памяти транзитных элементов данных. Таким образом, база данных имеет статическую структуру, в то время как рабочая память является динамической, В отличие от памяти порождающей системы, которая организована в виде набора модулей, управляемых по определенной схеме, база данных состоит из записей обычной структуры, которые для каждого компонента хранят информацию о его классе, типе и множестве характеристик. Например, ниже представлен фрагмент записи о контроллере накопителя на магнитных дисках типа
RK611
CLASS: UNIBUS MODULE
TYPE: DISK DRIVE
SUPPORTED: YES
PRIORITY LEVEL: BUFFERED NPR
TRANFER RATE: 212
Знания об ограничениях сохраняются в виде правил в памяти продукционной системы программы R1. Левая часть правил описывает условия (ситуацию), при соблюдении которых возможно расширение частичной конфигурации, а правая часть описывает, как выполняется расширение. В начале сеанса работы с системой рабочая память пуста, а в конце сеанса в ней содержится описание сформированной конфигурации. Компоненты в этом описании представлены в виде лексем, имеющих вид векторов, состоящих из элементов "атрибут-значение". С информацией, хранящейся в базе данных компонентов, система R1 может выполнять пять видов операций: генерировать новую лексему, отыскивать лексему, отыскивать подстановку для заданной лексемы, извлекать атрибуты, связанные с заданной лексемой, и извлекать шаблон, который в дальнейшем должен быть заполнен.
Помимо лексем компонентов, рабочая память содержит элементы, которые представляют частичные конфигурации оборудования, результаты вычислений и символьное описание текущей задачи.
Система R1 хранит порядка 10 000 правил, значительная часть которых определяет, какое следующее действие должна выполнить программа. Пример одного из таких правил приведен ниже.
DISTRIBUTE-MB-DEVICES-3
ЕСЛИ: предыдущим активным контекстом является расширение количества
устройств, подключаемых к шине .MASSBUS
& имеется однопортовый НМД, не подключенный к MASSBUS
& отсутствуют двухпортовые НМД, еще не подключенные к MASSBUS
& количество устройств, которое можно подключить к расширителю MASSBUS,
известно
& существует расширитель MASSBUS, к которому подключен по крайней мере
один НМД и который может
поддерживать дополнительные НМД
& известен тип кабеля, которым должен быть связан НМД с ранее установленным устройством
ТО: подключить НМД к MASSBUS
Такие управляющие знания о предметной области (domain-specific control knowledge) позволяют программе R1 принимать решение о том, с чего начинать и как расширять структуру комплекса, не используя при этом сложной процедуры поиска.Как мы увидим далее, программа R1, как правило, не нуждается в обратном прослеживании неудовлетворительных решений, которое можно было бы использовать для отмены сформированной частичной конфигурации и замены ее новой.
Использованные в R1 управляющие знания малочувствительны к очередности применения отдельных правил. Этим она отличается от систем, в которых общая задача конфигурирования решается разделением на подзадачи и выбором групп правил, соответствующих определенной подзадаче. В результате процесс решения проблемы в R1 направляется последовательностью правил, активизированных последними. Как будет показано в следующем разделе, для упрощения реализации такой стратегии используются некоторые из средств разрешения конфликтов, которые имеются в языке OPS5.
