构建业务用例

业务用例模型是由业务用例和主角构成的模型的主要目的是说明客户和合作伙伴是如何开展业务的。直接与客户或合作伙伴相关的活动以及与外部各方并不直接相关的支持和管理任务都可以在模型中给出。

建立业务用例模型有三个主要原因：

• 使业务用例更易于理解。
• 复用多个业务用例共享的部分工作流程。
• 使业务用例模型更易于维护。

我们有三种关系用于建立业务用例模型。使用这些关系，您可以将那些可以在其他业务用例中复用的、或者作为该业务用例的特化或选项的部分业务用例分离出来。我们将代表修改的业务用例称为附加用例。被修改的业务用例称为基本用例。

• 如果基本用例的某个部分代表一个功能，而业务用例只依赖于本功能的结果，而不是产生结果的方法，那么您可以将这部分分离出来，形成一个附加用例。使用包含关系，将附加部分明确包含于基本用例中。
• 如果基本用例的一部分是可选的，或对于理解该用例的主要目的来说不是必需的，那么您可以将这部分分离出来，形成一个附加用例，以简化基本用例的结构。利用扩展关系，将附加部分隐含地包含于基本用例中。
• 如果几个业务用例在行为和结构上具有共同点，同时在目的上又很相似，则可以将它们的共同部分分离出来，形成一个基本用例（父用例），该基本用例被附加用例（子用例）继承。子用例可以在从父用例继承的结构中插入新的行为或修改现有的行为。

• 为建模工作定界

  特别是当开发业务模型只是为了“支持”某个软件工程项目时，您需要细致地对业务建模工作进行定界。在这种情况下，即使只对业务流程的一部分进行建模，也几乎不值得涵盖整个组织。为了能突出重点并产生期望的结果，应该选择只将整个公司的一部分视为您的“业务系统”，而所选部分应该是公司中将直接使用该系统的部分。组织中决定作为模型外部对待的那部分则可以表示为业务主角。

• 调查说明

  业务用例模型的调查说明应该：

  • 概述组织的目的。
  • 指出模型的定界 - 模型中不包括的部分以及不包括的原因。
  • 指定主要业务用例。

  示例：

  业务用例模型覆盖我们公司管理客户订单的部分，因为只有这部分对软件工程项目有意义，它将使用业务建模的结果作为输入。出于这个原因，我们没有将公司中负责结账、生产、产品管理和产品开发的部门包括进来；这些部门作为模型的外部被表示为业务主角。

  在该组织中，一次销售不仅包括对某个解决方案达成一致，还包括对该解决方案的构建。为了给解决方案定价，您需要将其设计并构建到足够细化的程度。这就是在“投标流程”中所进行的工作。与客户达成一致之后，公司便开始设计解决方案的所有细节，然后在客户方进行安装。这就是在“订购流程”中所进行的工作。“投标流程”和“订购流程”都包括“报价流程”这个抽象业务用例。

  好的业务用例模型的特征

  • 用例符合它们所描述的业务。
  • 可以找到所有用例。合起来看，用例可以执行业务中的所有活动。
  • 业务中的每个活动都应包含在至少一个用例中。
  • 用例数量和用例大小之间应该保持平衡：

  • 较少的用例可以使模型易于理解。
  • 用例过多可能使模型理解起来比较困难。
  • 大用例可能十分复杂，理解起来比较困难。
  • 小用例通常易于理解。但是，一定要确保用例描述了一个完整的工作流程，该工作流程可以为客户产生某种有价值的结果。

  • 每个用例都必须是唯一的。如果工作流程与其他用例相同或相似，以后将很难保持它们的同步。 因此考虑将它们合并为一个用例。
  • 对用例模型的调查应该给出组织全面的情况。