Приложение 3.
Каталог Примеров по формализации знаний

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

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

Здесь приводятся примеры визуализации задач с применением частных языков из числа рассмотренных в данном документе.

Управление двумя клапанами (визуализация автоматной спецификации процессов)

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

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

Предполагается, что рандеву-оператор каждого типа на Оберон-07 реализуется как процедура, т.к. такого оператора в языке нет (а есть в Promela).

С учётом этого получаем дракон-модель, показанную ниже:

Визуализация автоматной спецификации процессов

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

Автоматы в данном случае информатически строги, т.е. условия переходов непротиворечивы и полны в каждом состоянии². Поэтому визуализация логики состояний тривиальна; мы просто вводим по условию (единственному и определяющему пару переходов) единственную развилку с заземлением плеч; по ложности «петляем» на то же состояние (организуя одноветочный цикл), по истинности переходим на следующее.

Для обозначения одного из веточных циклов использован специфический индекс 'Ц'. Вообще-то это необязательно; в заземлённой лиане можно употребить уже введённый для ветки назначения индекс '1'. В данном случае так сделано, чтобы явно выделить конечную вершину следования; она является конечной вершиной «зацикленного» силуэта в целом как маршрутной схемы в смысле определения в /3, п. 3.1.1/. Содержательно на ней заканчивается шампур схемы «зацикленный силуэт» (как цепочка шампуров веток, связанных силуэтными переходами вперёд по правилу «чем правее, тем позже») и происходит возврат в начало шампура, реализующий логику «риторического вопроса», обсуждённую в /3, п/п 2.3.1.1/.

Заметим, что в модели для действий над клапанами (и для эффекторных переменных) употребляется термин «<от|за>пирать», а для состояний клапанов (и рецепторных переменных) – «<от|за>крывать». Тем самым эти категории (соответствующие прямой и обратной связям в контуре управления) дополнительно разделяются для читателя.

Если по каким-то причинам нужно выдавать сигналы приводам только в случае смены воздействия, то нужно ввести в состояния 2 и 4 анализ текущего выдаваемого сигнала (определяемого значением, хранимым в порте), чтобы не выводить в случае совпадения с требуемым. Это показано как варианты автоматных визуалов; т.к. прекращение текущего воздействия является разовым событием (не повторяется более одного такта), то для него это не требуется.

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

Конечно, при реализации механизма каталогизации в РДП-редакторе графит-синтаксис м.б. и иным.

Далее мы можем реализовать дракон-модель. При инженерной технологии разработки составляется текстовая модель для проверки, напр. на языке Promela. В Promela строки нумеруются, поэтому разрешённые (силуэтные) БП будут использовать уже номера строк.

Используя РДП-редактор, поддерживающий возможности Promela полностью (включая объявление классов в деклар-подъязыке), можно генерировать текст непосредственно по графит-Promela-модели.

Задачу можно использовать как основу лабораторной работы на проверку модели.

В полном соответствии с предложениями из /Поликарпова, Шалыто, с. 69/, Promela-модель может содержать одно определение класса автоматных алгопроцессов (как Proctype Автомат, абстрагированный по сущностям), из которого порождается два экземпляра (Автомат1 и Автомат2, конкретизируемые подстановкой имён сущностей). Однако также возможно и напрямую закодировать вышеприведённую графит-модель без унификации автоматных алгопроцессов.

Программирование должно проводиться на ТЯП, не имеющих оператора БП (в отличие от Promela); поэтому нужно позаботиться о согласовании модели с ними.

Учитывая «несилуэтность» реальных ТЯП, приведём дракон-силуэты к графит-СЦД по методу, описанному для этого примера. Только после этого можно запрограммировать модель, напр., на ТЯП Оберон-07. Результат приведения показан ниже:

Визуализация автоматной спецификации процессов через СЦД

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

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

Отметим, что цикл Дейкстры записан в прямой диоформе согласно определению в /3, п/п 2.2.3.1/. Для ЦД с выходом в такой записи было бы невозможно избежать пересечения (выходного шампура с петлёй цикла); однако т.к. у нас выхода нет (СЦД является объемлющей конструкцией алгоритма, который «зациклен»), то пересечения не возникает. Точно так же в этом случае не проявляется другая особенность прямой записи, нарушающая требования шампур-метода – выход ЦД не находился бы на одной вертикали со входом.

Замыкание ветвей СЦД показано слитно – втеканием в общую петлю. Т.к. ветви не содержат проходных блоков, раздельный показ петель по веткам в данном случае необязателен, а слитный упрощает чтение схемы.

Также заметим, что состояние 4 выбирается как «любое другое». Можно было бы заложить для его выбора явную проверку; отрицательный её результат указывал бы на то, что значение переменной состояния неправильное. Тогда в побочной вертикали м.б. организована обработка этой ситуации; это м.б. целесообразно для повышения надёжности реализации.

В исходной модели явно не указаны значения, выводимые в порты (воздействия). Подразумевается, что выходные переменные имеют булевый тип (что должно указываться в деклар-части программы, напр., на АТ-схеме), и запись идентификатора без отрицания означает вывод лог.1, а с отрицанием – лог.0. Однако это всё-таки «наивное» кодирование спецификации, сохраняющее её «математизм». Поэтому в данной модели значения задаются информатически строго – присваиваниями.

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

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

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

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

Здесь мы также показываем элементы графит-синтаксиса организации моделей. Графит-метод для этой цели использует вершины Область. Определение области дано в п/п 4.1.12.2; основные правила использования областей согласно графит-методу – в п/п 1.3.2.2 Приложения 2 (правило СЕ) и в п/п 1.3.2.3 Приложения 2 (правило ДИ).

В данной графит-модели возможности графит-метода представлены выборочно через макетирование РДП-документа. В частности, условия выбора варианта как основного заданы как атрибуты вершин Область, представленные видимыми полями.

Кроме того, мы сталкиваемся с целесообразностью ещё одного механизма организации графит-моделей – псевдонимики. В самом деле, Promela, как и ряд прогязыков, не допускают текстов (в т.ч. имён величин) не в латинице, иногда ограничена также длина имени; «предметнику» же удобнее имена на родном естественном языке (а значит, в его алфавите) и часто более длинные. Если не игнорировать удобство, то возникает необходимость иметь «естественный» и «технический» варианты имени для каждой сущности. Логично определить соответствие между ними в РДП-документе и возложить на РДП-редактор подстановку нужного варианта по ситуации употребления. Как это реализуется, описано в п/п 1.1.2.4 Приложения 2.

Родных языков у читателей документа м.б. много, и они-то как раз могут сильно различаться. Поэтому «родных» псевдонимов может понадобиться поддерживать много; они образуют переменный (от документа к документу) состав псевдонимики. Поддержка переменного состава – задача для пользователей (сочинителей и читателей РДП-документов).

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

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

1 Источник: Поликарпова Н.И., Шалыто А.А. Автоматное программирование. - СПб.: Питер, 2010. - п. 2.1.2.

2 Определения непротиворечивости и полноты см. в /Поликарпова, Шалыто, п. 2.2.2/.