Ильченко Эдуард писал(а):
Кстати, «точка слияния» в паре с «точкой расщепления», на мой взгляд звучит лучше чем «точка сбора».
Согласен, только пусть будет "узел"; солидаризируюсь с Рэйлвей Каген, что это всё-таки не "безымянная точка", а нечто содержательно посложнее, и надо это отличать терминологически. Далее пользуюсь такой терминологией.
Ильченко Эдуард писал(а):
Независимые процессы А и В могут выполняться параллельно (А || B), в порядке А -> В или В -> А. Совершенно не важно кто выбирает порядок: транслятор по RAND, программист или "начальник транспортного цеха". Нет задачи попасть в точку сбора в определённое время. Есть задача, чтобы все процессы достигли этой точки. Имя процессу нужно если он будет контролироваться извне. Например, некий менеджер : ) контролирует возведение стен дома, по тайм-ауту ему посылается сообщение, что «стены до сих пор нет» и имя запоротого процесса.
А вот в случае приготовления кофе, ИМХО, имя процессу и не нужно, только картинку перегрузит.
Что касается бизнес-процессов, то выше приведённая конструкция выглядит не плохо.
Чего не скажешь в случае программирования, как такового. В программе порядок действий должен быть задан однозначно. Следовательно, нужно определить порядок запуска процессов. Например слева на право. Тогда вся конструкция вырождается в линейный алгоритм. Зато появляется возможность визульно представить 1-D конструкцию алгоритма как 2-D. Хорошо ли это, не знаю : )
Порядок запуска процессов д.б. таким, как нужно для достижения цели. По поводу контроля извне: сейчас даже в функциональном моделировании бизнес-процессов (IDEF0) пришли к тому, что среди боксов верхнего уровня иерархии д.б. управляющий, чтобы система была кибернетической, т.е. целенаправленной (см., кажется, в книге Дубейковского, предшествующей той, из которой давал выдержку, или в работе: Костров А.В. и др. Уроки информационного менеджмента. – М.:Финансы и статистика, 2005.). Поэтому "менеджер" теперь есть всегда
И надо учитывать это и в более низкоуровневых моделях, вплоть до программ (и вообще командных моделей деятельнсти).
Попробую предметно обсудить в этом аспекте свойства предложения по расширению техноязыка, сформулированного, как я понимаю, независимо также dvuugl. Прошу простить за многословие вместо картинок, но сам же согласился с тем, что формализация начинается с текста, т.е. чтобы начертить что-то, это сначала надо проговорить:). Конкретно для модели dvuugl зададимся следующими вопросами:
1) Можно ли вводить такое расширение? Да, и даже необходимо, и не только в целях наглядности, но и чтобы отразить реально возможное многообразие путей (маршрутов) решения задачи.
2) Является ли данная модель дракон-схемой (визуализацией некоторого алгоритма)? Нет, не является, и именно в силу того, что мы решили показать на ней многообразие маршрутов. В результате процесс выполнения этой схемы перестаёт быть алгоритмическим (невозможно указать единственную цепочку шагов от начала к концу даже при определённых и корректных значениях всех входных данных).
3) Можно ли свести данную модель к информатической (алгопроцессу или системе алгопроцессов) с сохранением смысла, вложенного её сочинителем (научно говоря, "семантики")? Думаю, да, можно. Например, средствами классического техноязыка я бы воспользовался так. Полагаю модель dvuugl частным случаем модели с узлами-перекрёстками, причём тип узла сбора неявно устанавливается по типу предшествующего узла расщепления; также все узлы асинхронные и имеют тип "И" (строго говоря, при единственном типе узлов неважно, явно или неявно устанавливается тип - всё равно других в модели быть не может; это важно, если мы захотим расширить язык модели). Тогда данную модель можно преобразовать следующим образом:
1. Выносим каждый маршрут (шампур-блок) между узлами в отдельный визуал, которому даём имя (т.е. делаем своего рода групповую подстановку); при этом вынесенные визуалы понимаются не как вставки, а как параллельные процессы-потомки, отсюда и дальнейшие рассуждения. Можно определить формальные параметры (если считать, что в сообщении на запуск визуала, передаваемом иконой И20, они м.б. перечислены также, как в иконе Вставка).
2. На место узла расщепления ставим икону И20, инициирующую все вынесенные визуалы. В конце каждого из этих визуалов ставим икону И20, посылающую сообщение о завершении этого алгоритма визуалу-родителю (м.б. передан конкретный результат исполнения потомка).
3. От иконы И20 к узлу слияния прокладываем звено вертикали; его содержанием считаем цикл ЖДАТЬ, в котором проверяем получение сообщений о завершении от каждого потомка (т.к. у нас сбор "И", то условием выхода из цикла будет наличие сообщений ото всех потомков).
Такую систему алгоритмов уже можно исполнять (неважно, параллельно, или квазипараллельно).
Попробую конкретизировать сказанное ранее. Информатическая модель, как только её дополнить возможностями, при которых теряется свойство развёртываемости при каждом исполнении по единственному маршруту, перестаёт быть информатической и возвращается на математический уровень формализации (а то и на качественный, если не обеспечивается даже математическая строгость); как следствие, надо найти средства и условия обратного перехода от такой модели к информатической. Это касается и IDEF3-подобных моделей деятельности. Считаю их более общим случаем и попробую предложить метод сведения таких моделей к алгоритмическим.
Про диспетчеризацию было упомянуто не зря. Основная идея алгоритмизации модели с узлами расщепления/сбора процессов (буду называть её схемой поведения, исходя из смысла, приданного в IDEF3) следующая. Некий надалгоритм (системный процесс) в цикле ЖДАТЬ (задающем шаг отслеживания) регулярно проверяет состояние совокупности активных (выполняемых на данном шаге) процессов из числа входящих в схему поведения, на соответствие совокупности условий, определённых узлами этой схемы (понятно, что можно ограничиться узлами, которым предшествуют активные процессы, если устанавливать/сбрасывать и проверять атрибут активнсти). Когда выполнено условие для некоторого узла (совокупности узлов), результатом является запуск процесса (совокупности процессов) посылкой определённых сообщений (представляемой посредством икон И20).
Для асинхронного режима дополнительно определяются возможные (потенциально учитываемые при алгоритмизации поведения) условия неодновременного начала (т.е. допустимого "откладывания" запуска) тех или иных процессов из числа инициируемых асинхронным узлом расщепления (конечно, если тип узла не "Исключающее ИЛИ"; это особый случай, и как видно из сравнения определений узлов у Дубейковского и Черемных, при информатизации схем поведения в среде AllFPM даже "потеряно" выделение синхронности/асинхронности для этого типа узлов; наверное, не случайно:) ) и равно возможные условия неодновременного завершения процессов из числа инициируемых асинхронным узлом сбора (т.е. допустимого раннего окончания некоторых процессов). Эти условия, очевидно, м.б. по времени (учитывая: возможные в реальности разбросы моментов; необходимые интервалы между началами/завершениями конкретных процессов, определяемые "физикой" моделируемой системы; и т.д.), по доступности исполнителей процессов (квантов времени исполнителя), по чему-либо ещё. Иначе говоря, смысл узла расщепления/сбора, определяемый явно (через содержание подключённого узла-референта) или неявно, м.б. не любым, а только таким, который можно превратить в алгоритмический процесс (описать который, как и основные процессы, конечно, оптимально на техноязыке).
Фактически предлагается для каждой модели поведения процессов (представляемой как схема поведения) строить надалгоритм диспетчеризации (и конечно перестраивать его вслед за корректировкой схемы); модель должна охватывать систему целиком. Очевидно, для автоматизации работы по алгоритмизации моделей поведения нужна либо среда гибридного моделирования, для которой язык схем поведения является входным так же, как и ДРАКОН, и которая строит надалгоритм по схеме поведения, либо для дракон-среды (поддерживающей только техноязык - гибридизированный с прогязыками или нет, понятно, здесь роли не играет) - отработанные методики формирования такого надалгоритма для произвольной схемы поведения (ну и поддерживающие их заготовки-образцы фрагментов надалгоритма).
Возможны, наверное, и другие пути сквозной формализации отношений между процессами. Так, можно, наверное, перенести на общие модели поведения принцип, показанный на частной модели dvuugl: не формировать отдельный процесс управления поведением, а распределить его функции по смежным процессам. Кроме того, как уже указывалось где-то на форуме, иконы И20 реализуют метод рандеву, а возможен ещё по крайней мере метод семафоров.