DRAKON.SU

Они не второстепенны, а первостепенны.
У Тышова предусмотрены 3 режима работы программы ИС Дракон:
а). Обычное (неавтоматное) программирование.
b). Автомат 1. (автоматное программирование).
c). Автомат 2. (автоматное программирование).
Мои комментарии относятся только к случаю а).

. Спасибо, это очень важно. Желательно сформулировать, какие именно доработки нужны.

Объяснение простое. У меня в книгах было предусмотрена такая возможность на всякий случай.
И Тышов ее реализовал.

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

Даже затрудняюсь уточнить, какие доработки нужны, скорее всего, политические прежде всего (особенно в связи с функционалом ИС Дракон, как некоего эталонного представителя Дракон-платформы).
Ранее Вы указали:

Действительно, есть впечатление, что закреплённых метафор за элементами языка нет.
Ниже рисунок из затронутой ранее темы про автоматы:
https://forum.drakon.su/viewtopic.php?f=62&t=6097&start=40#p100677

Как я пониманию, если в трансляторе выбрать случай а) "Обычное (неавтоматное) программирование", то диаграмму необходимо интерпретировать как традиционную алгоритмическую схему императивного алгоритма, согласно принципам графа передачи управления (о чём посвящены основные публикации по Дракон-у). Если же выбрать необходимый вариант трансляции "автоматное программирование", который соответствует примерам в смежной теме форума по ссылке выше, то семантика элементов языка существенно изменяется. Каждая ветка силуэта приобретает собственные вход/выход (фактически, трансформируется в функцию), уже нет маршрутного следования по силуэту -- при входе в ветку (кроме первого входа в алгоритм) происходит выход из алгоритма. Причём вход в ветку может быть произведен не только через переходы по "адресам" из других веток, но и внутри самой ветки с помощью циклов (которые на рисунке помечены закрашиванием вторых линий). Т.е. цикл согласно правилам императивных схем означает переход на первую икону в ветке, но в "автоматной" схеме этот переход "перехватывается" или интерпретируется как переход на "заголовок" ветки, в результате чего и происходит выход из алгоритма. И цикл в общем случае не временно прерывается до последующего входа в алгоритм, а окончательно -- вход в алгоритм может произойти в рамках любой ветки.
Так во всяком случае видится семантическая политика, фактически, нового языка (исходя из разговоров в смежной теме). Причём такую методику не получится интерпретировать в стиле аспектно-ориентированного моделирования. В последнем случае, если в ту же императивную модель внедряется скрытый функционал, то нет искажения исходной модели вычислений.
И по-видимому, например, Степан Митькин запросто может сделать свой вариант автоматной трансляции схем, также вне императивного исполнения (в соотношении с графом передачи управления):
https://forum.drakon.su/viewtopic.php?f=62&t=6097#p100629

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

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

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

Это называется доведение до абсурда.

Кто-то "ожидание" воспримет буквально. Раз сказано ждать, значит нужно ждать.
Кто-то воспримет интеллектуально. Тут ждём, но можно же ещё вот это сделать.

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

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

Вот когда в Дракон-силуэте возникает отсутствие необходимого "шума" -- уже ведь другие эффекты то -- "семантическое голодание", а хуже всего -- семантическое искажение.

Вы правы. В моих книгах я описывал только императивный (процедурный) вариант а).

Вы правы. В автоматном программировании на языке ДРАКОН семантика иная.

Кто придумал автоматное программирование на языке ДРАКОН?

В случае программы ИС Дракон два автоматных режима придумал Сергей Ефанов, а реализовал Геннадий Тышов.
К сожалению, в литературе это нигде не описано.

Это означает, что имеет место две дополнительных (автоматных) интерпретации дракон-схем.

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

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

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

Это очень хорошая идея.

Просьба пояснить слова "вводят в заблуждение". Почему вводят в заблуждение? В чем состоит заблуждение?

Язык ДРАКОН развивается. Практика (Сергей Ефанов и Геннадий Тышов) порою оказывается впереди. Этому можно только порадоваться.
Хотя, конечно, новые возможности, которые нигде не описаны и не опубликованы, — это трудности роста, которые сдерживают распространение языка.

Хотелось бы услышать комментарий по этому важнейшему вопросу от Сергея Ефанова и Геннадия Тышова или LKom.

Возможно, вы считаете, что я считаю, что Дракон лучше Зюбина.
Да, блин. И Дракон-схемы и Зюбин-схемы плохи. У каждой из них есть неопределённость семантики исполнителя. Иными словами, порядок выполняемых действий существенно зависит от знания документации на сам язык.

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

PS. Я не считаю, что домохозяек нужно переводить на Kotlin.

https://news.mail.ru/economics/33930726/?frommail=1

Немного изменим утверждение Дмитрия Рогозина:

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

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

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

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

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

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

Тогда такая идея позволяет задать такую схему:

, которая выражает вообще не алгоритм, а структуру данных (где ";" -- последовательность в кортеже):
"A: int; array of (B: int; C: int); D: int"

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

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

Имя ветки — это просто метка. Она не выполняет никаких действий. Действия начинаются на выходе иконы "Имя ветки". Перенос стрелки на вход иконы "Имя ветки" ничего не меняет (если не считать того, что схема стала запутанной).

Возможно, что я вас не понял.

Казалось бы, но не всегда.



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

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

Получается, чтобы составлять/читать программы в таком стиле нужно знать как ведут себя каждые попарные комбинации элементов. Недостаточно 1 раз понять, что "стрелка передаёт управление". Оказывается, что если она ведёт в начало ветки, то она не просто так управление передаёт, а в диспетчер. И визуально это вообще невозможно понять.

Картинка в которой стрелка идёт выше заголовка ветки, это, похоже, одна из попыток PSV100 хоть как-то структурировать этот "автоматный подход". Хоть стрелки и выглядят необычно, но зато появляется простое правило: управление в диспетчер передаётся тогда, когда дело доходит до заголовка ветки тем или иным образом.

Сам механизм "возвращать управление в начале ветки" звучит несколько странно (сама идея мне не нравится, т.к. разбивка на ветки и возврат управления это всё-таки разные вещи), но вариация PSV100 звучит гораздо лучше, чем изобретение "специального смысла у стрелки, которая ведёт в начало ветки".

Сдается мне, это "на всякий случай" вовсе не случайно. А имеет глубокие корни.

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

Итак, место появления "Дракона" - а точнее, технологии ГРАФИТ-ФЛОКС - НПЦ АП имени Пилюгина. Фирма, занимающаяся созданием систем управления ракет-носителей и разгонных блоков.

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

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

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

Взамен полноценной операционной системы реального времени (вроде VxWorks, Lynx, QNX и пр.) могут иметься некоторые самописные "рудименты" диспетчера задач - скорее всего, на машинах "Бисер" НПЦ АП подобным образом и организован вычислительный процесс, не исключено вообще что "пакет" задач носит фиксированный характер с выделением входящим в него четко определенным при проектировании процессам "квантов времени" в каждом "системном цикле" - так называемая "синхронная" диспетчеризация без прерываний.

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

Если же брать, скажем, космические аппараты ДЗЗ, производимые РКЦ "Прогресс", они имеют срок активного существования несколько лет (а не минут!), более разнообразный и широкий набор бортового оборудования, большее разнообразие функционального программного обеспечения, связанного с управлением теми или иными бортовыми системами (их может быть порядка десятка, а модулей функционального ПО, функционирование которых, подчеркну, должно организовываться параллельно), а также требуют большего разнообразия и динамичности в функционировании, что обуславливает большую адекватность асинхронной вытесняющей диспетчеризации. И даже если то системное ПО, что этим занимается, не носит названия "операционной системы", по сути ей является.

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

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

Примечания: 1) Д2Вх1 - диспетчер БОС, на примитивах "выхода" указывается, что ему передается управление 2) Вход 1 включается из других функциональных программ, работающих параллельно в многозадачной ОС. Их имена, например, А25 и Р11, указаны рядом с граф.примитивом входа. У других входов подобные имена не указаны, поскольку это - части одного "функционального" алгоритма. Здесь мы наглядно видим отражение сложности межзадачного взаимодействия.

И даже вплоть до такого...

И еще "занимательная картинка".

P.S. Сразу хочу подчеркнуть: ничего секретного или даже ДСП в этих старых "рабочих" картинках, да еще и без всяких расшифровок, нет и в помине.

ТОЛЬКО ДЛЯ АВТОМАТНОГО ПРОГРАММИРОВАНИЯ.

В автоматном программировании на ДРАКОНе:

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

2) обсуждаемый вариант (цикл со стрелкой, ведущей на выход иконы "Имя ветки") эквивалентен выходу через икону Адрес.

3) это значит, что стрелку можно (но так делать не надо) оторвать от иконы "Имя ветки" и заземлить ее к нижней шине силуэта через икону Адрес. Разницы никакой.

4) Вариант 3 теоретически возможен, но на практике плох тем, что появляется лишняя икона Адрес, загромождающая схему.

Лучше уж тогда не изобретать новый смысл икон "Адрес", не изобретать новый смысл "стрелки, ведущей в начало/конец ветки".

Достаточно было существующей иконы "пауза". Чем она плоха?

"Специальный смысл стрелки, ведущий в начало ветки" это хороший пример того, как НЕ нужно развивать Дракон.
Иными словами, "выход из ветки через икону Адрес (по С.Д. Ефанову)" это прекрасный пример как можно запутать схему на ровном месте.

Владимир, что означают ваши слова?

Вы предлагаете (в случае автоматного программирования) заменить икону Адрес на икону Пауза? Или нет?
Просьба пояснить

Я предлагаю в случае автоматного программирования оставить икону Адрес в покое.

Если же нужна операция "вернуть управление в диспетчер", "вернуть управление в ОС" и т.п., то в этом месте нужно разместить икону Пауза. Например, "пауза на 0 секунд".

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