14.2.1.
Компоненты и ограничения
Хотя и 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.