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

Дружелюбный Русский Алгоритмический язык, Который Обеспечивает Наглядность/Надёжность

Инструменты пользователя

Инструменты сайта


ocenka_texnojazyka_i_shampur-metoda

Различия

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

Ссылка на это сравнение

Предыдущая версия справа и слева Предыдущая версия
Следующая версия
Предыдущая версия
ocenka_texnojazyka_i_shampur-metoda [2012/03/27 13:32]
Владислав Жаринов [Дракон-лексика: уточним состав и смысл]
ocenka_texnojazyka_i_shampur-metoda [2012/05/21 19:43] (текущий)
Владислав Жаринов
Строка 1: Строка 1:
-====== ​Оценка техноязыка и шампур-метода ======+====== ​Перспективы ​техноязыка и шампур-метода ======
  
-Безусловно, ​ДРАКОН-визуализация отличается от традиционной визуализации ​потоков управления блок-схемами. Сам Паронджанов указал на это следующим ​образом:+ДРАКОН-визуализация ​- дело новое. И важно понимать, что техноязык и лежащий в его основе шампур-метод — это: а) не сухая книжная ​догма, а живые сущности, имеющие потенциал для плодотворного развития и б) не трактуемы узко как средство и метод формализации только импер-знаний, но приложимы и для знаний других ​родов и служат источниками ​общих идей ​визуализации. Что и будет по возможности показано далее - на опыте как исследовательском и учебном, так и практическом.
  
 +Предложения создателя техноязыка сохраняют общность с БСАП-языком в отношениях:​
 +  * структуры схем — объектом вывода также является т. н. сводимый (аранжируемый,​ устремлённый;​ на эквивалентность этих определений указано в п. 6 [[biblioteka:​start|доклада Ермакова и Жигуненко]]) граф — ориентированный циклический,​ с выделенной начальной вершиной;​
 +  * отношения к разметке — как и в БСАП, рассматривается неразмеченный граф, который Паронджанов называет «слепышом»;​
 +  * интерпретации — как и БСАП, примитивы и силуэты понимаются как графы потока управления,​ а их цепи — как маршруты алгоритмических процессов.
  
-//"Задача формализации и унификации множества ​профессиональных языков с целью обеспечить эффективное взаимопонимание между специалистами любых профессий, включая программистов, является, хоть и важной, но, увы, неразрешимой. Положение ​в корне меняется, если ограничиться императивными профессиональными ​знаниями. Именно эту задачу ​решает язык ДРАКОН. Он построен путём формализации,​ неклассической структуризации и эргономизации блок-схем алгоритмов и программ, описанных ​в стандартах ГОСТ 19.701-90 ​и ISO5807-85."//​ (Паронджанов В.Д. Как улучшить работу ума, с. 36)+Как правилопредставленные здесь предложения следуют этомуно в ряде случаев рассматривается размеченный граф (прежде всего с текстовкой вершин).
  
-Смысл сказанного можно раскрыть через «формулу новизны»,​ как это и принято для официального описания существа изобретений. Напомним,​ что она имеет вид: «<Предлагаемый сабж>​ отличается от <​такого-то существующего сабжа> тем, что имеет <​такие-то ​новые фичи> и/или <​такие-то фичи>,​ имевшиеся в <​существующем сабже>,​ здесь реализованы с <​такими-то отличиями>​».;​-)+====== ​Предложения и решения ​======
  
-Здесь можно сказать, что техноязык ​отличается от языка, заданного стандартами на блок-схемы алее - БС), тем, что:+===== Дракон-лексика: полнота состава и смысла =====
  
-  * устанавливает требования ​к графике вершин и линий схем с учётом удобства восприятия «слепыша» и компоновки ​содержания вершин;​  +[[Дракон-лексикаполнота состава и смысла|]]
-    +
-  * использует понятие вложения для применения принципов исчисления ​к графам; +
-    +
-  * упорядчивает схемы за счёт принципов шампура и главной/​побочной вертикалей; +
-    +
-  * использует ​соединители, принятые для блок-схем как межстраничные, ​в новом качестве — как внутрисхемные для укладки ​схемы на плоскости без пересечений цепей и с возможностью структуризации содержания;​ +
-    +
-  * даёт возможности выразить топологии потоков управления,​ характерные как для структурной,​ так и для неструктурной алгоритмизации (программирования),​ также через операции исчисления;​ +
-    +
-  * предлагает некоторые правила разметки вершин и линий.+
  
-Можно раскрыть эти отличия (а также сходства,​ оставшиеся с БС) и одновременно оценить шампур-метод ​(далее - ШМ) и язык, возможности его ​развития.+===== Цикл-силуэт и метод ​Дейкстры =====
  
-Каждый пункт списка будет раскрыт в самостоятельном разделе — по сути, получится цикл статей (на общей странице сайта).+[[Цикл-силуэт и метод Дейкстры|]]
  
-Предварительно следует сказать кое-что и о понимании сути визуализации и вообще формализации. Удобно это сделать в связи с «исправлением имён» шампур-метода. Так, здесь мы не говорим об иконах. Тому две причины. Во-первых,​ такое название как краткий синоним для пиктограммы пришло из культуры в религиозном смысле протестантской (антикатолически-реформатской ветви западного христианства) — представленной прежде всего носителями английского и немецкого языка. Там иконы как предмет культа не приняты,​ и это слово сакрального смысла,​ в сущности,​ не имеет. Носители русского языка существенно разноконфессиональны,​ и восточное христианство (в частности,​ русское православие) вводит иконы как предмет культа и сакрализует это слово. На возможный конфликт его «мирского» употребления с чувствами соответственно верующих (которые м.б. и сочинителями,​ и читателями описаний на техноязыке) указал Д.В. Барановский — один из практиков дракон-визуализации — [[http://​forum.oberoncore.ru/​viewtopic.php?​p=51261#​p51261|см. здесь]]. ​ 
  
-Это тем более существенно,​ что христианин в некотором смысле может рассматривать формализацию мира (и дракон-визуализацию в частности),​ особенно неограниченную и касающуюся человеческого поведения,​ как продолжение «познания добра и зла»... и тогда противоречие словоупотребления и убеждений станет серьёзным (хотя здесь оно будет касаться скорее сущностной стороны — в частности,​ возможного использования техноязыка для посягательства на свободу воли и попытки игнорировать неполноту формализуемого знания в виде неопределённости,​ присутствующей в любой модели или в контексте моделирования и сказывающейся в её реализации на практике). 
- 
-Во-вторых,​ у автора языка «икона» понимается как визуальный оператор. Но не любая конструкция визуального языка (и вообще ЯПЗ) может считаться оператором. 
- 
-В силу всего сказанного,​ мы называем вершины,​ имеющие операторный смысл, виопами (от ВИзуальный ОПератор),​ а не имеющие такого смысла (или в общем смысле) — просто вершинами. 
- 
-Далее мы будем широко пользоваться приёмами структурного анализа и синтеза. Проще говоря,​ это умение подразделять данный предмет (в частности,​ воображаемый) на относительно самостоятельные части, которые можно рассматривать независимо,​ и выделять связи частей. И определять такие части, из которых можно собрать (используя связи) заданный предмет так, что он приобретёт нужные свойства (в частности,​ за счёт интегрального эффекта связывания). 
- 
-Структурируя схемы, естественно пользоваться понятием //​**позиции**//​. Как «белого ящика»,​ содержащего часть схемы (её элемент — вершину или ребро, фрагмент,​ законченную конструкцию) и имеющего связи с остальной частью схемы. Позиций на схеме можно определить много. Но полностью схема не может состоять из них — должны оставаться по крайней мере связи. Их положение и присоединение к позициям задают «каркас» строения схемы как результат структурного анализа. А если определить некие операторы управления вхождением позиций — можно описать и структурный синтез. ​ 
- 
-Пока это лишь слова (не каждому читателю,​ возможно,​ до конца понятные) — но по ходу рассказа мы раскрем суть сказанного на примере структурирования конструкций и схем техноязыка и шампур-метода. 
- 
-Часто мы будем говорить о смысле частей схем. Под этим понимается интерпретация получателем сообщения,​ написанного на данном языке (в нашем случае — на ДРАКОНе). Принцип интерпретации можно найти у В.Ш. Кауфмана в книге [[http://​forum.oberoncore.ru/​viewtopic.php?​p=71218#​p71218|«Языки программирования. Концепции и принципы»]] (п. 1.3). Здесь под получателем будем подразумевать //​**машину для переработки данных**//​ (также называемую //​информатической//​) — по сути своей формально-языковую,​ т.е предназначенную для работы с неким математически определимым языком. Ту самую, которую обычно называют «компьютером» (но это не более чем жаргонное словцо,​ передающее лишь часть возможностей таких машин). Но не каждую информашину,​ а такую, устройство и принцип действий которой можно описать моделью,​ известной как «машина Тьюринга» (или аналогичной моделью - «машиной Поста»). В основе своей такая модель несложна для понимания — с ней можно познакомиться по книжке В.А. Успенского «Машина Поста» или в учебнике В.А. Острейковского «Информатика» ([[http://​forum.oberoncore.ru/​download/​file.php?​id=2219|п. 3.1]]). Всё распространённые информашины (включая ПК) описываются этой моделью. Главное,​ что нам надо знать — пространство для переработки данных в такой машине разбито на ячейки,​ упорядоченные в линию и снабжённые номерами-адресами. 
- 
-Вообще каждый формальный язык подразумевает какую-то модель исполнителя. Если она соответствует какому-то реальному исполняющему устройству — то говорят,​ что это язык низкого уровня. Если же модель абстрагирует (т.е. отвлекается от несущественных деталей,​ скрывает их за укрупнённым представлением) реального исполнителя — то говорят,​ что язык, соответствующий ей, высокого уровня.На рисунках далее мы будем пользоваться элементами когнитивной графики,​ как принятой у Паронджанова,​ так и новой. Словарь обозначений можно найти [[http://​grafit-basis.narod.ru/​L3/​usl_obozn.html#​Pril1-n12|здесь]]. 
- 
-==== Отступление о синтаксисе:​ эргономично — не всегда неформально ==== 
- 
- 
-Далее как в графике,​ так и в тексте мы будем пользоваться новыми для читателя обозначениями. Дадим некоторые пояснения в дополнение к упомянутым ранее определениям. 
- 
-В общем случае содержание можно описать с привлечением метаязыка РБНФ, что и сделано в этой статье. Определение принятой версии РБНФ можно найти среди условных обозначений,​ к которым Вас отсылали ранее. 
- 
-РБНФ у нас применяется не только к текстам,​ но и к графике. Принцип простой — в индексе части вводятся РБНФ-скобки,​ если часть необязательна в данном месте схемы. А если скобки задают возможность повтора,​ то очередное место указывается там же стрелочками. Если в одну сторону — то новая часть должна входить в схему всегда с этой стороны (получается,​ что после предыдущей введённой части с таким же индексом — ряд растёт по стрелке). А если в обе — то можно выбирать место в ряду — с левого края, правого или где-то посередине (если в ряду уже больше двух частей — между любыми двумя). Нельзя только выйти за место самого ряда в схеме. Сами индексы,​ если необязательно приводить их полностью,​ замещаем знаком '#'​ (кстати,​ знаки как элементы структуры текста везде берутся в апострофы). 
- 
-В графике мы тоже акцентируем возможность отсутствия фигур и/или связей — пунктиром линий. Если надо зрительно объединить разные части схемы — используем цвет линий и/или фона, толщину контуров и/или связей. Применяем и специальные операторы выбора частей. При этом на схеме выделяются позиции частей,​ к которым выбор применяется. Здесь интуитивно д.б. понятно следующее правило — когда в результате выбора данная часть отсутствует,​ отсутствуют и её внешние связи. Обычно индексы выбора мы даём для вершин — связанные с ними рёбра выбираются,​ так сказать,​ автоматически. 
- 
-Конечно,​ для чтения этих обозначений нужен некоторый навык. Поэтому мы часто кое-что поясняем по их употреблению. В дальнейшем читатель,​ думается,​ сможет и сам пользоваться ими. 
- 
-Может возникнуть вопрос — а зачем они? Одна из основных ролей — сокращать объём представления. Если рисовать/​писать всё, что может повторяться — то при большом числе повторов получится чересчур «габаритное» описание. Помимо его большой площади (и трудной обозримости),​ возникает и взаимосвязанная проблема восприятия — когда «за деревьями не видно леса». :-) Т.е. логическая структура предмета описания неясна. И вот тут выделение частей,​ которые могут повторяться или быть необязательными,​ кроме сокращения объёма,​ работает и на прояснение структуры. Как правило,​ это оказываются именно те части, на которые можно поделить предмет в результате структурного анализа его содержания. И получается,​ что физическое и логическое структурирование в значительной степени совмещаются. 
- 
-==== Отступление об исполнителях:​ «наши машины» и люди - «винтики» и «творцы» ==== 
- 
-Так называются машины для переработки данных у Б. Мейера — одного из современных специалистов по инженерии программ. Мы уже говорили,​ что исполнителя алгоритмов можно описать формальной моделью. При этом важно понимать,​ что он так или иначе связан с окружающим миром — иначе превращается в «вещь в себе», для решения задач бесполезную. Законы связи, взаимодействия и реализации задач, поставленных исполнителю (а где-то — и установления целей и постановки задач) изучает специальная наука — //​**кибернетика**//​. И исполнитель вместе с окружением образует некую кибернетическую систему как объект изучения в этой науке. 
- 
-Начнём с простой системы,​ которая показана в «детской» книжке по техноязыку - «Занимательная информатика»:​ 
- 
-{{ :​sxemavklispolnitelja_-_ill_zaniminfor_.png?​200 |}} 
- 
-Здесь показан исполнитель,​ устроенный так, что может и получать данные от окружения — по связи «информация о внешнем мире» (её ещё называют обратной),​ и выдавать воздействия во внешний мир — по связи «движения Мускула» (ещё её называют прямой). Собственно «наша машина» - устройство-исполнитель программы — это блок «Мозг». Идущие от него вопросы — это тоже команды,​ управляющие получением данных обратной связи. 
- 
-Здесь исполнитель подразумевается как техническое устройство. Но задачи он решает в интересах человека-пользователя. Человек выбирает алгоритм (а если это не предусмотрено задачей,​ для которой сделан исполнитель — то запускает его исполнение — хотя бы просто включив робота). 
- 
-Многие машины устроены по такой схеме. Это и программируемая бытовая техника,​ и станки с ЧПУ (в режиме работы по программе),​ и самонаводящиеся боеприпасы. 
- 
-Во многих задачах человек присутствует непосредственно — когда он участвует в процессе решения. Вот пример структуры исполнителя для такого случая:​ 
- 
-{{ :​page3_graph_a3ls_taskdataproc_111_drakon-schdesign_curr.png?​200 |}} 
- 
-Тут человек-оператор представлен «крупным блоком» вверху,​ а машина (КСА — от «комплекс средств автоматизации») — таким же блоком внизу. Внутри каждого блока находятся элементы — это части т.н. информационного пространства. Оно выделяется в модели исполнителя — наряду с т.н. операционным устройством. В упомянутых «машинах Тьюринга/​Поста» это «лента» и «головка». 
- 
-Эта схема относится к [[http://​grafit-basis.narod.ru/​L3/​viz_alg_TFZ.html#​Doc-n42-1B-I2|задаче оформления дракон-схем]]. Можно изучить описание задачи полностью — может пригодиться. Если, скажем,​ надо нарисовать схему — а под рукой только редактор из офисного пакета. Или есть и специализированный дракон-редактор — но он для простого рисования слишком сложен... 
- 
-Что мы здесь видим? Человек хранит не только точные описания алгоритмов,​ подобные машинным — но и знания,​ умения,​ навыки (ЗУН). А ещё — цели, представления о том, как можно ставить задачи и находить их решения. И чем нужно ограничивать себя в целеполагании и в решении задач (в самом общем смысле это нормы этики),​ а также чем должны ограничиваться люди в отношении к окружающему миру (это нормы морали). Всё это составляет интеллектуальные ресурсы. 
- 
-Если же думать,​ что поведение человека описывается только алгоритмически строго — то мы приходим к упрощённой модели человека — т.н. «винтику». В каких-то задачах,​ которые поставлены уместно с т. зр. общих норм поведения — да, можно составлять алгоритмические инструкции и следовать им. Но в целом, если не упрощать — мы не можем дать «фундаментального алгоритма поведения»... 
- 
-Вот и повод показать более общий случай структуры исполнителя. Здесь различные люди имеют отношение к одной «предметной области»,​ решая разные задачи:​ 
- 
-{{ :​graph_a3l_3211_task_senscontr-activsch_dsk.gif?​ |}} 
- 
-Оператор,​ решающий рассматриваемую задачу (её описание можно найти [[http:///​drakonografika.narod.ru/​L3/​automatization_know.html#​Pril4-n3211-2|здесь]]),​ связан с объектом. И этот же объект используется его персоналом — другими людьми. Иногда цели их м.б. нейтральны друг к другу, иногда совместны,​ иногда и противоположны. 
- 
-А что внутри у исполнителя алгоритма?​ Устройство его сложно,​ и описать можно по-разному. В большинстве случаев структура подобна показанной на следующей схеме: 
- 
-{{ :​grafit-abc_html_m5c6b9f1d.gif?​ |}} 
- 
-Схема составлена на [[http://​grafit-basis.narod.ru/​L3/​aktiv-vspom.html#​Pril2-n73|СТ-языке]]. 
- 
-Важно понимать,​ что все эти блоки тоже работают в определённом порядке. Только алгоритм здесь не программируется,​ а как говорят,​ "​зашит в железе"​ - реализован аппаратно,​ за счёт соединения деталей. Для переработки данных существуют определённые законы устройства аппаратуры,​ делающие её работу максимально правильной. Интересующиеся могут прочесть [[http://​www.mcst.ru/​e2k_arch.shtml|эту работу]]. 
- 
-Можно видеть,​ что «наша машина» (здесь это устройство — ДСК) может и не использоваться при решении — если она стала неработоспособной. Кто это определяет?​ Оператор. А бывает и так — машина в какой-то момент начинает работать неправильно. А определить это оказывается невозможно — по крайней мере, вовремя... ​ 
- 
-Чтобы свести такую возможность к минимуму,​ изделия рук человеческих д.б. гарантоспособны. По-простому это значит — их создатели должны полностью отвечать за то, что изделие работает так, как положено. Но не только — ещё нужно, чтобы ущерб от неправильной работы был в допустимых пределах или вообще была возможность его предотвратить. Если изделие программируется — то гарантоспособность исполнения программ «нашей машиной» в его составе — важная часть решения этой проблемы в целом. Если же и нет — то понимание работы изделия,​ строгое алгоритмически,​ тоже важно. Для этого в конечном счёте и нужно описывать алгоритмы точно и понятно. Для человека... 
- 
-==== Отступление:​ формализация и языки представления знаний ==== 
- 
-В отличие от исходного определения,​ здесь задаются также текстоэлементы языка. Дело в том, что смысл и лексики,​ и отдельных конструкций (типовых и уникальных подсхем) и законченных схем не сводится к тому, который представлен графикой вершин и линий. Это отражено ещё автором техноязыка в названии авторской технологии его применения — ГРАФИТ-ФЛОКС (от ГРАФика И Текст; ФЛОКС — дополнительный к ДРАКОНу табличный язык, используемый для описания величин) — и в предварительной классификации содержания программно строгих описаний деятельности. Последовательно этот принцип проведён в [[http://​grafit-basis.narod.ru/​L2/​gen_struct_dan.html|классификации формализуемых знаний]] и в графит-методе — новом виде исчисления схем, определённом [[http://​grafit-basis.narod.ru/​L3/​grafit-rules.html|здесь]]. Графит-метод использует и основные принципы,​ принятые для техноязыка,​ но также вводит новые. Учёт текста не только для частных случаев (гибридных техноязыков),​ но и в общем (и в правилах исчисления,​ когда нужно) — один из графит-принципов. Заметим,​ что правильно добавлять сюда также и таблицы — как своего рода предтечу схемы текста — и несхематические изображения (скажем,​ рисунки,​ вставленные в вершины) — и тогда говорить просто о содержании вершин. 
- 
-Уже давно специалисты по анализу и проектированию деятельности и взаимодействия человека в трудовом процессе — инженерные психологи — определяли общую структур процесса формализации знаний. Общий результат можно найти на [[http://​drakonografika.narod.ru/​L2/​formalization.html#​Doc-n1411|этой странице]]. В структуре процесса можно фактически выделить три стадии - «качественную»,​ математическую и информатическую. Каждой из них соответствует достигаемый уровень формальности языка. Познакомимся с этими уровнями вкратце. 
- 
-//​**Неформальный**//​ предполагает «почти естественную» формулировку действия — как фразы на родном языке сочинителя,​ только с заданным подразделением на имена объектов (в экономическом смысле — предметов и результатов труда) и «имя действия» - глагольные обороты,​ связующие объекты и указывающие применение к ним называемых действий (и, возможно,​ инструментов). Как действия д.б. знакомы исполнителю по названиям (входить,​ как говорят Паронджанов,​ а ранее — [[http://​forum.oberoncore.ru/​viewtopic.php?​p=71218#​p71218|В.Ш. Кауфман в книге «Языки программирования. Концепции и принципы»]],​ в его «репертуар»),​ так и объекты д.б. известны по именам,​ образуя,​ так сказать,​ «багаж» исполнителя;​ то же касается и инструментов,​ образующих,​ условно говоря,​ «реквизит» процесса. Понятно,​ что не меньшие знания обо всём этом д.б. у сочинителя. ;-) 
- 
-//​**Функциональный**//​ уровень в принципе соответствует уже математической трактовке деятельности. Как некоей структуры функций,​ применение которых к аргументам (тем же объектам-предметам труда) даёт объекты-результаты труда. Структура объединяет функции прежде всего путём композиции (в цепочку,​ где результат[ы] одной функции передаются как аргумент[ы] следующей). 
- 
-//​**Информатический**//​ уровень возникает как результат информатизации представления о деятельности. При этом выделяется императивное формализованное знание — о маршрутах процесса,​ декларативное — о типах объектов и их структурах,​ активностное — о типах операций и средствах их выполнения (как структуре механизмов «реквизита»). В пределе обязательно представление объектов как чисел (кодов) и операций — как арифметических и/или логических (в смысле булевых функций над двоичными цифрами-битами). Любым «материальным последствиям» исполнения алгоритма тогда соответствуют (в алгоритмической обстановке,​ т.е. в модели контекста процесса) значения чисел/​кодов на определённых линиях связи внутри исполнителя (между механизмами «реквизита») и в его окружении в определённые моменты времени. Так можно описать то, что Паронджанов называет «техпроцессом». Понятно,​ что сочинитель должен представлять себе схему исполнителя вместе с окружением,​ «размеченную» величинами данного процесса. 
-===== Вершины и линии схем: смысл — в ГРАФике И Тексте ===== 
- 
-По идее когнитивной формализации знаний,​ в ШМ она должна прежде всего удобно вмещать текст (и/или таблицы,​ если они допустимы как содержание вершины некоторого типа). Поэтому из БС-графики заимствуются только такие формы икон и их частей,​ которые и наглядны сами по себе, и удобно и экономично вмещают текст. 
- 
-Как следствие,​ по сравнению с блок-схемами некоторые формы блоков получают новые значения (к примеру,​ форма-трапеция – как основа хронизаторов реального времени),​ а другие (скажем,​ ромб) не используются. 
- 
-В то же время композиция многофигурных вершин м.б. более стройной,​ если ввести общие законы их построения. Возможны следующие:​ 
-вертикалей окружения — вводятся условные оси, параллельные шампуру схемы и представляющие совокупные потоки управления процессов,​ взаимодействующих с алгоритмическим процессом,​ описываемым схемой;​ 
-событийного следования — фигуры в вершине и/или части её содержания упорядочиваются по шампуру в порядке исполнения. 
- 
-В части первого нужно раздельно представлять процессы того же исполнителя и процессы его внешней среды; поэтому следует ввести оси по обе стороны шампура;​ фигуры,​ представляющие связь с соответствующей категорией процессов,​ для удобства чтения нужно сделать как по форме направленными на ось, так и по положению смещёнными к ней. 
- 
-В части второго предшествующие события представляются фигурами,​ расположенными ближе к началу шампура;​ кроме того, можно использовать уровни глубины,​ если допускать частичное перекрытие фигур в вершине. 
- 
-Можно видеть,​ что в ШМ принято единственное правило — располагать фигуры вершины «лесенкой» всегда справа налево и направленные формы фигур направо - более простое,​ но менее информативное. 
- 
-Также алфавит БС функционально шире, чем в ДРАКОНе. Блок-схемы предназначены для представления содержания всей программы (в смысле расширенного тезиса Вирта). Поэтому,​ кроме подалфавита импер-части (называемой в БС «схема алгоритма»),​ предусмотрен также подалфавит для деклар-части («схемы данных»). Имеются также средства для представления материальных действий («техпроцессов» по Паронджанову) и структур (актив-части). Однако назначение ДРАКОНа — представлять только императивные знания;​ поэтому остальной алфавит здесь не нужен. 
- 
-Важно понимать,​ что графика шампур-схемы представляет лишь часть формализуемого знания о предмете шампур-визуализации. Остальная часть представляется содержанием вершин (и, возможно,​ рёбер). Т.е. за схемой всегда стоит некий целостный язык представления (ЯПЗ), изначально полностью текстовый. Именно на него мы и указываем префиксом. Не принимать во внимание этот язык можно, лишь рассматривая абстрагированные шампур-схемы (литеральные и «слепыши»). Конкретный же графит-язык «гибриден»,​ т.е. образуется «скрещиванием» ЯПЗ с шампур-языком (схем-«слепышей»). При этом часть синтаксиса текстового ЯПЗ представляется графикой вершин и рёбер, а часть — их содержанием (как ещё говорят,​ разметкой графа). Образуется т.н. гибридный язык — который д.б. эквивалентен чисто текстовому. 
- 
-Если же мы не указываем ЯПЗ, но считаем,​ что схема конкретная (гибридная) — это лишь значит,​ что мы принимаем для содержания её рёбер и/или вершин синтаксис некоего гибридного ЯПЗ, выбираемого «по умолчанию». Разумно считать таким естественный язык описания деятельности,​ родной для сочинителя (и, конечно,​ читателя) схемы. Однако этот язык для удобства дальнейшей формализации обычно как-то структурируется (ограничивается). Как — покажем при определении лексики языка. 
- 
-Далее рассмотрим дракон-алфавит с позиций структурного анализа и синтеза. 
-==== Начало азбуки ДРАКОНа-1:​ вроде, как в БС... да не как в БС ==== 
- 
-С учётом определения «от блок-схем» начать,​ конечно,​ стоит с вершин,​ представляющих эквиваленты БС-алфавита. Их определения даны на рисунке ниже. 
- 
-{{ :​jazyk:​soobschenija_o_jazyke_i_metode_ischislenija_ikon:​st_drakonsu_-_ocenka_texnojazyka_i_ishm_html_m6dbf46c5.gif?​ |}} 
- 
-Видно, что дракон-алфавит богаче БС уже в этой части. Причиной тому в первую очередь разнообразие способов представления ветвлений (т.н. предикатных вершин в терминах блок-схем). 
- 
-Для уточнения (расширения) смысла вершины,​ включённой в шампур,​ в шампур-методе используют добавочные вершины-боковики,​ присоединяемые справа и/или слева к вершине,​ находящейся на шампуре (в цепочке следования). Возможность присоединения мы показываем отрезком линии сбоку. Так же показываются точки включения в вертикаль (вход и/или выход[ы] вершины). 
- 
-Возвращаясь от формы к сути, заметим для начала,​ что алфавитные знаки индексируются не так, как в исходном техноязыке. Это связано и с их смысловой группировкой,​ и с тем, что ДРАКОН — лишь один из нужных для визуализации языков. Это следует из упомянутых классификаций — уже в ГРАФИТ-ФЛОКС,​ как было сказано,​ имеется два языка. Поэтому же в текст вершины ''​Заголовок''​ включён префикс языка — каждая схема составляется на одном языке, но языков,​ у потребляемых для описания одного и того же предмета,​ м.б. более одного... Почему - сказано выше в "​Отступлении о языках..."​. 
- 
-Далее, в техноязыке принято включать в заголовок имя схемы. По сути, это имя алгоритмического процесса. Имеющего некий внешний контекст,​ в котором он вызывается,​ для чего создаётся собственный контекст процесса. Для указания контекста в техноязыке обычно используют боковики. 
- 
-Процесс может и не иметь конца — тогда говорят,​ что он «зацикленный». В техноязыке в этм случае используют специальную форму дракон-схемы,​ которую рассмотрим в другом разделе. 
- 
-Возможно,​ что два и более алгопроцессов взаимодействуют друг с другом. Тогда возникает некая организация дракон-схем в систему,​ которую можно назвать "​дракон-моделью"​. Представляемые схемами модели процессы могут находиться либо в отношении «главный-подчинённый» (иерархическая,​ или ранговая модель),​ либо в отношении «партнёров» (одноранговая,​ или диспозитивная модель). По порядку же возникновения всегда существует первичный процесс,​ который для другого данного процесса бывает:​ 
- 
- 
-  * вызывающий — когда данный процесс был вставкой (во вставку во вставку и т.д... - если уровней вызова много) в другой процесс;​ 
- 
- 
-  * «родительский» - когда данный процесс порождён как часть системы т.н. совместно протекающих взаимодействующих процессов (как ещё говорят,​ асинхронных или параллельных — понятие см. в Ч.I, Гл. 6 «Концепций и принципов...» В.Ш. Кауфмана). 
- 
-В ранговой модели существует только одна рабочая точка. Она последовательно проходит процессы,​ начиная с первичного вызывающего. Там, где указана вставка другого процесса,​ совершается переход на его схему. Когда эта схема пройдена до конца — переход обратно на место указания вставки. В совокупности эти переходы образуют т.н. переход с возвратом (у Паронджанова также называется «акробатический прыжок»). Первичный процесс здесь понимается как головной. 
- 
-Суть асинхронности (параллелизма) — в допущении более чем одной «рабочей точки» для системы процессов. Каждая точка развёртывает свою схему, и при необходимости процессы взаимодействуют. Первичный процесс в этом случае понимается как базовый;​ он может контролировать ход порождённых им процессов и при необходимости «снимать» их — досрочно прекращать исполнение. 
- 
-Понятно,​ что в обоих моделях в каждом процессе,​ если он нелинейный,​ проходится один маршрут. Также понятно,​ что в ранговой модели ни один процесс,​ кроме первичного,​ не м.б. «зацикленным». 
- 
-В определении действия мы видим повторяющуюся структуру. Хотя бы одно действие всегда записано в вершине;​ но можно записать два и больше. Это удобно для смысловой группировки цепочки действий в одной или более вершинах. При этом считаем,​ что действия выполняются в том порядке,​ как они написаны в вершине. 
- 
-Что такое маршруты процесса?​ Это возможные цепочки действий от начала до конца процесса. На дракон-схеме маршрут получается,​ если пройти путь от начала её к концу. Если такой путь м.б. только один, то процесс (и маршрутная структура) //​**линейный**//​. Однако в жизни чаще одного результата можно ( или нужно) достигать разными путями — вспомним о существовании условий решения задачи. Они м.б. начальными (грубо говоря,​ когда стоит начинать процесс и что при этом нужно «принять по умолчанию») и граничными — что нужно соблюдать в процессе решения (возможно,​ когда прекратить процесс,​ не дойдя до результата). 
- 
-В //​**нелинейных**//​ процессах и структура маршрута нелинейна. Чтобы её выразить,​ используется прежде всего условный (т.н. предикатный,​ как говорят математики) тип вершин. В условной вершине выбирается один из возможных маршрутов. В техноязыке для этого служит виоп ''​Развилка''​. 
- 
-Уточним,​ что в РБНФ-итераторах (как помним из определения РБНФ-метаязыка,​ так называется операция,​ обозначаемая фигурными скобками) N служит обозначением натурального (иногда — целого,​ т.е. включающего и ноль) числа — предела повторений вхождения. Число это каждый раз м.б. разным — на что указывает конкретизирующий индекс при N. 
- 
-В нелинейной схеме «самый-самый» по какому-то критерию (или ряду критериев) маршрут удобно принять за **//​главный//​**. В шампур-методе принято,​ что он всегда идёт по прямой — т.е. через главные выходы всех развилок. Как упорядочиваются остальные маршруты — поговорим дальше. 
- 
-С использованием двух следующих вершин строится дракон-переключатель — иная форма визуализации условия ветвления. 
- 
-Какие конструкции можно строить из этих «кубиков»?​ Чтобы это понять,​ далее рассмотрим следующую группу знаков и конструкций шампур-схем. 
- 
-Детальное определение (раскрытие текста действия) фактически вводит три уровня формальности языка. Мы уже их обсудили выше. 
- 
-В определении развилки мы снова видим разные уровни формальности. Правда,​ здесь выделены только два, дабы не перегружать читателя подробностями. Однако математический уровень существует — обычно представляется в виде функций исчисления высказываний (т.н. предикатов — откуда и название условных вершин в БС-языке). В практике алгоритмизации пока ещё принято «пропускать» этап выделения условных функций. Но для надёжной (гарантоспособной) формализации он необходим — их формулирование даёт возможность понимать логику формирования маршрутов и проверять её. 
- 
-Понятно,​ что уровни формальности содержания вершин д.б. согласованы в пределах схемы (по крайней мере, законченной). Вряд ли есть смысл для исполнителя информатически строгого (реальной машины или её абстракции типа «машины Тьюринга») в действиях и вопросах,​ представленных как функции и/или неформальные предложения... ;-) 
- 
-То же касается и согласования репертуара,​ багажа и реквизита схемы и предполагаемого исполнителя при должном уровне формальности языка. 
- 
-==== Азбука ДРАКОНа-1 — сложные схемы и их описание ==== 
- 
-{{ :​jazyk:​soobschenija_o_jazyke_i_metode_ischislenija_ikon:​st_drakonsu_-_ocenka_texnojazyka_i_ishm_html_4df6cdb4.gif?​ |}} 
- 
-Сначала — замечания по синтаксису. Прежде всего видно, что мы ввели визуальный эквивалент РБНФ. Здесь он описывает повторы отдельных частей схем (знаков Д17 и Д18). Как — сказано выше в «Отступлении о синтаксисе...». 
- 
-Снова вернёмся от представления к содержанию. С комментариями всё понятно. Или они указывают,​ «куда подшили» (скобочные),​ или «куда вставили» (вершинный). Вообще комментарий в формальном смысле - это часть текста,​ которую можно удалить без изменения значения (для исполнителя). Проще говоря — это часть описания,​ нужная для сочинителя,​ а не для исполнителя (второму она м.б. и непонятна). Но вершинный комментарий на практике иногда используют для размещения части описания,​ не выразимой на языке шампур-схемы. Это эргономически не лучшее решение — и м.б. только как временное в процессе построения полноценной системы языков (как описано в завершающем разделе статьи). 
- 
-Далее у нас определены конструкции для нелинейных связей в схемах техноязыка. Причём подробно — вместе с вершинами. Поскольку в них выражена своя часть смысла — и нам интересная именно в связи с построением и чтением схем. После изучения языка этот смысл понятен — поэтому на практических схемах вершины можно не показывать (как и делается в книгах по техноязыку). Вот чего там не делалось (по крайней мере, до 2011 года :)) - это объяснения их смысла... 
- 
-Петля цикла, как мы видим — в некотором смысле пара для развилки — там вершина-разветвитель,​ здесь — соединитель. Она и используется в паре — направляя побочный выход развилки выше её входа по шампуру — в конструкциях циклических атомов техноязыка (об атомах поговорим в следующем разделе). По конфигурации это тот же знак, что в книгах. Только добавлен вариант,​ зеркальный относительно вертикали (зачем — будет ясно далее). 
- 
-А вот гребёнок в исходном определении техноязыка читатель не найдёт. На их месте определяется как знак петля силуэта. Это - следствие структурного анализа шампур-схем — т.е. целесообразного выделения их частей. В самом деле, конструкции ветвления (и соответствующие атомы техноязыка),​ как можно видеть,​ содержат такие гребёнки. И при их отсутствии в словаре получается,​ что ветвление частично строится непонятно из чего... :-) Тогда как петля силуэта м.б. построена как раз из гребёнок и петли цикла — только в зеркальном отражении (для того оно и введено в алфавит). Как всё это делается — рассказано после раздела об атомах. 
- 
-==== Азбука ДРАКОНа-1 — кое-что для реальных исполнителей алгоритмов ==== 
- 
-Ну и третья порция определений — остальные вершины исходного алфавита. ​ 
- 
-{{ :​jazyk:​soobschenija_o_jazyke_i_metode_ischislenija_ikon:​st_drakonsu_-_ocenka_texnojazyka_i_ishm_html_m3378fbd9.gif?​ |}} 
- 
-Здесь достаточно пёстрое собрание. Общее в них то, что синтаксис содержания строго задан — от уровня формальности зависит разве что состав текста (добавляются кое-где детали). В силу же различий можно выделить следующие группы. ​ 
- 
-Ввод и вывод представляют случаи обмена со внешней средой процесса (окружением исполнителя). В сущности,​ это разновидности действия - как и Полка действия. 
- 
-Полка данных представляет псевдооператор. Он никаких действий при исполнении вызывать не должен - но согласно его содержанию определяются места для величин и, возможно,​ записываются их начальные значения. 
- 
-Вершины-боковики представлены виопом Формальные параметры — он добавляет к заголовку схемы параметры вызова процесса как процедуры (вставки). Сама Вставка имеет вид действия. Только это действие расписано как отдельный визуал-вставка. А эта вершина показывает,​ откуда в данном визуале нужно совершить,​ как говорит Паронджанов,​ «акробатический прыжок» - перейти к исполнению вставки. При этом как раз параметры,​ перечисленные как формальные,​ получают реальные значения,​ используемые при работе вставки. И становятся фактическими. 
- 
-Ещё один момент — кроме вызова,​ происходит и возврат. А он возможен (на то же место),​ если визуал-вставка имеет нормальное завершение (основной выход). Бывают и процессы «зацикленные» - сочиняемые без него (исключения не в счёт — они не обязаны вернуть управление именно по месту вызова). Если вызвать такой процесс — то продолжить работу вызывающего по логике вставки будет невозможно — ведь условием этого является возврат управления («рабочей точки») из вызванного. Здесь мы сталкиваемся с необходимостью различных «рабочих точек» для логически связанных процессов. 
- 
-В таком случае используют механизмы,​ специально предназначенные для неиерархических систем процессов. В техноязыке они представлены в дополнении для т.н. реального времени (ДРАКОН-2). ​ 
- 
-==== ДРАКОН-2:​ реальное время и его азбука ==== 
- 
-Время при моделировании в информатике протекает дискретно,​ по шагам алгопроцесса;​ на каждом шаге исполнитель совершает целостное действие,​ изменяющее объекты процесса и обстановку в целом. Его категории можно выделить так. Положим,​ что имеется конечный набор «обстоятельств времени» алгопроцесса,​ а при алгоритмизации конкретной задачи учитывается большая или меньшая их часть. Тогда можно построить следующую иерархию информатического времени:​ 
- 
-  * //​абстрактное//​ – временные соотношения в описании алгопроцесса игнорируются (предполагая,​ что процесс и каждый его шаг в любом случае начнётся и закончится тогда, когда нам это нужно, исходя из цели и условий обстановки);​ 
- 
-  * //​условное//​ – принимается во внимание,​ что шаги процесса имеют конечную длительность,​ а среда взаимодействия исполнителя процесса – определённую динамику;​ поэтому нужно контролировать время выполнения процесса и привязывать начало операторов взаимодействия (ввода-вывода) к определённым моментам;​ 
- 
-  * //​реальное//​ – также учитывается,​ что процесс может исполняться не сам по себе, а во взаимодействии с другими процессами,​ а исполнитель может одновременно выполнять не один, а несколько процессов,​ ведущих к различным целям (в общем случае ряд систем процессов распределяются между рядом координированных исполнителей);​ поэтому нужно обеспечивать межпроцессное взаимодействие и распределение работ между исполнителями. 
- 
-В условном времени мы можем построить модель исполнения алгоритма — т.н. //​**циклограмму**//​. На ней все действия упорядочены по оси времени. Из циклограммы ясно, когда чем исполнитель загружен по данному алгопроцессу. А в окружении все действия исполнителя считаются вызывающими тоже известные по содержанию и времени процессы. 
- 
-В реальном времени действует совершенно иной принцип — сочинитель не должен определять порядок действий во времени. Течение процесса определяется только отслеживаемыми исполнителем данными — т.е. величинами данного процесса и, возможно,​ какими-то дополнительными данными состояния исполнителя и его окружения. Что происходит в окружении (и в самом исполнителе кроме работы с величинами данного алгоритма) — определяется только по значениям величин состояния. Главный теоретический принцип здесь — шаги сочиняемого алгопроцесса и любых других могут перемежаться в любом порядке. И если мы уж хотим анализировать исполнение в реальном времени — то надо все эти порядки и рассматривать. И определять,​ какие из них ведут к нужным результатам,​ а какие нет. А дальше думать,​ можно ли исключить каждый такой порядок и как? И если нельзя,​ то как его обнаружить при исполнении и какие реакции заложить,​ чтобы результаты были всё-таки наиболее благоприятными (или хотя бы наименее неблагоприятными)?​.. 
- 
-Как правило,​ «школьные» информатические задачи составляются для абстрактного времени. Но и в жизни, если это возможно,​ нужно стремиться к тому, чтобы «привязать» шаги алгопроцессов к конкретным моментам времени. 
- 
-''​Пример. Хорошая иллюстрация деятельности в реальном времени – сцена из известного фильма Чаплина «Великий диктатор»,​ где герой-парикмахер бреет клиента под музыку Брамса,​ привязывая определённые фазы бритья к музыкальным фразам. :​-)''​ 
- 
-Здесь мы обсуждали,​ конечно,​ логическое время; существует и физическое. В информатике оно отражается через состояния т.н. датчиков времени – объектов данных,​ значения которых формируются периодическими физическими процессами (колебаниями в генераторе синхронизации,​ моментами прохождения процессами во внешней среде определённых состояний). Эти значения математически образуют ось времени – числовой ряд (обычно целый) и при необходимости пересчитываются по определённой системе счёта времени (календарю);​ дискретность алгопроцесса ведёт к тому, что можно сопоставить его шагам отрезки на оси времени;​ эти отрезки можно упорядочивать. За качественным пониманием физического времени,​ естественно,​ нужно обратиться к физике. 
- 
-Предложенный создателем техноязыка состав лексики представлен на рисунке. 
- 
-{{ :​jazyk:​soobschenija_o_jazyke_i_metode_ischislenija_ikon:​st_drakonsu_-_ocenka_texnojazyka_i_ishm_html_5f4e1c9a.gif?​ |}} 
- 
-Первые четыре оператора представляют средства описания алгопроцессов,​ исполняемых в условном времени. Здесь заметим лишь, что в нелинейном алгоритме пуск таймера может нахдиться на маршруте,​ который реально не будет исполнен. Тогда первый же пускаемый по этому таймеру оператор,​ встретившийся дальше по ходу исполнения,​ будет блокирован. Так что процесс,​ управляющий таймером,​ должен как-то разрешать эту ситуацию (ясно, что это опять будет исключение). Отметим,​ что у этого алгопроцесса своя «рабочая точка» - т.е. он образует с алгопроцессами,​ синхронизируемыми по таймерам,​ систему (диспозитивную). 
- 
-Следующий оператор уже является средством описания реального времени. Конкретно для данного случая вместо вставки используется создание экземпляра процесса,​ представленного другим визуалом. Это представляется как посылка оператором Д25 на имя визуала сообщения «Пуск» (возможно,​ с дополнительным идентификатором экземпляра — скажем,​ номером по порядку создания). Созданный визуал становится «партнёром»,​ сотрудником и родительского,​ и всех визуалов,​ порождённых таким же образом. 
- 
-Конечно,​ визуал-сотрудник не обязан быть «зацикленным». Тогда обычный (конечный) экземпляр при нормальном исполнении отработает до конца, после чего «снимется» (перестанет использовать ресурсы исполнителя),​ и взаимодействие с ним других процессов (ещё работающих) станет невозможным. Если же такое произойдёт (т.е. какой-то процесс отправит что-то на имя «снятого» процесса) — это также должно считаться исключением. 
- 
-Заметим,​ что эти языковые средства разрабатывались автором техноязыка для конкретных задач и исполнителей (бортовых комплексов управления ракетами). С т. зр. теории алгоритмических процессов (и их систем) они не полны. Но для многих задач (допускающих математическое представление и информатизацию с теми же условиями) их вполне достаточно. Развитие же языка — дело будущего (и объективно уже идущий процесс). Рассмотрим некоторые его направления. 
- 
-==== Дракон-лексика:​ уточним состав и смысл ==== 
- 
- 
-=== Вставка как активная подстановка схем === 
- 
- 
-Процесс,​ описываемый вставкой,​ м.б. алгоритмом-функцией — возвращать какое-то значение по завершении. Можно назвать его фактическим параметром возврата. ​ 
- 
-Также в программировании у вставки м.б. т.н. приёмник — параметр-сообщение одного из заранее заданных типов. Тогда в дракон-модели определяют визуал-вставку для работы с каждым типом приёмника — а при исполнении вызывается вставка,​ определённая для нужного типа. Фигурально говоря,​ на десерт у нас м.б. яблоки,​ апельсины и арбузы. Каждый из них можно съесть — но сам процесс будет в чём-то различаться. Вот программисты и придумали способ описания подобных различий с учётом свойств исполнителя-машины... :-) 
- 
-Между прочим,​ всё это в техноязыке требует текстового описания — поэтому у вставки столько текстоэлементов. И это не все возможные — исполнение системы со вставками более сложно,​ чем одного процесса,​ содержащего тела всех вставок по местам подстановки. Визуал-вставка может менять и другие переменные величины,​ доступные и в вызывающем,​ и в других визуалах — это называется побочным эффектом. А может не менять,​ а просто пользоваться их значениями — если это не запрещено средствами языка. Если все величины всех визуалов ранговой дракон-модели можно использовать и менять в любом из этих визуалов — говорят,​ что у них единая область видимости. Между такой моделью и эквивалентным ей единым визуалом нет разницы при исполнении. Если в процессе-вставке и/или в головном процессе нельзя менять и/или читать величины,​ определённые за его пределами — говорят о различных областях видимости. В детали мы вдаваться не будем. Кстати,​ их нужно определять в рамках декларативного знания о системе процессов — т.е. за пределами техноязыка. 
- 
-Для примера ниже показано определение «акробатического прыжка» для одного из современных языков программирования... 
- 
-{{ :​jazyk:​soobschenija_o_jazyke_i_metode_ischislenija_ikon:​st_drakonsu_-_ocenka_texnojazyka_i_ishm_html_m29f1f3a2.gif?​ |}} 
- 
-...и определения знаков,​ введённые для её записи:​ 
- 
-{{ :​jazyk:​soobschenija_o_jazyke_i_metode_ischislenija_ikon:​st_drakonsu_-_ocenka_texnojazyka_i_ishm_html_m4bb9e298.gif?​ |}} 
- 
-Особо разъяснять эти рисунки мы не будем — для того и визуализация,​ чтобы перевести всё, что можно, в графику и поясняющий текст. ;-)  
- 
-=== Разветвители и соединители в гребёнках === 
- 
- 
-Теперь рассмотрим смысл разветвителей и соединителей. Для этого введём ещё две шампур-вершины:​ 
- 
-{{ :​jazyk:​soobschenija_o_jazyke_i_metode_ischislenija_ikon:​st_drakonsu_-_ocenka_texnojazyka_i_ishm_html_7f5accf5.gif?​ |}} 
- 
-Как упомянуто во введении,​ их можно понимать как БС-соединители в новой роли — внутрисхемных «контактов». Именно эта роль — оригинальное решение шампур-метода. Ибо оказывается,​ что с их помощью можно описать реализацию не только вершин,​ но и схем в целом. Правда,​ эти возможности в исходном ШМ использованы не полностью,​ но это нетрудно исправить. 
- 
-Начнём с разветвителей:​ 
- 
-{{ :​jazyk:​soobschenija_o_jazyke_i_metode_ischislenija_ikon:​st_drakonsu_-_ocenka_texnojazyka_i_ishm_html_m4b5432cb.gif?​ |}} 
- 
-Здесь применён ещё один приём записи текста — совмещение формального и неформального определений. Второе при этом выступает как т.н. «формальный комментарий» к первому. Т.е. структура текста вершины принимает вид: 
- 
-<​осн-текст-1>​['​ ≡ '<​внутр-комм-1>​]{<​разд-ед><​осн-текст-i>​['​ ≡ '<​внутр-комм-i>​]} 
- 
-Здесь осн-текст — это текст любой вершины,​ данный по её определению. Т.е. внутренний комментарий можно добавить к каждой вершине,​ где сочинитель считает необходимым (для читателя;​ кстати,​ в этой роли он может выступать и сам :-)). 
- 
-Первая идея, представленная на схеме — условная вершина есть эквивалент дракон-переключателя на два направления. При этом развилка — просто иное представление разветвителя гребёнки (верхней). На момент проверки условия имеют переменные выбора нужные значения (условие развилки истинно) — идём на главный выход. В противном случае — на побочный. Можно и наоборот — идти на главный по ложности условия. В техноязыке элементы разветвителя сокращаются,​ и получается тот вид, который принят в определении языка. 
- 
-С т. зр. синтаксиса,​ такое приравнивание даёт важный результат,​ представленный в нижнем ряду схем. А именно — ответы на вопрос развилки не обязательно понимать как тексты её выходных рёбер (плеч). Можно представить их и через контактные вершины — единообразно с переключателем. Справа дан вариант,​ сокращённый аналогично переключателю. 
- 
-Разберёмся теперь с семантикой — что значит соединитель?​ Понятно,​ что некий переход по совпадению имён контактов. Его важное свойство — возможность и в случае,​ когда соединяемые части схемы не лежат на одной линии (не принадлежат линейному порядку,​ как говорят математики). Линия вертикали между соседними вершинами на шампуре тоже представляет переход — но его можно совершить только в линейном порядке. Можно назвать его естественным (Паронджанов при обсуждении шампур-метода говорил о «сочленении» в этом случае) — он реализуется механизмами исполнителя (скажем,​ в адресной машине по окончании текущей команды выбирается следующая записанная за ней в памяти,​ что обеспечивается устройством процессора). Межконтактный же переход имеет смысл безусловного (БП) — совершаемого не по порядку,​ а по имени-метке некоторой точки структуры. 
- 
-Понимая это, рассмотрим представления вершин-соединителей:​ 
- 
-{{ :​jazyk:​soobschenija_o_jazyke_i_metode_ischislenija_ikon:​st_drakonsu_-_ocenka_texnojazyka_i_ishm_html_79163591.gif?​ |}} 
- 
-Здесь мы видим использование семантики БП. В частности,​ очевидно,​ что команд с одной меткой м.б. много, а сама метка требуется только одна. По такому принципу можно представить и нелинейные знаки целиком с учётом расположения на диосцене. В частности,​ петлю цикла: 
- 
-{{ :​jazyk:​soobschenija_o_jazyke_i_metode_ischislenija_ikon:​st_drakonsu_-_ocenka_texnojazyka_i_ishm_html_1e06865d.gif?​ |}} 
- 
-Из записи справа,​ помимо прочего,​ можно понять,​ зачем для вершин Имя/​Адрес определено необязательное поле (с пунктирным контуром). Оно указывает,​ что переход по данному имени происходит против шампура,​ т.е. образует цикл. А текст поля сообщает,​ какой цикл в данной вершине Адрес начинается и какой цикл в данной вершине Имя заканчивается. Начинаться и/или заканчиваться в одной вершине может более одного цикла, если эти циклы т.н. вложенные — входят друг в друга, образуя своего рода «матрёшку». 
- 
-Читателю,​ думается,​ нетрудно будет «достроить» структуру цикла, используя описания развилки выше. 
- 
-Для нижней гребёнки представление очевидно — добавляется столько команд перехода (вершин Адрес),​ сколько «зубцов». Это можно понять из правила сокращения безусловных переходов,​ образующих цепочки. Оно показано на рисунке (для пары смежных БП-соединителей):​ 
- 
-{{ :​st_drakonsu_-_ocenka_texnojazyka_i_ishm_html_m58647463.gif?​ |}} 
- 
-Для верхней всё не столь тривиально — но это имеет смысл рассмотреть отдельно для различных случаев употребления. Не забывая,​ как обычно,​ о тексте... 
- 
-Конечно,​ содержание вершин и/или линий не всегда нужно учитывать. Поэтому дальше мы будем использовать и абстрактные схемы («слепыши»). 
- 
-Итак, мы кое-что знаем о визуализации разветвляющихся и циклических конструкций алгоритмов. А какие конструкции нужно строить?​ По теории алгоритмов,​ любой алгопроцесс можно построить из структур следования (цепочек вершин типа действия) и циклов. Менее строго можно допустить ветвления. На сей счёт была доказана т.н. теорема Б<​о|ё>​ма-Джакопини. Интересующиеся могут найти её в[[http://​www.ozon.ru/​context/​detail/​id/​3056680/​|этой книге]] (как можно видеть,​ мы для примера применили РБНФ к «обыденному») тексту — чтобы указать на разночтение имени одного из соавторов :-)). 
- 
-Такое предпочтение циклам не случайно и в плане сложности описания. В самом деле, можно сказать что «цикл — это способ записать меньше,​ чем на самом деле будет сделано» (написали в теле одну цепочку команд — а выполнится она столько раз, сколько нужно). Тогда как «ветвление — способ записать больше,​ чем будет сделано» (написали и такую цепочку,​ и такую — а выполнится каждый раз только одна). 
- 
-И как же строятся схемы? Шампур-метод устанавливает правила на этот счёт — одни более строгие,​ другие менее. Начнём с более строгих — которые составляют основу метода и при некотором «графитном» понимании задачи сочинителем достаточны для вывода схем. 
- 
-===== Вложение и структурные изменения на графах ===== 
- 
-В текстовом программировании известны применения вложения в той или иной форме (например,​ в архитектуре и программировании отечественных машин семейства «Эльбрус»;​ см. [[http://​forum.oberoncore.ru/​viewtopic.php?​p=52411#​p52411|это сообщение]]). ​ 
- 
-В рамках ШМ это понятие было применено к графам. При этом среди рёбер графа выделяются такие, что допускают замену на тот или иной подграф — т.н. //​рёбра ввода//​. Этот подграф называется //​атомом//​ и всегда имеет один вход и один выход; оба они представлены рёбрами ввода, между которыми располагается смысловая часть — так сказать,​ «ядро» атома. Оно м.б. единственной вершиной или также подграфом (для ДРАКОНа - типа ветвления или цикла). Во втором случае рёбра ввода также м.б. в «ядре». 
- 
-В исходном ШМ на ребре ввода определена т.н. //​валентная точка//​ — вспомогательная вершина,​ на месте которой ребро как бы можно разорвать и вставить в разрыв атом так, что части разорванного ребра становятся продолжениями рёбер вставляемого атома. 
- 
-В процессе обсуждения ШМ было предложено называть валентные точки //​точками ввода//,​ а также отказаться от определения этих точек как вершин и считать само ребро допускающим ввод. 
- 
-Принцип вложения (ввода атома) показан на рисунке ниже. 
- 
-{{ :​jazyk:​soobschenija_o_jazyke_i_metode_ischislenija_ikon:​proekt_statja_-_ocenka_texnojazyka_i_ishm_kak_razvitija_stbs_html_m5d093cb2.gif?​ |}} 
- 
-==== Операция ввода атома в шампур-методе ==== 
- 
-Для исчисления схем на конкретном шампур-языке задаются множества атомов и заготовок схем. На каждом определяются рёбра ввода. При этом для более удобного представления ветвления на множество вариантов Паронджановым предложена атомарная структура «переключатель». 
- 
-Кроме вложения,​ в ШМ определены также операции изменения топологии схемы, не нарушающие структурности. Это добавление/​удаление варианта переключателя,​ удаление конца схемы («зацикливание» алгоритма в целом — от начала до конца),​ боковое присоединение (добавление вершины-модификатора к другим вершинам). 
- 
-Схематически можно представить сказанное о вершинах,​ атомах и заготовках,​ как на следующих рисунках. 
- 
-{{ :​jazyk:​soobschenija_o_jazyke_i_metode_ischislenija_ikon:​proekt_statja_-_ocenka_texnojazyka_i_ishm_kak_razvitija_stbs_html_f52ad4a.gif?​ |}} 
- 
-{{ :​jazyk:​soobschenija_o_jazyke_i_metode_ischislenija_ikon:​proekt_statja_-_ocenka_texnojazyka_i_ishm_kak_razvitija_stbs_html_30622066.gif?​ |}} 
- 
-{{ :​jazyk:​soobschenija_o_jazyke_i_metode_ischislenija_ikon:​proekt_statja_-_ocenka_texnojazyka_i_ishm_kak_razvitija_stbs_html_1fc6b470.gif?​ |}} 
- 
-Здесь также представлены основные структурные операции (кроме удалений). 
- 
-===== Упорядочение маршрутов:​ чем правее,​ тем... придумай сам ===== 
- 
-Принципы ШМ эргономически выгодно отличаются от принятого в блок-схемах порядка,​ при котором:​ 
- 
- * выходы развилок (предикатных вершин) обычно направлены в разные стороны от оси входа; 
- 
- 
-  * вход и выход вершин следования не требуется располагать на одной оси (а обычно даже их оси составляют прямой угол, т.е. вершина в то же время является точкой излома следования;​ часто это делают,​ чтобы «сэкономить» на звене вертикали перед/​после излома);​ 
- 
- 
-  * возможны наклонные линии связей,​ часто «ступеньки» на них, порой даже «обратное следование» - загиб вертикали против направления от начала к концу схемы. 
- 
-Иногда такую организацию блок-схем называют «анархической». Она критикуется рядом авторов,​ скажем,​ Б. Мейером в [[http://​forum.oberoncore.ru/​viewtopic.php?​p=69170#​p69170|"​Почувствуй класс",​ Гл. 7]]. 
- 
-По сути, в стандартах на БС и не существует чётких правил упорядочения элементов и подсхем. Тогда как ШМ, в общем-то,​ и есть система таких правил,​ только данная в математическом смысле не формально («что есть правильная схема»),​ а конструктивно («как построить правильную схему из правильной заготовки»). 
- 
-Каким же образом в шампур-схемах уходят от «анархии»?​ Для этого и существуют нелинейные конструкции. Любую из них можно структурно подразделить на два типа частей:​ 
- 
- 
-  * тела вертикалей — то, чем мы «нагрузили» составной атом (вложенные атомы, если мы рассматриваем матрёшку) — поэтому можно тела называть ещё //​**нагрузкой**//;​ 
- 
- 
-  * «каркас»,​ остающийся,​ если мысленно отбросить нагрузку — будем называть его //​**кроссом**//​. 
- 
-Какое-то тело может отсутствовать — тогда говорят,​ что эта вертикаль не нагружена. Атомы определены так, что все вертикали сразу нельзя оставлять без нагрузки. Т.е. в завершённой схеме не м.б. конструкции из одного только кросса — если понимать её как описание алгоритма,​ то это был бы т.н. пустой оператор. 
- 
-В линейной схеме также можно условно выделить кросс — если отбросить все вершины,​ то останется цепочка звеньев вертикали;​ крайние сверху и снизу звенья одним своим концом будут присоединяться к заголовку и концу соответственно. 
- 
-Рассмотрим кросс составного атома в общем виде — предполагая отбрасываемую нагрузку призвольной. Удобно показать его, как говорят,​ //​**инвариантно**//​ — т.е. «для всего сразу»,​ выделяя общее для всех разновидностей предметов и частное для тех или иных разновидностей. В данном случае мы совмещаем прежде всего переключатель и переключающий цикл: 
- 
-{{ :​st_drakonsu_-_ocenka_texnojazyka_i_ishm_html_m8391685.gif?​ |}} 
- 
-В данном случае частное в инварианте представлено через графит-выбор подсхем по ИЛИ, а также подведением под РБНФ. 
- 
-Верхняя схема построена из лексики техноязыка,​ как мы её дали ранее. Нетрудно выделить в кроссе верхнюю и нижнюю гребёнки и петлю цикла; здесь они напрямую не связаны -только через другие вершины или более крупные части конструкции. А что между ними и как всё это работает?​ Это можно понять,​ раскрывая смысл соединителей и разветвителей по образцу,​ также предложенному ранее. Что и сделано на нижней схеме. 
- 
-Нетрудно видеть,​ что вершины ''​Вариант''​ — это просто именные части БП-контактов на выходах разветвителей верхней гребёнки. А адресные части вместе с логикой развилок мы не показываем на реальных схемах. Эргономически это правильно — позволяет сосредоточиться на значениях для выбора варианта. Если же показать,​ как здесь — то видно, что обычный цикл тоже можно получить из данной структуры. Надо только исключить при переходе к циклу и первый вариант переключателя,​ а также определение переменной выбора. Так у нас получится цикл ПОКА. Чтобы показать реализацию гибридного цикла (или цикла ДО), инвариант нужно дополнить,​ как показано на следующей схеме. 
- 
-{{ :​st_drakonsu_-_ocenka_texnojazyka_i_ishm_html_m7696e5cc.gif?​ |}} 
- 
-В текстовых ЯВУ обычно цикл ПОКА записывается через ключевые слова ''​WHILE-DO-[W]END'',​ а цикл ДО — через ''​REPEAT-UNTIL''​. 
- 
-На этих схемах мы снова пользуемся понятием позиции,​ введённым в первом разделе. Здесь «белый ящик» в некоторых позициях задаёт варианты подстановки части в схему. Причём мы не только помещаем варианты внутрь знака «белого ящика выбора» (области с текстом условия выбора — в данном случае по ИЛИ) — но иногда «подключаем» части к знаку позиции снаружи,​ выделяя их цветом и толщиной линии. Это удобно,​ если конфигурация частей сложна — тогда бы и «белый ящик» пришлось делать сложной формы, что неудобно. Интуитивно понятно,​ как найти конец позиции — он там, где начинается обычное оформление графики схемы. 
- 
-В нашем случае вне позиций остаётся и часть схемы. А «белые ящики выбора» участвуют в определении инвариана. Как и до этого, частное в инварианте представлено также через графит-выбор подсхем по РБНФ. 
- 
-Снова возвращаясь от синтаксиса к содержанию,​ видим разницу в том, что в обычном цикле не нужен и первый вариант переключателя. Можно сказать и иначе — в схеме на этом месте будет следующий шампур-блок,​ никакого отношения к рассматриваемой конструкции не имеющий. ​ 
- 
-Как видим, «подвал» составного атома (и конструкции на его базе) в любом случае имеет смысл кратных БП. 
- 
-Обратим внимание — изломы возможны только в гребёнках. А направление следования по вертикалям везде одинаковое — от начала к концу схемы. Оно ещё называется «по шампуру». Только в петле цикла есть вертикаль,​ по которой следуют против шампура — для того эту петлю и определили как единицу лексики техноязыка. 
- 
-А что будет, если убрать из схемы и первую развилку?​ В разветвлённом варианте останется шампур-блок (возможно,​ ограниченный с начала и с конца контактами-БП) — или просто звено вертикали. А в циклическом — либо также звено, либо два шампур-блока (подтела ДО и ПОКА), разделённых контактом,​ либо один из них. Причём всё это «зациклено» - т.е. раз войдя в полученную конструкцию,​ исполнитель будет постоянно проходить по ней — пока либо машину не выключить,​ либо — при наличии процесса-партнёра,​ способного управлять исполнением,​ — пока этот процесс не «снимет» зациклившийся. 
- 
-В алгоритмизации,​ однако,​ такое «зацикливание» м.б. и целесообразным. Часто тот же «первый среди равных» процессов-партнёров зацикливают — чтобы он управлял другими процессами с момента своего запуска до выключения машины. Поэтому и в языки программирования вводят иногда такой цикл в явном виде — т.н. конструкция ''​LOOP-END''​. Чаще допускают выход из «зацикливания» - тогда получается конструкция ''​LOOP-EXIT-END''​. Визуализировав её, можно видеть,​ что это обычный цикл: 
- 
-{{ :​ciklsubstproc_html_m136ff908.gif?​ |}} 
- 
-Как видим, для этого достаточно сделать рокировку плеч EXIT-развилки. 
- 
-Возможно и несколько выходов из цикла. Но при этом конструкция получается неструктурной,​ если не соблюдены некоторые ограничения на следование их развилок. Обсудим их в разделе о структурной алгоритмизации. 
- 
-В текстовом виде цикл LOOP есть далеко не вовсех языках. Но можно его «эмулировать» - выразить через конструкции,​ имеющиеся в этих языках. Достаточно взять обычный цикл (гибридный,​ ПОКА, ДО) и записать его условие как заведомо истинное (можно просто записать константу логического типа со значением,​ соответствующим ответу «да»). 
- 
-В сравнении с БС упорядоченность шампур-схемы можно видеть на рисунках ниже. 
- 
-{{ :​jazyk:​soobschenija_o_jazyke_i_metode_ischislenija_ikon:​part_viz_know_html_m5dd068a.gif?​ |}} 
- 
-{{ :​jazyk:​soobschenija_o_jazyke_i_metode_ischislenija_ikon:​part_viz_know_html_2ef165be.gif?​ |}} 
- 
-Шампур-схема закономерно асимметрична. Это даёт возможность показать упорядоченность маршрутов по какому-то критерию. Не всегда такой критерий нужно или можно определить по смыслу схемы; в этом случае порядок м.б. произвольным или введён по какому-то абстрактному правилу. 
- 
-В то же время запрещение ступенек и загибов сужает возможности компоновки схемы в конкретном формате. Однако это можно понимать как плату за упорядоченность схемы. 
- 
-==== Развилки,​ циклы и варианты использования:​ как сводить маршруты?​ ==== 
- 
-Дракон-схема,​ как и БС, математически есть т.н. //​**сводимый граф**//​. Это значит,​ что у неё один конец, куда должны сойтись все маршруты,​ ведущие к нужному результату. Поэтому нужны и вершины-соединители маршрутов;​ пока на них останавливаться не будем. 
- 
-Заметим,​ что можно и не сводить маршруты. Тогда схема нелинейного алгопроцесса будет деревом,​ у которого и главный,​ и каждый побочный маршруты имеют отдельный конец. Также и все цепочки,​ общие для разных маршрутов,​ дублируются. Циклы же разворачиваются — т.е. путь в цикле повторяется подряд столько раз, сколько итераций цикла (проходов по нему) будет при исполнении. Обычно заранее можно предсказать только максимальное и минимальное число итераций — так что и при описании развёрнутого цикла без РБНФ не обойтись. 
- 
-Читать такую схему сложнее физически из-за большего объёма;​ но иногда она нагляднее показывает логику процесса. Кроме того, это промежуточное представление на пути к отдельному описанию каждого маршрута (которое часто возникает в ходе сочинения и допускается в формализации в виде т.н. //​**вариантов использования**//​ — англ. use cases). Такой вариант — это конкретная реализация описания нелинейного процесса,​ его развёртка «рабочей точкой» (как ещё говорит Паронджанов,​ «дракон-поездом»). 
- 
-Каждый вариант нелинейного процесса — это соответствующий маршрут,​ оформленный как линейная дракон-схема под общим именем процесса (возможно,​ с добавлением какого-то индекса маршрута для удобства различения). Представление его на техноязыке - любая дракон-схема с т.н. «хвостами» - неприсоединёнными побочными выходами развилок. Примером может служить схема на с. в «Занимательной информатике» Паронджанова:​ 
- 
-{{ :​jazyk:​soobschenija_o_jazyke_i_metode_ischislenija_ikon:​marshrut_kak_ds_s_xvostami_-_ill_zaniminfor_.png?​200 |}} 
- 
-Заметим,​ что в книге такая схема трактуется как логически ошибочная. Так и есть — если считать её завершённой,​ а не развёрткой отдельного маршрута. В то же время способ сочинения «визуалов с хвостами» нужно считать вполне естественным. В самом деле, часто сочинитель описывает реальную деятельность (или проектируемый процесс) отдельно по каждому пути от «дано» к «надо» - обычно начиная с более удобного или уже проверенного. Рассуждая примерно так: «сначала делаем то-то и то-то... тут надо, чтобы выполнилось это — а что будет, если не выполнилось — нас не интересует... потом делаем то-то и то-то... после чего должно иметь место это... » ...ну и т.д. В дальнейшем появляются описания,​ как действовать,​ если что-то не выполняется — и у «хвостов» появляются продолжения. Постепенно (или сразу) «концы сводятся с концами» - определяется,​ какое продолжение ведёт к цели сразу (т.е. на конец всего алгоритма),​ какое должно «втекать» в одно из остальных (и в каком месте) — и дерево превращается в сводимый граф — т.е. в ту же дракон-схему. Которую,​ однако,​ можно снова и «развести» в дерево,​ и «расплести» на маршруты-представления вариантов использования... 
- 
-В отношении синтаксиса уточним,​ что здесь правильно будет оформить ответы на вопросы развилки в вершинах ''​Имя''​ — как мы сделали при [[http://​drakon.su/​ocenka_texnojazyka_i_shampur-metoda#​drakon-leksikautochnim_sostav_i_smysl|раскрытии соединителей и разветвителей]] ранее. Здесь такая вершина при побочном выходе будет обозначать начало маршрута,​ не входящего в вариант использования. Полезно будет и указывать присоединения таких маршрутов — тоже вершинами ''​Имя''​. 
- 
-В случае циклов на схеме маршрута будут «хвосты»,​ ведущие вверх (против шампура) — от побочных выходов условий циклов. Вершина ''​Адрес''​ такого хвоста будет началом петли цикла. И нужно явно указывать конец петли (точку возврата) — также вершиной Имя выше по шампуру. Здесь следует использовать и поля индекса цикла. 
- 
-А что делать,​ если есть «не сводимые» к нужному результату концы? Т.е. продолжения,​ возможные,​ но не ведущие к результату?​ При информатизации их оформляют как т.н. //​**исключения**//​ - «побочные» выходы из процесса. Понятно,​ что надо иметь, куда выходить — значит,​ д.б. первичный процесс,​ где исключение можно обработать. Тем самым также возникает некая система дракон-схем (дракон-модель,​ обсуждавшаяся вкратце [[http://​drakon.su/​ocenka_texnojazyka_i_shampur-metoda#​nachalo_azbuki_drakona-1vrode_kak_v_bs_da_ne_kak_v_bs|здесь]]). Первичный алгопроцесс в зависимости от организации бывает либо вызывающий (вышележащий вплоть до головного),​ либо «родительский» (базовый). Принцип исключений мы описывать не будем — читатель может найти в той же книге Кауфмана (Ч.I, Гл. 8). Если же исключение обработать негде/​нечем — значит,​ система будет работать ненадёжно (может и создать проблемы). 
- 
-Если даже маршруты полностью различны после какой-то развилки — всё равно в дракон-схеме надо их соединить — иначе она не будет сводимым графом. Соединитель тогда ставится прямо перед вершиной ''​Конец''​. 
- 
-А есть варианты использования у линейного алгопроцесса?​ Да, есть единственный вариант — совпадающий со структурой маршрутов всего процесса. В качестве примера можно снова привести схему из «Занимательной информатики»:​ 
- 
-{{ :​linejnyj_algoritm_-_ill_zaniminfor_.png?​200 |}} 
- 
-Заодно здесь можно увидеть понимание схемы как «железной дороги» для «дракон-поезда». 
- 
-Направление движения — это и есть направление «по шампуру». А выделенная белым часть схемы — пример простого шампур-блока. В данном случае он охватывает всё тело схемы. 
- 
-В качестве примера покажем представления маршрутов для схемы, уже рассматривавшейся ранее. Начнём с развёртки сводимого графа в дерево:​ 
- 
-{{ :​st_drakonsu_-_ocenka_texnojazyka_i_ishm_html_15b5f35b.gif?​ |}} 
- 
-Здесь показаны разные возможности сокращённой развёртки цикла. В любом случае они используют РБНФ-итератор. 
- 
-На основе дерева уже нетрудно составить разложение в набор вариантов использования:​ 
- 
-{{ :​st_drakonsu_-_ocenka_texnojazyka_i_ishm_html_1fdbadc2.gif?​ |}} 
- 
-Здесь мы представляем другие варианты оформления РБНФ-графит-подстановки на схеме. Это области различной формы как «ритмические полосы»: ​ 
- 
- 
-  * «габаритная» - прямоугольник,​ описанный около фрагмента схемы; 
- 
- 
-  * «фигурная» - сохраняющая в заданных пределах отступы от габаритов содержания,​ своего рода «маленькое серое платье»,​ следующее внешней форме фрагмента. 
- 
-В данном случае мы сохраняем упорядочение побочных участков вправо. Поэтому более удобна фигурная область. Габаритная же легко накладывается,​ но удобна только при линейной компоновке содержания. 
- 
-Текст итераторов содержит условие повторения тела, направление следования вхождений и запись диапазона повторов вхождения. Условие записано в двух вариантах:​ с русскоязычными названиями логфункций и международными,​ принятыми в ряде прогязыков. 
- 
-Диапазон повторов указан по Б. Мейеру (со знаками регулярных выражений). В данном случае знак '​+'​ указывает на начало числа повторений с единицы (т.к. по схеме у нас гибридный цикл, где тело выполнится хотя бы один раз). При выходе же из цикла выполнится только ПОКА-подтело;​ поэтому оно продублировано отдельно,​ а число повторов уменьшено на единицу в сравнении с предельным числом итераций цикла (Nц). 
- 
-Ответы развилок мы оформили как ответные части БП-контактов,​ как уже делали ранее. 
- 
-=== Отступление:​ варианты использования до нашей эры === 
- 
-Известна следующая притча о борьбе древних греков с персидскими завоевателями. Перед решающим сражением персидский военачальник прислал грекам письмо. Примерно следующее:​ "​Если <​случится то-то>,​ и <​то-то>,​ и <​то-то>​... то мы победим."​ Греки ответили кратко:​ "​Если!"​. И выиграли битву. 
- 
-Что можно сказать об императивном знании,​ заключённом в этих письмах?​ Персы, по сути, предложили вариант использования для предстоящего сражения. Но если взглянуть на него с учётом понимания естественного языка (русского в данном случае),​ то... можно видеть,​ что это вариант,​ понимаемый,​ так сказать,​ как "​неглавный"​... Если его визуализировать - то не как вертикаль,​ а как "​лесенку",​ т.е. со связями каждый раз через побочный выход развилки. А "​хвосты"​ будут от главных выходов каждой развилки. 
-Можно сказать,​ что здесь выражено некое сомнение в успехе дела - т.е. предполагался исход, неблагоприятный для самих персов. А греки своим ответом выразили уверенность в таком же исходе - который для них, разумеется,​ полагается благоприятным. 
- 
-Так что с помощью схем можно выражать не только суть дела, но и определённые аспекты отношения к нему. Думается,​ сочинителям полезно будет иметь это в виду. 
-... Если его визуализировать - то не как вертикаль,​ а как ​ 
-===== Шампур-укладка на плоскости:​ свет и тени силуэта ===== 
- 
-Структуру связей предмета описания не всегда можно показать двумерно без пересечений. В математике схему типа представляющей структуру императивного знания — маршрутов деятельности,​ потоков управления — называют **//​аранжируемым/​устремлённым/​сводимым графом//​**,​ а если в этом графе нет пересечений — говорят,​ что он также **//​планарный//​**. Непланарный же устремлённый граф нужно «уложить» на плоскости,​ устранив пересечения. Конечно,​ необязательно,​ чтобы этот граф имел смысл именно структуры маршрутов алгоритма — речь идёт только о структуре схемы. 
- 
-В текстовой форме связи подразумеваемы совпадением имён начал и концов,​ и пересечения неявны. В форме же схемы они становятся явными. Как считает Паронджанов,​ это затрудняет восприятие структуры. Для исключения этого на шампур-схему как аранжируемый граф как раз и накладывается ограничение планарности. Как же уложить непланарную схему по шампур-методу?​ 
- 
-Непланарная аранжированная схема (в терминах ШМ — //​примитив//​) с пересечениями разделяется веточными соединителями на блоки-единицы укладки — //​ветки//​ — так, что из каждой пары пересекающихся цепей одна оказывается проходящей через подсхему связи веток — своего рода //​**кросс**//​ (по аналогии с сетями связи; в проводке компьютерных сетей часто называется «патч-панель»). Тем самым пересечение устраняется. Уложенная на плоскости с применением соединителей аранж-схема в ШМ называется //​силуэтом//,​ а кросс-подсхема— //​петлёй силуэта//​. 
- 
-Силуэт можно и получать сразу — выводом из заготовки (ШМ-аксиомы). Только такой путь и допустим в ШМ; поэтому Паронджанов рекомендует мало-мальски сложный алгоритм визуализировать сразу как силуэт — чтобы избежать его вывода заново. Заготовка имеет исходно минимальное число веток (две); определены операции добавления/​удаления ветки в силуэт. 
- 
-Пример укладки показан ниже (для той же схемы, на которой демонстрировалась упорядоченность маршрутов). 
- 
-{{ :​jazyk:​soobschenija_o_jazyke_i_metode_ischislenija_ikon:​st_drakonsu_-_ocenka_texnojazyka_i_ishm_html_468e7188.gif?​ |}} 
- 
-{{ :​jazyk:​soobschenija_o_jazyke_i_metode_ischislenija_ikon:​part_viz_know_html_260e06df.gif?​ |}} 
- 
-Видно, что в петлю силуэта можно уложить и петлю цикла. Так образуется т.н. //​веточный макроцикл//​ (далее — ВМЦ). 
- 
-Паронджановым доказаны теоремы о представимости любой структуры маршрутов алгоритма (т.е. фактически любой устремлённой схемы) как силуэта. Т.е. силуэт есть т.н. универсальная программа. 
- 
-В общем виде силуэт тоже состоит из кросса и тел веток. Только ветки здесь бывают не только атомарные (получаемые структурными операциями). Вновь покажем структуру кросса и раскроем его смысл. 
- 
-{{ :​st_drakonsu_-_ocenka_texnojazyka_i_ishm_html_m5c7fa7a8.gif?​ |}} 
- 
-Первая мысль — кросс снова, как и в атомах,​ состоит из верхней и нижней гребёнок и петли цикла. Только петля теперь левая и она соединяет гребёнки между собой. Обычно её рисуют без лишних (в случае такого соединения) изломов. Как — показано сплошными линиями. А если посмотреть на пунктирные части — нетрудно узнать ту форму, которую мы дали её в определении (совместном с правой петлёй). 
- 
-Если раскрыть вершины гребёнок,​ то видим, что по главным входам/​выходам ветки силуэта связаны в цепочку. Однако она представлена как цикл. Это и есть приём силуэтной укладки — чтобы на схеме не появлялись вертикали следования против шампура — вместо них рисуем петлю цикла (где следование против шампура разрешено). В рамках шампур-метода это не фиксируется — он исходно определён для «слепышей». Но сочинитель должен знать — тексты вершин ''​Адрес''​ на главных выходах веток однозначно определяются по правилу «чем правее ветка — тем она дальше по шампуру от заголовка силуэта». 
- 
-Ветки, которые изначально соединены и с верхней,​ и с нижней гребёнками,​ будем называть //​полными//​. В них возможны т.н. //​побочные выходы//​ - не от главной вертикали ветки. Ветку (крайнюю правую),​ которая изначально к нижней гребёнке не присоединена,​ будем называть //​конечной//​. 
- 
-Как получается побочный выход ветки? Это показано внизу. Прежде всего тело ветки д.б. нелинейным. Тогда в нём есть хотя бы одна развилка. Начинающийся от неё побочный маршрут куда-то присоединён в теле ветки (скажем,​ как результат вставки атома). Вершину-соединитель в шампур-методе можно переносить по некоторым правилам (это называется «операциями с лианой»;​ о них вкратце в следующем разделе). В частности,​ можно перенести соединение на нижнюю горизонталь кросса («землю» силуэта). 
- 
-Развилок в теле ветки м.б. много (или не быть ни одной — потому они тоже показаны пунктиром и подведены под РБНФ-итератор с независимым индексом). И побочных выходов можно сделать более одного (при соблюдении ограничений на операции с лианой). Располагаются развилки как на главной вертикали ветки, так и м.б. на любой побочной (если таковые имеются) — поэтому стрелки-указатели направлений итерации на плоскости направлены «на все стороны света». 
- 
-Мысль следующая — силуэт тоже можно зациклить. Мы уже говорили,​ для чего это нужно. Но зациклить можно и часть веток внутри силуэта (или одну ветку). Для этого нужно, чтобы хотя бы один побочный маршрут выходил из тела ветки на нижнюю гребёнку. Тогда он заканчивается вершиной ''​Адрес'',​ текст в которой уже можно выбирать любым из числа имён веток данного силуэта. Если это имя ветки, лежащей левее, чем данная — то получается,​ что нужно идти против шампура. Так что получится уже реальный цикл. Он и называется веточным макроциклом (ВМЦ). Почему «макро» — а потому,​ что ветки задают макроструктуру маршрутов алгоритма. И ВМЦ возможен только с "​шагом ветками"​ - т.е. ни его начало,​ ни конец не могут располагаться внутри тел веток. 
- 
-Вообще //в силуэте недопустимы передачи управления (т.е. связи),​ минующие кросс//​. Это относится,​ скажем,​ к циклам ДЛЯ - их визуальный синтаксис не содержит явной петли цикла. и потому сочинитель легко может "​растянуть"​ такой цикл на две и более веток - что нарушает указанный запрет. 
- 
-Третья мысль — в силуэт можно войти не обязательно с начала. Но и через каждую ветку, если она не внутри ни одного веточного макроцикла. Если определить дополнительные входы на имена веток, либо не входящих ни в один ВМЦ, либо начальных в одном и более веточных макроциклов. 
- 
-Ну и наконец — если все полные ветки из силуэта удалить (РБНФ-продукции допускают такой вариант),​ то получится... примитив. Причём в нашем определении видно — он тоже м.б. как обычным,​ так и «зацикленным». 
- 
-А что за величина ''​b''?​ Это — переменная номера следующей ветки. Здесь мы, в сущности,​ проиллюстрировали сказанное Паронджановым об укладке маршрутов:​ 
- 
-//​Произвольная (неструктурная) программа в ряде случаев не м.б. изображена в виде примитива;​ однако с помощью эквивалентных преобразований,​ допускающих введение дополнительных переменных (идентификаторов ветки),​ она всегда м.б. изображена в виде силуэта. (Как улучшить работу ума..., с. 100).// 
- 
-В присваиваниях значений этого номера мы видим то же самое правило «чем правее — тем дальше» (у Паронджанова дана эквивалентная формулировка:​ «чем правее — тем позже»). 
- 
-Такое детальное раскрытие выявляет интересный факт — выбор-то следующей ветки на самом деле организуется в теле предыдущей. И вершины-разветвители в верхней гребёнке «петли силуэта» на самом деле оказываются фиктивными — ничего они сами по себе не выбирают... 
- 
-Тогда нужен ли нам этот «второй тур выбора»?​ Мы же не претендентов в консерваторию отбираем... или на выборную должность... :-) Из той же схемы по зрелом размышлении можно увидеть,​ что не нужен. Достаточно воспользоваться тем, что имена веток — это метки БП. И на каждую из них можно прямо «разадресовать» команды БП из «подвала» силуэта. Вместо того, чтобы адресовать их все на начало силуэта (имя ''​Сш<​1>''​). Команды,​ находящиеся на главных выходах веток адресуются каждая на следующую ветку, на побочных выходах — на любую ветку по выбору сочинителя. Схему предоставляем сочинить читателю. 
- 
-Силуэтная укладка есть физическое подразделение структуры маршрутов. Петля силуэта представляет связи веток как совокупность возвратных переходов с выходных соединителей на входные. В императивном смысле (для дракон-силуэта) это простые безусловные переходы. Достоинство их силуэтного употребления — в том, что передачи возможны не в произвольные места схемы, а лишь в заданные делением на ветки. Тем самым допускается goto, но также ограниченный — только на начала веток. Недостаток — в том, что переходы явные, и в терминах программирования дракон-силуэт м.б. представлен только на языках с явным БП (на ЯВУ с goto и на машинах с командой jmp-типа). 
- 
-===== Атомарные и лианные структуры:​ когда мудрец похож на обезьяну?​ ===== 
- 
-Известно,​ что минимально для представления любой структуры маршрутов достаточно только следования и цикла; менее строго к этому добавляется также ветвление. По ШМ такое представление очевидно выводимо одним вложением соответствующих атомов. Поэтому можно называть получаемые структуры атомарными — такими,​ что тело схемы всегда можно «без остатка» подразделить на атомы языка этой схемы (и без перекрытия границ подразделений — только с полным вхождением,​ если подразделяется «матрёшка»). Другие упомянутые выше ШМ-операции атомарности тела схемы не нарушают. 
- 
-Все теоретически возможные структуры маршрутов не всегда можно получить только вложением. Имеются в виду структуры с БП — произвольным внутри программы (goto) и изнутри цикла на его начало/​конец (т.н. break/​continue-заменители). Для их представления Паронджановым было введено понятие лианной структуры маршрутов и операция ''​пересадки лианы''​. В результате в техноязыке возможно представить структуры циклов с заменителями,​ и сверх того — некоторые случаи goto в разветвлённых алгоритмических структурах (на ближайшие слева/​справа вертикали). Как результат пересадок лианы могут возникать связи, нарушающие атомарность тела примитива (ветки силуэта),​ и их соединения тоже требуют представления явными БП. 
- 
-В силуэте у ветки возможны и побочные выходы. Они получаются как в результате укладки примитива с пересечениями,​ так и при изначальном сочинении силуэта. Для создания побочных выходов в ШМ включена операция ''​заземления лианы''​. 
- 
-Примерное выполнение этих операций показано на рисунках. 
- 
-{{ :​jazyk:​soobschenija_o_jazyke_i_metode_ischislenija_ikon:​proekt_statja_-_ocenka_texnojazyka_i_ishm_kak_razvitija_stbs_html_m78d9ffef.gif?​ |}} 
- 
-{{ :​jazyk:​soobschenija_o_jazyke_i_metode_ischislenija_ikon:​proekt_statja_-_ocenka_texnojazyka_i_ishm_kak_razvitija_stbs_html_m139b893d.gif?​ |}} 
- 
-Очевидное достоинство такого подхода — техноязык практически нейтрален к структурности алгоритмов («войне языков» высокого уровня по поводу goto и заменителей). Если принять подход противников явных БП в ЯВУ — можно отказаться от операций с лианой и алгоритмизовать только атомарными структурами. Если принять подход сторонников — разрешить лианные операции и структуры. 
- 
-Недостаток разрешения лианных структур — тот же, что в случае силуэтной укладки схемы — необходимость в явных БП для представления соединителей. Аналогично он и преодолевается. 
- 
-А что такого в том, чтобы допустить операции с лианой?​ И почему мы говорим,​ что «мудрец в этом случае становится похож на обезъяну»?​ Может, дело в этом описании сочинения лианных структур у Паронджанова:​ 
- 
-//​Обезьяна,​ сидевшая на дереве,​ поймала свисавшую сверху лиану. Однако нижняя часть лианы приросла к стволу и не поддавалась. Обезъяна перегрызла её зубами,​ уцепилась за конец и мигом перелетела на соседнее дерево,​ где намертво привязала лиану к ветке. (Как улучшить работу ума..., с. 229)// 
- 
-Да нет — если бы дело ограничивалось такой аллегорией,​ это ещё было бы ничего — даже сообщало бы сочинению элемент игры. Что где-то и неплохо... если не заигрываться... ;-) 
- 
-Тут штука в другом — возможность манипулировать соединителями маршрутов так, что получаются неатомарные структуры,​ не располагает к построению алгоритмов,​ скажем так, контролепригодных. Ведь как строится в таком случае алгоритм?​ Сочинитель выводит какую-то атомарную структуру путём ввода атомов. Формулирует содержание линейных участков (в сущности,​ различных видов действий) и вопросы для развилок. Проверяет,​ соответствует ли исполнение этой структуры с таким текстом тому, что нужно для решения задачи. Обычно для этого "​прокручивается"​ процесс исполнения. Мысленно и/или с помощью имитатора-отладчика. 
- 
-Часто причина несоответствия в том, что в процессе вывода понимание решения уточняется — но это нам сейчас не так важно. Важно другое — что делать сочинителю,​ если обнаружено несоответствие?​ Атомарную структуру нужно в чём-то построить заново (в части вывода «слепыша» и/или содержания вершин). При этом обычно нужно рассмотреть схему или крупный блок в целом, со всеми его условиями. А в лианной можно... просто «приклепать» ещё одну или более развилок в тех местах,​ где «не работает». Пересадить лианы от новых развилок и составить их вопросы так, чтобы «пропатчить» каждую локальную проблему несоответствия. И считать на этом сочинение законченным. Если нужно ещё что-то изменить — снова можно «приклепать» неатомарные маршруты-«заплатки»... Главное — по возможности не трогать уже построенную часть маршрутной логики... 
- 
-Но. Если вспомнить смысл вопросов — то это ведь отношения над величинами алгоритма. И ответ при исполнении развилки — да или нет — зависит от значений величин,​ включённых сочинителем в вопрос. Неважно,​ сформулирован ли он уже в виде логвыра или «качественно». И может оказаться так, что на каком-то сочетании значений сами лианные маршруты станут источником новых проблем исполнения. Ведь они сочинялись во многом отдельно от остальной части схемы (и часто друг от друга — ведь решались каждый раз новые локальные проблемы) — а исполняется-то всё как система... А вот узнать,​ возможно ли такое, для неатомарной структуры оказывается проблематично. Фактически тут возможен только полный перебор сочетаний значений величин в вопросах развилок. И определение,​ какие варианты использования для каждого сочетания получаются... 
- 
-Для атомарных же структур разработаны математические методы вывода нелинейных структур маршрутов. Они принимают во внимание значения величин,​ включаемых в условия. Поэтому,​ во-первых,​ вопросы получаются «сразу правильными» (в пределах знаний сочинителя о задаче). Во-вторых,​ выводится схема сразу с текстом. 
- 
-Важно понимать такую вещь. И в атомарных структурах возможны ошибки. По теории вообще не существует «абсолютной правильности» сочинения — можно установить правильность только относительно конкретных требований к решению. Но атомарные структуры естественно выводятся из чётко сформулированных требований — это раз. И наиболее пригодны для проверки на соответствие таким требованиям — это два. 
- 
-Почему так получается?​ Дело в том, что лианная структура перестаёт быть регулярной. В некотором смысле возвращаясь к «анархии» блок-схем. И то, что шампур-метод накладывает физические ограничения (запрет пересечений маршрутов,​ упорядоченность положения выходов вершин-развилок и действий) — не избавляет от логической нерегулярности. Короче,​ эргономичность формы записи (за счёт замены части текста на графику схем) сочетается с «избыточной сложностью» содержания этой записи (потому что не исключили возможностей произвольно строить структуру). 
- 
-Фактически аналогия с обезьяной лежит именно здесь — в логике. Конкретно — в типе мышления. На это указывал один из современных специалистов в алгоритмизации и программировании — Ф.В. Ткачёв. Способ,​ которым выводятся лианные структуры,​ в его классификации относится к низшему — т.н. //​**комбинаторному**//​ — типу. Человек в этом случае действует аналогично обезьяне в известных экспериментах по изучению мышления приматов — видит «конкретный банан» - тянется к нему, не видит — не тянется (а если охота поесть — двигается,​ пока в поле зрения банан не попадёт :-))... Не правда ли, похоже на описанный нами процесс «клепания» маршрутов?​.. 
- 
-Высший тип — //​**рефлексивный**//​ — предполагает,​ что сочинитель критически анализирует возможные варианты и отбрасывает ненужные. При этом «комбинаторность» никуда не девается - просто она управляется рефлексией. И человек может определёнными усилиями и при благоприятных обстоятельствах перейти от первого типа ко второму. Подробнее можно узнать [[http://​forum.oberoncore.ru/​viewtopic.php?​p=64991#​p64991|здесь]] (Ткачёв выступает под псевдонимом Info21). 
- 
-Ну и как же это делается?​ Удобно будет раскрыть суть структурной алгоритмизации в отдельном разделе. 
- 
-===== Структурная алгоритмизация и шампур-метод:​ сочинитель становится мудрецом ===== 
- 
-Поговорим о том, как получается,​ что соединители маршрутов не требуют для текстовой записи (высокоуровневой) явных БП. Оказывается,​ это напрямую связано с тем, как выводить дракон-схему маршрутов шампур-методом. 
- 
-Часто об условных переходах говорят,​ что их условие «охраняет» выход, соответствующий истинности (или просто называют условное выражение //​**охраной**//​). Если вернуться к нашим определениям содержания вершин (на РБНФ-метаязыке),​ то можно сказать кратко «шершавым языком продукций»:​ 
- 
-''​охрана-выбора<​главного выхода развилки>​ ::= лог-выр''​ 
- 
-Тогда любой набор значений входящих в это выражение величин,​ при котором условие истинно,​ можно называть «паролем» охраны. Понятно,​ что паролей м.б. и больше одного — это зависит от выражения (вида условий,​ значений входящих переменных и констант). 
- 
-Важно понимать также вот что. Структура охранного логвыра,​ как она определена для виопа Д4 в [[http://​drakon.su/​ocenka_texnojazyka_i_shampur-metoda#​nachalo_azbuki_drakona-1vrode_kak_v_bs_da_ne_kak_v_bs|этом подразделе]],​ допускает при проверке охраны также вычисления арвыров. Но результаты этих вычислений используются только в течение проверки. Это значит,​ что полученные значения недоступны после прохождения виопа. Но не менее существенно,​ что они недоступны и до этого. Т.е. возможно,​ что мы проверяем не то, что имели в виду для данной развилки (скажем,​ в неформальной постановке её вопроса). И это нужно учитывать. Разумный путь — использовать в охранах только имена величин (это и есть простейшая форма арвыра,​ как можно видеть из определения виопа Д3). 
- 
-Если некие данные используются только в развилках и не являются объектами действий алгопроцесса,​ то их можно получать арифметически (в частности,​ как результат алгопроцесса-функции). Но тут уже неоднократно используемую величину имеет смысл вычислить как действие и потом только указывать имя результата вычисления. Это сокращает работу исполнителя. 
- 
-В теории структурной алгоритмизации определены два вида сложных нелинейных конструкций — разветвляющаяся и циклическая. В честь учёного и программиста,​ заложившего основы этой теории,​ их называют выбором и циклом Дейкстры. Рассмотрим их по той же схеме, что и раньше — сначала схема кросса без упрощений шампур-метода,​ затем раскрытие её смысла. 
- 
-Кросс выбора Дейкстры имеет следующую структуру:​ 
- 
-{{ :​st_drakonsu_-_ocenka_texnojazyka_i_ishm_html_m275d44cc.gif?​ |}} 
- 
-Теперь мы не ограничиваемся схемой,​ а приводим также её текстовый эквивалент. Язык текста условный программный с русской лексикой и РБНФ — для кросса это ЯВУ типа Оберона (а в тексты '​(*'​ и '​*)'​ берутся комментарии),​ для смысла — Ассемблер для машин с явной адресацией памяти. Как можно видеть,​ атомарные конструкции допускают единообразное описание формальным текстом. Предоставляем читателю попробовать составить такое описание для лианных структур. :-) 
- 
-Первая мысль, очевидная уже из схемы кросса — крайняя правая ветвь выбирается по неявному условию,​ которое неформально можно сформулировать как «любое другое<​ кроме явно заданных в развилках>​». Строго же говоря,​ это логвыражение,​ определённое следующим образом. Из множества значений для каждой из величин,​ входящих в каждое из явных условий (охран выбора Дейкстры) выделяется подмножество значений,​ на котором ни один из вопросов развилок,​ содержащий эту величину,​ не будет иметь ответ «да» (т.е. ни одна из охран не будет истинна). Когда значение каждой из величин при исполнении равно какому-то из этого подмножества — выбирается крайняя правая ветвь конструкции. Объединение этих равенств по И (конъюнкция) и даёт искомое условие. 
- 
-Заметим,​ что любая величина может входить более чем в одно условие выбора Дейкстры,​ а интересующее нас подмножество значений у каких-то величин м.б. пустым (т.е. нет таких значений,​ при которых не была бы истинной хотя бы одна из охран выбора). 
- 
-Мысль вторая — при произвольном содержании охран может получиться так, что более чем одна из них будет истинной (т.е. «пароль» как конкретный набор значений охранных величин подходит к двум и более ветвям). Это вытекает из структуры выражения охраны,​ как мы сказали в начале раздела. А рабочая точка у нас одна — и надо иметь правило выбора для таких случаев. Принято правило т.н. «//​**ленивых**//​» вычислений — исполнитель предъявляет пароль охранам последовательно,​ и выбирается первый встретившийся вариант,​ охрана которого истинна при данном пароле. На этом следование по «шапке» выбора Дейкстры прекращается. Нетрудно видеть,​ что порядок проверки паролей (вычисления охранных логвыров) задаёт «слепыш» конструкции. ​ 
- 
-Третья мысль связана уже с кодированием выбора. Полный смысл кода включает контакты для каждого входа и выхода ветви. Для двумерной организации некоторые контакты м.б. лишними — они показаны другим типом пунктира. А вот если иметь в виду, что код в пространстве исполнителя располагается одномерно -то нужно иметь возможность «выложить» все ветви в одну линию (возможно,​ с разрывами). И некоторые или все эти контакты нужно будет реализовать (как команды БП). 
- 
-Выбор Дейкстры в своё время был сформулирован в текстовом виде как т.н. конструкция ''​IF-FI'';​ та форма, в которой мы записали текст, известна в англоязычном варианте как ''​IF{-EL[S]IF}-END''​. Разработчиками ряда текстовых ЯВУ был определён частный случай выбора по константам— т.н. ''​CASE[-ELSE]-END''​-конструкция. Именно она естественно изображается в техноязыке как дракон-переключатель. Дракон-развилка есть частный случай выбора Дейкстры по единственному условию. Поэтому и выбор Дейкстры можно записать (в тех языках где нет такой конструкции) как вложение обычных операторов ''​ЕСЛИ-ТО[-ИНАЧЕ]-ВСЁ''​ (также вплотную — т.е. не д.б. операторов ни между ''​ВСЁ'',​ ни между концом предыдущей ''​ТО''​-ветви и текущим ''​ЕСЛИ''​). 
- 
-Ну и нетрудно увидеть,​ что в случае единственной охраны выбор Дейкстры превращается в развилку (обычную). А выводится он вложением развилки в побочную вертикаль развилки предыдущего уровня вложенности. При этом, хотя по шампур-методу можно продолжать ввод атомов выше и/или ниже вложенной развилки — но в данном случае этого делать не следует. Потому что тогда получится уже не выбор Дейкстры. Поэтому же не следует в охранных выражениях включать вычисления величин,​ используемых в действиях алгоритма — это эквивалентно тому, что перед развилкой находятся виопы ''​Действие''​ с этими вычислениями. 
- 
-Сказанное означает следующее требование к техноязыку как средству структурной алгоритмизации:​ //​__дракон-лексика должна включать атом выбора Дейкстры как отдельный элемент словаря,​ а правила — добавление/​удаление варианта выбора__//​. Этот атом определяется как переключатель с раскрытием соединителей (в верхней гребёнке). Разница с «матрёшкой» развилок — в запрете ввода атома в рёбра «шапки» и «подвала» - т.е. там же, где и в переключателе. 
- 
-Перейдём к циклу Дейкстры. Он также изначально был сформулирован в текстовой записи. Современная формулировка дана в новом издании классической работы «Алгоритмы и структуры данных» Н. Вирта ([[http://​forum.oberoncore.ru/​viewtopic.php?​p=50482#​p50482|Приложение С]]). Фактически она представляет выбор Дейкстры,​ вложенный как тело цикла ПОКА. О смысле конструкции сказано следующее:​ 
- 
-//​Грубо говоря,​ обычно n-веточный цикл Дейкстры соответствует конструкциям из n обычных циклов,​ каким-то образом вложенных друг в друга. (Алгоритмы и структуры данных,​ с. 268)// 
- 
-Каким же образом?​ Попробуем разобраться с помощью графит-метода (шампур-метод снова недостаточен — нам нужно привлекать и содержание вершин). 
- 
-{{ :​st_drakonsu_-_ocenka_texnojazyka_i_ishm_html_3d71655a.gif?​ |}} 
- 
-Для компоновки содержания на заданном формате мы ввели т.н. дополнительные изломы линий на верхней схеме. Как можно видеть,​ это затрудняет чтение схемы: поэтому обычно следует избегать такой ситуации. 
- 
-Можно заметить,​ что ветвь N здесь необязательно было и изображать — её отсутствие в определении смысла конструкции не меняет. Кстати,​ в определении Вирта её нет. 
- 
-Главная мысль здесь — структура цикла Дейкстры образуется из обычных циклов,​ у которых в качестве ПОКА-подтел выступают циклы следующего уровня вложенности. У самого вложенного цикла ПОКА-подтело д.б. пустым. Условие цикла понимается так же, как и в выборе Дейкстры — как охрана ветви. Разница лишь в том, что на любую ветвь можно вернуться неоднократно — пока не вышли из цикла в целом. 
- 
-Если сказанное неочевидно сразу — можно «расплести» петлю цикла Дейкстры на петли составляющих обычных циклов. Учитывая,​ что при этом недопустимы пересечения. При этом у каждй ветви появится своя точка возврата. 
- 
-Следующая мысль — ветвь составляет ДО-подтело каждого из вложенных циклов;​ все они обычно присутствуют. Но ничто не мешает нам оставить пустой одну из ветвей. Это значит,​ что по данному паролю не надо ничего делать,​ но не надо и выходить из цикла. Если же при сочинении ЦД выходит,​ что нужно оставить пустыми две и более ветвей (но не все — это бессмысленно) — значит,​ их условия можно объединить в одно. И тогда пустая ветвь опять станет единственной. 
- 
-Представляет интерес определение порядка следования по «шапке»,​ вплоть до выхода из цикла. В книге на этот счёт сказано следующее:​ 
- 
-//Хотя в теории Дейкстры последовательность выбора ветвей цикла и вычисления соответствующих охран не определена,​ в этой книжке принято,​ что охраны вычисляются в текстуальном порядке. (Алгоритмы и структуры данных,​ с. 269)// 
- 
-Что происходит при этом? Проверяется ПОКА-охрана. Если она истинна — исполнитель идёт на ПОВТОР (выполняет первую ветвь). Если ложна — то исполнитель идёт... нет, не на выход из конструкции (обозначенный как КЦ)... а на текст за телом этой ветви. Это м.б. конец конструкции только в том случае,​ когда в цикле только одна охрана. Как нетрудно убедиться,​ это уже не цикл Дейкстры,​ а обычный цикл. А начало следующей ветви — это ближайшее ИНАЧЕСЛИ — так и попадаем на охрану следующей ветви. Если и она ложна — всё повторяется по шампуру. 
- 
-Итак, мы видим, что уточнение порядка было не случайным. А наглядно показать его необходимость помогает графит-представление конструкции. 
- 
-Наконец,​ если цикл Дейкстры не надо выкладывать в линию отдельно по ветвям,​ то не нужны контакты-БП между соседними развилками. Потому они и не показаны. Также необязателен и контакт на выходе из ЦД (включённый по аналогии с выбором Дейкстры). 
- 
-Текстовый код (для второй схемы) здесь не приводится — читатель может написать его сам. 
- 
-В современных текстовых ЯВУ цикл Дейкстры существует как в исходном синтаксисе (т.н. конструкция ''​DO-OD'',​ например,​ в языке Promela, описанном в [[http://​forum.oberoncore.ru/​viewtopic.php?​p=52453#​p52453|Гл. 8]] работы Ю.Г. Карпова по гарантоспособному программированию [[http://​www.ozon.ru/​context/​detail/​id/​4797670/?​partner=vlad_grafit-basis|"​Model Checking..."​]]),​ так и в модернизированном - как ''​WHILE-ELSIF-END''​ и ''​LOOP-ELSIF-EXIT''​ (рассмотренные в упомянутом Приложении С к книге Вирта). 
- 
-Также по шампур-методу можно продолжать ввод атомов выше и/или ниже любого цикла, вложенного как ЦД-ветвь — и так же этого делать не следует,​ поскольку логика конструкции перестанет соответствовать циклу Дейкстры. Отсюда следующее требование к техноязыку как средству структурной алгоритмизации:​ //​__дракон-лексика должна включать атом цикла Дейкстры как отдельный элемент словаря,​ а правила — добавление/​удаление ЦД-ветви__//​. ЦД-атом можно определять как переключающий цикл с раскрытием соединителей (в верхней гребёнке) и отражением нижней гребёнки по горизонтали (устремлением не к главной вертикали,​ а к петле цикла). Разница с «матрёшкой» циклов — также в запрете ввода атома в рёбра «шапки» и «подвала». 
- 
-Цикл Дейкстры предоставлляет интересные возможности для структурирования алгоритма в целом. Рассмотрим,​ как это можно сделать. 
- 
-==== Дейкстрал:​ тени исчезают с лианами,​ а охрана требует пароль ==== 
- 
-Недостаток силуэтной укладки как физической можно преодолеть,​ если перейти к логической укладке маршрутов. Имеется в виду, что вход в единицу укладки определяют не соединители,​ а условия выбора. ​ 
- 
-Проще говоря,​ нужно перейти от деления схемы соединителями к делению разветвителями. Фактически они присутствуют в «петле силуэта»,​ но их условия (охраны) имеют смысл исключительно проверок совпадения значений адреса целевой ветки и имени текущей. Возможность и логической укладки (исключения межветочных БП), и отказа от явных БП в теле схемы даёт цикл Дейкстры (далее - ЦД) как иная форма универсальной программы. ​ 
- 
-Представим себе, что ЦД охватывает всё тело алгоритма — от заголовка до конца. Только условия «шапки» расположим так, как при раскрытии смысла верхней гребёнки — по горизонтали. Получится схема, кросс которой показан на рисунке:​ 
- 
-{{ :​st_drakonsu_-_ocenka_texnojazyka_i_ishm_html_674f63e6.gif?​ |}} 
- 
-Здесь фактически вводится новый тип устремлённого планарного графа, называемый //​**дейкстралом**//​. Он обеспечивает универсальность за счёт того, что ЦД-ветви можно выбирать в любом порядке (пока мы не вышли из цикла). Если представить,​ что телом каждой ветви служит простой шампур-блок (отдельный линейный участок) схемы алгоритма — скажем,​ примитива,​ — то это значит,​ что мы можем организовать порядком выбора ветвей в ЦД любой из вариантов использования,​ возможный в этой схеме. 
- 
-Главная идея схемы — реально перенести выбор единицы метаструктуры маршрутов (здесь мы называем её ветвью,​ в отличие от ветки шампур-силуэта) в «шапку» схемы. Для этого мы исключаем возможность побочных выходов из ветвей,​ а условия «шапки» понимаем как охраны. Т.е. они м.б. сформулированы от любых величин алгоритма. 
- 
-Также показано,​ что дейкстрал можно «зациклить». 
- 
-Наконец,​ как частный случай из дейкстрала (и обычного,​ и «зацикленного») можно получить примитив. Как и в силуэте,​ для этого достаточно оставить только конечную ветвь — она и будет телом примитива. 
- 
-Текстовая запись дейкстрала возможна различным образом — в зависимости от конструкций Дейкстры,​ поддерживаемых текстовым ЯВУ. Если имеется только выбор Дейкстры — текст показан вверху. Кстати,​ здесь уточнено,​ что ЦД можно получить вложением выбора Дейкстры в цикл LOOP. Поскольку и этот цикл можно получить из других (об этом мы уже говорили) — то ЦД (как и дейкстрал) в принципе можно написать на любом императивном языке. 
- 
-Это можно видеть на схемах ниже. 
- 
-{{ :​st_drakonsu_-_ocenka_texnojazyka_i_ishm_html_m51337e4f.gif?​ |}} 
- 
-Для упрощения силуэт мы показали одноадресным и без дополнительных входов. 
- 
-В силуэте реален как циклический (действительно идёт против шампура) только один переход — с конца на начало силуэта,​ когда он «зацикленный» (реагирующий). Остальные переходы на главном маршруте силуэта реально идут по шампуру. Поэтому разветвления для выбора их в петле силуэта фиктивны — никаких условных переходов на самом деле для этой цели не нужно. Как следствие,​ адрес перехода с главного выхода ветки предопределён — всегда на следующую справа ветку. Можно считать — хотя в шампур-методе это не оговорено,​ ибо он исходно определён только для «слепышей» — что тексты икон Адрес для главных выходов веток назначаются автоматически по правилу «чем правее,​ тем позже» — соответственно и циклы по этим выходам невозможны. ​ 
- 
-В многоадресном силуэте побочные выходы,​ возможные в любой неконечной (т.е. изначально заземлённой по шампуру) ветке, могут давать как прямые,​ так и возвратные переходы — всё зависит от желания сочинителя,​ т.к. он имеет право ввести в икону Адрес любое имя ветки данного силуэта. Если это имя текущей или более левой ветки — образуется ВМЦ. Вообще говоря,​ такие циклы тоже нельзя образовывать произвольно,​ если хотя бы два из них охватывают более, чем по одной ветке. Поскольку тогда возможно пересечение циклов,​ что в структурной алгоритмизации не допускается. Как мы уже говорили,​ в рамках ШМ невозможно задать правила образования ВМЦ — ибо такие правила должны включать имена веток (абстрактные,​ как на наших схемах) — а ШМ исходно рассматривает только «слепыши». 
- 
-В дейкстрале каждый переход между его ветвями реально циклический — т.е. идущий против шампура. Потому и выбор ветви реальный — каждый раз надо проверять условие на входе каждой ветви, начиная слева, пока не обнаружится первое истинное — в эту ветвь и войдёт исполнитель на очередной итерации цикла. Задача сочинителя — так сформулировать выражения охран, чтобы выбирались ветви, нужные по условию задачи. Конечно,​ и тела ветвей дейкстрала не обязаны быть линейными — в них также м.б. развилки (плечи которых не выходят за пределы тела ветви). ​ 
- 
-В принципе можно организовать внутри ветви и один или больше локальных циклов — но часто бывает удобнее замкнуть все циклы алгоритма через кросс дейкстрала. Тогда тело простого цикла целиком будет телом какой-то ветви, а тело гибридного — двух ветвей (для ДО- и ПОКА-частей). 
- 
-Итак, в дейкстрале изначально не нужны заземления лиан. Нет необходимости и в пересадках — те же варианты использования можно получить разнесением простых шампур-блоков лианного макроблока по дейкстрал-ветвям и надлежащим выбором ветвей. Это в пределе — часто можно проще, сочетая ветвления в телах дейкстрал-ветвей с выбором самих ветвей. 
- 
-Принцип практической реализации всех упомянутых типов схем можно показать совмещённо,​ как на следующем рисунке. 
- 
-{{ :​st_drakonsu_-_ocenka_texnojazyka_i_ishm_html_205cf538.gif?​ |}} 
- 
-Здесь можно видеть,​ чем представляются вершины кросса в системе команд типичного исполнитля алгоритмов — машины с адресной архитектурой. Это команды БП — простого и с возвратом. 
- 
-Использование ЦД возможно двумя путями:​ 
- 
- 
-  * вывода тела дракон-схемы или его части как ЦД в рамках ШМ-правил (как варианта вложенного цикла);​ 
- 
- 
-  * модификации метода для использования ЦД-организации схем, начиная с аксиом. 
- 
-Первый путь требует только определённого порядка вывода в ШМ: 
- 
- 
-  - схема-дейкстрал может пониматься как примитив,​ так что для вывода берём заготовку-примитив;​ 
-  - новая ветвь дейкстрала добавляется вводом дракон-атома обычного цикла как ДО-подтела обычного цикла предыдущего уровня вложенности за счёт такого единообразного порядка вложения формируем метаструктуру тела визуала (только «шапка» будет «в столбик»);​ 
-  - чтобы сделать шапку по горизонтали («лесенкой»,​ на манер силуэтной),​ последовательно рокируем плечи условий вложенных циклов. 
- 
-Второй путь предполагает определение заготовки для вывода схемы как ЦД, ЦД-атома,​ а также операций добавления/​удаления ветви (аналогично добавлению/​удалению ветки силуэта). Это уже выходит за рамки исходного ШМ и потому может обсуждаться отдельно. 
- 
-Определённая сложность логической укладки в том, что структуру нужно логически выводить изначально,​ пользуясь методами т.н. доказательного программирования. Для неподготовленного сочинителя это может представлять известную проблему. Возможны следующие пути её решения:​ 
- 
- 
-  * пользоваться известными методами формальной спецификации задачи,​ хорошо разработанными и допускающими эргономизацию;​ 
- 
- 
-  * приводить разработанные силуэты и/или лианные макроблоки к форме ЦД. 
- 
-Среди первых можно выделить т.н. [[http://​forum.oberoncore.ru/​viewtopic.php?​p=52313#​p52313|автоматное программирование]]. Спецификации конечными автоматами естественны для задач управляющего (реагирующего) рода и рядом специалистов считаются наглядными. 
- 
-Показано,​ что дракон-силуэт можно преобразовать в ЦД-схему. Тем самым ЦД-укладка обратно совместима с силуэтной. Т.е. можно переводить «силуэтно-унаследованные» визуализации алгоритмов и потоков управления программ в ЦД-запись. 
- 
-Важное преимущество ЦД как замены силуэта в том, что его ветви имеют один выход. Тем самым отпадает нужда в ШМ-операции «заземление лианы». Кроме того, в рамках доказательного программирования Дейкстрой,​ Виртом и другими исследователями было показано,​ что в теле ЦД также не нужно употреблять явных БП, чтобы получить те же маршруты,​ что и с их использованием;​ соответственно не требуется операция «пересадка лианы». Как следствие,​ редактор,​ реализующий только логическую укладку,​ м.б. упрощён в плане как алгоритмов,​ так и структур данных;​ очевидно,​ это даст большую его производительность. 
- 
-Другое преимущество в том, что доказательность достигается с участием текста вершин. Тем самым сочинитель уходит от частичной корректности программы в визуализированной форме (которую только и обеспечивает ШМ, как указывал Паронджанов) к полной. Но визуализация может облегчать правильное построение программы и проверку корректности. 
- 
-Как и для конструкций Дейкстры,​ вывод дейкстрала в рамках исходного ШМ не исключает ввода, искажающего маршрутную логику. Отсюда и аналогичное требование:​ //​__техноязык как средство поддержки структурной алгоритмизации должен включать как аксиому дейкстрал-заготовку,​ а метод — операции добавления/​удаления дейкстрал-ветви,​ а также конца схемы__//​. 
- 
-Важно понимать,​ что эти требования прямо следуют из необходимости достижения максимальной гарантоспособности сочинения. //​**Поэтому в т.н. «критических» сферах приложения техноязыка и шампур-метода их выполнение обязательно.**//​ Поскольку в таких условиях обычно используют методы инженерного,​ расчётно-логического проектирования процессов,​ требующие рассуждения о свойствах полного описания — и графики,​ и текста,​ если говорить о схемах. 
- 
-Следует основываться на этих конструкциях и при профессиональном обучении алгоритмизации и программированию. Заметим,​ что их введение не отменяет существующих возможностей шампур-метода. Поэтому можно пользоваться и ими. Однако,​ как можно видеть из раскрытия смысла,​ силуэтная структуризация целесообразна лишь при описании алгопроцессов с расчётом на их прямое кодирование для исполнителя-машины. Фактически такова схема работы по исходной технологии ГРАФИТ-ФЛОКС. Необходимости же в неатомарных конструкциях внутри алгоритма вообще нет. 
-===== Разметка схем и гибридные техноязыки:​ ДРАКОН начинает,​ ГРАФИТ выигрывает ===== 
- 
-В ШМ она, по сути, не рассматривается. По определению это исчисление «слепышей»,​ т.е. неразмеченных графов (без учёта текстоэлементов синтаксиса схем). Однако на практике возникает необходимость по крайней мере в двух типах разметки шампур-схем:​ 
- 
- 
-  * для выходов развилок — надписями «да»/​«нет» при выходных рёбрах;​ 
- 
- 
-  * для веточных макроциклов (ВМЦ) — какими-нибудь индексами,​ позволяющими отличить разные ВМЦ в одном силуэте. 
- 
-Первый тип можно реализовать и иначе — вершинами,​ несущими надписи. Такое решение можно видеть в предложениях Рэйлвей Кагена для его ПРОТОН-нотации. По сути, такие вершины — эквиваленты икон ''​Вариант''​ в макроиконе ''​Переключатель''​. 
- 
-Второй тип может иметь синтаксис,​ предложенный некоторыми пользователями техноязыка и показанный у Паронджанова(см. выдержку в [[http://​forum.oberoncore.ru/​viewtopic.php?​p=57898#​p57898|этом сообщении]]). В веточные соединители добавляется поле индекса ВМЦ. 
- 
-По Паронджанову предлагается разделять шампур- и гибридную формализацию императивных знаний. В первом случае определён т.н. маршрутный граф-язык «слепышей»,​ представляющий только управляющие знания — т.е. структурную часть императивной составляющей знания — для любых существующих и мыслимых чисто текстовых языков (узко императивных или содержащих императивную составляющую). В этом понимании маршрутный язык есть полиязык для текстовых. Во втором определяется гибридный техноязык путём: 
- 
- 
-  - выделения в чисто текстовом языке управляющей части и замены её на маршрутный язык (синтаксис «слепышей»);​ 
-  - разметки остальным содержанием текстового языка вершин и рёбер «слепыша». 
- 
-Выделение управляющей части может оказаться нетривиальной задачей;​ её наличие определяется высотой абстракции языка от алгоритмического исполнителя (машины или арифметической модели алгоритма). 
- 
-Управляющие знания логически есть одна часть из двух (структурной и атрибутивной) в одной составляющей из четырёх (императивной,​ декларативной,​ активностной и обобщающей). Это следует из известного тезиса Н. Вирта (программа = алгоритм + структура данных + систематическое представление об исполнителе;​ см. в [[http://​forum.oberoncore.ru/​download/​file.php?​id=1881|этой статье]]),​ а также из факта существования т.н. [[http://​ru.wikipedia.org/​wiki/​Парадигма_программирования#​.D0.A0.D0.B0.D0.B7.D0.BB.D0.B8.D1.87.D0.BD.D1.8B.D0.B5_.D0.BE.D0.BF.D1.80.D0.B5.D0.B4.D0.B5.D0.BB.D0.B5.D0.BD.D0.B8.D1.8F|парадигмы программирования]] как способа увязки частей описания программы (по Вирту) в единое целое. Однако синтаксический объём этих частей в разных языках не обязательно одинаков. Существует и [[http://​forum.oberoncore.ru/​viewtopic.php?​p=71247#​p71247|подход В.Ш. Кауфмана]] — язык программирования определяет данные,​ операции и их связывание. 
- 
-Проще говоря,​ любой язык программно строгой формализации распадается на ряд подъязыков,​ один из которых играет интегрирующую роль. И нужно определить синтаксис каждого языка. Создатель техноязыка указывает на необходимость единых правил построения объектных имён, информативных и удобных для восприятия;​ для этого нужна и достаточная длина имени: ​ 
- 
-//​«...множество 32-символьных идентификаторов образует весьма выразительный,​ хотя и своеобразный,​ язык, законы и правила оптимизации которого ещё предстоит открыть,​ обсудить и подвергнуть экспериментальной проверке.»//​ /Как улучшить работу ума, с.163/. 
- 
-В то же время командная часть императивного подъязыка (так сказать,​ «имена действий») также должна иметь текстовый синтаксис. Нужен и синтаксис их сочетания в дракон-вершинах. 
- 
-Определённое достоинство такого пути (можно сказать,​ частной гибридизации) в его простоте — определение гибридного языка можно получить без больших видимых усилий. На практике же проявляются недостатки. Их можно объяснить,​ исходя из сказанного выше при обосновании языка и метода. 
- 
-Во-первых,​ неуправляющее содержание языка, полного в смысле Вирта и парадигмы программирования,​ как нетрудно видеть,​ логически составляет семь восьмых от всего содержания любого описания на этом языке. Поэтому объём разметки м.б. весьма значительным. Практически в любом случае возникает «перекос» в сторону текста в гибридной схеме, что может умалять эргономический эффект от визуализации маршрутов. 
- 
-Во-вторых,​ для некоторых парадигм,​ не императивных по своей сути, возможность выделить управляющую часть вообще неопределённа. Это возможно для языков высокой абстракции,​ тяготеющих к дескриптивности («ЧТО-формализации»). В частности,​ тех или иных языков спецификации программ/​задач. 
- 
-В-третьих,​ существует часть знания,​ отражаемая в формальном тексте неявно. На это, в частности,​ указывал И. Ермаков при обсуждении визуализации [[http://​forum.oberoncore.ru/​viewtopic.php?​p=68824#​p68824|здесь]]. При буквальном переводе части текстового синтаксиса в графику нет оснований полагать,​ что эта часть станет явной. 
- 
-Преодолеть недостатки частной гибридизации можно следующим образом:​ 
- 
- 
-  * визуализировать в каждой составляющей текстового языка её структурную часть; 
- 
- 
-  * рассматривать парадигмы «ЧТО-формализации» на предмет выделения их структурной части и нахождения структур графов,​ формально и эргономично представляющих эту часть; 
- 
- 
-  * выявлять содержание,​ не отражённое в конкретном языке явно, и находить средства его выражения. 
- 
-Тем самым определение гибридного языка на базе только дракон-схем для языка программирования или спецификации м.б. лишь началом гибридизации. 
- 
-Безусловно,​ путь, намеченный Ермаковым,​ требует и теоретических изысканий,​ на что он [[http://​forum.oberoncore.ru/​viewtopic.php?​p=26640#​p26640|также указывал]]. 
- 
-==== Доалгоритмическая формализация:​ хороший командир указывает,​ ЧТО, но не указывает,​ КАК ==== 
- 
- 
- 
-Это правило (своего рода неформальное военное поучение) для нашей темы отражает важное обстоятельство — алгоритмизация (и последующее программирование/​инструктирование) требуют от сочинителя понимания постановки задачи (что «дано» решателю и что «надо» от него — включая различные начальные и граничные условия). А эта постановка,​ в свою очередь,​ отражается на соответствующих языках представления отчуждаемых знаний — дескриптивных — по своей сути ничего общего с императивными языками не имеющих. И решение в этом случае тоже отражается дескриптивно — какие отношения и сущности надо преобразовать и что для этого надо сделать (формально — какие логико-математические операции,​ функции и где применить). 
- 
-«ЧТО»-язык отражает некие сущности решаемой задачи и её предметной области (не обязательно объекты алгоритма) и некие отношения между ними. Такие языки тоже бывают как чисто текстовыми,​ так и графитными. Пример последнего — язык информационного моделирования IDEF1X. Он отражает только систему отношений между сущностями. Для записи преобразований (отдельно или вместе с сущностями-отношениями) существуют другие языки — скажем,​ т.н. функционального или логического программирования. Ряд таких языков имело бы смысл «графитизировать» — но делать это нужно по иным принципам,​ чем для императивных языков. Примером могут служить языки схем зависимостей,​ потоков данных,​ такие как [[http://​grafit-basis.narod2.ru/​L3/​mental-vspom.html#​Pril2-n38|функциональные схемы, ДПД]], [[http://​forum.oberoncore.ru/​viewtopic.php?​f=28&​t=3884|Анимо]]. Следует выработать эргономические оптимальные правила организации таких схем. В чём-то может помочь опыт эргономизации системных схем, частично зафиксированный в стандартах на такие схемы (типа ЕСКД). 
- 
-Условия применения «ЧТО»-описаний хорошо сформулированы у Кауфмана:​ 
- 
-//​Людей как исполнителей характеризует прежде всего наличие у них модели реального мира, в достаточной мере согласованной с моделью мира у создателя плана <т.е. описания поведения исполнителя>​. Поэтому в плане для людей можно указывать цели, а не элементарные действия. ([[http://​forum.oberoncore.ru/​download/​file.php?​id=3066|ЯП. Концепции и принципы,​ с. 31]])// 
- 
-Такую возможность как раз даёт аппарат мышления человека. Не случайно идут поиски объяснений механизмов мышления,​ попытки их формализации. 
- 
-В более практическом смысле дескриптивные языки можно применять для более качественной постановки задач. А их графические разновидности — и для эргономизации представления «ЧТО»-описаний. 
ocenka_texnojazyka_i_shampur-metoda.1332840779.txt.gz · Последние изменения: 2012/03/27 13:32 — Владислав Жаринов