DRAKON.SU

Текущее время: Воскресенье, 27 Май, 2018 20:43

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




Начать новую тему Ответить на тему  [ Сообщений: 43 ]  На страницу Пред.  1, 2, 3  След.
Автор Сообщение
СообщениеДобавлено: Вторник, 15 Май, 2018 19:11 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 157
Согласно текущим правилам выражение ожидания событий могло бы быть примерно в таком виде:
Закревский. Параллельные алгоритмы логического управления
Вложение:
20180225160031.png
20180225160031.png [ 167.93 КБ | Просмотров: 198 ]

, где используется икона "событие" (как "синхронизатор", но без нагрузки, т.е. без указания времени). Тогда "автоматные" ветки обычно будут начинаться с "ожидающего цикла" в стиле начала параллельного действия 10 на рисунке. Или же ожидающий цикл может быть с использованием "периода" (нулевой или без указаний времени) как здесь:
https://forum.drakon.su/viewtopic.php?f=78&t=6068&start=40#p100412

В общем случае вместо одиночной проверки состояния переменной "пуск" (на рисунке выше) возможен каскад разнообразных условий, как в процессе atFloor выше: "closeButton() or t >= Tdoor", для чего напрашивается композиция икон "вопрос" (а в целом возможно и использование "выбора" с шиной вариантов). Но, во-первых, по-Драконовски то, необходимо вместо вопроса "t >= Tdoor" для "тестирования" таймеров использовать икону "пауза" (или "период", или что-то подобное), однако семантика которой заключается в "блокировке" алгоритма. В смежной теме насчёт методики Закревского (по ссылке выше) так и не нашли решения для гибкого построения композиции условий.

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

Возможны случаи моделирования, когда потребуются какие-то дополнительные соглашения. К примеру, мол диспетчер понимает, от чего зависят условия возникновения событий (какие используются объекты или переменные), и диспетчер передаёт управление (исполнителя) алгоритму лишь тогда, когда в системе возникнут необходимые сигналы (изменится состояние объектов и т.п.). В каких-то случаях, чтобы подчеркнуть семантические особенности, возникает потребность в использовании операций ввода/вывода (над каналами связи или т.п.). В автоматном программировании школы В.И. Шелехова автоматы могут общаться и через отправку/получения сообщений:
В.И. Шелехов. Язык и технология автоматного программирования
Код:
process Работа_часов_с_будильником {
  Часы t = Часы();
  off:    receive H           { t.inc_h()    #off }
          else receive M   { t.inc_m()   #off }
          else receive A             { #set }
          else  { tick()  #off }

  set:    receive H          { t.inc_alarm_h()    #set }
          else receive M  { t.inc_alarm_m()  #set }
          else receive A   { t.bell_on()           #on }
          else  { tick()  #set }

  on:    receive H         { t.inc_h()      #on }
         else receive M  { t.inc_m()     #on }
         else receive A   { t.bell_off()   #off }
         else  { tick(); if (t.bell_limit()) { t.bell_off() #off } else #on }
}

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

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

Когда-то предлагались на форуме такие варианты организации силуэта:
https://forum.drakon.su/viewtopic.php?p=91480#p91480
https://forum.drakon.su/viewtopic.php?p=91480#p92660

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

На сегодня, вроде как, икона "событие" забанена, и стандартных вариантов отражения событий нет:
https://forum.drakon.su/viewtopic.php?f=176&t=6221#p101386

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 15 Май, 2018 19:20 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 157
В последнем примере выше для процесса "Работа_часов_с_будильником" в начале кода есть действие "Часы t = Часы();". На Дракон-схеме, по-видимому, это действие будет оформлено в виде первой ветки силуэта, не являющейся "веткой-состоянием" в отличие от прочих веток. Или же есть необходимость в таких алгоритмах:
https://forum.drakon.su/viewtopic.php?p=91480#p91478

, где оператор выбора "СОБЫТИЯ", по-видимому, ещё необходимо "подкрепить" какой-то иконой "событие". В данном случае, если и говорить о каких-то возникающих вариантах алгоритма, то эти варианты, как таковые, идентифицируются иными ветками без какого-то оператора "ожидание", или выражение "условий для автомата" отделено от действий при этих условиях.
Короче говоря, силуэты на практике в Дракон-схемах могут быть скомпонованы по-разному в зависимости от потребностей, установленной дисциплины, или же из-за необходимости в ликвидации пересечений и т.д. и т.п. И предстоит ещё работа по формированию реального представления автомата.

На примере Esterel -- древней известной (относительно) автоматной школы -- автомат, как "высокоуровневая" алгоритмическая абстракция, понимается примерно так (упрощённый псевдокод по мотивам, однако в т.н. "синхронных" языках моделирования/программирования, в текстовых и графических, имеются специализированные языковые конструкции с подобной семантикой):
Код:
reset
    do
      A || B || C
    until X do D|E end
    until Y do F end
every Z

Выше в начале исполняется параллельная композиция процессов A, B, C (понимая широко как произвольное совместное исполнение процессов). Затем, в контексте оператора do...until (в данном случае с двумя условиями перехода), при возникновении события X процессы A, B, C "вытесняются" (останов), и исполняется процесс D или E. В случае события Y -- переход на процесс F. При возникновении события Z, на которое "реагирует" оператор reset...every, происходит "возврат" на начало оператора, и вновь запускаются процессы A, B, C (причём "возврат" понимается как "сброс", т.е. он может произойти и при работающих этих процессах, в результате они начнут работу с начала, т.е. как автоматы перейдут в свои начальные состояния).
Операторы автоматных переходов могут "взаимодействовать" с процессами, например, внутри процесса может быть нечто такое:
Код:
...
global x;
...
process any_proc {
   ...
   do
     x = f1();
     yield;
     x = f2();
   until x > 0;
   ...
}

Выше процесс изменяет глобальный x до тех пор, пока не достигнуто условие "x > 0". При этом внутри оператора do...until содержится оператор yield, вызывающий приостановку алгоритма и "выход в диспетчер". По отношению к алгоритму могут существовать внешние операторы переходов между процессами (аля do...until), которые могут прекратить его работу, к примеру, этот x может изменять целая кооперация процессов для достижения общего результата. После "возвращения" в процесс (в рамках отработки оператора yield) выполняется внутренняя проверка условия в until, которая может прервать исполнение блока-оператора. Если алгоритм продолжается, то на втором такте автомата x изменяется по-другому (тем самым регулируется "гранулярность" отражения автоматных состоянии -- напр., незначительные вариации на тактах автомата отражаются внутри локализованного блока кода (и существуют различные способы для потребностей), без переключений на другие "функции-состояния"). При достижении конца блока (точки until) вновь осуществляется "выход в диспетчер" и повторяются все проверки, при потребности цикл возобновляется и т.д.

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 15 Май, 2018 19:28 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 157
Попытаться ввести операторы "автоматного перехода" (как в пред. сообщении) теоретически возможно, выделяя группу действий как при использовании иконы "продолжительности":
https://forum.drakon.su/viewtopic.php?f=172&t=5370#p91440

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

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

Во-вторых -- подобная попытка введения новых операторов, фактически, бесполезна. В Дракон-е не выделяются алгоритмические блоки, прежде всего иерархические, вложенные, с явными наглядными "точками", по которым можно "прыгать" согласно определенным правилам.
Достаточно взглянуть на возникающие конструкции циклов, включая и вложенные, с каскадами условий, с задействованием силуэта и пр.:
https://forum.drakon.su/viewtopic.php?f=143&t=6249#p101669

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

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

И если вернуться в начало ветки форума:
Цитата:
1. В статье 1996 года Анатолий Абрамович Шалыто сравнивает свой метод с методом Ашкрофта-Манны и делает вывод, что метод Шалыто удобнее. Шалыто не сравнивает свой метод с языком ДРАКОН, так как ДРАКОН тогда был практически неизвестен.
2. Потом Анатолий Абрамович Шалыто узнал про ДРАКОН, но, по-видимому, предположил, что ДРАКОН не отличается или мало отличается от метода Ашкрофта-Манны. И снова сделал вывод, что метод Шалыто лучше.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 17 Май, 2018 18:04 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 157
Сегодняшнее положение дел в Дракон-е вокруг понимая "событий" и "синхронизации" вызывает некоторую неоднозначность:
https://forum.drakon.su/viewtopic.php?p=101352#p101368
Вложение:
ico_sync.png
ico_sync.png [ 245.55 КБ | Просмотров: 171 ]

К примеру:
Вложение:
ico_sync_wait.png
ico_sync_wait.png [ 54.03 КБ | Просмотров: 171 ]

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 17 Май, 2018 18:12 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 157
Если воспользоваться результатами Закревского и Зюбина, то в качестве эксперимента для Дракон-а вырисовывается такая картина.
На примерах схем от Степана Митькина в рамках темы:
Закревский. Параллельные алгоритмы логического управления
Вложение:
20180225160004.png
20180225160004.png [ 48.46 КБ | Просмотров: 171 ]

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

Есть возможность для иконы "синхронизатор" оставить семантику "продолжительности действий" как универсальный контекст для любой предметки (подразумевается метафора "периода", но не паузы, а длительности исполнения):
Вложение:
ico_period.png
ico_period.png [ 145.27 КБ | Просмотров: 171 ]

А для "ожидания" события можно воспользоваться кружочком с "ожидающей" стрелкой от Зюбина -- как "соединитель", но не с листами для печати, а коннект с "диспетчером":
Вложение:
lin_alg.png
lin_alg.png [ 41.03 КБ | Просмотров: 171 ]

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 17 Май, 2018 18:14 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 157
Совмещение "пауз" и "ожиданий" (как и для "пауз", каждый раз, попадая в "ожидающий вопрос", выполняется ожидание события) -- оригинал и модификация схемы:
Вложение:
20180225160011.png
20180225160011.png [ 145.47 КБ | Просмотров: 171 ]

Вложение:
svet_alg.png
svet_alg.png [ 108.59 КБ | Просмотров: 171 ]


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 17 Май, 2018 18:19 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 157
Пример с вертикально-протяжным станком -- оригиналы и модификация схем:
Вложение:
20180225160027.png
20180225160027.png [ 114.09 КБ | Просмотров: 171 ]

Вложение:
stan_alg.png
stan_alg.png [ 90.94 КБ | Просмотров: 171 ]

Вложение:
20180225160031.png
20180225160031.png [ 167.93 КБ | Просмотров: 171 ]

Вложение:
stan_alg2.png
stan_alg2.png [ 127.58 КБ | Просмотров: 171 ]

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 17 Май, 2018 18:24 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 157
Уточнения для "управляющих алгоритмов реального времени, или алгоритмов, управляемых временем":
https://forum.drakon.su/viewtopic.php?f=176&t=6221#p101394
https://forum.drakon.su/viewtopic.php?f=176&t=6221#p101395
https://forum.drakon.su/viewtopic.php?f=176&t=6221#p101428

"Разрыв потока управления" с "многовходовым силуэтом" -- оригинал и вариация по мотивам:
Вложение:
СхемаСРазрывомДляПаронджанова.jpg
СхемаСРазрывомДляПаронджанова.jpg [ 112.21 КБ | Просмотров: 171 ]

Вложение:
alg_timers.png
alg_timers.png [ 36.22 КБ | Просмотров: 171 ]

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

Ожидания "на таймерах" также могут быть составными (в том числе и в совокупности с иными операциями над объектами других типов). По аналогии с иконой "пуск таймера" ожидающие "вопросы" по времени можно выделить двойной боковой линией.

В последней ветке используется "ожидающий выбор". При необходимости, конечно же, для конкретной предметки могут быть свои специализированные или адаптированные ожидающие операторы (напр., вместо композиции условий используется один "вопрос" с "полкой" для расшифровки условий аля:
A(x) && B(y)
-------------------
x > y

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 17 Май, 2018 18:27 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 157
Вход от диспетчера и выход в него возможен и для примитива (аля работающие в системе обработчики событий или функциональные задачи):
https://forum.drakon.su/viewtopic.php?f=176&t=6221#p101429
Вложение:
ДляПаронджанова2.png
ДляПаронджанова2.png [ 17.96 КБ | Просмотров: 171 ]

Вложение:
alg_uvi.png
alg_uvi.png [ 16.34 КБ | Просмотров: 171 ]


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 17 Май, 2018 18:30 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 157
Икона "ожидание" может использоваться и сама по себе как аля "пауза". В этом случае элемент интерпретируется как явная передача управления с последующим возвратом в эту же точку. Например, работающие сопрограммы/корутины после кванта работы могут переключать контекст ("делясь" процессором), или как-то косвенно, без явных условий событий, организовывать взаимодействие. Упрощённо -- универсальный оператор аля "yield" в каком-либо виде. В т.ч. yield может возвращать и данные как временный оператор возврата из алгоритма, что практикуется в ряде языков программирования/моделирования. Как, напр., в Python для паттерна "генератор", где в цикле (оператор цикла "понимает" как вызывать yield) исполняется генерирующая данные функция (процедура) по схеме:
https://lancelote.gitbooks.io/intermediate-python/content/book/generators.html
Вложение:
alg_gen.png
alg_gen.png [ 21.96 КБ | Просмотров: 171 ]


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 17 Май, 2018 18:32 

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 18 Май, 2018 14:02 

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

PSV100 писал(а):
Вложение:
stan_alg2.png


На этом алгоритме изменилась семантика.

1.1) Раньше было: "дождаться пока ДВК и ДВП перейдут в <<Да>>".
В варианте stan_alg2.png получилось: "дождаться пока ДВК перейдёт в <<Да>>; дождаться пока ДВП перейдёт в <<Да>>". При этом, значение ДВК может измениться пока мы ждём ДВП. Первый вариант "в одном цикле" (без возврата управления) получал Да+Да, а второй может получить Нет+Да.

1.2) По-моему, правильнее было бы помещать yield иконку на стрелке из ДСК/ДНП. Раньше она была, но сейчас пропала. Как раз её можно было бы вернуть и на ней разместить yield.

2.1) Вариант возврат управления слева от вопроса "Пуск" выглядит хорошо. Тут понятно, что есть единственный вариант продолжения и понятно, что мы ждём этого самого пуска.

2.2) Непонятно что значит вопрос "ПТП" с двумя выходами и возвратом управления. Что, если значение ПТП всегда равно <<Да>>? Нарисованный слева "возврат управления" будет как-нибудь влиять? Честно говоря, когда слева от ПТП нарисована иконка синхронизатора (ну или как её там) всё равно непонятно как предполагается обработка ПТП. Но я к тому, что "возврат управления" слева от иконки вопроса, у которой обе ветки идут вниз смотрится вообще непонятно.

3) С одной стороны вариант yield иконки, мне нравится (начертание -- без понятия, я пока больше про семантику), но остаётся за кадром как отобразить "ждём не более 5 секунд, если не дождались, то план Б".

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

Является ли примитив reentrant или нет? Ну, может ли он запуститься заново, если он внутри стоит на yield, а пришло событие, подходящее под его запуск? По-моему, так не должно быть. Ну, мы же как бы не закончили ещё примитив выполнять.

А в alg_uvi.png интереснее: что, если посредине одного примитива мы зашли в yield, то можем ли мы начать обработку какого-то другого примитива, если пришло событие подходящее для него? Или мы должны дождаться входа из 1-го примитива? Может потребоваться как один, так и другой вариант. Возможно, нужна какая-то привязка "примитивов-силуэтов" к "потокам выполнения".


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

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 157
Владимир Ситников писал(а):
2.2) Непонятно что значит вопрос "ПТП" с двумя выходами и возвратом управления. Что, если значение ПТП всегда равно <<Да>>? Нарисованный слева "возврат управления" будет как-нибудь влиять? Честно говоря, когда слева от ПТП нарисована иконка синхронизатора (ну или как её там) всё равно непонятно как предполагается обработка ПТП. Но я к тому, что "возврат управления" слева от иконки вопроса, у которой обе ветки идут вниз смотрится вообще непонятно.

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

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

Возможны и иные варианты операции yield без явной передачи данных и явного ожидания события (косвенно). Выше в теме была затронута древняя Esterel, где, как и у упомянутых Закревского и Зюбина, техника моделирования процессов основана на разделяемых переменных, но с уже выраженными "автоматными" принципами. Ниже примерчик по мотивам тех краёв (Pascal-подобный псевдокод):
Код:
type SomeObj = active object
public
    input  x: int;
    output y: int = 0;
private   
    shared var s1, s2, s3: int;

    procedure proc1;
    begin
      init;
      loop
        s1 := comp1(x);
        pause;
      end;
    end;

    procedure proc2;
    begin
      loop
        s2 := comp2(x);
        pause;
      end;
    end;

    procedure proc3;
    begin
      pause;
      loop
        s3 := comp3(s1, s2);
        pause;
      end;
    end;

    procedure proc4;
    begin
      pause;
      pause;
      loop
        y := comp4_1(s3);
        pause;
        y := comp4_2(s3);
        pause;
      end;
    end;

begin
  prepare;
  async par([x], [y], [proc1, proc2, proc3, proc4]);
end;

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

"Активный" объект SomeObj имеет вход и выход. В исполняющем теле объекта после некой инициализации prepare запускается оператор "par" -- организация параллельной композиции процессов, в данном случае с т.н. "синхронной" моделью вычислений. Оператор "async" указывает на асинхронность -- каждый процесс (процедура) со своим исполнителем (потоком). Семантика вычислений сохранится, если в реальности будет лишь один исполнитель (или же асинхронность не указана, или определена отдельно для каждого процесса и т.д.).
Такая форма оператора "par" предусматривает в качестве аргументов массив ссылок на input-переменные, массив ссылок на output-переменные, массив процедур/функций. Бесконечно (в цикле) выполняются указанные процессы: при появлении входа реализуется глобальный логический такт автомата -- итерация цикла, заставляющая работать все потоки. После отработки процессов возвращается результат (обновляются output-параметры). Параллельные процессы общаются между собой через разделяемые переменные "shared var" -- нечто вроде volatile-переменных со своей семантикой: процессы манипулируют копиями переменных (при потребности), после каждого такта общие переменные обновляются, возможно с особенностями (к примеру, если несколько процессов изменяют одну и ту же переменную, то можно осуществлять сборку конечного значения через необходимые функции).
Оператор pause есть аля yield -- приостанавливает поток выполнения, указывая на конец локального такта автомата в процессе (когда все процессы завершат свой локальный такт, завершится и глобальный такт с обновлением выхода).
Процесс proc3 начинается с pause -- первый такт автомата пропускается, т.к. переменные s1 и s2 ещё не определены -- задержка исполнения процесса, при этом виртуальный (или реальный) диспетчер переменные s1 и s2 буферизирует для процесса proc3 (диспетчер "понимает" взаимосвязи в потоках данных, shared var и input/output -- виртуальные переменные (как и у Зюбина общие переменные), могут быть и массивы/списки/очереди данных вместо одиночного скалярного значения, внутренняя реализация механизма зависит от потребностей, к примеру, м.б. реализован как массив с политикой кольцевого буфера, и т.д.). Процесс proc4 имеет двойную задержку согласно стадии конвейера, при этом внутри рабочего цикла имеется дополнительная "пауза" -- такты автомата реализуются по-разному в данном случае. Процесс proc4 устанавливает выходной параметр "y". На начальных тактах автомата, где процесс proc4 ещё не работает, для параметра действует значение по умолчанию.

На Р-схемах такой автомат можно отразить так (для Дракон-а, по-видимому, необходимы идентичные принципы, но возникают свои особенности, о чём далее):
Вложение:
SomeObj.png
SomeObj.png [ 19.83 КБ | Просмотров: 66 ]

В данном случае "пустая" двойная дуга -- "петля" в графе переходов без действий и условий -- интерпретируется как "пауза" (вместо циклов). Двойные и более "паузы" можно отмечать и иначе (к примеру, как и в тексте аля "pause[2]", так и в графике в виде заголовка дуги как "+[2]====+", где "+" -- вершина).
Оператор "par" задаётся как спецструктура с отмеченной спецвершиной "(||)" -- отражается структура процессов согласно отношениям "производитель-потребитель" (или ярусно-параллельная форма) над общими данными, "двойные" вершины подчёркивают факт наличия асинхронности или собственного исполнителя (вместо прямого доступа к разделяемым переменным для каждого процесса можно задать свои входные/выходные аргументы и при указании параллельной композиции переменные и прочие параметры можно распределить между процессами явно -- второстепенно в данном случае).

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 24 Май, 2018 20:27 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 157
Для явного ожидания событий используется оператор аля "await", с переключением контекста исполнения со стороны диспетчера:
Код:
type SomeObj1 = active object
public
    input  x: int;
    output y;
begin
  loop
    await x;
    emit y := comp(x);
  end;
end;

Оператор "emit" -- "эмиссия" данных, как операция аля yield, которая возвращает данные -- изменяются переменные и выполняется переключение контекста диспетчером (выше оператор "par" ожидание входа и эмиссию выходных данных выполняет неявно). На Р-схеме для однообразия (не используя дополнительных отдельных средств) для оператора emit следом возникает "пауза":
Вложение:
SomeObj1.png
SomeObj1.png [ 1.76 КБ | Просмотров: 66 ]

Для "ожидания" используется двойная дуга с "разорванной" конечной вершиной. У Вельбицкого (в Р-комплексах) такая дуга использовалась в древности до ГОСТ-ов для выражения аля оператор "выбор", "определение" или "pattern matching":
Вложение:
key_edge.png
key_edge.png [ 22.11 КБ | Просмотров: 66 ]

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


Итого, для моделирования возникает потребность, как минимум, в двух операциях "ожидания": вида await (ожидание события) и pause/emit (завершение акта исполнения и ожидание разрешения для дальнейшей работы).


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 24 Май, 2018 20:34 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 157
Владимир Ситников писал(а):
3) С одной стороны вариант yield иконки, мне нравится (начертание -- без понятия, я пока больше про семантику), но остаётся за кадром как отобразить "ждём не более 5 секунд, если не дождались, то план Б".

Общий случай ожидания событий может быть таким (продолжая мотивы моделирования выше):
Код:
...
a1;
par/or([
    { await
        if X > 0 then a2
        elif Y > 0 then a3
        elif timeout(5) then a4; },

    { a5;
      await Timer1;
      a6;}
]);
a7;
...

Вложение:
par_wait.png
par_wait.png [ 7.05 КБ | Просмотров: 66 ]

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

На Р-схеме, если для "await"-дуги не задано условие (нет предиката), то ожидание закончится тогда, когда структура справа станет проходной (как на графах Закревского или в схемах/программах Зюбина) -- нет каких-то явных "циклов ожидания" (если циклы возникают, то они являются явными предметными алгоритмическими, т.е. в алгоритме циклически возникает ожидание). Если в условиях отсутствует конечная "else"-часть, то при не выполнении условий происходит не "зависание" (или exception) алгоритма (как в обычных вычислительных алгоритмах), а возврат управления диспетчеру.

Оператор параллельных действий в примере показан лишь с целью демонстрации возможной гибкости. Подобные конструкции (почти что полувековой давности) не используются сейчас в мэйнстриме. "Высокоуровневые" аналоги в виде операторов аля "select" как в Go для ожидания операций с каналами, как в Ada для выбора входов в "мониторы", операторы приёма сообщений из "почтовых ящиков" в "акторах" или эмуляции подобных "select"-операторов на конструкциях из "лямбд" и т.п., как правило, имеют единую точку входа в ожидание и лишь линейный список альтернатив (а также ограниченные алгоритмические возможности управления вариантами альтернатив или каналами). Выше, к примеру, действие a5 выполнится перед попыткой выяснения состояния таймера 1 (Timer1) и лишь в случае, если первый процесс (с совокупностью вариантов ожидания) неуспешен (остался в ожидании).
Сам оператор await может использоваться и без блоков параллельности. Выделяются две формы.
Первая -- ожидание изменения (возникновения) свойств конкретного объекта (объектов) аля "await Timer1" или "await x > 0 or y > 0".
Вторая форма -- с произвольным гибким условием (на "вопросах" и "выборах", у Зюбина часто "функции-состояния" начинаются с подобных условий).

Система может предоставлять механизмы аля таймаутов (с отчётом времени от начала ожидания, как у Зюбина). Таймаут предусматривает возможность переключение контекста для диспетчера. Возможны и "классические паузы" как в блок-схемах для задержек по времени без переключения контекста, пусть для этого предназначен оператор "delay":
Код:
...
comp1();
delay(2);
comp2();
timeout(5);
comp3();
...

Вложение:
wait_time.png
wait_time.png [ 1.74 КБ | Просмотров: 66 ]

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 24 Май, 2018 20:36 

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

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

А в alg_uvi.png интереснее: что, если посредине одного примитива мы зашли в yield, то можем ли мы начать обработку какого-то другого примитива, если пришло событие подходящее для него? Или мы должны дождаться входа из 1-го примитива? Может потребоваться как один, так и другой вариант. Возможно, нужна какая-то привязка "примитивов-силуэтов" к "потокам выполнения".

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


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

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 157
Владимир Ситников писал(а):
На этом алгоритме изменилась семантика.

1.1) Раньше было: "дождаться пока ДВК и ДВП перейдут в <<Да>>".
В варианте stan_alg2.png получилось: "дождаться пока ДВК перейдёт в <<Да>>; дождаться пока ДВП перейдёт в <<Да>>".

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

Тогда, если "реабилитировать" икону-синхронизатор и как "событие", то вырисовывается вариант действовать так, как делал Степан Митькин:
Вложение:
alg_uvi2.png
alg_uvi2.png [ 15.25 КБ | Просмотров: 66 ]

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 24 Май, 2018 20:42 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 157
Вместо силуэта для ожидания можно использовать "параллельные действия" (однако, внутри действий (параллельных "веток") "силуэтов" быть не может, если вдруг, к примеру, необходимо устранить пересечение линий):
Вложение:
process1.png
process1.png [ 44.97 КБ | Просмотров: 66 ]

"Параллельная линия" помечена как "Или" для уточнения семантики (стандартных средств для такого приёма нет). В данном случае две последние "параллельные ветки" могут завершить исполнение блока параллельных действий.
Алгоритм завершается переходом на "процесс 2" (смена "функции-состояния" по Зюбину).


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 24 Май, 2018 20:44 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 157
Иконка "ожидание" как "пауза" -- завершение акта исполнения:
Вложение:
alg_gen2.png
alg_gen2.png [ 21.54 КБ | Просмотров: 66 ]

Таким образом, при таком подходе не нарушается имеющаяся семантика в Дракон-е.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 25 Май, 2018 10:05 

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

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


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 43 ]  На страницу Пред.  1, 2, 3  След.

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


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

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


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

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