Сердцем системы является процессор правил, использующий правила и
факты для достижения цели. Единственным путем внесения в систему
данных является декларация фактов. Правда, системы работающие с
большими объемами данных, часто объединены с БД и пользователь
может как декларировать факты, так и напрямую работать с таблица-
ми БД.
Для приведения баз правил к виду объектов мы должны реализо-
вать общий механизм, позволяющий им доступ к внешним данным - се-
тевые заклинания; в частности, это даст БП доступ к удаленным БД.
Теперь БП сама может рассматриваться как распределенный объект.
Правила как методы объекта.
Для использования правил в работе объекта следует просто
реализовать диспетчер, делегирующий работу процессору правил в
соответствии с заклинанием. Вкупе с доступом к БД мы получаем,
что база правил есть объект с состоянием - данными БД и методами -
правилами, также хранящимися в БД. Обычно нежелательно, чтобы
правила напрямую обращались к БД; соответственно, диспетчер дол-
жен передавать базе правил свой собственный идентификатор и про-
цессор правил будет обращаться к нему с заклинаниями доступа к
данным.
Вынесенные заключения и нерешенные проблемы.
В ходе экспериментов выяснилось следующее:
- хотя в начальной идее заклинание разбивалось на адреса и
аргументы, часто удобно рассматривать заклинание как неразрывную
сущность;
- "хорошие" сообщения по идее должны пониматься всеми под-
держиваемыми объектами. Hепонятно, как быть в случае, когда сооб-
щение бессмысленно для принимающего - ответить некоторым стандар-
тно-бессмысленным образом или отдать объекту и позволить ему об-
работать и/или сгенерировать исключение;
- возникают вопросы с конкурентным доступом к объектам в
распределенных системах. В настоящее время идет разработка допол-
нений, которые позволят реализовать любой из методов управления
конкуренцией, предлагаемый в прикладных системах;
- метаобъекты. В системе следует организовать некий мета-у-
ровень и разрешить доступ к нему диспетчеров. Явное указание ал-
горитмов диспетчеризации подобно использованию goto: и гибко, и
опасно. Постепенно выделятся общие пути диспетчеризации, которые
станут высокоуровневыми абстракциями;
- отделение мета- и базового уровня. Смесь в одном диспетче-
ре доступа к обоим уровням трудна для восприятия;
- оптимизация. Преимуществом предложенной схемы является то,
что она не рассчитана на конкретный метод диспетчеризации и, сле-
довательно, возможно оптимизировать какие-либо части работающей
системы не нарушая работы остальных.