DRAKON.SU

Журнал "Программная инженерия", Номер 1 2019 год
Митькин С.Б.
Автоматное программирование на языке ДРАКОН
https://drakonhub.com/files/pe_drakon_a ... n_2019.pdf

Конечный автомат хорошо...
А как будет выглядеть и работать конечный автомат внутри конечного автомата?
Это если рассматривать конечные автоматы как кирпичики для построения сложных программ.

Поздравляю Степана Борисовича Митькина с замечательным достижением — публикацией оригинальной статьи " Автоматное программирование на языке ДРАКОН" в авторитетном профессиональном журнале "Программная инженерия".

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

Это правильный вопрос. Я вскользь касаюсь его в разделе "Сеть автоматов".
К сожалению, в статье не было возможности подробно рассказать о взаимодействии автоматов.
Если в кратце:
1. Есть известный набор правил, которых следует придерживаться при построении программы из многих автоматов.
2. Если не придерживаться тех правил, то возникнут известные проблемы.

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

Степан если в схеме содержится два или более одинаковых конечных автомата, то мы можем говорить о программных экземплярах автоматов?

Для меня вопрос применения конечных автоматов, для построения схем по "кирпичикам" это ежедневный и злободневный вопрос.

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

Если экземпляр автомата не получил поток управления, то он сохраняет на своих входах предыдущее состояние. И это оказалось очень критично.

Если не понятно - могу приводить примеры!

У меня есть несколько приемов обхода таких состояний, но все они вносят такой сумбур, что схема становится не читаемой

Отличная статья! Спасибо, внушает

В статье: (см.стр.10)

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

И еще непонятно назначение ветки "Exit". Может иконку ветки совсем убрать? А иконку Конец - оставить.

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

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

Потому что из одного состояния может быть несколько выходов, а правило, выполняемое на любом из выходов из состояния, должно быть одно.
Пример: "при выходе из состояния X закрыть файл Y". При этом из состояния X автомат может перейти в состояния A, B и C.

Некоторые автоматы могут выключить себя. Они соответствуют конечным алгоритмам. Для таких автоматов ветка с концом нужна.
Некоторые автоматы не могут выключить себя сами. Они соответствуют бесконечным алгоритмам (например, алгоритмы управления). Для таких автоматов ветка с концом не нужна.
В DRAKON Editor есть ограничение: ветку с выходом нельзя удалить.

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

Что такое - "уникальный выход"?

Откуда взят такой термин?

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

https://forum.drakon.su/viewtopic.php?f=94&t=6449#p102803

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

В общем случае необходимо различать:
- переходы в другие состояния, а также и переход в собственное состояние -- "петля" в графах переходах/диаграммах состояний. В последнем случае также необходимо выполнить выходные действия и затем входные -- "сброс" или "reset", начинаем работать с начала, м.б. с корректировками;
- "шаг системы" без перехода в иное состояние. В автоматных методиках часто действия без перехода обозначаются аля "do action/activity" или "during action" (в случае поддержки множества событий, в каком-либо виде, возможно дополнительное деление аля "immediate" или нет -- многократное или одноразовое исполнение при дублировании событий, и т.д.).

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

Входные действия могут быть определены в местах с "зеленым маркером", как здесь:
https://forum.drakon.su/viewtopic.php?f=62&t=6097#p100629

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

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

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

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

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

Теоретически это возможно, но на практике такая ситуация мне не попадалась.

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

Язык должен быть ТУПОЙ, КАК ДРОВА.

Иначе народ не поймёт. Иначе будет попытка повторить гротескную сложность си-плюс-плюс с его виртуальными перегруженными операторами.



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

К сожалению, должен, но в реальности Дракон, фактически, от С++ не отстаёт и даже в некоторых моментах превосходит.
Рядом, в иной теме форума, были соответствующие заметки насчёт семантической выразительности. Вот появился и ещё один пример, насчёт "вставки":
https://forum.drakon.su/viewtopic.php?f=78&t=6453#p102843

Оказывается, что "вставка" понимается полиморфно: и как "повторное использование (без вызова)", и как "вызов процедуры/функции". В "стандарте" предназначение определено, скорее, как первое:
https://forum.drakon.su/viewtopic.php?f=62&t=6156#p100785

При этом первоначально, до Дракон-а в массах, всё же "вставка" была "предопределенным процессом" как и в блок-схемах:
https://forum.drakon.su/viewtopic.php?p=23281#p23301

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

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

Нет, не совсем то же самое. Всё же, прежде всего, понятие некой сети автоматов, фактически, задаётся вне условной методики "силуэт-автомат" -- композиция автоматов ("силуэтов") не отражается в Дракон-схемах -- необходимы иные вспомогательные формализмы.
В случае сети возникает "гипер", но как совокупность совместно исполняемых процессов. Гиперпроцесс же предполагает взаимоисключаемое исполнение процессов (функций-состояний). Термины из результатов В.Е. Зюбина (есть и соответствующие математические формализмы):
https://forum.oberoncore.ru/viewtopic.php?f=152&t=5978#p99829

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

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