怎样对客户进行UML业务建模

简单而言，客户就是准备购买或使用、或者已经购买或使用了一个组织（下称业务系统）的产品或服务的人。对于这个描述中，站在不同的角度，对客户的实质理解可能不同，而UML业务建模，则抓住了客户的这样一个实质含义：客户是站在这个业务系统的外部，和这个业务系统发生交互行为的对象。早期有专家把Actor翻译为"外部动作者"，虽然有些拗口，但意义非常精准。

为什么UML一定要站在交互行为的角度来看客户呢？这是因为一个客户的重复进行的行为能最清楚地表达客户的真实需求（即所谓肢体语言表达更丰富且真实），对客户和业务系统之间的交互行为的描述和记录，不但可以指引未来类似的过程重复进行，更本质的意义在于，这些交互行为，清楚地表达了客户和业务系统之间价值转移发生的全过程。

一个业务系统是必须是一个开放的系统，也就是说，它必须接受来自外部的刺激，这种刺激，包括物质，能量和信息的交换，才能驱动业务系统内部的要素持续地运转下去，否则，这个系统最终会走向沉寂。这就是一个企业没有外部的客户，没有供应商，没有水电供应，没有电信服务，这个企业就只能关门的内在道理。

如果从"外部动作者"这个本质的定义反过来寻找一个实际的业务系统的对应物，我们会发现，在一个业务系统外部，除了"客户"，还存在大量其他"外部动作者"，如：供应商、政府机构、行业协会、投资机构、甚至某些自动化的服务系统等等。围绕在一个实际业务系统的周围的"外部动作者"是多种类型，而且数量众多的。这些外部动作者，要么向业务系统提供服务，收取报偿；要么接受业务系统的服务，提供报偿，这就是业务系统的上、下游的价值链关系，这些价值链实际上就是靠外部动作者与业务系统的交互行为来建立和维持的。

从价值链的角度，我们就能理解"业务主角"这个名词的真实含义了，正是由于有这些系统外的"动作者"，怀有各自的目的，来到业务系统跟前，和业务系统进行一系列的交互行为，最终获得业务系统提供的服务，支付给业务系统报偿，即进行完价值交换后，扬长而去，这才使得业务系统找到自身存在的价值，所以，业务主角是主持业务系统生死攸关的外部角色，称其为"主"，是恰如其分的。

由于现在全球经济环境目前出现的状态是买方市场占优的状态，也就是说，是产品和服务过剩，需求不足的状况，对于所有的业务系统而言，谁能拥有和维持客户，谁就获得提供产品和服务的机会，谁就能够活下来，并长大，所以，流行"顾客是上帝"，"以客户为中心"的口号才盛行。在个别的局部环境下，存在卖方市场的状况时，则会出现"供应商是上帝"的局面。如果戴着UML业务建模的"有色眼镜"来看，不管是客户还是供应商，大家都是"业务主角"，都是业务系统的"上帝"。明眼人可能已经看出，单是从"业务主角"这个建模元素，我们已经可以体会到UML业务建模令人惊叹的抽象表达能力。

如何对服务项目进行UML业务建模

一个服务项目是一个业务系统对外提供的一项有价值的服务过程。每个组织或企业（业务系统）存在的理由都是因为它们能够对外界提供这些服务项目。

需要辨析的是，服务项目不是笼统的价值描述，而是对应确实可行的一系列的行为过程的指称，也就是说，提到一个服务项目的名称，我们就知道意味着可以启动执行的一个具体的事例。比如说，畅享网列举的主要服务如下：

1. 结识全球各地的管理、信息化、投融资等领域的人脉。
2. 发起、加入自己感兴趣的圈子，创建同好、校友、同事联络区，组织线上线下活动。
3. 发布、获取、讨论商业机会，招聘人才、获取工作，进行服务及物品的交易。
4. 在最早、最丰富、最权威的管理和信息化知识库里获取专业实用的理论研究、实践经验、案例探讨、解决方案、可用资源。
5. 同专业人士分享您在管理和信息化领域的思考、心得、经历、体验。
6. 第一时间获取业内知名企业、企业家、专家的新闻动态。
7. 创建个人博客，记录人生感悟、展示自我风采，用拖拉方式DIY博客，完全个性化。

其中谈到了很多畅享网可以提供的服务项目，也谈到了畅享网能提供的价值。如：同专业人士分享您在管理和信息化领域的思考、心得、经历、体验。就是对服务价值的描述，而创建个人博客，记录人生感悟、展示自我风采，用拖拉方式DIY博客，完全个性化。则是一个具体的服务项目。服务价值是通过提供服务项目来实现的。进行这样的区分是非常重要的，因为建模的关键之一就是要仔细辨识一些概念的微妙关系与区别，只有这样，我们才能真正认清事物的关键部分和本质部分。

UML业务建模正是通过对服务项目的建模来体现业务系统的价值的。UML使用"业务用例"（Business Usecase）一词来称呼服务项目。很多初学者对"用例"这个名字感觉很不习惯，为什么要取这么个怪名字呢？我想，主要还是为了突出服务项目的动态交互性和价值的明确性。

Usecase这个名字首先告诉我们这是一单Case，什么叫Case？Case就是当回事，当回事就是有开始、有过程、有结尾、有收获，还可以做了一回又做一回，即可重复。Use有两层含义：

1. 可用：说明这是一件可以操作的具体的事；
2. 有用：说明这是一项有价值的事。

UseCase合起来，就是"可用的和有用的事例"，简称"用例"，还是蛮讲得通的。Business UseCase 就是"业务系统提供的可用的和有用的事例"的意思了，其实，这不就是"服务项目"这个名称的含义吗？

我们常说，要做有用的人，要做有价值的企业。什么是有用的人，有价值的企业呢？有用的人，是通过这个人能做有用的几件事来体现的，有价值的企业，也是通过企业能提供有价值的服务来表现的。价值是人的根本需求，"用例"则是对实现和表达需求的肢体语言的描述，是一个过程。可以说，用户的需求是很少变化的，变化的是用户实现需求的过程。在对业务系统的分析中，发现业务需求与业务用例（业务价值与业务过程）的映射关系是非常重要的。我们通过表达业务系统可用和有用的事，就能间接地表达业务系统有什么价值。

为了说明需求与用例的关系，我再举一个简单的例子。

比如问，水果刀有什么用（价值）？

我们一般会马上回答：可以用来削皮，切开水果。

我们回答的实际上是"用水果刀能做什么事？"这个问题，得到了"削皮"和"切果"两个答案，也就是两个"用例"。

那么，真正的需求是什么呢？也就是"水果刀有什么用（价值）？"这个问题的真实答案应该是什么呢？应该是：1.使水果吃起来更卫生；2.使水果吃起来更方便。这才是真正的水果刀的价值。

我们可以看到，实现水果刀价值的过程，不一定只有"削皮"和"切果"这两个过程，也不一定只有水果刀能提供这些过程，比如削皮机，果汁机等都可以用不同或相同的过程来满足两项需求。用例是满足需求的过程，而需求则是过程背后所实现的价值。这正是UML用例建模的核心思想。

怎样对服务体系进行UML业务建模

我们知道，客户是从业务系统的外部启动并享用服务项目的人或机构，在现代供应链管理模式下，服务过程是客户驱动的，即，如果没有客户出现，服务项目的实例服务过程就不会被启动和执行，否则，我们就找不到"谁让你做这事的？"的答案，自然没有人愿意来为你的劳动买单。此外，客户可以分为很多类型，不同类型的客户，需要的服务项目可能有相同的部分，也可能有不同的部分。

从业务系统外部看来，一个业务系统对外提供的服务项目一般不是单一的，而是多项的，并且多个服务项目之间还存在一定的联系。这些服务项目之间的联系，也是客户所知道和所需要的，所谓"一条龙"服务，就是系统性地为客户提供全方位的服务，是最大限度地提高客户的满意度的，体系化的服务。

只有通过特定的客户和服务项目之间的联系，不同服务项目之间的联系，业务系统才能把不同类型的客户或供应商集结起来，这就构成了业务系统对外的服务体系。对于企业来说，只要能够对适当的客户群提供系统性的、体系化的服务，一般就都具备了长盛不衰的基础。

我们已经知道，对客户和供应商等业务系统外部的交互者，UML用"业务主角"的概念来建模，对业务系统对外提供的服务项目，UML用"业务用例"的概念来建模。对上述业务系统的对外服务体系，UML则运用了最基本的模型-"业务用例模型"来表达。

一个组织面对什么客户群，提供怎样的服务体系，是决定一个组织业务架构的基础。比如：供电局和环保局的业务架构就不同，学校和医院的业务架构也不同，商场和工厂的业务架构也不同，原因就是他们各自对外提供的服务体系是非常不同的。

UML业务用例模型用一个带箭头的线段来连接业务主角和业务用例，或连接一个业务用例到另一个业务用例。这样就把分散独立的业务主角和业务用例连接成了一个网络关系的图。也就是"业务用例图"。业务用例图是业务用例模型的图示化的表达，能清晰、完整细致地表现业务系统对外的服务体系。

这个带箭头的线段，用于连接业务主角和业务用例的时候，表达了如下的含义：

1. 这里有一个交互操作的过程，交互操作的发起者在线段的起始端，响应者则在箭头指向端；
2. 这里有一个服务价值转移的过程，服务的请求者、受益者和支付者在线段的起始端，服务的提供者、实现者和受酬者则在箭头的指向端。
3. 这里有一个信息流向的过程，在交互操作的过程中，虽然信息一般是双向流动的，但从总的信息流量和信息交换的主被动关系来看，接受信息多的一方往往也是被动交换信息的一方，因此，也是箭头指向的一方。

以上三层含义就分别表达了对外服务体系中的三层关系，即有形的操作交换关系以及无形的价值交换和信息交换关系。这三层关系组合结果，可能出现的情况如下：

1. 这三层的关系的方向指向在绝大多数情况下，可以认为是一致，不出现矛盾的情况，这种情况下，箭头方向选择没有任何疑问；
2. 在某些情况下，某层关系可能不明显和直接，但总有某一层关系是明显的；这时，箭头方向表达最明确的层次关系。
3. 当实际的三个表达层次出现矛盾的时候，则可以取最希望表达的层次来理解，这时，箭头方向的选择代表了建模者在特定场景下主观意图上对某个层次的重视。

当箭头线用于连接两个不同的业务用例的时候，表示在两个业务用例所表达的服务项目之间存在某种关联关系，可能的关系含义包括但不限于如下几种：

1. 箭头的起始端业务用例与其业务主角的关系，可以顺着箭头线，"传导"到箭头指向的业务用例。也就是说，箭头线起始端业务用例的主角，同样是箭头线指向端业务用例的主角。
2. 业务主角在享受一个服务项目的价值的过程中，一定会要享受另一个服务项目的价值；
3. 业务主角在享受一个服务项目的价值的基础上，还可以享受更多的别的具有衍生价值的项目服务；
4. 业务主角在享受一个服务项目之前，依赖于先前享受过另一个服务项目的服务；
5. 一项总的服务项目和组成这个总服务项目中的某个分项目；
6. 一种服务项目的操作模式和按这种操作模式实现的具体的服务项目；
7. 一个粗略的服务项目可具体化为一个精细的服务项目；
8. 一个服务项目的意图过程和实现这个意图过程的具体的服务项目。

用来表达以上多种业务用例关系的箭头线有不同的画法，为了能区分到底表达的是哪种用例的关系，可能在线的旁边用文字来标识，也可能用不同的箭头形状，线型表示不同的关系类型。详细的表达方法我们在讨论具体的用例关系表达时做专题讨论。

最后需要强调的是：业务用例模型只需要表达一个业务系统对外界的服务体系，不需要对业务系统内部的服务和协作关系进行表达。对于后者，UML业务建模会用"业务对象模型"这种更适合表达协作过程的模型来表达，这是UML业务建模的最基本的模型分工。这样分工带来的好处是：一方面可以让我们在建立业务用例模型的时候，把主要精力集中到要满足的客户业务需求上面来；另一方面使得模型的表达内外有别，内外呼应，使模型信息的组织更加具有系统性，并符合我们认识事物由远而进，由外向内的一般规律。

如何对客户体验进行UML业务建模

前面我们从业务系统的客户谈到服务项目，从服务项目谈到对外服务体系，可以说，这些是"站在离业务系统比较远一点的地方"看到的业务系统比较宏观的外部景象。如果我们再"走近"一点，但仍然保持是"站在业务系统外面"的观察点来仔细观察一个业务系统，那么，我们就会"看到"业务系统的客户是如何享受每一个服务项目的服务的，我们可以描述客户的详细的体验过程，这是发现和评价服务项目的价值最直接的办法。

UML通过事件流描述的办法来记录（设计）客户在服务项目上的交互过程。此时，我们需要把业务系统看成是一个"黑箱"，要想象客户与业务系统的交互过程发生在"黑箱"的某个对外开放的"窗口"上，这个窗口就代表一个服务项目，我们只能看到客户以及业务系统在这个窗口上所发生的全部事件，窗口里面所发生的一切，我们暂时不去细究。

这个"窗口"，实际上就是客户和业务系统进行交互活动的一个"界面"。UML事件流描述的方法从界面交互的细节为切入点，能抓住业务系统为了满足客户的体验需求而必须做出的所有活动，从而为下一步在设计业务系统内部运作过程时提供了目标每一个业务系统内部的活动都必须是以满足界面上必须表现的行为为目标的，而且每一个界面上所发生的业务系统的响应事件，都必需要有内部活动来支持。在"窗口"上所作的事件流记录，集中体现了以下重要的模型价值：

1. 对客户行为和业务系统的行为进行了耦合；
2. 对客户提供了过程清晰，价值明确的服务向导和指南；
3. 对客户的体验进行了直接和真实的记录，以利于和客户沟通，发现问题及时改进；
4. 对客户的需求与业务系统的功能提供了良好的匹配；
5. 通过"近距离"观察客户和业务系统交互的界面，业务建模的焦点从客户逐渐转移到业务系统身上来了，为接下来进入业务系统内部探究找到了可以跟踪返回的入口。
6. 对业务系统的边界（即对外功能范围）提供了详尽的描述；
7. 对业务系统的服务项目的服务功能和性能提供了测试的详细依据。

如何来描述一个服务项目的事件流呢？

事件流的描述，实际上就是对观察到的现实的或者设计想象的虚拟的客户体验过程进行详细的文字录像。把客户在什么样的背景条件下，启动业务系统的某个服务项目，向业务系统提出怎样的服务请求，业务系统又如何回应，要了解客户的哪些信息，要客户做出什么配合行动，要为客户做出什么行动，要交付客户什么物品，要在多长时间内完成等等，按先后顺序和逻辑过程详细地用文字一句一句地记录下来。

相信大多数读者有到食堂吃饭的经历，下面，我们就以食堂的客户的身份，来考察一下"食堂"这个业务系统的"卖饭"这个服务项目，看看它的事件流表达是怎样的。

业务系统：食堂。

业务用例名：卖饭。

业务主角：职工。

主角价值：得到一份自己比较喜欢的饭菜。

启动条件：

1. 食堂开饭时间到;
2. 餐具已经准备好；
3. 饭菜已经做好，并摆上了卖饭窗口的卖饭台;
4. 卖饭师傅到位。

事件流：

1. 职工到餐具领取处领取餐具；
2. 餐具领取处给每位来就餐的职工提供一套餐具；
3. 职工到打菜窗口排队；
4. 轮到职工打菜；
5. 职工说出自己喜欢的菜名；
6. 职工通过用餐电子卡打卡付帐；
7. 职工递过空餐盘给打饭师傅；
8. 打菜师傅将打好菜的餐盘交回给职工；
9. 职工接过打好菜的餐盘到打饭处排队；
10. 职工根据饭量自己打适量的米饭；
11. 用例结束。

例外1，餐卡余额不足：

例外发生点：6. 职工通过用餐电子卡打卡付帐；

例外事件流：

例外返回点：7. 职工递过空餐盘给打饭师傅；

例外2，餐票不足，重点菜

例外发生点：6.2职工交餐票；

例外事件流：

6.2.1. 职工发现自己餐票不足；

6.2.2. 职工重新点菜，直到餐票够用；

例外返回点：7. 职工递过空餐盘给打饭师傅；

例外3，餐票不足，无法重点菜

例外发生点：6.2职工交餐票 或6.2.2职工重新点菜，直到餐票够用；

例外事件流：

6.2.3. 职工发现自己的餐票不够用，点不到合适的菜；

6.2.4. 职工放弃打菜，离开打菜队伍；

例外返回点：11. 用例结束。

从以上事件流的描述中我们可以看到，事件流着重描述的是客户在业务系统界面与系统交互的行为产生的事件，而对业务系统内部的事件则基本忽略，如：缺菜的信息是怎么传递到厨房的，菜又是怎么从厨房补充到打菜台的这些完全是在食堂内部发生的事件，暂时就不必出现在用例的事件流的描述中，这些过程信息可以在进行后续工作设计业务用例内部流程时得到表达。

如何对服务项目的关系进行UML建模

前面讲到对服务体系建模的时候，提到一个服务体系中最重要的部分之一就是服务项目之间的关系，这一讲开始，我们专门来探讨这个问题。

在现实的业务工作中，针对一个业务系统的任意两个服务项目，要么它们之间有直接的关系，要么没有，正是因为存在服务项目之间的关系，才将一系列的服务项目整合为业务系统整体的服务形象。那么，通常的服务项目之间可能存在的关系有哪些种类呢？对这些关系UML又怎样来表达它们呢？

在UML标准语义中，只提供了三种用例关系的表达方法，联系我在第三讲中讲到的服务项目的关系，对这三种用例关系的"精确解释"如下：

1． 包含关系，其含义如下：

• 业务主角享受一个服务项目价值时，一定会享受到另一个服务项目的价值；
• 前一个服务项目的服务内容串行地包含了后一个服务项目的服务内容；
• 后一个服务项目的服务内容还可以是其他服务项目服务内容的必要组成部分；
• 后一个服务项目不一定可以单独提供服务。

那么，用来表达前一个服务项目的业务用例就"包含"用来表达后一个服务项目的业务用例。UML中用一个带"《包含》"文字说明的实线的单箭头来表示用例的包含关系，箭头指向被包含的用例。

2． 扩展关系，其含义如下：

• 业务主角在享受一个基本的服务项目的价值的基础上，还可以享受更多的别的衍生价值；
• 衍生的服务项目内容是"根植"在基本的服务项目的价值上的，但衍生的服务项目内容不是基本的服务项目的服务内容组成部分，而是并列地新冒出来的；
• 享受基本服务项目服务内容时，不一定要享用衍生的服务内容；
• 衍生的服务项目不一定可以单独提供服务。

那么，用来表达基本服务项目的业务用例就被表示衍生服务项目的业务用例所"扩展"。UML中用一个带"《扩展》"文字说明的实线的单箭头来表示用例的扩展关系，箭头指向基本用例。

3． 泛化关系，其含义如下：

• 一种服务项目的操作过程模式和按这种操作过程模式实现的具体的服务项目；
• 一个粗略的服务项目可具体化为一个精细的服务项目

那么，用来表达粗略服务项目或服务项目模式的业务用例，和表示具体服务项目的业务用例就形成了"父子关系"，粗略空泛的用例为"父用例"，具体实在的用例为"子用例"。UML中用一个不带文字说明的实线的空三角箭头来表示用例的泛化关系，箭头指向父用例。

初学UML的人，往往对被这三种基本的用例关系搞得很糊涂。包含、扩展、泛化，三个哲学味十足的词语足以让初学者不敢深入探究其中的精确含义。有必要搞那么复杂吗？这是常见的初学者疑问。如果你觉得有些晕，你就把用例换成"服务项目"，再回头记住上面我对每种关系所说的第一点解释。联系实际找几个享受类似服务项目之间的关系的例子对照理解，相信就会比较清醒了。

比如：

到南方的酒店享受完一顿餐饮服务后，服务员会自动上一盘免费的水果拼盘，免费享受一碟水果甜品服务似乎已经包含在南方的酒店餐饮服务的内容之中了；另外的场合是：在某些酒店享受保健理疗项目的同时，也可以同时享受一碟免费的水果甜品服务。

上面的例子中，同样是"免费水果甜品服务"，对于"餐饮服务"而言，就可以理解为是被包含的用例，但对"保健理疗"项目而言，则理解为是扩展用例更为合适。为什么呢？

首先，在服务的操作流程上，吃完饭后上水果在操作流程上是必选的串行流程，并且吃水果和吃饭一样都是获得享受美食，补充营养的价值，在价值上是一致的关系。而对做理疗而言，吃水果则是根据客户的喜好意愿来提供的，在操作流上是可选的并行的流程，并且做理疗是为了放松和治疗，吃水果是为美食和补充营养，在价值上是相关的，但不是一致的。

服务项目之间的泛化关系也是很常见的，

比如

你报某旅行社的"珠海一日游"这个服务项目，作为一个空泛的服务流程模式可能只说明，上午做景点光观，中午享受海鲜美食，下午市容参观购物等这么一个框架式的安排，也是一个价值明确的服务项目。当你实际随团旅游的时候，这个项目一定会落实为指定了时间地点的具体活动项目，比如：上午9：00-11：30到园明新园光观；中午12：00-1：30到得月舫享受海鲜美食；下午到珠海鱼女参观然后到九州城免税商场购物。

不用解释，前面这个空泛的"珠海一日游"服务项目就是后面这个"珠海一日游"服务项目的泛化。二者的关系就是泛化关系。

尽管UML提供了三种基本的用例关系的模型，但这三种关系模型对表达我在第三讲中讲到的一般的服务项目的关系来看，显然是不够充分的。我在ROSE工具中也发现，ROSE工具并不限制我们在不同的用例之间画具有其他的关系语义的连线，换句话说，只要使用得当，为了表达更丰富的服务项目之间的关系，我们是可以在用例之间任意选用不同型式关系连线来建立合适的其他的用例关系的，甚至可以通过改写连线上的"关系型"说明文字，来建立自己所要表达的用例关系。

从我个人的分析和总结看来，所有服务项目之间的关系可以分为最基本的两类：

1． 实际的服务项目操作过程的关系：也就是一个服务项目的操作流直接和另一个服务项目的操作流进行了搭接，在两个服务项目之间存在操作流转移的通路。我们可以将其简称为"实关系"；UML标准的用例关系中的"包含"和"扩展"关系就属于这种"实关系"类型。

2． 抽象的服务项目概念之间的关系：对任何一个服务项目，我们都会在脑海里建立这个服务项目的整体概念，那么，一个服务项目的概念可能和另外一个服务项目的概念有关系，这种概念上的关系，与服务项目的操作流搭接关系没有必然的联系，不是那么"可见"的，而是"可想"的关系，我们可以把这种服务项目概念之间的关系简称为"虚关系"。

实际上，UML标准的用例关系中的"泛化"关系就属于这种"虚关系"类型。"泛化"就是"一般化"的意思，"一般化"显然是用来描述两个概念之间的关系的，而非用来描述两个实际过程之间关系的，因为我们只能说：这个操作过程的这种说法（一个概念）是那种说法（另一个概念）的一种一般化形式，而不能说，这个操作过程是那个操作过程的一般化。

UML用一个椭圆来代表一个服务项目并取名为"某用例"。这个表达本身就包含了两层的含义：这个椭圆可以代表这个服务项目的实际的操作流，也可以代表我们头脑中建立的这个服务项目的概念。UML并没有在语义上将这两层含义分开来表达，这就导致了画在用例模型上的用例之间的箭头线出现多种型式。在ROSE建模工具中，提供了实线箭头和虚线箭头两种基本的关系线线型。我个人就倾向于用实线型表示实关系，用虚线表示虚关系。这和UML中用实线来表达真实事物之间的关系，用虚线表达模型构件之间的关系的本质含义是一致的，因为模型元素就是真实事物的概念化表达。

为了表达丰富的服务项目之间的关系类型，需要更多的"非标准语义"的用例关系，关于"非标准语义"的用例关系以及区分实关系和虚关系概念的重要性，我们在下一讲细说。

如何对服务项目之间的实关系进行UML建模

上一讲讲到我把服务项目之间的关系归为两类：一类是实关系，另一类是虚关系。

服务项目之间的实关系，是服务项目实际操作过程中实实在在存在的关系，这是对业务系统建模工作本来就要表达的内容。

任何一个服务项目，都是过程与目的的综合，也就是操作流与价值流的合流，通俗地说就是既“可用”又“有用”的事例，“可用”表明可操作，有操作流程，“有用”表明有价值，能达到某些目的。UML标准语义中的用例包含关系和扩展关系，正是在服务项目之间的过程关系与目的关系上，进行了两种最基本的分类表达。

仔细分析包含关系和扩展关系的区别，我们会发现，两种关系是从过程的“内”与“外”，目的的“同”与“异”两个维度来确定的：包含关系所涉及的两个服务项目，其中一个服务项目的操作过程是包含在另一个服务项目之内的，两者实现相同类型的同一个目的；扩展关系则正好相反，一个服务项目过程连接在另一个服务项目过程之外，两者实现不同类型的两个相关目的。

服务项目之间的实关系，从本质上来说虽然不外乎包含关系和扩展关系两种，但如果仅仅只使用这两种关系，会导致模型表达不够细腻和具体，对抽象思维水平要求过高，同时会增加建模的难度，也会带来模型在沟通效果上的欠缺。因为，从通俗意义上的服务项目关系来看，还存在许多看上去更丰富多彩的实关系类型可供表达。下面，我们还是顺着“实际的服务项目关系有哪些类型，用UML又如何表达它们”的思路来举例分析。

我们先来看包含关系的一个例外：从服务项目的操作流关系上看，即使是把一部分操作流看成是构成整体操作流的内部组成部分，这部分的操作流与其他部分操作流的执行关系不一定只有串行操作的关系，而可能也存在并行操作的关系。

比如：播放电影的服务是同时播放画面和播放音响的服务；看电影就是在用眼睛欣赏动态的画面同时，用耳朵欣赏音乐和对白，确实是两个同步、并列、相关进行的过程。假设我们用包含关系来表达播放电影的服务和播放图像和播放音响的服务之间的关系，虽然可以准确地表达出播放电影的服务和播放图像和播放音响之间的整体包含部分的关系，但也会错误地把播放图像和播放音响之间关系表达为串行操作的关系，显然是不妥的。比较准确的表达还必须在上述包含关系的基础上，添加播放图像和播放音响之间相互扩展的关系才能表达到位，但这样会让模型看起来显得太复杂了。

对此，更直观的表达是“组成关系”，把播放电影的服务建模为由播放图像和播放音响两项服务组成的，就可以相对简单而准确地表达出被包含的多个操作流的并行操作的含义。

我们再来看一个例子，这个例子中两个服务项目之间确实存在直接的关系，而这种关系又不是直接的操作流衔接关系，在这种情况下，直接用包含关系和扩展关系来表达都是不大适合的。

公共汽车公司为乘客提供公交线路旅客运输服务的服务项目，在有人售票的公共汽车上，售票本来只是线路客运服务过程中的一个操作步骤。在改用无人售票线路客运服务之后，售票的过程被分解为打卡的操作和乘车卡充值的服务，于是，公共汽车公司新增了一项“乘车卡充值”的服务项目。

现在来考究“无人售票线路客运”用例和“乘车卡充值”用例的关系？应该是什么关系呢？如何来表达呢？我们知道，在“无人售票线路客运”的“打卡”操作步骤上，有一个依赖的前提是：乘客的卡中必须是有足够的余额的，而“让乘客的卡中有足够的余额”这个价值，正好就是由“乘车卡充值”用例来实现的。两个用例之间没有直接的操作流搭接，而是通过乘车卡的余额这个对象的属性建立关联，由于充值的过程又不是在乘车的过程中进行的，所以，用扩展关系表达这个关系也不够准确。

最简明的处理办法是：将二者的关系定义为“依赖关系”，即“无人售票线路客运”用例依赖于“乘车卡充值”用例，表达方法是：用带普通箭头的线段从依赖用例指向被依赖用例，然后再在线段关系型名称上写上“《依赖》”即可。

值得一提的是，本例对服务项目进行拆分的技巧，这才是业务用例建模真正的技术所在：通过对服务项目的巧妙拆分或组合，改变了服务项目的划分和相互的关系，让业务系统整体的效率和效益获得提升，这才是真正需要运用业务经验和智慧，体现业务用例建模活动本身价值的关键所在。

用例之间的实关系存在哪些类型还可以从另一个思路来分析，研究用例关系，需要抓住的核心要点是操作流和价值流的关系。一个用例，可以类比为操作流和价值流两种类型直线段绞合而成的折线段，它和其他用例所有可能的关系类型，可以从空间中折线段与折接段之间关系类型得到启发。根据折线段与折线段的关系类型有单点交叉、部分重合、并列合股、分岔、汇合，首尾对接，延长对接等等可数的关系类型以及这些关系类型的简单组合，我们完全可以类比地找到符合这些几何意义的操作流与价值流的关系类型，从而确定不同服务项目之间的关系类型。根据这个思路可以系统性地对操作流和价值流的拆分和整合进行测试，对改进服务项目非常有启发性。

图中存在如下的服务项目的“几何关系”：

服务项目1和服务项目3在X点处存在“单点交叉”情况。举例：交通工具旅行中，不同线路服务项目出现中转交叉点的情况。可定义服务项目1和3之间存在的转接关系；

服务项目1和服务项目2在AB段存在“部分重合”的情况，则可分别建立服务项目1和服务项目2对AB段服务的包含关系。

服务项目2和服务项目4之间存在分岔和汇合的组合关系，服务项目6也是服务项目3的分岔，那么服务项目4和6就分别是服务项目2和3的扩展用例。

服务项目5连接在服务项目1的延长线上，这种情况就是依赖关系。

服务项目7直接连接在服务项目3的末端，这种情况可以定义为衔接关系，或调用关系。

服务项目8衔接在服务项目7后，其中的服务项目8.1和8.2存在并列合股的情况，可以定义服务项目8与服务项目8.1和8.2之间的组成关系。

建模工作的挑战之一就是要克服被建模系统的复杂性，系统的复杂性不仅仅表现在组成系统元素类型的多样性，更表现在元素之间关系类型的多样性上面。要克服系统的复杂性，关系类型的多样性问题是不能回避的。谈到这里，没有“钻进来”初学者也许会感到服务项目的关系太过复杂了，“钻进来”了的初学者则可能会发现，原来只提供包含关系和扩展关系2种关系建模，反而显得过于简单了。

我们时常需要检讨，当我们抱怨某种表达过于复杂，在我们常借言“简单才是美”的时候，我们是否为了片面地追求简单的表达，而回避了系统真正复杂的核心问题的解决，最终落入肤浅？说一个表达是否简单，应该是相对该表达要解决的问题的复杂程度而言的，而不是相对其它简单问题的简单表达而言的。不管用例关系有多复杂，只要抓住操作流和价值流的关系组合这个核心，我们就总可以找到“来时的路”而不致迷失。

经过建模，实际的服务项目转变成用例模型中用例的概念，对服务项目概念层的关系进行再加工的结果，就建立了用例概念上的虚关系。虚关系的建立让模型表达更简练，更清晰。

如何对服务项目的虚关系进行UML建模

前面已经多次讲到，虚关系就是概念关系。对于不大习惯抽象思维的读者，可能对于什么是概念关系可能仍然不是很清楚。下面举个简单的例子来说明：

这里有两句话:

1. “客户吃了一个苹果。”

2. “苹果是水果的一种。”

第一句话讲到客户和苹果之间的一个关系：客户吃苹果，这里，“苹果”一词指的是一个实在的苹果，代表苹果的实物，所以，“客户吃苹果”这个关系就是实关系：我们可以用眼睛实实在在地看到这样的关系发生；

第二句话讲到苹果和水果之间的一个关系：苹果是水果的一种；这里，“苹果”一词泛指所有的苹果，代表苹果的概念，所以，“苹果是水果的一种”这个关系就是虚关系：我们只能在头脑中形成这样的一个概念知识。

建模的过程之一就是认识被建模对象的过程，认识事物和事物关系的过程是：首先建立事物的实概念和事物关系的实概念，然后对这些实概念进行思维加工，总结出抽象概念，于是就会出现实概念和实概念、抽象概念和实概念、抽象概念和抽象概念之间的关系。具体事物的同类特征和关联就被浓缩到概念和概念的关系之中，从而大大提高表达的效率，这正是概念建模的基本原理之一。

需要细心注意的是：事物实概念之间的关系和事物关系的实概念是不同的，前者是虚关系，后者才是实关系，虽然，有时看上去它们的形态可能完全相同，但含义却有微妙的区别。比如：“猫是会吃老鼠的动物”与“猫吃老鼠是正常的”这两句话中，同样是“猫吃老鼠”的关系，含义上就有微妙的区别，前者表明：我们知道“猫”这个概念所指的动物能吃“老鼠”这个概念所指的动物，但我们永远也看不到“猫”这个概念吃掉“老鼠”这个概念的事情发生，所以，“猫”概念和“老鼠”概念之间的“吃”关系是虚关系；后者则表明：我们能看到“猫吃老鼠”这样的事情发生，所以，这里的“猫吃老鼠”的关系是实关系。

对于服务项目和服务项目之间的关系，认识它们的规律和认识人和苹果、猫和老鼠的规律并没什么不同，因此，在服务项目之间也存在虚关系需要表达。前面我们也已经讲到，用例之间的泛化关系就是一种虚关系。除了泛化关系之外，用例之间还可以存在虚包含、虚扩展、精化、衍生等虚关系。

“虚包含”关系就是一个用例所定义的内容包含在另一个用例所定义的内容之中，此时的用例，完全理解为是模型的部件。虚包含关系的使用，可以重复使用被包含用例的定义内容，从而减少模型信息的冗余，提高模型表达的效率。

“虚扩展”关系也是用来表达一个用例所定义的内容，是在另一个基本用例定义的内容的基础上的扩充。这样，也可以避免基本用例定义的内容的重复表达。

“精化”关系用来表达多个下层的用例所定义的内容，是对某个高层用例定义的内容更精确细化的表达。一般用在对大型的服务项目分层进行表达的时候，顶层的用例对应高层组织作为整体对外提供的服务，下层的用例则使对应该项服务为落实到下级组织后，精化表达的结果。

“衍生”关系用来表达围绕一个主要的服务项目周围，可以衍生一系列的周边相关的服务项目出来。比如，围绕长途汽车旅客运输服务，会衍生车站旅店住宿服务，车站餐馆的饮食服务等服务项目来。衍生关系实际上是一种在概念上的依赖关系，衍生出来的项目在概念上是依赖于主要服务项目的，也就是说，虽然衍生的服务本身是一种独立完整的服务，但如果没有主服务的存在，衍生服务也会逐渐消亡。

组织简介 | 联系我们 |   Copyright 2002 ®  UML软件工程组织 京ICP备10020922号

京公海网安备110108001071号