从业务流程中识别用例

开发团队可以使用业务流程模型来可视化地记录业务工作流，并将用例与这些业务流程关联，以建模系统需要实现的期望功能。在本教程中，我们将详细说明如何使用模型转换器功能，建立用例与业务流程之间的可追溯性。

什么是 BPMN 和 BPD？

BPMN 为业务分析师提供了一套用于建模业务流程的图形化符号。它最初由 业务流程管理倡议 (BPMI) 开发，目前由 对象管理组 (OMG) 维护。开发 BPMN 的其中一个动机是为来自不同角色、不同国家和/或使用不同语言的人提供一种通用的图形化语言，使他们能够无障碍地理解同一业务流程。

BPD 是 业务流程图 的缩写，是使用 BPMN 建模业务流程的地方。它是一种类似流程图的图表，用于展示流程的走向、参与方以及参与方之间的消息交换。业务分析师绘制 BPD 来建模不同参与方如何协作以实现业务目标。在与最终用户验证完完整的业务模型后，系统分析师便可开始规划系统。

以下是某组织注册流程的简单 BPD。它涵盖了你通常会看到的大多数典型建模符号。让我们来看一下。

符号	描述
	池 – 表示流程中的一个参与方。在 BPMN 中，池和泳道都用于表示参与方。泳道包含在池中，用于建模父池的子分区。
	开始事件 – 流程的起点。可以定义触发条件，以告知读者在何种情况下流程将被触发。例如，当收到一封邮件/当是周一早上/当发生错误时。
	任务 – 指定参与方（由池/泳道建模）可能执行的原子活动。任务和其他流程对象连接在一起，形成完整的业务工作流。
	结束事件 – 流程的终点。可以定义结果，以告知读者流程结束时会发生什么。例如，发出信号/产生错误等。

在本教程中，我们不会过多关注 BPD 或业务流程建模。如果你想了解更多关于 BPMN、BPD 或业务流程建模的内容，请阅读教程《BPMN 第一至第四部分.

什么是用例图？

用例建模指的是使用 UML 用例图来捕捉高层次用户需求的技术。用例模型是为软件或系统设计师设计的，而不是为业务人员设计的。

用例图中有三个主要元素。

符号	描述
	用例——每个用例代表一个用户目标，即用户希望在系统中实现的一个目标。请注意，用例只能用来展示用户想要做什么，而不是开发人员需要开发什么，尽管在某些情况下两者可能相同。如果你想记录或建模用例中涉及的功能，可以使用事件流工具，或通过以下方式详细说明用例：顺序图/活动图请记住，用例建模的目标是模拟用户希望实现的内容。
	参与者——系统的用户。这里的“用户”不仅限于人类，也可以是与我们的系统交互以实现特定业务目标的其他系统。
	通信链路/关联——连接参与者与用例，表示参与者对系统的访问。每个通信链路都意味着参与者与系统之间的一系列交互。

从BPD到用例图的转换

尽管BPD和用例图不一定必须相互依赖，但它们在某种程度上可以相互补充。通常，我们开发软件是为了自动化或优化某些业务流程。通过BPD，你可以了解参与者如何协作以及谁对什么负责，从而确定他们需要系统支持哪些功能。用户希望实现的这些系统功能（工作流或业务流程）可以通过用例进行建模，然后由团队进行开发。因此，我们可以说，BPD有助于你识别待开发系统中的用例。

Visual Paradigm是一款可视化建模工具，通过模型转换功能在两个模型之间建立可追溯性链接，支持从业务流程执行到用例建模（从业务需求到应用需求）的全过程。我们需要可追溯性，原因如下：

• 通过研究用例所涉及的流程部分，我们可以确保系统能够适应现实世界的应用。
• 通过追溯用例所源自的流程部分，来回答“我们为什么需要这个（系统）功能？”之类的问题。
• 通过从BPD追溯到用例图，来回答“某个特定操作是否已经实现？”之类的问题。

BPD与用例图对比

当你将BPD转换为用例图时，可以从泳道/池中生成参与者，从任务/子流程中生成用例。下表展示了泳道、泳道、参与者、任务、子流程和用例在模型转换方面的特征。

来源	目标	描述
		泳道/池 → 参与者 在BPD中，泳道代表业务流程的参与者，而泳道是泳道的子分区。任何与流程相关并需要执行活动的个体都被称为参与者。在用例图中，参与者代表系统的用户。请记住，任何不是系统用户的个人或角色都不应被视为参与者。
		任务/子流程 → 用例 在BPD中，任务/子流程（活动）指的是参与者为完成业务流程可能执行的任何操作。在用例图中，用例表示用户通过使用系统希望实现的目标。请记住，一个活动不一定与任何系统功能相关，一个用例可能满足多个活动。

有些人可能认为用例图与BPD相似，但在符号和目的上却有很大不同。请记住，BPMN是为业务人员设计的，而用例图则是为系统分析师或系统开发人员设计的。它们服务于不同的目的，并从两个不同的视角解读业务。因此，在前一节中，我总结了BPD与用例图之间的关系，即“BPD有助于你识别用例”。BPD在识别用例时只能提供一些提示。并没有规定BPD中的每个任务都等同于一个用例。但我们可以通过用例来详细描述业务流程，以实现目标系统对某一功能的自动化。

在案例研究中，我将向你介绍在将BPD转换为用例图时需要注意的事项。这样你就能理解它们之间的差异。

案例研究：真 Aqua 纯净水公司

真 Aqua 纯净水公司是一家城市中的年轻纯净水供应商。他们向企业和家庭销售纯净水。以下是其送水流程的文字描述。

订购纯净水时，客户可通过拨打订购热线或发送电子邮件完成。目前，90%的订单来自电话，10%通过电子邮件下单。接收订单的客服助理将检查客户是现有客户还是新客户。如果客户从未订购过，客服助理将在安排送水前为其创建客户账户。 纯净水的配送每周一次，安排在每周三。因此，每周三上午，客服助理会将订单转发给物流部门进行配送。一旦物流部门经理收到订单，他将通过为不同订单分配工作人员、打印并张贴配送计划来安排配送。工作人员接到通知后，按要求将水送到客户手中。

基于上述描述，已创建了一个业务流程模型。现在，你需要开发一个计算机系统来优化整个流程。首先，你需要开发一个用例模型。在BPD的帮助下，尝试绘制用例图。

1. 下载纯净水配送.vpp。你也可以在本教程的底部找到该文件。
2. 在 Visual Paradigm 中打开下载的 .vpp 文件。要打开项目，请选择项目 > 打开从应用程序工具栏中。
3. 打开 BPD蒸馏水订购流程。仔细研究流程。
   
4. 流程在客户下单时开始。这里我们可以考虑一个用例——下单。该用例将通过为客户提供一个无需客户服务中心助理协助即可下单的界面，帮助自动化流程，验证客户身份，并在客户不存在时创建账户。右键单击“下单”，然后选择相关元素 > 转移到新用例……从弹出菜单中。
   
5. 这会弹出转移模型元素窗口，您可以在其中选择将用例和参与者放置的模型，并重命名它们。在这种情况下，我们对用例和参与者的名称感到满意。让我们保持不变。单击确定.
   
   这将在 UeXceler 中形成一个新的用例图。
   
6. 返回到 BPD。
7. 让我们考虑一下任务创建客户账户。在业务流程中，客户服务中心助理需要为每位新客户创建账户。在新系统中，这可以是“下单”用例的一部分，也可以是由客户服务中心助理手动触发的独立用例。在现实情况中，您应该与利益相关者澄清此类疑问，因为错误的用例模型会导致开发出不符合用户期望的功能。在这个例子中，我们假设用户希望“创建客户账户”任务由客户服务中心助理完成。让我们从它创建一个用例。右键单击创建客户账户，然后选择相关元素 > 转移到新用例……从弹出菜单中。
   
8. 再次，我们对用例和参与者的名称感到满意。请将“转移模型元素”窗口中的所有内容保持不变。单击确定用例图已更新，新增了一个用例和一个参与者。我们来看一下。
   
9. 返回BPD。我们继续看子流程安排配送物流部门经理可以使用系统进行调度并通知员工配送水。因此，这也是系统的一个用例。右键单击子流程安排配送并选择相关元素 > 转移到新用例……从弹出菜单中。
10. 在转移模型元素窗口中检查参与者经理。如果我们保持参与者名称为经理，这在用例模型中是模糊的，因为公司中可能有多个部门，每个部门都有不同的经理。因此，将参与者重命名为物流部门经理.
    
11. 单击确定。用例图已更新。
    
12. 返回BPD。最后的任务配送水是一项只能由人工完成且与系统交互无关的工作。因此，我们不需要为此创建用例。
13. 假设区域经理希望系统支持一个新功能，可以生成报告以显示订单统计数据。该功能可以帮助他审查和优化营销策略。尽管该功能在业务流程模型中尚未建模，但我们可直接在用例图中绘制。打开用例图。绘制一个参与者区域经理。从该参与者创建一个用例生成统计报告，并用关联连接。
    
14. 假设客户希望允许客户查看账单并取消订单。此外，客户还希望允许物流部门经理打印物流报告。分别绘制这些用例。
    
15. 整理一下图表。
    
16. 转换关系使您能够从用例模型追溯到业务流程模型（反之亦然）。我们来试试。将鼠标指针放在下单 用例。
    
17. 点击模型转换器 资源，位于形状的右下角。选择从 > 蒸馏水订购流程 <.下单 从弹出菜单中。
    
    这将打开BPD，并选中任务下单 已选中。