Приложение 4.
КАТАЛОГ ПРИМЕРОВ ВИЗУАЛИЗАЦИИ

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

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

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

В примере визуализирована по графит-методу текстовая Паскаль-Ассемблер-программа¹. Машобраз текстового описания доступен здесь.

Под логическим сектором понимается целевое содержимое физического сектора (поле данных).

Модель включает обобщённое описание (представлено на ПК-языке, а также в КогниСтиль и другими ОС-средствами) и частное – импер-знание (на Д2М-языке) и деклар-знание (на АТ-языке); актив-знание не представлено (черпается из источников по архитектуре Интел-ИБМ-МС). Структура знаний каждого рода изображается графикой схем; как обычно, это упрощает чтение по сравнению с прогтекстом.

Максимум сведений, помещённых в сопроводительном тексте исходного описания, в графит-модели отражён в комментариях – как внутренних (Паронджанов называет их «формальными»), так и вынесенных в шампур-вершины.

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

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

Тем самым показывается маршрут, который нельзя пересекать и разрывать между ветками силуэта.

Несмотря на усовершенствования, логика процедуры остаётся недостаточно наглядной; это обусловлено как «затемением» смысла циклических действий конструкцией Цикл ДЛЯ (введённой в техноязык из стандарта ГОСТ Р/ИСО на блок-схемы), так и принципом визуализации сложного цикла через «гнездование» простых. Поэтому предпринята попытка вывести содержание процедуры непосредственно из требований к её назначению, используя подход т.н. доказательного, или «убедительного» программирования; результаты оформлены как этот пример.

Обобщённая модель представлена, как и для Оберона, на ПК-языке. ПК-ветка здесь визуализирует Паскаль-оператор PROGRAM, а отношения импорта сводятся к определяемым по USES – видимости загруженных модулей Турбо-среды из сочиняемой программы.

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

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

Деклар-часть визуализирована на АТ-языке, определение которого на момент составления примера формируется; алфавит языка приведён в этом пункте. Для использованных типов правила языка несложны и частично откомментированы на схемах; остальное д.б. очевидно.

В данном случае значение логического сектора получается как результат стандартной DOS-функции int25h и сохраняется в массиве buf, элементы которого доступны по индексу i. Вызов функции оформлен на Ассемблере х86, как принято в Турбо-Паскале.

Ассемблерная вставка оформлена как иерархия областей (отражающая результат декомпозиции); на это указывает формат индекса подчинённой области (в нём появляется подиндекс языка детализации). При этом подразумевается, что РДП-редактор поддерживает детализацию ЯВУ-маршрутов на ассемблере, т.е. «умеет» делать вставки асмкода в исхтекст (а практически он и должен хранить в ТФРД-представлении асмкод так, как принято для ЯВУ, в данном случае – как тело оператора ASM-END).

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

На втором листе даны схемы «для справок», не включаемые в модель; это отражается их атрибутами.

Вероятно, следует пояснить визуализацию деклар-части общей АТ-схемой. Схема построена по принципу «родословного древа» – каждый уровень представлен ОС-узлом И, из которого «растут» определения величин этого уровня и узел следующего уровня. Данную схему следует читать в текстовом виде как «проект порождает глобальную область видимости программы, которой принадлежат <такие-то> глобальные величины, а также главная процедура программы, порождающая свою локальную область видимости; этой области принадлежат <сякие-то> локальные величины, а также, возможно, вызываемые из главной вспомогательные процедуры, порождающие каждая свою локальную область видимости (в данном примере – одна процедура и соответственно одна область); каждой области принадлежит <эдакий-то набор> локальных величин и, возможно, вспомогательные процедуры, вызываемые из данной (в данном примере – опять-таки одна); и т.д.».

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

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

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

Здесь мы должны рассмотреть вопрос о построении АТ-дерева. В самом деле, пустая ветвь удобна, если строить дерево вручную; тогда можно было бы, следуя шампур-методу, определить на вертикалях точки ввода и наращивать дерево добавлением «левых» выходов И-узла как пустых ветвей и в них – новых И-узлов. Однако вспомним, что вложение областей вообще-то соответствует иерархии подстановок визуалов в дракон-модели. Получится, что сочинитель дважды независимо определяет эту иерархию – вставками в визуалы и «левыми» маршрутами АТ-дерева. Конечно, это недопустимо. Если обходиться без АТ-иерархии (общая АТ-схема имеет только один И-узел), то читабельность схемы ухудшится. Поэтому мы должны отвести общей АТ-схеме роль производной, как для ДМ-схемы, и строить её автоматически.

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

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

Если рассматривать процедуры как особый тип сущностей – как это трактуется в Паскаль-системе Пекан (см. определения в окне SumOddNumbers Symbols на иллюстрации), языках Promela и Оберон-2 (п. 6.5 спецификации), то можно иначе построить общую АТ-схему. Это отражено как вариант тела на втором листе. Здесь уже принят зеркальный порядок группировки – процедурные выходы И-узлов упорядочены вправо, что коррелирует с упорядочением вертикалей дракон-схем.

Может возникнуть мысль поместить в такую схему и дракон-схемы процедур, тем самым получив единое описание проекта. Тогда вроде бы можно обойтись и без ПК- и ДМ-схем. Однако такое решение скорее усложнит чтение модели. Кроме того, в данном случае не используются указатели, которые дополнительно усложняют структуру типов. Поэтому импер-части процедур целесообразно, как и в других языках, связать с АТ-вершинами процедур по гиперссылке на имя.

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

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

1Источник: Ерёмин Е.А. Популярные лекции об устройстве компьютера. – СПб.:БХВ-Петербург, 2003. – С.138-141.