Преимущества и недостатки BPMN?

Я надеялся, что вы скажете мне, каковы преимущества и недостатки BPMN с точки зрения разработчиков.

Я сравниваю UML с BPMN и обнаружил кучу преимуществ и недостатков для UML, но ни одного для BPMN.

 B--rian12 мар. 2019 г., 09:18
Аналогичный вопрос:stackoverflow.com/questions/25471548/... (уже связано в любом случае)
 Gottlieb Notschnabel01 апр. 2015 г., 09:57
Вы можете взглянуть наэто сравнение BPMN инструментов.

Ответы на вопрос(5)

См. MDA для OMG (Model Driven Architecture): - мы используем BPMN только для моделей, независимых от вычислений (CIM) - мы используем UML только для моделей, независимых от платформы (PIM, проектирование высокого уровня) и конкретной модели платформы (PSM, проектирование низкого уровня) , - использование BPMN для любых «программных систем» или UML для «бизнеса» не имеет смысла (см. UML v.2.5) - для разработчиков: мы можем перейти от бизнес-процесса BPMN к Use Case, это хороший инструмент для определения объема требований для программного обеспеченияhttps://www.visual-paradigm.com/tutorials/from-business-process-to-use-cases.jsp

Основными аргументами в пользу BPMN с точки зрения бизнеса обычно являются:

При построении диаграмм BPMN с нуля со многими заинтересованными сторонами можно смешивать задачи разных уровней иерархии, которые могут быть детализированы или обобщены позже.основные языковые элементы можно быстро подумать даже нетехнической аудитории.Разработчики могут немедленно начать работу и присоединять исходный код и сценарии к диаграмме BPMN с помощью программного обеспечения для управления рабочими процессами и бизнес-процессами, такого какCamunda.

Основные недостатки в том, что

Первоначальный набросок BPMN (обычно по бизнесу) обычно требует много итераций, чтобы получить диаграмму, которая допускает реализацию.Не просто представлять разные роли, поскольку обычная концепция дорожек в пулах может быть недостаточной или приводить к огромным диаграммам, см., Например,BPMN: несколько ролей подряд
 B--rian03 авг. 2017 г., 14:30
Я добавил еще один недостаток BPMN, о котором недавно узнал. НТН.

Новый профиль BPMN обсуждался на OMG. UML может легко генерировать код даже с диаграммами действий или состояний. Вам просто нужно добавить стереотипы в вашу модель, тогда парсер возьмет xmi и создаст код. Спецификация OMG определит, какие стереотипы следует использовать и почему. Действительно очень хорошая идея!

В моей компании мы прекратили использовать BPMN и сосредоточены только на диаграмме действий, которая является более точной, поскольку построена на основе стандартного языка. Наличие диаграммы классов, диаграмм использования и активности позволяет моделировать быстрее. Мы получаем работающий код из нашей диаграммы активности или состояния. Мы отлаживаем с нашей диаграммой классов. Мы используем одну и ту же метамодель для всех диаграмм и поэтому можем проследить активность до реализации кода и через диаграмму классов. Я имею в виду, что после того, как код сгенерирован, он переворачивается, и затем мы проверяем все требования и архитектуру, чтобы получить более качественную объектную архитектуру. Все работает хорошо :-)

Теперь мы ждем новую спецификацию профиля и будем внедрять необходимые стереотипы, чтобы охватить BPMN. Мой ответ на ваш вопрос заключается в том, что нам больше не нужен BPMN, и мы должны перейти к реализации профиля UML 2.3 BPMN.

Решение Вопроса

Это в значительной степени зависит от аудитории и цели. С точки зрения языка моделирования, диаграммы деятельности BPMN и UML покрывают практически одно и то же концептуальное пространство с различными обозначениями. Нотация очень быстро становится религиозной. Я лично предпочитаю нотацию AD, а не BPMN, но это очень личная вещь.

Вообще говоря, BPMN имеет тенденцию пользоваться популярностью у тех, кто пришел из бизнес-процессов моделирования / бизнес-анализа. UML AD, как правило, предпочитают те, кто приходит с точки зрения программного обеспечения. Поддержка инструментов имеет тенденцию отражать это: высокопроизводительные инструменты моделирования процессов (casewise, aris и т. Д.) С большей вероятностью поддерживают BPMN; инструменты программного моделирования (MagicDraw, Sparx и т. д.) предпочитают UML. Однако там растет кроссовер. Я использовал оба с деловыми заинтересованными сторонами без проблем в любом случае.

Наконец-то цель. Будут ли ваши диаграммы предназначены только для потребления человеком или используются в качестве спецификации для какой-либо формы анализа / генерации кода? Если это не просто картинки, то ваша цепочка инструментов может стать решающим фактором.

Если вы хотите более подробное описание различий, посмотрите на ответ вэто сообщение на форуме.

BPMN предназначен для моделирования потока бизнес-процессов, не так ли? Это не совсем то, для чего нужен UML. Цель UML состоит в том, чтобы смоделировать программное обеспечение с другой точки зрения и, в конечном счете, не кодировать его (да, это своего рода идеал).

Ваш ответ на вопрос