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

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

Я сравниваю ОМЛ с BPMN и нашла кучу преимуществ и disadvanteges для UML, но никто в BPMN.

9
bpmn modeling uml

5 ответов

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

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

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

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

14

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

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

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

2

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

1

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

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

основными недостатками являются то, что

  1. начальный эскиз BPMN (обычно бизнесом) обычно требует много итераций, чтобы прийти к диаграмме, которая позволяет реализовать.
  2. это не прямо вперед, чтобы представить различные роли, так как обычная концепция полос движения в пулах может быть недостаточно или привести к огромным диаграммам, см., например,в BPMN: несколько ролей подряд
0

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

0