6.5. WorkBench-системы

К

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

основным характеристикам WorkBench-систем относятся:

1. Использование определенной технологии проектирования на протяжении всего жизненного цикла целевого продукта.

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

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

4. Сбалансированность инструментария, то есть отсутствие дублирующих компонентов, «необходимость и достаточность» каждого инструмента.

Одна из систем данного типа разрабатывалась в рамках проекта VITAL [VITAL, 1990]. Отдельные стадии методологии поддерживаются здесь следующими средствами: анализ — подсистемой КАТ (Knowledge Acquisition ToolKit); проектирование — подсистемой FTDT (Functional and Technical Design Tool); кодирование знаний — языком представления знаний; проверка и верификация — V&VT (Validation and Verification Tool); поддержка и отладка — VT (Visualization Tool).

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

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

Проект VITAL, если так можно сказать, определил философию разработки WorkBench-систем. Ниже, в качестве примеров, рассматриваются две WorkBench-системы, KEATS [Motta et al., 1988] и Shelly [Bouchet et al, 1989], где эта философия нашла некоторое реальное воплощение.

Система KEATS (Knowledge Engineer's Assistant); [Motta et al., 1988; Motta et al, 1989] первоначально представляла собой набор инструментов, созданных для помощи инженерам знаний в проведении анализа предметных знаний и разработки концептуальной модели ПО (вот тут говорится про предметную область!!!). В первой версии системы, называемой KEATS-1 [Motta et al., 1988], были реализованы редактор текстов CREF (Cross Reference Editing Facility) и графический редактор GIS (Graphical Interface System), а также фрейм-ориентированный язык описания знаний KDL (Knowledge Description Language) и интерпретатор продукционных правил COPS (Context Oriented Production System).

Редактор текстов CREF помогает инженерам знаний провести анализ документов, имеющих текстовую форму, и допускает установление связей между фрагментами типа «ссылается», «обобщает», «заменяет», «предшествует».

Графический редактор GIS позволяет инженеру знаний быстро построить представление концептуальной модели ПО (то же самое). Элементами графического представления могут быть как фрагменты, выделенные посредством компонента CREF, так и произвольные объекты исследуемой ПО (то же самое). Различаются два вида графических элементов: классы (изображаются овалом) и примеры (изображаются прямоугольником). Разные типы отношений между элементами показываются разными стрелками. В KEATS-1 такое графическое представление автоматически транслируется в текст на языке KDL. Поддерживается и обратное отображение.

В работе [Motta et al., 1989] были проанализированы ограничения CREF и GIS как инструментальных средств приобретения знаний. Анализ текстовых документов в CREF и построение концептуальной модели ПО (то же самое), поддерживаемое GIS, являются хотя и разными, но тесно связанными видами деятельности. Но поскольку в KEATS-1 они обеспечиваются разными программными системами и автоматического интерфейса между ними нет, то построение концептуальной модели, элементами которой были бы сущности, выделенные в процессе анализа, требует от инженера по знаниям дополнительных усилий. Поэтому естественно иметь такую инструментальную поддержку, которая позволяла бы инженеру знаний строить концептуальную модель, исходя из информации, содержащейся в текстовых документах. Требуемая инструментальная поддержка была реализована в подсистеме ACQUIST системы KEATS-2 [Motta et al., 1989].

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

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

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

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

Новая версия системы KEATS, которая была развитием предыдущей, разработана в лаборатории когнитологии Открытого университета Великобритании и финансировалась British Telecom. Corp. По определению авторов, KEATS — программное окружение, поддерживающее построение систем, основанных на знаниях. Основное назначение — поддержка разработки ЭС на критических стадиях — приобретение и кодирование знаний, отладка БЗ [Motta et.al, 1989].

Данная система поддерживает не только отдельные методы моделирования, но и обеспечивает интегрированную программную поддержку взаимосвязанных моделей знаний. Основные компоненты KEATS: ACQUIST — средство фрагмен-тирования текстовых источников знаний, которое позволяет разбить текст или протокол беседы с экспертом на множество взаимосвязанных, аннотированных фрагментов (гипертекст) и создать концепты (понятия); FLIK — фреймово-ориентированный язык представления знаний; GIS — графический интерфейс, используемый как для создания гипертекстов и концептуальных моделей с помощью ACQUIST, так и для проектирования фреймовых систем на основе языка FLIK; ERI — базисный интерпретатор правил, обеспечивающий прямой и обратный вывод по продукциям; TRI — визуализирующий интерпретатор правил, демонстрирующий трассу выполнения продукций в виде мозаичной таблицы, а также графически отражающий активные правила, фреймы и конфликтное множество; Tables — интерфейс манипулирования таблицами, который может использоваться вместе со всеми моделями знаний, поддерживаемыми в KEATS; CS — язык описания и распостранения ограничений; TMS — немонотонная система сопровождения истинности, тесно связанная с ERI, FLIK и CS, а также TMV — графический интерфейс подсистемы TMS, обеспечивающий визуализацию на И/ИЛИ дереве значения истинности или ложности заключений в зависимости от посылок.

В системе KEATS концептуальные модели могут создаваться с помощью методов «сверху—вниз» и «снизу—вверх». Первый цодход используется при четко определенной задаче и наличии специфической модели в ПО (то же самое), например в задачах диагностики. Специфическая модель может быть сразу же отражена в виде таблиц и концептуальных моделей и имплантирована в будущую ЭС с помощью GIS и Tables. Когда приобретение знаний основывается не на четко определенной модели ПО, а, например, на протоколе опроса эксперта, используется второй подход. Текстовые данные анализируются и фрагментируются с помощью ACQUIST, и выделяются концепты. Созданная модель затем визуализируется с помощью GIS.

Интеллектуальная система Shelly [Bouchet et al., 1989] является представителем следующего поколения программной поддержки KADS-методологии. Она способна не только обеспечивать выполнение работ, предусматриваемых методологией, но и советовать инженеру знаний, когда и как выполнять ту или иную работу, а также объяснять, почему это необходимо. Система Shelly разрабатывалась как интегрированная программная среда, поддерживающая весь процесс создания ЭС, если он осуществляется в соответствии с KADS-методологией. И процесс разработки самой системы Shelly является примером практического ее применения.

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

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

Основное проектное решение при создании системы Shelly состоит в том, что каждому виду деятельности здесь соответствует свое инструментальное средство AST (Activity Support Tool).

Центральным модулем в Shelly является управляющий модуль «Advice & Guidance». Он предназначен для информирования пользователя о текущем состоянии разработки его прикладной ЭС; обеспечивает ответы на конкретные вопросы пользователя; рекомендует пользователю дальнейшие действия и активирует соответствующий модуль AST; предупреждает пользователя о нарушении им KADS-методологии.

Модуль «Advice & Guidance» может функционировать в двух режимах, различающихся степенью сложности, Первый, простой режим, «локального совета», активируется посредством явного запроса, поступившего от пользователя. Во втором режиме пользователь может получить рекомендации относительно того, как наиболее эффективно работать с Shelly. Система будет постоянно следить за деятельностью пользователя и при необходимости предупредит его и объяснит, почему рекомендуется выполнять ту или иную работу.

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

Пример 6.1

описание: <текст>

цель: <текст>

когда: <текст>

как: <текст>

вход: <объект КАВ8-методологии>

выход: <объект КАВ8-методологии>

связан с: <вид деятельности>

поддерживается: AST

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

Пример 6.2

ЕСЛИ <деятельиость1> по проекту X = «завершена» И

<деятелыюсть2> по проекту X = «завершена»

ТО возможно начать <деятельностьЗ> по проекту X.

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

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