Comments 48
То есть человеку, оплатившему обучение, не показывают сообщение, что запись прошла успешно?
Показывает, но после оплаты, то есть это сообщение будет в схеме bpmn "Оплата", так как без оплаты человека на обучение не запишут.
На этой схеме можно добавить сообщение о том, что место на обучение забронировано и информацию, что нужно оплатить перед шагом оплаты для информативности
И, ИМХО, «сказочка» и картинки — не к месту.
На схеме разделения на ui сайта и сервис не показано, чтобы проще было читать процесс.
Сервис ответит на ui, что обучение платное, ui интерфейс покажет пользователю сообщение, то есть пользователь увидит сообщение, поэтому сообщение в пользовательском пуле.
Оплата в пользовательском пуле, так как пользователь переходит на оплату
Про картинки и сказку спасибо за ваше мнение. ?
Оплата в пользовательском пуле, так как пользователь переходит на оплатуи после того, как он туда перешел — по вашей же схеме процесс завершается. «разделения на ui сайта и сервис» тут совершенно ни при чем. если «сообщение в пользовательском пуле», причем в «пользовательских действиях» — значит, его делает сам пользователь.
Момент интересный, если посмотреть на процесс как на запись на обучение, то именно запись на обучение закончена, так как пользователь ушёл на оплату. Я именно с этой точки зрения рисовала схему, но ваш комментарий говорит мне, что верно было бы закончить процесс (end) только для бесплатного курса, а для платного перейти на оплату.
Пользователь видит сообщение об успешной записи на курс и как минимум нажмёт закрыть. Я бы добавила элемент сообщение от сайта к пользователю в потоке обучение бесплатное, чтобы точно было понятно.
Поправлю схему в статье
то именно запись на обучение закончена, так как пользователь ушёл на оплату.— тогда «оплата обучения» должна быть не как «действие пользователя», а как «сообщение пользователю о необходимости совершить оплату». тогда да — с текущим процессом закончили, а поступление оплаты запустит отдельный новый другой процесс, со своим кротом и дюймовочками.
Ну или если в одном процесссе — то «предложили оплатить» — если оплатили — тогда «записали на курс», «сообщили» и закончили. если «не оплатили», то «попрощались» и закончили.
Спасибо за интересную и простую манеру изложения.
Для новичка просто идеальный старт. :)
То есть, декомпозиция проведена некачественно, с путаницей уровней абстракции. Ну и скажу честно, по прочтении статьи я так и не понял, в чём принципиальная разница хоть с теми же блок-схемами и почему надо пользоваться именно bpmn.
По вашему рисунку я понимаю, что вам не хватило статье инструкции как пользоваться инструментом drawio, чтобы получить диаграмму?
Кстати, именно для bpmn лучше использовать другой инструмент - demo.bpmn.io, лежащая в основе библиотека, кстати, используется в подавляющем большинстве bpms-систем с веб-интерфейсом.
Рискну предположить, что не хватило развёрнутого объяснения, как несколько вырванных из контекста кадров мультфильма превратились в псевдо-BPMN диаграмму.
И к чему тут 1 (один) час.
Не хватает слайдов с промежуточными итогами построения, понимаете ли.
Я полгода убил на то, чтобы эти диаграммы хотя бы читали, а Вы хотите, чтобы процесс их создания "экстраполировали назад" без наглядного материала, за одну статью.
Не стоит так делать впредь, не поймут.
Во-первых, лучше и удобнее пользоваться инструментами на основе фреймворка bpmn-js, например, demo.bpmn.io, storm.bpmn2.ru, Camunda Modeler и прочими подобиями.
Во-вторых, согласно стандарту, единственный элемент, который может разделять или объединять потоки управления - это шлюз.
В-третьих, хорошо бы рисовать диаграмму в одном стиле. Т.е., если задачи/работы могут (с вашей точки зрения) разделять или объединять потоки управления, тогда не надо использовать шлюзы; если используете шлюзы для разделения/слияния потоков управления, то только их используйте. Читаемость схемы гораздо выше, если каждый элемент выполняет только определенную ему стандартом роль - разнообразие здесь только во вред.
инструментами на основе фреймворка bpmn-js, например, demo.bpmn.io, storm.bpmn2.ru, Camunda Modeler и прочимиа они позволяют проверять модель?
(я только проприетарным bizagi пользовался)
Ещё есть TWE - Together Workflow Editor. Редактор кода в нём неудобен, но он из всего, что я пользовался наиболее полноценный с валидацией модели и интеграцией с движком (Enhydra Shark). Очень удобно в целом, и цикл разработки короткий.
я просто «рисовал картинки», а моделлер ее валидировал.ну и на основе этого делалась документация.
а можно — в трех словах — как используется «редактор кода» (что, на чем и куда пишется, и куда потом попадает), что делает движок, и т.д.?
я даже не понимаю, зачем там редактор кода.
BPMN без движка, это именно что рисовалка.
BPMN, это не просто картинки, это готовый к исполнению workflow в формате XPDL и исполняется он на движке который совместим со спецификацией BPMN.
Едит:
Ах, да, редактор кода, нужен чтоб Активити типа скрипт редактировать, у TWE поддерживается питон, жабаскрипт и beanshell.
Но можно как-нибудь с примером: вот ТС нарисовал этот ворфлоу приема заявки. как он будет исполняться?
То, что «на движке» можно отмоделировать — это я понимаю. Но исполнять-то всеравно должна создаваемая целевая система? под выражением «workflow в формате XPDL и исполняется на движке» — понимается моделирование, или реальная работа?
Моделирование в редакторе. А исполнение на движке. В редакторе, вы не просто рисуете, а создаёте живой процесс, который потом выполняется сразу на движке, после того как вы ему этот XPDL подкинете. Движок, например enhydra shark, интегрируете в своё приложение.
Примером может служить например платформа CMDBuild.
storm.bpmn2.ru умеет "в валидацию"
Спасибо за инструменты! Draw io использую, так как он есть в Confluence, который сейчас встречается практически во многих компаниях для документации.
чтобы рисовать хореографию, можно пользоваться этим веб-инструментом https://bpt-lab.org/chor-js-demo/
Во-первых, лучше и удобнее пользоваться инструментами на основе фреймворка bpmn-js, например, demo.bpmn.io, storm.bpmn2.ru, Camunda Modeler и прочими подобиями.
Не раскрыта тема "истинного опенсорса" широкого профиля типа DIA.
Всё равно BPMN до конца мало кто понимает - а значит, где-то надо упрощать, где-то разделять, и инструмент широкого профиля типа DIA покажет себя заведомо лучше.
(в т. ч. тем, что не будет решать за составителя, валидная диаграмма или невалидная. Всякое бывает в рабочих процессах, знаете ли...)
bpmn-js как раз является истинным представителем жанра опенсорс, т.к. позволяет встраивать себя в любой вебсайт, а не только эксплуатировать себя с "одобренных партией" сайтов и приложений.
Пагадитя... Мы BPMN ещё не освоили толком - а Вы уже предлагаете что-то куда-то встраивать... Это... немного не с той стороны подход...
The source code responsible for displaying the bpmn.io project watermark that
links back to https://bpmn.io as part of rendered diagrams MUST NOT be
removed or changed. When this software is being used in a website or application,
the watermark must stay fully visible and not visually overlapped by other elements.
Во-вторых, вот эта выдержка из лицензионного соглашения на bpmn-js, мягко говоря, нетипична для "истинного представителя жанра опенсорс".
Я, признаться, не очень разбираюсь в сортах опенсорса, но безусловное требование всегда во всех копиях держать ватермарку, ведущую на сайт исходного производителя, - это не совсем опенсорсно с точки зрения "почти обычного пользователя", загоняющегося по опенсорсности.
DIA такой тщеславной фигнёй не страдает.
и еще один момент - промежуточное событие-сообщение не используется для обозначения информационного обмена между ролями, а только между бассейнами. если надо показать обмен между ролями, то, во-первых, есть специальные два Task'а - Send Task и Receive Task, обозначаются черным и пустым конвертами в левом верхнем углу Task'а; а во-вторых, можно использовать Data Object, связав его при помощи двух Association Flow с соотв. Task'ами или SubProcess'ами
и последнее (на сегодня точно) замечание - потоки управления и сообщения не взаимозаменяемы. поток управления связывает задачи и подпроцессы внутри бассейна в одну или несколько траекторий исполнения, а поток сообщений показывает направление движения информации, и обозначает факты информационного обмена между бассейнами.
Несколько важных моментов, которые часто упускается при использовании BPMN, как на вышеприведённой диаграмме:
Pools (чаще их называют Lanes) лучше всего рассматривать не просто как subjects, a как роли (roles). При таком подходе, декомпозиция глубже и чище, как плюс сразу есть понимание об уровне доступа. Т.е. lane "сайт", по хорошему должен быть разделён на пачку lanes, каждая из которых роль (или конкретная подсистема/функция).
Каждый элемент Activity, это работа над персистентными данными. Создавать элементы Activity в которых не изменяются никакие данные/состояния - смертный грех.
Шлюзы "И" и "ИЛИ", это не просто булевские операции. Шлюз "И", создаёт параллельные потоки workflow, которые могут выполняться разными ролями одновременно. Ни в коем случае не одной ролью (в этом просто смысла нет). И где-то эти потоки должны в конце концов слиться.
Pools, Lanes - добавила в статью уточнения
Схема должна быть понятной, поэтому иногда можно показать действия без изменений, чтобы исключить недопонимания. Чаще всего такие действия требуются на бизнес процессах, когда схему рассматривает заказчик, не технический специалист.
"Исключающий Шлюз" использую в схеме, потому что в процессе проверка прошла или не прошла, то есть параллельно не могут идти эти потоки, аналогично с платный и бесплатный курс
в bpmn "за час" есть парочка неточностей)
пул != дорожка, у вас через запятую и не очень понятно имеете ли вы ввиду что это одно и то же
поток по умолчанию, это немного не то чем вы его называете ( This flow will be used only if all the other outgoing conditional flow is not true at runtime )
Для указания действий, следует указывать глаголы в повелительном наклонении
очень желательно следовать принципу, что процесс движется слева направо + сверху вниз (у вас он идет вертикально например в начале) хотя может это вы так экономили место
Какой процесс описывали? Что не получилось?
"Освоить за час" обычно (в моём опыте) требуется аналитику, когда нет времени на детальное изучение больших статей:
1) перед собеседованием, если в вакансии указан bpmn, а ты с ним не работал
2) пришёл на новую работу, а раньше не рисовал в bpmn, а там всё схемы в нотации и попросили поправить.
То есть сначала осваивается минимум "за час", а затем повышается скилл, за счёт детального изучения и практики
Вон оно что, Михалыч! То, что я всю жизнь рисовал "чтобы людям было понятно" оказывается умным словом называется!
Сама статья может уместиться в пару абзацев, а поди ж ты, все равно полезно оказалось узнать! Спасибо автору.
а еще demo.bpmn.io умеет с недавних пор свернутые Sub Process'ы связывать с отдельными диаграммами, как Visual Paradigm. и хранится все это добро по-прежнему в одном bpmn-файле, который по сути есть обыкновенный XML
(глядя на обсуждение выше) Ну вот берем мы эту нарисованную диаграмму и отсылаем ее на Code Review коллегам и прочим заинтересованным лицам. Они на все это смотрят, делают комментарии и даже вносят правки. Потом к нам возвращаются n-ное количество штук слегка отличающихся диаграмм с которыми мы делаем что? Какими инструментами мы все эти правки в итоговую диаграмму сводим? Или хотя бы смотрим, что именно поправили?
В своей практике использовала такие варианты
Вариант 1. Прикладывать в документацию схемы по версиям, но тогда только визуально будет видно изменение.
Вариант 2. Выделять цветом изменения на схеме, это уже более наглядно.
Вариант 3. Описать внесённые изменения перед диаграммой текстом, но этот вариант не всегда могут прочитать текст
Т.е. сведение в общую диаграмму все-таки в ручную. Кроме того. Это описано, что делать на одном обороте уточнений. А как сравниваем текущее состояние диаграммы с тем, что было пару-тройку итераций назад? Ну неудобны, диаграммы для таких желаний без соответствующего инструментария, про который постоянно забывают сказать. Хотя сильно стоило бы.
чтобы коллективно такие диаграммы рисовать, нужно использовать нечто вроде Visual Paradigm - он всю версионность таких процессов как-то сам отслеживает и обслуживает
Странно что EPC в вариантах для голосования нет.
Bpmn для системного аналитика. Освойте нотацию за 1 час