I. разработка прототипа эс. (наличие данной части желательно)

      Комментарии к записи I. разработка прототипа эс. (наличие данной части желательно) отключены

Требования к расчетно-графическому заданию

По дисциплине ИИС

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 случаев, то это нецелесообразно.

Для решения этой задачи можно в БЗ задать правила, которые определяют вопросы, которые не нужно задавать.

Отчет. В отчете обязательно должны быть представлены: краткое описание предметной области, назначение программы, алгоритм принятия решения, полная схема диалога, список вопросов и допустимых ответов, структура БЗ (инфологическая и даталогическая модель), подробный алгоритм работы программы с БЗ, подробная инструкция по работе с БЗ.

Статьи к прочтению:

Prototype Прохождение На Русском #1 — СМЕРТЬ ГОРОДА! ПРОТОТИП!


Похожие статьи: