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-систем. Ниже, в качестве примеров, рассматриваются две Work­Bench-системы, 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 & Gui­dance». Он предназначен для информирования пользователя о текущем состоя­нии разработки его прикладной ЭС; обеспечивает ответы на конкретные вопросы пользователя; рекомендует пользователю дальнейшие действия и активирует со­ответствующий модуль AST; предупреждает пользователя о нарушении им KADS-методологии.

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

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

Пример 6.1 описание: <текст>

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

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

как: <текст>

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

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

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

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

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

Пример 6.2

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

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

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

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

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

Дата добавления: 2015-07-02