Различия

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

--- ocenka_texnojazyka_i_shampur-metoda [2012/04/05 11:45]
Владислав Жаринов [Содержание]
+++ ocenka_texnojazyka_i_shampur-metoda [2012/04/10 08:55]
Владислав Жаринов
@@ Строка 1: / Строка 1: @@
-====== Оценка техноязыка и шампур-метода ======
+====== Техноязык и шампур-метод - сущность, преемственность, развитие ======
 Безусловно, ДРАКОН-визуализация отличается от традиционной визуализации потоков управления блок-схемами. Сам Паронджанов указал на это следующим образом:
@@ Строка 156: / Строка 156: @@
 Таков пролог нашей истории... :)
+====== Продолжение следует... ======
 ===== Вершины и линии схем: смысл — в ГРАФике И Тексте =====
-По идее когнитивной формализации знаний, в ШМ графика должна прежде всего удобно вмещать текст (и/или таблицы, если они допустимы как содержание вершины некоторого типа). Поэтому из БС-графики заимствуются только такие формы икон и их частей, которые и наглядны сами по себе, и удобно и экономично вмещают текст.
-Как следствие, по сравнению с блок-схемами некоторые формы блоков получают новые значения (к примеру, форма-трапеция – как основа хронизаторов реального времени), а другие (скажем, ромб) не используются.
+[[Вершины и линии схем - смысл — в ГРАФике И Тексте|]]
-В то же время композиция многофигурных вершин м.б. более стройной, если ввести общие законы их построения. Возможны следующие:
-вертикалей окружения — вводятся условные оси, параллельные шампуру схемы и представляющие совокупные потоки управления процессов, взаимодействующих с алгоритмическим процессом, описываемым схемой;
-событийного следования — фигуры в вершине и/или части её содержания упорядочиваются по шампуру в порядке исполнения.
-В части первого нужно раздельно представлять процессы того же исполнителя и процессы его внешней среды; поэтому следует ввести оси по обе стороны шампура; фигуры, представляющие связь с соответствующей категорией процессов, для удобства чтения нужно сделать как по форме направленными на ось, так и по положению смещёнными к ней.
-В части второго предшествующие события представляются фигурами, расположенными ближе к началу шампура; кроме того, можно использовать уровни глубины, если допускать частичное перекрытие фигур в вершине.
-Можно видеть, что в ШМ принято единственное правило — располагать фигуры вершины «лесенкой» всегда справа налево и направленные формы фигур направо - более простое, но менее информативное.
-Также алфавит БС функционально шире, чем в ДРАКОНе. Блок-схемы предназначены для представления содержания всей программы (в смысле расширенного тезиса Вирта). Поэтому, кроме подалфавита импер-части (называемой в БС «схема алгоритма»), предусмотрен также подалфавит для деклар-части («схемы данных»). Имеются также средства для представления материальных действий («техпроцессов» по Паронджанову) и структур (актив-части). Однако назначение ДРАКОНа — представлять только императивные знания; поэтому остальной алфавит здесь не нужен.
-Важно понимать, что графика шампур-схемы представляет лишь часть формализуемого знания о предмете шампур-визуализации. Остальная часть представляется содержанием вершин (и, возможно, рёбер). Т.е. за схемой всегда стоит некий целостный язык представления (ЯПЗ), изначально полностью текстовый. Именно на него мы и указываем префиксом. Не принимать во внимание этот язык можно, лишь рассматривая абстрагированные шампур-схемы (литеральные и «слепыши»). Конкретный же графит-язык «гибриден», т.е. образуется «скрещиванием» ЯПЗ с шампур-языком (схем-«слепышей»). При этом часть синтаксиса текстового ЯПЗ представляется графикой вершин и рёбер, а часть — их содержанием (как ещё говорят, разметкой графа). Образуется т.н. гибридный язык — который д.б. эквивалентен чисто текстовому.
-Если же мы не указываем ЯПЗ, но считаем, что схема конкретная (гибридная) — это лишь значит, что мы принимаем для содержания её рёбер и/или вершин синтаксис некоего гибридного ЯПЗ, выбираемого «по умолчанию». Разумно считать таким естественный язык описания деятельности, родной для сочинителя (и, конечно, читателя) схемы. Однако этот язык для удобства дальнейшей формализации обычно как-то структурируется (ограничивается). Как — покажем при определении лексики языка.
-Далее рассмотрим дракон-алфавит с позиций структурного анализа и синтеза.
-==== Начало азбуки ДРАКОНа-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 и заменителей). Если принять подход противников явных БП в ЯВУ — можно отказаться от операций с лианой и алгоритмизовать только атомарными структурами. Если принять подход сторонников — разрешить лианные операции и структуры.
-Недостаток разрешения лианных структур — тот же, что в случае силуэтной укладки схемы — необходимость в явных БП для представления соединителей. Аналогично он и преодолевается.
-Суть различий между атомарными и лианными структурами можно понять, раскрыв смысл конструкций каждого вида. Удобно взять «матрёшку» и результат пересадки лиан в ней (с сохранением частичной эквивалентности как тождества части наборов маршрутов). Возьмём конструкцию, предложенную Паронджановым для визуализации функции «логическое И» (над вопросами развилок, понимаемыми как булевы термы):
-{{ :st_drakonsu_-_ocenka_texnojazyka_i_ishm_html_m450f7821.gif? |}}
-Для этой цели из возможных звеньев ввода нужно использовать только одно — на главной вертикали конструкции. Именно этот маршрут выбирается по И над вопросами развилок.
-Уже из схем кроссов видно главное отличие лианной конструкции — нарушение эквивалентности с «матрёшкой» (здесь — в части побочных маршрутов). С позиций шампур-метода это несущественно — для того и операции с лианой, чтобы вывести то, что не получается вложением...
-Другое отличие видно при раскрытии смысла — безусловные переходы, представляющие соединители из «подвала», частично объединяются с переходами, представляющими вершины-разветвители из «шапки».
-Заметим, что для понимания смысла нужно вновь привлекать текст. Во-первых, вопросов — каждый вопрос нужно чётко понимать как значение, получаемое при ответе и имеющее смысл переменной булева типа. На это косвенно указывает и Паронджанов — при обсуждении визуализации логики в [[http://drakon.su/biblioteka/start#literatura|"Как улучшить работу ума...", Гл. 9]]. А во-вторых, нужно учитывать и ответы — точнее, их положение при выходах развилки. Можно показать, что от этого зависит интерпретация «шапки» как логического выражения. Мы на этом здесь останавливаться не будем — читатель, достаточно разобравшийся в структурном анализе, может попробовать сделать это сам.
-А что такого в том, чтобы допустить операции с лианой? И почему мы говорим, что «мудрец в этом случае становится похож на обезъяну»? Может, дело в этом описании сочинения лианных структур у Паронджанова:
-//Обезьяна, сидевшая на дереве, поймала свисавшую сверху лиану. Однако нижняя часть лианы приросла к стволу и не поддавалась. Обезъяна перегрызла её зубами, уцепилась за конец и мигом перелетела на соседнее дерево, где намертво привязала лиану к ветке. (Как улучшить работу ума..., с. 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? |}}
-Теперь мы не ограничиваемся схемой, а приводим также её текстовый эквивалент. Язык текста условный программный с русской лексикой и РБНФ — для кросса это ЯВУ типа Оберона (а в тексты '(*' и '*)' берутся комментарии), для смысла — Ассемблер для машин с явной адресацией памяти. Как можно видеть, атомарные конструкции допускают единообразное описание формальным текстом. Предоставляем читателю попробовать составить такое описание для лианных структур. :-)
-Первая мысль, очевидная уже из схемы кросса — крайняя правая ветвь выбирается по неявному условию, которое неформально можно сформулировать как «любое другое< кроме явно заданных в развилках>». Строго же говоря, это логвыражение, определённое следующим образом. Из множества значений для каждой из величин, входящих в каждое из явных условий (охран выбора Дейкстры) выделяется подмножество значений, на котором ни один из вопросов развилок, содержащий эту величину, не будет иметь ответ «да» (т.е. ни одна из охран не будет истинна). Когда значение каждой из величин при исполнении равно какому-то из этого подмножества — выбирается крайняя правая ветвь конструкции. Объединение этих равенств по И (конъюнкция) и даёт искомое условие.
-Заметим, что любая величина может входить более чем в одно условие выбора Дейкстры, а интересующее нас подмножество значений у каких-то величин м.б. пустым (т.е. нет таких значений, при которых не была бы истинной хотя бы одна из охран выбора).
-Мысль вторая — при произвольном содержании охран может получиться так, что более чем одна из них будет истинной (т.е. «пароль» как конкретный набор значений охранных величин подходит к двум и более ветвям). Это вытекает из структуры выражения охраны, как мы сказали в начале раздела. А рабочая точка у нас одна — и надо иметь правило выбора для таких случаев. Принято правило т.н. «//**ленивых**//» вычислений — исполнитель предъявляет пароль охранам последовательно, и выбирается первый встретившийся вариант, охрана которого истинна при данном пароле. На этом следование по «шапке» выбора Дейкстры прекращается. Нетрудно видеть, что порядок проверки паролей (вычисления охранных логвыров) задаёт «слепыш» конструкции.
-Ленивые вычисления предполагают связывание охран посредством т.н. //**полустрогих**// булевых операций. В такой операции порядок операндов зависит от их значений и смысла согласно цели вычисления. Базовыми являются операции and then и or else (подробнее см. [[http://forum.oberoncore.ru/viewtopic.php?p=69127#p69127|у Мейера в Гл. 5]]).
-Третья мысль связана уже с кодированием выбора. Полный смысл кода включает контакты для каждого входа и выхода ветви. Для двумерной организации некоторые контакты м.б. лишними — они показаны другим типом пунктира. А вот если иметь в виду, что код в пространстве исполнителя располагается одномерно -то нужно иметь возможность «выложить» все ветви в одну линию (возможно, с разрывами). И некоторые или все эти контакты нужно будет реализовать (как команды БП).
-Ну и нетрудно увидеть, что в случае единственной охраны выбор Дейкстры превращается в развилку (обычную). А выводится он вложением развилки в побочную вертикаль развилки предыдущего уровня вложенности. При этом, хотя по шампур-методу можно продолжать ввод атомов выше и/или ниже вложенной развилки — но в данном случае этого делать не следует. Потому что тогда получится уже не выбор Дейкстры. Поэтому же не следует в охранных выражениях включать вычисления величин, используемых в действиях алгоритма — это эквивалентно тому, что перед развилкой находятся виопы ''Действие'' с этими вычислениями.
-Выбор Дейкстры в своё время был сформулирован в текстовом виде как т.н. конструкция ''IF-FI''; та форма, в которой мы записали текст, известна в англоязычном варианте как ''IF{-EL[S]IF}-END''. Разработчиками ряда текстовых ЯВУ был определён частный случай выбора по константам— т.н. ''CASE[-ELSE]-END''-конструкция. Именно она естественно изображается в техноязыке как дракон-переключатель. Дракон-развилка есть частный случай выбора Дейкстры по единственному условию. Поэтому и выбор Дейкстры можно записать (в тех языках где нет такой конструкции) как вложение обычных операторов ''ЕСЛИ-ТО[-ИНАЧЕ]-ВСЁ'' (также вплотную — т.е. не д.б. операторов ни между ''ВСЁ'', ни между концом предыдущей ''ТО''-ветви и текущим ''ЕСЛИ'').
-Существует определённая аналогия между полустрогими операциями и конструкциями типа выбора Дейкстры с возможностью действий между развилками. Однако имеется и различие — в полустрогой операции второй операнд-охрана м.б. не определён (и это есть основание для их применения) — тогда как в конструкциях типа ''AND-THEN'' и ''OR-ELSE'' каждая охрана д.б. определена (вычислима). Просто неистинность охраны означает, что предыдущие действия неудачны (в смысле цели всей конструкции) и нужно выбирать не продолжение целевых действий, а парирование неудачи.
-Сказанное означает следующее требование к техноязыку как средству структурной алгоритмизации: //__дракон-лексика должна включать атом выбора Дейкстры как отдельный элемент словаря, а правила — добавление/удаление варианта выбора__//. Этот атом определяется как переключатель с раскрытием соединителей (в верхней гребёнке). Разница с «матрёшкой» развилок — в запрете ввода атома в рёбра «шапки» и «подвала» - т.е. там же, где и в переключателе.
-Перейдём к циклу Дейкстры. Он также изначально был сформулирован в текстовой записи. Современная формулировка дана в новом издании классической работы «Алгоритмы и структуры данных» Н. Вирта ([[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]])//
-Такую возможность как раз даёт аппарат мышления человека. Не случайно идут поиски объяснений механизмов мышления, попытки их формализации.
+===== Разметка схем и гибридные техноязыки =====
-В более практическом смысле дескриптивные языки можно применять для более качественной постановки задач. А их графические разновидности — и для эргономизации представления «ЧТО»-описаний.
+[[Разметка схем и гибридные техноязыки - ДРАКОН начинает, ГРАФИТ выигрывает|]]

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

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

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

Различия

Инструменты страницы