Безусловно, ДРАКОН-визуализация отличается от традиционной визуализации потоков управления блок-схемами. Сам Паронджанов указал на это следующим образом:

«Задача формализации и унификации множества профессиональных языков с целью обеспечить эффективное взаимопонимание между специалистами любых профессий, включая программистов, является, хоть и важной, но, увы, неразрешимой. Положение в корне меняется, если ограничиться императивными профессиональными знаниями. Именно эту задачу решает язык ДРАКОН. Он построен путём формализации, неклассической структуризации и эргономизации блок-схем алгоритмов и программ, описанных в стандартах ГОСТ 19.701-90 и ISO5807-85.» (Паронджанов В.Д. Как улучшить работу ума, с. 36)

Смысл сказанного можно раскрыть через «формулу новизны», как это и принято для официального описания существа изобретений. Напомним, что она имеет вид: «<Предлагаемый сабж> отличается от <такого-то существующего сабжа> тем, что имеет <такие-то новые фичи> и/или <такие-то фичи>, имевшиеся в <существующем сабже>, здесь реализованы с <такими-то отличиями>».

Здесь можно сказать, что техноязык отличается от языка, заданного стандартами на блок-схемы (далее - БС), тем, что:

• устанавливает требования к графике вершин и линий схем с учётом удобства восприятия «слепыша» и компоновки содержания вершин;

• использует понятие вложения для применения принципов исчисления к графам;

• упорядчивает схемы за счёт принципов шампура и главной/побочной вертикалей;

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

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

• предлагает некоторые правила разметки вершин и линий.

Можно раскрыть эти отличия (а также сходства, оставшиеся с БС) и одновременно оценить шампур-метод (далее - ШМ) и язык, возможности его развития.

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

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

Во-вторых, у автора языка «икона» понимается как визуальный оператор. Но не любая конструкция визуального языка (и вообще ЯПЗ) может считаться оператором.

В силу всего сказанного, мы называем вершины, имеющие операторный смысл, виопами (от ВИзуальный ОПератор), а не имеющие такого смысла (или в общем смысле) — просто вершинами.

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

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

Далее как в графике, так и в тексте мы будем пользоваться новыми для читателя обозначениями. Дадим некоторые пояснения в дополнение к упомянутым ранее определениям.

В общем случае содержание можно описать с привлечением метаязыка РБНФ, что и сделано в этой статье. Определение принятой версии РБНФ можно найти среди условных обозначений, к которым Вас отсылали ранее.

РБНФ у нас применяется не только к текстам, но и к графике. Принцип простой — в индексе части вводятся РБНФ-скобки, если часть необязательна в данном месте схемы. А если скобки задают возможность повтора, то очередное место указывается там же стрелочками. Если в одну сторону — то новая часть должна входить в схему всегда с этой стороны (получается, что после предыдущей введённой части с таким же индексом — ряд растёт по стрелке). А если в обе — то можно выбирать место в ряду — с левого края, правого или где-то посередине (если в ряду уже больше двух частей — между любыми двумя). Нельзя только выйти за место самого ряда в схеме. Сами индексы, если необязательно приводить их полностью, замещаем знаком '#' (кстати, знаки как элементы структуры текста везде берутся в апострофы).

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

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

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

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

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

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

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

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

Можно видеть, что в ШМ принято единственное правило — располагать фигуры вершины «лесенкой» всегда справа налево и направленные формы фигур направо - более простое, но менее информативное.

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

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

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

В отличие от исходного определения, здесь задаются также текстоэлементы языка. Дело в том, что смысл и лексики, и отдельных конструкций (типовых и уникальных подсхем) и законченных схем не сводится к тому, который представлен графикой вершин и линий. Это отражено ещё автором техноязыка в названии авторской технологии его применения — ГРАФИТ-ФЛОКС (от ГРАФика И Текст; ФЛОКС — дополнительный к ДРАКОНу табличный язык, используемый для описания величин) — и в предварительной классификации содержания программно строгих описаний деятельности. Последовательно этот принцип проведён в классификации формализуемых знаний и в графит-методе — новом виде исчисления схем, определённом здесь. Графит-метод использует и основные принципы, принятые для техноязыка, но также вводит новые. Учёт текста не только для частных случаев (гибридных техноязыков), но и в общем (и в правилах исчисления, когда нужно) — один из графит-принципов. Заметим, что правильно добавлять сюда также и таблицы — как своего рода предтечу схемы текста — и несхематические изображения (скажем, рисунки, вставленные в вершины) — и тогда говорить просто о содержании вершин.

Возвращаясь от формы к сути, заметим для начала, что алфавитные знаки индексируются не так, как в исходном техноязыке. Это связано и с их смысловой группировкой, и с тем, что ДРАКОН — лишь один из нужных для визуализации языков. Это следует из упомянутых классификаций — уже в ГРАФИТ-ФЛОКС, как было сказано, имеется два языка. Поэтому же в текст вершины Заголовок включён префикс языка — каждая схема составляется на одном языке, но языков, у потребляемых для описания одного и того же предмета, м.б. более одного…

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

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

Уточним, что в РБНФ-итераторах (как помним из определения РБНФ-метаязыка, так называется операция, обозначаемая фигурными скобками) N служит обозначением натурального (иногда — целого, т.е. включающего и ноль) числа — предела повторений вхождения. Число это каждый раз м.б. разным — на что указывает конкретизирующий индекс при N.

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

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

Функциональный уровень в принципе соответствует уже математической трактовке деятельности. Как некоей структуры функций, применение которых к аргументам (тем же объектам-предметам труда) даёт объекты-результаты труда. Структура объединяет функции прежде всего путём композиции (в цепочку, где результат[ы] одной функции передаются как аргумент[ы] следующей).

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

Что такое маршруты процесса? Это возможные цепочки действий от начала до конца процесса. На дракон-схеме маршрут получается, если пройти путь от начала её к концу. Если такой путь м.б. только один, то процесс (и маршрутная структура) линейный. Однако в жизни чаще однго результата можно ( или нужно) достигать разными путями — вспомним о существовании условий решения задачи. Они м.б. начальными (грубо говоря, когда стоит начинать процесс и что при этом нужно «принять по умолчанию») и граничными — что нужно соблюдать в процессе решения (возможно, когда прекратить процесс, не дойдя до результата).

В нелинейных процессах и структура маршрута нелинейна. Чтобы её выразить, используется прежде всего условный (т.н. предикатный, как говорят математики) тип вершин. В условной вершине выбирается один из возможных маршрутов. В техноязыке для этого служит виоп Развилка.

Дракон-схема, как и БС, математически есть т.н. сводимый граф. Это значит, что у неё один конец, куда должны сойтись все маршруты, ведущие к нужному результату. Поэтому нужны и вершины-соединители маршрутов; пока на них останавливаться не будем.

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

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

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

А что делать, если есть «не сводимые» к нужному результату концы? Т.е. продолжения, возможные, но не ведущие к результату? При информатизации их оформляют как т.н. исключения - «побочные» выходы из процесса. Понятно, что надо иметь, куда выходить — значит, д.б. базовый процесс, где исключение можно обработать. Тем самым возникает некая организация дракон-схем в систему, которую можно назвать «дракон-моделью». Базовый алгопроцесс в зависимости от организации бывает:

• вызывающий — когда данный процесс был вставкой (во вставку во вставку и т.д… - если уровней вызова много) в базовый;
• «родительский» - когда данный процесс порождён как часть системы т.н. совместно протекающих взаимодействующих процессов (как ещё говорят, асинхронных или параллельных — понятие см. в Ч.I, Гл. 6 «Концепций и принципов…» В.Ш. Кауфмана).

Принцип исключений мы описывать не будем — читатель может найти в той же книге Кауфмана (Ч.I, Гл. 8). Если же исключение обработать негде/нечем — значит, система будет работать ненадёжно (может и создать проблемы).

Суть асинхронности (параллелизма) — в допущении более чем одной «рабочей точки» для системы процессов. Каждая точка развёртывает свою схему, и при необходимости процессы взаимодействуют.

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

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

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

То же касается и согласования репертуара, багажа и реквизита схемы и предполагаемого исполнителя при должном уровне формальности языка.

С использованием двух следующих вершин строится дракон-переключатель — иная форма визуализации условия ветвления.

Какие конструкции можно строить из этих «кубиков»? Чтобы это понять, познакомимся со следующей группой знаков и конструкций шампур-схем.

Сначала — замечания по синтаксису. Прежде всего видно, что мы ввели визуальный эквивалент РБНФ. Здесь он описывает повторы отдельных частей схем (знаков Д17 и Д18). Как — сказано выше в «Отступлении о синтаксисе…».

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

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

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

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

Ну и третья порция определений — остальные вершины исходного алфавита.

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

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

…и определения знаков, введённые для её записи:

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

Поэтому там используют механизмы, специально предназначенные для неиерархических систем процессов. В техноязыке они представлены в дополнении для т.н. реального времени (ДРАКОН-2). Его состав представлен на рисунке.

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

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

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

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

В исходном ШМ на ребре ввода определена т.н. валентная точка — вспомогательная вершина, на месте которой ребро как бы можно разорвать и вставить в разрыв атом так, что части разорванного ребра становятся продолжениями рёбер вставляемого атома.

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

Принцип вложения (ввода атома) показан на рисунке ниже.

Для исчисления схем на конкретном шампур-языке задаются множества атомов и заготовок схем. На каждом определяются рёбра ввода. При этом для более удобного представления ветвления на множество вариантов Паронджановым предложена атомарная структура «переключатель».

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

Схематически можно представить сказанное о вершинах, атомах и заготовках, как на следующих рисунках.

Здесь также представлены основные структурные операции (кроме удалений).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Силуэтная укладка есть физическое подразделение структуры маршрутов. Петля силуэта представляет связи веток как совокупность возвратных переходов с выходных соединителей на входные. В императивном смысле (для дракон-силуэта) это простые безусловные переходы. Достоинство их силуэтного употребления — в том, что передачи возможны не в произвольные места схемы, а лишь в заданные делением на ветки. Тем самым допускается goto, но также ограниченный — только на начала веток. Недостаток — в том, что переходы явные, и в терминах программирования дракон-силуэт м.б. представлен только на языках с явным БП (на ЯВУ с goto и на машинах с командой jmp-типа).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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