Ну, пока что я не увидел, как на драконе рисуется прерывание процесса по событию в произвольном месте с возвратом в процесс после завершения прерывания. Ну или полное прерывание по другому событию.
IMHO, дракон застыл в развитии сразу после своего создания 30 лет назад, на уровне однопоточных синхронных программ и программно-управляемого ввода-вывода. За прошедшее время в нём так и не появились сигналы, семафоры, прерывания, асинхронные события. Да, единичный процесс дракон описывает (правда, не особо лучше, чем обычная блок-схема), но наглядно показать взаимосвязь связь нескольких процессов он уже не способен.
Золь (также лиозоль, коллоидный раствор, нем. sol от лат. solutio — раствор) — высокодисперсная коллоидная система (коллоидный раствор) с жидкой (лиозоль) или газообразной (аэрозоль) дисперсионной средой, в объёме которой распределена другая (дисперсная) фаза в виде капелек жидкости, пузырьков газа или мелких твёрдых частиц, размер которых лежит в пределе от 1 до 100 нм (10⁻⁹—10⁻⁷м).
Вот только когда я рисую схему обмена сигналами (третья и четвёртая схемы у меня), я просто определяю акторы и сигналы, которыми они обмениваются, но не указываю, в какой последовательности эти сигналы располагаются. Мне это неважно, могу их расположить произвольно. Дракон не может не указывать порядок выполнения. Причём тут схема простая, всего два актора, Если их на схеме будет с десяток, то цветовая дифференциация икон даст такую пестроту, что со схемой будет невозможно работать. А чтобы определить все сигналы, получаемыен неким актором, вам придётся либо делать двухцветные иконы, либо просматривать надписи на всех иконах отправки сообщений. Ну и ещё, как же быть с заявленной вами декомпозицией? Где тут икона "Вызов", которая обменивается сигналами и которую я могу открыть, чтобы определить, как именно она получает и отправляет сигналы?
Ну так как указать на схеме в свёрнутом блоке (икона "Вызов"?), что он может прерываться по какому-то сигналу? Что когда начальник сказал "Стоп" поиск должен прерваться. Вы же во время поиска не проверяете каждую секунду, не позвонил ли вам начальник. Вам просто приходит звонок, вы приостанавливаете работу в любом месте, отвечаете на звонок и либо продолжаете работу с того места на котором остановились, либо прекращаете её. Скажем, мы расписали подробно схему поиска информации и она теперь содержит полсотни подзадач. Должна ли проверка условий остановки добавляться после каждой подзадачи? Но если звонок поступил в середине выполнения подзадачи? Что-то я не нашёл в драконе простого способа обозначения таких прерываний и их влияния на основную задачу.
Как именно прерывается блок "поиск в интернет" при поступлении сообщения об остановке поиска и откуда видно, что он вообще может прерываться до окончания поиска?
поясните подробнее механизм процесса
Простой пример. Клиент выдаёт некие требования оператору. Оператор предлагает клиенту варианты решения проблемы. Клиент выбирает вариант или отклоняет все варианты и выдвигает дополнительные требования. Если клиент выбрал вариант, то оператор размещает заявку, иначе подбирает варианты с учётом новых требований и процесс повторяется. При этом процесс асинхронный и управляется событиями (пунктирная рамка вокруг подзадачи). Поступление новых требований перезапускает подбор вариантов, отказ клиента от заявки прерывает подбор вариантов. Теперь я готовлю задание для разработчика оператора. Ему неважно, что именно происходит у клиента, поэтому мы сворачиваем пул клиента в линию и оставляем только сообщения. Я хочу сделать эту схему частью большой схемы. Сворачиваю задачи, оставляя только обмен. Готовлю задание для проектирования API - вообще оставляю только линии и сообщения, чтобы празработчик видел, кто и какие сообщения передаёт. Если для первых двух случаев я ещё могу представить схему на драконе, правда не знаю, как именно там нарисовать асинхронные события, то два послдних, IMHO, на драконе не изобразить без потери информации.
можно брать астероиды поменьше и сдергивая их с орбиты лупить в тот что побольше
Для этого нужно ещё больше энергии, чем для двигателей непосредственно на астероиде. Потери при соударении будут большими - астероиды не упругие тела, часть энергии уйдёт на разрушение астероида.
У каждого подпроцесса в пуле подрядчиков есть комментарии. Один из них, например, - "Подпроцесс по каждому плечу маршрута перевозки для каждой заявки".
не описывает когда стоит остановится
Не описывает. Осталось за кадром. Хотя ничто не мешает добавить в схему ещё подпроцессы. Например, когда начальник решает, что хватит искать, и даёт команду остановить поиск или когда по наступлению определённого события (скажем, таймера) такая команда генерируется автоматически.
В целом же ваша схема не соответствует оригиналу. Поскольку у вас синхронное выполнение, то до проверки на остановку (Информация найдена?) каждый сотрудник дойдёт только после завершения (успешного или нет) своего поиска, в то время, как он должен прервать и выполнение поиска (асинхронно) и дальнейшее движение по схеме.
P.S. Кстати, помниться вы утверждали, что схемы на драконе легко декомпозируются. Как на нём показать, что во время выполнения свёрнутой задачи (икона "Вызов", если не ошибаюсь) идёт обмен со свёрнутой задачей из другого пула или с хранилищем?
И получаем проблему хранения этих секретов. Только теперь мы добавили ещё одну глобальную зависимость и при падении Vault мы теряем доступ к остальным сервисам.
Я не могу сказать, что моя схема полностью корректна. Она набросана была на скорую руку, по аналогии с одной из картинок в поиске. И уж тем более я не могу сказать, что именно дракон позволил вам выявить ошибки. Учитывая, что большинство подпроцессов на схеме свёрнуты (плюсик снизу), какие-то вещи могут быть скрыты в реализации этих подпроцессов. Однако, ваша схема неверна в принципе, поскольку не показывает параллельного выполнения процессов и не учитывает, что перевозка может выполняться несколькими плечами, на каждом из которых есть свой подрядчик. Ну и часть с оплатой вы пропустили.
В общем, видно, что дракон неплохо описывает однопоточные замкнутые процессы, но не справляется с многопоточными, а тем более с несколькими взаимосвязанными, но параллельными процессами. Тут уже нужен не дракон, а лернейская гидра, ну или, хотя бы, трёхголовый змей горыныч.
Попробуйте, например, нарисовать такую схему: Руководитель отправляет трёх сотрудников на поиск нужной информации. Один ищет в интернете, второй в литературе, третий в архивах организации. Как только один из них находит нужное, все поиски прекращаются. Подпроцесс поиска у каждого, естественно, свой.
bpmn
P.S. Кстати, наглядность схемы на драконе довольно низкая. Попробуйте, например, быстро найти на ней те места, где идёт взаимодействие с клиентом.
при построении схемы заставляет явно прописывать все варианты развития событий
Но у вас не прописаны все варианты. Покажите, как у вас работает следующая ситуация: Оператор одновременно направил заявки на бронирование трём подрядчикам. Два из них подтвердили бронирование, один отклонил. Оператор направил заявку ещё одному подрядчику, тот её подтвердил.
Затем, у каждого подрядчика свой процесс перевозки груза, при этом он отправляет сообщения оператору, а тот передаёт информацию о прохождении груза клиенту. Но это параллельные процессы. Оператор может, например, накапливать информацию от подрядчиков в течение некоторого периода и отправлять её клиенту разом. Блок "Управление и контроль перевозки" свёрнут и что происходит внутри на этой схеме не видно. Там , в свою очередь, может быть несколько подпроцессов, каждый со своей точкой старта и завершения. Как в драконе показать, что это именно параллельные независимые процессы, обменивающиеся сообщениями?
Иконки с конвертами - это не письма, а сообщения. Они могут быть в абсолютно любом формате, хоть устные между людьми, хоть по шине между потоками программы, хоть по сети между компьютерами. Иконка с пустым конвертом - ожидание входящего сообщения, иконка с закрашенным конвертом - отправка исходящего сообщения сообщение. Все потоки управления, начинающиеся с зелёных иконок, выполняются независимо друг от друга и обмениваются сообщениями. Например, блоки "Контроль перевозки" в пуле клиентов, "Управление и контроль перевозки" в пуле логистического оператора и "Погрузка, перевозка, разгрузка" в пуле подрядчиков должны выполняться параллельно. При этом оператор получает сообщения от подрядчика и, в свою очередь отправляет сообщения клиенту. К тому же, блок "Погрузка, перевозка, разгрузка" выполняется для каждого участка перевозки (значок цикла снизу блока). Плюсики внизу блоков означают, что это подпроцессы, каждый может раскрываться в отдельную схему. Несколько блоков "Получение оплаты за услуги" и "Расчёт с подрядчиками" могут выполняться одновременно и параллельно. Это показано значком из трёх вертикальных полосок.
У вас на схеме нет ни параллельности независимых процессов, ни многократности.
Предполагается, что найдётся хотя бы одна цепочка подрядчиков, которая может доставить груз. Отдел логистики получает ответы от всех подрядчиков, которым отправлял заявки, и строит маршрут. Но, в принципе, ничто не мешает добавить точку выхода при невозможности построения маршрута.
Видите плюсики в ромбиках? Они означают, что в этих точках либо один входящий поток управления делится на несколько параллельных, либо ожидается приход всех входящих потоков для продолжения. Крестики - либо условие, если один входящий, либо соединениие, если один исходящий. Вот несколько сложнее, хотя и более линейный процесс:
Если для вас потери информации нет, то скажите только по своей схеме, на каких этапах может идти общение с клиентом? Требуется ли выполнение обоих пунктов 8 и 9 для перехода к пункту 10? Если да, то почему менеджер должен ждать обе ветви, чтобы начать корректировку договора? Если не требуется, то где происходит синхронизация ветвей? Если этот процесс является подпроцессом, то как узнать статус его завершения в родительском процессе?
Я не большой специалист в BPMN, но вот простейшая схема. Попробуйте переделать её на дракон не потеряв информацию о действующих лицах и их взаимосвязях.
Всё верно. Первые поколения. Если из замкнутой системы (не столько биологической, сколько социальной), которая должна сформироваться в эксперименте, резко изъять поколение пенсионеров, то нарушится баланс. Так что пенсионеры стартуют вместе со всеми и умирают уже на борту корабля.
Ну так собственно и полетят их дети и внуки, уже привыкшие к жизни в изолированном самообеспечивающемся пространстве. Другое дело, как будет смотреться жизнь этих людей со стороны всего человечества. Как подготовка будущих героических покорителей космоса или просто как бесчеловечный эксперимент над детьми?
Идея ДРАКОНа как раз в том, что, в отличие от громоздких BPMN-простыней, он построен на принципе декомпозиции.
Но никто не мешает декомпозировать BPMN-схему. В ней даже есть специальный блок "свёрнутый подпроцесс". Кроме того, BPMN, как специализированная нотация (заметьте, никто не называет её языком), предназначен именно для бизнес-процессов. Многие вещи, которые легко рисуются в BPMN невозможно изобразить в драконе. Попробуйте, например, на драконе показать разделение процесса на три параллельно выполняющихся ветви с их дальнейшим слиянием, при этом какие-то этапы на этих ветвях должны обмениваться информацией с другими ветвями и/или общим хранилищем как вв однонапраленном, так и в двунаправленном вариантах. Ну и плюс BPMN, что, в отличие от дракона, для неё есть стандартизованное XML-представление. То есть, схема созданная в одном редакторе без проблем переносится в другой редактор. Для дракона такого нет и два редактора могут оказаться просто несовместимыми по формату хранения.
Diff нужен, в первую очередь, не для того, чтобы показать факт изменения, а для показа точных мест изменения кода/текста. А Git прзволяет не просто версионировать файлы, но и разбивать разработку на отдельные ветки, в каждой из которых идёт модификация своей части кода, и сливать эти ветки в основной поток, суммируя всю разработку.
у меня возникает ощущение, что мы мысленно застряли в прошлом веке
Увы, но далеко не везде есть переговорки, проекторы, плоттеры A0. Вполне хватает небольших компаний, которые размещаются в двух-трёх кабинетах, с одним 24-дюймовым монитором у каждого сотрудника. Держать отдельную комнату, которая будет использоваться три раза в год или струйный плоттер, на котором надо печатать регулярно, чтобы не засохла головка, довольно накладно.
Ну, пока что я не увидел, как на драконе рисуется прерывание процесса по событию в произвольном месте с возвратом в процесс после завершения прерывания. Ну или полное прерывание по другому событию.
IMHO, дракон застыл в развитии сразу после своего создания 30 лет назад, на уровне однопоточных синхронных программ и программно-управляемого ввода-вывода. За прошедшее время в нём так и не появились сигналы, семафоры, прерывания, асинхронные события. Да, единичный процесс дракон описывает (правда, не особо лучше, чем обычная блок-схема), но наглядно показать взаимосвязь связь нескольких процессов он уже не способен.
Ну, та же википедия говорит
Размер снежинок явно больше 100 нанометров.
Вот только когда я рисую схему обмена сигналами (третья и четвёртая схемы у меня), я просто определяю акторы и сигналы, которыми они обмениваются, но не указываю, в какой последовательности эти сигналы располагаются. Мне это неважно, могу их расположить произвольно. Дракон не может не указывать порядок выполнения.
Причём тут схема простая, всего два актора, Если их на схеме будет с десяток, то цветовая дифференциация икон даст такую пестроту, что со схемой будет невозможно работать. А чтобы определить все сигналы, получаемыен неким актором, вам придётся либо делать двухцветные иконы, либо просматривать надписи на всех иконах отправки сообщений.
Ну и ещё, как же быть с заявленной вами декомпозицией? Где тут икона "Вызов", которая обменивается сигналами и которую я могу открыть, чтобы определить, как именно она получает и отправляет сигналы?
Ну так как указать на схеме в свёрнутом блоке (икона "Вызов"?), что он может прерываться по какому-то сигналу? Что когда начальник сказал "Стоп" поиск должен прерваться. Вы же во время поиска не проверяете каждую секунду, не позвонил ли вам начальник. Вам просто приходит звонок, вы приостанавливаете работу в любом месте, отвечаете на звонок и либо продолжаете работу с того места на котором остановились, либо прекращаете её.
Скажем, мы расписали подробно схему поиска информации и она теперь содержит полсотни подзадач. Должна ли проверка условий остановки добавляться после каждой подзадачи? Но если звонок поступил в середине выполнения подзадачи? Что-то я не нашёл в драконе простого способа обозначения таких прерываний и их влияния на основную задачу.
Как именно прерывается блок "поиск в интернет" при поступлении сообщения об остановке поиска и откуда видно, что он вообще может прерываться до окончания поиска?
Простой пример. Клиент выдаёт некие требования оператору. Оператор предлагает клиенту варианты решения проблемы. Клиент выбирает вариант или отклоняет все варианты и выдвигает дополнительные требования. Если клиент выбрал вариант, то оператор размещает заявку, иначе подбирает варианты с учётом новых требований и процесс повторяется. При этом процесс асинхронный и управляется событиями (пунктирная рамка вокруг подзадачи). Поступление новых требований перезапускает подбор вариантов, отказ клиента от заявки прерывает подбор вариантов.
Теперь я готовлю задание для разработчика оператора. Ему неважно, что именно происходит у клиента, поэтому мы сворачиваем пул клиента в линию и оставляем только сообщения.
Я хочу сделать эту схему частью большой схемы. Сворачиваю задачи, оставляя только обмен.
Готовлю задание для проектирования API - вообще оставляю только линии и сообщения, чтобы празработчик видел, кто и какие сообщения передаёт.
Если для первых двух случаев я ещё могу представить схему на драконе, правда не знаю, как именно там нарисовать асинхронные события, то два послдних, IMHO, на драконе не изобразить без потери информации.
BPMN
Для этого нужно ещё больше энергии, чем для двигателей непосредственно на астероиде. Потери при соударении будут большими - астероиды не упругие тела, часть энергии уйдёт на разрушение астероида.
У каждого подпроцесса в пуле подрядчиков есть комментарии. Один из них, например, - "Подпроцесс по каждому плечу маршрута перевозки для каждой заявки".
Не описывает. Осталось за кадром. Хотя ничто не мешает добавить в схему ещё подпроцессы. Например, когда начальник решает, что хватит искать, и даёт команду остановить поиск или когда по наступлению определённого события (скажем, таймера) такая команда генерируется автоматически.
В целом же ваша схема не соответствует оригиналу. Поскольку у вас синхронное выполнение, то до проверки на остановку (Информация найдена?) каждый сотрудник дойдёт только после завершения (успешного или нет) своего поиска, в то время, как он должен прервать и выполнение поиска (асинхронно) и дальнейшее движение по схеме.
P.S. Кстати, помниться вы утверждали, что схемы на драконе легко декомпозируются. Как на нём показать, что во время выполнения свёрнутой задачи (икона "Вызов", если не ошибаюсь) идёт обмен со свёрнутой задачей из другого пула или с хранилищем?
И получаем проблему хранения этих секретов. Только теперь мы добавили ещё одну глобальную зависимость и при падении Vault мы теряем доступ к остальным сервисам.
Я не могу сказать, что моя схема полностью корректна. Она набросана была на скорую руку, по аналогии с одной из картинок в поиске. И уж тем более я не могу сказать, что именно дракон позволил вам выявить ошибки.
Учитывая, что большинство подпроцессов на схеме свёрнуты (плюсик снизу), какие-то вещи могут быть скрыты в реализации этих подпроцессов.
Однако, ваша схема неверна в принципе, поскольку не показывает параллельного выполнения процессов и не учитывает, что перевозка может выполняться несколькими плечами, на каждом из которых есть свой подрядчик. Ну и часть с оплатой вы пропустили.
В общем, видно, что дракон неплохо описывает однопоточные замкнутые процессы, но не справляется с многопоточными, а тем более с несколькими взаимосвязанными, но параллельными процессами. Тут уже нужен не дракон, а лернейская гидра, ну или, хотя бы, трёхголовый змей горыныч.
Попробуйте, например, нарисовать такую схему: Руководитель отправляет трёх сотрудников на поиск нужной информации. Один ищет в интернете, второй в литературе, третий в архивах организации. Как только один из них находит нужное, все поиски прекращаются. Подпроцесс поиска у каждого, естественно, свой.
bpmn
P.S. Кстати, наглядность схемы на драконе довольно низкая. Попробуйте, например, быстро найти на ней те места, где идёт взаимодействие с клиентом.
Но у вас не прописаны все варианты. Покажите, как у вас работает следующая ситуация:
Оператор одновременно направил заявки на бронирование трём подрядчикам. Два из них подтвердили бронирование, один отклонил. Оператор направил заявку ещё одному подрядчику, тот её подтвердил.
Затем, у каждого подрядчика свой процесс перевозки груза, при этом он отправляет сообщения оператору, а тот передаёт информацию о прохождении груза клиенту. Но это параллельные процессы. Оператор может, например, накапливать информацию от подрядчиков в течение некоторого периода и отправлять её клиенту разом. Блок "Управление и контроль перевозки" свёрнут и что происходит внутри на этой схеме не видно. Там , в свою очередь, может быть несколько подпроцессов, каждый со своей точкой старта и завершения. Как в драконе показать, что это именно параллельные независимые процессы, обменивающиеся сообщениями?
Иконки с конвертами - это не письма, а сообщения. Они могут быть в абсолютно любом формате, хоть устные между людьми, хоть по шине между потоками программы, хоть по сети между компьютерами.
Иконка с пустым конвертом - ожидание входящего сообщения, иконка с закрашенным конвертом - отправка исходящего сообщения сообщение.
Все потоки управления, начинающиеся с зелёных иконок, выполняются независимо друг от друга и обмениваются сообщениями.
Например, блоки "Контроль перевозки" в пуле клиентов, "Управление и контроль перевозки" в пуле логистического оператора и "Погрузка, перевозка, разгрузка" в пуле подрядчиков должны выполняться параллельно. При этом оператор получает сообщения от подрядчика и, в свою очередь отправляет сообщения клиенту. К тому же, блок "Погрузка, перевозка, разгрузка" выполняется для каждого участка перевозки (значок цикла снизу блока).
Плюсики внизу блоков означают, что это подпроцессы, каждый может раскрываться в отдельную схему.
Несколько блоков "Получение оплаты за услуги" и "Расчёт с подрядчиками" могут выполняться одновременно и параллельно. Это показано значком из трёх вертикальных полосок.
У вас на схеме нет ни параллельности независимых процессов, ни многократности.
Предполагается, что найдётся хотя бы одна цепочка подрядчиков, которая может доставить груз. Отдел логистики получает ответы от всех подрядчиков, которым отправлял заявки, и строит маршрут.
Но, в принципе, ничто не мешает добавить точку выхода при невозможности построения маршрута.
Видите плюсики в ромбиках? Они означают, что в этих точках либо один входящий поток управления делится на несколько параллельных, либо ожидается приход всех входящих потоков для продолжения.
Крестики - либо условие, если один входящий, либо соединениие, если один исходящий.
Вот несколько сложнее, хотя и более линейный процесс:
Hidden text
Если для вас потери информации нет, то скажите только по своей схеме, на каких этапах может идти общение с клиентом?
Требуется ли выполнение обоих пунктов 8 и 9 для перехода к пункту 10? Если да, то почему менеджер должен ждать обе ветви, чтобы начать корректировку договора? Если не требуется, то где происходит синхронизация ветвей?
Если этот процесс является подпроцессом, то как узнать статус его завершения в родительском процессе?
Потеряна информация об обмене данными с клиентом.
Нет информации, что корректировкой занимается менеджер, согласуя корректировку с клиентом.
Я не большой специалист в BPMN, но вот простейшая схема. Попробуйте переделать её на дракон не потеряв информацию о действующих лицах и их взаимосвязях.
Всё верно. Первые поколения. Если из замкнутой системы (не столько биологической, сколько социальной), которая должна сформироваться в эксперименте, резко изъять поколение пенсионеров, то нарушится баланс. Так что пенсионеры стартуют вместе со всеми и умирают уже на борту корабля.
Ну так собственно и полетят их дети и внуки, уже привыкшие к жизни в изолированном самообеспечивающемся пространстве. Другое дело, как будет смотреться жизнь этих людей со стороны всего человечества. Как подготовка будущих героических покорителей космоса или просто как бесчеловечный эксперимент над детьми?
Но никто не мешает декомпозировать BPMN-схему. В ней даже есть специальный блок "свёрнутый подпроцесс".
Кроме того, BPMN, как специализированная нотация (заметьте, никто не называет её языком), предназначен именно для бизнес-процессов. Многие вещи, которые легко рисуются в BPMN невозможно изобразить в драконе. Попробуйте, например, на драконе показать разделение процесса на три параллельно выполняющихся ветви с их дальнейшим слиянием, при этом какие-то этапы на этих ветвях должны обмениваться информацией с другими ветвями и/или общим хранилищем как вв однонапраленном, так и в двунаправленном вариантах.
Ну и плюс BPMN, что, в отличие от дракона, для неё есть стандартизованное XML-представление. То есть, схема созданная в одном редакторе без проблем переносится в другой редактор. Для дракона такого нет и два редактора могут оказаться просто несовместимыми по формату хранения.
Diff нужен, в первую очередь, не для того, чтобы показать факт изменения, а для показа точных мест изменения кода/текста. А Git прзволяет не просто версионировать файлы, но и разбивать разработку на отдельные ветки, в каждой из которых идёт модификация своей части кода, и сливать эти ветки в основной поток, суммируя всю разработку.
Увы, но далеко не везде есть переговорки, проекторы, плоттеры A0. Вполне хватает небольших компаний, которые размещаются в двух-трёх кабинетах, с одним 24-дюймовым монитором у каждого сотрудника. Держать отдельную комнату, которая будет использоваться три раза в год или струйный плоттер, на котором надо печатать регулярно, чтобы не засохла головка, довольно накладно.