BPMN的优点和缺点？
我希望您能告诉我从开发人员的角度来看 BPMN 的优点和缺点是什么。
我将 UML 与 BPMN 进行比较，发现 UML 有很多优点和缺点，但 BPMN 却没有。
I was hoping you could tell me what the advantages and disadvantages of BPMN are in a developers perspective.
I'm comparing UML with BPMN and a found a bunch of advantages and disadvanteges for UML but none for BPMN.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
这很大程度上取决于观众和目的。在建模语言方面，BPMN 和 UML 活动图涵盖了几乎相同的概念空间，但具有不同的符号。符号的事情很快就变得宗教化了。与 BPMN 相比，我个人更喜欢 AD 表示法 - 但这是非常个人化的事情。
一般来说，BPMN 往往会受到那些具有业务流程建模/业务分析背景的人的青睐。 UML AD 往往受到软件角度人士的青睐。工具支持往往反映了这一点：高端流程建模工具（casewise、aris 等）更有可能支持 BPMN；软件建模工具（MagicDraw、Sparx 等）有利于 UML。然而，那里的交叉越来越多。我已经与业务利益相关者一起使用过这两种方法，在这两种情况下都没有出现任何问题。
最后是目的。您的图表仅供人类使用还是用作某种形式的分析/代码生成的规范？如果不仅仅是图片，那么您的工具链很可能是决定因素。
如果您想要更详细地描述差异，请查看 此论坛帖子。
It's largely down to audience and purpose. In terms of modelling language, BPMN and UML activity diagrams cover pretty much the same conceptual space with different notations. The notation thing gets religious very quickly. I personally prefer AD notation over BPMN - but it's a very personal thing.
Broadly speaking, BPMN tends to find favour with those coming from a business process modelling / business analysis background. UML ADs tend to be favoured by those coming from a software perspective. Tool support tends to mirror this: the high end process modelling tools (casewise, aris, etc.) are more likely to support BPMN; software modelling tools (MagicDraw, Sparx, etc.) favour UML. However there's increasing crossover there. I've used both with business stakeholders with no issues in either case.
Finally is purpose. Are your diagrams going to be for human consumption only or used as a specification for some form of analysis/code generation? If it's not just pictures then your tool chain may well be the deciding factor.
If you want a more detailed description of the differences, have a look at the answer in this forum post.
OMG 已经讨论了新的 BPMN Profile。即使使用活动图或状态图，UML 也可以轻松生成代码。您只需要在模型中添加构造型，然后解析器将获取 xmi 并创建代码。 OMG 规范将定义应使用哪些构造型以及原因。确实是一个非常好的主意！！
在我的公司，我们已经停止使用 BPMN，只关注活动图，因为它构建在标准语言之上，所以更加准确。还拥有类图、用例和活动图，可以更快地建模。
我们从活动或状态图中获取正在运行的代码。我们用类图进行调试。
我们对所有图使用相同的元模型，因此可以通过类图跟踪活动到代码实现。我的意思是，代码一旦生成就会反转，然后我们检查所有需求和架构，以便拥有更好的对象架构。
一切正常:-)
我们现在正在等待新的配置文件规范，并将实现所需的构造型以覆盖 BPMN。
我对您问题的回答是，我们不再需要 BPMN，应该继续实施 UML 2.3 BPMN 配置文件。
A new BPMN Profile has been discussed at the OMG. UML can easily generate code even with an activity or state diagrams. You just need to add stereotypes in your model then a parser will take the xmi and create code. The OMG specification will define which stereotypes should be used and why. Really a very good idea !!
In my company we have stopped using BPMN and are only focus on the activity diagram which is more accurate because built on the top of a standard language. Having also class diagram, usecase and activity diagrams allows to model faster.
We get a running code from our activity or state diagram. We debug with our class diagram.
We use the same metamodel for all diagrams and therefore can trace activity to code implementation and through class diagram. I mean that the code is reversed once generated and then we check all requirements and the architecture in order to have a nicer object architecture.
Everything works well :-)
We are now waiting for the new profile specification and will implement the needed stereotypes in order to cover BPMN.
My answer to your question is that we don't need anymore BPMN and should move on to UML 2.3 BPMN profile implementation.
BPMN 用于对业务流程进行建模，不是吗？这并不完全是 UML 的用途。 UML 的目标是从不同的角度对软件进行建模，并且最终不必对其进行编码（是的，这是一种理想的情况）。
BPMN is for modeling business process flow, isn't it? That's not exactly what UML is for. The goal of UML is to model a software from different view and ultimately not to have to code it (yes that's kind of ideal).
从业务角度来看 BPMN 的主要论点通常是：
主要缺点是
The main arguments for BPMN from a business perspective are usually:
The main drawbacks are that
请参阅 OMG（模型驱动架构）上的 MDA：
- 我们仅将 BPMN 用于计算独立模型 (CIM)
- 我们仅将 UML 用于平台独立模型（PIM，高级设计）和平台特定模型（PSM，低级设计）。
- 对任何“软件系统”使用 BPMN 或对“业务”使用 UML 没有任何意义（参见 UML v.2.5）
- 对于开发人员：我们可以从 BPMN 业务流程过渡到用例，它是定义软件需求范围的好工具 https://www.visual-paradigm.com/tutorials/from-business-process-to-use-cases.jsp
See the MDA on OMG (Model Driven Architecture):
- we use BPMN only for Computation Independent Models (CIM)
- we use UML only for Platform Independent Model (PIM, high level design) and Platform Specific Model (PSM, low level design).
- using BPMN for any "software systems" or UML for "business" have no sense (see UML v.2.5)
- for developers: we can make transition from BPMN business process to Use Case, it is good tool for defining scope of requirements for software https://www.visual-paradigm.com/tutorials/from-business-process-to-use-cases.jsp
如果您正在寻找相似之处，UML 和 BPMN 图都可以使用文本来描述。
If you are looking for similarities, both UML and BPMN diagrams can be described using text.