使用 UML 进行有效的业务建模：: 描述业务用例和实现

就像大多数的软件开发从业者所知道的那样，统一建模语言 （UML）在表示真实世界的现象方面是非常优秀的。这种能力导致了 Business Modeling Profile 的发展，UML Business Modeling Profile 提供了扩展和原型以使用户和分析人员之间的交流更加容易。

<!--start RESERVED FOR FUTURE USE INCLUDE FILES--><!-- include java script once we verify teams wants to use this and it will work on dbcs and cyrillic characters --><!--end RESERVED FOR FUTURE USE INCLUDE FILES-->

正考虑应用 Business Modeling Profile 的组织通常都会有一些实际的问题，比如下面的问题：

• 在什么时候我们真正需要一个业务模型？什么时候只需要用例模型就足够了？
• 对于特定的业务建模情景，我们应该使用哪一种 UML 图？例如，我如何知道应该使时序图还是使用协作图？
• UML 业务模型使如何与其他 UML 模型（领域模型、用例模型等等）相关联的？我应该所＝如何组织这些模型呢？

识别业务参与者（Actor） 为系统建模识别参与者是容易的 － 任何系统外部的事物都是一个参与者，并且边缘十分清晰，因此人总是参与者。对于业务建模来说就不是那么简单的，因为一个人既可以是一个业务参与者（比如，一个与业务交互的外部人员）也可以是一个业务执行者（比如，一个业务内部的人员）。关于这个问题的一个方法是在将他们分类成为业务参与者或者业务执行者之前识别出与业务场景相关的所有人员。这意味着你必须在同一抽象级别上定义业务参与者和业务执行者：他们都是人或者人的群体。 不要尽力的将任何系统都定义成为业务参与者，虽然在你挖掘系统用例时一些系统将成为参与者。在业务建模中，你希望将注意力集中在业务流程上，因此将系统问题的处理推迟到以后来做可以避免使业务用例模型混乱。 在我们的业务用例模型调查中，业务参与者是人，而不是人的群体；也就是说，我们有一个最终用户的经理 ，而不是一个最终用户的部门，还有一个供应商经理，而不是一个供应商。这样在我们以后实现业务用例时，业务参与者和业务执行者是在同一抽象级别的。为了确定一个业务用例的范围，通常我们在类似表 1 中的某一个单独的工作流程中跟踪一个核心的圆舞曲目标。如果被获得的用例太长，我将细化核心的业务目标成为多个子目标，并将工作流程相应的分段，同时将一个长的工作流程水平的划分成几个业务用例。

不幸的是，关注于这些问题和应用 UML 业务建模 Profile 的文献资料比系统建模的资料相对来说少的多。这使那些认同使用 UML 进行业务建模的用户和分析人员十分失望，但是他们还是被迫的去努力使用这些符号。

本文通过了解一个样例用例来说明大家所关系的事情，这个样例用例建模了一个负责管理外包开发的 IT 部分的采购流程。这个由法律顾问、企业架构师和项目经理构成的部门负责和约的、系统架构的和项目管理的问题。这个部门的任务是将最终用户部分从 IT 相关的问题中解放出来，以便他们能够将经理放在业务运作上。当这些部门需要采购新的系统或者改进已有的系统时，他们会让 IT 部门准备最初的说明书，然后 IT 部门选择合适的供应商交付被需要的系统。

我们这个讨论的假设基础

我们假设你对 Rational 统一过程（RUP）中描述的业务建模 Profile 的知识有一定的了解。如果你对这个 Profile 还不是很熟悉，请参考文章尾部的附录。

进行一个业务用例模型调查

我们这个简单例子的第一部时完成一个业务用例模型调查。

如图 1 所示，存在两个参与者和两个用例。最终用户 Manager 想要一个供应商来自动化一些工作流程，因此 IT 部门通过准备最初的需求文档和包含几个候选供应商的方式来帮助业务部门。一旦和约敲定，采购部门将通过根据和约中的里程碑管理系统的交付来帮助最终用户 Manager 。

图 1: 业务用例模型

我们将业务用例总结如下：

• 准备 Tender：描述准备系统说明的流程。
• 选择供应商：描述供应商选择的流程，从 tender 的批准到与一个供应商签订能够在合理的成本和时间计划内满足需求的和约。

我们将业务用例总结如下：

• 最终用户方面的经理 ：要求自动化工作流程的最终用户部门的联系人。
• 供应商方面的经理 ：供应商一方的代表，负责合同投标和系统实施的监控。

表 1 ：很长的工程流程

当最终用户的部门要求一个额外的自动化以改进业务运作时，业务用例就开始了。这个用例的目标是选择一个能够交付最终用户部门期望的系统的供应商。

1. 最终用户的经理选派。采购部门为整个采购过程指派一名最终用户的经理。

2. 准备需求系统说明。最终用户的经理准备并向 IT 部门提交需求系统说明。

3. 准备 Tender 文档。IT 部门检查被提交的需求说明并准备一份 tender 文档，增加一些和约性的需求说明。

4. Tender 文档的批准。最终用户的经理检查并批准 tender 文档。

5. 公开 Tender 。一旦 Tender 文档被批准， IT 部门将它送到一系列指定系统分类的供应商。

6. 准备投标。每个供应商准备一份投标估计成本和项目交付计划，并提交给 IT 部门。

7. 缩小投标范围。在招标期间的末期， IT 部门根据估计成本和交付计划的可行性缩小候选投标商（供应商）的范围。

8. 选择供应商。从缩小的供应商列表中，最终用户经理选择最合适的一个。

9. 准备和约。 IT 部门与被选中的供应商准备一份和约。

10. 签署和约。最终用户经理和被选中的供应商签署和约，并开始更详细的系统计划和设计。

在我们的例子中，采购一个新系统的核心业务目标是将目标分解成两个子目标。

• 说明将要采购的系统。
• 选择并评估一个候选供应商。

因此，准备 Tender 业务用例包括了表 1 中的步骤 1 到 步骤 4，选择供应商业务用例包括了表 1 中的步骤 5 到 步骤 10 。有很多方法可以分割工作流程，与客户讨论选择是重要的。然而，明白业务建模的真正价值在于理解被分解的工作流程之间是如何关联的是十分重要的。

进行业务用例说明

在这个部分，我们来看一下如何描述业务用例。RUP 中的业务用例模板由一些部分组成，但是我们将只关注在基本的和可选的工作流程上。我将在未来的文章中讨论其他的部分 － 包括目标、风险、职责等等。表 2 显示了为准备 Tender 业务用例的基本和可选的工作流程。

表 2: 业务用例说明

准备 Tender 的基本工作流程

当最终用户部门要求额外的自动化以改进业务运作时，这个业务用例就开始了。目标是将能够分发给候选供应商的 tender 文档最终定稿。

1. 最终用户的经理选派。采购部门为整个采购过程指派一名最终用户的经理。 2. 准备需求系统说明。最终用户的经理准备并向 IT 部门提交需求系统说明。 3. 准备 Tender 文档。IT 部门检查被提交的需求说明并准备一份 tender 文档，增加一些和约性的需求说明。 4. Tender 文档的批准。最终用户的经理检查并批准 tender 文档。

可选工作流程

1. 系统说明无效。在步骤 3 ，如果 IT 部门发现系统的说明是含糊不清或者是不可行的，最终用户经理需要重新指定系统的说明。步骤 2 的业务用例也要重新开始，或者如果最终用户经理不希望继续的话，将中止整个过程。

2. 系统已经存在。在步骤 3 中，如果 IT 部门发现最终用户部门需要的系统与在另一个部门中已有的系统非常的相似，那么 IT 部门将让最终用户经理参考那个部门的系统。如果最终用户经理希望继续采购“新的”系统，他或者她必须在系统的说明中指出不同的特性，重新提交系统说明，并继续步骤 2 。如果最终用户在＝经理不希望继续，业务用例中止。

3. Tender 文档不一致。在步骤 4 中，如果最终用户经理注意到在 Tender 文档中的不一致，这个 Tender 文档将被拒绝，并且 IT 部门必须重新制作它。业务用例在步骤 3 处继续。

业务用例的实现

在这个部分，我们将讨论几个实现业务用例的方法：

基本和可选的工作流程 一个业务用例描述了一个业务执行活动的顺序以生成对特定业务参与者有价值的观察结果。在用例开始前识别出初始的条件是重要的 － 也包括用例的目标。基本工作流程应该文档化从初始条件直接到达最终目标的步骤。从基本工作流程出发，集中的集体讨论在每一步也许会出现的不同情况，并将他们文档化为可选工作流程。 在会面期间，客户常常描述很多可能的情况，这个可能会使分析人员的思想变得混乱，并且将分析人员的注意力从文档化主要的工作流程中转移。为了避免这种情况，分析人员能够在一个“停车场”中文档化这些可选的情景，（例如，对于将来的参考和讨论的一个临时但又明显的位置，象白板的以角），在基本工作流程上专心的工作。然后，当到了识别可选工作流程时，他能够从“停车场”中的文档中简单的挑出需要的文档。 作为流程定式的说明 业务用例说明描述了业务外部的视图，相反业务用例实现则描述了业务内部的视图。但是对于业务流程分析人员来说定义什么是“内部的”和什么是“外部的”通常不是很容易的。你总是仅仅描述业务参与者与业务之间的交互吗？，或者你进入到业务本身内部运作的细节了吗？这是用例社区中经典的“设计需求”方面的争论：什么时候需求是实际意义上的需求？什么时候需求应该转化成设计？ 我所说的是，如果很难区别什么是内部的和什么是外部的，为什么不使用业务用例说明来从什么能够被重新设计中辨别过程定式（固定的元素）呢？然后，你能够在你的业务用例实现中文档化一个被选中的过程定式，并且在业务用例说明中的“可能的事情”部分列出其他的选项。

• 关注工作流程。
• 关注流程自动化。
• 关注信息流程

接下来的子部分描述了每种方法的好处，和这些方法是如何互相补充的。

关注工作流程

我们将看一下业务用例实现，它关注在包括业务执行者和他们的职责的工作流程上。如图 2 所示，准备 Tender 业务用例有三个业务执行者。

• IT 项目经理：与最终用户经理的主要联系点。
• 企业架构师：通过确保被采购的系统能够满足组织的标准以降低系统集成的复杂度来帮助 IT 项目经理。
• 法律官员： 通过补充和检查在 tender 内的合同条款来帮助 IT 项目经理。

图 2: 业务执行者 － 准备 Tender

一个时序图描述了准备 Tender 业务用例的基本工作流程的实现，如图 3 所示。

图 3: 准备 Tender （关注工作流程）的业务用例实现

在图 3 中的消息能够被映射到每一个业务执行者的职责上，如图 4 所示。这种技术非常类似于指导用例分析的技术，这恰恰是为什么 RUP 的业务建模技术是如此强大的原因：相同的技术能够被应用到业务建模和系统建模上。

图 4: 业务参与者和业务执行者参与业务的视图

事件/动作与职责/活动之间的区别

在业务用例实现中，在消息和操作中使用动词如“准备”和“检查”，并且避免如“提交”、“批准”和“拒绝”等等的动词是最好的。这样我们就能够区分事件/动作与职责/活动之间差别。否则，我们就会范类似于图 5 中的错误。

图 5: 错误：事件和职责有同样的名字

假设最终用户发送了一个消息 － “提交系统说明” － 给 IT 部门的经理，如图 5 左侧所示。这意味着 IT 项目经理有责任“提交系统说明”，但是这显然是错误的。最终用户的经理应该做这个事情。如果我们使用一个如图 6 所示的从最终用户经理到到它自身的反身消息“提交系统说明”，情况仍然是糟糕的。图 6 没有显示最终用户经理必须要“提交系统说明”。

关注业务参与者和业务执行者 理解业务参与者和业务执行者的职责是需求引出的非常重要的方面，因为我们想构建正确的系统来满足他们的需要并在他们的业务环境中高效的业务运作。 通常分析人员在没有考虑真实的问题、没有对真正的需求进行好的理解或者没有在一些业务上下文中放入需求的情况下就直接跳到了系统说明中。这通常会导致需求的变更。因此，在首次尝试实现业务用例时有意的关注业务参与者和业务执行者的职责是非常重要的。我强烈建议完全首次的尝试一定不要包括任何系统做什么的考虑，尤其是一些遗留系统被包括的情况，因为这样存在“忘记”那些系统在业务中应该具有的职责的倾向。当这种情况发生时，人们也会忘记询问关键的业务流程和在旧系统中隐藏的规则，并且会忘记在新的业务环境中仔细的检查他们。 也要注意，不论是业务远景文档还是远景文档都需要有对客户、用户和系统涉众职责的描述。 一旦你理解了各种角色的职责，识别出他们中的哪一些是耗时间的，哪一些是资源密集的，或者有错误倾向的 ，在哪里自动化能够创造最大的价值。在我的前一篇发表在 Rational Edge 的文章 ”Business Process Simulation with UML“ 中，描述了如何使用模拟从数量上估计不同的自动化选择。

图 6: 错误：反身消息不能指明谁收到了系统说明

被推荐的方案是在图 3 中使用消息 2 。子任务指明了系统说明准备额完成。此外，消息 2 的方向也表明了系统说明被最终用户经理提交给 IT 项目经理。

图 7 显示了对于一个直接的”提交系统说明“活动的一个相似的错误。被推荐的方案被显示在图 8 中；子任务是一个引发从”准备系统说明“向”准备 Tender 文档“转移的事件或者动作。这样做是更加简明；注意图 8 仅有两个活动而不象在图 7 中的 3 个。

图 7: 错误：最终用户经理既拥有活动也拥有动作

图 8: 方案：创建一个包含引发转移的动作的子任务

将注意力放在过程自动化上

现在我们准备探究业务参与者或者业务执行者的职责自动化 － 特别是他们什么时候和如何使用业务系统。在我们的例子中，我们有两个业务系统，入图 9 所示：

• Tender 管理系统 (TMS)：一个为准备 tenders 和选择供应商被开发的新系统。
• 和约管理系统(CMS)：一个跟踪已有和约的现有系统。

图 9: 对于准备 Tender 用例的业务系统

RUP 中的业务对象模型指南建议了定义一个新的原型图标的可能性。在本文中我们将为业务系统使用 ”Business Worker“ 图标，但是他们将在新的 UML 业务建模 Profile 中有一个新的图标。注意，不管用何种方法，我们的业务系统的概念要严格的于在新的 Profile 中相同。

图 10 显示了一个用来描述准备 Tender 业务用例的基本流程实现的时序图，包括了被要求的业务系统。

图 10: 业务用例实现 － 自动化准备 Tender 用例

在图 10 中的消息能够根据每一个业务执行者的职责进行映射，如图 11 所示。

图 11: 由业务参与者、执行者和系统构成的视图

图 11 中的类图显示了 Tender 管理系统 (TMS) 的上下文关系。通过这个关系，我们表达了需要 TMS 服务的客户和对于操作 TMS 需要的供应者。这个上下文关系能够在用例图中用另一种形式表示，如图 12 所示。

图 12: 源自业务用例实现的 Tender 管理系统的用例

在图 12 中的用例的名字要严格的符合在图 11 中 TMS 的操作的名字。在图 12 中的参与者的名字要严格的符合在图 11 中的业务参与者和业务执行者的名字。使用相同的命名习惯有利于从业务对象模型到系统用例模型的跟踪。

探究自动化选择 在图 10 中的时序图阐明了 Tender 管理系统 (TMS) 是如何从法律官员隐藏和约管理系统(CMS)的。这是可能的系统开发场景之一，包括：

场景 1: 没有被集成的异构系统

场景 2:仅仅提供一个新的前端系统

场景 3: 集成

有多少个业务用例？ 总的来说，业务用例的数量应该比系统用例的数量要少。业务用例的实现包括了业务参与者和业务执行者的参与，者两者都将潜在的需要与系统进行交互，并且因此拥有他们自己的用例集合。通常情况下，业务用例对系统用例的比率应该在 1:5 到 1:10 之间。在我们的例子中，”准备 Tender“ 业务用例被用五个系统用例来表示，如图 12 。业务用例的价值在于它将用例放到了上下文关系中 － 显示一个业务用例组如何能够被实现以交付业务价值。 如果业务用例和系统用例的数量是可比的（比如， 1:1 到 1:3 的比率），我将提出对业务建模的要求。如果业务用例和系统用例的粒度是相似的，那么其中的一个类型就是多余的。

在场景 1 中，没有在 TMS 和 CMS 之间的集成，并且二者都被作为分离和独立的系统处理。对于法律官员的时序图被表示在图 13 中；注意法律官员要直接访问 CMS 。

图 13: 时序图 － 场景 1：没有集成的异构系统

对于源自图 13 中的 TMS 的用例图被在图 14 中进行了描述。注意 CMS 没有出现在图 14 中，因为它不和 TMS 进行交互。

图 14: 用例图：场景 1 ：没有集成的异构系统

在场景 2 中， TMS 提供了一个封装 CMS 功能的前端系统。对于法律官员活动的时序图被显示在图 15 中。这个方法的目标是为最终用户提供一个一致的外观。然而，在使用法律条款进行检查和补充 Tender 中，没有额外的功能来支持法律官员。

图 15: 时序图 － 场景 2 ：提供新的前端系统

对于源自图 15 的 TMS 的用例图被在图 16 中被描述。注意图 16 包含一个新的用例，”查找和约“，它与 CMS 交互。

图 16: 用例图 － 场景 2：提供新的前端系统

场景 3 被显示在图 10 的消息 4 中。 TMS 提供了一个 CMS 的前端，并且同时提供了方便法律官员用法律条款检查和补充 Tender 的额外功能。

消息能够映射到用例或流程上。在上面的讨论中，在时序图中的每一个消息被映射到一个用例。这意味着业务对象模型和用例模型一定是一致的 － 也就是说，用例是根据业务系统中的操作的名字命名的。这可能会太局限了，因为在很多的情况下，我们想要彼此独立的重构用例模型或者业务对象模型。然而，重构每一个模型都将使在两个模型之间的映射变得无效，我们希望维护一致性或者一些可跟踪的形式。我们能够通过允许一个消息被映射到每一个整体用例或者一个用例的一部分来实现这个目的，作为一个与消息语义相应的流程或者事件来支持这种映射。你可以在图 17 和 18 中看到他的表示。

图 17: 消息到用例的映射

图 18: 操作到用例的映射

关注信息流程

现在，让我们看一下关注与2信息流程的业务用例实现 － 也就是，业务实体如何被使用。我们的例子有几个业务实体，如图 19 ：

• 系统说明文档，描述系统的需求。它由最终用户经理最初开发出来，并通过 IT 项目经理被企业架构师来补充。
• Tender 文档，将被分发给候选的供应商作为一个准备投标的基础。它包括系统的说明和法律的条款。
• 法律条款，Tender 中的一个重要部分，定义了候选供应商必须履行的法律条款和条件。
• 和约，能够引用已有的相关和约，以便法律官员不必每一次都在和约中写法律条款。

图 19: 业务实体 － 准备 Tender 用例

一个时序图描述了准备 Tender 业务用例的基本流程实现（信息流程），如图 20 所示。

图 20: 业务用例实现 － 准备 Tender 用例信息流程（顺序）

相应的协作图描述了用例的实现（信息流程），如图 21 所示。

图 21: 业务用例实现 － 准备 tender 用例信息（协作）

在图 20 和 21 中的消息能够被映射到每一个业务实体的职责上，如图 22 所示。

图 22: 由业务参与者、执行者和实体组成的视图

注意，业务实体是被动的，并且不能触发与自身的交互。因此，在图 20 和 21 中的消息代表可业务参与者和业务执行者如何操作这些实体，或者是手工操作或者是通过自动化的工具操作（比如，Tender 系统或者和约管理系统）。在大多数的情况下，组织将有不止一个系统，因此一个单个的业务实体的职责可能被映射带多个体统的职责上。在图 20 中描述哪一个业务系统被用于操作哪一个业务实体将使图 20 变得与图 21 和 22 一样复杂。

当你进行用例分析时，你能够将描述被系统操作的实体推迟到活来进行。可选的，你可以有一个映射业务系统和业务实体的类图。图 22 能够通过仅显示参与的业务实体被简化，如图 23 。

图 23: 业务实体参与的视图 － 准备 tender 用例

图 23 也被作为领域视图被引用，并且所有的业务实体集合组成了领域模型。领域模型也描述了动态的行为，通常是通过状态转换图。除了显示不同业务实体之间的关系，显示单独的业务实体的状态也是重要的。状态图显示了能够在每一个业务实体上执行的操作。图 24 是 tender 文档的状态图。

图 24: Tender 文档的状态图

业务规则 在需求引出中的一个挑战是如何组织业务规则和确保他们的完整性。我通常识别并对业务规则组进行分类，因为遗漏一个业务规则组要比遗漏一个组中的规则更具有破坏性。一些可能的业务规则组的来源是： 在业务用例说明/实现中的可选流程。 在领域模型中的事件。 例如，在真北 tender 的业务用例说明中，我们有一个可选的流程 － A1：系统说明无效。这表明一个检查列表被需要来确定是否系统说明是真的无效。这个检查列表能够作为一个业务规则组被文档化。 在领域模型中的状态表突出了可能发生的不同事件（比如，图 24 ），事件能够被笔筒的条件出发或者保持。因此，根据事件对业务规则分组是简单自然的。 ”维护“用例 跨越”维护“类型的用例从业者经常会问：这些”维护“用例是从哪里来的，他们的业务目标是什么？在业务用例实现的每一个步骤中都有先决条件，这些条件能够被先前的步骤或被”维护“用例实现。例如，”查找和约“要求一些和约的存在作为前提条件。当在准备 Tender 业务用例中没有任何前提条件的创建一个和约，一个”维护“用例将被需要。对于”维护法律条款“用例没有需要，因为法律条款被作为”用法律图奥扩补充 Tender“步骤的一个部分被创建和更新。

在图 24 中，事件与 Tender 文档中的操作有相同的名字。Guard 条件（比如，在 UML 中被 "[" and "]" 界定的表达式）表示了操作的不同终止条件。例如，检查 Tender 文档操作有三个可能的终止条件，命名为：

• 可接受的
• 法律条款不可接受的
• 系统说明不可接受的

这些终止条件必须被在图 12 中被识别的”检查 Tender 文档“用例处理。被接受的 Tender 文档可以是用例的基础流程，其他两个条件可以是可选流程。从状态转换到用例的映射能够得自于从如图 25 。

一个被映射到用例得事件，看守条件被映射映射到用例得一个流程，并且动作代表了下面的看守条件发觉的步骤。

图 25: 从状态转换到用例的映射

这样，在图 24 中被准备的 Tender 文档的状态被一个用例处理：检查 Tender 文档，如表 3 。准备的 Tender 文档的状态有三个分支的转换，他们被映射带在＝基本流程的步骤 4 ，可选流程 A1 和 A2 上。

表 3: 检查 Tender 文档用例

基本流程

这个用例开始于最终用户经理被 IT 项目经理通知文档已经完成后，最终用户经理想要检查 tender 文档。

1. 列举 tender 文档。系统为最终用户返回并显示一个一个 tender 文档的总结列表，并显示他们的状态。

2. 打开 tender 文档。最终用户经理选择一个 tender 文档。系统返回并显示它。

3. 检查 tender 文档。最终用户奖励检查系统说明和法律条款。

4. Tender 文档接受。如果最终用户经理接受了内容，她或者他批准这个文档。系统记录决定，并且 IT 部门能够为招标到开 Tender。用例终止。

可选流程

1. 法律条款不可接受。如果在基本流程的步骤 3 最终用户经理发现法律条款不可接受，拒绝他们的原因被标注。系统通知 IT 项目经理和拒绝的法律官员。用例终止。

2. 系统说明不可接受。如果在基本流程的步骤 3 最终用户经理发现系统说明不可接受，拒绝他们的原因被标注。系统通知 IT 项目经理和拒绝的企业架构师。用例终止。

在表 3 中的可选流程处理Tender 文档的拒绝。在表 3 中的基本流程的步骤 1 中，系统显示tender文档的总结列表和他们的状态。这样，在业务模型中的状态图提供了一种详细描述以下方面用例的方法：

• 识别可选流程。
• 实体的列举状态被显示。

结论

软件系统被开发以达到业务目标。然而，用户、分析人员和开发人员通常生活在不同的世界里；他们有不同的看法并使用不同的行业术语。在这些人之间的沟通障碍导致了很多关于各种系统需求的解释和变更需求上的激烈讨论。通常，这些变化的发生不是应为最终用户改变他们的想法，而是因为最初的需求需要被澄清。

因此使用一种通用的符号系统（比如 UML）和通用的技术（UML 和 RUP 业务建模 Profile）是至关重要的，这些技术既可以描述业务流程也可以用于所有用户、分析人员和开发人员理解系统。这种被改进的沟通的确可以使软件工程项目更加成功。

在本文中，我们讨论了识别业务参与者和业务用例的步骤，并且使用三种方法描述了他们的实现，每一种都有不同的关注点（见表 4） 。

表 4: 描述业务用例实现的方法

关注点	目的	好处
工作流程	识别业务参与者和业务执行者的职责。	在不被系统或者信息描述分散注意力的情况下理解业务流程。 识别哪一个业务参与者和执行者和职责是耗时的、资源集中的，或者是对自动化需求的优先级划分的错误倾向。
流程自动化	识别在业务参与者或者执行者职责的支持中业务系统的职责。	理解业务系统是如何被业务参与者和执行者用作他们工作流程的部分。 便于系统用例的引出。
信息流程	识别被业务参与者和执行者使用的业务实体的操作。	理解业务实体之间的关系。 使系统用例的细化和确认更加容易。

附录: 业务建模简介

本文假设读者对 UML 有一定的了解，并对业务建模的 UML profile 有一些基本的理解。当前的用于业务建模的 UML profile 的简介在表 A-1 中。

表 A-1. 用于业务建模的 UML profile 的简介

原型	描述	UML 表示
业务用例模型	面向业务功能的模型。 被用作基本的输入来识别组织中的角色和交付产物。	模型，作为”业务用例模型“的原型
业务对象模型	描述业务用例实现的对象模型	模型，作为”业务对象模型“的原型
业务用例	一个定义了业务用例实例集合的类；每一个实例是一个业务执行的动作序列，业务产生一个对特定业务参与者有价值的结果。	用例，作为”业务用例“的原型
业务用例实现	描述一个特定的业务用例是如何根据协作的对象（业务执行者和业务实体的实例）在业务对象模型中被实现的。	协作，作为”业务用例实现“的原型
业务参与者	代表在业务环境中与业务相关的人或者事的角色。	参与者，作为”业务参与者“的原型
业务执行者	一个代表与系统交互的人的抽象的类。 与其他业务执行者交互，当参与业务用例实现时操作业务实体。	类，”业务执行者“的原型
业务实体	一个不能发起与自身交互的被动类。 可能会参与多个不同的业务用例实现。 在业务建模中，代表业务执行者访问、检查、操作、产生等的对象。 提供在不同的业务用例实现中业务执行者之间共享信息的基础。	类，作为”业务实体“的原型
组织单元	业务执行者、业务实体、关系、业务用例实现、图和其他组织单元的集合。 通过划分成更小的部分被用来结构化业务对象模型。	在业务对象模型中的包，作为”组织单元“的模型