Ильченко Эдуард писал(а):
Где прописать имя процесса?
Как преобразовать в силуэт?
Предлагаю варианты икон для узлов расщепления (верхняя) и сбора (нижняя):
Вложение:
СхПовед - Узлы.JPG [ 36.13 КБ | Просмотров: 14862 ]
Расщепление содержит текст базового смысла данного оператора, представленного для определённости на манер строевой команды:) При этом вводится поле параметров для каждого шампура; в базовом смысле оно может содержать набор формальных параметров выполняемого на нём процесса (при алгоритмизации оформляется иконой И11). Расширенный смысл определяет условия прохода, т.е. старта процессов, и дополнительные параметры, могущие входить в эти условия. Так, можно указать норму времени на исполнение шампура; для асинхронного расщепления задать предел (интервал) позднего старта данного шампура, выдержки времени относительно реальных моментов старта других шампуров. Можно указывать относительную важность маршрутов, что будет влиять на порядок назначения им исполнителей из ограниченного множества по мере освобождения от других работ (в частности, чтобы важные процессы не стартовали слишком поздно). Сам старт визуализируется, как обычно в ДРАКОН-2, посылкой сообщения процессу в иконе И20.
Для сбора базовый смысл сформулирован аналогично. В полях параметра указывается, какого доклада (в смысле состава величин и их значений) сочинитель ожидает от процессов шампура. Расширенный смысл определяет условия прохода узла; отсутствием условий можно указывать, что требуется лишь завершение процесса на данном шампуре. По времени для асинхронного сбора содержит также интервал раннего финиша; при этом ноль может указывать эталонный в этом смысле шампур (от реального момента финиша по которому отсчитываются финиши остальных). Можно указать относительную важность докладываемых результатов по шампурам, а также ставить учёт результатов, получаемых по исполнении одних шампуров, в зависимость от наличия и/или значений результатов исполнения других. Из этого вытекает возможность игнорировать незавершённость исполнения одних шампуров, подходящих к узлу, если завершено с тем или иным результатом исполнение других по принципу: "вообще-то для сбора нужно сделать и Это, и То, и Сё, но если сделано хотя бы То и Сё, то Это пока может подождать"; тогда сочинитель предусматривает контроль игнорированных результатов где-то в последующих узлах сбора по схеме (возможно, не в одном месте). Контроль исполнения в этом случае является пассивным: узел сбора ждёт доклада процессов (в виде сообщений И20, входящих в их визуалы, как предлагал Рэйлвей Каген в модели "построить дом"). Однако возможен и активный контроль, что характерно для процессов организованной деятельности: узел, не дождавшись доклада по шампуру, начинает посылать напоминания в иконе И20 отстающему процессу этого шампура; целесообразно, когда сочинитель предполагает, что без доклада узел пройден не будет (подобную ситуацию довелось визуализировать при описании реальной деятельности). Другая типичная ситуация - слишком раннее завершение шампура; в этом случае можно подразумевать вопрос "почему так рано?" и предусмотреть в узле углублённый контроль результатов.
Алгоритмически базовый смысл узла раскрывается через иконы И20. Принцип их распределения по вмзуалам процессов показал Рэйлвей Каген.
Условия прохода м.б. любыми функциональными (типа: "если [НЕ] Это, тогда [НЕ] То ИЛИ [НЕ] Сё"; "И [НЕ] То, И [НЕ] Это"; "лучше/хуже/так же, как/иначе, чем <сущность-образец>"; "имеющий <признаки>"; и т.п.), временнЫми ("[НЕ] раньше/позже, чем [через <интервал> после] <событие>"; "тогда-то по такому-то времени"; "одновременно с <событие>"; "в течение такого-то времени"; "быстрее/медленнее/в том же темпе в сравнении с <процесс-эталон>"; и т.п.), пространственными ("левее/правее/выше/ниже/ближе/дальше, чем <реперный объект/точка> на <смещения по координатам>"; "там-то"; "со <стороны> от <реперный объект/точка>"; "там же, где и <реперный объект/точка>"; "длиннее/короче/крупнее/мельче, чем <объект-эталон>"; "на [расстоянии <величина> по] пути <имя> из <> в <>"; "вплотную/с зазором <размер> к <базовая точка/линия/поверхность>"; "с поворотом оси на <угол>" относительно <реперной оси>; и т.п.). При этом видим, что выделяются условия единичные - для одного маршрута и множественные - увязывающие разные маршруты. Первые указываются в полях иконы, зрительно связанных с соответствующими линиями, вторые - в общем поле. Обычно записываются как логические формулы (объединяющие в сложное условие); их надо визуализировать как нелинейные конструкции. Единичные условия при алгоритмизации, наверное, нужно включать в свои процессы (по их выполнении запускаются следующие процессы), как оформлять множественные условия - надо подумать.
Т.к. иконы узлов растянуты на нужную ширину, то ломаные линии присоединения шампуров отсутствуют. Не нужны дополнительные маркеры. Считал бы эргономичным пометку синхронных узлов дополнительной линией контура (подобно перекрёсткам), чтобы читатель сразу понимал, что процессы по всем шампурам стартуют (финишируют) одновременно (точнее, с разбросом меньше шага отслеживания) и не надо искать временнЫх условий, определяющих старт (финиш).
С использованием этих икон перерисовал схему Ильченко:
Вложение:
СхПовед Напоить себя.JPG [ 111.18 КБ | Просмотров: 14862 ]
Все узлы здесь считаю синхронными. Условия, конечно, придумывал навскидку. Параметры отдельно не задавал (предполагая наличие только тех, что использованы в условиях). Также привёл топологию переключателя к нормальной для техноязыка (побочные вертикали вроде как нельзя присоединять к главной вертикали в разных точках).
Важной представляется идея Ильченко о выделении главного маршрута для процесса управления расщеплением/сбором ("супервизора") в рамках всей схемы. Возможную логику такого процесса я уже предлагал
в этом сообщении (называя его "диспетчером"). Как часть его можно включить и процедуру-"напоминайку" для отстающих процессов, получающую список "отстающих" как формальный параметр; альтернативный вариант - реализовать её как "зацикленный" процесс, только запускаемый в начале схемы и собирающий список "отстающих" по узлам.
Конструкция, ограниченная расщеплением и сбором (равно как и каскадами одновидовых узлов), образует своего рода мультишампур-блок. Шампуры в нём можно упорядочивать по-разному, как и в техноязыке: по значимости, по желаемому времени запуска (если подразумевается асинхронность).
Если допустить динамические маршруты, то можно принять также правило, чтобы не плодить разные типы линий: все маршруты, входящие в мультишампур-блок, динамические.
Точный состав допустимых параметров условий прохода, конечно, оговаривается для конкретного диалекта расширенного таким образом техноязыка.
При переходе к силуэту можно допустить разрыв шампуров мультишампур-блока; в этом случае иконы Имя ветки и Адрес используются в смысле Рэйлвей Каген (но в отношении 1:1) и для указания на это специально помечаются (как у него); их текст служит меткой маршрута (в частном случае может совпадать с именем единственного входящего процесса). Остальные иконы имеют обычный смысл разрешённых БП техноязыка. По умолчанию мультишампур-блок помещается целиком в теле одной ветки. Имя процесса там, где ему положено по правилам техноязыка - в иконе процесса.
Остаётся вопрос с "зацикленными" процессами; они "никогда" не закончатся и при обычной логике узел сбора с их участием не будет пройден. Если такой процесс может входить в мультишампур, то не следует ли допустить запуск его в любом месте схемы, а в мультишампуре - только чтение его текущего состояния (которое может включать и счётчик проходов процесса) и выход по состоянию (в частности - по достижению счётчиком некоторого значения)?
И ещё: допустим, в параллельном прогязыке Оккам есть два рандеву-оператора - один посылает сообщения другому процессу, как И20, а другой принимает сообщения от другого процесса. Вероятно, какой то смысл в этом есть (дело же не в том, что Оккам - текстовый язык
)?
Конечно, и это предложение, подобно КВНу, опять "не решит всех проблем":). Кто может, пусть предлагает лучше, и с возможно более подробными разъяснениями...
P.S. Да, и явное указание объектов шампура в узле расщепления должно, полагаю, автоматически означать их блокировку, т.е. эквивалент команды "[Процессы, ]Разобрали цели!", чтобы не получалось, как с Дарьей Домрачевой
; проход узла сбора означает освобождение объектов собираемых им шампуров. Если какие-то объекты ещё не освобождены процессами, стартовавшими в других расщеплениях (из параллельно выполняемых мультишампур-блоков, отстающими из предыдущих блоков), то старт откладывается (шампур, т.е. поток, "засыпает").
При уточнении смысла узлов надо также подумать о дублировании (размножении) одного маршрута (содержанием которого м.б. и конструкция из мультишампур-блоков) во время выполнения. Также пока неясно с зацикливанием такой схемы (тем более что это вроде как не алгоритм). В общем, многое еще прояснять надо...
P.P.S. Корректируются также узлы для общего случая, изменил определения базового смысла с учётом сказанного выше. Также имена в точечной записи должны означать свойства объектов (не везде соблюдал). Нарисовал схему поведения в форме силуэта, правда, для такой схемы это построение надуманное. Кстати, мои извинения Эдуарду: его переключатель также допустим, просто в нём пересажена лиана "Квас"; а мой вариант имел целью показать употребление каждого напитка
Ещё об "алгоритмической расшифровке" узлов. Узел расщепления в результате выдаёт последовательность сообщений И20 (далее тип сообщения буду указывать через дефис). При этом в его алгоритме вначале описывается (исходя из содержания иконы Узел расщепления) вычисление порядка старта шампуров, формирующее массивы: имён их процессов; количеств порождаемых копий (в частном случае равно единице); интервалов старта текущего шампура относительно предыдущего (для синхронного узла все равны нулю); реальных моментов старта шампуров (по единому времени; вначале все элементы нулевые); наборов параметров (включая формальные, если есть), размножаемых (возможно, с изменениями, также описываемыми изначально в иконе Узел расщепления) по числу копий; индекс массивов есть номер шампура по порядку старта. Далее повторяется по числу исходящих шампуров (следованием, а лучше как тело охватывающего цикла ДЛЯ по номеру шампура) конструкция следования из: цикла ЖДАТЬ, проверяющего доступность "своих" объектов (и исполнителей при ограничении на их доступность); иконы Пауза, берущей интервал старта "своего" шампура; цикла порождения копий, в теле которого идут: конструкция описания "захвата" набора параметров шампура; икона И20-Старт, в которой и имя процесса, и набор формальных параметров есть переменные-компоненты нужных массивов, выбираемые по индексу шампура ("параметризованное" сообщение процессу; вроде техноязыком допускается); икона Действие для записи реального момента старта текущего шампура в "свой" элемент массива (можно заменить её на Пуск таймера и тогда делать вместо паузы цикл порождения по таймеру с параметром (ПерТаймера[ПредШамп]+ИнтСтарта[ТекШамп]; или, если так можно, делать Пуск таймера текущего по ПерТаймера[ПредШамп], сравниваемой по "не меньше" с ИнтСтарта[ТекШамп]). Т.о. у нас заранее (до исполнения) определены "типы" шампуров как алгоритмы их процессов, а временнОй порядок следования типов и число экземпляров каждого типа определяются при исполнении (конечно, на схеме поведения эргономично упорядочить асинхронные шампуры в порядке старта, о чём уже говорилось); это указывается в тексте единичного поля узла расщепления. Если узлы расщепления каскадируются, то на шампуре текущего узла, идущем к следующему узлу расщепления, стартует его визуал (все узлы имеют уникальные имена, назначаемые и их алгоритмам) сразу; неясно, можно ли допускать вставку между ними ещё и целевого процесса - ведь его работу обычно ещё надо контролировать.
В составе алгоритма шампура (сочиняемого, очевидно, вполне независимо от охватывающих узлов) от схемы поведения появляется икона И20-Доклад, где имя адресата есть имя алгоритма "своего" узла сбора, а содержание сообщения - набор "докладываемых" величин процессов шампура. Видимо, если содержание шампура сочинитель представляет как цепочку отдельных процессов, то каждый предшествующий процесс в цепочке перед иконой Конец запускает последующий (также по И20-Запуск). Видится ограничение для этого случая: сочинитель д.б. уверен, что каждый предшествующий процесс нормально завершится, для чего строить все процессы, кроме последнего, логически просто, минимизируя "подводные камни" периода исполнения.
Алгоритм узла сбора в первую очередь также вычисляет параметры своего дальнейшего исполнения, формируя массивы (индексированные также по шампурам, но уже по входящим): нормативных значений наборов параметров для "доклада" от процессов шампура; признаков [не]выполнения единичных условий. Далее в цикле пошампурно анализируются единичные условия, в результате чего устанавливается признак выполнения для данного шампура. Вопрос, что делать, если обнаружено невыполнение: во-первых, полагая его причиной сбой, можно послать И20-Старт процессу (единственному/первому) этого шампура для "пересчёта" (ограничение: если шампур управляет реальными объектами, это м.б. бессмысленно или даже опасно); во-вторых, можно запустить алгоритм аварийного управления (ограничение: если по логике решения задачи это возможно независимо от других шампуров); в-третьих, ничего не делать и перейти к обработке множественных условий узла; наверное, возможны "в-четвёртых" и т.д. (кто-нибудь их будет находить при матанализе и информоделировании схем поведения, в практике визуализации реальных задач). Эту часть сбора, как уже говорилось, наверное можно визуализировать как отдельный процесс, связанный только со "своим" шампуром (через "рандеву" по И20-Доклад; при этом узел расщепления должен давать И20-Старт и этому процессу вместе с первым процессом шампура); тогда, очевидно, можно разнести исполнение для разных шампуров по ресурсам [квази]мультипрограммного исполнителя. Далее переходим к общей части, начинающейся с проверки множественных условий (использующих "доклады" от разных шампуров); для них, очевидно, справедливы те же соображения, что для проверки единичных, и дополнительно в этих условиях учитываются признаки проверки единичных. Следствием выполнения условий д.б. проход всего узла; этот проход алгоритмизуется следованием из: процедур освобождения объектов шампуров узла; иконы И20-Старт для процесса следующего узла расщепления (или следующего шампура, если идёт каскадирование узлов сбора либо достигнута нижняя граница МШБ). В каскаде данная организация узлов сбора принципиально не меняется.
Вернёмся к каскадированию узлов расщепления через шампуры с целевыми процессами. Наверное, в некоторых случаях можно сформулировать это как единичную часть сбора и включить её после целевого процесса; т.о. перед расщеплением имеем "сбор одного шампура". Это надо показывать и на МШ-схеме (добавляя единичный блок сбора сверху иконы расщепления).
Кстати, о проблеме "пустого" шампура между расщеплением и сбором: м.б. заполнять его "докладом" без передаваемых параметров?
Аварийно процесс завершается иконой И20-Финиш.
Вот такие соображения; надо их ещё проверять на корректность и развивать. Прошу критиковать.