 |
Глава 8. Программный инструментарий разработки систем, основанных на знаниях
|
|
|
|
8.1. Цели и принципы технологии разработки
программных средств
Технология – это наука о мастерстве (технос – мастерство, логос – слово, наука). Под технологией программирования понимается совокупность знаний о способах и средствах достижения целей в области ПО. Изменения являются постоянным фактором разработки ПО. Для того чтобы преодолеть их разрушающий эффект, в качестве целей технологии разработки ПО принимаются следующие свойства ПС:
* модифицируемость: необходимость возникает, чтобы отразить в системе изменение требований или чтобы исправить ошибки;
* эффективность системы подразумевает, что при функционировании оптимальным образом используются имеющиеся в ее распоряжении ресурсы (время, память);
* надежность системы означает, что она должна предотвращать концептуальные ошибки, ошибки в проектировании и реализации, ошибки, возникающие при функционировании системы;
* понимаемость является мостом между конкретной проблемной областью и соответствующим решением. Для того чтобы система была понимаемой, она должна быть прозрачной.
По мере выполнения работ необходимо придерживаться определенного набора принципов, которые обеспечивают достижение поставленных целей:
* абстракция – выделение существенных свойств с игнорированием несущественных деталей. По мере декомпозиции решения на отдельные компоненты каждый из них становится частью абстракции на соответствующем уровне. Абстрагирование применяется и к данным и к алгоритмам. На любом уровне абстракции могут фиксироваться абстрактные типы данных, каждый из которых характеризуется множеством значений и множеством операций, применимых к любому объекту данного типа;
|
|
|
* сокрытие (упрятывание) информации имеет целью сделать недоступными детали, которые могут повлиять на остальные, более существенные части системы. Упрятывание информации обычно скрывает реализацию объекта или операции и позволяет фиксировать внимание на более высоком уровне абстракции. Сокрытие проектных решений нижнего уровня оберегает стратегию принятия решений верхнего уровня от влияния деталей. Абстракция и сокрытие информации способствует модифицируемости и понимаемости ПО;
* модульность реализуется целенаправленным конструированием. Модули могут быть функциональными (процедурно-ориентированными) или декларативными (объектно-ориентированными). Связность модулей определяется как мера их взаимной зависимости. В идеале должны разрабатываться слабосвязанные модули;
* локализация помогает создавать слабо связанные и весьма прочные модули. По отношению к целям технологии разработки ПО принципы модульности и локализации прямо способствуют достижению модифицируемости, надежности и понимаемости.
Абстракция и модульность считаются наиболее важными принципами, используемыми для управления сложностью систем ПО. Но они не являются достаточными, потому что не гарантируют получения согласованных и правильных систем. Для обеспечения этих свойств необходимо привлекать принципы единообразия, полноты и подтверждаемости.
8.2. Технология и инструментарий разработки
программных средств
|
|
|
|
|
|
|
|
|
Рис. 8.1. Общая структура типовой технологической системы поддержки разработки ПС
Новой ветвью в технологии разработки ПО является CASE-технология (Computer Aided Software Engineering). Первоначально CASE-технология появилась в проектах создания систем обработки данных. Все средства поддержки CASE-технологии делятся на две группы: CASE-Tool Kits и CASE-Work Benches. Русских эквивалентов нет, но первую группу называют «инструментальные сундучки» (технологические пакеты),
а вторую «станки для производства программ» (технологические
линии) (рис.8.2).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Рис. 8.2. Типовая система поддержки CASE-технологии
Стиль программирования в ИИ-системах существенно отличается от стиля программирования с использованием обычных алгоритмических языков [9]. В табл. 2 приведены соответствующие сравнительные характеристики.
Таблица 2
| Характеристики программирования | Программирование в ИИ-системах | Традиционное программирование |
| Тип обработки | Символьная | Числовая |
| Методы | Эвристический поиск | Алгоритм |
| Задание шагов решения | Неявное | Точное |
| Искомое решение | Удовлетворительное | Оптимальное |
| Управление и данные | Перемешаны | Разделены |
| Знания | Неточные | Точные |
| Модификации | Частые | Редкие |
Разработка системы ИИ начинается с формирования полных, непротиворечивых и однозначных требований. При проектировании используются принципы технологии разработки ПО: сокрытие информации, локализация и модульность. Система ИИ проектируется как композиция уровней. Любой уровень чувствителен лишь к нижестоящим уровням. Такое проектирование упрощает реализацию и тестирование системы ИИ.
Тестирование ПО ИИ отличается от тестирования обычных систем, так как для ИИ-систем характерно недетерминированное поведение вследствие использования стратегии разрешения конфликтов, зависящей от параметров периода исполнения программы. Поэтому единственным эффективным способом тестирования систем ИИ является прототипизация.
|
|
|
Фаза сопровождения, включающая выполнение самых различных модификаций системы, является важнейшим этапом процесса разработки любой системы, но имеет свою специфику для систем ИИ. Здесь БЗ - наиболее динамичный компонент и меняется в течение всего жизненного цикла. Поэтому сопровождение ИИ-систем является сложной проблемой. Приобретение знаний - ключевая задача во всех технологиях построения систем, основанных на знаниях. Производительность ИИ-систем находится в прямой зависимости от количества знаний, содержащихся в системе.
В области поддержки разработки ИИ-систем можно указать две тенденции:
* классический путь развития средств автоматизации программирования: автокоды => языки высокого уровня => языки сверхвысокого уровня => языки спецификаций. Условно эту тенденцию можно назвать восходящей стратегией в области создания средств автоматизации ИИ-систем;
* нисходящая тенденция, связывается со специальными средствами, уже изначально ориентированными на определенные классы задач и методы ИИ.
Эти тенденции, взаимно обогатив друг друга, должны привести к созданию мощного и гибкого инструментария интеллектуального программирования. В настоящее время усилия концентрируются в следующих направлениях:
1. Разработка систем построения знаний (СПЗ) путем прямого использования широко распространенных языков обработки символьной информации и языков программирования общего назначения [2].
2. Расширение базисных языков ИИ до СПЗ за счет специализированных библиотек и ППП.
3. Создание языков представления знаний (ЯПЗ), специально ориентированных на поддержку определенных формализмов и реализация соответствующих трансляторов с этих языков.
До недавнего времени наиболее популярным языком реализации
ИИ-систем был ЛИСП, разработанный под руководством Дж. Маккарти в Стэнфорде в начале 60-х годов XX века. Это был язык, который должен был стать следующим за ФОРТАНом шагом на пути автоматизации программирования. К концу 80-х годов ЛИСП был реализован на всех классах ЭВМ от персональных до высокопроизводительных вычислительных систем. В настоящее время фирмами США, Японии, Западной Европы выпускаются ЛИСП-машины.
|
|
|
Параллельно с ЛИСПом разрабатывались другие языки обработки символьной информации СНОБОЛ, РЕФАЛ. СНОБОЛ стал одной из первых практических реализаций развитой продукционной системы. РЕФАЛ вобрал в себя лучшие черты языков обработки символьной информации, активно используется концепция поиска по образцу.
В начале 70-х годов XX века появился ПРОЛОГ, разработанный в Марсельском университете. В японском проекте вычислительных систем V поколения ПРОЛОГ был выбран в качестве базового языка для машины вывода. ПРОЛОГ удобен, если число отношений не слишком велико и каждое отношение описывается небольшим числом альтернатив. Механизмы вывода обеспечивают поиск решения на основе перебора возможных альтернатив и декларативного возврата из тупиков. ЛИСП, СНОБОЛ, РЕФАЛ и ПРОЛОГ – языки общего назначения для задач ИИ. Вместе с тем в рамках развития средств автоматизации ПС, ориентированных на знания, были языки, сыгравшие важную роль в эволюции основных языков ИИ. Языки, основанные на программировании поисковых задач, – ПЛЭНЕР, КОННАЙВЕР, функционируют в ЛИСП-среде, реализуют представление данных в виде поисковых структур, развитые методы сопоставления образцов, поиск с возвратами и вызов процедур по образцу.
В 70-х годах в ИИ сформировались концепции представления знаний на основе семантических сетей и фреймов. Характерными чертами разработанных языков KRL, FRL были двухуровневое представление данных (абстрактная модель предметной области в виде иерархии множеств понятий и конкретная модель ситуаций как совокупность взаимосвязанных экземпляров этих понятий); представление связей между понятиями и закономерностей предметной области в виде присоединенных процедур; семантический подход к сопоставлению образцов и поиску по образцу.
Одним из распространенных ЯПЗ стал OPS5 (Official Production Systems), который в начале 80-х годов претендовал на роль языка стандарта в области представления знаний для ЭС. OPS5 – один из самых многочисленных на сегодняшний день ЯПЗ для ЭС, поддерживающий продукционный подход к представлению знаний. Модуль вывода решений в OPS5-системе состоит из трех блоков:
* отождествление, где осуществляется поиск подходящих правил;
* выбор исполняемого правила из конфликтного множества правил;
* исполнитель выбранного правила.
В OPS5 поддерживается единственная стратегия вывода решений – вывод, управляемый целями (обратный вывод).
|
|
|
В общем случае к ЯПЗ предъявляются требования:
* наличие простых и мощных средств представления сложноструктурированных и взаимосвязанных объектов;
* возможность отображения описаний объектов на разные виды памяти компьютера;
* наличие гибких средств управления выводом, учитывающих необходимость структурирования правил работы решателя;
* «прозрачность» системных механизмов для программиста, предполагающая возможность их доопределения и переопределения на уровне входного языка;
* возможность эффективной реализации.
Следующим этапом в развитии инструментальных средств стала ориентация на среды поддержки разработок ИИ-систем. Примерами инструментальных пакетов и систем оболочек служат EXSYS, GURU, однако наиболее распространенными являются ART, KEE, J2.
В середине 80-х годов система ART была одной из самых современных интегрированных сред, поддерживающих технологию проектирования систем, основанных на правилах. ART является пакетом разработчика. ART объединяет два главных формализма представления знаний: правила для процедурных знаний и фреймоподобные структуры для декларативных знаний. ART предлагает традиционные модели вывода: «от фактов к цели» и «от цели к фактам». Первые версии ART опирались на язык ЛИСП, последние – на язык С.
Главное отличие между формами представления знаний KEE и ART заключается в способе, которым эти интегрированные системы связывают фреймы и правила. KEE является средой, в основе которой лежат фреймы, а в ART – правила. Описание объектов и правил в KEE представляется в виде иерархии фреймов.
Инструментальная среда J2 является развитием ЭС реального времени PICON и самой мощной системой реального времени. Работает под управлением Windows NT, возможна работа с системой в режиме «клиент–сервер» в сети Internet. Основные функциональные возможности J2 связаны с поддержкой процессов слежения за множеством (порядка тысячи) одновременно изменяющихся параметров и обработкой изменений в режиме реального времени; проверкой нештатных ситуаций на управляемых объектах и принятием решений как в режиме ассистирования оператору, так и в автоматическом режиме. J2 является одной из первых инструментальных сред, поддерживающих разработку интегрированных ИИ-систем.
Системы Work Bench в контексте автоматизации программиро-
вания – это интегрированные инструментальные системы, поддерживающие весь цикл создания и сопровождения программ. К основным характеристикам Work Bench-систем относятся:
* использование определенной технологии проектирования на протяжении всего жизненного цикла (ЖЦ) системы;
* вертикальная интеграция инструментальных средств, обеспечивающая связи и совместимость по данным между различными инструментами, используемыми на различных стадиях создания системы;
* горизонтальная интеграция модулей и методов, используемых на одной и той же стадии проектирования;
* сбалансированность инструментария, то есть отсутствие дублирующих компонентов, необходимость и достаточность каждого инструмента.
К Work Bench-системам относятся VITAL, KEATS, SHELLY
|
|
|
