2.2. Технология разработки экспертных систем

Информация для экспертной системы поступает из пред­метной области ПО. Разработка экспертной системы для кон­кретной ПО состоит из нескольких унифицированных этапов (Рис.3). Первый из них - идентификация И. На этом этапе рассматри­вается предметная область и определяется целесообразность и возможность создания экспертной системы. Принцип целесо­образности состоит в выявлении степени неопределенности предметной области. Если предметная область может быть четко формализована в виде алгоритмической или матема­ти­ческой модели, то экспертную систему создавать нецелесообразно.

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

После этого осуществляется формализация Ф. При Ф

13

систематизирован­ные признаки предметной области представляются в символь­ном виде и разрабатываются или предлагаются правила рабо­ты с символьными представлениями. После Ф на этапе выпол­не­ния В экспертная система наполняется знаниями, т.е. сведе­ни­ями в символьном представлении, которые описывают раз­лич­ные ситуации (свойства) предметной области. Здесь же символь­ные данные описываются средствами программирова­ния вычислительных систем.

ПО ЭС

И

Т ОЭ

ПФ

ПФ ПК

К

Ф

В

Рис.3. Последовательность разработки экспертной системы

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

14

зации. При положительном выводе о готовности системы, она передается конечному пользова­те­лю.

Обычно разработка систем выполняется как разработка прототипов, т.е. не ставится задача разработки сразу системы с полным объемом знаний. Для начала на этапах И и К выбира­ются наиболее существенные признаки ПО, и система разраба­тывается и тестируется только в объеме этих признаков. В даль­нейшем в систему добавляется новый объем признаков, создается второй прототип и так далее до исчерпания всех известных признаков.

2.3. Механизм вывода в экспертных системах

При принятии решения сначала выполняется выборка Выб (Рис. 4). При выборке из рабочей памяти РП извлекаются данные, а из базы знаний БЗ правила.

В

РП

РК

Соп.

Выб.

ОМ

КМ

АМ

БЗ

Рис. 4. Последовательность вывода в экспертных системах

Выбранный означенный модуль ОМ выполняется на этапе выполнения Все извлекаемые данные и знания анализируются на возможность применения при решении. В ре­зуль­тате чего создается набор активных модулей АМ. Далее модули из набора сопоставляются (Соп). При сопоставлении создаются пары или тройки из данных и правил, т.е. выбира­ют­ся данные и правила, которые к этим данным можно приме­нить. Резуль

15

тат сопоставления – набор конфликтных модулей КМ. Модули конфликтны в том смысле, что поиск решения может начинаться с любого из них. Выбор последовательности работы с модулями осуществляется при разрешении конфлик­тов РК. В. В результате модифицируется РП (изменение данных). В дальнейшем механизм вывода может работать или в стадии РК до перебора всех конфликтных модулей или запускаться по полному циклу с учетом модификации базы данных (РП).