DRAKON.SU

Это не так.

1. В драконе нет терминаторов, который рисуют где угодно на чертеже и которые могут повторяться несколько раз, что вносит неразбериху и затрудняет понимание.
2. В драконе есть икона Заголовок (вход), причем только одна на чертеже и в строго определенном месте.
3. В драконе есть икона Конец (выход), причем только одна на чертеже и в строго определенном месте.

Это значит: один вход, один выход, т.е. простая программа.

PSV100, вы ставите вопрос, что этого мало и что нужно несколько икон Заголовок и несколько икон Конец. Для меня это не очевидно. Это нужно доказать.

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

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

Почему?
Потому что так удобно программировать. Компьютер так устроен.
Это не соответствует ГОСТу? Очень жаль.
Зато это соотносится с тем, как работают "современные" операционные системы.

PSV100, спасибо за подробное изложение вашей точки зрения.

У нас с вами существенно разные позиции.
Моя позиция в следующем сообщении.

Для PSV100

1. Стандарты ISO 5807-85 и ГОСТ 19.701-90 на блок-схемы устарели. Они не защищают от ошибок а наоборот, провоцируют появление ошибок.
Схема, нарисованная по этим стандартам — это каша с гвоздями.

2. Эти стандарты нужно аннулировать и заменить на новый стандарт, основанный на правилах языка ДРАКОН (возможно, с коррекциями).

3. Цель языка ДРАКОН — предотвращать ошибки.

4. Стандарты ISO 5807-85 и ГОСТ 19.701-90 давно морально устарели. То, что они продолжают действовать объясняется лишь тем, что

(1) язык ДРАКОН мало кому известен,
(2) нет инициативного человека, который бы взял на себя миссию убрать эту древность и заменить ее на ДРАКОН.

Вот отзыв из сети:
viewtopic.php?p=100245#p100245

==============
Насчет пристрастий.
Чтобы попусту не спорить, надо ответить на вопрос:
Программа будет правильно работать? Если да, то вопрос исчерпан.

На сегодня устройство компьютеров есть сложная многоуровневая система или со множеством страт:
https://panchul.livejournal.com/469643.html?thread=19173003#t19173003

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

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

Степан, проблематика не в соответствии ГОСТу как таковом, а в Дракон-философии, что ли. Из-за естественного стремления к эргономике в Дракон-е возникает эффект "мульти-метафор" и "диалектов", так что ли назвать происходящие явления, не знаю как именно.

К примеру, в попытке обобщения семантики в контексте "реального времени и диспетчера" Вы для "вывода" определяете лишь один вариант семантики. Но в общем случае с алгоритмической точки зрения выделяются, как минимум, следующие ситуации (которые могут быть в рамках даже одного и того же проекта или программы, не то чтобы в разных предметных областях):
1) напр., при операции с файлом исполнительный поток должен быть заблокирован (хотя бы виртуально) в том смысле, что не должно быть переключения контекста на смежные (заинтересованные) процессы -- данный алгоритм не сигнализирует о завершении предметного такта работы, лишь выполняет свою "рутину";

2) алгоритм сигнализирует о завершении прикладного шага в работе, при этом:
2.1) поток не должен быть заблокирован (по возможности, во всяком случае, алгоритм не требует блокировки);
2.2) поток блокируется по мотивам организации кооперативной многозадачности (пока не завершаться смежные и прочие необходимые процессы);

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

Уточнения выше не являются вспомогательными в смысле как уточнение параметров/адресатов (мол "отправляем документ такой-то в отдел такой-то"), а определяющими в контексте организации управления действиями -- ключевого аспекта самих схем как таковых. И, вроде как, намечается новый "стандарт" (если Ваши усилия так воспринимать), но его не достаточно. Вводить новые иконы -- вариации "вывода" с закорючками -- язык запрещает, ибо уже тогда появляется новый язык как таковой (да и эргономика при "мозаиках" под вопросом). Но "диалекты" возникают всё равно, в ином виде. К примеру, "стандарт" предопределяет использование икон реального времени так -- "взвод" таймера (в ноль, напр.) и возможно множество сопряжённых точек ожидания/синхронизации в зависимости от отсчитанного времени:
https://forum.drakon.su/viewtopic.php?f=78&t=6263#p101816

Однако, от TAU мы наблюдаем уже "диалект" этих же икон -- взвод УВИ на конкретное время и одну связанную точку синхронизации, где в "синхронизаторе" время уже не указывается:
https://forum.drakon.su/viewtopic.php?f=176&t=6221#p101429

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

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

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

А если "одобрямс" от "Дракон-комитета" поддерживает: "ожидающие циклы -- с позиции читателя это правильно, нет лишней работы, так эргономично -- и это главное", и "стандарт" будет подкорректирован, то, к примеру, и "ожидающих вопросов" не избежать в итоге. Напр., возникнет новое направление -- "интеллектуальное бизнес-управление", где какие-то "проталкиватели" курсов/продукта постановят: после команды "Ок, [s]Google[/s] Дракон!" схема переходит в особый режим, где "решения" в иконах "вопрос" принимает не человек, а Дракон-диспетчер с "искусственным интеллектом", на которого в иконе неявно осуществляется переключение контекста исполнения -- мол так подчёркивается "фишка" интеллектуального управления, ведь так эргономично -- раскрывается сама суть технологии, и Дракон на передовой искусственного интеллекта!

Я конечно же, приукрашиваю, но основное -- возникнут или уже есть какие-то "диалекты", где смена семантики икон/элементов языка может происходить динамически внутри схемы (и те же иконы-"вопросы" -- не исключение).


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

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

Владимир Даниелович, нет никакого спора. И проблематика не в "программа будет правильно работать ?", ведь правильно программу можно задать и на блок-схемах.

Каша в упорядоченности элементов на плоскости и в организации топологии схем, конечно же, есть. Но нет некой каши в семантике, которая возникает в Дракон-е.

Тот же вход/выход в Дракон-е в явном виде задаётся лишь как "Заголовок" и "Конец". Т.е. семантическое понимание взаимодействия с внешней средой такое же, как и у блок-схем (и икона та же, и параметры алгоритму передаёт внешняя среда и т.д.). А остальные возникающие входы/выходы и передача управления внешней среде (диспетчеру) и от неё скрываются и являются функциональной частью семантики иных икон. Степан Митькин этот же принцип предлагает расширить и распространить на некоторые другие иконы, так как для задач вне рамок предметки с алгоритмами, управляемых временем, удобно (а то и необходимо) манипулировать с понятием "событий"/"ожиданий" в отношении определенного "ввода/вывода", специализированных операций и т.п.

В блок-схемах же действует традиционный инженерный подход: конкретная выделенная семантическая "метафора" --> конкретная геометрическая фигура и единственная с такой семантикой. И нет понятия в стиле, мол можно не отражать незначащую деталь -- незначащих деталей нет: если в изделии есть элемент с определенной семантикой, попадающий под "надзор" метафор, то он должен быть и в чертеже.
Речь в целом о принципах, дисциплина моделирующих, конечно же, может быть разной, и они нарисовать могут всё что угодно.

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

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

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

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

Согласен, но с оговоркой, что используется максимум 2-3 УГО: "блок действий", "развилка с вопросом", "соединяющая линия со стрелкой".
Подобные блок-схемы более-менее будут понимаемы.
Если же нарисовать хитроумную схему со всеми ГОСТовыми УГО, то с вероятностью 146% "домохозяйка" не догадается что значат 42% схемы.


Простите, но в примере download/file.php?id=6741&mode=view явный перебор с визуальным шумом.
Какие-то таблички, рамочки, кружочки, стрелочки, использование фоновой заливки по делу и без дела.
Из "понятного" там разве что подписи в духе "наполнение бака" (название процесса?).

Вариант "ожидание кнопки старт" -- пример того, что "умом не понять". Аналогично, "шеврон". Зачем он вообще нужен? Почему он пустой

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

В общем, вариацию Зюбина без специальной подготовки прочитать невозможно. А написать уж точно. Да и зачем, ведь Data-Ink ratio у подхода Зюбина под большим вопросом.

Это голословное утверждение.

Вот пример: MOV is Turing-complete. Речь про одну единственную x86 инструкцию.
Это весьма популярная инструкция. Конечно, если каждую программу будут прогонять через movfuscator это жесть, но никто же не заставляет использовать все-все-все возможности "ассемблера"?

Для PSV100

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

1. В языке ДРАКОН строгая семантика, но не метафоры. Нет никаких метафор или неоднозначностей. Если вы укажете на нарушение однозначности, мне придется признать ошибку и внести исправление в язык ДРАКОН.

2. ДРАКОН это не только эргономика, но и математика и программирование. Когда появилось структурное программирование, программисты забыли про блок-схемы и отказались от них.

Почему? Потому что блок-схемы не удовлетворяют требованиям структурного программирования.

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

4. Вы пишите Это не так. Вы спутали икону Пауза с иконой Время.

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

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

Повторяю, здесь нет никаких метафор, только семантика.

5. Графика языка ДРАКОН преобразуется через маршрутный транслятор Геннадия Тышова в исходный код целевого языка (target language). Транслятор не умеет обрабатывать метафору. Значит, это не метафора, а строгая математика.

6. Язык ДРАКОН наиболее полно описан в книге Учись писать, читать и понимать алгоритмы, изданной стереотипно в 2012, 2014, 2016 гг
Медицинский ДРАКОН изложен здесь

Эти две книги на сегодня содержат всю сумму знаний о языке ДРАКОН

Блок-схемы и структурное программирование



Стандарты на блок-схемы нарушают правила структурного программирования.

Язык ДРАКОН — это осторожная попытка внедрить структурное программирование в блок-схемы с учетом требований когнитивной эргономики (как я их понимаю).

Увы, но процетированное вами в полной мере относится и к Дракон-схемам.
Как вы говорите, в Драконе нет goto, goto бывает только в тексте. Но ведь в обычных блок-схемах тоже нет goto (или есть?). А тогда почему про обычные блок-схемы говорят "ориентированы на использование goto"? Ответ прост, в блок схемах возможны переходы управления, которые соответствуют goto в тексте программы. И то же самое можно сказать и про Дракон, только там это делается не совсем теми же средствами как и в обычных блок-схемах. В Драконе есть два варианта для представления goto:
- иногда средства языка позволяют сделать стрелочку в нужное место, тогда просто делаем стрелочку и всё;
- если же средства языка не позволяют сделать стрелочку, то всегда конструкцию можно разбить на несколько веток и путем передачи управления на нужные ветки, так можно реализовать требуемую передачу управления.

Владимир Даниелович, метафора в данном случае -- перенесение функции или назначаемой системной роли на графический образ необходимой геометрической фигуры в чертеже. Функция "входа из внешней среды/выход во внешнюю среду" как в блок-схемах (одна метафора) в Дракон-е распределяется между иконами "Заголовок", "Конец", "Пауза", "Синхронизатор", "установка таймера" и м.б. ещё некоторые иконы, связанные с управлением через таймер, в рамках которых даже имеется эргономичный эффект -- уточняется роль/функция в каждой иконе.
Однако, если предложение Степана Митькина вступает в силу, или уже "диалект реального времени" в таком виде и является действующим, т.е. является частью языка Дракон:
https://drakonhub.com/read/realtime

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

Да, спутал, а подразумевалось следующее:
https://forum.drakon.su/viewtopic.php?p=101352#p101373

Нет ошибок в семантике, поскольку разделяются дисциплины. Есть лишь отличия от традиционного инженерного подхода: одна роль выделяется для одной фигуры (в частности, один и тот же моделирующий может одновременно использовать схемы с исполнителем-человеком и со "строгим" исполнителем. А в последнем случае, к слову, также возможны ограничения/характеристики длительности).

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

А вот в контексте интерпретации строгой математики маршрутного управления с помощью этого транслятора возникает настороженность и недопонимание. К примеру (в теме по ссылке ниже содержаться и рисунки, связанные с цитатой):
https://forum.drakon.su/viewtopic.php?f=62&t=6097&start=40#p100673

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

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

И, кстати, в ИС Дракон для чего-то имеется "многовходовость" (множество заголовков), запрещаемая математикой Дракон-а:

Самая популярная инструкция -- отличение -- вся алгоритмика по своей сути, как продукт природного гомеостаза, заключается лишь в организации последовательности операции отличения (ну и сохранения результатов).

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

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

Изыски в визуальном оформлении намарафетить можно, что второстепенно. Первично же -- нет "шума" в семантике то -- все маршруты и переходы в/из внешней среды явны и т.д., и всё там интуитивно понятно и очевидно.

Не могу согласиться. Нет здесь неоднозначности.

1) В обоих случаях речь идет не программировании, а workflows или о медицине.

2) в обоих случаях речь идет о времени

3) в обоих случаях указывается время, заданное для икон, находящихся справа .

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

Но. Здесь нет никакой передачи управления.

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


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

А реально на стройке были случаи, что разработчики Kotlin документировали suspend через блок-схемы?

Я к тому, что Дракон-схемы плохо подходят для документирования Kotlin suspend.
И блок-схемы тоже плохо подходят.

Конечно, может встретиться в документации пара случаев, когда нужно изобразить 3 действия следующих подряд тремя квадратиками с двумя стрелками между ними. Но называть это "о, тут используются блок-схемы" у меня язык не поворачивается.