DRAKON.SU

Вот и я бы так делал. Силуэт, каждая ветка соответствует состоянию КА. При любом событии внешней программой запускается Дракон-схема, проходящая по одной ветке и, возможно, меняющая состояние.

Вот нормально нарисованный КА. Только состояние может меняться внутри КА. В данном примере состояние - День Недели - меняется внешне.

Честно говоря считать это как КА можно с большой натяжкой

А что Вам не нравится?

Здесь день недели это скорее событие. А состояние всегда одно - студент учится в институте(надо подрабатывать)

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

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

Икона Выбор выбирает текущее состояние программы, соответственно, управление передается на требуемую ветку СОСТОЯНИЕ.

При достижении иконы Адрес со словом СОСТОЯНИЕ управление передается на ветку ТЕКУЩИЙ ВЫХОД и происходит выход из цикла.

Через какой Адрес СОСТОЯНИЕ N был выход из рабочего цикла, в такую ветку с именем СОСТОЯНИЕ N будет передано управление в следующем рабочем цикле.

В одном рабочем цикле передача управления с ветки на ветку возможна только для веток не имеющих слова СОСТОЯНИЕ в названии и только для веток, находящихся между двумя соседними ветками СОСТОЯНИЕ.

Текст иконы Имя ветки, содержащий слово СОСТОЯНИЕ, может содержать и другие слова, характеризующие это состояние : )

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

С днем недели Вы правы, я более близкого не нашел в книжке

Но тем не менее(как я писал), если менять День Недели внутри...
На рисунке область КА отмечена серым. Белым - исполняющая система. При любом событии (инициализация или 1 раз в час) вызывается КА. В конце серой области добавляем алгоритм перехода состояний
if (Час==24) День Недели++

Визуально это на мой взгляд лучшее, что приходит в голову. Вот я вижу сообщение Эдуарда Ильченко с реальной схемой автомата по тому же принципу.

Но я по-прежнему не уверен, что это лучше, чем граф состояний КА у Шалыто. И некоторые вещи нужно доопределять (команды - черным, примечания - синим).

И, повторяюсь, есть еще проблема доказуемости, что разработанная Вами Дракон схема является КА. Как ее проверить, что она хотя бы не зависнет? Для КА есть формальные методы.

Как во времена моей молодости вставляли студентам перфокарты
1 GOTO 2
...
2 GOTO 1

Дмитрий!
Дык и я отвечал на второй вопрос. В том ключе, что, если переходы КА полны и непротиворечивы - то импер-граф-схему (т.е. операционную графическую модель) и сделать несложно, и она (IMHO) по крайней мере, не потеряет в наглядности. Хотя второе, наверное, так же субъективно (точнее, обусловлено типом мышления), как и предпочтение "графика-текст"...
Но. Схема-то указанная и граф-, и импер-,... и даже выводима "по шампуру"... да не силуэт... Видимо, Вы это имели в виду (что может ли быть нагляднее и проверяемее, чем КА-граф, не вообще шампур-схема, а именно какой-нибудь силуэт)?

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

Вот, кстати, блог, указанный здесь, показывает, что и не обязательно с XML нужно будет дело иметь... и не обязательно императивный язык визуализировать...
Возможно, и такое развитие Вы имели в виду?.. Или пока будем определять гибрид с императивным ("КАК-") языком (учитывая также область применения - см. хотя бы здесь: viewtopic.php?p=68442#p68442)? С каким Вы бы предложили (учитывая возможные "подводные камни"...)?

Владислав!

Я давно описал в "Два пернатых" и свое видение редактора, и свое видение языка как инварианта Дракон-схемы.

Просто можно сделать приемлемое для всех решение (в виде скажем библиотеки):
1. структура данных, которую представляет собой Дракон-схема.
2. формат данных, грубо: XML, LISP(ПРОТОН), КАРТА ЗНАНИЙ, TCL, бинарный.
3. утилиты преобразования туда-обратно.

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

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