Визуальный язык ДРАКОН

Принципы ШМ эргономически выгодно отличаются от принятого в блок-схемах порядка, при котором:

• выходы развилок (предикатных вершин) обычно направлены в разные стороны от оси входа;

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

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

Иногда такую организацию блок-схем называют «анархической». Она критикуется рядом авторов, скажем, Б. Мейером в "Почувствуй класс", Гл. 7.

По сути, в стандартах на БС и не существует чётких правил упорядочения элементов и подсхем. Тогда как ШМ, в общем-то, и есть система таких правил, только данная в математическом смысле не формально («что есть правильная схема»), а конструктивно («как построить правильную схему из правильной заготовки»).

В сравнении с БС упорядоченность шампур-схемы можно видеть на рисунках ниже.

Шампур-схема закономерно асимметрична. Это даёт возможность показать упорядоченность маршрутов по какому-то критерию. Не всегда такой критерий нужно или можно определить по смыслу схемы; в этом случае порядок м.б. произвольным или введён сочинителем по какому-то абстрактному правилу.

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

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

Все теоретически возможные структуры маршрутов не всегда можно получить только вложением. Имеются в виду структуры с БП — произвольным внутри программы (goto) и изнутри цикла на его начало/конец (т.н. break/continue-заменители). Для их представления Паронджановым было введено понятие лианной структуры маршрутов и операция пересадки лианы. В результате в техноязыке возможно представить структуры циклов с заменителями, и сверх того — некоторые случаи goto в разветвлённых алгоритмических структурах (на ближайшие слева/справа вертикали). Как результат пересадок лианы могут возникать связи, нарушающие атомарность тела примитива (ветки силуэта), и их соединения тоже требуют представления явными БП.

В силуэте у ветки возможны и побочные выходы. Они получаются как в результате укладки примитива с пересечениями, так и при изначальном сочинении силуэта. Для создания побочных выходов в ШМ включена операция заземления лианы.

Примерное выполнение этих операций показано на рисунках.

Очевидное достоинство такого подхода — техноязык практически нейтрален к структурности алгоритмов («войне языков» высокого уровня по поводу goto и заменителей). Если принять подход противников явных БП в ЯВУ — можно отказаться от операций с лианой и алгоритмизовать только атомарными структурами. Если принять подход сторонников — разрешить лианные операции и структуры.

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

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

Проще говоря, нужно перейти от деления схемы соединителями к делению разветвителями. Фактически они присутствуют в «петле силуэта», но их условия (охраны) имеют смысл исключительно проверок совпадения значений адреса целевой ветки и имени текущей. Возможность и логической укладки (исключения межветочных БП), и отказа от явных БП в теле схемы даёт цикл Дейкстры (далее - ЦД) как иная форма универсальной программы. Это можно видеть на схемах ниже.

Для упрощения силуэт мы показали одноадресным и без дополнительных входов.

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

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

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

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

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

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

Здесь можно видеть, чем представляются вершины кросса в системе команд типичного исполнитля алгоритмов — машины с адресной архитектурой. Это команды БП — простого и с возвратом.

Использование ЦД возможно двумя путями:

• вывода тела дракон-схемы или его части как ЦД в рамках ШМ-правил (как варианта вложенного цикла);

• модификации метода для использования ЦД-организации схем, начиная с аксиом.

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

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

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

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

• приводить разработанные силуэты и/или лианные макроблоки к форме ЦД.

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

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

Важное преимущество ЦД как замены силуэта в том, что его ветви имеют один выход. Тем самым отпадает нужда в ШМ-операции «заземление лианы». Кроме того, в рамках доказательного программирования Дейкстрой, Виртом и другими исследователями было показано, что в теле ЦД также не нужно употреблять явных БП, чтобы получить те же маршруты, что и с их использованием; соответственно не требуется операция «пересадка лианы». Как следствие, редактор, реализующий только логическую укладку, м.б. упрощён в плане как алгоритмов, так и структур данных; очевидно, это даст большую его производительность.

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

В ШМ она, по сути, не рассматривается. По определению это исчисление «слепышей», т.е. неразмеченных графов (без учёта текстоэлементов синтаксиса схем). Однако на практике возникает необходимость по крайней мере в двух типах разметки шампур-схем:

• для выходов развилок — надписями «да»/«нет» при выходных рёбрах;

• для веточных макроциклов (ВМЦ) — какими-нибудь индексами, позволяющими отличить разные ВМЦ в одном силуэте.

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

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

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

1. выделения в чисто текстовом языке управляющей части и замены её на маршрутный язык (синтаксис «слепышей»);
2. разметки остальным содержанием текстового языка вершин и рёбер «слепыша».

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

Управляющие знания логически есть одна часть из двух (структурной и атрибутивной) в одной составляющей из четырёх (императивной, декларативной, активностной и обобщающей). Это следует из известного тезиса Н. Вирта (программа = алгоритм + структура данных + систематическое представление об исполнителе; см. в этой статье), а также из факта существования т.н. парадигмы программирования как способа увязки частей описания программы (по Вирту) в единое целое. Однако синтаксический объём этих частей в разных языках не обязательно одинаков. Существует и подход В.Ш. Кауфмана — язык программирования определяет данные, операции и их связывание.

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

«…множество 32-символьных идентификаторов образует весьма выразительный, хотя и своеобразный, язык, законы и правила оптимизации которого ещё предстоит открыть, обсудить и подвергнуть экспериментальной проверке.» /Как улучшить работу ума, с.163/.

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

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

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

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

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

Преодолеть недостатки частной гибридизации можно следующим образом:

• визуализировать в каждой составляющей текстового языка её структурную часть;

• рассматривать парадигмы «ЧТО-формализации» на предмет выделения их структурной части и нахождения структур графов, формально и эргономично представляющих эту часть;

• выявлять содержание, не отражённое в конкретном языке явно, и находить средства его выражения.

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

Безусловно, путь, намеченный Ермаковым, требует и теоретических изысканий, на что он также указывал.

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

«ЧТО»-язык отражает некие сущности решаемой задачи и её предметной области (не обязательно объекты алгоритма) и некие отношения между ними. Такие языки тоже бывают как чисто текстовыми, так и графитными. Пример последнего — язык информационного моделирования IDEF1X. Он отражает только систему отношений между сущностями. Для записи преобразований (отдельно или вместе с сущностями-отношениями) существуют другие языки — скажем, т.н. функционального или логического программирования. Ряд таких языков имело бы смысл «графитизировать» — но делать это нужно по иным принципам, чем для императивных языков. Примером могут служить языки схем зависимостей, потоков данных, такие как функциональные схемы, ДПД, Анимо. Следует выработать эргономические оптимальные правила организации таких схем. В чём-то может помочь опыт эргономизации системных схем, частично зафиксированный в стандартах на такие схемы (типа ЕСКД).

Условия применения «ЧТО»-описаний хорошо сформулированы у Кауфмана:

Людей как исполнителей характеризует прежде всего наличие у них модели реального мира, в достаточной мере согласованной с моделью мира у создателя плана <т.е. описания поведения исполнителя>. Поэтому в плане для людей можно указывать цели, а не элементарные действия. (ЯП. Концепции и принципы, с. 31)

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

В более практическом смысле дескриптивные языки можно применять для более качественной постановки задач. А их графические разновидности — и для эргономизации представления «ЧТО»-описаний.