Страница 92

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

Исторически впервые автоматическое извлечение из экспертов конструктов и создание репертуарных решеток, необходимых для построения поля знаний [Гаврилова и др., 1988], было реализовано в системе PLANET [Shaw, 1982; Shaw et al., 1984]. Ряд алгоритмов и программ PLANET был впоследствии использован при создании системы ETS [Boose, 1985a; Boose, 1985b; Boose, 1985с; Boose, 1986], обеспечивающей не только автоматическое создание репертуарной решетки, но и преобразование ее в традиционные для ЭС формы представления БЗ. Потомками ETS являются система NeoETS [Boose et al., 1986] и интегрированная среда для извлечения экспертных знаний AQUINAS [Boose et al., 1987]. Дальнейшим развитием системы PLANET является интегрированная среда KITTEN [Gaines et al., 1986; Gaines et al., 1987], поддерживающая ряд методов извлечения знаний.

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

6.5. 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 подробнее. Выделение фрагментов здесь реализуется посредством указания (с помощью мыши) на область текста и задания имени понятия, релевантного отмеченному тексту. Имена понятий высвечены в виде элементов меню на том же экране, что и анализируемый текст. Нескольким фрагментам может быть поставлено в соответствие одно и то же понятие. Понятия могут быть заранее перечислены инженером знаний или генерироваться непосредственно в процессе анализа текста. В последнем случае возможно «заводить» имена понятий вручную либо воспользоваться лексическим анализатором.