BPMN的优缺点?

这在很大程度上取决于观众和目的。在建模语言方面,BPMN和UML活动图涵盖了几乎相同的概念空间和不同的符号。符号很快就变成了宗教。我个人更喜欢广告符号而不是BPMN——但这是一件非常私人的事情。

从广义上讲,BPMN往往会受到来自业务流程建模/业务分析背景的青睐。从软件的角度来看,UML广告往往更受欢迎。工具支持倾向于反映这一点:高端流程建模工具(casewise、aris等)更可能支持BPMN;软件建模工具(magicDraw、sparx等)更倾向于UML。但是那里交叉越来越多。我和业务利益相关者都使用过,在这两种情况下都没有问题。

最后是目的。您的图表将只供人类使用还是用作某种分析/代码生成形式的规范?如果这不仅仅是图片,那么你的工具链很可能是决定因素。

如果您想要更详细地描述这些差异,请查看 this forum post .

OMG讨论了一个新的BPMN配置文件。即使使用活动或状态图,UML也可以轻松地生成代码。您只需要在模型中添加构造型,然后解析器将获取XMI并创建代码。OMG规范将定义应该使用哪些原型以及原因。真是个好主意!!

在我的公司中,我们已经停止使用BPMN,只关注活动图,因为它建立在标准语言之上,所以更准确。拥有类图、用例图和活动图可以更快地建模。 我们从活动或状态图中得到一个运行代码。我们用类图进行调试。 我们对所有图使用相同的元模型,因此可以通过类图将活动跟踪到代码实现。我的意思是代码一旦生成就被颠倒,然后我们检查所有需求和体系结构,以便有一个更好的对象体系结构。 一切正常:-)

我们现在正在等待新的概要规范,并将实现所需的原型,以涵盖BPMN。 我对您的问题的回答是,我们不再需要bpmn,应该继续使用uml 2.3bpmn概要文件实现。

BPMN是为业务流程流程建模的,不是吗?这并不是UML的目的。UML的目标是从不同的视图对软件进行建模,最终不必编写代码(是的,这是一种理想的方法)。

从业务角度来看,BPMN的主要论点通常是:

1. 当与许多涉众从头构建BPMN图时,可以混合不同层次的任务,这些任务可以在后面详细描述或总结。
2. 这个 basic language elements 即使对非技术性的观众也能迅速想到。
3. 开发人员可以立即开始工作,并通过工作流和业务流程管理软件(如 Camunda .

主要的缺点是

1. 最初的BPMN草图(通常由业务部门完成)通常需要多次迭代才能得到一个允许实现的图。
2. 由于池中通常的车道概念可能不够,或导致出现巨大的图表,因此表示不同角色的方法并不直接。 BPMN: multiple roles in a row

参见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