2.5.4. Метамодель систем продукций

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

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

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

2.5.4.1. Основные подсистемы

Рассмотрим схему функционирования систем продукций. Анализ этой схемы позволяет выделить три тесно связанные подсистемы, которые можно считать основными структурными компонентами ПСМ: модуль базы данных, модуль правил и модуль управления (интерпретатор) (рис. 1.1).

Рис. 1.1. Основные компоненты ПСМ

Модуль базы данных представляет собой ассоциативную память, ори­ентированную на размещение и обработку структур какого-либо опреде­ленного типа. В базе хранятся данные, которые обрабатывает ПСМ, и это определяет основной набор реализуемых в базе данных операций. К этим операциям относятся:

• поиск фрагмента данных (подструктуры) по образцу,

• исключение подструктуры,

• добавление подструктуры.

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

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

<имя, условие применимости, оператор>,

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

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

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

13. с точки зрения процесса, ограничивая совокупность правил, до­ступных на каждом этапе, позволяет:

• повысить эффективность процедуры проверки условий применимости правил,

• сократить объем необходимой оперативной памяти,

• упростить условия применимости правил.

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

• глобальную, относящуюся ко всей системе правил;

• локальную, относящуюся к данной группе правил;

• индивидуальную, т.е. спецификацию самого правила.

Весьма существенным является разделение систем правил на два класса — статические, т.е. не меняющиеся в процессе работы ПСМ, идинамические, способные к саморедактированию.

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

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

• различных результатов;

• путей вычисления одного и того же результата.

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

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