дб. Четвертое издание джозеф Джарратано Университет Хьюстон клиэрЛэйк Гари Райли People5oft, Издательский дом "Вильямс" Москва СанктПетербург Киев 2007 ббк 32. 973. 26 018 75 Д
 Скачать 3.73 Mb.
|
6.4. Ошибки, возникающие на различных этапах разработки 527Прежде чем воспользоваться каким-либо инструментальным средством для создания экспертной системы, применяемой в ответственном приложении, необходимо определить, как проводилась аттестация этого инструментального средства. Как правило, каждая новая версия инструментального средства создания экспертных систем должна проходить проверку с помощью тестового набора такая проверка предусмотрена, в частности, для языка CLIPS. Проверка автоматизирована, поэтому позволяет получить объективные результаты, а ее проведение не происходит в спешке, поскольку никто не настаивает на скорейшем выпуске продукта под давлением внешних обстоятельств, чем обычно грешит руководство. Простейшим методом проверки наличия ошибок в инструментальном средстве является классический метод опроса других пользователей, а также поставщиков этого инструментального средства. Любой поставщик программного обеспечения должен быть готов предоставить список заказчиков, отчеты об обнаруженных ошибках, внесенных исправлениях, а также сообщить, как долго это Глава 6. Проектирование экспертных систем инструментальное средство находится в эксплуатации. Еще одним превосходным источником информации может стать группа пользователей. Ошибки вцепи логического вывода. Эти ошибки могут быть вызваны наличием ошибочных знаний, семантическими ошибками, ошибками в программном обеспечении машины логического вывода, неправильными спецификациями приоритетов правили незапланированными взаимодействиями правил. Более сложные ошибки вцепи логического вывода возникают из-за неопределенности в правилах и свидетельствах, распространения неопределенности вцепи логического вывода, а также из-за немонотонности, обусловленной необходимостью извлекать неправильные факты, а также все другие факты, выработанные на основе неправильных фактов. Такое поведение машины логического вывода можно сравнить стем, что человек, узнав об отмене собрания, не отправляется в пустой конференц-зал, безуспешно дожидаясь, пока в нем соберутся люди, а реализует другие планы (например, решает немного вздремнуть, так как вокруг больше никого нет. Недостаточно просто выбрать какой-то метод учета неопределенности, поскольку никогда не удается автоматически разрешить все вопросы, связанные с неопределенностью. Например, даже прежде чем выбрать простой байесовский логический вывод, необходимо выяснить, достаточно ли для достижения успеха принять предположение об условной независимости. Ошибки определения границ незнания. На всех этапах разработки приходится сталкиваться с одной и той же проблемой — определения границ незнания системы. Как было указано в главе 1, обычно можно рассчитывать на то, что эксперты-люди знают пределы своих знаний, поэтому надеяться, что сами эксперты смогут корректно показывать снижение качества своих рекомендаций при достижении границ своего незнания. Эксперты-люди должны быть достаточно честными, чтобы признать реальное увеличение неопределенности в своих выводах вблизи от этих границ. Но экспертная система может по-прежнему уверенно выдавать ответы, даже если цепи логического вывода и сами свидетельства становятся очень хрупкими и ненадежными (такой недостаток экспертных систем может быть преодолен, только если подобные системы специально запрограммированы для работы в условиях неопределенности. А если в надежность выводов системы необоснованно поверят люди, может случиться худшее 6.5. Разработка программного обеспечения и экспертные системы 529 6.5 Разработка программного обеспечения и экспертные системы В предыдущих разделах были приведены общие соображения, которые касаются использования подхода, основанного на экспертных системах, а в этом разделе рассматриваются этапы разработки экспертных систем с более формальной точки зрения — с позиций инженера по знаниям, который фактически формирует систему. С тех пор как экспертные системы вышли за пределы исследовательских лабораторий, появилась реальная потребность в создании для них высококачественного программного обеспечения на основе стандартов, не уступающих стандартам для обычного программного обеспечения. Общепринятой методологией разработки качественного программного обеспечения, соответствующего требованиям к коммерческим, промышленным и правительственным стандартам, является программотехника. Необходимо тщательно придерживаться качественных стандартов разработки любого программного продукта, так как в противном случае не удастся достичь высокого качества такого продукта. А экспертные системы — это такие же программные продукты, как и любое другое программное обеспечение, будь то текстовый процессор, программа учета заработной платы или компьютерная игра. Тем не менее по своему назначению экспертные системы значительно отличаются от обычных потребительских программных продуктов, таких как текстовые процессоры и видеоигры. Термин "назначение" служит для описания общей цели создания любого проекта или технологии. Обычно технология экспертных систем приобретает важное предназначение, которое связано с обеспечением доступа к экспертным знаниям в ситуациях, требующих высокой производительности, а также, возможно, связанных с опасностями, когда под угрозой находится жизнь и собственность человека. В этом и состоит определение тех ответственных приложений, о которых шла речь в предыдущем разделе. А системы, основанные на знаниях, необязательно должны соответствовать таким высоким стандартам Ответственные приложения весьма отличаются по своему назначению от программ, эксплуатируемых в менее жестких условиях, например, текстовых процессоров и видеоигр, поскольку при разработке последних основное внимание уделяется повышению эффективности и обеспечению удобства в работе. В частности, в связи с наличием ошибки в программе текстового процессора или видеоигры жизнь человека не подвергается опасности (или, по крайней мере, этого не должно быть. Экспертные системы представляют собой высокопроизводительные системы, которые должны обладать высоким качеством, так как в противном случае при их эксплуатации придется столкнуться с ошибками. Как показано на рис. 6.5, 530 Глава 6. Проектирование экспертных систем ПРОБЛЕМЫ Высокая стоимость разработок Отсутствие единообразия в методологиях разработки Недостаточная производительность труда программистов цикл программного ия требования Документация Отчеты Графики Обеспечивающий удобство сопровождения и усовершенствования Аттестованный, верифицированный и проверенный Экономически эффективный Своевременно созданный Хорошо документированный Рис. Методология разработки программного обеспечения в основе методологий создания качественного программного обеспечения лежит программотехника. Термину "качество" нелегко дать общее определение, поскольку в разных областях человеческой деятельности он может приобретать различный смысл. Одним из способов определения качества является перечисление обязательных или желательных атрибутов некоторого объекта, измеряемых по некоторой шкале. В данном контексте термин "объект" используется для обозначения любых программных или аппаратных средств, таких как, допустим, рассматриваемый программный продукт. Атрибуты и их значения принято называть метриками, поскольку они используются как показатели измерения характеристик объекта. Например, надежность жесткого диска принято рассматривать как метрику, определяющую его качество. Одной из единиц измерения этого атрибута является среднее время наработки на отказ (Mean Time Between Failures — MTBF) жесткого диска. Надежный жесткий диск должен иметь показатель MTBF, составляющий не меньше 50 тысяч часов эксплуатации между отказами, а менее надежный, дешевый жесткий диск может иметь показатель, составляющий 10 тысяч. Разработка программного обеспечения и экспертные системы 531 часов. В ХХ столетии часто приходилось наблюдать, как пользователи включают свои компьютеры всего на несколько часов дома или на работе, а теперь в основном принято оставлять компьютер включенным круглосуточно (по формуле 24 х 7 х 52), поэтому общая продолжительность эксплуатации жесткого диска значительно увеличилась. Безусловно, современные операционные системы позволяют переводить в режим уменьшенного потребления электроэнергии не только мониторы, но и жесткие диски. Тем не менее, если продолжительность времени простоя, по истечении которого такое устройство переводится в режим ожидания, установлена слишком короткой, то останови последующий запуск жесткого диска происходит слишком часто, что может стать источником новых рисков. Производители жестких дисков стремятся не только повысить их быстродействие, но и сократить частоту возникновения ошибок при записи. Предположим, что согласно спецификации жесткий диск должен обеспечивать запись, допуская ошибки не больше чем водном бите на каждый миллиард операций записи. В х годах, когда обычные жесткие диски имели объем порядка 20 Мбайт, это означало„что жесткий диск можно было заполнить больше 50 раз, ни разу не столкнувшись с ошибкой при записи. А в настоящее время появились жесткие диски с емкостью порядка 200 Гбайт, поэтому притом же показателе в одну ошибку на миллиард операций записи количество ошибок на жестком диске может достигнуть 200 (при условии, что частота ошибок не изменится). Если ошибка произойдет при записи сжатого изображения, такого как . j pg, то, по всей видимости, она не будет обнаружена. Но если ошибка возникнет при записи строки кода, то искажение водном бите может привести к тому, что оператор программы, допустим ХА, превратится в Х = В, а это может повлечь за собой весьма неблагоприятные последствия. Современные жесткие диски имеют встроенный датчик, который непрерывно контролирует состояние поверхности диска с помощью средства, называемого SMART (Self-Monitoring, Analysis and Reporting Technology). Доступ к средствам технологии SMART может быть получен с помощью таких программ, как Norton System Utilities, например, путем вызова на выполнение программы Disk Doctor Utility. Такие программы позволяют получить заблаговременное предупреждение о большинстве возможных нарушений в работе аппаратного обеспечения жесткого диска. Однако, чтобы это предупреждение действительно не прошло даром, необходимо создавать резервные копии и заменять жесткий диск, пока еще не произошла потеря данных. Технология SMART — это инструмент, который предсказывает возможное ухудшение состояния жесткого диска, ноне позволяет его исправить, если проблема связана с износом и снижением качества поверхности магнитного носителя, поскольку ничто в мире неидеально. Нов каждом новом поколении жестких дисков применяются все более высокие значения частоты вращения пластина магнитное покрытие этих пластин неизменно становится все более совершенными надежным Глава 6. Проектирование экспертных систем В х годах стандартным показателем частоты вращения было значение мин 1, затем это значение увеличилось домин и теперь составляет 7200 мин появились даже такие выдающиеся модели жестких дисков, в которых частота вращения достигает 10000 мин 1. Чтобы проще было представить себе эту скорость, рассмотрим такую аналогию. Колесо автомобиля имеет диаметр приблизительно 60 см и длину окружности около 190 см. Если бы колеса автомобиля вращались с частотой 3600 мин 1, то автомобиль двигался бы со скоростью примерно 410 км/ч, а при частоте вращения мин 1 скорость автомобиля достигла бы 1130 км/ч, т.е. приблизилась бык скорости звука. Именно поэтому в любой компьютерной системе основным источником неисправностей являются механические компоненты, создающие вибрацию и вырабатывающие тепло. Но после ввода в действие битовых процессоров возник еще один первоисточник отказов, поскольку новые процессоры стали вырабатывать намного больше тепла по сравнению с битовыми. Эта проблема оказалась настолько важной, что предназначенные для их установки системные платы начали выпускаться с температурными датчиками, прямо на самом процессоре стали устанавливаться радиаторы с вентиляторами, корпуса компьютеров для охлаждения оснащались шестью вентиляторами, а для останова системы в случае чрезмерного повышения температуры было создано специальное программное обеспечение. Кроме того, жесткий диски память стали размещаться на максимально возможном расстоянии от процессора. К счастью, в новых версиях битовых процессоров этот недостаток преодолен. В табл. 6.1 приведен контрольный список некоторых показателей, которые могут использоваться в оценке качества экспертной системы. Эти показатели следует рассматривать только в качестве ориентировочных, поскольку, когда речь идет о конкретной экспертной системе, не все они могут оказаться в достаточной степени приемлемыми. Тем не менее всегда важно иметь в своем распоряжении перечень необходимых характеристик, который может использоваться при оценке качества. Следует всегда руководствоваться заранее подготовленным списком требуемых показателей, поскольку он позволяет проще расположить показатели по приоритетам в случае обнаружения конфликтов между ними. Например, увеличение продолжительности проверки экспертной системы в целях обеспечения ее надежной аттестации приводит к увеличению издержек. Вообще говоря, решение о прекращении испытаний является очень сложным, требующим учета таких трех факторов, как степень выполнения графика работ, объем затрат и соответствие системы предъявляемым требованиям. В идеальном случае испытания должны быть завершены в условиях положительной оценки всех трех указанных факторов. Но на практике некоторые из них часто рассматриваются как более важные, чем другие, поэтому и ослабляются ограничения, касающиеся реализации всех факторов без исключения. Жизненный цикл экспертной системы 533 Таблица Некоторые показатели оценки качества программного обеспечения для экспертных систем Показатель оценки качества программного обеспечения Правильные выходные данные при наличии правильных входных данных Полный объем выходных данных при наличии правильных входных данных Неизменные выходные данные при повторном поступлении одних и тех же входных данных Достаточно высокая надежность, благодаря которой не происходит отказ из- за ошибок (или, по крайней мере, происходит редко) Удобство в эксплуатации, а также, желательно, дружественность Удобство в сопровождении Расширяемость Соответствие потребностями запросам пользователя, подтвержденное путем проведения аттестации Правильность и полнота, подтвержденные в результате проверки Экономическая эффективность Наличие кода, применимого для создания других приложений Обеспечение переносимости в другую аппаратную и (или) программную среду Возможность сопряжения с другим программным обеспечением Удобство кода для чтения и понимания Правильность Точность Корректное снижение качества результатов по мере приближения к границам незнания Встроенные возможности взаимодействия с другими языками Аттестованная база знаний Наличие средства объяснения б.б Жизненный цикл экспертной системы Одним из ключевых понятий программотехники является жизненный цикл Жизненный цикл программного обеспечения — это период времени, который начинается с формулировки первоначальных концепций, лежащих в основе программного обеспечения, и заканчивается переводом программ в категорию непригодных для дальнейшего использования. Понятие жизненного цикла позволяет отказаться от отдельного рассмотрения этапов разработки и сопровождения и создать общий Глава 6. Проектирование экспертных систем 534 контекст, непрерывно связывающий все этапы. При таком подходе появляется возможность запланировать работы, связанные с сопровождением и дальнейшим развитием, на ранних этапах жизненного цикла, что позволяет в последующем снизить расходы на осуществление указанных этапов. Расходы на сопровождение Расходы на сопровождение обычного программного обеспечения, достигшего коммерческого успеха, которое неизменно модифицируется и дополняется через каждые несколько лет, вполне могут превзойти в десятки раз первоначальные расходы на разработку, связанные с созданием первого выпуска данного программного продукта, и возрастать с появлением каждой новой версии. Безусловно, может показаться, что такие расходы со временем становятся чрезмерными, но, как было указано выше, само сопровождение программы может стать источником существенных доходов. Однако минус третий закон успеха гласит если вы не любите путешествовать, то довольствуйтесь теми занятиями, которые вас устраивают на данный момент. Поэтому если вы неизменно продолжаете устранять ошибки в вашем программном продукте, то не заменяйте его название чемто полностью новым. При этом целесообразно придерживаться такого принципа варьировать старое название, ноне вводить в это название неприятный оттенок, например, не называть новую версию "Doors BugFix No. 10" (Программа Doors, с исправлением ошибок номера назвать ее, скажем, "Doors 2010". В последнее время все чаще создаются экспертные системы, основанные не на экспертных знаниях человека, а на обычных знаниях. Из этого правила есть заметные исключения. К ним относятся интеллектуальные обучающие системы для такого специального персонала, как врачи или летчики. Экспертные системы весьма успешно применяются в качестве обучающих систем и позволяют значительно сократить затраты времени, на которые обычно приходится идти, если к преподаванию вступительного материала специалисты привлекаются в отрыве от основной деятельности. Нов принципе, если созданию экспертной системы уделено достаточно времени и ресурсов, то с ее помощью часто можно предоставить студенту такую подготовку, что он может немедленно приступать к реальной работе. По мере того как убыстряется смена технологий, снижается потребность в сохранении в системе знаний людей, отправляющихся на пенсию. Но необходимость в сопровождении экспертных систем возрастает, поскольку относительный объем содержащихся в них эвристических знаний, основанных на опыте, возрастает. Еще больших расходов на сопровождение и доработку требуют экспертные системы, в которых осуществляется большой объем логического вывода в условиях неопределенности. Безусловно, в результате появления автоматизированных инструментальных средств формирования и импорта онтологий в экспертные си 6.6. Жизненный цикл экспертной системы стемы задача сопровождения таких систем упрощается, но вместе стем сами эти системы также становятся крупнее, как и любое программное обеспечение, развивающееся со временем, поэтому задача сопровождения отнюдь не становится проще. Модель каскадного развития жизненного цикла 2. Какую продолжительность должен иметь следующий этап Модель процесса фактически представляет собой метаметодологию, поскольку определяет порядок и продолжительность применения обычных программных методов. Ниже перечислены наиболее широко используемые методы (или методологии разработки программного обеспечения. Выбор конкретных методов для осуществления работ на определенной стадии, в том числе указанных ниже. ° Планирование. ° Определение требований. ° Приобретение знаний. ° Проверка. Для обычного программного обеспечения был разработан целый ряд различных моделей жизненного цикла. Классической моделью жизненного цикла является впервые разработанная модель такого типа — каскадная модель, которая показана на рис. Эта модель хорошо знакома программистам, занимающимся разработкой обычного программного обеспечения. В каскадной модели каждый этап производственной деятельности заканчивается верификацией и аттестацией (Verification and Validation — V й V), что позволяет свести к минимуму количество проблем, подлежащих решению после перехода наследующий этап. Кроме того, следует отметить, что, как показано на рис. стрелки проходят в прямом и обратном направлениях одновременно только через один этап. Тем самым подчеркивается, что разработка осуществляется итеративно с охватом только двух смежных этапов. Это позволяет значительно уменьшить расходы по сравнению с таким подходом (требующим гораздо более значительных издержек, в котором итеративная разработка охватывает несколько этапов. Стоимость возврата к предыдущим этапам измеряется непростой линейной функцией, а определяется экспоненциальной зависимостью от сложности связанных с этим операций. Для обозначения понятия жизненного цикла применяется еще один термин модель процесса, поскольку это понятие связано с двумя перечисленными ниже фундаментальными вопросами разработки программного обеспечения. 1. Что должно быть сделано наследующем этапе 536 Глава 6. Проектирование экспертных систем Рис. Каскадная модель жизненного цикла программного обеспечения Составление документации. Представление результатов выполнения работ на текущей стадии, как указано ниже 537 6.6. Жизненный цикл экспертной системы ° Разработка кода Подготовка диаграмм. Модель развития жизненного цикла на основе "кодирования и исправления" Инкрементная модель жизненного цикла Инкрементная каскадная модель представляет собой результат усовершенствования каскадного подхода и стандартного нисходящего подхода. Основная идея инкрементной разработки состоит в том, что программное обеспечение создается по принципу поэтапного наращивания функциональных возможностей. Применение инкрементной модели в крупных проектах разработки обычного программного обеспечения оказалось очень успешным. Инкрементная модель используется также для разработки экспертных систем на ее основе происходит добавление правил, в результате чего возможности системы постепенно возрастают и система превращается вначале в помощника, затем в коллегу и наконец достигает уровня эксперта. Таким образом, в экспертной системе крупными этапами усовершенствования становится переход из статуса помощника в статус коллегии из статуса коллеги в статус эксперта. Мелкие этапы усовершенствования соответствуют такому увеличению объема экспертных знаний на каждом уровне, которое может рассматриваться как заметное достижение. Наконец, микроусовершенствование — это такое изменение Для разработки программного обеспечения применялся целый ряд моделей процесса. Одной из ранних моделей (впрочем, вряд ли даже имеющих право называться моделями) является печально знаменитая модель разработки на основе "кодирования и исправления, в которой предусматривается написание некоторого кода и последующее исправление, если этот код действует неправильно. Как правило, именно такой метод выбирают студенты, впервые приступающие к освоению обычного программирования и программирования экспертных систем. К 1970 году недостатки подхода на основе "кодирования и исправления" стали настолько очевидными, что была разработана каскадная модель, которая позволила наконец предоставить систематизированную методологию, оказавшуюся особенно удобной для крупных проектов. Но при использовании каскадной модели возникали сложности, поскольку в ней предполагалось, что известна вся информация, необходимая для реализации каждого этапа. Нона практике часто было невозможно сформулировать общие требования до того, как будет создан некоторый прототип. Такая ситуация привела к выработке концепции двукратной разработки, на основании которой создавался прототип, определялись требования, а затем создавался окончательный вариант системы Глава б. Проектирование экспертных систем Модель спирального развития жизненного цикла Один из способов визуального представления инкрементной модели состоит в применении стандартной спиральной модели разработки программного обеспечения Барри Бома (Barry Boem), которая показана на рис. 6.7. После прохождения каждого цикла в спирали к системе добавляются определенные функциональные возможности. Обозначение конечной точки как "Системы, предоставляемой заказчику" фактически не становится концом спирали. Вместо этого закладывается новая спираль, в которую включены этапы сопровождения и развития системы. Саму спиральную модель можно также дополнительно усовершенствовать, определив более точно общие этапы приобретения знаний, разработки кода, проведения оценки и планирования. 6.7 Подробная модель жизненного цикла Одной из моделей жизненного цикла, которая успешно использовалась во многих проектах экспертных систем, является линейная модель, показанная на рис. 6.8. Определяемый таким образом жизненный цикл состоит из ряда этапов, начинающихся с планирования и заканчивающихся оценкой готовой системы, и описывает разработку системы до некоторого момента, в который должна быть получена оценка функциональных возможностей системы. После этого в жизненном цикле повторяется та же последовательность от планирования до оценки в объеме экспертных знаний, которое соответствует добавлению или уточнению отдельного правила. Основное преимущество инкрементной модели состоит в том, что задачи проверки, верификации и аттестации достижений в части расширения функциональных возможностей решаются проще по сравнению с каскадной моделью, поскольку последняя предусматривает решение этих задач на отдельных этапах применительно ко всему разрабатываемому продукту. Таким образом, инкрементная модель позволяет проводить с участием эксперта проверку, верификацию и аттестацию результатов каждого этапа усовершенствования функциональных возможностей сразу же после его завершения, а не ожидать проведения аттестации всей системы по окончании разработки. Благодаря этому снижается стоимость внесения исправлений в систему. По существу, инкрементная модель аналогична по своему назначению непрерывно дополняемому первоначальному прототипу, над которым проводится работа в течение всей разработки. Как уже было сказано, в подходе на основе двукратной разработки первоначальный прототип применяется только на начальных этапах для определения требований к системе, а в подходе на основе инкрементной модели как непрерывно развивающийся прототип рассматривается сама система 6.7. Подробная модель жизненного цикла 539 Рис. Спиральная модель разработки экспертной системы системы. Эти этапы разработки осуществляются до тех пор, пока система не будет передана в повседневную эксплуатацию. В дальнейшем это определение жизненного цикла применяется для осуществления последующих этапов сопровождения и развития системы. Безусловно, на схеме это явно не показано, но параллельно с осуществлением данных этапов происходит верификация и аттестация. Для обеспечения высокого качества экспертной системы необходимо непросто исправлять обнаруженные ошибки, но неуклонно придерживаться одной и той же последовательности этапов. Если какие-либо этапы пропускаются, пусть даже ради исправления единственной небольшой ошибки, общее качество системы снижается. Жизненный цикл, показанный на рис. 6.8, может рассматриваться как один цикл спиральной модели. Каждый этап состоит из задач. На некотором этапе может не потребоваться выполнение всех задач, особенно после того как начинается сопровождение и развитие системы. Дело в том, что в рассматриваемом подходе понятие задачи формулируется таким образом, что каждая задача рассматривается как соединение всех задач, относящихся ко всему жизненному циклу, начиная от формулировки исходной концепции и заканчивая переводом программы в категорию подлежащих замене. Кроме того, формулировка задач зависит оттого, какое именно приложение подлежит разработке, и поэтому рекомендуемый состав каждой задачи должен рассматриваться только в качестве руководящих, а не СО он Сб с :> 0) Q) CL д М оно ос) Б д Ф э CL Q) И РЭ Сб I- hC вс О о CL C о L од Б Б Ио о CL C 'Е Ь о. Ф о ос Б K K д Сб ь- 2 со оно ос Сб н Со оно' ос Сб о CL K )- М Ф ос д И д СТ Б Ф о Б и Q) Х д Q) э CL Ф m (Ч х Б д Z Сб О Сб С до д Яд Сб д m д hc д Ф э СО о о h ос х m ) Z У Фд О о СО )g о о ИМ Сб с Q) со ТО ос оно хо Ь ) c) ос о од хо Сб а о- m И СО с 0) х 2 И д)д С д Q) Z Z 5 у ИО с сб ос й о ж Со ж н РИМ о g Мн о ЮН р й о о ж ж ЯМ ой сб ж )g 2 ж 00 '40 ж Фм Я у до Ио с m c CL 6.7. Подробная модель жизненного цикла 541 Планирование Назначение этапа планирования состоит в подготовке формального рабочего плана разработки экспертной системы. Рабочий план представляет собой набор документов, на основании которых должны осуществляться действия по руководству разработкой и оценке результатов. Отдельные действия, выполняемые на этом этапе, приведены в табл. Наиболее важной задачей, которая должна быть решена в процессе реализации жизненного цикла, является оценка осуществимости. При проведении этой Таблица 6.2. Действия, выполняемые на этапе планирования Назначение Действие Определение того, оправданы ли затраты по созданию системы, и, в случае положительного ответа, выяснение, должна ли для этого использоваться технология экспертных систем Оценка осуществимости Оценка объема необходимых ресурсов, в том числе рабочей силы, времени и финансов, а также программного обеспечения и аппаратных средств. Приобретение и управление требуемыми ресурсами Управление ресурсами Определение этапности решения задач Выявление состава задачи определение поэтапного порядка их решения Составление планов, регламентирующих время начала и окончания этапов решения задач Планирование Определение того, какие операции должна осуществлять система, путем указания функций системы высокого уровня. При осуществлении указанного действия на этапе планирования уточняется назначение системы Предварительная функциональная компоновка Определение требований высокого уровня Подготовка составленного в общих терминах описания того, как должны выполняться функции системы абсолютных требований, которые должны быть выполнены для успешного завершения каждого этапа. Рассмотрим эту модель жизненного цикла более подробно, чтобы показать, как много факторов приходится рассматривать при создании крупной и качественной экспертной системы. С другой стороны, при разработке небольших экспериментальных прототипов, не предназначенных для общего пользования, нужны не все задачи и даже не все этапы. Но удивительно то, насколько большой объем программного обеспечения разрабатывался для личного пользования или ради эксперимента, после чего был передан в руки коллег, оказался весьма востребованными наконец поступил в общее пользование Глава 6. Проектирование экспертных систем 542 Определение знаний Целью этапа определения знаний является выяснение требований к знаниям, содержащимся в экспертной системе. Этап определения знаний состоит из двухосновных задач, которые описаны ниже. ° Идентификация и выбор источника знаний. ° Приобретение, анализ и извлечение знаний. Каждая из этих основных задач состоит из других задач. В табл. описаны задачи, связанные с идентификацией и выбором источника знаний. Таблица 6.3. Задачи идентификации и выбора источника знаний Задача Назначение Идентификация источника знаний Поиск ответа на вопрос о том, кто и что должно явиться источником знаний при решении этой задачи проблема доступности источника знаний не рассматривается Распределение источников знаний по приоритетам, отражающим их значимость для разработки Оценка важности источника знаний Составление списка источников знаний, упорядоченного с учетом их доступности. Как правило, Web, книги и другие документы позволяют получить к ним доступ намного проще, чем эксперты-люди Оценка доступности источника знаний Окончательный выбор источников знаний с учетом их важности и доступности Выбор источника знаний Задачи приобретения, анализа и извлечения знаний описаны в табл. 6.4. Основной целью осуществления задач приобретения знаний, анализа знаний и извлечения знаний является подготовка и проверка знаний, требуемых в системе. К тому времени, когда будет собран требуемый объем знаний, все эти знания должны быть правильными и пригодными для осуществления следующего этапа проектирования знаний. Сбор знаний может выполняться не только с использованием общепринятого метода проведения собеседования с экспертами, но и с помощью многих программных инструментальных средств, позволяющих обеспечить оценки необходимо найти ответы на вопрос о том, стоит ли заниматься реализацией данного проекта, а также на связанный с ним вопрос о том, является ли приемлемым подход, основанный на использовании экспертной системы. От ответов на эти два вопроса зависит решение, касающееся дальнейшей реализации рассматриваемого проекта на основе подхода, в котором применяется экспертная система. При оценке осуществимости приходится учитывать множество факторов. Как было описано в разделе 6.1, в число этих факторов входят выбор подходящей проблемной области экспертной системы, определение затрат, выигрыша и т.д. 6.7. Подробная модель жизненного цикла 543 Назначение Задача Регламентация процедур приобретения знаний с указанием методов получения интервью у экспертов, обработки документов, вывода правил методом индукции, создания устойчивых решеток (как способа представления знаний) и т.д. Определение стратегии приобретения знаний Выборка из источников знаний конкретных знаний, которые потребуются на данной итерации жизненного цикла Идентификация элементов знаний Классификация и упорядочение знаний в целях упрощения операций верификации и усвоения знаний, выполняемых разработчиками. По возможности при решении этой задачи следует использовать способы классификации с помощью иерархических групп Создание системы классификации знаний Составление подробной спецификации функциональных возможностей системы. Этот уровень в большей степени относится к компетенции технических специалистов, тогда как задача разработки предварительной функциональной компоновки решается на уровне руководящих работников Разработка подробной функциональной компоновки Описание общих этапов, реализуемых входе эксплуатации экспертной системы. Этапы соответствуют логическим группам правил, которые одновременно активизируются и (или) переходят в неактивное состояние, в связи с чем в системе осуществляется передача управления от одного компонента к другому Предварительное планирование процессов передачи управления Подготовка описания системы сточки зрения пользователя. Эта задача в составе задач создания системы часто игнорируется, но является чрезвычайно важной. Пользователей абсолютно необходимо привлекать к работе как можно раньше, чтобы можно было скорее ознакомиться сих откликами. Если систему никто не использует, она ничего не стоит Предварительное составления руководства пользователя Точное определение требований к системе. На основании этих требований должна проводиться аттестация экспертной системы Определение требований к системе Выявление того, какие знания являются для системы наиболее важными. После определения базовой структуры любые изменения в нее вносятся только по формальному запросу, поскольку это определение знаний высокого уровня теперь должны стать основой следующей стадии проектирования знаний Определение базовой структуры знаний Таблица Задачи приобретения, анализа и извлечения знаний Глава 6. Проектирование экспертных систем Проектирование знаний Целью этапа проектирования знаний является подготовка подробного проекта для экспертной системы. Ниже указаны две основные задачи, из которых состоит этот этап. ° Определение знаний. ° Составление подробного проекта. В табл. б описаны задачи, связанные с определением знаний. Таблица 6.5. Задачи определения знаний Задача Назначение Определение формы представления знаний, такой как правила, фреймы или логические формулы, с учетом того, какую форму представления поддерживает используемое инструментальное средство разработки экспертных систем Выбор способа представления знаний Создание трех общих структур управления во-первых, структур, определяющих способ вызова системы, если код системы входит в состав процедурного кода во-вторых, структур, обеспечивающих управление взаимосвязанными группами правил входе эксплуатации системы в-третьих, структур метауровня, под управлением которых действуют правила Подробная разработка структур управления Определение единообразной внутренней структуры фактов, позволяющей упростить понимание смысла фактов и добиться применения хорошего стиля программирования Регламентация внутренней структуры фактов Определение предварительных требований к пользовательскому интерфейсу. Получение от пользователей отзывов об интерфейсе Предварительная подготовка пользовательского интерфейса Определение способов проверки кода. Регламентация состава проверочных данных, подготовка вспомогательных программ, применяемых в процессе проверки, и выбор способа анализа результатов проверки Составление начального плана проверки Внутренние структуры фактов, о которых речь идет в табл. б, рассматриваются более подробно в главах данной книги, посвященных языку CLIPS. При автоматическое приобретение знаний. Подобные инструментальные средства часто предоставляются поставщиками инструментальных средств. А что касается приобретения знаний инженером познаниям, пытающимся выявить знания, которыми обладает эксперт, то для этого требуется довольно высокая квалификация эта тема более подробно рассматривается в [43]. 6.7. Подробная модель жизненного цикла 545 Таблица Задачи этапа подробного проектирования знаний Задача Назначение Регламентация способов логической организации знания в базе знаний и определение того, что должно находиться в базе знаний Разработка структуры проекта Выбор стратегии реализации Определение того, как должна осуществляться реализация системы Подробное определение пользовательского интерфейса на основании изучения отзывов пользователей в отношении предварительного проекта пользовательского интерфейса Подробная разработка пользовательского интерфейса Подготовка спецификаций проекта и составление отчетов Документальное оформление результатов проекта Составление подробного плана проверки Точное определение того, как должна осуществляться проверка и аттестация кода В результате выполнения этапа подробного проектирования создается конкретизированный проектный документ, на основании которого можно непосредственно приступать к разработке кода. Но до начала разработки кода этот конкретизированный проектный документ в качестве заключительной проверки подвергается рецензированию как проект системы знаний. определении структур фактов необходимо прежде всего придерживаться хорошего стиля программирования. Например, такой факт, как "10", сам по себе содержит мало смысла, поскольку трудно сказать, что означает "10". Если же в определение факта включается дополнительная информация, такая как "price цена, равная 10) или, что еще лучше, "gold price 10" (цена на золото, равная 10), то становится ясно, что речь идет оценена золото. Следует отметить, что в такой форме факт соответствует обычному шаблону "объект — атрибут значение" и поэтому становится удобным для чтения и понимания людьми. В языке CLIPS возможность использования такой формы предоставляется с помощью конструкции deftemplate для правила также с помощью объектов. В некоторых языках экспертных систем поля могут иметь строгую типизацию, что позволяет хранить в них только определенные значения. Если же предпринимается попытка задать в правиле недопустимое значение, то машина логического вывода отмечает такую ситуацию как ошибку. В табл. 6.6 показан состав задач, решаемых на этапе подробного проектирования знаний Глава б. Проектирование экспертных систем Разработка кода и отладка В табл. 6.7 представлены задачи этапа разработки кода и отладки, с которого начинается фактическая реализация кода. Таблица 6.7. Задачи разработки кода и отладки Задача Назначение Разработка кода Проверка Фактическое осуществление разработки кода Проверка кода с использованием проверочных данных, вспомогательных программ проверки и процедур анализа результатов проверки Подготовка снабженного комментариями и документированного исходного кода Подготовка распечаток программ Подготовка рабочей пользовательской документации, с помощью которой эксперты и пользователи могли бы быстрее осваивать систему Подготовка пользовательской документации Подготовка руководств по инсталляции и экс- Документирование применяемых пользователями процедур инсталляции и эксплуатации системы плуатации Общее описание функциональных возможностей, ограничений и задач, связанных с эксплуатацией экспертной системы Составление документа с описанием системы Верификация знаний Этап верификации знаний имеет своей целью определение правильности, полноты и непротиворечивости системы. Этот этап подразделяется на две основные задачи, приведенные ниже. ° Проведение формальных проверок. ° Анализ результатов испытаний. В табл описан состав задач формальной проверки на этапе верификации знаний. В табл. 6.9 показаны задачи анализа результатов проверки. В процессе анализа результатов проверки предпринимаются попытки выявить следующие основные недостатки ° неправильные ответы ° неполные ответы Этот этап завершается проверкой готовности к испытаниям, входе которой определяется готовность экспертной системы к проведению следующего этапа верификации знаний. Подробная модель жизненного цикла 547 Таблица Состав задач формальной проверки на этапе верификации знаний Задача Назначение Осуществление процедур проверки Реализация процедур формальной проверки Подготовка отчетов по результатам Документирование результатов проверки проверки ° несовместимые ответы. Таблица 6.9. Задачи анализа результатов проверки Задача Назначение Оценка результатов Подготовка рекомендаций Анализ результатов проверки Документальное оформление рекомендаций и заключений по результатам проверок Оценка системы Как показано в табл, конечным этапом жизненного цикла разработки является этап оценки системы. Назначение этого этапа состоит в подведении итогов того, какие выводы были сделаны на основании рекомендаций по усовершенствованию и внесению исправлений. Как уже было сказано, обычно разработка экспертной системы осуществляется путем последовательного наращивания ее возможностей, поэтому, как правило, отчет, составленный по результатам выполнения этапа оценки системы, становится промежуточным отчетом, в котором дано описание функциональных возможностей системы, возросших в результате введения новых знаний. Тем не менее новые возможности системы необходимо проверять не только отдельно, но ив сочетании со знаниями системы, которые были введены в нее ранее. Это означает, что и верификация системы должна выполняться с учетом всех знаний Кроме того, входе решения этих задач необходимо определить, обусловлены ли эти недостатки ошибками в правилах, цепях логического вывода, в оценке неопределенности, или являются следствием воздействия некоторой комбинации этих трех факторов. Если причины обнаруженного недостатка невозможно выявить путем анализа самой экспертной системы, то необходимо проанализировать на наличие программных ошибок программное обеспечение инструментального средства разработки экспертных систем, но к такой мере следует прибегать только в крайнем случае. В отличие от других инструментальных средств для языка CLIPS предоставляется весь исходный код и все руководства, поэтому всегда есть возможность дойти до первопричины ошибки Глава 6. Проектирование экспертных систем Таблица Задачи этапа оценки системы Задача Назначение Оценка результатов Подведение итогов по результатам проверки и верификации Подготовка рекомендаций по внесению изменений в систему Выработка рекомендаций Проведение аттестации, позволяющей определить, что система действует правильно, а также соответствует потребностями пожеланиям пользователей Аттестация Если разработка системы завершена, то составляется окончательный отчет. В противном случае составляется промежуточный отчет и определяются потребности в дальнейшем финансировании Подготовка промежуточного или окончательного отчета 6.8 Резюме В этой главе обсуждался программотехнический подход к разработке экспертных систем. Изложены основные принципы качественного проведения собеседований с экспертом. В наши дни технология экспертных систем широко используется для решения практических задач, поэтому к качеству экспертных систем предъявляются очень высокие требования, особенно в связи стем, что многие из них используются в оборонительных системах ив кредитных агентствах. При проектировании экспертной системы необходимо рассмотреть целый ряд факторов, таких как состав задач, ограничения по стоимости и вероятный выигрыш. Успешное создание системы становится невозможным, если не учитываются и управленческие, и технические аспекты [40]. Одним чрезвычайно полезным понятием, применяемым при разработке программного обеспечения, является понятие жизненного цикла экспертной системы. При использовании подхода, основанного на определении жизненного цикла, разработка программного обеспечения рассматривается как ряд стадий существования программного обеспечения, начинающихся с формулировки начальной концепции и заканчивающихся его переводом в категорию непригодных для дальнейшего использования. (Однако создается впечатление, что при современной организации бизнеса, когда основные доходы приносит исправление ошибок и (или) системы, а не только новых знаний. В идеальном случае после каждого перехода на данный этап должна также проводиться аттестация экспертной системы, чтобы не приходилось ожидать завершения последней итерации разработки. Но при таком подходе возникает опасность непроизводительного использования рабочего времени эксперта 549 Задачи Задачи 6.1. Рассмотрите простую систему, основанную на знаниях, предназначенную для диагностирования неисправностей в автомобиле. Опишите эту предлагаемую систему в том виде, который подходит для использования на каждой стадии линейной модели. (Для этого не требуется детализация вплоть до отдельной задачи.) Исходите из того, что над проектом работает много людей, поэтому предусмотрите возможность координации их усилий. Дайте пояснения по поводу всех принятых вами предположений. Составьте отчет о выполнении задачи 6.1 с использованием коммерческого автоматизированного инструментального средства для управления знаниями. Загрузите его испытательную версию, проведя поиск либо в приложении Ж, либо в Web. Перечислите основные проблемы, которые удалось обнаружить сего помощью, и укажите стоимость их устранения. Объясните, в чем состоят изменения или различия в линейных моделях, используемых для разработки крупного проекта с участием многочисленных разработчиков или небольшого проекта, только с одним участником. выпуск усовершенствованных версий, более выгодно никогда не отказываться от дальнейшего сопровождения программного обеспечения в связи сего устареванием) Практика показала, что неизменное соблюдение всех требований, связанных с осуществлением подхода на основе жизненного цикла, позволяет успешно создавать качественное программное обеспечение. Обсуждалось несколько разных моделей жизненного цикла, применимых для разработки экспертных систем, и приведено подробное описание каждой из этих моделей. В рамках проекта RuleXML и инициативы по созданию языка RuleML (Rule Markup Language) ведутся работы по обеспечению машинного чтения правил (http://www.ruleml.org). Глава Введение в CLIPS 7.1 Введение Вначале данной главы приведено вводное описание практических понятий, необходимых для формирования экспертной системы. В главах 1 — 6 даны основные сведения, представлена история развития, изложены основные определения, описана терминология, расшифрованы основные понятия, а также перечислены наиболее характерные инструментальные средства и приложения экспертных систем. Короче говоря, в первых главах изложен материал, позволяющий получить основные сведения о том, что представляют собой экспертные системы и какие задачи они позволяют решать. Эта теоретическая инфраструктура понятий и алгоритмов необходима для создания экспертных систем. Однако в процессе создания экспертных систем приходится сталкиваться со многими практическими аспектами, которые необходимо изучать путем самостоятельного выполнения соответствующих действий. Процесс создания экспертной системы во многом напоминает процесс написания программы на процедурном языке. Ведь недостаточно знать, как действует алгоритм, чтобы быть способным написать процедурную программу для реализации этого алгоритма. Аналогичным образом, недостаточно овладеть знаниями эксперта, чтобы приобрести способность к созданию экспертной системы. По этой причине в процессе изучения всей тематики экспертных систем становится бесценным практический опыт использования инструментальных средств создания экспертных систем. В оставшейся части данной книги для демонстрации различных концепций будет использоваться язык экспертных систем Язык CLIPS поддерживает подходы к программированию трех типов основанные на правилах, объектноориентированные и процедурные. Программирование, основанное на правилах, рассматривается в главах 7 — 9. В главе 10 описано процедурное программирование Глава 7. Введение в CLIPS Глава 11 посвящена объектно- ориентированному программированию. Наконец, в главе обсуждается несколько примеров программ, которые демонстрируют возможности, представленные в предыдущих главах. В целом главы 7 — 12 отражают мнение авторов в отношении того, какие средства CLIPS являются наиболее полезными ив каком контексте они должны использоваться. Безусловно, эти главы и связанные сними приложения могут применяться в качестве справочника по языку программирования CLIPS, но основным их назначением является обучение читателя написанию программ Поэтому оставшуюся часть книги не следует рассматривать как материал, в котором приведено исчерпывающее описание каждой подробности каждого средства, предусмотренного в языке CLIPS. А для использования в качестве авторитетного справочника по языку программирования CLIPS предназначен документ CLIPS Basic Programming Guide, представленный в электронном виде на компакт-диске, прилагаемом к данной книге. Этот документ полностью соответствует своему назначению как справочного руководства, поэтому может принести наибольшую пользу тем программистам, которые уже знают, как писать программы CLIPS, и нуждаются в более точной информации о конкретном средстве. В настоящей главе описаны основные компоненты экспертной системы, основанной на правилах (см. главу 1), входящих в состав CLIPS. Эти основные компоненты перечислены ниже. 1. Список фактов содержит данные, на основании которых формируются логические выводы. 2. База знаний содержит все правила. Язык CLIPS CLIPS — это язык программирования, позволяющий использовать целый ряд подходов, который обеспечивает поддержку программирования на основе пра- 3. Машина логического вывода обеспечивает общее управление процессом выполнения программы. Настоящая глава в основном посвящена описанию этих трех компонентов CLIPS. Особенно подробно рассматривается первый компонент — факты. Вначале описаны операции добавления, удаления, модификации, дублирования, отображения и трассировки фактов, а затем дано объяснение того, как правила взаимодействуют в программе CLIPS с фактами для обеспечения функционирования программы. После этого рассматривается тема использования переменных и подстановочных символов в операциях сопоставления с шаблонами. Наконец, для демонстрации взаимодействия многочисленных правил применяется программа "мира блоков", основанная на использовании средств, которые описаны в данной главе. Язык CLIPS 553 вил, объектно-ориентированного и процедурного программирования. Возможности логического вывода и представления, предоставляемые основанным на правилах языком программирования CLIPS, аналогичны возможностям языка OPS5, но являются более мощными. По своей синтаксической структуре правила CLIPS весьма напоминают правила, применяемые в таких языках, как Eclipse, CLIPS/R2 и Jess, но CLIPS поддерживает только правила прямого логического вывода. Этот язык не обеспечивает обратный логический вывод. Возможности объектно- ориентированного программирования языка упоминаемые под общим названием как язык представляют собой гибридную комбинацию средств, обнаруживаемых в других объектно-ориентированных языках, таких как CLOS (Common Lisp Object System — общая объектная система Lisp) и SmallTalk; кроме того, в языке COOL воплощены некоторые новые идеи. С другой стороны, средства языка процедурного программирования, предусмотренные в напоминают средства таких языков, как Си, а по своему синтаксису аналогичны языку LISP. Язык название которого представляет собой сокращение от С Integrated Production System — продукционная система, интегрированная с языком Сбыл разработан с использованием языка программирования Св Космическом центре NASA/Äæîíñîí. Перед разработчиками этого языка была поставлена конкретная задача — обеспечить полную переносимость, низкую стоимость и простую интеграцию с внешними системами. Но компоненты расшифровки аббревиатуры CLIPS не следует трактовать буквально. Дело в том, что первоначально CLIPS обеспечивал поддержку только программирования на основе правил (отсюда происходит часть его обозначения как "продукционной системы. Нов версии языка CLIPS введена поддержка процедурного и объектно- ориентированного программирования. Кроме того, может сбить столку и часть этого сокращенного обозначения, в которой упоминается "язык С, поскольку одна из версий разработана полностью на языке Ada. К настоящей книге прилагается компакт-диск, содержащий исполняемые файлы версии CLIPS 6.2 для DOS, Windows 2000/XP и документацию в электронном виде и исходный код на языке С для CLIPS. Язык CLIPS действительно обеспечивает полную переносимость, поэтому может быть устанавливаться на компьютерах самых разных типов, начиная с персональных компьютеров и заканчивая суперкомпьютерами Большинство примеров, приведенных в этой и последующих главах, должно работать на любом компьютере, на котором установлен язык CLIPS. Но рекомендуется, чтобы пользователи обладали определенными знаниями об операционной системе того компьютера, на котором эксплуатируется Например, от типа операционной системы зависит метод обозначения имен файлов. Если рассматриваемые команды могут зависеть от типа компьютера или операционной системы, об этом дается соответствующее упоминание. Глава 7. Введение в CLIPS 554 7.3 Система обозначений) Это описание синтаксиса означает, что конструкция) должна быть введена так, как показано. Точнее, вначале должен быть введен знак открывающей скобки (, затем буква е, после этого буквы харе и, наконец, знак закрывающей скобки, ) . Квадратные скобки, [ ], указывают, что содержимое в квадратных скобках является необязательным. Например, следующее описание синтаксиса показывает, что цифра 1, находящаяся в квадратных скобках, может не указываться (example [1]) Таким образом, следующий результат ввода является совместимым с указанным выше синтаксическим определением (example) как и такой результат ввода (example 1) Знаки "меньше" и "больше, вместе взятые, указывают, что должна быть выполнена замена значением того типа, который обозначен содержимым, находящимся внутри знаков <>. Например, следующее описание синтаксиса, в котором используются знаки "меньше" и "больше, показывает, что должна быть выполнена замена действительным целочисленным значением |