UML：业务用例

业务用例（business use case）是定义了一组业务用例实例。业务用例具有名称。

      业务用例实例（business use case instance）是在业务中执行的一系列动作，这些动作为业务的个体主角产生具有可见价值的结果。 
 
      业务流程被定义为数个不同的业务用例，其中每个业务用例都代表业务中某个特定的工作流程。业务用例确定了执行业务时将要发生的事情；它描述了一系列动作的执行，而这些动作会产生对特定业务主角具有价值的结果。业务流程为业务产生价值或降低业务的成本。

游客 (Passenger) 可以独自旅行，也可以随旅游团 (Tour Guide) 旅行。随旅游团旅行时，游客将由导游带领。

      业务用例描述了“在业务中执行的一系列动作，这些动作为业务的个体主角产生具有可见价值的结果”。因此，从个体主角的角度看，业务用例确定了一个能够产生期望结果的完整工作流程。这与我们常说的“业务流程”很相似，但是“业务用例”有更精确的定义。

      业务用例概念的定义包含了许多对理解业务用例十分重要的关键字：

      业务用例实例 - 上面定义的实际上是一个特定的业务工作流程，即一个实例。实际上，存在大量可能的工作流程，而且它们中有很多是非常相似的。
为了使业务用例模型易于理解，可以将类似的工作流程组成一个业务用例（按照对象模型的话来说就是一个“类”）。确定和描述业务用例是指确定和描述具有类特征的业务用例，而不是单个用例实例。

      个体主角-主角可能是找到正确的业务用例的关键。从个体主角开始（实际上是从主角实例开始），可以帮助我们避免太大或太复杂的业务用例。
确定合适的主角时，首先指定至少两三个能担任所讨论主角的人，然后严格评估每个人需要什么样的支持。例如，假定您最初确定了一个名为“客户”的主角。而后，随着您仔细考查每个客户所需的支持，可能发现三种不同的客户：产品的一般“用户”、“采购员”和“评估员”，他们能够将产品与其他同类产品进行比较。每种客户都需要一个单独的业务用例，因为它们代表了作用于业务的不同角色。

      具有可见价值的结果 - 该表达对于确定正确的业务用例范围非常重要，这个范围不能太小，也不能太大。规定业务用例应该给出一个具有可见价值的结果（即可以感觉到而且可以进行评测），这可以帮助您找到完整的流程，同时防止业务用例太小。
      一个好的业务用例可以帮助主角执行具有可确定价值的任务。它可能会为成功执行的业务用例确定一个价格。一个太小的业务用例由于范围有限，导致进行重建的可能性较小。

      在业务中 -“在业务中执行的动作”意味着业务向主角提供业务用例，同时业务用例只包含那些业务中实际执行的动作。其他地方进行的支持工作并不包含在内。

      动作 - 动作由主角对业务发出的请求调用，或者在某个特定时间调用。动作包括内部活动和决策，以及对被调用的主角或其他主角的请求。

      业务服务通过不同的业务用例来描述，每个业务用例都有自己的任务。这些业务用例的集合组成使用业务的所有可能的方法。另请参见指南：业务用例模型。

一、业务用例与业务用例实现

      在受用例驱动的业务建模项目中，您将制作业务的两个视图。

      业务用例本身展示了业务的外部视图，它确定了业务为了向主角交付期望结果，关键要执行什么。同时还确定了执行业务用例时，业务与主角之间需要进行哪些交互。必须在确定并同意每个业务用例的工作时制作该视图。这一系列业务用例描述了业务的概貌，对雇员了解执行业务的哪些不同部分以及所期望的结果十分有用。

      另一方面，业务用例实现给出了业务用例的内部视图，它确定了如何组织和执行工作来获得期望的结果。实现中包含了业务角色和业务实体，它们涉及业务用例的执行，以及进行该工作所需的业务角色和业务实体之间的关系。必须制作该视图，以便确定并同意为获得期望的结果，如何在每个业务用例中组织工作。

      两种业务用例视图面向的主要对象都是业务中的人员 - 外部视图供业务用例外的人员使用，而内部视图则供业务用例内的人员使用。

二、类和业务用例实例

      随着业务的进行，您将发现可以确定的单独工作流程的数目几乎是无限的。一个用例实例只是一个特定的工作流程（即场景）。它对应着（由大量协作的业务成员按照对象模型中所定义的角色来执行的）工作，而不是某个特定的业务成员，也不是成员所担当的角色。

      业务用例通常用来使用例模型易于理解，同时避免过多的细节。它代表一组业务用例实例，这些业务用例实例具有类似但不完全相同的工作流程。

      通常，某个能担当特定角色的雇员会在多个不同的业务用例实例中发挥作用。

      示例：
      在机场登记处，个人登记 (Individual Check-in) 和团体登记 (Group Check-in) 两个业务用例对登记处雇员的工作能力有相同的要求，而且两个业务用例访问相同的起飞信息。因此，两个用例可以而且应该使用同一个登记处服务人员 (Check-in Agent) 角色和起飞 (Departure) 实体。

三、业务用例的范围

      有时，我们很难确定一项服务是一个业务用例还是多个业务用例。在机场登记流程中应用业务用例的定义。一个旅客将机票和行李交给登记处服务人员，他为旅客找到一个座位，然后打印登机牌并开始处理行李。如果旅客携带的是普通行李，登记处服务人员将打印行李标签和旅客行李领取牌，在行李上贴好行李标签，最后将行李领取牌和登机牌一起交给旅客，从而完成该业务用例。如果行李形状或所装东西比较特殊，不能按普通行李运输，则旅客必须将行李送往特殊行李台。如果行李过重，旅客必须去机场票务处交纳费用，因为登记处服务人员不负责收取费用。

      您是否要为登记处、特殊行李台和票务处各设一个业务用例呢？或者您只需要一个业务用例？的确，该处理过程涉及三种不同的操作。但问题是，是否每个操作对携带特殊行李的旅客都是有意义的？当然不是，只有整个过程（从旅客到达登记处直到他补交完行李超重费）对旅客来说才是有意义的。所以，涉及三个不同柜台的整个过程才是一次完整的使用，即一个业务用例。

      除了这个标准之外，另一个实用的方法就是将密切相关服务的说明放在一起，这样您可以同时对它们进行复审、修改和测试，为它们编写手册，并将它们作为一个单元来管理。

      值得注意的是两个独立的业务用例可能有相似的开始。

      示例：
      在保险公司中，业务用例“索赔处理”和“申保处理”都以某人 (主角) 与申请处理员的联系开始。申请处理员和主角交换信息，确定对方需要赔偿还是保险咨询。然后，也只有在此时，才可以确定应该执行哪个业务用例。尽管两个业务用例有相似的开始，但它们之间却是相互独立的。

四、名称

      业务用例的名称应该能够描述执行业务用例实例时所发生的情况。因此，名称的形式应该是主动的，通常使用动词的动名词形式 (Checking-in) 或同时使用动词和名词。

      名称也可以从外部或内部的角度来描述业务用例中的活动，如“订购”和“收到订单”。尽管业务用例描述业务中发生的事情，但它常会很自然地从主要主角的角度来命名业务用例。一旦确定了要使用的命名方法，就要在业务模型中对所有业务用例遵循同样的规则。

五、目标

      业务用例的目标应该至少从两方面来说明：

      为那些与业务流程交互的业务主角指定它们期望业务能实现的价值（外部目标）。 
      从使用业务流程的组织的角度，明确开发该业务流程的目的是什么以及希望通过该流程达到什么目标（内部目标）。 

六、性能目标

      最常用的分类指标是：

      时间 - 执行工作流程或部分工作流程大致需要的时间。 
      成本 - 执行工作流程或部分工作流程大致需要的成本。 

      困难的是理解哪些场景（业务用例实例）与评测有关。判断的标准可以是场景使用的频率，或场景的业务相关性。如果能确定工作流程中的重要部分，您只要评测这个分支流的成本或时间就可以了，这样可以减少许多工作量。

七、工作流程 - 结构

      大多数工作流程可以看作是由多个分支流组成的，这些分支流共同组成了整个流程。有时候，业务中多个业务用例会有共同的分支流，或是同一个分支流出现在一个业务用例的不同部分。如果这种共同行为出现的情况较频繁，则应该由同一个角色来执行。

      如果某个分支流具有实质内容，为多个业务用例公用并且形成一个自然定界的独立部分，那么应该将该行为分离出来，作为一个独立的业务用例，这样会使模型更加清晰。这时，这个新的业务用例要么包含于原始用例（请参见指南：业务用例模型中的包含关系）或是原始用例的扩展（请参见指南：业务用例模型中的扩展关系），要么是原始用例的父用例（请参见指南：业务用例模型中的用例泛化关系）。

      示例：
      在机场登记处，个人登记和团体登记两个业务用例使用同一个过程来处理个人旅客的行李。因为此分支流独立于机票处理，而且在逻辑上是联系在一起的，所以此分支流在行李处理 (Baggage Handling) 业务用例中被单独建模。

      可以使用活动图以可视化方式表示业务用例的工作流程，请参见指南：业务用例模型中的活动图。

      有关构建和描述业务用例工作流程的详细信息，请参见指南：用例中关于“事件流”的讨论。

八、工作流程 - 示例

      某组织向单个客户销售专门配置的解决方案，以下是对其“投标流程”业务用例中工作流程的描述。在指南：业务用例模型中的活动图的“使用示例”一节中，您可以找到一个活动图示例，该图以可视化的方式显示了此工作流程的结构：

1. 基本工作流程

      1.1. 最初接触

      此流程从客户和公司之间的最初接触开始。最初接触可能采取以下方式之一：

      客户与公司联系，提出询问或一系列需求。
      公司确定自己的产品能为客户创造价值，同时为公司创收。
 
      公司与客户联系以确定：

      客户联系人，
      公司联系人，
      该客户是否是公司的新客户，
      所有围绕此协议的有关投标的竞争信息。

      1.2. 最初机会工作

      这部分工作有两个主要目的：

      搜集客户需求，
      决定针对此机会的进一步行动。
      初步搜集客户需求、制定销售计划（可选）、进行机会分析各步骤可以按迭代方式进行，有时也可以稍做并行。

      1.2.1 初步搜集客户需求

      搜集产品需求和客户业务需求，方法如下：

      询问客户
      考虑所有客户输入
      进行初步的现场调查（可选）
      研究一切可用的客户信息

      一整套需求应该包括：

      技术选择（如果客户希望研究多种备选方案，则可能有多个选择）
      所有产品首选项
      功能性需求（市场分析）
      构建结构和环境特征
      人数统计
      机动性/容量
      网络增长预测
      确定的基础信息
      时间线
      服务需求
      价格需求

      1.2.2 制定销售计划（可选）

      公司与客户合作，确定如何提出一个满足客户需求的解决方案。制定销售计划，其中包括潜在解决方案的当前网络和转换特征。还要讨论公司的战略定位和其网络情况，这样我们可以为满足进一步的需要作准备。
然后，同客户一起对此销售计划进行复审，保证它精确完整。该计划将在整个投标流程中发挥指导作用，帮助确定要建议的产品、市场包装或货品明细分类项，以及整理标书所要进行的假设。

      1.2.3 进行机会分析

      公司将获得有关潜在解决方案高水平价位及成本的信息。这样做是为了了解此机会的潜在价值，而不是为客户提供一个精确的报价。
随后公司考虑客户需求，以确定：

      机会中的风险（产品可用性、竞争、客户风险）
      成本和收入的比较
      机会类型（简单、复杂等）
      销售的可能性
      大概的销售量数字
      大概的时间表
 
      根据这些估计，公司就是否继续此机会作出决策。

      1.3. 制定投标项目计划

      公司将制定一个计划，来制定并提交标书。计划中应包括投标中各部分工作的分配情况。

      1.4. 制定交付项目计划

      根据以下信息，公司将制定一个交付解决方案的暂定项目计划：

      客户需求中的最后期限
      资源可用性
      生产能力
      新产品的可用性
      第三方产品的可用性
      此项目计划将用于制定未来的生产计划。

      另外，此项目计划将在“报价流程”进行更新和修改。

      1.5. 准备报价

      该步骤在业务用例“报价流程”中有详细说明。
“报价流程”结束时应有一个设计好的解决方案。该方案可能具有不同程度的确定性，而且要提供价格。

      1.6. 编辑其他信息

      公司编辑信息来回答客户的所有询问（这些询问通常牵涉到未来的产品开发，它们可能是客户业务需求的一部分）。这些信息还包括公司认为客户应该了解的信息。询问通常分为以下几类：

      技术
      当前的性能
      未来的性能
      符合标准
      符合未来的标准
      当前提供的服务
      未来将提供的服务。
 
      1.7. 分析并完成标书

      公司编辑完成标书，其中包括以下信息：

      报价
      现成的市场材料（已有）
      产品信息（已有）
      财务条款
      进度信息
      按标书要求水平进行财务分析汇总
      客户与公司各自的责任和处罚
      法律“环境”声明
      制定标书中的解决方案时所作的所有假设
      公司将这些信息编辑为可呈交给客户的标书。

      1.8. 呈交标书

      公司向客户提交或提出以上信息。

      1.9. 获得客户决策信息

      客户将对标书进行反馈。公司获得客户对标书中报价的认可。根据客户和解决方案特点的不同，这种认可可以有多种不同的形式。
可能是：

      一份正式签署的购货订单
      一个客户将发出购货订单的口头协定
      一个正式签署的合同
      一个口头协定

      如果在有效期内未作出任何决定，则视为拒绝

2. 备选工作流程

      2.1. 放弃商机

      在 1.2. 中，如果放弃商机，则可以采取以下措施：

      完全放弃
      尝试与其他供应商合作
      重新定向到其他领域
      将请求转发给其他经销商/供应商
      尝试改变客户需求
 
      2.2. 无法满足客户需求

      如果在进行机会分析或报价准备的过程中，公司不能针对客户的需求提出解决方案，那么可能要采取以下措施：

      建议使用另一家厂商的设备
      重新评估客户需求
      与公司联系以获得有关未来产品的信息
      尝试改变客户需求
      决定开发新产品
      寻求合资伙伴或供应商
      寻求其他融资方式
      采用不同的折扣方式

      2.3. 关键信息未知

      如果在“投标流程”中公司发现某些关键信息未知或无法得到，可采取以下措施：

      获得此信息
      作出假设，然后继续

      如果进行了假设，则必须对假设进行记录并作为标书的附带文档交给客户。

      2.4. 新的、不完整的或不正确的一般客户简档

      如果公司认为一般客户简档由于某些原因而不准确，则可采取以下措施：

      如果是新客户，则与之协商达成一致
      包含/确定客户偏好
      确定已安装的信息库
      请求对记录进行更新

九、可能性

      业务用例的可能性应反映出业务用例在流程和规模方面进行改进的潜力。参考您指定的业务用例指标。

十、扩展点

      扩展点使业务用例有进行扩展的可能。它有一个名称，以及一组对业务用例的工作流程中一个或多个位置的引用。

      另请参见指南：业务用例模型中的扩展关系。

十一、好的业务用例的特征

      其名称和简要说明清晰易懂，甚至对业务建模团队之外的人来说也是如此。
      从外部（即主角的）角度看，每个业务用例都是完整的。例如，保险公司的“索赔处理”业务用例以一个客户提交索赔请求开始。如果不包含保险公司向客户发出有关索赔请求处理决定的通知或（在同意赔偿的情况下）保险赔偿的支付，则“索赔处理”业务用例是不完整的。
      每个业务用例一般至少涉及一个主角。业务用例由主角启动，通过与主角进行交互来完成活动并交付结果。
      支持用例可能不与主角进行交互，不过这种情况不太常见。如果业务用例由某个内部事件启动，并且不必和主角进行交互即可完成活动，则可能出现上述情况。

十二、好的工作流程说明的特征
 
      说明必须清晰易懂，甚至对业务建模团队之外的人来说也是如此。
      对工作流程进行描述，而不是仅仅描述业务用例的目的。
      只对业务内部的活动进行描述。
      描述业务用例中所有可能的活动。例如，满足或不满足某个条件将分别出现什么情况。
      不提及那些与其没有通信的主角。如果提及了其他主角，将使说明更加难于理解和维护。
      只描述属于本工作流程的活动，不涉及在其他并行的业务用例中进行的活动。
      不提及无关的业务用例。如果业务用例要求在业务开始之前某种结果必须存在于业务中，则应该将其作为前置条件进行描述。但对前置条件的描述不应该涉及产生此结果的业务用例。
      如果业务用例中活动的顺序不固定，说明中应该指出这一点。
      有结构地进行说明，这样易于阅读和理解。
      说明清晰地描述了工作流程的开始和结束。
      清楚地说明每个扩展关系，这样插入业务用例的方式和时间将显而易见。

十三、好的抽象业务用例的特征

      具有实质性。请记住，具体业务用例与其抽象业务用例必须易于理解。因此，一个抽象业务用例不应该太小。如果某个抽象业务用例不具有实质性，您应该将其删去，而其活动应在受影响的具体业务用例中进行说明。
      它包含逻辑上相关的活动。
      它为某个特定原因而存在。一个抽象业务用例应该包含以下三类活动中的任意一类：多个业务用例中共用的活动；可选的活动；或那些非常重要、要在模型中强调的活动。