Комментарии 5
Такими темпами вы книжку долго копипастить сюда будете. Начали бы с самого интересного - запустить ваш простенький процесс. Это бы хоть теме статьи соответствовало. Тут и возникают нюансы и приходит понимание, что все эти low code/no code нифига не low и, тем более, не no.
Начали бы с самого интересного - запустить ваш простенький процесс. Это бы хоть теме статьи соответствовало. Тут и возникают нюансы и приходит понимание, что все эти low code/no code нифига не low и, тем более, не no.
Миф о low-no-code видимо можно показать, если сравнить реализацию простейшего калькулятора (даже проще, чем штатный в windows и телефоне) на нескольких BPMN - платформах, включая camunda и runabase.ru
И потом сравнить с "много кода" в 30 строчек.
Кроме спорного вопроса, что BPMN это действительно low code/no code (см. выше), популярен миф, что BPMN - схема исполняемого приложения (программы) – это и есть "хорошая" документация на нее. Из практики: разработчики программ на BPMN обычно концентрируются только на исполняемой части (чтобы "работало"), но не добавляют на схему «лишние» элементы, например, документы и их статусы, которые помогли бы понять суть происходящего в части docflow. Для корректной работы программы не обязательна декомпозиция (процессы - подпроцессы), возможность печати на А4 и т.п.
Изначально была вера в концепт BPMN - как язык для машин и людей, т.е. «схема = документация» («чертеж» программы), но обычно для документирования процесса (бизнес-процесса) исполняемую схему приходится переписывать или в той же нотации BPMN, но уже как неисполняемую, добавляя в схему (обогащая) упомянутый docflow и другие данные, или в нотации EPC, которая еще более наглядна (интуитивно понятнее). При этом теряется ключевое свойство What You See Is What You Get — Что видишь то и получишь (точнее: что видишь, то и исполнится bpmn-engine), которое должно было позволить «визуальное программирование», «программирование без программирования» и подобные концепты на основе генерации исполняемого кода по нарисованной схеме, - понятной рядовому бизнес-пользователю (участнику процесса) и полностью описывающей его процесс.
Т.е. в схеме на как бы «low code» BPMN мы не только не видим реального «много кода», который дописывают программисты (без него бизнес-логика неполная), чтобы схема все же заработала (обогащение схемы кодом), но и для понимания работы схемы мы саму схему обогащаем информацией, делая новую схему процесса, но более понятную - обогащая схему деталями, например, документами (точнее docflow, включая изменение статусов документов) и комментариями, которые поясняют логику «много кода», спрятанного под капотом low code.
Плохо описана разница между эксклюзивным и инклюзивным шлюзами. Судя по тексту они оба подходят под критерий логического или.
Это не описание, а просто скопированный текст из нотации. На первой схеме цикл, который не понятно как решать. И откуда взята эта схема я думаю все знают
Практическая работа с BPMN