如何一起使用 BPMN 和用例及其他图
BPMN（Business Process Modeling Notations）用于通过可视化的方式对业务流程进行建模，从而通过BPMN图的表达使无形的想法变得具体。问题是，如何使用 UML 组织 BPMN。
最初，我想到了两种方式来组织用例和业务流程图：
1 对一/多：通过映射每个步骤（
step这里指的是中的每个节点业务流程图中的 BPMN 图）以及一个或多个用例。每个用例都映射有相关的几个类图/组件图（我更喜欢这个，因为您可以将一组类封装到一个具有输入和输出的组件中），几个序列图（可选）。有了类图/序列图后，就可以根据模型编写/生成代码。多对一：通过将多个步骤映射到一个用例中。后续步骤是相同的。
多对多：例如，业务流程中的一个步骤可以映射到两个或多个用例，而相同的两个或多个用例可以映射到其他步骤。
上述方法可以通过建模工具来完成，在我的例子中，我使用Sparx System的Enterprise Architect。我最近发现它并且正在试用它，但我将来会购买它。我可以通过BPMN图一步来组织很多用例图，并且可以点击查看必要的用例。但是，如果它支持多对多情况，我不知道。
在思考了自己组织 BPMN 和用例的方法之后，我在网上搜索，找到了另外两篇论文，每篇论文都提出了以下方法：
将每个用例转化为 BPMN 图的每个步骤：可视化精细化用例如何融入业务流程。我喜欢这种方法，因为可以对带有步骤的业务流程进行建模，然后每个步骤都变成一个用例。一个步骤就是一个用例。这与我上面的一对一映射相同。原始演示文稿在这里：将用例集可视化为 BPMN 流程
每个用例都是一个业务流程：每个步骤用例中是业务流程的每个步骤。原始论文在这里：用用例描述业务流程
在我看来，没有标准化的方法来粘合这些工件（BPMN 和用例以及其他图） ） 一起。也许这是一个管理问题，更多地依赖于创造性的使用，而不是遵循正式的步骤。 您对在软件工程过程中使用这些图表有何看法/经验？
我知道像 XP 这样的方法论，它指定了自己在软件开发过程中的实践。然而，与 Scrum 不同的是，Scrum 更关注管理方面（这意味着您仍然可以将 BPMN/UML 建模应用到您的工作流程中），XP 指定了软件实践并要求您遵循，并消除了像 BPMN/UML 这样的建模流程，并且它的实践如果应用不当会导致诸如文档不足、软件设计不足等问题。
相比 XP，我更喜欢模型驱动的方式。我想这取决于公司和个人的喜好。敏捷的目标之一是“将开发人员从文档工作中解放出来”。像 XP 这样的方法似乎很容易导致文档不足。我认为要实现这一目标，解决方案是实现该工具来帮助开发人员减少编写文档的工作量，而不是通过编写更少的文档，而是通过从现有图表中收集信息并自动生成报告（在本例中为RTF、PDF、HTML） Sparx 系统企业架构师）。另一个例子是，人们经常抱怨绘制图表浪费了他们的时间。在我看来，解决方案不是画图，而是使用工具。如今的建模工具支持往返工程，您可以在代码和图表之间进行同步，从而消除了在代码库发生更改（特别是类图）时手动更正图表的额外工作。 您对此问题有何看法/经验？
BPMN (Business Process Modeling Notations) is used for modeling business process by visualization, thus making intangible ideas become physically concrete through the expression of BPMN diagrams. The question is, how do I organize the BPMN with the UML.
Initially, I thought of two ways to organize use cases and business process diagram:
1 to one/many: By mapping each step (
stephere means each node in the BPMN digram) in the business process diagram with one or several use cases. Each use case is mapped with relevant several class diagrams/component diagrams (I prefer this one, since you can encapsulate a set of classes into one component which has input and output), several sequence diagrams (optional). After you have class diagrams/sequence diagrams, code is written/generated based on the model.Many to one: By mapping several steps into one use case. The subsequence steps are the same.
Many to many: For example, one step in the business process can be mapped with two or more use cases, and the same two or more use cases can be mapped with other steps.
The above methods can be done by the modeling tool, and in my case, I use Enterprise Architect from Sparx System. I discover it recently and I am using its trial, but I will buy it in the future. I can organize many use case diagrams with one step of the BPMN diagram, and can click to view the necessary use cases. However, I don't if it supports many to many cases.
After thinking my own method for organizing BPMN and Use Cases, I searched the Internet, and found two other papers, each suggest the following method:
Turn each use case into each step of BPMN diagrams: To visualize how refined use cases fit into the business process. I like this approach, since the business process with steps can be modeled, and later each step is turned into a use case. One step is one use case. This is the same with my one to one mapping above. Original presentation is here: Visualizing Use Case Sets as BPMN Processes
Each use case is exactly a business process: Each step in the use case is each step of the business process. Original paper is here: Describing Business Processes with Use Cases
It seems to me that there's not standardized way of gluing these artifacts (BPMN and Use Cases and other digrams) together. Maybe it's a management problem and rely more on creative usage rather than follow a formal steps. What are your opinions/experience on the usage of these diagrams in software engineering process?
I know methodology like XP which specifies its own practice in software development process. However, unlike Scrum where it focuses more on management aspects (which means you can still apply the BPMN/UML modeling into your work process), XP specifies software practices and requires you to follow, and eliminate the modeling process like BPMN/UML, and its practices if not apply properly will lead to issues like under documentation, incorporates insufficient software design....
I prefer the model driven way than XP. I guess it's up to the preference of companies and people. One of Agile goal is to "free developers from document works". Methodology like XP seems to easily lead to under documentation. I think to achieve that goal, the solution is to implement the tool to help developer reduce the workload on writing document, not by writing less documents, by gathering information from existing diagrams and automatically generate reports (in RTF, PDF, HTML in the case of Enterprise Architect of Sparx System). Another example is, people often complain about drawing diagrams consume their time. In my opinion, the solution is not to draw diagram, but the using the tool. Modeling tools today support round-trip engineering, where you can synchronize between your code and your diagrams, thus eliminates the extra effort to manually correct the diagrams if the code base changes (specifically, class diagram). What's your opinions/experience on this issue?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
用例应该是面向目标的任务，它们不是单一步骤。第一个示例是利用用例的标准方法的明确变体。我建议将每个用例映射到单个业务流程上。此 Sparx EA 示例将用例映射到活动图上，但确实揭示了使用方法。
Usecase should be goal oriented tasks they are not single steps. The first example is a definite variation of the standard way to utilise usecases. I suggest map each usecase onto a single business process. This Sparx EA example maps usecase onto activities diagrams but does reveal the approach to use.
我的 2 美分
我的建议是使用这些工具来了解业务流程。我遵循以下
当您开始寻找所有这些的完美结合时，您将迷失在细节中。 ;-)
My 2 cents
My suggestion is to use these tools to understand the business processes. I follow the below
When you start looking out for the perfect marriage of all these, you will be lost in details. ;-)
我建议采用这种方法： https://www.academia.edu/6750935/From_Business_Process_Models_to_Use_Case_Models_A_systematic_approach
一般来说，一个流程对应多个流程除了一个用例之外，只有在特定情况下关系才会是一对一的。
I suggest this approach: https://www.academia.edu/6750935/From_Business_Process_Models_to_Use_Case_Models_A_systematic_approach
Generally speaking, one process maps to more than one use case, only in particular cases the relationship goes one-to-one.