В рамках этого задания необходимо расширить функциональные возможности ЭС. Для этого необходимо заранее разработать правила, которые позволяют на основе введенной информации самостоятельно определить значения атрибутов (свойств) объекта. Наличие таких правил должно обеспечить сокращение числа вопросов к пользователю и перенос в БЗ некоторых (в идеале - всех) алгоритмов расчета, оценки ситуации, выявления неисправности и т.д. Обязательным требованием к системе правил является как минимум двухфазный вывод.
1. Все правила должны быть построены по принципу простой продукции ЕСЛИ …, ТО …. Правила необходимы для генерации новых знаний (данных) на основе введенных ответов (исходной информации). Иногда применение правил позволяет избежать лишних вопросов. Например, если пользователь сообщит программе точную информацию о модели устройства, то нет необходимости выявлять все его параметры. Это можно сделать на основе заложенных правил.
Второй случай применения правил связан с отсутствием ответа на прямой вопрос и необходимостью задания ряда дополнительных вопросов. Используя дополнительную информацию, можно с помощью правил ответить на исходный (основной) вопрос. Например, если покупатель не знает модель необходимой видеокарты, то его можно спросить о ее характеристиках (объеме памяти, поддержки AGP, количестве и типах видеовыходов, разъемах и т.д.). Используя эту информацию и заранее разработанные правила можно определить конкретную модель.
Третий случай (самый распространенный) применения правил вызван необходимостью сделать вывод (выработать решение или рекомендацию) в ЭС. Для этого необходимо представить алгоритм работы программы в виде продукций или других правил. Если в Вашем алгоритме присутствуют сложные арифметические или другие операции, то разрешается их выполнять в теле программы и не представлять в БЗ. Однако, такое решение должно быть четко аргументировано, а правила использованы для других задач, рассмотренных выше.
2. Правила должны быть представлены в явном виде и храниться в отдельной структуре (таблице) БЗ. Описание правил в БЗ должно быть реализовано таким образом, что от пользователя не требуется указание номера вопроса, номера ответа и т.д.
3. Применение одного, нескольких или всех правил может осуществляться после ответа на каждый вопрос, только на некоторые вопросы или после завершения диалога. Для избежания повторного использования правила можно ввести соответствующий атрибут (например, Used).
4. Если условие применения одного правила зависит от результатов использования других правил, то необходимо задать соответствующий порядок (очередность). Альтернативой этому является повторная проверка выполнимости всех правил после срабатывания хотя бы одного из них.
5. В общем случае необходимость и очередность задавания вопросов может определяться на основе применения группы правил. Для реализации этого механизма имеет смысл объединить правила для вопросов и правила определения новых параметров.
Отчет. В отчете обязательно должны быть представлены: краткое описание предметной области, назначение программы, алгоритм принятия решения (с помощью правил), полная схема диалога, список правил, вопросов и допустимых ответов, структура БЗ (инфологическая и даталогическая модель), подробный алгоритм работы программы с БЗ, подробная инструкция по работе с БЗ.
Ниже приведены два варианта реализации таблицы правил. В таблице RulesSimple.db всегдаимеется только одна посылка и одно следствие. Для реализации множества следствий необходимо написать несколько правил с одинаковой левой частью. В таблице RulesComplex.db может иметься одна или две посылки, которые могут объединяться логической, арифметической или другой операцией. Для реализации более сложного правила, содержащего три или более посылки, его нужно разбивать на несколько простых. При вероятностном или нечетком выводе можно использовать операцию приращения/уменьшения значения параметра.
Таблица RulesSimple.db
| Поле | Тип данных | Описание |
| ID | Integer | Идентификатор правила |
| IF_Atr | String | Атрибут (свойство) объекта посылки. |
| IF_Value | String | Значение атрибута (свойства) объекта посылки. |
| Then_Atr | String | Атрибут (свойство) объекта следствия. |
| Then_Value | String | Значение атрибута (свойства) объекта следствия. |
| Used | Boolean | Использовано/не использовано правило |
Таблица RulesComplex.db
| Поле | Тип данных | Описание |
| ID | Integer | Идентификатор правила |
| IF1_Atr | String | Атрибут (свойство) объекта посылки. |
| IF1_Value | String | Значение атрибута (свойства) объекта посылки. |
| Operation | Integer | Логическая операция (0 – нет операции, 1 – AND, 2 – OR, 3 – NOT …) |
| IF2_Atr | String | Атрибут (свойство) объекта посылки. |
| IF2_Value | String | Значение атрибута (свойства) объекта посылки. |
| Then_Atr | String | Атрибут (свойство) объекта следствия. |
| Then_Value | String | Значение атрибута (свойства) объекта следствия. Значение ='Null', если осуществляется прирост/уменьшение вероятности гипотезы. |
| ChangeValue | Integer (Number) | Прирост/уменьшение вероятности (уверенности, достоверности) гипотезы (факта). |
| Used | Boolean | Использовано/не использовано правило |
ЕСЛИ [ (&IF1_Atr = IF1_Value) Operation (&IF2_Atr = IF2_Value) ]
ТО [ ЕСЛИ (Then_Value<>'Null') ТО (&Then_Atr = Then_Value) ]
ЕСЛИ [ (&IF1_Atr = IF1_Value) Operation (&IF2_Atr = IF2_Value) ]
ТО [ЕСЛИ (Then_Value='Null') ТО (&Then_Atr = &Then_Atr + ChangeValue) ]
Дополнительно в рамках работы можно реализовать:
· функцию синтаксического разбора логических и математических выражений в продукционных правилах;
· компоненту ввода правил в БЗ;
· возможность задания и вывода правил с помощью нечетких множеств;
· функции проверки правил на противоречивость и избыточность;
· функцию вывода новых (производных) правил;
· компоненту отображения дерева вывода;
· функции обратного, смешанного и немонотонного выводов.
