Дисципліна «Методи та системи штучного інтелекту »

Лабораторна робота №5

Дисципліна «Методи та системи штучного інтелекту»

Тема: «дослідження етапів розробки експертних систем»

Мета роботи – отримати практичні навички розробки експертних систем.

 

Завдання

 

1. Обрати предметну область для побудови експертної системи та узгодити її з викладачем.

2. З'ясувати мету та задачі експертної системи (На які питання повинна відповідати експертна система і що це практично дасть користувачеві).

3. Визначити об’єкти предметної області і зв’язки між ними.

4. Визначити задачі експертної системи.

5. Визначити вхідні дані і діапазон їхньої зміни.

6. Записати продукційні правила бази знань.

7. Записати запитання експертної системи.

Перелік рекомендованих тем для створення експертних систем.

1. Експертна система з індивідуального підбору косметики.

2. Експертна система з індивідуального підбору одягу.

3. Експертна система з індивідуального підбору взуття.

4. Експертна система з індивідуального підбору мобільного телефону.

5. Експертна система з підбору відеомагнітофону.

6. Експертна система з підбору музичного центру.

7. Експертна система з підбору відеокамери.

8. Експертна система з підбору телевізора.

9. Експертна система з підбору комп'ютера.

10. Експертна система з підбору автомобіля.

11. Експертна система з підбору житла.

12. Експертна система з підбору туристичної путівки.

13. Експертна система з індивідуального підбору спеціальності для абітурієнтів.

14. Експертна система з підбору музичних інструментів.

15. Експертна система з підбору комп’ютерних ігор.

КОНТРОЛЬНІ ПИТАННЯ

 

1. Чим експертні системи відрізняються від звичайних програмних додатків та типових програм штучного інтелекту?

2. Чи може програма, яка не використовує методи штучного інтелекту, мати такі ж властивості як експертна система?

3. У чому різниця між експертною системою та системою, що ґрунтується на знаннях?

4. Чи буде експертною системою програма передбачення погоди у Криму, що виводить повідомлення такого роду: "Завтра погода не буде відрізнятися від сьогоднішньої"?

5. Нехай вона представляє сьогоднішню погоду у символьному вигляді, легко модифікується та здатна до розширення, прекрасно працює та може пояснити, чому вона прийшла до певного висновку.

6. Чи є експертною системою програма, котра формує прогноз погоди на певну дату шляхом усереднення температури повітря, кількості опадів та кількості сонячних годин у цю дату за всі роки, починаючи з 1900?

7. Чи є система пошуку у мережі World Wide Web експертною? Якщо ні, то яких властивостей їй бракує для того, щоб кваліфікувати її як експертну систему пошуку потрібної Web-сторінки?

8. Чому задача набуття знань є вузьким місцем у проектуванні експертних систем? Які рішення пропонуються для виходу з такої ситуації?

9. Чому пакет програм статистичного аналізу неможна вважати програмою штучного інтелекту?

10. Як ви розумієте термін "простір пошуку"?

11. Як ви розумієте термін "простір рішень"?

 

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

 

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

В ходе работ по созданию экспертных систем сложилась определенная технология их разработки, включающая шесть следующих этапов [1]: идентификация, концептуализация, формализация, выполнение, отладка и тестирование, опытная эксплуатация и внедрение. Эти этапы, как правило, выполняются не в линейном порядке, т.е. постоянно осуществляется модификация разрабатываемой ЭС. Можно выделить следующие виды модификации системы: переформулирование понятий и требований, переконструирование представления и усовершенствование прототипа. Усовершенствование прототипа осуществляется в процессе циклического прохождения через этапы выполнения и тестирования с целью отладки правил и процедур вывода. Циклы повторяются до тех пор, пока система не будет вести себя ожидаемым образом. Изменения, осуществляемые при усовершенствовании, зависят от выбранного способа представления и от класса задач, решаемых экспертной системой. Если в процессе усовершенствования желаемое поведение не достигается, то необходимо осуществить более значительные модификации архитектуры системы и БЗ. Возврат от этапа тестирования на этап формализации приводит к пересмотру выбранного ранее способа представления знаний. Данный цикл называют переконструированием. Если возникшие проблемы еще более серьезны, то после неудачи на этапе тестирования может потребоваться возврат на этапы концептуализации и идентификации. В этом случае речь будет идти о переформулировании понятий, используемых в системе, т.е. о проектировании всей системы заново.

Соответствие между методологией разработки ЭС и методологией RAD

Методология быстрой разработки приложений RAD - это промышленная технология разработки программных систем на основе использования CASE-средств и методов быстрого прототипирования и верификации прототипов пользователем при жестком ограничении времени, отведенного на разработку. На уровне организации проектных работ RAD можно охарактеризовать как "автоматизированную групповую разработку приложений (Joint Application Development - JAD) в условиях ограниченных сроков. Технология JAD была разработана фирмой IBM в начале 70-х годов для быстрой разработки спецификаций и требований к программным системам.

Основными рабочими продуктами RAD в порядке их формирования являются бизнес-модель, модель данных и функциональная модель. Бизнес-модель - это графическое и текстуальное описание информационных потоков между элементами автоматизируемой системы, включая элементы, внешние по отношению к системе. Модель данных - графическое и текстуальное описание структуры и семантики информации, используемой в системе. Функциональная модель - графическое и текстуальное описание функций системы, операций, задач, решаемых в ходе выполнения этих функций, и взаимосвязей между функциями в терминах входов и выходов. Все описания формируются в терминах CASE-системы, что дает возможность проводить непосредственно на их основе генерацию результирующего кода прикладной программы.

Ниже приведено соотношение между методологией RAD и методологией ЭС.

Соответствие между этапами проекта RAD и жизненного цикла ЭС

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

 

 

Идентификация

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

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

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

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

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

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

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

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

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

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

 

Концептуализация

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

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

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

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

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

К числу базовых типов диаграмм относятся [2,3]:

• контекстные диаграммы (структурно-функциональные схемы);

• диаграммы "сущность-связь";

• диаграммы потоков данных;

• диаграммы "состояния-переходы".

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

Контекстная диаграмма в сочетании с перечнем системных требований стремится ответить на вопрос "Что делает система?", причем дает только частичный ответ. Для систем со сложными связями между объектами важно более детально представлять взаимоотношения между объектами. Это делается с помощью диаграмм "сущность -связь". В этих диаграммах объекты представляются прямоугольниками, а связи между ними - стрелками, на которых расположены ромбы. В прямоугольниках и ромбах записаны имена объектов и связей. Тип связи и ее направление определяются с помощью стрелок в начале и в конце линии связи. Тип связи задает отношение множественности между объектами, т.е. определяет, скольким экземплярам второго объекта соответствует один экземпляр первого объекта. Диаграммы "сущность - связь" также отвечают на вопрос "Что?"

После того как определено, что должна делать система, необходимо ответить на вопрос "Как?" Первый вопрос заключается в том, как система взаимодействует с внешним окружением. Ответ на этот вопрос дает диаграмма потоков данных (ДПД). На ней представлены внешние объекты, хранилища данных в системе, потоки данных, входящие, выходящие и проходящие внутри системы, и системные процессы, обрабатывающие эти потоки. Объекты принято обозначать квадратами, хранилища данных - узкими прямоугольниками без правой стороны, процессы - прямоугольниками с закругленными углами, а потоки данных - линиями со стрелками. ДПД позволяют проводить декомпозицию по уровням раскрытия системных процессов и потоков. В совокупности они показывают, как система отвечает требованиям и как реализуется проект.

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

 

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

• степень выполнения общих требований в выбираемом ИС; к этим требованиям относятся (см. п. 1.1): интегрированность, открытость и переносимость, использование языков традиционного программирования и рабочих станций, использование архитектуры клиент-сервер, проблемно/ предметная ориентация ИС;

• тип приложения (изолированность/интегрированность, закрытость/открытость, централизованность/децентрализованность) - см. п.3.1;

• тип проблемной среды, включающей как характеристики предметной области (статические/динамические, структурированная/неструктурированная БЗ, вводятся или нет объекты и их классы), так и характеристики решаемых задач (анализ/синтез, частность/ общность выполняемых утверждений) - см. п. 3.1;

• технологию разработки ЭС, которую допускает выбираемое ИС (подход, основанный на поверхностных или глубинных знаниях, на структурировании процесса решения, или смешанный подход), -см. п. 3.1.

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

Выполнение

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

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

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

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

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

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

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

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

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

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

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

Отладка и тестирование

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

Специалисты [4] выделяют три аспекта тестирования экспертных систем: тестирование исходных данных; логическое тестирование базы знаний; концептуальное тестирование прикладной системы.

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

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

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

ЛІТЕРАТУРА

 

1. Статические и динамические экспертные системы: Учеб. пособие/Э.В. Попов, И.Б. Фоминых, Е.Б. Кисель, М.Д. Шапот. - М.: Финансы и статистика, 1996. - 320с.: ил.

2. Дубровин В.И., Субботин С.А., Богуслаев А.В., Яценко В.К. Интеллектуальные средства диагностики и прогнозирования надежности авиадвигателей. - Запорожье: ОАО "Мотор Сич", 2003.-279 с.

3. Рiдкокаша А.А., Голдер К.К. Основи систем штучного інтелекту. - Черкаси: Вiдлуння - плюс, 2002.- 240 с.

4. Васильев В.И. Распознающие системы: справочник. - К.: Наукова думка, 1969.- 292 с.

5. Дюк В., Самойленко А. Data mining: учебный курс.- СПб.: Питер, 2001.- 368 с.

6. Биргер И.А. Техническая диагностика. - М.:Машиностроение,1978.- 240 с.

7. Айвазян С.А., Бухштабер В.М., Енюков И.С., Мешалкин Л.Д. Прикладная статистика. Классификация и снижение размерности - М.: Финансы и статистика.-1989.- 607 с.

8. Братко И. Программирование на языке PROLOG для искусственного интеллекта. - М.: Мир, 1990. - 559 с.

9. Хейес-Рот Ф., Уотерман Д., Ленат Д. Построение экспертных систем. - М.: Мир, 1987. - 430 с.

10. Нильсон Н. Принципы искусственного интеллекта. - М.: Радио и связь, 1985. -376 с.

11. Стерлинг Л., Шапиро Э. Искусство программирования на языке ПРОЛОГ. - М.: Мир, 1990.

12. Уотермен Д. Руководство по экспертным системам. - М.: Мир, 1989.

13. Уинстон П. Искусственный интеллект. - М.: Мир, 1980. - 519 с.

ЛИТЕРАТУРА

1. Попов Э.В. Экспертные системы. Решение неформализованных задач в диалоге с ЭВМ. - М.: Наука, 1987.

2 Гейн К., Сарсонт Т. Структурный системный анализ: средства и методы. В 2-х ч. Ч1/Пер. с англ. под ред. А.В. Козлинского. - М.: Эйтекс, 1993. - 188 с.

3. Modern Software Engineering. - Edited by Peter A.Ng., Raymond T.Ych-VAN NOSTRAND - NY.: 1990.

4. Shekhar H. Kirani, Imran A. Zualkernan, Wei-Tek Tsai. Evaluation of Expert System Testing Methods //Communications of the ACM. - 1994. - November. -V. 37. - №11.

5. Sherry A. Land, Jane T. Malm. Making Intelligent Systems Team Players. A Guide to Developing Intelligent Monitoring Systems // NASA Technical Memorandum 104807. - 1995, July.

 

Лабораторна робота №5

Дисципліна «Методи та системи штучного інтелекту»