DRAKON.SU

Прочитал книгу А.Д. Закревского "Параллельные алгоритмы логического управления"
https://forum.oberoncore.ru/viewtopic.p ... 233#p77233

Очень хорошая книга. Написана простым и понятным языком.
Я перевёл некоторые алгоритмы из этой книги на язык ДРАКОН.
https://drakon-editor.com/ide/doc/examples/127

Как я переводил:

Ожидание входящих сигналов
По Закревскому алгоритм управления принимает сигналы извне через входные переменные.
Для получения сигнала имеется оператор "ожидание". В нём алгоритм ждёт, когда в одной или нескольких входных переменных появится определённое значение.
Как отобразить оператор "ожидание"? Я применил икону "Событие" ("Синхронизатор") вместе с иконой "Вопрос" и стрелочным циклом.
При этом вместо одной иконы "Вопрос" может быть несколько (логическая формула).
Смысл данной макроиконы получился такой:
Проверяем наличие некоторых значений во входящих переменных.
Если значения есть, идём дальше.
Если нет, ждём сигнала извне.
Когда сигнал приходит, снова проверяем переменные и так далее.
Это не ожидание в состоянии занятости.

Параллельные алгоритмы
Параллельные алгоритмы из книги я изображал двумя способами:
1. Макроиконой "Начало совместной работы".
2. Иконой "Параллельный процесс".

У Закревского есть операция "гашение". Это остановка всех параллельных ветвей, которые выполняются в настоящий момент.
Для гашения я применил икону "Вывод": выдать команду "прекратить параллельный процесс".

Вот операторы "ожидание" и "выдача команды":


Пример со светофором:


Пример с вертикально-протяжным станком:

Очень близко к "циклу с ожиданием" (ну, когда паузу рисуют на обратной стрелке)

Встречный вопрос: в книге встречается вариация "ждать, но не более N секунд"?
Например, "подали команду на пуск насоса и ждем срабатывание датчика давления" (см №25-26). По-хорошему, ждать нужно не бесконечно, а какое-то ограниченное время.

Согласен. Бесконечное ожидание — это обычно дефект алгоритма.
Надо указывать таймаут.
Например так:

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

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

Нельзя использовать икону Синхронизатор без наличия иконы ПускТаймера.

Т.к. надо запустить отсчет времени.

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

Получается, нужна стрелка назад "продолжаем ждать" и стрелка вниз "дождались" и еще одна стрелка вниз "не дождались".

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

Да и не сочетается "выбор" со стрелками назад.
Может, получится как-то упростить (в визуальном смысле) "выбор"?

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


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

Да.


Можете предложить, как?


Предлагаю такой вариант

Вариант 1
Переменная таймаут всегда лежит в иконе "Вопрос", к которой присоедена икона "Событие".

Точно понятно, к какому ожиданию относится проверка таймаута. Но не ясно, чего ждём.


Вариает 2
Переменная таймаут видна:
1. Ниже иконы "Вопрос" с "Событием" по пути выполнения.
2. Выше иконы "Пауза" по пути выполнения.

Ясно, изменения какой переменной мы ждём. Но можно забыть, к какому ожиданию относится таймаут.

LKom принял икону Событие за икону Синхронизатор.
Возможно, имеет смысл икону Синхронизатор показывать в виде другой графической фигуры.
А может и нет.

Знал бы -- предложил бы.
Не появляется идей, когда оно выглядело бы компактно, понятно и т.п.

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

б) Вообще останавливать Дракон-схему при наступлении таймаута. Тут, конечно, вопрос "как в обработчике" понять какое именно действие превысило указанную длительность, но может оказаться, что вариант "вообще все timeout'ы обрабатываются одинаково" не самый плохой с точки зрения надёжности. Как-никак, будет гарантия, что все timeout'ы обработаны. Это что-то сродни "обработке исключений" типа "деление на ноль".

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

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

Например, на картинке 20180225160031 (в этой теме) развилка "ДВК" (сразу после комментария "4") двумя своими ветками смотрит вниз, и вариант "в" для неё не получится. Ну, невозможно сказать "в случае превышения длительности переходи к следующему шагу". Какой там следующий (yes или no)?


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

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

http://forum.drakon.su/viewtopic.php?p=101378#p101378

Степан Митькин: - "LKom принял икону Событие за икону Синхронизатор."
У LKom-а правильно - икона Синхронизатор.

Смотрите - http://forum.drakon.su/viewtopic.php?p=101352#p101352
В.Д. Паронджанов от Четверг, 22 Февраль, 2018 16:11 (перед праздником День Защитника Отечества)


У В.Д. Паронджанов, в редакции от 22 Февраль, нет иконы Событие.

LKom прав.

Степан, объясню, почему так получилось.

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

Поэтому я удалил слово Событие которое стояло в таблице, как второе название иконы Синхронизатор.

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

Вообще, у Закревского акцент на реагирующих алгоритмах (управляемых событиями - event driven), имеющих "пассивную натуру" и пребывающих в основном в нормальном для них "спящем" состоянии ожидания.

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

Поскольку ДРАКОН рожден в космической отрасли и появился из ГРАФИТа, примитивы для описания задержек и таймеров в нем присутствуют

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

Андрей Александрович, спасибо за замечание.

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

Без такого примера трудно в полной мере понять суть предложения.

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


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


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

Рекомендую взглянуть на труды В.Е. Зюбина, как развитие результатов Закревского (или чуть иная форма построения моделей), оставаясь на простейшем уровне событийного управления с "логическим" параллелизмом:
http://forum.drakon.su/viewtopic.php?f=143&t=6160&start=20#p100964

Вариант графического формализма:
https://cyberleninka.ru/article/n/razrabotka-graficheskogo-formalizma-dlya-opisaniya-algoritmov-v-protsessorientirovannom-stile

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

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

Если коротко: после иконы активации таймера мы рано или поздно выходим в ОС. Поток управления алгоритма прерывается. В том числе - визуально. Что правильно, поскольку на самом деле ничего не происходит. Далее мы рисуем некое новое "начало" алгоритма - новый "вход" или включение его.

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

Вот, впрочем, удалось нарисовать в не столь "строгом" к порядку ввода оффлайновом редакторе Митькина

УВИ - термин, применяемый на "Прогрессе", означет "уставка временного интервала".