2. Разработка и программирование функциональной модели предметной области

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

Разработка правил принятия решения по выбору аппаратной платформы

Необходимо разработать функциональную модель предметной области с использованием продукционных правил. Для этого следует создать базу знаний в ЭО KАРРА и апробировать ЭС, запустив ее из окна интерпретатора.

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

• платформа должна быть применена,

• платформа может быть применена,

• платформа не может быть применена.

В данном случае предварительно должна быть расширена объектная модель предметной области путем увеличения перечня слотов классов Systemза счет их частных и обобщенных характеристик. Конечные рекомендации экспертной системы формируются в процессе логического вывода на основании значений обобщенных характеристик. Те же, в свою очередь, формируются также в процессе логического вывода на основе значений частных характеристик. Последние изначально вводятся пользователем ЭС. В качестве обобщенных характеристик могут быть рекомендованы:

• адекватность технических характеристик (AdekvTH)

• ценовая категория (CenaKat),

• перспективность платформы (PerspPl),

• перспективность изделия (PerspIzd),

• надежность поставщика (NadPost).

Пусть обобщенные и частные характеристики могут принимать лишь значения: низкое (niz), среднее (sr), высокое (vis). Например, перспективность платформы – высокая, надежность поставщика – низкая и т.п.

Частные характеристики платформы могут быть разнообразны и выбираются студентом самостоятельно. Например, частными характеристиками, составляющими базу для выводов о ценовой категории, могут быть: цена комплектующих (CenaKomp), сроки поставки (SrokPost) и стоимость изготовления (StoimIzg), для выводов об адекватности технических характеристик - производительность процессора (ProizvProc), пропускная способность канала (PropSpos) и энергопотребление (EP) и т.п.

Методические указания.

Описание правил. Основным средством разработки функциональной модели являются правила. В общем виде правила имеют следующую конструкцию:

IF посылка THEN заключение.

Каждое правило имеет имя. Для создания правил используется редактор правил (окно Ktools, пиктограмма Rule). Окно редактора имеет два основных поля If и Then, где пользователь набирает тексты посылки и заключения соответственно. Как посылки, так и заключения представляют собой выражения, состоящие из имен классов, объектов, их слотов и значений слотов.

В правилах можно, но необязательно использовать переменные, называемые в ЭО КАРРА Patterns (образцы переменной). В поле Patterns справа от вертикальной черты пишут имя класса, для анализа которого используется это правило, а слева от вертикальной черты пишут имя переменной, которое будет фигурировать в правиле и представлять любой объект из рассматриваемого класса. Правило, описанное таким образом, работает для любого объекта или подкласса этого класса. В результате использования этого приема можно одно и то же правило применить ко многим объектам.

Рекомендуется при выполнении задания не создавать сразу все необходимые правила, а создать сначала, например, лишь правила, которые обслуживают только две рекомендации. Пусть этими рекомендациями будут, например, «платформа должна быть применена» и «платформа не может быть применена». При этом пусть также эти две рекомендации опираются лишь на две обобщенные характеристики – ценовая категория и адекватность технических характеристик. Такой прием называют разработкой прототипной системы. Для такого прототипа достаточно шести правил. Каждое из шести правил своим заключением будет обслуживать одну ситуацию:

Правила, формирующие рекомендации

1. Правило DP: Если ценовая категория низкая и адекватность технических характеристик высокая, то платформа должна быть применена.

2. Правило NMP: Если ценовая категория высокая и адекватность технических характеристик низкая, то платформа не может быть применена.

Правила, формирующие обобщенные характеристики

1. Правило CenaN: Если цена комплектующих низкая и себестоимость изготовления низкая, то ценовая категория низкая.

2. Правило CenaV: Если цена комплектующих высокая и себестоимость изготовления низкая и сроки поставки средние, то ценовая категория средняя.

3. Правило TehV: Если производительность процессора достаточна и пропускная способность канала достаточна и энергопотребление в пределах допустимого, то адекватность технических характеристик высокая.

4. Правило TehN: Если производительность процессора недостаточна и пропускная способность канала достаточна и энергопотребление в пределах допустимого, то адекватность технических характеристик низкая.

На рис. 1.12 приведен пример оформления правила AdekTH, где символ #= (решетка с равенством) обозначает сравнение строковых переменных.

Запуск логического вывода. В систему КАРРА встроены механизмы прямого и обратного выводов. Для их инициирования предусмотрены две соответствующие функции манипулирования знаниями ForwardChain() и BackwardChain(), основным аргументом которых является имя цели вывода. В принципе, инструмент целей (Goal) разрабатывался специально для построения цепочки рассуждений в обратном на­правлении, но можно с помощью этого механизма прерывать и рассуждения, проводимые в прямом направлении (как только Цель достигнута, вывод заканчивается). Цели описываются в редакторе целей Goal (окно Ktools) на KAL. Они должны иметь имена. Кроме цели, среди аргументов этих функций может быть перечень активизируемых правил. Если в записи функции опускается обязательный аргумент, например, имя цели в функциях, инициирующих вывод, то на его месте пишется NULL.

Пусть при реализации прямого вывода используется цель с именем Rekom. Тогда логический вывод инициируется с помощью функции:

ForwardChain (Rekom).

В проектируемой ЭС цель (условие окончания прямого логического вывода) может быть определена как появление некоторого признака, свидетельствующего о выработке первой рекомендации. Для этого определите в объекте Global слот с именем Rekom, который может принимать два значения – begin и end. Значение begin присваивается слоту перед началом логического вывода, значение end – сразу после выдачи первой рекомендации. В результате выражение для цели имеет вид:

Global:Rekom #= end;

Реализация логического вывода. При реализации как прямого, так и обратного выводов формируются два списка. Первый из них – это список правил (Rule List), намеченных к анализу на последующих шагах логического вывода. При прямом выводе правило включается в список, если его посылка содержит пару объект:слот из заключения, полученного на предыдущем шаге. При обратном выводе наоборот, а именно, правило включается в список, если его заключение содержит пару объект:слот из анализируемой посылки. Построение списка правил порождает второй список. Действительно, рассмотрим прямой вывод. В общем случае каждое правило, включаемое в первый список (Rule List), имеет в своей посылке еще и другие условия, кроме того, из-за которого оно было включено в этот список. Истинность всех этих дополнительных условий должна быть проверена прежде, чем это правило будет применено в процессе рас­суждения. Для этого соответствующие этим условиям пары объект:слот собираются в специальном списке Agenda и затем последовательно проверяются на истинность. Очевидно, что в момент запуска прямого вывода этот список не должен быть пуст. Поэтому перед запуском в список заносится одна или более пар объект:слот, которых достаточно, по мнению разработчика, для начала вывода. Занесение производится с помощью команды Assert (), аргументом которой является имя заносимого слота. Заметим, что в ЭО Kappa принято считать, что все функции, инициирующие какие-либо действия, принимают значения TRUE и FALSE (истина, ложно). В отношении функций инициирующих логический вывод такой подход адекватен, т.к. при этом доказывается истинность или ложность некоторого утверждения (цели).

В создаваемом проекте ЭС перед началом прямого логического вывода в список Agenda должны быть занесены слоты, отражающие все частные характеристики платформы. Таких характеристик в прототипной системе для двух приведенных выше правил четыре. Каждая характеристика заносится отдельной функцией Assert. Чтобы при каждом запуске ЭС не набирать шесть функций, сформируем пользовательскую функцию Init, включающую все эти функции, а также осуществляющую присваивание начальных значений всем устанавливаемым в процессе вывода слотам (рис. 1.13). Функцию создайте в редакторе функций (пиктограмма Function в окне Ktools).

Отладка базы знаний ЭС

Как правило, при разработке базы знаний допускаются многочисленные ошибки. Часто они являются следствием недостаточной внимательности и организованности. Так, например, в результате ошибки могут не совпадать обозначения одного и того же слота, использованные в предметной и функциональной моделях. Вплоть до того, что в одном случае имя может начинаться с большой буквы, в другом с маленькой. Иногда возникает путаница в обозначениях оператора присваивания «=», оператора сравнения данных числового типа «==» и оператора сравнения данных символьного типа «#=». Также распространена ошибка, когда вместо круглых скобок ставится квадратная и наоборот. Для обнаружения подобных и многих других ошибок в ЭО KAPPA предусмотрены средства отладки.

Окно связи правил (рис. 1.14). Просмотреть в окне Rule Relations все созданные правила. Временно исказите в каком-либо правиле имя слота и пронаблюдайте изменение структуры связей в окне связи правил.

Методические указания. В этом окне можно просматривать связи правил. Для этого надо выбрать интересующее Вас правило, тогда в группе IF Dependencies окажутся пра­вила, заключения которых являются посылками для него, а справа (в разделе Then Dependencies) - правила, предпосылки которых - заключение нашего правила. Слоты, которыми связаны эти правила, просматриваются посредством выбора пункта List Slots из всплывающего меню (при выборе конкретного правила).

Можно просмотреть отношения любого правила, появившегося в этом окне, вы­брав его с помощью мыши или обратившись к пунктам меню Options/Show Relations. Кроме того, из этого окна возможна загрузка редактора правил.

Активная трассировка логического вывода. Пошаговый режим. Осуществить трассировку логического вывода в прототипной ЭС. Просмотреть ее работу в окне Rule Trace в пошаговом режиме.

Методические указания. Окно Rule Trace позволяет просматривать процесс рассуждения поэтапно, т.е. является инструментом отладки (трассировки) системы правил. Формирование прямой цепочки рассуждений можно выполнять в режиме актив­ной трассировки (Active Trace Mode). При этом можно по Списку слотов (Agenda) и Списку Правил (Rule List) видеть процесс формирования цепочки. Кроме того, можно прой­ти весь процесс формирования цепочки по шагам.

Окно трассировки правил (The Rule Trace window) содержит три дочерних окна и одну кнопку: окно текста трассировки (Trace Text window), окно Списка слотов (Agenda list box), в нем перечисляются, все необходимые в процессе рассуждения пары объект: слот), список трассируемых правил (Rule list box) и кнопку Шаг (Step button). По умолчанию, видимым является только окно с текстом трассировки (когда режим ак­тивной трассировки выключен).

Если установлен режим активной трассировки (с помощью меню Options в окне Rule Trace), то станут видимыми и остальные дочерние окна. Кнопка Шага появля­ется, если выполняется прямое формирование цепочки по шагам. Чтобы установить пошаговый режима, необходимо прежде установить режим активной трассировки. Поша­говый режим автоматически вызывает функцию ForwardChain (формирования цепочки рассуждений в прямом направлении), появляется диалоговая панель с запросом аргумен­тов этой функции.

Для пошаговой трассировки прототипной ЭС необходимо сделать следующее.

1. Выполнить в окне интерпретатора функцию Init со значением аргумента, равным имени анализируемого объекта.

2. В окне трассировки правил выбрать режим активной трассировки (Activ Trace в меню Options).

3. Выбрать в меню Options пункт Step Mode и ввести из аргументов функции ForwardChain только имя цели Rekom. В результате появится кнопка Step и можно начинать пошаговую трассировку ЭС.

После нажатия экранной кнопки Step очередной элемент из списка слотов удаляется, и в список правил добавляются все правила, имеющие отношение к этому элементу. Стрелка на кнопке Step показывает направление действия следующего шага. Очередное нажатие этой кнопки удалит следующее правило из списка и добавит новые элементы в список слотов.