Визуализация экспертных систем

Более удачный вариант решения той же задачи показан на рис. 102. Учебная экспертная дракон-система работает следующим образом. После запуска системы рабочая точка процесса начинает двигаться от иконы “заголовок” к иконе “конец”. По ходу ее движения иконы и соединительные линии вспыхивают и горят на экране более ярким светом, выделяя пройденную часть пути. Когда процесс дошел до иконы-вопрос “При взаимодействии с Н2SO4выделяется бурый газ?”, данная икона начинает мерцать, привлекая к себе внимание и требуя ответа. Реагируя на это событие, ученик подводит курсор к нужному ответу (да или нет) и щелкает клавишей мыши. Икона перестает мерцать и (при ответе “да”) загорается путь, ведущий к иконе-вопрос “При взаимодействии со щелочью ощущается запах аммиака?”, которая начинает мерцать. Далее события повторяются, пока на экране не загорится искомое название удобрения.

Таким образом, дракон-система выполняет те же самые функции, что и система на БЕЙСИКЕ. Вместе с тем она обладает рядом преимуществ.

! Программа на БЕЙСИКЕ содержит 790 символов (не считая пробелов), из которых только 488 символов (60%) описывают задачу на естественном языке, а остальные 302 (40%) представляют собой набор иероглифов — загадочный текст на птичьем языке программирования, который все нормальные люди (не программисты) воспринимают с неудовольствием. В дракон-схеме на рис. 102 повод для недовольства исчезает, “птичья абракадабра” полностью отсутствует, а все необходимые функции тем не менее выполняются. Становится очевидным, что “программные иероглифы” являются паразитными, избыточными и даже вредными, поскольку они работают не на пользователя (которому они не нужны), а сами на себя. В данном случае сущность эргономизации состоит в полном отказе от использования “птичьей абракадабры”.

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

 

1) постановка задачи;

2) описание действий с исследуемым веществом и реактивами;

3) логический анализ результатов опыта.

Недостаток программы на БЕЙСИКЕ в том, что она освещает лишь последнюю часть и “прячет от читателя” две первых. Дракон-сис­тема свободна от этого дефекта: в первой ветке даны постановка задачи (икона “комментарий”) и описание последовательности ручных манипуляций (четыре иконы “действие”), во второй ветке демонстрируется логический анализ и получение ответа.

Исключительно важно, что все три части проблемы предъявляются зрителю в одном визуальном поле. Благодаря этому обеспечивается симультанизация восприятия и улучшение работы ума.

! Программа на БЕЙСИКЕ — пример плохой (неэргономичной) экспертной системы, которая общается с пользователем через узкую “замочную скважину”, сквозь которую виден один-единственный вопрос и больше ничего. Тем самым бейсик-система не дает возможности человеку одновременно охватить единым взором и логические детали, и общую картину логического вывода, фактически превращая пользователя в какого-то пасынка или даже дурачка, от которого скрывают все самое интересное.

! Хорошо известно, что пользователю далеко не безразлично, каким образом экспертная система приходит к своему решению. Идя навстречу таким пожеланиям, современные экспертные системы помогают пользователю не только принимать решения, но и позволяют выявить мотивы их принятия через систему объяснения. Более того, специалисты считают, что от наличия или отсутствия в системе объяснительной функции зависит право этой системы называться экспертной. Исходя из этого, многие системы разрешают пользователю задавать вопрос “Почему?”, после чего “раскрывают карты” и в словесной форме показывают пользователю ход своих рассуждений. Это хорошо, но мало. В ряде приложений идеальным решением можно назвать такое, при котором система предъявляет пользователю всю панораму возможных логических выводов, на которой выделяется (яркостью или цветом) маршрут цепочки конкретных умозаключений, ведущих к выбранному ответу. ДРАКОН-система реализует именно этот идеальный подход (рис. 102).

Визуализация описания
технологических процессов

На рис. 103 представлено упрощенное описание технологического процесса изготовления фруктовых консервов из косточковых плодов (автор технологии Е. Свешникова). Реальный технологический процесс может быть очень сложным. Обычно его описывают как головной процесс, содержащий большое число вставок. В качестве примера в головном процессе на рис. 103 показана вставка “Изготовление сиропа и мари­нада”, раскрытая на рис. 104.

В реальном техпроцессе часто встречаются одновременно протекающие процессы. Для их изображения на языке ДРАКОН применяется не только икона “параллельный процесс”, но и другие средства (учитывающие специфику технологических процессов), которые в данной книге не рассматриваются.

Дракон-схемы технологических процессов могут найти применение в следующих случаях:

! создание наглядных плакатов, дающих целостное представление о процессе во всей его многосложности и используемых в качестве демонстрационных материалов; при этом в иконе “комментарий” могут помещаться чертежи, фотографии, схемы установок, станков, сетей трубопроводов и другого оборудования;

! выпуск технологической документации;

! проектирование и моделирование технологических процессов;

! создание визуальной базы данных о техпроцессах;

! создание экспертных систем для проектирования технологических процессов, а также тренажеров для эксплуатационников;

! изготовление альбомов и каталогов технологических процессов для обучения или рекламы; можно рекомендовать формат бумажной стра­ницы альбома А3, имея в виду, что оригинал-макеты альбомов готовятся на лазерном принтере формата А3.

Что такое методология?

Джеймс Мартин подчеркивает необходимость различать два понятия: методика (technique) и методология (methodology).

Методика — это способ выполнения одной операции. Например, правила составления схем потоков данных — это методика.

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

Визуализация методологий

Иногда высказывают мнение, что язык ДРАКОН хорошо описывает простые задачи и непригоден для изображения сложных проблем. Это неверно. ДРАКОН специально сконструирован, чтобы облегчить формализацию широкого спектра задач, включая самые сложные. Более того, чем сложнее проблема, тем больше выигрыш от использования языка ДРАКОН.

Чтобы убедиться в этом, рассмотрим методологию проектирования атомного реактора. Ясно, что это грандиозная, “запредельная” по сложности проблема. Целостный взгляд на методологию представлен на рис. 105. Дракон-схема на рис. 105 содержит большое число вставок, для обозначения которых в данном случае целесообразно ввести термин алгоритм-концепция. Например, во второй и четвертой ветке на рис. 105 имеются иконы-вставки “Расчет стационарных параметров первого контура атомного реактора” и “Расчет реактивностных аварий атомного реактора”. Соответствующие им алгоритмы-концепции показаны на рис. 106 и 107[19].

Рис. 105—107 убедительно демонстрируют, что любую, сколь угодно сложную методологию можно изобразить с помощью простого и единообразного приема, который можно охарактеризовать как наглядную декомпозицию. Верхний уровень иерархии, показанный на рис. 105, можно рассматривать как вершину гигантской пирамиды, откуда открывается взгляд на проблему с высоты птичьего полета. Там же перечисляются все алгоритмы-концепции второго уровня, которые в нашей воображаемой пирамиде расположены на один шаг “ближе к земле”. Рассматривая алгоритм второго уровня (изображенные на рис. 106 и 107), легко заметить, что в них указываются алгоритмы-концепции третьего уровня, которые находятся еще ближе к земле, т. е. дают более детальное знакомство с проблемой. Постепенно спускаясь с вершины пирамиды к ее основанию, мы наблюдаем последовательную декомпозицию сложной проблемы на все более мелкие и подробные детали, которые
в конечном итоге (когда мы спустимся “на уровень земли”) дадут исчерпывающее и полное описание методологии как императивной про­блемы. При необходимости ее можно дополнить соответствующими декларативными описаниями.

Важным достоинством является тот факт, что язык не зависит от уровня иерархии — он один и тот же и на самом верху и у основания пирамиды. Благодаря этому достигается резкое упрощение описания задач любой сложности; в итоге “уму непостижимая” проблема превращается в относительно простую, ясную и наглядную.

Насколько известно автору, до сих пор практически отсутствовали эффективные эргономичные изобразительные средства, позволяющие одновременно решать две задачи: формализацию и визуализацию методологий. По этой причине целостный взгляд на методологию, как на детерминированный многоступенчатый процесс, имеющий начало и конец, по сути дела был недоступен широкому кругу специалистов и учащихся, оставаясь достоянием узкой группы суперспециалистов, которые “все держат в голове”. Из-за этого остальным участникам сложного проекта вынужденно отводилась роль винтиков творческого организма, которые должны знать свой “шесток”, но которым “не поло­жено” иметь целостное панорамное видение процесса во всей его многосложности. Язык ДРАКОН позволяет сделать важный шаг к устранению этого недостатка, более эффективно организовать совместную работу участников сложного проекта и более разумно использовать интеллектуальные ресурсы их коллективного мозга.

 

Система “Человек—машина”

В настоящем параграфе[20] обосновывается целесообразность использования языка ДРАКОН для формализованного описания систем “человек—машина”. Рассмотрим для примера разработку системы “экипаж—вер­толет”. Описание этой системы необходимо иметь при проектировании вертолета на этапе эскизного проекта для достижения трех целей.

Во-первых, для проведения эргономического анализа системы “человек—машина” при выборе вариантов:

! распределения функций между человеком и машиной;

! распределения функций между членами экипажа вертолета;

! состава оборудования;

! численности экипажа.

 

Во-вторых, для обеспечения специалистов информацией о работе различных подсистем системы “человек—машина” в штатных и аварийных условиях работы. В-третьих, для обучения операторов работе с системой.

В настоящее время при проектировании летательных аппаратов описание алгоритма работы системы “человек—машина” делается в текстовой форме в виде документа, который называется “Руководство по летной эксплуатации”, форма которого определена государственным стандартом. Этот документ выпускается слишком поздно — после окончания рабочего проектирования и обычно бывает приурочен к началу летных испытаний. Он представляет собой констатацию сложившихся в ходе проектирования алгоритмов работы системы “человек—машина” и не предназначен для достижения первых двух целей. Кроме того, текстовая форма документа не отвечает принципам симультанного восприятия, что затрудняет его использование для обучения персонала.

В связи с этим была предпринята попытка применить для решения задачи язык ДРАКОН. В частности, была разработана детальная дракон-схема, описывающая работу системы “экипаж—вертолет” при возникновении аварийной ситуации в воздухе — пожаре правого двигателя. Анализ полученных результатов позволяет сделать вывод о полезности такого описания: оно сочетается с требованиями, предъявляемыми к математическому моделированию системы “человек—машина”, определению временной структуры деятельности членов экипажа, использованию микроструктурного анализа деятельности и т. д. Можно утверждать, что создание библиотеки дракон-схем проектируемой системы “человек—машина” — необходимый этап детального эргономического анализа при создании пилотируемых летательных аппаратов.