close

Вход

Забыли?

вход по аккаунту

?

lab praktikum IIS 2013

код для вставкиСкачать
Учебный курс "Теория баз данных и знаний"
Лабораторный практикум. Часть 1. Разработка прототипа ЭС
1. Цель работы. Ознакомиться с подходом к разработке ЭС в части создания основных компонент: базы знаний, машины вывода и диалога (интерфейса) с пользователем.
2. Порядок выполнения работы.
2.1. Изучить теоретическое введение.
2.2. Последовательно выполнить все задания к лабораторному практикуму .
2.3. Проверить правильность выполнения заданий не менее чем на пяти примерах.
2.4. Оформить отчет по лабораторному практикуму .
3. Задания к лабораторному практикуму (часть 1)
3.1. Выбрать предметную область и задачу, которая может быть решена с помощью ЭС. Рекомендуется реализовать задачу анализа входных данных и последующего принятия решения по выбору конкретного объекта или рекомендации из заранее определенного множества.
3.2. Разбить процесс решения задачи на следующие этапы:
* Получение исходных данных (множество P) от пользователя в режиме диалога
* Обработка (анализ) полученных данных P для определения атрибутов (множество A) объекта принятия решения O
* Принятие решения на основе полученных характеристик A (выбор одного из заранее определенных вариантов решения) и вывод результата пользователю.
Количественные требования к основным показателям:
* P >=20 (Количество параметров, извлекаемых от пользователя, должно быть более 19)
* A >=10 (Количество атрибутов, которые характеризуют объект выбора или принятия решения O, должно быть более 9)
* P > 2*A (количество исходных данных должно быть больше количества необходимых атрибутов для принятия решения больше как минимум в два раза) * Множество A может только частично (не более чем на 30%) входить в множество P.
* Количество вопросов должно быть не меньше количества параметров P.
* Итоговое принятие решения (выбор) должен производиться на основе хотя бы двух альтернативных вариантов.
3.3. Разработать вопросы к пользователю и граф диалога
Необходимо разработать схему разветвленного диалога, содержащего не менее 20 вопросов с двумя или более вариантами ответов. Целью диалога является выявление у пользователя информации, необходимой для расчета, оценки ситуации, выявления неисправности и т.д. Одновременно должен задаваться только один вопрос. Варианты допустимых ответов должны оформляться в виде раскрывающего списка, радио кнопок или других не менее функциональных визуальных элементах. Для группы вопросов должна быть реализована функция ручного ввода ответа. Программа должна быть нечувствительна к регистру вводимого текста, и выдавать ошибку в случае неправильного набора (недопустимого варианта ответа). Для остальных вопросов ответы должны быть предопределены.
Порядок задавания вопросов должен изменяться в зависимости от ответов, т.е. могут быть заданы не все 20 вопросов, а только их часть. Более того, в зависимости от ответов должны задаваться разные группы вопросов.
Все вопросы должны задаваться в распространенной языковой и по возможности вежливой форме. Например, вместо Цвет?, Размер? должны задаваться указания или вопросы: Выберите цвет автомобиля, Какой размер одежды Вы носите?
Замечание 1. Для некоторых задач диалог может быть построен таким образом, что ответ на очередной вопрос сужает область поиска (выбора), а каждому листу дерева вопросов сопоставляется вариант решения. В этом случае в схеме диалога заложен алгоритм принятия решения (выбора). Характерной особенностью таких диалогов является взаимосвязанность всех вопросов. Однако, для случаев, когда существует группы несвязанных и не зависящих друг от друга вопросов (фактически отдельные графы диалога), возникают проблемы: Например, необходимо определить характеристики покупаемого компьютера. Пусть имеется, по крайней мере, четыре независимых группы вопросов, определяющих требования к системному блоку, монитору, клавиатуре и мыши соответственно. При использовании указанного подхода каждому ответу из множества {Answer1, ..., AnswerN}, на котором заканчивается диалог о выборе системного блока, нужно сопоставить переход на первый вопрос Q2 из группы по выбору монитора (клавиатуры, мыши). Если нужно вопрос Q2 заменить на другой (Q3), то придется изменять N соответствующих переходов (ссылок) на него. Для избежания этого недостатка можно задать порядок (очередность) следования вопросов при отсутствии явных указаний. Если в структуре ответа, хранящегося в БЗ, не будет указаний на следующий вопрос, то программа осуществит поиск первого незаданного вопроса. Обычно первыми в списке идут вопросы, являющиеся вершинами независимых веток графа диалога.
Требование. Не допускается исключение этапа определения значений необходимых для принятия атрибутов за счет использования хорошо построенного диалога. Чтобы этого избежать можно, например, ввести несколько независимых веток вопросов.
Замечание 2. На практике часто встречаются случаи, когда граф (правильней сказать дерево) диалога имеет циклические структуры. Это может привести к тому, что один и тот же вопрос будет задаваться больше одного раза. Например, при выборе монитора в самом общем случае необходимо знать, является ли покупатель слепым. Этот же вопрос важен и при выборе устройств ввода/вывода данных. Конечно, можно вынести все общие вопросы разных веток диалога и задавать их один раз без привязки к конкретному устройству (части компьютера) в начале или конце диалога. Однако, если по статистике эти вопросы нужно задавать в одном из 100 случаев, то это нецелесообразно. Для решения этой задачи можно в БЗ задать правила, которые определяют вопросы, которые не нужно задавать.
3.4. Разработать БД для хранения исходных, промежуточных и результирующих данных.
Для принятия решения ЭС необходимо наличие исходных данных, которые представляют собой группу характеристик и их значения. Эти характеристики могут быть представлены как атрибуты (свойства) реального объекта. Например, объект - правильная геометрическая фигура со свойствами количество ребер, длина ребра, цвет, материал. Характеристики также могут быть представлены как свойства некого абстрактного объекта. Например, объекты заказ, анкета_сотрудника, протокол_ответов.
Необходимо разработать структуры для хранения данных о параметрах P, полученных в ходе ответов на вопросы, об атрибутах A объекта(ов) и, по желанию, о вариантах принятия решения (выбора).
3.5. Разработать вопросно-ответную компоненту БЗ.
Важное отличие ЭС от традиционной расчетно-логической программы состоит в отделении алгоритма работы (машины вывода) от базы знаний, которая содержит вопросы, варианты ответов и информацию о последовательности и необходимости задавания вопросов. База знаний должна быть реализована в архитектуре баз данных . Программа должна работать независимо от содержимого БЗ (в рамках неизменной структуры). * Можно расширить функциональные возможности программы за счет создания подсистем редактирования БЗ, и отображения графа диалога.
* Можно несколько усложнить задачу, создав структуру правил очередности задавания вопросов и механизм ее обработки. Применение таких правил позволяет избежать лишних вопросов. Например, если пользователь сообщит программе точную информацию о модели устройства, то нет необходимости выявлять все его параметры.
Ниже предлагается один из вариантов реализации структуры БЗ в архитектуре реляционных БД. БЗ содержит 3 таблицы: таблицу вопросов (Quest.db), таблицу правил очередности задавания вопросов (QuestRules.db) и таблицу ответов (Answ.db).
Таблица Quest.db
ПолеТип данныхОписаниеIDIntegerИдентификатор вопросаQuestionStringВопросAnsTypeIntegerТип данных для ответа (0 - Boolean, 1 - Integer, 2 - String)Answer1StringВариант ответа 1Answer2StringВариант ответа 2.........AnswerNStringВариант ответа NAskedBooleanЗадан/не заданParameterStringПараметр (свойство) объекта, значение которого определяется ответом.OrderIntegerПорядок (очередность) задавания вопроса Таблица Answ.db
ПолеТип данныхОписаниеIDIntegerИдентификатор записиParameter 1StringЗначение параметра (свойства) объекта, заполняемое после ответа на вопрос.Parameter 2StringЗначение параметра 2.........Parameter MStringЗначение параметра M Таблица QuestRules.db
ПолеТип данныхОписаниеIDIntegerИдентификатор правилаIF_ParStringПараметр (свойство) объекта.IF_ValueStringЗначение параметра (свойства) объектаNextQuestIntegerНомер (ID) следующего вопроса. Значение =0, если нужно только исключить вопрос.NoAskIntegerНомер (ID) вопроса, который не надо задавать. Значение =0, если не нужно исключать вопрос. 3.6. Разработать правила и реализовать машину вывода
Эта часть работы посвящена второму и третьему этапу решения задачи. Она должна быть реализована произвольно с использованием стандартного подхода к разработке расчетно-логических систем в рамках тела программы.
4. Содержание отчета * Название и цель работы
* Задание
* Краткое описание предметной области и выбранной задачи
* Перечень параметров, атрибутов и их допустимых значений
* Перечень вопросов, вариантов ответов и граф диалога
* Правила получения атрибутов A из множества исходных параметров P
* Алгоритм принятия решения (выбора) со схемой
* Алгоритм работы программы (по 3 частям)
* Структура БЗ (логическая и физическая модель данных в архитектуре реляционных или объектных БД)
* Подробный алгоритм работы программы с БЗ
* Подробная инструкция по работе с БЗ и ЭС
Учебный курс "Теория баз данных и знаний"
Лабораторный практикум. Часть 2. Разработка базы знаний с правилами вывода
1. Цель работы.
Ознакомиться с подходом к разработке ЭС в части создания основных компонент: базы знаний, машины вывода и диалога (интерфейса) с пользователем.
2. Порядок выполнения работы.
2.1. Изучить теоретическое введение.
2.2. Последовательно выполнить все задания к лабораторному практикуму. 2.3. Проверить правильность выполнения заданий не менее чем на пяти примерах.
2.4. Оформить отчет по лабораторному практикуму.
3. Задания к лабораторному практикуму (часть 2) . 3.1. Выбрать предметную область и задачу, которая может быть решена с помощью ЭС. Рекомендуется реализовать задачу анализа входных данных и последующего принятия решения по выбору конкретного объекта или рекомендации из заранее определенного множества.
3.2. Разбить процесс решения задачи на следующие этапы:
* Получение исходных данных (множество P) от пользователя в режиме диалога
* Обработка (анализ) полученных данных P для определения атрибутов (множество A) объекта принятия решения O
* Принятие решения на основе полученных характеристик A (выбор одного из заранее определенных вариантов решения) и вывод результата пользователю.
Количественные требования к основным показателям:
* P >=20 (Количество параметров, извлекаемых от пользователя, должно быть более 19)
* A >=10 (Количество атрибутов, которые характеризуют объект выбора или принятия решения O, должно быть более 9)
* P > 2*A (количество исходных данных должно быть больше количества необходимых атрибутов для принятия решения больше как минимум в два раза) * Множество A может только частично (не более чем на 30%) входить в множество P.
* Количество вопросов должно быть не меньше количества параметров P.
* Итоговое принятие решения (выбор) должен производиться на основе хотя бы двух альтернативных вариантов.
3.3. Разработать вопросы к пользователю и граф диалога
Необходимо разработать схему разветвленного диалога, содержащего не менее 20 вопросов с двумя или более вариантами ответов. Целью диалога является выявление у пользователя информации, необходимой для расчета, оценки ситуации, выявления неисправности и т.д. Одновременно должен задаваться только один вопрос. Варианты допустимых ответов должны оформляться в виде раскрывающего списка, радио кнопок или других не менее функциональных визуальных элементах. Для группы вопросов должна быть реализована функция ручного ввода ответа. Программа должна быть нечувствительна к регистру вводимого текста, и выдавать ошибку в случае неправильного набора (недопустимого варианта ответа). Для остальных вопросов ответы должны быть предопределены.
Порядок задавания вопросов должен изменяться в зависимости от ответов, т.е. могут быть заданы не все 20 вопросов, а только их часть. Более того, в зависимости от ответов должны задаваться разные группы вопросов.
Все вопросы должны задаваться в распространенной языковой и по возможности вежливой форме. Например, вместо Цвет?, Размер? должны задаваться указания или вопросы: Выберите цвет автомобиля, Какой размер одежды Вы носите?
Замечание 1. Для некоторых задач диалог может быть построен таким образом, что ответ на очередной вопрос сужает область поиска (выбора), а каждому листу дерева вопросов сопоставляется вариант решения. В этом случае в схеме диалога заложен алгоритм принятия решения (выбора). Характерной особенностью таких диалогов является взаимосвязанность всех вопросов. Однако, для случаев, когда существует группы несвязанных и не зависящих друг от друга вопросов (фактически отдельные графы диалога), возникают проблемы: Например, необходимо определить характеристики покупаемого компьютера. Пусть имеется, по крайней мере, четыре независимых группы вопросов, определяющих требования к системному блоку, монитору, клавиатуре и мыши соответственно. При использовании указанного подхода каждому ответу из множества {Answer1, ..., AnswerN}, на котором заканчивается диалог о выборе системного блока, нужно сопоставить переход на первый вопрос Q2 из группы по выбору монитора (клавиатуры, мыши). Если нужно вопрос Q2 заменить на другой (Q3), то придется изменять N соответствующих переходов (ссылок) на него. Для избежания этого недостатка можно задать порядок (очередность) следования вопросов при отсутствии явных указаний. Если в структуре ответа, хранящегося в БЗ, не будет указаний на следующий вопрос, то программа осуществит поиск первого незаданного вопроса. Обычно первыми в списке идут вопросы, являющиеся вершинами независимых веток графа диалога.
Требование. Не допускается исключение этапа определения значений необходимых для принятия атрибутов за счет использования хорошо построенного диалога. Чтобы этого избежать можно, например, ввести несколько независимых веток вопросов.
Замечание 2. На практике часто встречаются случаи, когда граф (правильней сказать дерево) диалога имеет циклические структуры. Это может привести к тому, что один и тот же вопрос будет задаваться больше одного раза. Например, при выборе монитора в самом общем случае необходимо знать, является ли покупатель слепым. Этот же вопрос важен и при выборе устройств ввода/вывода данных. Конечно, можно вынести все общие вопросы разных веток диалога и задавать их один раз без привязки к конкретному устройству (части компьютера) в начале или конце диалога. Однако, если по статистике эти вопросы нужно задавать в одном из 100 случаев, то это нецелесообразно. Для решения этой задачи можно в БЗ задать правила, которые определяют вопросы, которые не нужно задавать.
3.4. Разработать БД для хранения исходных, промежуточных и результирующих данных.
Для принятия решения ЭС необходимо наличие исходных данных, которые представляют собой группу характеристик и их значения. Эти характеристики могут быть представлены как атрибуты (свойства) реального объекта. Например, объект - правильная геометрическая фигура со свойствами количество ребер, длина ребра, цвет, материал. Характеристики также могут быть представлены как свойства некого абстрактного объекта. Например, объекты заказ, анкета_сотрудника, протокол_ответов.
Необходимо разработать структуры для хранения данных о параметрах P, полученных в ходе ответов на вопросы, об атрибутах A объекта(ов) и, по желанию, о вариантах принятия решения (выбора).
3.5. Разработать вопросно-ответную компоненту БЗ.
Важное отличие ЭС от традиционной расчетно-логической программы состоит в отделении алгоритма работы (машины вывода) от базы знаний, которая содержит вопросы, варианты ответов и информацию о последовательности и необходимости задавания вопросов. База знаний должна быть реализована в архитектуре баз данных . Программа должна работать независимо от содержимого БЗ (в рамках неизменной структуры). * Можно расширить функциональные возможности программы за счет создания подсистем редактирования БЗ, и отображения графа диалога.
* Можно несколько усложнить задачу, создав структуру правил очередности задавания вопросов и механизм ее обработки. Применение таких правил позволяет избежать лишних вопросов. Например, если пользователь сообщит программе точную информацию о модели устройства, то нет необходимости выявлять все его параметры.
Ниже предлагается один из вариантов реализации структуры БЗ в архитектуре реляционных БД. БЗ содержит 3 таблицы: таблицу вопросов (Quest.db), таблицу правил очередности задавания вопросов (QuestRules.db) и таблицу ответов (Answ.db).
Таблица Quest.db
ПолеТип данныхОписаниеIDIntegerИдентификатор вопросаQuestionStringВопросAnsTypeIntegerТип данных для ответа (0 - Boolean, 1 - Integer, 2 - String)Answer1StringВариант ответа 1Answer2StringВариант ответа 2.........AnswerNStringВариант ответа NAskedBooleanЗадан/не заданParameterStringПараметр (свойство) объекта, значение которого определяется ответом.OrderIntegerПорядок (очередность) задавания вопроса Таблица Answ.db
ПолеТип данныхОписаниеIDIntegerИдентификатор записиParameter 1StringЗначение параметра (свойства) объекта, заполняемое после ответа на вопрос.Parameter 2StringЗначение параметра 2.........Parameter MStringЗначение параметра M Таблица QuestRules.db
ПолеТип данныхОписаниеIDIntegerИдентификатор правилаIF_ParStringПараметр (свойство) объекта.IF_ValueStringЗначение параметра (свойства) объектаNextQuestIntegerНомер (ID) следующего вопроса. Значение =0, если нужно только исключить вопрос.NoAskIntegerНомер (ID) вопроса, который не надо задавать. Значение =0, если не нужно исключать вопрос. 3.6. Разработать правила и реализовать машину вывода.
Необходимо формализовать второй этап принятия решения с помощью системы правил вывода, которые должны быть построены по принципу простой продукции ЕСЛИ ..., ТО ...
Обязательным требованием является наличие правил, имеющих две (или более) посылки и реализующих их конъюнкцию (или другую форму агрегирования). Например, Если стиль_одежды = "модный" AND пол="женский" То цвет_одежды="розовый"
Правила должны храниться в отдельной структуре (таблице) БЗ. Описание правил в БЗ должно быть реализовано таким образом, что от пользователя не требуется указание номера вопроса, номера ответа и т.д.
Применение одного, нескольких или всех правил может осуществляться после ответа на каждый вопрос, только на некоторые вопросы или после завершения диалога. Для избежания повторного использования правила можно ввести соответствующий атрибут (например, Used). Если условие применения одного правила зависит от результатов использования других правил, то необходимо задать соответствующий порядок (очередность). Альтернативой этому является повторная проверка выполнимости всех правил после срабатывания хотя бы одного из них.
В общем случае необходимость и очередность задавания вопросов может определяться на основе применения группы правил. Для реализации этого механизма имеет смысл объединить правила для вопросов и правила определения новых параметров.
Ниже приведены два варианта реализации таблицы правил. В таблице RulesSimple.db всегда имеется только одна посылка и одно следствие. Для реализации множества следствий необходимо написать несколько правил с одинаковой левой частью. В таблице RulesComplex.db может иметься одна или две посылки, которые могут объединяться логической, арифметической или другой операцией. Для реализации более сложного правила, содержащего три или более посылки, его нужно разбивать на несколько простых. При вероятностном или нечетком выводе можно использовать операцию приращения/уменьшения значения параметра.
Таблица RulesSimple.db
ПолеТип данныхОписаниеIDIntegerИдентификатор правилаIF_AtrStringАтрибут (свойство) объекта посылки.IF_ValueStringЗначение атрибута (свойства) объекта посылки.Then_AtrStringАтрибут (свойство) объекта следствия.Then_ValueStringЗначение атрибута (свойства) объекта следствия.UsedBooleanИспользовано/не использовано правило Таблица RulesComplex.db
ПолеТип данныхОписаниеIDIntegerИдентификатор правилаIF1_AtrStringАтрибут (свойство) объекта посылки.IF1_ValueStringЗначение атрибута (свойства) объекта посылки.OperationIntegerЛогическая операция ( 0 - нет операции, 1 - AND, 2 - OR, 3 - NOT ...)IF2_AtrStringАтрибут (свойство) объекта посылки.IF2_ValueStringЗначение атрибута (свойства) объекта посылки.Then_AtrStringАтрибут (свойство) объекта следствия.Then_ValueStringЗначение атрибута (свойства) объекта следствия. Значение ='Null', если осуществляется прирост/уменьшение вероятности гипотезы.ChangeValueInteger (Number)Прирост/уменьшение вероятности (уверенности, достоверности) гипотезы (факта).UsedBooleanИспользовано/не использовано правило ЕСЛИ [(&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)]
Дополнительно в рамках лабораторной работы можно реализовать:
* функцию синтаксического разбора логических и математических выражений в продукционных правилах;
* компоненту ввода правил в БЗ;
* возможность задания и вывода правил с помощью нечетких множеств;
* функции проверки правил на противоречивость и избыточность;
* функцию вывода новых (производных) правил;
* компоненту отображения дерева вывода;
* функции обратного, смешанного и немонотонного выводов.
3.7. Реализация принятия решения
Эта часть работы третьему этапу решения задачи. Она должна быть реализована произвольно с использованием стандартного подхода к разработке расчетно-логических систем в рамках тела программы или в виде дополнительного механизма с использование БЗ.
4. Содержание отчета * Название и цель работы
* Задание
* Краткое описание предметной области и выбранной задачи
* Перечень параметров, атрибутов и их допустимых значений
* Перечень вопросов, вариантов ответов и граф диалога
* Правила получения атрибутов A из множества исходных параметров P
* Алгоритм принятия решения (выбора) со схемой
* Алгоритм работы программы (по 3 частям)
* Структура БЗ (логическая и физическая модель данных в архитектуре реляционных или объектных БД)
* Подробный алгоритм работы программы с БЗ
* Подробная инструкция по работе с БЗ и ЭС
1
Документ
Категория
Рефераты
Просмотров
25
Размер файла
46 Кб
Теги
iis, lab, 2013, praktiku
1/--страниц
Пожаловаться на содержимое документа