Требования к расчетно-графическому заданию
По дисциплине ИИС
I. Разработка прототипа ЭС. (Наличие данной части желательно)
Необходимо разработать прототип ЭС. Основное назначение программы состоит в отделении алгоритма работы (машины вывода) от базы знаний, которая содержит вопросы, варианты ответов и информацию о последовательности и необходимости задавания вопросов. База знаний должна быть реализована в архитектуре баз данных (напр. таблицах Paradox). Программа должна работать независимо от содержимого БЗ.
Программа обязательно должна иметь цель не только запротоколировать ответы, но и использовать их для принятия какого-либо решения, выдачи рекомендации. Во время принятия решения программа должна учитывать все ответы на основные вопросы.
Можно расширить функциональные возможности программы за счет создания подсистем заполнения БЗ, отображения графа диалога, сохранения БЗ в собственном формате (объектная БД или текстовый файл).
Ниже предлагается один из вариантов реализации структуры БЗ в архитектуре реляционных БД. БЗ содержит 3 таблицы: таблицу вопросов (Quest.db), таблицу правил для вопросов (QuestRules.db) и таблицу ответов (Answ.db).
Таблица Quest.db
| Поле | Тип данных | Описание |
| ID | Integer | Идентификатор вопроса |
| Question | String | Вопрос |
| AnsType | Integer | Тип данных для ответа (0 – Boolean, 1 – Integer, 2 – String) |
| Answer1 | String | Вариант ответа 1 |
| Answer2 | String | Вариант ответа 2 |
| … | … | … |
| AnswerN | String | Вариант ответа N |
| Asked | Boolean | Задан/не задан |
| Attribute | String | Атрибут (свойство) объекта, значение которого определяется ответом. |
| Order | Integer | Порядок (очередность) задавания вопроса |
Таблица Answ.db
| Поле | Тип данных | Описание |
| ID | Integer | Идентификатор записи |
| Attribute1 | String | Значение атрибута (свойства) объекта, заполняемое после ответа на вопрос. |
| Attribute2 | String | Значение атрибута 2 |
| … | … | … |
| AttributeM | String | Значение атрибута M |
Таблица QuestRules.db
| Поле | Тип данных | Описание |
| ID | Integer | Идентификатор правила |
| IF_Atr | String | Атрибут (свойство) объекта. |
| IF_Value | String | Значение атрибута (свойства) объекта |
| NextQuest | Integer | Номер (ID) следующего вопроса. Значение =0, если нужно только исключить вопрос. |
| NoAsk | Integer | Номер (ID) вопроса, который не надо задавать. Значение =0, если не нужно исключать вопрос. |
1. Для принятия решения ЭС необходимо наличие исходных данных, которые представляют собой группу характеристик и их значения. Эти характеристики могут быть представлены как атрибуты (свойства) реального объекта. Например, объект – правильная геометрическая фигура со свойствами количество ребер, длина ребра, цвет, материал. Характеристики также могут быть представлены как свойства некого абстрактного объекта. Например, объекты заказ, анкета_сотрудника, протокол_ответов.
2. Диалог может быть построен детерминированным образом, т.е. для каждого ответа на вопрос точно определен следующий вопрос. Это не удобно в тех случаях, когда существует группы несвязанных вопросов (ветвей графа диалога), не зависящих друг от друга.
Например, необходимо определить характеристики покупаемого компьютера. Пусть имеется, по крайней мере, четыре независимых группы вопросов, определяющих требования к системному блоку, монитору, клавиатуры и мыши соответственно. При использовании детерминированного подхода каждому ответу из множества {Answer1, …, AnswerN}, на котором может закончиться диалог о выборе системного блока, нужно сопоставить переход на первый вопрос Q2 из группы по выбору монитора (клавиатуры, мыши). Если нужновопрос Q2 заменить на Q3, то придется изменять N соответствующих переходов (ссылок).
Для избежания этого недостатка можно задать порядок (очередность) следования вопросов при отсутствии явных указаний. Если в структуре ответа, хранящегося в БЗ, не будет указаний на следующий вопрос, то программа осуществит поиск первого незаданного вопроса. Обычно первыми в списке идут вопросы, являющиеся вершинами независимых веток графа диалога.
3. На практике часто встречаются случаи, когда граф (правильней сказать дерево) диалога имеет циклические структуры. Это может привести к тому, что один и тот же вопрос будет задаваться больше одного раза. Например, при выборе монитора в самом общем случае необходимо знать, является ли покупатель слепым. Этот же вопрос важен и при выборе устройств ввода/вывода данных. Конечно, можно вынести все общие вопросы разных веток диалога и задавать их один раз без привязки к конкретному устройству (части компьютера) в начале или конце диалога. Однако, если по статистике эти вопросы нужно задавать в одном из 100 случаев, то это нецелесообразно.
Для решения этой задачи можно в БЗ задать правила, которые определяют вопросы, которые не нужно задавать.
Отчет. В отчете обязательно должны быть представлены: краткое описание предметной области, назначение программы, алгоритм принятия решения, полная схема диалога, список вопросов и допустимых ответов, структура БЗ (инфологическая и даталогическая модель), подробный алгоритм работы программы с БЗ, подробная инструкция по работе с БЗ.
