Какие действия предполагает этап стыковки экспертной системы

Какие действия предполагает этап стыковки экспертной системы

Разработка программных комплексов экспертных систем как за рубежом, так и в нашей стране находится на уровне скорее искусства, чем науки. Это связано с тем, что долгое время системы искусственного интеллекта внедрялись в основном во время фазы проектирования, а чаще всего разрабатывалось несколько прототипных версий программ, прежде чем был получен конечный продукт. Такой подход действует хорошо в исследовательских условиях, однако в коммерческих условиях он является слишком дорогим, чтобы оправдать коммерчески жизненный продукт.

Процесс разработки промышленной экспертной системы, опираясь на традиционные технологии [4,8,10], можно разделить на шесть более или менее независимых этапов (рис 16.7), практически не зависимых от предметной области.

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

В целом за разработку экспертных систем целесообразно браться организации, где накоплен опыт по автоматизации рутинных процедур обработки информации, например:

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

ЭТАП 1: ВЫБОР ПОДХОДЯЩЕЙ ПРОБЛЕМЫ

Этот этап включает деятельность, предшествующую решению начать разрабатывать конкретную ЭС. Он включает:

определение проблемной области и задачи;

нахождение эксперта, желающего сотрудничать при решении проблемы, и назначение коллектива разработчиков;

определение предварительного подхода к решению проблемы;

анализ расходов и прибыли от разработки;

подготовку подробного плана разработки.

Рис. 16.7. Этапы разработки ЭС

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

При выборе области применения следует учитывать, что если знание, необходимое для решения задач, постоянное, четко формулируемое и связано с вычислительной обработкой, то обычные алгоритмические программы, по всей вероятности, будут самым целесообразным способом решения проблем в этой области,

Экспертная система ни в коем случае не устранит потребность в реляционных базах данных, статистическом программном обеспечении, электронных таблицах и системах текстовой обработки. Но если результативность задачи зависит от знания, которое является субъективным, изменяющимся, символьным или вытекающим частично из соображений здравого смысла, тогда область может обоснованно выступать претендентом на экспертную систему.

Приведем некоторые факты, свидетельствующие о необходимости разработки и внедрения экспертных систем:

нехватка специалистов, расходующих значительное время для оказания помощи другим;

потребность в многочисленном коллективе специалистов, поскольку ни один из них не обладает достаточным знанием;

сниженная производительность, поскольку задача требует полного анализа сложное набора условий, а обычный специалист не в состоянии просмотреть (за отведенное время) все эти условия;

большое расхождение между решениями самых хороших и самых плохих исполнителей;

наличие конкурентов, имеющих преимущество в том, что они лучше справляются с поставленной задачей.

Подходящие задачи имеют следующие характеристики:

не зависят в значительной степени от общечеловеческих знаний или соображении здравого смысла;

o не являются для эксперта ни слишком легкими, ни слишком сложными (время, необходимое эксперту для решения проблемы, может составлять от трех часов до трех недель);

условия исполнения задачи определяются самим пользователем системы;

имеет результаты, которые можно оценить.

Обычно экспертные системы разрабатываются путем получения специфических знаний от эксперта и ввода их в систему. Некоторые системы могут содержать стратегии одного индивида. Следовательно, найти подходящего эксперта — это ключевой шаг в создании экспертных .систем.

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

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

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

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

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

Наметились тенденции разработки менее дорогостоящих систем, хотя и с более длительным сроком возвращаемости вложенных в них средств, так как программные средства разработки экспертных систем непрерывно совершенствуются.

После того как инженер по знаниям убедился, что:

• данная задача может быть решена с помощью экспертной системы;

• экспертную систему можно создать предлагаемыми на рынке средствами;

• имеется подходящий эксперт;

• предложенные критерии производительности являются разумными;

• затраты и срок их возвращаемости приемлемы для заказчика.

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

ЭТАП 2: РАЗРАБОТКА ПРОТОТИПНОЙ СИСТЕМЫ

Понятие прототипной системы

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

Объем прототипа — несколько десятков правил, фреймов или примеров. На рис. 16.8 изображены шесть стадий разработки прототипа и минимальный коллектив разработчиков, занятых на каждой из стадий (пять стадий заимствованы из [10]). Приведем краткую характеристику каждой из стадий, хотя эта схема представляет грубое приближение к сложному итеративному процессу.

Рис.16.8.Стадии разработки прототипа ЭС

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

Сроки приведены условно, так как зависят от квалификации специалистов и особенностей задачи.

Идентификация проблемы

Уточняется задача, планируется ход разработки прототипа экспертной системы, определяются:

необходимые ресурсы (время, люди, ЭВМ и т.д.);

источники знаний (книги, дополнительные эксперты, методики);

имеющиеся аналогичные экспертные системы;

цели (распространение опыта, автоматизация рутинных действий и др.);

классы решаемых задач и т.д.

Идентификация проблемы — знакомство и обучение коллектива разработчиков, а также создание неформальной формулировки проблемы.

Средняя продолжительность 1 — 2 недели.

Извлечение знаний

Происходит перенос компетентности экспертов на инженеров по знаниям с использованием различных методов:

наблюдение и другие.

Извлечение знаний — получение инженером по знаниям наиболее полного представления о предметной области и способах принятия решения в ней.

Средняя продолжительность 1 -3 месяца.

Структурирование или концептуализация знаний

Выявляется структура полученных знаний о предметной области, т.е. определяются:

список основных понятий и их атрибутов;

отношения между понятиями;

структура входной и выходной информации;

стратегия принятия решений;

ограничения стратегий и т.д.

Концептуализация знаний — разработка неформального описания знаний о предметной области в виде графа, таблицы, диаграммы или текста, которое отражает основные концепции и взаимосвязи между понятиями предметной области.

Такое описание называется полем знаний. Средняя продолжительность этапа 2 — 4 недели.

Формализация.

Строится формализованное представление концепций предметной области на основе выбранного языка представления знаний (ЯПЗ). Традиционно на этом этапе используются:

логические методы (исчисления предикатов I порядка и др.);

продукционные модели (с прямым и обратным выводом);

объектно-ориентированные языки, основанные на иерархии классов, объектов и др.

Формализация знаний — разработка базы знаний на языке, который, с одной стороны, соответствует структуре поля знаний, а с другой — позволяет реализовать прототип системы на следующей стадии программной реализации.

Все чаще на этой стадии используется симбиоз языков представления знаний, например, в системе ОМЕГА [7] — фреймы + семантические сети + полный набор возможностей языка исчисленияпредикатов. Средняя продолжительность 1 — 2 месяца.

Реализация

Создается прототип экспертной системы, включающий базу знаний и остальные блоки, при помощи одного из следующих способов:

программирование на традиционных языках типа Паскаль, Си и др.;

программирование на специализированных языках, применяемых в задачах искусственного интеллекта: LISP [14], FRL [I], SmallTalk [7] и др.;

использование инструментальных средств разработки ЭС типа СПЭИС [З], ПИЭС [11];

использование «пустых» ЭС или «оболочек» типа ЭКСПЕРТ [2], ФИАКР [7] и др.

Реализация — разработка программного комплекса, демонстрирующего жизнеспособность подхода в целом. Чаще всего первый прототип отбрасывается на этапе реализации действующей ЭС.

Средняя продолжительность 1 — 2 месяца.

Тестирование

Оценивается и проверяется работа программ прототипа с целью приведения в соответствие с реальными запросами пользователей. Прототип проверяется на:

удобство и адекватность интерфейсов ввода-вывода (характер вопросов в диалоге, связность выводимого текста результата и др.)

• эффективность стратегии управления (порядок перебора,использование нечеткого вывода и др.);

• качество проверочных примеров;

• корректность базы знаний (полнота инепротиворечивость правил).

Тестирование — выявление ошибок в подходе и реализации прототипа и выработка рекомендаций по доводке системы до промышленного варианта.

Средняя продолжительность 1 — 2 недели.

ЭТАП 3: РАЗВИТИЕ ПРОТОТИПА ДО ПРОМЫШЛЕННОЙ ЭС

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

Если первоначально выбранные объекты или свойства оказываются неподходящими, их необходимо изменить. Можно сделать оценку общего числа эвристических правил, необходимых для создания окончательного варианта экспертной системы. Иногда [14] при разработке промышленной системы выделяют дополнительные этапы для перехода: демонстрационный прототип — исследовательский прототип — действующий прототип — промышленная система.

Однако чаще реализуется плавный переход от демонстрационного прототипа к промышленной системе, при этом, если программный инструментарий выбран удачно, необязательна перепись другими программными средствами.

Понятие же коммерческой системы в нашей стране входит в понятие промышленный программный продукт, или промышленной ЭС в этой работе (табл. 16.1).

Таблица 6.1. Переход от прототипа к промышленной экспертной системе

Демонстрационный прототип ЭС

Система решает часть задач, демонстрируя ж из неспособность полхода (несколько десятков правил или понятий)

Исследовательский прототип ЭС

Система решает большинство задач, но не устойчива в работе и не полностью проверена [несколько сотен правил или понятий)

Действующий прототип ЭС

Система надежно решает все задачи на реальных примерах, но для сложной задачи требует много времени и памяти

Система обеспечивает высокое качество решений при минимизации требуемого времени и памяти: переписывается с использованием более эффективных средстн представления знаний

Промышленная система, пригодная к продаже, т.е. хорошо документирована и снабжена сервисом

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

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

На этом этапе разработки большинство экспертов узнают достаточно о вводе правил и могут сами вводить в систему новые правила. Таким образом, начинается процесс, во время которого инженер по знаниям передает право собственности и контроля за системой эксперту для уточнения, детальной разработки и обслуживания.

ЭТАП 4: ОЦЕНКА СИСТЕМЫ

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

критерии пользователей (понятность и «прозрачность» работы системы, удобство интерфейсов и др.);

критерии приглашенных экспертов (оценка советов-решений, предлагаемых системой, сравнение ее с собственными решениями, оценка подсистемы объяснений и др.);

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

ЭТАП 5: СТЫКОВКА СИСТЕМЫ

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

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

Для подтверждения полезности системы важно предоставить каждому из пользователей возможность поставить перед ЭС реальные задачи, а затем проследить, как она выполняет эти задачи. Чтобы система была одобрена, необходимо представить ее как помощника, освобождающего пользователей от обременительных задач, а не как средство их замещения.

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

Пример 16.15. Успешно состыкована со своим окружением система PUFF — экспертная система для диагностики заболеваний легких [10]. После того, как PUFF была закончена и все были удовлетворены ее работой, систему перекодировали с LISPa на Бейсик. Затем систему перенесли на ПК, которая уже работала и больнице. В свою очередь, эта ПК была связана с измерительными приборами. Данные с измерительных приборов сразу поступают в ПК. PUFF обрабатывает эти данные и печатает рекомендации для врача. Врач в принципе не взаимодействует с PUFF. Система полностью интегрирована со своим окружением — она представляет собой интеллектуальное расширение аппарата исследования легких, который врачи давно используют.

Пример 16.16. Другая система, которая хорошо функционирует в своем окружении, — САТ-1 [8] — экспертная система для диагностики неисправностей дизелей локомотивов.

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

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

ЭТАП 6: ПОДДЕРЖКА СИСТЕМЫ

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

Пример 16.17. Удачным примером ЭС, внедренной таким образом, является XCON (R1) — ЭС, которую фирма DEC использует для комплектации ЭВМ семейства VAX. Одна из ключевых проблем, с которой столкнулась фирма DEC, — необходимость постоянного внесения изменений для новых версий оборудования, новых спецификаций и т.д. Для этой цели XCON поддерживается в программной среде OPS5.

VI Международная студенческая научная конференция Студенческий научный форум — 2014

ПРОЕКТИРОВАНИЕ И РЕАЛИЗАЦИЯ ЭКСПЕРТНОЙ СИСТЕМЫ НА ЯЗЫКЕ ПРОГРАММИРОВАНИЯ PROLOG

Богданова Н.Ю. 1 , Буслова Н.С. 1
1 Тобольская государственная социально-педагогическая академия им. Д.И.Менделеева
Работа в формате PDF

Текст работы размещён без изображений и формул.
Полная версия работы доступна во вкладке «Файлы работы» в формате PDF

ВВЕДЕНИЕ

Сегодня всем, кто работает в области информатики или интересуется этой областью науки, известен термин «экспертные системы». Экспертная система (ЭС) (expert system, knowledge based system) — это программная система, знания и умения которой сравнимы с умением и знаниями специалистов в какой-нибудь специальной области знаний. ЭС вместе с системами обработки естественных языков являются наиболее важными в коммерческом плане областями использования искусственного интеллекта.

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

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

В настоящее время проблема разработки ЭС отражены в работах Джозефа Джарратано и Гари Райли «Экспертные системы: принципы разработки и программирование», Таунсенда К., Фохта Д. «Проектирование и программная реализация экспертных систем на персональных ЭВМ».Изучением различных аспектов данной проблемы занимались Питер Джексон «Введение в экспертные системы», Уотермен Д. «Руководство по экспертным системам».

Цель исследования – спроектировать и реализовать экспертную систему «Определение неисправности при запуске компьютера».

Объект исследования –процесспроектирования иреализации экспертной системы.

Предмет исследования –структура и содержание экспертной системы на языке программирования PROLOG.

Задачи исследования:

1. Изучить и проанализировать научную литературу по проблеме исследования;
2. Изучить понятие ЭС и ее структуру;
3. Изучить технологию проектирования ЭС;
4. Спроектировать и реализовать ЭС на языке программирования PROLOG.

Методы исследования:

1. Анализ литературы по теме исследования;

2. Формализация полученных знаний для построения базы знаний ЭС.

Теоретической основой исследованиявыступили работы таких авторов как:Джозеф Джарратано и Гари Райли «Экспертные системы: принципы разработки и программирование», Таунсенд К., Фохт Д. «Проектирование и программная реализация экспертных систем на персональных ЭВМ», Питер Джексон «Введение в экспертные системы», Уотермен Д. «Руководство по экспертным системам».

Практическая значимость исследования заключается в том, что ЭС «Определение неисправности при запуске компьютера» будет полезна для начинающих пользователей ПК, а также студентам изучающим архитектуру ПК.

ГЛАВАI. ТЕОРЕТИЧЕСКИЕ АСПЕКТЫ ПРОЕКТИРОВАНИЯ И РЕАЛИЗАЦИИ ЭКСПЕРТНЫХ СИСТЕМ

1.1. Понятие и свойства экспертных систем

В информатике ЭС рассматриваются совместно с базами знаний как модели поведения экспертов в определенной области знаний с использованием процедур логического вывода и принятия решений, а базы знаний – как совокупность фактов и правил логического вывода в выбранной предметной области деятельности.

Знания являются явными и доступными, что отличает ЭС от традиционных программ, и определяет их основные свойства такие как:

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

2. Наличие прогностических возможностей, при которых ЭС выдает ответы не только для конкретной ситуации, но и показывает, как изменяются эти ответы в новых ситуациях, с возможностью подробного объяснения каким образом новая ситуация привела к изменениям.

3. Обеспечение такого нового качества, как институциональная память, за счет входящей в состав ЭС базы знаний, которая разработана в ходе взаимодействий со специалистами организации, и представляет собой текущую политику этой группы людей. Этот набор знаний становится сводом квалифицированных мнений и постоянно обновляемым справочником наилучших стратегий и методов, используемых персоналом.

4. Возможность использования ЭС для обучения и тренировки руководящих работников, обеспечивая новых служащих.

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

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

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

1.2. Классификация, структура и задачи экспертных систем

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

— системы, базирующиеся на правилах;

— системы, базирующиеся на логике;

— системы, базирующиеся на фреймах;

— системы, базирующиеся на моделях.

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

Системы, базирующиеся на правилах, наиболее популярны из-за своей простоты и наглядности. В этих системах вся информация хранится в виде правил Пролога. Второй тип ЭС – системы, базирующиеся на логике, — наиболее точно отражают структуру Пролога. В подобных системах основу базы знаний составляют факты (предложения-утверждения).

Для классификации ЭС можно использовать различные критерии.

1. По назначению ЭС можно условно разделить на консультационные (информационные), исследовательские и управляющие. Консультационные ЭС предназначены для получения квалифицированных ответов; исследовательские – для помощи пользователю квалифицированно решать научные задачи; управляющие – для автоматизации управления процессами в реальном масштабе времени.

2. По сложности и объему базы знаний –неглубокие и глубокие. Неглубокие (простые) ЭС имеют относительно малые БЗ. Доказательства их заключений обычно коротки, большинство выводов являются прямыми следствиями информации, хранимой в базе знаний. Такие ЭС в основном предназначены для решения относительно простых задач типа ответов на запросы по требуемой информации.

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

3. По области применения ЭС делятся следующие классы.

1) Диагностика.Например, медицинская диагностика, когда системы используются для установления заболеваний; техническая диагностика, когда определяют неисправности в механических и электрических устройствах.

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

3) Планирование и проектирование. Такие системы предназначены для достижения конкретных целей при решении задач с большим числом переменных (консультации по приобретению товаров, проектирование космических станций, и так далее).

4) Интерпретация. Интерпретирующие системы обладают способностью получать определенные заключения на основе результатов наблюдения (например, местоположение и тип судов в океане по данным акустических систем слежения).

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

6) Обучение. Экспертно-обучающие системы реализуют следующие педагогические функции: учение, обучение, контроль и диагностику знаний, тренировку.

4. По связям с реальным миром.

1) Статические ЭС разрабатываются в предметных областях, в которых БЗ и интерпретируемые данные не меняются во времени, они стабильны. Например, диагностика неисправностей в автомобиле.

2) Квазидинамические ЭС интерпретируют ситуацию, которая меняется с некоторым фиксированным интервалом времени. Например, микробиологические ЭС, в которых снимаются лабораторные изменения с технологического процесса один раз в 4 -5 часов и анализируется динамика полученных показателей по отношению к предыдущему измерению.

3) Динамические ЭС работают в сопряжении с датчиками объектов в режиме реального времени с непрерывной интерпретацией поступающих в систему данных. Например, управление гибкими производственными комплексами, мониторинг в реанимационных палатах.

Можно выделить четыре основных класса ЭС: классифицирующие, доопределяющие, трансформирующие и мультиагентные.

1) Классифицирующие ЭС решают задачи распознавания ситуа­ций. Основным методом формирования решений в таких систе­мах является дедуктивный логический вывод.

2) Доопределяющие ЭС используются для решения задач с не полностью определенными данными и знаниями. В таких ЭС возникают задачи интерпретации нечетких знаний и выбора аль­тернативных направлений поиска в пространстве возможных ре­шений. В качестве методов обработки неопределенных знаний могут использоваться байесовский вероятностный подход, коэффициенты уверенности, нечеткая логика.

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

• генерация и проверка гипотез;
• логика предположений и умолчаний (когда по неполным данным формируются представления об объектах определенного класса, которые впоследствии адаптируются к конкретным усло­виям изменяющихся ситуаций);
• использование метазнаний (более общих закономерностей) для устранения неопределенностей в ситуациях.

1) Мулътиагентные системы – это динамические ЭС, основан­ные на интеграции нескольких разнородных источников знаний. Эти источники обмениваются между собой получаемыми резуль­татами в ходе решения задач. Системы данного класса имеют следующие возможности:

 реализация альтернативных рассуждений на основе исполь­зования различных источников знаний и механизма устранения противоречий;

 распределенное решение проблем, декомпозируемых на па­раллельно решаемые подзадачи с самостоятельными источника­ми знаний;

 применение различных стратегий вывода заключений в за­висимости от типа решаемой проблемы;

 обработка больших массивов информации из баз данных;

 использование математических моделей и внешних процедур для имитации развития ситуаций.

2) Синтезирующие. В системах решение синтезируется из отдельных фрагментов знаний.

5. По видам используемых данных и знаний различают ЭС с детерминированными и неопределенными знаниями. Под неопределенностью знаний и данных понимаются их неполнота, ненадежность, нечеткость.

Большинство ЭС включают знания, по содержанию которых их можно отнести одновременно к нескольким типам. Например, обучающая система может также обладать знаниями, позволяющими выполнять диагностику и планирование. Она определяет способности обучаемого по основным направлениям курса, а затем с учетом полученных данных составляет учебный план. Управляющая система может применяться для целей контроля, диагностики, прогнозирования и планирования. Система, обеспечивающая сохранность жилища, может следить за окружающей обстановкой, распознавать происходящие события (например, открылось окно), выдавать прогноз (вор-взломщик намеревается проникнуть в дом) и составлять план действий (вызвать полицию).

Структура экспертной системы

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

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

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

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

 прием и отображение информации с использованием устройств ввода и вывода инструментальной ЭВМ;

 поддержка удобной для пользователя формы диалога (с использованием естественного языка);

 обработка исключительных ситуаций непонимания между пользователем и ЭС (включая элементы обучения системы).

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

Первый элемент ЭС – база знаний – зависит от конкретной области приложения. Механизм логического вывода и системы пользовательского интерфейса, в общем случае, не зависят от области приложения. Поэтому их принято объединять в понятие универсальной оболочки ЭС.

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

1. Данные и знания надежны и не меняются со временем;

2. Пространство возможных решений относительно невелико;

3. В процессе решения задачи должны использоваться формальные рассуждения;

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

4. Должен быть по крайней мере один эксперт, который способен явно сформулировать свои знания и объяснить свои методы применения этих знаний для решения задач.

В целом ЭС не рекомендуется применять для решения следующих типов задач:

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

Перечень типовых задач, для решения которых предназначены ЭС, включает:

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

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

  3.1. Этапы разработки экспертных систем

  В коллектив разработчиков ЭС входят как минимум четыре человека: эксперт, инженер по знаниям, программист и пользователь.

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

  Процесс разработки ЭС можно разделить на следующие этапы:

  1. Выбор проблемы.

  2. Разработка прототипа ЭС.

  3. Доработка до промышленной ЭС.

  1) Выбор подходящей проблемы.

   определяется проблемная область;

   подбирается коллектив разработчиков;

   определяется предварительный подход к решению проблемы;

   готовится подробный план разработки.

  2) Разработка прототипа ЭС.

  Прототипная система является сокращенной версией ЭС, спроектированной для проверки правильности представления фактов, связей и стратегий рассуждения эксперта. Объем прототипа – несколько десятков правил, фреймов или примеров. Разработка прототипа ЭС делится на шесть стадий: идентификация проблемы, извлечение знаний, концептуализация (структурирование) знаний, формализация, реализацияпрототипа, тестирование.

  a) Идентификация проблемы – знакомство и обучение членов коллектива разработчиков, а также создание неформальной формулировки проблемы. На этом этапе уточняется задача, планируется ход разработки прототипа ЭС, определяются:

   ресурсы (время, люди и т.д.);

   источники знаний (книги, дополнительные эксперты);

   имеющиеся аналогичные ЭС;

   классы решаемых задач и т.д.

  b) Извлечение знаний – получение инженером по знаниям наиболее полного из возможных представлений о предметной области и способах принятия решения в ней. Для извлечения знаний инженер использует различные методы: анализ текстов, диалоги, лекции, дискуссии, интервью, наблюдение и др.

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

  d) Формализация знаний – это разработка базы знаний на языке представления знаний. На этом этапе используются: логические методы, продукционные модели, семантические модели, фреймы, объектно-ориентированные языки.

  e) Реализация прототипа –разработка программного комплекса, демонстрирующего жизнеспособность подхода в целом. На этом этапе создается прототип ЭС (включающий базу знаний, остальные программные модули) при помощи: языков программирования (традиционных, специализированных), инструментальных средств разработки ЭС, «пустых» оболочек ЭС.

  f) Тестирование –процесс выявления ошибок в подходе и реализации прототипа. Прототип проверяется на: удобство и адекватность интерфейса ввода/вывода, качество проверочных примеров, полнота и непротиворечивость правил в базе знаний.

  3) Развитие прототипа до промышленной ЭС.

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

  4) Оценка системы.

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

   критерии пользователя (понятность работы системы, удобство интерфейсов и т.д.);

   критерии приглашенных экспертов (оценка советов-решений, предлагаемые системой, оценка подсистемы объяснений и т.д.);

   критерии коллектива разработчиков (эффективность реализации, производительность, непротиворечивость базы знаний, количество тупиковых ситуаций и т.д.).

  5) Этап стыковки системы.

  Осуществляется соединение ЭС с другими программными средствами в среде, в которой она будет работать, и обучение людей, которых она будет обслуживать. Для подтверждения полезности системы важно предоставить каждому из пользователей возможность поставить перед ЭС реальные задачи и проследить, как она их выполняет. Стыковка включает обеспечение связи ЭС с существующими базами данных и другими системами на предприятии.

  6) Поддержка системы.

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

  ГЛАВАII. ПРОЕКТИРОВАНИЕ И РЕАЛИЗАЦИЯ ЭКСПЕРТНОЙ СИСТЕМЫ «ОПРЕДЕЛЕНИЕ НЕИСПРАВНОСТИ ПРИ ЗАПУСКЕ КОМПЬЮТЕРА»

  2.1. Реализация этапов разработки экспертной системы

  Разработка ЭС разбита на три этапа: выбор метода реализации ЭС, непосредственно кодирование программы и тестирование системы.

  1. Выбор метода реализации экспертной системы

  На сегодняшний день существует две основные возможности для реализации ЭС. Это связано с наличием двух весьма различных подходов к решению задачи.

  1) основывается на использовании для построения ЭС некоторого процедурного языка, со всеми его недостатками и достоинствами для решения данной задачи;

  2) использование языков программирования математической логики, языков в которых имеются имеющие огромное значение для построения ЭС возможности.

  Для ЭС лучшим решением является использование некоторого логического языка. Если сравнить код, реализующий одну и ту же ЭС (механизм вывода), то у процедурного языка он будет гораздо более объемным и более сложным. А наличие таких механизмов в языке как сопоставление образцов (унификации), древовидное представление структур, автоматический возврат делают его просто незаменимым языком для программирования ЭС. Общепринятое представление ЭС в виде базы знаний и механизма вывода не полностью пригодно для ЭС, написанных на Прологе. Многие функции механизма вывода обеспечиваются самим Прологом. Базы знаний, образованные средствами Пролога, являются выполняемыми. Однако Пролог не обеспечивает некоторых важных свойств ЭС, обычно встроенных в механизм вывода. Примеры таких свойств порождение объяснений и рассуждения в условиях неопределенности. Исходя из этого, средой для реализации основной части ЭС был выбран язык Пролог, в качестве одного из лучших представителей языков логического программирования.

  2. Построение экспертной системы: описание логической части программы

  Программа представляет собой интерактивную оболочку, которая может задавать пользователю вопросы. Когда программа задает вопрос, пользователь может ответить «Да» или «Нет».

  Возможность задания вопроса «Почему» реализуется в программе с помощью списка, в котором записывается весь путь, по которому прошла программа для вывода цели к текущему моменту времени. По запросу пользователя из списка извлекается его голова и выдается на экран, это и есть то нужное правило.

  Кроме ответа на вопрос «Почему» программа имеет возможность отвечать на вопрос «Как», после вывода сделанного ЭС пользователь может проследить весь процесс вывода.

  База знаний представлена в виде логических правил, поясняющих ход размышлений ЭС при ответах пользователя.

  • если отсутствует реакция на нажатие кнопки включения
  • если кабель питания подключен правильно

  то проверить надежность соединения коннекторов на материнской плате и питающие ее провода

  • если отсутствует реакция на нажатие кнопки включения
  • если все кабели питания подключены правильно
  • если провода и коннекторы внутри корпуса ПК исправны
  • если при отсоединении кнопки перезагрузки от материнской платы компьютер начинает работать

  то неисправна кнопка перезагрузки

  • если отсутствует реакция на нажатие кнопки включения
  • если все кабели питания подключены правильно
  • если провода и коннекторы внутри корпуса ПК исправны
  • если при замыкании двух контактов с надписью «Power Switch» происходит запуск компьютера

  то неисправна кнопка запуска

  • если отсутствует реакция на нажатие кнопки включения
  • если все кабели питания подключены правильно
  • если включенный в сеть блок питания не начинает работать при замыкании черного и зеленого контактов

  то неисправен блок питания

  • если при нажатии кнопки запуска компьютер начинает работать
  • если компьютер сразу прекращает работу

  то неисправно какое-либо устройство и срабатывает защита блока питания

  • если при нажатии кнопки запуска компьютер начинает работу
  • если в процессе загрузки компьютер подает характерный сигнал

  то неисправно оборудование согласно соответствующему значению сигнала

  • если при нажатии кнопки запуска компьютер начинает работу
  • если на экране монитора не отображаются никакие данные
  • если не звучит ни один из сигналов
  • если при нажатии кнопки запуска компьютер начинает работу
  • если на экране монитора не отображаются никакие данные
  • если не звучит ни один из сигналов
  • если после перезагрузки BIOS и проверки батарейки не происходит загрузка

  то неисправна материнская плата

  • если при нажатии кнопки запуска компьютер начинает работу
  • если не звучит ни один из сигналов
  • если на экране монитора появляется «Please enter Setup to recover BIOS setting | CMOS Date/Time Not Set »

  то проблема в настройках BIOS.

  • если при нажатии кнопки запуска компьютер начинает работу
  • если не звучит ни один из предупреждающих сигналов
  • если при загрузке на мониторе появляется сообщение о том, что BIOS не может найти загрузочный носитель
  • если в BIOS не отображается HDD

  то неисправен жесткий диск

  • если при нажатии кнопки запуска компьютер начинает работу
  • если не звучит ни один из сигналов
  • если при загрузке на мониторе появляется сообщение о том, что BIOS не может найти загрузочный носитель
  • если в BIOS отображается HDD
  • если жесткий диск работает при подключении к другому компьютеру как slave

  то поврежден загрузочный сектор

  • если при нажатии кнопки запуска компьютер начинает работу
  • если не звучит ни один из предупреждающих сигналов
  • если при загрузке на мониторе появляется логотип ОС, но загрузка не происходит

  то проблема в программном обеспечении.

  2.2. Проектирование интерфейса пользователя для экспертной системы

  Экспертная система «Определение неисправности при запуске компьютера»

  database

  predicates

  ask( symbol, symbol)

  goal

  clauses

  makewindow(l,7,7, «Экспертная система», 1,3,22,71),

  nl,write («Определение неисправности при запуске компьютера»),

  nl,write (» «), nl,write(«Пожалуйста, отвечайте на вопросы ‘yes’ или ‘no’.»),

  write (» Для продолжения нажмите любую клавишу»),nl,

  readchar (_),removewindow, exit.

  do_consulting:- pk_is(X). nl, write(X,“.”),nl,

  do_consulting:- nl, write(» Извините мы не можем определить неисправность Вашего ПК!»),

  ask(X,Y):- write(» expert «,X,» «,Y,» ?»),

  readln (Reply), remember(X,Y,Reply).

  positive (X,Y):- xpositive(X,Y).

  positive (X,Y):- not(negative(X,Y)). ask(X,Y).

  remember(X,Y,no):- asserta(xnegative(X,Y)), fail.

  clear_facts:- retract(xpositive(_,_)), fail.

  clear_facts:- retract(xnegative (_,_)), fail.

  pk_is(«Неисправна кнопка перезагрузки «):-

  рositive (» если отсутствует реакция на нажатие кнопки включения «),

  рositive (» если все кабели питания подключены правильно»),

  рositive (» если провода и коннекторы внутри корпуса ПК исправны»),

  рositive (» если при отсоединении кнопки перезагрузки от материнской платы компьютер начинает работать»).

  pk _is(«Неисправен жесткий диск «):-

  рositive (» если при нажатии кнопки запуска компьютер начинает работу «),

  рositive («если не звучит ни один из предупреждающих сигналов «),

  рositive («если при загрузке на мониторе появляется сообщение о том, что BIOS не может найти загрузочный носитель «),

  рositive («если в BIOS не отображается HDD «).

  ЗАКЛЮЧЕНИЕ

  В ходе выполнения данного исследования были достигнуты поставленные цель и задачи.

  Результатом выполнения данной работы стало создание экспертной системы «Определение неисправности при запуске компьютера», позволяющей по наличию ряда признаков определять неисправность прсонального компьютера.

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

  В процессе выполнения данной работы были изучены среда разработки ЭС – Prolog, а так же общие принципы построения баз знаний.

  Экспертные системы — один из немногих видов систем искусственного интеллекта, которые получили широкое распространение, и нашли практическое применение. В настоящее время уже существуют экспертные системы по военному делу, геологии, информатике, космической технике, математике, медицине, метеорологии, управлению, юриспруденции, и продолжается их дальнейшее изучение для решения задач в этих и других областях. Развитие этого направления является перспективным, потому что хорошая экспертная система в решении какой-либо проблемы может заменить специалиста.

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

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

  БИБЛИОГРАФИЧЕСКИЙ СПИСОК

  1. Андрейчиков А.В., Андрейчикова О.Н. «Интеллектуальные информационные системы»: М. Наука, 2004 г.
  2. Артамонов Б. Н., Брикалов Г. И., Гофман В. Э., Кадигроб Я. Е., Компаниец Р. И., Липецких А. Г., Мальцев М. Г., Рыжков Ю. И., Хоменко А. Д., Цыганов В. М. «Основы современных компьютерных технологий»: Учеб. пособие /; Под ред. проф. Хомоненко А.Д. – СПб.: КОРОНА принт, 1998. – 448 с.
  3. Братко И. «Программирование на языке Пролог для искусственного интеллекта». / Пер. с англ. – М.: Мир, 1990. – с. 560
  4. Братко И. «Алгоритмы искусственного интеллекта на языке PROLOG». — М.: Издательство «Вильямс», 2004.
  5. Гаврилова Т.А., Хорошевский В.Ф. «Базы знаний интеллектуальных систем». СПб: Питер, 2003г.
  6. Долин Г. «Что такое ЭС?». – Компьютер Пресс, 2002 г
  7. Егоров Н. В., Карпов А. Г. «Диагностические информационно-экспертные системы». – М.: Вильямс, 2002 .
  8. Зубов В. В., Макушкин В. А. «Экспертная система диагностирования цифровых устройств ДИЭКС на персональной ЭВМ. Экспертные системы на персональных компьютерах». М.: МДНТП, 2005, с. 115-120.
  9. Зубов В. В., Макушкин В. А., Оглоблин А. Г. «Экспертная система диагностирования цифровых устройств и БИС». Средства связи. — №3. – 2000. — С. 32-36.
  10. Круглов В. В. «Интеллектуальные информационные системы». – СПб: Питер. — 2002. – 234 с.
  11. Макушкин В. А., Щербицкий К. А. Экспертная система для контроля и диагностирования цифроаналоговых устройств. Новые информационные технологии в планировании, управлении и в производстве. М.: МДНТП. – 2001. — С. 121-125.
  12. Могилев А. В. и др. «Информатика»: Учеб. пособие для студ. пед. вузов/ Могилев А. В., Пак Н. И., Хеннер Е. К.; Под. ред. Хеннера Е. К. – 2-е изд., стер. – М.: Изд. центр «Академия», 2001. – С. 816
  13. Моисеев В.Б. Представление знаний в интеллектуальных системах. Информатика и образование,. №8, 2009. — С. 123
  14. Муромцев Д.И. «Введение в технологию экспертных систем». СПб: СПб ГУ ИТМО, 2005.
  15. Павлов И.О., Кулакова С.В. Основы программирования на языке Турбо-пролог: Методические указания к практическим занятиям по курсу «Представление знаний в информационных системах» / Воронеж. гос. технол. акад.; – Воронеж, 2001. – с. 450, с.32
  16. Попов Э.В. «Экспертные системы: Решение неформализованных задач в диалоге с ЭВМ». — М.: Наука. Гл. ред. физ.-мат. Лит., 1987 г.
  17. Попов Э. В., Фоминых И. Б., Кисель Е. Б., Шапт М. Д. «Статические и динамические экспертные системы». М.: Финансы и статистика, 2003 г.
  18. Рыбина Г. В., Пышагин С. В., Смирнов В. В., Левин Д. Е., Душкин Р. В. «Инструментальный комплекс АТ-ТЕХНОЛОГИЯ для поддержки разработки интегрированных экспертных систем». Учебное пособие, М.: МИФИ, 2001, с. 100
  19. Рыжиков Ю. И. «Информатика. Лекции и практикум». – СПб.: КОРОНА принт, 2000. – с. 256, с. 126-129
  20. Сафонов В.О. «Экспертные системы – интеллектуальные помощники специалистов». – СПб.: Санкт-Петербургская организация общества «Знания Росси», 2007.
  21. Соломин Д. «Использование Турбо-Пролога». / Ц. Ин.; Пер. с англ. – М.: Мир, 1993. – с. 608
  22. Стефанюк В.Л. «Экспертные системы и их применение»: Курс лекций.
  23. Уткин В. Г. «Информационные системы в экономике»: учеб. Для студ. высш. учеб. заведений. / Уткин В. Г., Балдин К. В.- 5-е изд. Стер. – М.: Изд. Центр «Академия», 2010. – с. 288, с. 255
  24. Убейко Н. «Экспертные системы». – М.: МАИ, 2002.
  25. Частиков А. П., Гаврилова Т. А., Белов Д. Л. «Разработка экспертных систем. Среда CLIPS BHV». — СПб, 2003 г., с. 606
  26. Джарратано Джозеф, Райли Гари «Экспертные системы: принципы разработки и программирование»: Пер. с англ. – М. : Издательский дом «Вильямс», 2006. – с. 1152
  27. Люгер Д. «Искусственный интеллект». – М.: Мир, 2006. с. 690
  28. Марселлус Д. «Программирование экспертных систем на Турбо Прологе». Пер. с англ. — М.: Финансы и статистика, 1994 г.
  29. Малпасс Д. Р. «Реляционный язык Пролог и его применение».
  30. Нейлор К. «Как построить свою экспертную систему».- М.: Энегроатомиздат, 2007.
  31. Питер Джексон «Введение в экспертные системы» = Introduction to Expert Systems. – 3-е изд. – М.: Вильямс, 2001. — с. 624.
  32. Стерлинг Л., Шапиро Э. «Искусство программирования на языке Пролог». / Пер. с англ. – М.: Мир, 1990. – с. 225
  33. Таунсенд К., Фохт Д. «Проектирование и программная реализация экспертных систем на персональных ЭВМ»: Пер. с англ. В. А. Кондратенко, С. В. Трубицына. – М.: Финансы и статистика, 1990. — с. 320
  34. Уотермен Д. «Руководство по экспертным системам»: Пер. с англ. под ред. В. Л. Стефанюка. — М.: «Мир», 1989: — с. 388
  35. Элти Д., Кумбс М. «Экспертные системы: концепции и примеры».- М.: Финансы и статистика, 1987.
  36. http://ru.wikipedia.org – Экспертная система
  37. http://www.swi-prolog.org/ — официальный сайт SWI-Prolog.
  38. http://www.expertsys.ru — материалы сайта «Все об экспертных системах»
  39. http://www.intuit.ru
  40. http://www.ai.tsi.lv
  41. http://knpi-iip.mipk.kharkiv.edu
  42. http://www.libray.narod.ru
  43. http://expro.kzn.ru
  44. http://256bit.ru/expert/glava
  45. http://tver.mesi.ru
  46. http://www.ssti.ru

  Применение экспертных систем для анализа и оценки информационной безопасности

  Козулин, С. В. Применение экспертных систем для анализа и оценки информационной безопасности / С. В. Козулин. — Текст : непосредственный // Молодой ученый. — 2017. — № 11 (145). — С. 40-43. — URL: https://moluch.ru/archive/145/40750/ (дата обращения: 30.10.2023).

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

  Ключевые слова: экспертная система, информационная безопасность, база знаний, интерфейс, диалог, алгоритм

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

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

  Успех обеспечения ИБ — заключается в комплексном подходе. Необходимо отметить, что ни одна система или организация не может считаться абсолютно защищенной, так как имеют достаточно много уязвимых мест. Понятие комплексности заключается не просто в создании соответствующих механизмов защиты, а представляет собой регулярный процесс, осуществляемый на всех этапах. При этом все средства, методы и мероприятия, используемые для защиты информации, объединяются в единый целостный механизм — систему защиты. От части решение задач обеспечения информационной безопасности организации может быть получено на базе использования экспертных систем, как части системы защиты информации.

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

  Экспертная система должна уметь взять на себя те функции, которые выполняет специалист-эксперт или выполнить роль ассистента (советчика) для лица, принимающего решения. Использование экспертных систем позволит управляющей информационной системе получать решение непосредственно от программы и полностью исключить необходимость использования человека в управляющей системе. С другой стороны, экспертная система может повысить эффективность работы человека, предлагая наиболее верное решение поставленной задачи [2].

  Процесс построения экспертной системы можно разделить на 6 относительно независимых этапов:

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

  − определение проблемной области и круга решаемых задач;

  − определение эксперта, с которым будет сотрудничать разработчик;

  − предварительное определение подходов к решению задачи;

  − анализ экономической эффективности разработки;

  − подготовка плана разработки.

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

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

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

  − критерии пользователей (понятность и «прозрачность» работы системы, удобство интерфейсов и др.);

  − критерии приглашенных экспертов (оценка советов-решений, предлагаемых системой, сравнение ее с собственными решениями, оценка подсистемы объяснений и др.);

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

  5) Стыковка системы. Выполняется интеграция экспертной системы с другими информационными системами в среде, в которой она будет работать, и обучение персонала. Также обеспечивается связь экспертной системы с базами данных, существующими на предприятии.

  6) Поддержка системы. Данный этап подразумевает постоянное обновление базы знаний, добавление новых правил и логических конструкций [3].

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

  

  Рис. 1. Функции экспертной системы

  Состав функциональных подсистем экспертной системы информационной безопасности соответствует определенным для нее функциям. В ЭС ИБ должны присутствовать подсистемы:

  − получения знаний позволяющая эксперту внести в базу знаний необходимые знания в удобном для него виде (выполнить обучение системы);

  − представления знаний (позволяющая создать новые хранилища знаний, организовать новое обучение системы, ввести необходимые данные для последующей обработки знаний);

  − получения ответа с объяснением решения (В результате запроса или по итогам ответов на вопросы системы пользователь должен получить ответ на поставленный вопрос).

  Для описания взаимодействия пользователей с подсистемами ЭС можно построить диаграмму вариантов использования UML (рис. 2).

  

  Рис. 2. Диаграмма вариантов использования ЭС

  С разрабатываемой системой могут работать три группы пользователей:

  1. Эксперты — занимаются вводом знаний в экспертную систему, могут участвовать в проверке знаний ЭС;
  2. Администраторы — занимаются обеспечением представления знаний в требуемых форматах, обеспечением предоставления новых хранилищ для знаний;
  3. Пользователи — получают ответы (решения) от экспертной системы.

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

  1. П. В. Плетнев, В. М. Белов. Методика оценки рисков информационной безопасности. Доклады ТУСУРа, № 1 (25), часть 2, июнь 2012. [Электронный ресурс] cyberleninka.ru/
  2. Культин Н., Delphi в задачах и примерах, Спб: БХВ-Петербург, 2012.
  3. Мельников В. П. Защита информации / Под ред. Мельникова В. П. (1-е изд.) учебник, М: Академия, 2014.
  4. Казиев В. М., Введение в анализ, синтез и моделирование систем. Учебное пособие, Интернет-Университет Информационных Технологий, 2014.
  5. Головчинер М. Н. Интеллектуальные информационные системы, Курс лекций. — Томск: ТГУ, 2015. — 97 с.

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

  Глава 2. Математическое описание экспертной системы

  Экспертная система (статическая) – вычислительная система, использующая знания эксперта и процедуры логического вывода и позволяющая дать объяснения полученным результатам. Синонимом ЭС является термин «система, базирующаяся на знаниях». Знания – совокупность данных и связывающих их правил. На начальных этапах развития рассматривались статические ЭС. В таких системах время на прямую не фигурировало. Изначально предполагалось, что схема ЭС будет иметь вид, показанный на рис. 1.1. Однако выяснилось, особенно после появления оболочки экспертной системы GURU, что построение «переводчика» с естественного языка на язык компьютера является сложной, вполне самостоятельной проблемой. Появление декларативных логических языков типа ПРОЛОГ (Prolog), а затем – языков, использующих ПРОЛОГ-идеи, позволило упростить задачу «перевода» при условии использования текстовых элементов из заранее составленного естественного языка. При этом структура интеллектуальной системы трансформировалась – исчезли блоки лингвистических и лексических процессоров. Первые ЭС были разомкнутыми и использовались чаще всего в диагностике. Сюда следует отнести такие медицинские системы, как MYCIN и EMYCIN. Их характеристиками являются простота общения с ПК, возможность наращивания модулей, интеграция неоднородных данных, решение многокритериальных задач с учетом предпочтений ЛПР, документальность, конфиденциальность, унификация формы знаний, независимость механизма логического вывода, возможность представления объяснений, возможность символьного описания процессов. Такие ЭС могут быть использованы как элементы управляющей части системы управления. Место таких систем в цикле управления показано на рис. 2.2. Статистическая ЭС без блока «база правил» называется оболочкой ЭС (аналог СУБД). Наиболее известная оболочка GURU. В рамках языка ПРОЛОГ также имеется оболочка ЭС. Очень скоро выяснилось, что эти системы имеют ограниченную сферу применения. В частности системы управления имеют, как правило, замкнутую структуру. Статические ЭС не позволяют: 1) учесть, сохранить и провести анализ изменяющихся во времени данных, поступающих от внешних источников; 2) работать с асинхронными процессами; 3) обеспечить механизм рассуждений при ограниченных ресурсах; 4) обеспечить прогноз последствий принимаемых решений-советов; 5) обеспечить создание и поддержку интерфейсов пользователей, уровень их защиты для различных категорий пользователей. Реализация ЭС в области управления называется интеллектуальной системой управления или ЭС реального времени (ЭСРВ). Следует отметить, что первоначально ЭСРВ работала с моделью объекта управления (рис. 1.1). В настоящее время в ЭСРВ включают реальный объект управления, информация о состоянии которого поставляется системой датчиков и отражается на табло. Время в ЭСРВ присутствует напрямую (рис. 2.3) Их место в цикле управления показано на рис. 2.2. Фирма Gensym в 1988 году выпустила очень удачный программный продукт под названием G2, получивший в настоящее время очень широкое распространение. С помощью ЭСРВ создаются эффективные управления непрерывными производствами и процессами в химии, фармакологии, производстве цемента, продуктов питания, в авиакосмических исследованиях, в транспортировке и переработке нефти и газа, в управлении тепловыми и атомными станциями,, в системах связи, в финансовых операциях. Создание даже статических ЭС достаточно дорого: 0,1 – 0,2 млн долларов при трудоемкости от 0,5 до 10 человеко-лет при количестве учитываемых параметров свыше тысячи. В то же время использование ЭС и ЭСРВ в настоящее время приносит значительный экономический эффект [12]. Фирма American Express сократила на 27 млн долларов свои потери при применении экспертной системы, принимающей решения-советы по кредитованию. Фирма Dec ежегодно экономит 70 млн долларов, используя экспертную систему для составления конфигурации вычислительной системы по заказу покупателя. При этом количество ошибок сократилось в 30 раз. Фирма Sira сократила затраты на строительство трубопровода в Австралии на 40 млн долларов, применив управление трубопроводом с помощью экспертной системы, реализованной с помощью оболочки G2. В последнее время наиболее значительная доля промышленных ЭС относится к ЭСРВ (например: G2). Если в 1988 году доход от продажи ЭС составлял 3 млн долларов, то в 1993 году уже 55 млн долларов. Причинами послужили специализация программных средств, увеличивающая эффективность их использования и сокращающая сроки разработки приложений; использование традиционных языков программирования, т.е. ПРОЛОГ-идей, что снизило требования к программным приложениям; возможность интегрирования ЭС с другими информационными технологиями; открытость и переносимость разработок путем использования стандартов; применение архитектуры клиент-сервер. В теории экспертных систем возможно выделить составляющие, показанные на рис. 2.4. 2.2. Составляющие теории экспертных систем Создание ЭС предполагает рассмотрение процесса проектирования. Рассмотрим его для ЭСРВ, поскольку этот процесс для статических ЭС значительно проще. ЭСРВ, как отмечалось, суть разновидность автоматизированной системы управления — АСУ. В то же время ЭСРВ специфична за счет более сложной структуры и потому для нее более подходит другая градация процесса проектирования [12]. I. Идентификация. II. Концептуализация. III. Формализация. IY. Выполнение (реализация). Y. Отладка и тестирование. YI. Опытная эксплуатация. Рассмотрим перечисленные этапы более подробно. I. Идентификация. Цель этапа – определение цели проектирования – построение базы знаний (БЗ). На данном этапе можно выделить такие работы. А. Формирование целей проектирования. Б. Формирование коллектива разработчиков. В. Определение ресурсов для разработки. Г. Идентификация проблемы. А. Следует отличать цель построения БЗ от целей, решаемых спроектированной системой при ее работе. Цель работы спроектированной системы – выработка решений-советов, анализ и учет последствий принимаемых решений. Целями проектирования могут быть формализация трудноформализуемых задач, неформальных знаний эксперта, улучшение качества решений экспертов, автоматизация интеллектуальных аспектов работы руководителя. Далее сосредоточимся на последней цели, в которой фактически сочетаются две первые цели. Среди руководителей выделим конечного пользователя (КП) – руководителя, который будет использовать создаваемую систему. Б. На этом этапе участвует несколько экспертов (руководителей, конечных пользователей) в роли учителей и инженер по знаниям – в качестве ученика, осваивающего словесную модель. В. Следует учитывать ограничения в процессе проектирования, к которым относятся: а) размеры финансирования работ; б) сроки выполнения проекта (предварительные результаты – через три месяца, первые уточненные результаты – через шесть месяцев); в) источники знаний; г) вычислительные средства. Г. Собственно идентификация предполагает получение ответов на следующие вопросы. 1. Какой класс задач решает система. 2. Как эти задачи могут быть определены. 3. Каковы основные понятия в предметной области. 4. Каковы трудности в решении выделенного класса задач. В самой процедуре идентификации выделяют процессы извлечения знаний эксперта (в беседе с инженером по знаниям), выявление знаний инженером по знаниям из книг и документов, приобретение знаний (трансформация вербальной модели знаний в формальную). Возможны следующие подходы к извлечению знаний: 1) долговременная работа с экспертами; 2) оперативное создание прототипа системы путем получения инженером по знаниям первоначальных знаний и предварительной структуризации процедуры извлечения; 3) анализ начальных и полученных знаний. В качестве методов извлечения можно использовать: 1) опрос эксперта по общему вопроснику с наводящими вопросами; 2) структуризованный опрос; 3) самонаблюдение с размышлением эксперта вслух; 4) самоотчет эксперта при выполнении работы; 5) критический обзор извлеченных знаний с целью уменьшения грубых ошибок и формирования метазнаний. Детально процесс извлечения знаний описан в работе [8]. В процессе извлечения знания получаются чаще всего в неформальном словесном виде. Основная задача инженера по знаниям – перейти от словесного описания к формальному с учетом используемого программного инструмента реализации (язык программирования, оболочка ЭС). II. Концептуализация. Цель этапа – получение ключевых понятий и словесной модели, необходимых для последующего формального описания процессов в системе. На этом этапе исходят из понятия “черный ящик”, для которого проводится детализация входов и выходов, выявление алгоритмов, разделение системы на подсистемы, установление информационных связей между подсистемами. Полезно составить словарь используемых терминов. Следует выявить место статической ЭС и аппарат ее описания. Выделяют словесное описание дискретной и непрерывной составляющих. Определяют выходные, входные координаты (данные) и связывающие их алгоритмы. Алгоритмами дискретной составляющей является система правил. Чаще всего для описания знаний дискретной составляющей используется аппарат продукций (системы правил “если …, то …”). Саму систему правил (дискретная составляющая описания управляющей части системы) выявляют в процессе беседы инженера по знаниям с экспертом — конечным пользователем по схеме “Ваше подразделение не выполнило план с начала месяца и за прошедший день – Ваши действия?” Как правило, формулировка ответов будет иметь вид “если недостаточно такого-то ресурса, то действие таково”. Целесообразно составить протокол рассуждений и действий эксперта. Определяется связь системы правил с непрерывной составляющей описания управляющей части системы. Само действие КП может характеризоваться непрерывным описанием или переходом к нему (выход, вход, алгоритм). III. Формализация. Цель этапа – переход от вербального (словесного) описания процессов в системе к их описанию на некотором формальном языке. Формальное представление связано со структуризацией. В общем случае выделяют структуризацию исходной задачи, предметной области, базы правил, приложения. Структуризация исходной задачи подразумевает выявление многоуровневой системы управления, разделение БЗ на функциональные и программные модули и определение правил “сборки” системы из модулей. Структуризация предметной области предполагает формирование иерархии классов понятий с их свойствами (летательный аппарат как исходный класс, самолет – родительский класс). Структуризация базы правил предполагает построение иерархии правил. Структуризация приложений подразумевает иерархию рабочих пространств и программных шаблонов Одновременно оценивается достоверность исходных данных и правил. Для этих целей можно использовать аппарат факторов уверенности или нечетких переменных [17]. Здесь могут решаться следующие проблемы. 1. Выбор алгебры оперирования с нечеткими переменными. 2. Построение модели настройки на конкретного КП и анализ его предпочтений. 3. Сопоставление предпочтениям ЛПР критериев оптимальности. IY. Выполнение (реализация). Цель этапа – создание прототипа БЗ. На нем проверяются основные технические решения, при этом могут не учитываться сложные причинно-временные соотношения, неточность данных. Проводится корректировка правил дополнительные детали в которые “добавляются” разработчиком после отладки и тестирования системы, учета замечаний пользователя. Таким образом, реализация является в общем случае процедурой итеративной. Y. Отладка и тестирование. На этом этапе система реализуется в полном объеме. Тестирование в ЭСРВ понимается в широком смысле, предполагая тестирование: 1) выявленных алгоритмов до их реализации; 2) алгоритмов в форме реализованных на компьютере программ. Первая разновидность тестирования есть тестирование исходных данных (в том числе их достоверности), логическое тестирование (системы продукций с точки зрения избыточных, цикличных или конфликтных пропущенных правил, пропущенных и пересекающихся правил, пересекающихся правил, несогласующихся условий, достоверности алгоритмов), концептуальное тестирование (проверка удовлетворения общих требований, предъявленных к системе). Проводится тестирование отдельных программных модулей и шаблонов, программы в целом, разрабатываются входные сценарии, результаты введения которых в программу известны, для проверки работы системы правил. Для упрощения тестирования отдельных модулей полезна их автономная отладка в виде компонент или шаблонов. Процедура стыковки программ с данными внешних устройств (например датчиками) получила в последнее время название инспекция. Для процедуры инспекции могут разрабатываться специальные программы (поиска местонахождения элементов на основе их типов, принадлежности к классу, атрибутов). Они должны позволять получать характеристики внешних устройств как в автономном режиме, так и при их работе в системе в целом. Для отладки используются специальные средства (сообщение об ошибках работы системы, пошаговое выполнение алгоритма, подсветка возбужденного правила), придаваемые, как правило, базовым программным продуктам. Отладочные средства тесно взаимодействуют со средствами инспекции. YI. Опытная эксплуатация. Разработанная система предъявляется заказчику, который оценивает ее обычно по таким признакам. Пригодность системы как сумма полезности системы и удобства работы с ней. Полезность определяется степенью удовлетворения требований (потребностей) пользователя и прежде всего в сбойных ситуациях. Удобство работы определяется свойствами интерфейсом пользователя, включая гибкость (настройка на различных пользователей или на изменение квалификации одного и тог же пользователя), устойчивость к ошибкам оператора (целостность системы). В ЭСРВ выделяют тренажерное тестирование, пилотное сопровождение и опытную эксплуатацию. В тренажерном (модельном) тестировании предъявляются более жесткие требования, чем в практической эксплуатации, к надежности системы в условиях более частой поломки оборудования, “зашумления” первичных данных датчиков, отказов, в том числе компьютера и периферийных средств. В пилотном сопровождении предполагается два варианта. 1. Подключение к системе входов реальных систем без замыкания обратных связей. 2. Поэтапное замыкание обратных связей. Система постепенно переводится от работы с моделью внешней среды к работе с самой средой. После завершения пилотного сопровождения, в процессе которого выявляются неполадки и пожелания пользователя, замечания устраняются и начинается эксплуатация системы в полном объеме. Использование ЭС. Использование (рис. 2.4) предполагает; введение запроса; получение ответа системы; получение объяснения. Формы запроса определяются интерфейсом пользователя (команды, системы команд, меню, естественный язык). Форма ответа определяется алгоритмом, сформированным для работы ЭС и заложенным в процессе ее проектирования. Объяснения могут иметь различную форму: КАК получено решение (на основе какаой системы правил), КАК звучит правило с определенным номером, в КАКИХ правилах используется тот или иной параметр, ПОЧЕМУ компьютер запрашивает данные для уточнения запроса. Более подробно процесс объяснения описан при рассмотрении языка ПРОЛОГ и оболочки GURU. Нетрудно видеть, что процессы вывода и объяснения определяются соответствующей теорией, использованной для процесса работы ЭС. Работа ЭС. В выводе результатов и объяснений основную роль играют блоки БД, база правил, МЛВ. В общем случае Работа этих блоков в части вывода результатов Y может быть представлена в виде Y = , (2.1) где X – множество базовых элементов (данных, называемы в теории экспертных систем и фактами); P – правила с условиями их применения; B – множество аксиом построения синтаксически правильных совокупностей; R – множество правил вывода. Результат Y в теории экспертных систем называют целью. Совокупность образует аппарат описания знаний в блоках БД и базе правил, совокупность — закономерности вывода в блоке МЛВ. Сочетание элементов X и P имеют свою специфику, поскольку базы данных имеют свою структуру. Это сочетание более подробно рассмотрено позднее при обсуждении многоагентных систем (МАС). Пока предполагаем, что данные имеют простейший бесструктурный вид и сочетание A и P выполнимо. Сложнее обстоит дело с сочетанием и , поскольку методы описания знаний и логического вывода первоначально развивались автономно. В связи с этим одной из задач экспертных систем является определение такого набора методов описания блоков, которые математически интегрировались бы в общую систему. К такому интегральному описанию предъявляются следующие требования: 1) наглядность описания; 2) простота математического описания; 3) однозначность описания; 4) эффективность методов; 5) возможность интеграции методов; 6) возможность формирования объяснений; 7) описание соотношений множества и подмножеств. Объяснение O в общем виде может быть описано O = i, i = 1, N>, (2.2) где P_i — правила, участвовавшие при выводе данного результата. Они (рис. 2.5) запоминаются в процессе вывода (путь вывода помечен жирными линиями). В рамках теории ЭС должны быть решены проблемы.

  29.08.2019 47.55 Кб 5 Глава1.docx

  31.08.2019 63.03 Кб 2 Глава1.docx

  03.09.2019 91.41 Кб 4 глава1.docx

  14.11.2019 54.39 Mб 5 Глава2.doc

  14.11.2019 5.73 Mб 3 Глава6.doc

  10.11.2019 95.74 Кб 6 Глава_2-ИИС.doc

  10.11.2019 154.11 Кб 2 Глава_3-ИИС.doc

  10.11.2019 95.23 Кб 4 Глава_4-ИИС.doc

  24.08.2019 593.41 Кб 0 Главы 7-8. Часть 2 (18 — начало 19вв.).rtf

  22.08.2019 73.22 Кб 0 Главы Истории Национально-Революционной Партии.doc

  19.07.2019 34.83 Кб 0 Глагол и его морфологические функции.docx

  Ограничение

  Для продолжения скачивания необходимо пройти капчу:

  Похожие публикации:

  1. Postgresql и postgres в чем разница
  2. Progressive web app что это
  3. Как грепать логи
  4. Как сделать таблицу маркировки