Схемотехника типовых маршрутов

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

Оказывается, есть:

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

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

Вот так, с применением навыков элементарной схемотехники, решается эта задача.

P.S. В принципе, блок 6 не особо нужен, можно было бы вывести из блока 4 две стрелки "Иначе", одну в блок 5, другую в блок 7. В этом случае схема выглядела бы более изящно. Но и приведенный вариант вполне допустим. Блоки-агрегаторы достаточно часто используются разработчиками не для соединения потоков, но для их разделения, т.к. в определенных случаях это облечает чтение схемы человеком.