DRAKON.SU

Текущее время: Пятница, 16 Ноябрь, 2018 00:21

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 188 ]  На страницу Пред.  1 ... 6, 7, 8, 9, 10  След.
Автор Сообщение
СообщениеДобавлено: Вторник, 10 Июль, 2018 21:45 

Зарегистрирован: Среда, 07 Январь, 2015 14:53
Сообщения: 787
Мало что понял в рассуждениях участников темы.
Не знаю, можно ли назвать рассуждения научными, но точно, от практики рассуждения очень далеки.
ИС Дракон же находит применение.

От Тышова:
Вложение:
20180622_081329.jpg


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 10 Июль, 2018 22:33 

Зарегистрирован: Среда, 03 Май, 2017 09:55
Сообщения: 189
LKom писал(а):
Мало что понял в рассуждениях участников темы.

Можете спросить у Тышова может ли он сделать такую реализацию, чтобы Дракон-схема разбивалась по паузам?
По веткам НЕ разбивалась, а разбивалась именно по паузам.

Вот это будет действительно шаг вперёд.

LKom писал(а):
ИС Дракон же находит применение.

К данной теме эта картинка вообще никак не относится.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 10 Июль, 2018 22:42 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 3806
Откуда: Москва
Фотография LKom видна здесь, называется:
Цитата:
Щит управления насосной группой
на 30 кВт
для кустовой насосной станции КНС (нефтедобыча)

https://okbamur3.ru/prodykt_avtomatika

На желтой плашке гравировка:
Цитата:
СПК-107 Панель оператора

Программная сборка: Дракон-Схема 220618_458

ОКБ АМУР №3 г. Москва www.okbamur3.ru


Спасибо LKom за чрезвычайно важную информацию.
Это первое известное мне официальное свидетельство коммерческого применения языка ДРАКОН и программы ИС Дракон в изделиях промышленной автоматики.

Поздравляю Геннадия Николаевича Тышова с замечательным достижением!


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 11 Июль, 2018 10:51 

Зарегистрирован: Среда, 07 Январь, 2015 14:53
Сообщения: 787
Владимир Паронджанов писал(а):
На желтой плашке гравировка:
Цитата:
СПК-107 Панель оператора

Программная сборка: Дракон-Схема 220618_458

ОКБ АМУР №3 г. Москва http://www.okbamur3.ru

Практическое освоение ИС Дракон начато на форуме: memberlist.php?mode=viewprofile&u=5536

Пользователь А_МУР, зарегистрирован: Среда, 27 Сентябрь, 2017 18:44.

По указаниям пользователя ИС Дракон доработан в части использования языка ST системы CoDeSys по стандарту МЭК 61131-3.

От модератора

Обсуждение ИС Дракон в данной теме является офтопиком и переносится в другой раздел

viewtopic.php?f=144&t=6282


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 08 Август, 2018 20:18 

Зарегистрирован: Среда, 07 Январь, 2015 14:53
Сообщения: 787
https://forum.drakon.su/viewtopic.php?p=101872#p101872
Рис 125, в будущей (возможно новой) книге ошибка старая.
Повторяюсь, т.к. много раз и лет, на форуме об ошибке сообщалось.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 09 Август, 2018 01:38 

Зарегистрирован: Воскресенье, 09 Март, 2008 22:38
Сообщения: 342
В сообщении viewtopic.php?p=101870#p101870 Степан Митькин писал(а):
Читателю ДРАКОН-схемы иногда нужно знать, как ведёт себя алгоритм в той или иной иконе. Где ждёт внешнего события, где передаёт управление диспетчеру. Я сначала согласился с мнением TAU, что автор схемы должен такие вещи указывать: рисовать пунктирную линию вместо сплошной, например.

Но потом я понял, что такие дополнительные детали добавлять в язык не надо. Поясню. Вы ожидаете, когда пользователь нажмёт кнопку, в иконе Ввод. Этого события можно ждать год. Поэтому TAU говорит: рисуй пунктир! Покажи, что алгоритм здесь залипает! Владимир Ситников добавляет: хочу видеть, когда управление переходит диспетчеру! Покажи это на схеме!
Но ведь автор уже сказал "ждать" иконой Ввод. Значит, дополнительные средства типа пунктира избыточны. Не рисуйте пунктир, не делайте лишнюю работу.
Но передачу контроля хотелось бы видеть. Как быть? Я предлагаю дополнительные автоматические средства визуализации.
...
Вот анализ поведения икон в ДРАКОНе с точки зрения реального времени и диспетчера:
https://drakonhub.com/read/realtime
Вложение:
realtime.png

Мне кажется, в табличке присутствуют:
1) опечатка, "все прочие" иконы не блокируют исполнение (не приостанавливают).
2) некорректность - и ввод, и вывод, например, в низкоуровневых (например, ассемблерных) программах могут не быть связаны с ОЖИДАНИЕМ, а представлять собой лишь считывание содержимого заданного порта или ячейки в ДАННЫЙ МОМЕНТ ВРЕМЕНИ.
3) еще одна некорректность в случае ввода/вывода в низкоуровневых программах - данные операции могут осуществляться БЕЗ обращения к операционной системе/диспетчеру.

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

Пунктир (хотя бы) продолжаю считать нужным в случае линии от иконы "установка таймера" к "следующей". Нет никакой СЛЕДУЮЩЕЙ на самом деле в данном случае! Может быть вообще подряд несколько установок ВИ в программе, и несколько "следующих" действий - некий в известном смысле аналог распараллеливания.

Семантически разные действия с потоком управления.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 17 Август, 2018 08:50 

Зарегистрирован: Среда, 07 Январь, 2015 14:53
Сообщения: 787
LKom писал(а):
https://forum.drakon.su/viewtopic.php?p=101872#p101872
Рис 125, в будущей (возможно новой) книге ошибка старая.
Повторяюсь, т.к. много раз и лет, на форуме об ошибке сообщалось.
Владимир Паронджанов писал(а):
Прошу критиковать
Есть критика.
В.Д. Паронджанов, и что будет в книге?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 17 Август, 2018 11:26 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 3806
Откуда: Москва
LKom писал(а):
Есть критика.
В.Д. Паронджанов, и что будет в книге?

В рисунке 125 ошибка исправлена в соответствии с вашим замечанием. Спасибо за указание на ошибку

Вложение:
Рис. 125 Паралл процесс.png
Рис. 125 Паралл процесс.png [ 115.64 КБ | Просмотров: 704 ]


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 20 Август, 2018 18:33 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 213
Владимир Ситников писал(а):
Если очень хочется в Дракон-схеме получить семантику "параллельные ветки, в которых выигрывает первая выполнившаяся, а остальные при этом останавливаются", то нужно либо оставить эту идею (т.к. подобного поведения несложно добиться двумя Д-схемами), либо придумать специальную нотацию для этого. Но я не вижу целесообразности изобретения специального вида параллельного выполнения.

Что, если завершать нужно не все параллельные ветки, а нужно дождаться завершения как минимум двух веток?
Ещё одну нотацию изобретать будете?

Кстати, в целом, в инженерии имеются типовые узлы конвергенции потоков работ или событий, охватывающие все варианты исхода: от одного до всех, в т.ч. и с учётом порядка. Встречаются в некоторых нотациях потоков работ и т.п., когда в контексте соответствующей предметки уместно визуально явно выражать возникающие условия.
Или вот пример -- fault tree analysis (FTA -- дерево отказов) -- см. таблица 6.8.1 "Логические символы" (вид символов в целом можно реализовать по-разному, напр., в Р-схемах в виде спецвершин аля "(&)", "(V)" и т.п.):
https://lektsii.org/1-45186.html
Владимир Ситников писал(а):
Или такая задача: ищем запись в телефонных книгах по ФИО, но более 100 записей находить не нужно, т.к. всё рано на экране слишком много будет. Искать можно в нескольких базах одновременно. Поиск останавливаем либо через 5 секунд, либо как найдётся 100 записей, либо как все источники скажут, что "записей больше не найдено".
Для семантики "выполнять параллельно, но не более 5 секунд и не более 100 суммарно найденых записей" снова ещё одну нотацию изобретать будете?

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

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

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

Вы как раз и указывали на хорошее обобщение популярных техник взаимодействия автоматов в рамках проекта Big-Step Modelling Language:
https://github.com/z9luo/BSML-mbeddr
https://cs.uwaterloo.ca/%7Esesmaeil/publications/2010/REJ10.pdf

, где сведён опыт ряда методик, причём именно из практики (из сферы Safety-Critical, т.е. с возможностью верификации алгоритмических систем, для чего и вводятся механизмы взаимодействия). В материалах имеется в т.ч. и акцент на параллельной композиции автоматов, "вытеснение" их работы разными методами. Вместо пони и кроме линейных или одноуровневых узлов сборки потоков работ возможны и многоуровневые иерархические композиции со стартом/прерыванием работы внутренних (вложенных, в т.ч. с возможностью множества уровней) состояний/автоматов. Последний способ дивергенции/конвергенции процессов используется шире в автоматных методиках. Ниже пример (с кратким описанием семантики вместо обширных талмудов), где используется иерархия с запуском, завершением (нормальным) и плюс прерывания (в т.ч. и как приостановка) автоматов. Потребность в терминации/прерываниях и есть один из основных факторов для обоснования необходимости в иерархии автоматов в популярных методиках моделирования. В представляемой модели взаимодействия имеются и многие прочие элементы, отмеченные в BSML-mbeddr, но в явном виде (в том числе) как расширения графического формализма диаграмм состояний (в данном случае вычислительная модель есть небольшое расширение Esterel/SCADE, прежде всего, в плане политики обработки разделяемых данных/переменных):
SCCharts: Sequentially Constructive Statecharts for Safety-Critical Applications
Владимир Ситников писал(а):
PSV100 писал(а):
т.е. алгоритм автомата явно (императивно, без декларативных дефиниций) будет "вмешиваться" (что обычно не приветствуется в "автоматных" методиках) в работу иного автомата через непосредственную установку значения какого-то управляющего свойства/переменной или с помощью спецфункций и т.п.

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

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

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


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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 20 Август, 2018 18:40 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 213
Цитата:
Много раз предлагали уже: возвращать управление в диспетчер по Паузам (а не по веткам).
И всего делов.

Однако, дела весёлые получаются то ...

Ниже примерчик с попытками дополнить схему с учётом кооперативной многозадачности:
https://forum.drakon.su/viewtopic.php?f=78&t=6068&start=40#p100412
Вложение:
pauses.png
pauses.png [ 30.45 КБ | Просмотров: 679 ]

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

Степан Митькин, вроде как, в контексте автоматов как раз стремиться к декларативности (плюс снижение потребности в обратных циклах и т.д.):
https://forum.drakon.su/viewtopic.php?f=62&t=6097&sid=040cd8a3c5b416c10e352ed5997ce332#p100629

Однако, Дракон императивный то, и в данном случае, например, непонятна ситуация с теми же "входными действиями при переключении в состояние" (по ссылке выше), если ветка-состояние заканчивается переходом в это же состояние (возникает "петля", т.е. нет перехода в иное состояние и нет "переключения" в это же состояние).
В последней вариации автоматной методики:
https://forum.drakon.su/viewtopic.php?f=142&t=6297
https://drakonhub.com/files/lift.html

нет акцента на entry-действиях (или я не заметил). По-видимому, теперь подобные вспомогательные события, если таковы предусматриваются, должны быть частью "вариантов" под иконой "receive". Если быть последовательным и избегать дублирования в выражении действий, то необходимы и классические exit-реакции. Но последние будут смотреться как-то несуразно, что ли: после попадания в икону "адрес", направляющую в иное состояние, необходимо вновь вернуться в исходное состояние и выполнить вариант "exit", который, по-видимому, вынужден содержать переход в это же состояние (но при этом после exit-действий необходимо покинуть состояние согласно предписаниям ранее). Т.е. маршрутная логика вырисовывается не императивной в таких случаях, но "картинки" то прежние.
Да и конструкция "receive-выбора" выглядит громоздкой, если состояние не ожидает событий, связанных с предметными данными кооперации. Т.е. состояние требует лишь получение кванта работы (напр., процесс может быть генером данных для кооперации автоматов, idle-процессом и т.п.), и не ясно, что вписывать в качестве заголовка receive-варианта в таком случае.
Если икона-выбор "receive" единственный способ идентификации событий, то не ясно, что вписывать в заголовки receive-вариантов для выражения отрицания событий, ну и для отражения их конъюнкции. Частично варианты можно объединить (ниже от икон "вариант") шинами. Но в общем случае, при любых конструкциях выражения условий, может возникнуть пересечение линий, которое в Дракон-е "снимается" через силуэт, т.е. с помощью веток, которые, однако, уже есть "состояния". Иными словами, может потребоваться "переход в состояние" ещё при анализе событий (о вероятности смешивания "автоматных" и "обычных" веток была речь ещё в начале этой темы). И в целом, Дракон-методология имеет целую "когнитивную науку" насчёт логических выражений и требует композицию "вопросов" для конъюнкции и дизъюнкции, и для отрицания.

В общем, заменить идиому "цикла-ожидания" и "пауз" подобными методами можно лишь частично.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 20 Август, 2018 18:46 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 213
По ходу дела, вспоминается проект Reactive Programming от исследовательской группы под крышей Esterel:
http://www-sop.inria.fr/indes/rp/index.html

, где реализована техника т.н. "Fair Threads" -- потоки с обычной (вытесняемой) политикой взаимодействия и с кооперативной многозадачностью. Есть разные платформы (в т.ч. и в виде диалекта ML (FunLoft), где ряд ограничений безопасности возникает в основе "по конструкции", т.е. статически при компиляции). Для Си реализация в виде модификации pthread, подробнее:
Вложение:

Для управления потоками используются спецфункции (которые есть аля suspend-функции как в Kotlin, с возможностью блокировать потоки). А также в рамках кооперативной многозадачности предусмотрен и вспомогательный язык как обвёртка над функциями в виде макросов (технически макросы полезны в том плане, что позволяют не создавать новый поток со своими структурами данных/стеком и не использовать последующие "тяжёлые" процедуры переключения контекста). Стиль макросов (задаются заглавными буквами) направлен на построение автоматов (в данном случае таково "умение" или алгоритмические ограничения транслировать модель на исполнителя):
Вложение:
ft_aut.png
ft_aut.png [ 54.17 КБ | Просмотров: 679 ]

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

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

Если не задан явный переход в теле состояния, то подразумевается переход в следующее после исполнения реакции в текущем. Используются и "мгновенные" переходы ("IMMEDIATE(...)") -- переходы без переключения контекста на смежные процессы. Проблематика мгновенных переходов рассмотрена в проекте BSML-mbeddr (по ссылке ранее), и таковы последствия практики. Некоторые автоматные методики не поддерживают мгновенные переходы из-за возможности возникновения каскадов событий/реакций или из-за упрощения модели (с соответствующим упрощением её анализа. К слову, в тех же отмеченных SCCharts/SyncCharts мгновенные переходы имеются (с помощью которых могут быть выражены прочие "навороты"), но возможности верификации позволяют оценивать риски).

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 20 Август, 2018 18:53 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 213
Вспоминается проект InteloGraf -- "горизонтальный" Дракон:
https://forum.drakon.su/viewtopic.php?f=62&t=4060
http://intelograf.narod.ru/

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

Для Дракон-а же вновь предлагается применение "терминаторов" от блок-схем в таком виде (на конкретику содержания самого примера нет смысла обращать внимание, здесь всего лишь набор возможных "картинок"):
Вложение:
automat.png
automat.png [ 26.45 КБ | Просмотров: 679 ]

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

"Адрес" с кружочком символизирует "мгновенный" переход -- кружок есть "коннектор" для листов, но в данном случае он "мгновенно" соединяет состояния. Мгновенные переходы позволяют в т.ч. разрулить ситуации, рассмотренные здесь на форуме, к примеру:
https://forum.drakon.su/viewtopic.php?f=142&t=6246&start=140#p101970

В принципе то, вполне можно смешивать "обычные" (с традиционными заголовками и адресами) и "автоматные" ветки. Но автоматные состояния, по тем же мотивам Fair Threads выше, вполне позволяют использовать один метод ("состояния") разделения алгоритма на логические части.
Подразумевается именно мгновенный переход, а не "мгновенная" часть алгоритма (в примере переход на State2 может быть мгновенным или нет, что влияет на логику выявления событий с учётом тактов кооперации). Мгновенными могут быть и все прочие переходы в виде линий (как в состоянии S2.1 на рисунке).

Вместо иконы "параметры" для заголовка алгоритма используется "карточка" из блок-схем. Такая икона используется и в "состоянии" State1, что позволяет применять не боковое соединение и при этом нет путаницы с иконой "действие". Так предполагается локализация состояний как некие вложенные блоки или подпрограммы ("функции-состояния"), со своими переменными/объектами. Примеры возможности оптимизации памяти/переменных уже были здесь в теме (что полезно и для случаев, когда автоматы в последствие будут интерпретированы как объекты/классы с полями данных, да и, в целом, в Дракон-е не помешает упрощённая локализация объектов по областям видимости/доступности):
Beyond Event Handlers: Programming Wireless Sensors with Attributed State Machines
(кстати, в статейке выше есть пару слов насчёт сопоставления традиционных обработчиков событий в "событийно-ориентированной парадигме" и автоматов).

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 20 Август, 2018 18:59 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 213
Пример автоматов от Fair Threads демонстрирует применение диспетчера с параметризуемыми состояниями (указаний зависимости от событий и др.), и в общем случае политику диспетчеризации (которая может быть вариативной) осуществляет именно диспетчер, что также сказывается на стиле реализации алгоритмов-реакции на события (например, для диспетчера декларируется список целевых событий и внутри обработчика выполняется анализ итогов работы диспетчера).
В смежной теме про автоматы с вариацией SWITCH-технологии автоматы сами "добывают" себе события, что имеет также последствия для структуры алгоритмов -- выполняется "ручной" ввод/вывод над механизмом сообщений и анализ результата соответствующих операций (в посте ниже от указанного по ссылке есть и картинки):
https://forum.drakon.su/viewtopic.php?f=62&t=6097&start=40#p100673

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

Таким образом, конечные или целевые автоматные методологии в моделировании могут быть разными. В общем случае возникает необходимость иметь декларации атрибутов/параметров для состояний (параметры могут "передаваться" и при переходах в состояния, как при вызове процедур/функций). Кроме "карточек" в примере из пред. поста используется "синхронизатор" для попыток указания ожидаемых событий для состояния. Возможны и прямоугольники (с "полками", присоединяемые и как-то снизу), или "параллельные процессы" как здесь:
https://forum.drakon.su/viewtopic.php?f=62&t=5671&view=next#p101424

Или, как в InteloGraf, есть смысл применять вертикальные секции для иконы-терминатора (возможно совместно со вспомогательными иконами-параметрами) по какой-то дисциплине. А также, вроде бы, возможна и компактификация границ состояний в некоторых случаях, указывая терминаторы в качестве "ведущих" вспомогательных икон по аналогии с "синхронизатором":
Вложение:
states.png
states.png [ 26.48 КБ | Просмотров: 679 ]

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 20 Август, 2018 23:14 

Зарегистрирован: Среда, 03 Май, 2017 09:55
Сообщения: 189
PSV100 писал(а):
В варианте справа для "наглядности" и однородности второй ожидающий цикл, с иконой "период", всё равно отделён "паузой" -- мол так акцентируются окончания тактов работы и акты ожидания.

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

PSV100 писал(а):
Ниже примерчик с попытками дополнить схему с учётом кооперативной многозадачности:
https://forum.drakon.su/viewtopic.php?f=78&t=6068&start=40#p100412
Вложение:
pauses.png

Слева оригинал, который с точки зрения "кооператива" есть упрощённый "протокол о намерениях" для человека. К примеру, пусть как в методике по Зюбину, "запустить" есть всего лишь установка "разрешения на исполнение", а само реальное исполнение требует переключение контекста или передачи исполнителя.

Вы что-то совсем про другое говорите.
Тот пример относился лишь к тому, как изложить конкретный алгоритм для ВЫПОЛНЕНИЯ НА ПЛК.
Если ваша критика остановилась на том, что "непонятно нужны ли паузы перед запуском насоса", то это просто прекрасно.
Значит по существу возражений нет.

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

В этом же самом сообщении viewtopic.php?f=78&t=6068&start=40#p100412 я и предлагал семантику (см по слову "доходит до №9"): при получении управления, Д-схема выполняется вплоть до операции с флажком (в последствии это преобразовалось в "до ближайшей паузы"). Не нужно везде лепить "пауз 0 сек". Достаточно тех двух, которые на обратных стрелках, ведь до одной из них Д-схема быстро докрутится. "запустить-остановить" схему "запуск насоса" это лишь указание ОС на то, что теперь нужно (или не нужно) выдавать кванты времени для соответствующей Д-схемы (по-хорошему, это O(1) операция).

PSV100 писал(а):
Требуются дополнительные иконы "пауза" (пусть и перед "остановить все насосы"), которые символизируют передачу управления в кооперацию процессов (аля yield)

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


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

Как раз именно и захотели.

В том примере смотришь на картинку и видно в каком порядке что будет выполняться.
Вы посмотрите следующий пример: viewtopic.php?f=78&t=6068&start=40#p100450
Пример "Для полноты картины" (код через CASE) это пример того, как сейчас пишут, и там постоянно косячат с выбором состояний и переходов между ними.

Код с паузами гораздо понятнее, и в нём ошибиться гораздо сложнее.


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

И? Это слишком жёсткое требование что-ли?
В каких-то языках это сделать проще, в каких-то сложнее.

Возможно, в "ДРАКОН-HTML" реализовать паузу вообще не получится. Но впилось ли кому-нибудь автоматное программирование на ДРАКОН-HTML?

PSV100 писал(а):
Степан Митькин, вроде как, в контексте автоматов как раз стремится к декларативности

Не относится к обсуждаемому.

PSV100 писал(а):
(плюс снижение потребности в обратных циклах и т.д.):

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

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

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

Тем не менее, предложу (в контексте "примерчик с попытками"): входные действия нужно изображать между "обратной стрелкой" и иконкой развилки. Удивительно, но факт. Чего непонятного-то?

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

А вот эти ваши слова, похоже, относятся к вариации тов. Митькина. Если эту вариацию вам интересно обсуждать, выделяйте, пожалуйста, в отдельные сообщения. По мне, так вариация Митькина не интересна, т.к. вариация "ветка-состояние" заведомо ущербна.

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

Конъюнкции и дизъюнкции в Д-схемах это code smell в полный рост. Изобразить-то можно, но читабельности никакой.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 21 Август, 2018 19:53 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 213
Владимир Ситников писал(а):
PSV100 писал(а):
Однако, Дракон императивный то, и в данном случае, например, непонятна ситуация с теми же "входными действиями при переключении в состояние" (по ссылке выше), если ветка-состояние заканчивается переходом в это же состояние (возникает "петля", т.е. нет перехода в иное состояние и нет "переключения" в это же состояние).

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

Тем не менее, предложу (в контексте "примерчик с попытками"): входные действия нужно изображать между "обратной стрелкой" и иконкой развилки. Удивительно, но факт. Чего непонятного-то?

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 21 Август, 2018 19:56 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 213
Владимир Ситников писал(а):
PSV100 писал(а):
Требуются дополнительные иконы "пауза" (пусть и перед "остановить все насосы"), которые символизируют передачу управления в кооперацию процессов (аля yield)

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 21 Август, 2018 20:54 

Зарегистрирован: Среда, 03 Май, 2017 09:55
Сообщения: 189
PSV100 писал(а):
Ранее не затрагивалась конкретика вашего примера (в нём может быть и можно обойтись лишь "ожидающими циклами"). Схемы сопоставлялись для возможности оценки восприятия, когда возникают дополнительные "паузы" для выражения операций аля yield (от пауз в глазах рябит, фактически).

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

PSV100 писал(а):
Даже в самой простой модели взаимодействия

Абстрактные слова с непонятной целью.

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

Приведите пример задачи -- тогда и обсудим как на неё напяливается (или не напяливается) Д-схема с паузами.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 22 Август, 2018 19:32 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 213
Владимир Ситников писал(а):
В примере с насосом оказалось, что достаточно пары пауз и схема выглядит весьма приглядно

Кстати, насчёт приглядности. В том примере:
https://forum.drakon.su/viewtopic.php?f=78&t=6068&start=40#p100412

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

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

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

При сценарии выше даже в этом примерчике приглядность в виде применения лишь одной конструкции "цикл-ждать" для актов ожидания возникает за счёт лишних операций (которые в общем случае могут быть не простыми), которыми, по-видимому, якобы можно пренебречь, но вряд ли такие принципы могут быть в основании какой-то методологии в целом. Напрашивается в использование дополнительно ожидающий цикл в стиле "с ведущим синхронизатором", как здесь на рисунках (м.б. с той же надписью "0 сек", или "ждать" как в "жизнеритмах" согласно Дракон-методологии):
https://forum.drakon.su/viewtopic.php?f=176&t=6221

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 22 Август, 2018 19:36 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 213
Владимир Ситников писал(а):
Если у вас есть пример задачи, в которой возникает необходимость использовать паузы на каждый чих -- давайте его и рассмотрим.

Да хоть любой протокол, к примеру. В рамках затронутой здесь SWITCH-технологии был хороший примерчик:
http://www.kit-e.ru/articles/circuit/2007_08_170.php

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

Рисовать Д-схему на "паузах" в таких случаях у меня нет желания (да и в целом Д-схему).


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 22 Август, 2018 23:24 

Зарегистрирован: Среда, 03 Май, 2017 09:55
Сообщения: 189
PSV100 писал(а):
нет конкретики насчёт что есть "команда на запуск" и как она появляется. По-видимому, в модели исполнителя, всё-таки, предполагается не истинная параллельность. В противном случае, скорее всего, не было бы прямого доступа к разделяемым объектам/переменным и явно (согласно императивным принципам да ещё с необходимостью визуальных "метафор") задавались бы средства синхронизации/защитные секции и т.п.

А вдруг там compare&swap?
Без проблем можно читать-обновлять глобальные переменные даже когда процессы выполняются параллельно.

Если вы говорите о модели памяти, это тоже хорошо, т.к. это вопрос решаемый.
Вон, например, Node.JS живёт со своим одним потоком и ничего.

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

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


PSV100 писал(а):
Пусть флаг "есть пуск" (или необходимые объекты, если это условие есть аля функция над чем-то)

Предполагалось, что флаг "есть пуск" устанавливается исходя из значений логических входов контроллера.

Иными словами, "ожидаемый" механизм работы контроллера следующий.
1) Читаем входы. (как раз тут значение физически замкнутой или разомкнутой кнопки "пуск" превращается во флаг "есть пуск")
2) Выполняем каждую (активную) Д-схему до следующего флажка (ХЗ в каком порядке, но, допустим, согласно приоритетам, которые поставил разработчик Д-схем)
3) Записываем значения выходов (тут флаг "нужен запуск насоса" превращается в реальное замыкание реле)
4) goto 1


PSV100 писал(а):
пусть в алгоритме "остановить все насосы" (икона 11) возможна коррекция этого флага

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


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

Да, всё так. Лишняя проверка. И? Какие-то проблемы с этим?
После "7. запустить насос" можно было бы добавить паузу со словами "а всё равно делать на текущем такте нам больше нечего, можно вернуть управление". Но это больше религиозный вопрос, т.к. без этой "лишней" паузы видно, что мы уходим на ожидание.


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

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

Вариации "с ведущим синхронизатором" это совсем другая песня. И этот ящик Пандоры я бы не хотел открывать. Сейчас.
Скажу так: у "паузы 0 сек" вполне понятная семантика. Она работает РОВНО так же, как и пауза 0 сек на обратной стрелке.
Поэтому особого вреда от такой конструкции нет.

"С ведущим синхронизатором" же море непонятностей. Можно ли прицепить "ведущий синхронизатор" к группе действий? А куда переходит управление, если "превышена длительность ожидания"? И так далее. В общем, в той ветке обсудили, и вариаций пока нет.

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


PSV100 писал(а):
Цикл "с синхронизатором", фактически, с теми же "трудозатратами"

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

А как работает "с синхронизатором"? Синхронизатор выполняется ДО или после проверки условия?
С синхронизатором сложнее понять "у нас интервал запуска в 1 минуту" или это "паузы размером в 1 минуту, а интервал как получится". И так далее. В общем, простая пауза гораздо более топорный инструмент, который, тем не менее, позволяет строить адекватные алгоритмы, которые поймёт полный профан.

PSV100 писал(а):
Подобный анализ работы "коллег"-процессов неизбежен в общем случае (вне зависимости от этого примера).

Как у нас там тема называется? Зачем же вы тут корректно критикуете ДРАКОН? Разумеется, в ДРАКОНе нет средств для анализа состояния процессов. И нет средств для того, чтобы указать или понять сколько "копий запуска насоса" активно. Грубо говоря, непонятно работает ли схема в единственном экземпляре, или есть несколько схем, работающих по одному алгоритму.


PSV100 писал(а):
Остальные варианты разбрасывания "пауз" были на картинке ранее с вариантами схемы -- не слаще...

Скажем так: для конкретной задачи весьма сладко. С точностью до того, что непонятно "запуск насоса" это один экземпляр или несколько и т.п.

Но для конкретной задачи -- более чем норм, и никаких "синхронизаторов" не нужно.


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 188 ]  На страницу Пред.  1 ... 6, 7, 8, 9, 10  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2008-2018, участники конференции «DRAKON.SU», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB