| 本文内容包括:
就像大多数的软件开发从业者所知道的那样，统一建模语言 （UML）在表示真实世界的现象方面是非常优秀的。这种能力导致了 Business
Modeling Profile 的发展，UML Business Modeling Profile 提供了扩展和原型以使用户和分析人员之间的交流更加容易。
正考虑应用 Business Modeling Profile 的组织通常都会有一些实际的问题，比如下面的问题：
- 在什么时候我们真正需要一个业务模型？什么时候只需要用例模型就足够了？
- 对于特定的业务建模情景，我们应该使用哪一种 UML 图？例如，我如何知道应该使时序图还是使用协作图？
- UML 业务模型使如何与其他 UML 模型（领域模型、用例模型等等）相关联的？我应该所＝如何组织这些模型呢？
不幸的是，关注于这些问题和应用 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 没有显示最终用户经理必须要“提交系统说明”。
图 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 中，没有在 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 文档的状态图
在图 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 表示 |
| 业务用例模型 |
- 面向业务功能的模型。
- 被用作基本的输入来识别组织中的角色和交付产物。
|
模型，作为”业务用例模型“的原型 |
| 业务对象模型 |
|
模型，作为”业务对象模型“的原型 |
| 业务用例 |
- 一个定义了业务用例实例集合的类；每一个实例是一个业务执行的动作序列，业务产生一个对特定业务参与者有价值的结果。
|
用例，作为”业务用例“的原型 |
| 业务用例实现 |
- 描述一个特定的业务用例是如何根据协作的对象（业务执行者和业务实体的实例）在业务对象模型中被实现的。
|
协作，作为”业务用例实现“的原型 |
| 业务参与者 |
|
参与者，作为”业务参与者“的原型 |
| 业务执行者 |
- 一个代表与系统交互的人的抽象的类。
- 与其他业务执行者交互，当参与业务用例实现时操作业务实体。
|
类，”业务执行者“的原型 |
| 业务实体 |
- 一个不能发起与自身交互的被动类。
- 可能会参与多个不同的业务用例实现。
- 在业务建模中，代表业务执行者访问、检查、操作、产生等的对象。
- 提供在不同的业务用例实现中业务执行者之间共享信息的基础。
|
类，作为”业务实体“的原型 |
| 组织单元 |
- 业务执行者、业务实体、关系、业务用例实现、图和其他组织单元的集合。
- 通过划分成更小的部分被用来结构化业务对象模型。
|
在业务对象模型中的包，作为”组织单元“的模型 |
|
