Этап 6. Опытная эксплуатация

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

Процесс разработки экспертной системы не сводится к строгой последовательности перечисленных выше этапов. В ходе работ приходится неоднократно возвращаться на более ранние этапы и пересматривать принятые там решения.

Этап I. Идентификация

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

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

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

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

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

· общие характеристики задачи;

· подзадачи, выделяемые внутри данной задачи;

· ключевые понятия (объекты), характеристики и отношения;

· входные (выходные) данные;

· предположительный вид решения;

· знания, релевантные решаемой задаче;

· примеры (тесты) решения задачи.

 

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

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

1. Какие задачи предлагается решать экспертной системе?

2. Как эти задачи могут быть охарактеризованы и определены?

3. На какие подзадачи разбивается каждая задача, какие данные они используют?

4. Какие ситуации препятствуют решению?

5. Как эти препятствия будут влиять на экспертную систему?

6. Ряд других вопросов.

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

 

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

· источники знаний,

· время разработки,

· вычислительные средства (возможности ЭВМ и программного инструментария)

· и объем финансирования.

 

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

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

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

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

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

Этап II. Концептуализация

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

На этом этапе определяются следующие особенности задачи:

· типы доступных данных;

· исходные и выводимые данные;

· подзадачи общей задачи;

· используемые стратегии и гипотезы;

· виды взаимосвязей между объектами проблемной области;

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

· процессы, используемые в ходе решения задачи;

· типы ограничений, накладываемых на процессы, используемые в ходе решения;

· состав знаний, используемых для решения задачи и для объяснения решения.

 

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

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

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

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

· диаграммы «сущность-связь», например нотация IDEF1X;

· диаграммы потоков данных, например нотация DFD;

· диаграммы «состояния-переходы», например нотация UML.

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

Контекстная диаграмма в сочетании с перечнем системных требований стремится ответить на вопрос: «Что делает система?», причем дает только частичный ответ.

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

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

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

Этап III. Формализация

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

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

1) структуризация общей задачи на связанные подзадачи;

2) структуризация предметной области на основе иерархии классов;

3) структуризация знаний на декларативные и процедурные;

4) структуризация приложения на основе иерархии «часть/целое».