BPMN（Business Process Modeling Notations）用于通过可视化对业务流程进行建模，从而通过BPMN图的表达使无形的想法在物理上变得具体。问题是，如何使用 UML 组织 BPMN。
最初，我想到了两种组织用例和业务流程图的方法：
1 to one/many：通过将业务流程图中的每个步骤（
step这里指的是BPMN图中的每个节点）映射到一个或多个用例。每个用例都映射有相关的几个类图/组件图（我更喜欢这个，因为您可以将一组类封装到一个具有输入和输出的组件中），几个序列图（可选）。拥有类图/序列图后，将根据模型编写/生成代码。多对一：通过将多个步骤映射到一个用例。后续步骤相同。
多对多：例如，业务流程中的一个步骤可以映射到两个或多个用例，相同的两个或多个用例可以映射到其他步骤。
上述方法可以通过建模工具完成，在我的例子中，我使用了 Sparx System 的 Enterprise Architect。我最近发现它并且正在使用它的试用版，但我将来会购买它。BPMN图的一步我可以组织很多用例图，可以点击查看需要的用例。但是，如果它支持多对多的情况，我不会。
在思考了自己组织BPMN和Use Cases的方法后，我在网上搜索，找到了另外两篇论文，每篇都建议以下方法：
将每个用例转化为 BPMN 图表的每个步骤：可视化优化用例如何融入业务流程。我喜欢这种方法，因为可以对带有步骤的业务流程进行建模，然后将每个步骤变成一个用例。一步是一个用例。这与我上面的一对一映射相同。原始演示文稿在这里：将用例集可视化为 BPMN 流程
每个用例就是一个业务流程：用例中的每个步骤都是业务流程的每个步骤。原始论文在这里：用用例描述业务流程
在我看来，没有将这些工件（BPMN 和用例以及其他图表）粘合在一起的标准化方法。也许这是一个管理问题，更多地依赖于创造性的使用，而不是遵循正式的步骤。您对在软件工程过程中使用这些图有什么看法/经验？
我知道像 XP 这样的方法论，它在软件开发过程中指定了自己的实践。但是，与 Scrum 更侧重于管理方面（这意味着您仍然可以将 BPMN/UML 建模应用到您的工作流程中）不同，XP 指定了软件实践并要求您遵循并消除像 BPMN/UML 这样的建模流程，并且如果应用不当，其做法将导致文档不足、软件设计不足等问题。
我更喜欢模型驱动的方式而不是 XP。我想这取决于公司和人们的偏好。敏捷的目标之一是“将开发人员从文档工作中解放出来”。像 XP 这样的方法似乎很容易导致文档不足。我认为要实现这个目标，解决方案是实现该工具来帮助开发人员减少编写文档的工作量，而不是通过编写更少的文档，通过从现有图表中收集信息并自动生成报告（以 RTF、PDF、HTML 为例） Sparx 系统企业架构师）。另一个例子是，人们经常抱怨画图消耗他们的时间。在我看来，解决方案不是画图，而是使用工具。今天的建模工具支持往返工程，您可以在其中同步代码和图表，你对这个问题有什么看法/经验？