Экспертные и автоматизированные системы управления не нашли своего полного и приемлемого воплощения в программных продуктах. Это обусловлено чрезвычайной сложностью задач подобного рода. Особенно трудно создавать такие системы на персональных компьютерах, которые имеют не очень высокие вычислительные мощности и ресурсы. Камнем преткновения остался до конца не раскрытый механизм принятия решения экспертом-специалистом.
Если связать эти аспекты и спросить - стоит ли тратить силы на решение этой проблемы на том техническом, теоретическом и программном уровне, который имеется в настоящий момент в нашем распоряжении или подождать лучших времен, то ответ будет однозначно положительный, несмотря всю трудоёмкость и неоднозначность решения этой проблемы. Для того, чтобы добиться успеха в выбранном направлении, следует определить ориентиры, реально способствующие решению этой задачи и смело браться за дело. Наблюдения и опыт в работе программистов и разработчиков приложений для корпоративных баз данных, последние достижения в программировании подскажут некоторые узловые моменты, необходимые для рождения экспертной системы современного стиля программирования.
Попыток создать экспертную систему было много, эта попытка будет базироваться на использовании последних достижений программирования, на построении и объединении новых концептуальных решений в программировании, изучении механизма принятия решения экспертом-человеком, получении дополнительной, достоверной развернутой и масштабной информации, опирающейся на сложные структуры базы данных.
Системный подход к решению данного вопроса требует определить средства, инструмент и подход решения вопроса. Разработать модель системы, ее внутренние связи и закономерности, принципы развития и модификации системной модели.
Для персонального компьютера классом ниже 586, выбирать из систем управления базами данных особо не приходится. Это или FoxPro или CLIPPER, в лучшем случае ACCESS for WINDOWS. Чем хороши эти системы управления базами данных и что следует выбрать для построения экспертной системы?
FoxPro хорош всем, работает и в DOS'е и в WINDOWS'е, но имеет медленный и слаборазвитый механизм обработки макросов.
ACCESS - это современный графический пакет, обладает почти всеми инструментами современного проектирования корпоративных баз данных, но очень медленно обрабатывает сложные SQL запросы на средних и больших базах данных.
CLIPPER имеет мощный механизм блоков кода, но неустойчиво работает с большими базами данных, довольно часто разрушаются индексные файлы. Имеет широкие возможности для создания всех необходимых инструментов современного проектирования.
Возьмём за основу экспертную систему для конечного пользователя, с характеристиками, присущими объектной базе данных и относительно небольших размеров. Для реализации этого проекта выберем CLIPPER. На данном этапе важно выработать системный подход и разработать мощную программную идею. Перенос программной идеи с одной платформы на другую осуществить гораздо проще, чем перенести программный код.
Рассмотрим базовые характеристики экспертной системы
Экспертная система должна иметь единый стиль программного интерфейса и программирования на всех этапах жизни этого продукта. Вся информация, связанная с экспертной системой и её поддержкой, оформляется исключительно в виде баз данных. Следует иметь единое логическое описание всех разделов и структур, как системы, так и ее поддержки, единый словарь, единую библиотеку и единый интерпретатор.
Представить себе модель экспертной системы.
Одно из самых наглядных и распространенных представлений о наблюдаемых процессах - таблицы и диаграммы. В большинстве случаев экспертная оценка осуществляется именно через таблицы и их сравнение. База данных является разновидностью таблицы, имеющей компьютерное представление и программное управление. Для понимания поверхностных связей сложной структуры базы данных представим простую схему, которая отображает взаимодействие реального мира и эксперта. Например, схему, состоящую из объекта наблюдения, которым являться человек, его здоровье или служебная карьера, методами исследования, механизмами формализации наблюдаемых фактов и системы экспертных запросов по формализованным фактам. Некоторые ключевые факты образуют карточку и определяют уникальность объекта, другие факты характеризуют методы воздействия и способы исследования объекта, основная по объему часть фактов оформляется в виде формализованного документа. Все эти факты доступны для экспертного запроса любой сложности.
Каждому объекту соответствует карточка с набором односложных атрибутов (фактов), в достаточной мере описывающая данный объект. Эти атрибуты образуют картотеку исследуемых объектов. Каждому исследованию соответствует свой набор односложных атрибутов. Такое описание позволяет накапливать статистическую информацию для экспертного запроса, как по картотеке, так и по исследованиям, проводить по атрибутам быстрый поиск и идентификацию объекта. Набор атрибутов пользователь определяет и заполняет в том объеме, который считает достаточным для своей работы. Набор атрибутов формируется динамически и каждый вновь включенный атрибут автоматически становится ключевым для поиска. Набор атрибутов исследуемого объекта может задаваться группой пользователей в том объеме, который им необходим для полноты информации. Это должно осуществляться как минимум через два списка атрибутов. Один список пользовательский. Второй список библиотечный для согласованного ведения карточки и стыковки вводимых данных. Метод исследования объекта определяется исходя из интересов пользователя. Этот метод определяет составные части объекта, порядок исследования, формализации данных и так далее.
Формализация данных должна придерживаться некоторых общих правил независимо от метода исследования. Например, на каждую составную часть исследования составляется описание и заключение. Должна допускаться вариация описаний и заключений. При необходимости, эти компоненты могут произвольно дополняться новыми компонентами.
Построение системы на вышеперечисленных постулатах должно иметь механизм подготовки формализованных документов и элементы экспертной оценки формализованных данных на этапе их ввода через формализованный документ и на стадии анализа этих данных. Экспертная оценка должна опираться как минимум на несколько видов подсистем разной степени сложности. Тогда можно надеяться на составление заключения на основе первичных описаний. Для этого введем понятие интеллектуальности и попробуем задать шкалу интеллектуальности экспертной оценки.
Первая степень - это когда результат может быть получен методом сверки введенных значений с таблицей или номограммой.
Вторая степень - позволяет пользователю по введенному описанию составной части исследования получить возможность подсказки для заключения, если для этого есть необходимость и время для ожидания формирования такой подсказки.
Третья степень - использование сложных методов формирования комплексного заключения, базирующихся на системе принятия решений, теории вероятности, функций предпочтения и так далее.
Открытая стиль сложной структуры базы данных, атрибутов картотеки и исследований формируется с помощью ассоциативных списков.
Ведение описаний и заключений проводится с помощью формализованного документа. Формализованный документ - документ, составленный с помощью заранее систематизированных и подготовленных лексем. Альтернативные лексемы объединяются в меню. Список меню образует бланк документа. Бланки статически, а при необходимости динамически, формируют документ.
Первая и вторая степень интеллектуальности системы реализуется программными методами, и не имеют больших затруднений, остальные требуют изучения механизма принятия решения экспертом-специалистом.
Что следует понимать под изучением механизма принятия решения экспертом. Некоторый статистический материал, накопленный на базе медсанчасти корпорации "Киевгорстрой" (МСЧ КГС), свидетельствует, что эксперт-специалист сознательно или бессознательно скрывает, как он достигает своей оценки, исследуя исходный материал.
Например, в кабинете ультразвуковой диагностики МСЧ КГС за три года было обследовано 10 000 человек, составлено более 30 000 описаний и заключений. Все исследования имеют формализованный характер, что позволяет сравнивать эти исследования и сопоставлять их. Описания и заключения составляются на основе просмотра эхограмм ультразвукового аппарата, как в реальном масштабе времени, так и в записи (на видеомагнитофоне, в памяти компьютера). Заполнение описаний и заключения ведется по канонам, принятым в этом разделе медицины [14].
Анализ описаний и заключений показал, что их качество (полнота описаний и частота выбора однотипных нозологий в заключении) меняется со временем. Это зависит от школы специалиста, от опыта, который со временем приобретается, от качества формализации знаний в виде используемого формализованного документа. Но самое интересное наблюдение состоит в том, что информация описания, определяющее заключение в описательной части теряется. Это подтверждается тем, что целый ряд не родственных заключений имеют абсолютно одинаковые описания. И даже эксперт-специалист по одному описанию не в состоянии повторить заключение в таком виде, как оно было сделано без дополнительного просмотра эхограмм в записи.
Отсюда напрашивается вывод, что экспертная система должна создать такие условия работы специалисту, при которых вся доступная для него информация должна быть отображена в описательной части, доже подразумеваемая или интуитивная.
Для этого необходимо использовать современные тенденции создания программных приложений, опирающиеся на использование объектно-ориентированные методы программирования и объектно-ориентированные базы данных. Здесь поможет моделирование программного приложения.
Методика объектного подхода (МОП) позволяет заложить решение сложных и объемных задач, поэтому нелишне вспомнить ключевые понятия МОП.
Методика объектного подхода подразумевает прежде всего использование объектно-ориентированных языков программирования. Но поскольку мы уже остановились на CLIPPER'е, который таковым не является, то придется подработать основные идеи объектно-ориентированного программирования (ООП) для нашей ситуации.
Все методические пособия по ООП направлены на то, чтобы выработать новый стереотип мышления программистов. Мы не будем отступать от этого правила, и решим для себя, что же является главным, за что потянуть, чтобы вытянуть нашу задачу.
Пять ключевых компонент объектно-ориентированной парадигмы: объект, сообщение, класс, экземпляр объекта и метод.
Объект - это инкапсулированная абстракция, которая включает информацию о состоянии и четко определенное множество протокола доступа (сообщения, которые обрабатывает объект).
Сообщение - это специальный символ, идентификатор или ключевое слово с или без параметров, которое представляет выполняемое объектом действие.
Класс представляет определенный тип объектов и задается при помощи описания класса, которое определяет переменные состояния и протокол доступа к объектам данного класса. Классы организуются иерархически, причем подклассы наследуют свойства породивших их классов - это также и объекты.
Экземпляр объекта. Объекты принадлежат к какому-либо классу. Свойства экземпляра объекта определяются описанием класса.
Метод существует для каждого сообщения, определенного для некоторого класса. Метод определяет реакцию объекта на сообщение. Обычно состоит из ряда выражений и может использовать протокол из другого класса.
Конкретные языки программирования могут иметь терминологию, несколько отличающуюся от приведенной выше, но нам важна не точность определений, а их принцип.
Некоторые принципы ООП реализуются непосредственно через компилятор соответствующего языка программирования, нам все принципы придется моделировать.
В нашем случае объектом является форма базы данных. Эта форма порождает ряд сообщений, которые требуют метода обработки этого сообщения. Целесообразно объединить сообщение и метод в одно понятие и назвать вектором обработки события формы. Векторы обработки событий должны построить весь антураж формы на экране и отработать нажатие функциональных клавиши, присущих этой форме. Основные векторы формы должны быть четко оговорены и представлены в виде полей базы данных. Поскольку с базами данных трудно организовать иерархию, как это принято в ООП, выход из ситуации реализуем через сложную систему описания форм.
Мощный инструмент разработки экспертной системы получаем, если использовать сложную структуры данных, объединённую с ассоциативными базами данных. База данных экспертной системы должна быть представлена в виде множества фактов таким образом, чтобы получать четко структурированную информацию. Для этого используем абстракцию данных, которую применяем как процесс организации различных фрагментов информации, рассмотренных выше, в единые логические единицы (возможно, иерархические), придавая ей при этом некоторую концептуально осмысленную форму. Каждая информационная единица должна быть легко доступна в программе. В идеальном случае все детали реализации такой структуры должны быть невидимы пользователю этой структуры. Самое главное в этом процессе - дать пользователю возможность использовать информацию, не думая о деталях её действительного представления.
Теперь на новом уровне объединить современные методы программирования, теорию принятия решения и системный подход к решению задачи.
Можно представить все с точки зрения языка Пролог. Очень интересная получается картина. Всю Пролог-систему реализовать трудно, да и незачем. Выберем самое главное. Язык Пролог как самостоятельный продукт программирования имеет низкоуровневый механизм доступа к файлам, объявления переменных и так далее. Все это отягощает Пролог-систему, все это опустим. Оставим только чистую логику. Ниже перечислим наиболее важные аспекты, позаимствованные у Пролога и немного подработанные под экспертную систему.
Пользователь должен иметь возможность задавать вопросы системе, касающиеся отношений (формальных параметров), определённые в программе.
Система отношений состоит из односложных атрибутов и формализованных документов.
Вопросы к системе строятся в виде экспертного запроса и образуют статистический отчет.
Если на вопрос существует несколько ответов, система найдёт столько из них, сколько пожелает пользователь.
Работа с системой состоит в заполнении формализованных документов и в постановке вопросов, касающихся этих документов.
Процедура заполнения документа - это множество предложений об одном и том же отношении.
Вопросы представляют собой запросы к базе данных. Ответы системы на вопрос - множество объектов, которые удовлетворяют запросу.
Рассмотрим объект данных системы. Объектами данных являются атрибуты и формализованный документ.
Атрибуты - это простая структура данных. Формализованный документ - сложная форма описания.
Таким образом, базу данных системы можно легко представить в виде «прологовских» терминов. А, используя такие механизмы Пролога, как вопросы и сопоставления, можно гибко и эффективно получать информацию из базы данных. Кроме того, можно использовать вспомогательные утилиты, еще больше облегчающие взаимодействие с базой данных. Абстракцию данных можно рассматривать как метод, который облегчает работу со сложными структурами данных.
Часто основным шагом на пути к решению оказывается обобщение задачи. Парадоксально, но рассмотрение более общей задачи позволяет облегчить формулировку решения.
Остался последний штрих создания экспертной системы. Это дать ей имя, например, ixBASE
