业务用例模型 |
业务用例模型描述一个业务的流程以及它们与外部各方（如客户和合作伙伴）之间的交互。 |
主题
由业务用例和主角构成的模型的主要目的是说明客户和合作伙伴是如何开展业务的。直接与客户或合作伙伴相关的活动以及与外部各方并不直接相关的支持和管理任务都可以在模型中给出。
模型以业务用例（相当于我们常说的“流程”）的形式对业务进行说明。
登记处的主角和用例。
当考查业务中的活动时，您至少可以确定三类工作，它们对应着三种业务用例类型。
- 第一类是在商业上比较重要的活动，常称为业务流程。
- 第二类是在商业上不太重要的活动，但必须进行这些活动来保证业务正常运转。系统管理、清洁和安全等工作就是这类活动的示例。该业务用例具有支持的性质。
- 第三类是管理工作。具有管理性质的业务用例所显示的工作影响如何管理其他业务用例以及该业务和其所有者的关系。
通常，管理类型的业务用例概括地描述了 CEO 和业务用例中工作人员之间的关系。它还说明了业务用例是如何被开发和“启动”（实例化）的。
在餐馆中，核心业务用例是市场营销 (Marketing) 和用餐服务 (Serving Dinner)，而采购
(Purchasing Supplies) 是支撑业务用例。
请注意，有时候您当作核心业务用例的用例在其他业务中会成为支撑业务用例。例如，在软件开发公司中，软件开发是核心业务用例；而在银行或保险公司中，它却是支撑业务用例。
一个业务有多个业务用例。多个不同业务用例的实例或一个业务用例的多个实例并行执行的情况是很正常的。一个用例实例可以遵循的路径的数目几乎是没有限制的。这些不同的路径代表了工作流程说明中用例实例的各种选择。根据具体事件和情况，用例实例可以沿着多种可能路径中的一种进行下去，例如：
在对业务用例建模时，您可以假定用例实例可以在不互相冲突的情况下同时进行。在业务开发的这个阶段，您应该侧重于业务应该作些什么。而解决潜在资源冲突的工作应该在工作建模阶段进行，此时，您要设法理解业务中的工作是如何进行的。或者，您也可以在新组织实施过程中，通过增加能完成关键任务的雇员来解决这些问题。
每个核心业务用例都应该和某个业务主角之间存在通信关系。该规则强调了构建业务的目的，即构建业务是为了提供用户要求的服务。如果业务用例模型中存在无人要求的业务用例，这就说明模型存在问题。
业务用例可以周期性地触发，也可以长时间工作；监督功能就是后者的一个示例。这些业务用例中甚至还存在最初启动这些业务用例并期望得到不同服务的业务主角。否则，它们将不能成为业务的一部分。其他业务用例将产生业务主角需要的结果，尽管业务主角并没有明确地启动它们。例如，某个广泛发布产品的开发很少是由某个可以确定的客户启动的。而对新产品的需求通常是通过市场研究和积累大量的用户请求了解到的。
尽管管理和支撑业务用例一般都有某种外部联系，但它们不一定需要与业务主角进行联系。例如，管理业务用例可以将业务的所有者或董事会作为其业务主角。
抽象业务用例不需要业务主角，因为它们从不独立进行实例化（“启动”）。
建立业务用例模型有三个主要原因：
- 使业务用例更易于理解。
- 复用多个业务用例共享的部分工作流程。
- 使业务用例模型更易于维护。
我们有三种关系用于建立业务用例模型。使用这些关系，您可以将那些可以在其他业务用例中复用的、或者作为该业务用例的特化或选项的部分业务用例分离出来。我们将代表修改的业务用例称为附加用例。被修改的业务用例称为基本用例。
- 如果基本用例的某个部分代表一个功能，而业务用例只依赖于本功能的结果，而不是产生结果的方法，那么您可以将这部分分离出来，形成一个附加用例。使用包含关系，将附加部分明确包含于基本用例中。另请参见指南：业务用例模型中的包含关系。
- 如果基本用例的一部分是可选的，或对于理解该用例的主要目的来说不是必需的，那么您可以将这部分分离出来，形成一个附加用例，以简化基本用例的结构。利用扩展关系，将附加部分隐含地包含于基本用例中。另请参见指南：业务用例模型中的扩展关系。
- 如果几个业务用例在行为和结构上具有共同点，同时在目的上又很相似，则可以将它们的共同部分分离出来，形成一个基本用例（父用例），该基本用例被附加用例（子用例）继承。子用例可以在从父用例继承的结构中插入新的行为或修改现有的行为。另请参见指南：业务用例模型中的用例泛化关系。
登记处的主角和用例。这里，我们还显示了包含用例“行李处理”(Baggage Handling) 和扩展用例“通过登记处”(Through
Check-In)。
您可以使用主角泛化关系来显示主角之间的特化情况。另请参见指南：业务用例模型中的主角泛化关系。
另请参见指南：用例模型中关于建立系统用例模型的讨论。
特别是当开发业务模型只是为了“支持”某个软件工程项目时，您需要细致地对业务建模工作进行定界。在这种情况下，即使只对业务流程的一部分进行建模，也几乎不值得涵盖整个组织。为了能突出重点并产生期望的结果，应该选择只将整个公司的一部分视为您的“业务系统”，而所选部分应该是公司中将直接使用该系统的部分。组织中决定作为模型外部对待的那部分则可以表示为业务主角。
示例：
某公司决定开发一个用于销售和订购管理的新应用程序。为了研究组织的需要，同时调整组织中开展业务的方式，第一步工作就是构建一套业务模型。公司中不经常使用新订购应用程序的部门被当作模型的外部，用业务主角表示。
某个订购管理组织的业务用例模型中的业务主角和业务用例。该组织向每个客户销售复杂的定制解决方案。
业务用例的简要说明：
订购流程 (Order Process)：该流程描述了公司如何采取适当的行动向客户提供解决方案，该解决方案是通过一系列客户需求确定的。当作出业务决策，开发双方协商同意的解决方案时，流程开始。这常表现为公司收到客户的定单。而当客户对解决方案的安装和试运行表示满意，公司收到客户的付款后，流程结束。流程的目标是在满足客户需求的同时保证公司获利。
投标流程 (Proposal Process)：该流程针对客户的需求产生一个或多个投标方案。该流程由客户的询问触发，当客户接受（或拒绝）标书中的报价时结束。目标是协商确定一个客户和公司都可以接受的报价。
报价流程 (Quote Process)：报价流程是一个抽象业务用例，它包含在投标流程和订购流程中。当客户要求公司为其需求给出报价时，报价流程开始。报价流程的目标是产生一个满足客户需求的解决方案，同时给出这个方案的价格。
业务用例模型的调查说明应该：
- 概述组织的目的。
- 指出模型的定界 - 模型中不包括的部分以及不包括的原因。
- 指定主要业务用例。
示例：
业务用例模型覆盖我们公司管理客户订单的部分，因为只有这部分对软件工程项目有意义，它将使用业务建模的结果作为输入。出于这个原因，我们没有将公司中负责结账、生产、产品管理和产品开发的部门包括进来；这些部门作为模型的外部被表示为业务主角。
在该组织中，一次销售不仅包括对某个解决方案达成一致，还包括对该解决方案的构建。为了给解决方案定价，您需要将其设计并构建到足够细化的程度。这就是在“投标流程”中所进行的工作。与客户达成一致之后，公司便开始设计解决方案的所有细节，然后在客户方进行安装。这就是在“订购流程”中所进行的工作。“投标流程”和“订购流程”都包括“报价流程”这个抽象业务用例。
- 用例符合它们所描述的业务。
- 可以找到所有用例。合起来看，用例可以执行业务中的所有活动。
- 业务中的每个活动都应包含在至少一个用例中。
- 用例数量和用例大小之间应该保持平衡：
- 较少的用例可以使模型易于理解。
- 用例过多可能使模型理解起来比较困难。
- 大用例可能十分复杂，理解起来比较困难。
- 小用例通常易于理解。但是，一定要确保用例描述了一个完整的工作流程，该工作流程可以为客户产生某种有价值的结果。
- 每个用例都必须是唯一的。如果工作流程与其他用例相同或相似，以后将很难保持它们的同步。 因此考虑将它们合并为一个用例。
- 对用例模型的调查应该给出组织全面的情况。
| 
