Глава 8. Программный инструментарий разработки систем, основанных на знаниях

8.1. Цели и принципы технологии разработки
программных средств

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

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

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

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

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

По мере выполнения работ необходимо придерживаться определенного набора принципов, которые обеспечивают достижение поставленных целей:

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

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

* модульность реализуется целенаправленным конструированием. Модули могут быть функциональными (процедурно-ориентированными) или декларативными (объектно-ориентированными). Связность модулей определяется как мера их взаимной зависимости. В идеале должны разрабатываться слабосвязанные модули;

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

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

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

документиро-вания

Подсистема управления

Спецификация, тесты

Подсистема разработки и реализации

Подсистема отладки

СУБД

БД проекта

Подсистема документирования

Документация

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

Новой ветвью в технологии разработки ПО является CASE-технология (Computer Aided Software Engineering). Первоначально CASE-технология появилась в проектах создания систем обработки данных. Все средства поддержки CASE-технологии делятся на две группы: CASE-Tool Kits и CASE-Work Benches. Русских эквивалентов нет, но первую группу называют «инструментальные сундучки» (технологические пакеты),
а вторую «станки для производства программ» (технологические
линии) (рис.8.2).

перепроекти-рования

Обнаружение ошибок

Прототипирова-ние

Моделирование проектных решений

Подсистемы перепроектирования

Анализ и проектирование

CASE-средства

Генерация года

Сопровождение

Обработка экранных форм

Программирова-ние

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

Документирова-ние

Выполнение

Документаторы

Анализаторы программы

Реструкториза-торы

Рис. 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