2. Технология быстрого прототипирования

Суть технологии состоит в том, что разработчики не пытаются сразу построить конечный продукт. На начальном этапе они создают прототип (прототипы) ЭС. Прототипы должны удовлетворять двум противоречивым требованиям: с одной стороны, они должны решать типичные задачи конкретного приложения, а с другой- время и трудоемкость их разработки должны быть весьма незначительны, чтобы можно было максимально запараллелить процесс накопления и отладки знаний (осуществляемый экспертом) с процессом выбора (разработки) программных средств (осуществляемым инженером по знаниям и программистом). Для удовлетворения указанным требованиям, как правило, при создании прототипа используются разнообразные средства, ускоряющие процесс проектирования (например,- BCB,- как RAD среда программирования).

Прототип должен продемонстрировать пригодность методов инженерии знаний для данного приложения. В случае успеха эксперт с помощью инженера по знаниям расширяет знания прототипа о проблемной области. При неудаче может потребоваться разработка нового прототипа или разработчики могут прийти к выводу о непригодности методов ЭС для данного приложения. По мере увеличения знаний прототип может достигнуть такого состояния, когда он успешно решает все задачи данного приложения. Преобразование прототипа ЭС в конечный продукт обычно приводит к перепрограммированию ЭС на языках низкого уровня, обеспечивающих как увеличение быстродействия ЭС, так и уменьшение требуемой памяти. Трудоемкость и время создания ЭС в значительной степени зависят от типа используемого инструментария.

2.1 Идентификация проблемы

Идентификация проблемы- ознакомление (обучение) членов коллектива разработчиков и создание предварительной (неформальной) формулировки проблемы.

Уточняется задача, планируется ход разработки прототипов экспертной системы, определяются:

·      необходимые ресурсы (время, люди, ЭВМ, и т.п.);

·        источники знаний (книги, эксперты);

·        имеющиеся аналогичные экспертные системы;

·        цели (распространение опыта, автоматизация рутинных действий);

·        подклассы решаемых задач…

В дальнейшем начинается разработка БЗ.

2.2 Получение знаний

Получение знаний - это процесс теоретически обоснованного извлечения знаний с использованием одного или группы практических методов извлечения. Теоретические основы извлечения знаний - включают совокупность стратегий получения знаний и аспектов извлечения знаний (по слоям). Практические методы: текстологические, коммуникативные (активные, пассивные).

Наибольший эффект достигается, когда методы применяются осознанно и в комбинации, например:

q  Анализируется литература экспертов (текстологический метод):

§  Формируется "черновик" по предметной области;

§ Составляется вопрос- ответная структура для БЗ;

§  Формируется анкета в соответствии с БЗ;

§  Эксперт заполняет анкету;

§  Аналитиком проводится анализ ответов эксперта;

q  В режиме интервью, диалога или игры (активные индивидуальные коммуникативные методы):

§  Эксперт и аналитик проводят совместный анализ материалов;

§  Исправляются ошибки в БЗ.

q  Инженер по знаниям вносит исправления.

Под "черновиком" здесь понимается текст, прошедший следующий алгоритм: накопление необходимой литературы по предметной области; выбор текста для извлечения знаний; первое знакомство с текстом (ознакомление в целом) формирование предварительной гипотезы о структуре и содержании текста; выделение ключевых понятий (адекватно и наиболее полно передающих смысл текста) в процессе внимательного чтения, так называемая "компрессия текста"; определение связности в рамках текста, составление реферата ("сжатого текста"); формирование вопросно-ответной структуры для базы знаний, так называемого поля знаний. В процессе формирования базы знаний важно помнить о теоретических аспектах извлечения знаний, чтобы максимально обеспечить передачу знаний от эксперта к испытуемому.

2.3 Концептуализация и структурирование знаний

Структурирование- разработка неформального описания предметной области в виде графа, таблицы, диаграммы или текста, которое отражает основные концепции и взаимосвязи между понятиями предметной области.

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

·      Терминология;

·        Список основных понятий и атрибутов;

·        Отношения между понятиями

·        Структура входной и выходной информации;

·        Стратегии приятия решений;

·        Ограничения стратегий.

2.4 Формализация знаний

Формализация знаний- процесс разработки базы знаний на языке представления знаний, который соответствует структуре поля знаний и позволяет реализовать прототип на следующей стадии программной реализации.

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

Осуществляется выбор модели представления знаний:

·      Логические модели (исчисление предикатами 1-го порядка)

·        Продукционные модели (прямой, обратный вывод);

·        Семантические сети

·        Фреймы

·        ООП

2.5 Реализация (выполнение)

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

Создается прототип экспертной системы, включающий базу знаний и остальные блоки, при помощи:

·      Программирование на высокоуровневых языках: C++, Pascal;

·        Программирование на специализированных языках ИИ: LISP.

·        Использование инструментальных средств разработки ЭС: G2.

·        Использование "пустышек" и "оболочек" ЭС: Exsys, Kappa.

2.6 Опытная эксплуатация

На этапе опытной эксплуатации (внедрения) проверяется пригодность ЭС для конечного пользователя. Система решает максимально возможное количество задач при работе с различными пользователями.

2.7 Тестирование (диагностика)

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

2.8 Получение результата в виде прототипа

Технология гарантированно обеспечивает получение прототипа как результата разработки.

Выделяют:

2.9 Оценка, стыковка, сопровождение системы

Оценка- после получения промышленной ЭС осуществляется анализ эффективности с использованием:

·      Критерии пользователей (понятность, прозрачность, удобство интерфейсных компонентов в процессе эксплуатации);

·        Критерии экспертов приглашенных со стороны (оценка адекватности решений, сравнение естественного и искусственного решений, объяснений);

·        Критерии коллектива разработчиков (эффективность реализации, производительность, время отклика, дизайн, широта и глубина охвата предметной области, непротиворечивость БЗ, наличие нештатных ситуаций)

Стыковка- анализ среды функционирования системы и интеграция ЭС в эту среду.

Поддержка- обслуживание системы в процессе эксплуатации с целью поддержания и повышения ее функционирования.

Приложение

1. Идентификация проблемы

На этапе идентификации определяются задачи, участники процесса разработки и их роли, ресурсы и цели. Определение участников и их ролей сводится к определению количества экспертов и инженеров по знаниям, а также формы их взаимоотношений. Обычно в основном цикле разработки ЭС участвуют не менее трех-четырех человек (один эксперт, один или два инженера по знаниям и один программист, привлекаемый для модификации и согласования инструментальных средств). К процессу разработки ЭС могут привлекаться и другие участники. Например, инженер по знаниям может привлекать других экспертов для того, чтобы убедиться в правильности своего понимания основного эксперта; представительности тестов, демонстрирующих особенности рассматриваемой задачи; совпадении взглядов различных экспертов на качество предлагаемых решений. Формы взаимоотношений экспертов и инженеров следующие: эксперт исполняет роль информирующего или эксперт выполняет роль учителя, а инженер - ученика. По нашему мнению, форма "учитель - ученик" больше соответствует методологии ЭС. Вне зависимости от выбранной формы взаимоотношений инженер по знаниям должен быть готов и способен изучать специфические особенности той проблемной области, в рамках которой предстоит работать создаваемой ЭС. Несмотря на то, что основу знаний ЭС будут составлять знания эксперта, для достижения успеха инженер по знаниям должен использовать дополнительные источники знаний в виде книг, инструкций, которые ему рекомендовал эксперт.

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

Цель этапа идентификации задачи состоит в том, чтобы характеризовать задачу и структуру поддерживающих ее знаний и приступить к работе по созданию базы знаний. Если исходная задача оказывается слишком сложной с учетом имеющихся ресурсов, то этап идентификации может потребовать нескольких итераций.

В ходе идентификации задачи необходимо ответить на следующие вопросы: "Какие задачи предлагается решать экспертной системе?", "Как эти задачи могут быть охарактеризованы и определены ?", " На какие подзадачи разбивается каждая задача, какие данные они используют ?", "Какие ситуации препятствуют решению ?", "Как эти препятствия будут влиять на экспертную систему ?"

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

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

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

Задача идентификации целей заключается в формулировании в явном виде целей построения экспертной системы. При этом важно отличать цели, ради которых строится система, от задач, которые она должна решать. Примерами возможных целей являются: формализация неформальных знаний экспертов; улучшение качества решений, принимаемых экспертом; автоматизация рутинных аспектов работы эксперта (пользователя); тиражирование знаний эксперта.

На первом этапе инженер по знаниям должен ответить на основной вопрос: "Подходят ли методы инженерии знаний для решения предложенной задачи?" Для положительного ответа на данный вопрос необходимо, чтобы задача относилась к достаточно узкой, специальной области знаний и не требовала для своего решения использования того, что принято называть здравым смыслом, поскольку методы искусственного интеллекта не дают возможности формализовать это понятие. Кроме того, качество ЭС зависит в конечном счете от уровня сложности решаемой задачи и ясности ее формулировки. Задача не должна быть ни слишком легкой, ни слишком трудной. Обычно число связанных понятий, релевантных проблеме, должно составлять несколько сотен. Говоря другими словами, назначение экспертной системы в том, чтобы решать некоторую задачу из данной области, а не в том, чтобы быть экспертом в этой области.

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

На этапе концептуализации эксперт и инженер по знаниям выделяют ключевые понятия, отношения и характеристики, необходимые для описания процесса решения задачи. На этом этапе определяются следующие особенности задачи: типы доступных данных; исходные и выводимые данные; подзадачи общей задачи; используемые стратегии и гипотезы; виды взаимосвязей между объектами проблемной области; типы используемых отношений (иерархия, причина/следствие, часть/целое и т.п.); процессы, используемые в ходе решения задачи; типы ограничений, накладываемых на процессы, используемые в ходе решения; состав знаний, используемых для решения задачи и для объяснения решения.

Для определения перечисленных характеристик задачи целесообразно составить детальный протокол действий и рассуждений эксперта в процессе решения хотя бы одной конкретной задачи. Такой протокол обеспечивает инженера по знаниям словарем терминов (объектов) и некоторым приблизительным представлением о тех стратегия которые использует эксперт. Кроме того, протокол помогает ответит на многие другие вопросы, возникающие в ходе разработки. На этом этапе инженер по знаниям рассматривает вопросы, относящиеся представлению знаний и методам решения, но говорить о выборе конкретных способов и методов здесь еще рано.

Адекватным средством для выделения ключевых понятий, отношений и характеристик являются диаграммы, которые используют практически все современные ИС.

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

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

К числу базовых типов диаграмм относятся:

·      контекстные диаграммы (структурно-функциональные схемы);

·        диаграммы "сущность-связь";

·        диаграммы потоков данных;

·        диаграммы "состояния-переходы".