本节和大家学习一下UML业务建模，前面讲到对服务体系建模的时候，提到一个服务体系中最重要的部分之一就是服务项目之间的关系，这一讲开始，我们专门来探讨这个问题。
如何对服务项目的关系进行UML业务建模
在现实的业务工作中，针对一个业务系统的任意两个服务项目，要么它们之间有直接的关系，要么没有，正是因为存在服务项目之间的关系，才将一系列的服务项目整合为业务系统整体的服务形象。那么，通常的服务项目之间可能存在的关系有哪些种类呢？对这些关系UML又怎样来表达它们呢？
在UML业务建模标准语义中，只提供了三种用例关系的表达方法，联系我在第三讲中讲到的服务项目的关系，对这三种用例关系的"精确解释"如下：
1．包含关系，其含义如下：
业务主角享受一个服务项目价值时，一定会享受到另一个服务项目的价值；
前一个服务项目的服务内容串行地包含了后一个服务项目的服务内容；
后一个服务项目的服务内容还可以是其他服务项目服务内容的必要组成部分；
后一个服务项目不一定可以单独提供服务。
那么，用来表达前一个服务项目的业务用例就"包含"用来表达后一个服务项目的业务用例。UML中用一个带"《包含》"文字说明的实线的单箭头来表示用例的包含关系，箭头指向被包含的用例。
2．扩展关系，其含义如下：
业务主角在享受一个基本的服务项目的价值的基础上，还可以享受更多的别的衍生价值；
衍生的服务项目内容是"根植"在基本的服务项目的价值上的，但衍生的服务项目内容不是基本的服务项目的服务内容组成部分，而是并列地新冒出来的；
享受基本服务项目服务内容时，不一定要享用衍生的服务内容；
衍生的服务项目不一定可以单独提供服务。
那么，用来表达基本服务项目的业务用例就被表示衍生服务项目的业务用例所"扩展"。UML业务建模中用一个带"《扩展》"文字说明的实线的单箭头来表示用例的扩展关系，箭头指向基本用例。
3．泛化关系，其含义如下：
一种服务项目的操作过程模式和按这种操作过程模式实现的具体的服务项目；
一个粗略的服务项目可具体化为一个精细的服务项目
那么，用来表达粗略服务项目或服务项目模式的业务用例，和表示具体服务项目的业务用例就形成了"父子关系"，粗略空泛的用例为"父用例"，具体实在的用例为"子用例"。UML中用一个不带文字说明的实线的空三角箭头来表示用例的泛化关系，箭头指向父用例。
初学UML业务建模的人，往往对被这三种基本的用例关系搞得很糊涂。包含、扩展、泛化，三个哲学味十足的词语足以让初学者不敢深入探究其中的精确含义。有必要搞那么复杂吗？这是常见的初学者疑问。如果你觉得有些晕，你就把用例换成"服务项目"，再回头记住上面我对每种关系所说的第一点解释。联系实际找几个享受类似服务项目之间的关系的例子对照理解，相信就会比较清醒了。
比如：
到南方的酒店享受完一顿餐饮服务后，服务员会自动上一盘免费的水果拼盘，免费享受一碟水果甜品服务似乎已经包含在南方的酒店餐饮服务的内容之中了；另外的场合是：在某些酒店享受保健理疗项目的同时，也可以同时享受一碟免费的水果甜品服务。#p#
上面的例子中，同样是"免费水果甜品服务"，对于"餐饮服务"而言，就可以理解为是被包含的用例，但对"保健理疗"项目而言，则理解为是扩展用例更为合适。为什么呢？
首先，在服务的操作流程上，吃完饭后上水果在操作流程上是必选的串行流程，并且吃水果和吃饭一样都是获得享受美食，补充营养的价值，在价值上是一致的关系。而对做理疗而言，吃水果则是根据客户的喜好意愿来提供的，在操作流上是可选的并行的流程，并且做理疗是为了放松和治疗，吃水果是为美食和补充营养，在价值上是相关的，但不是一致的。
服务项目之间的泛化关系也是很常见的，比如：
你报某旅行社的"珠海一日游"这个服务项目，作为一个空泛的服务流程模式可能只说明，上午做景点光观，中午享受海鲜美食，下午市容参观购物等这么一个框架式的安排，也是一个价值明确的服务项目。当你实际随团旅游的时候，这个项目一定会落实为指定了时间地点的具体活动项目，比如：上午9：00-11：30到园明新园光观；中午12：00-1：30到得月舫享受海鲜美食；下午到珠海鱼女参观然后到九州城免税商场购物。
不用解释，前面这个空泛的"珠海一日游"服务项目就是后面这个"珠海一日游"服务项目的泛化。二者的关系就是泛化关系。
尽管UML业务建模提供了三种基本的用例关系的模型，但这三种关系模型对表达我在第三讲中讲到的一般的服务项目的关系来看，显然是不够充分的。我在ROSE工具中也发现，ROSE工具并不限制我们在不同的用例之间画具有其他的关系语义的连线，换句话说，只要使用得当，为了表达更丰富的服务项目之间的关系，我们是可以在用例之间任意选用不同型式关系连线来建立合适的其他的用例关系的，甚至可以通过改写连线上的"关系型"说明文字，来建立自己所要表达的用例关系。
从我个人的分析和总结看来，所有服务项目之间的关系可以分为最基本的两类：
1．实际的服务项目操作过程的关系：也就是一个服务项目的操作流直接和另一个服务项目的操作流进行了搭接，在两个服务项目之间存在操作流转移的通路。我们可以将其简称为"实关系"；UML标准的用例关系中的"包含"和"扩展"关系就属于这种"实关系"类型。
2．抽象的服务项目概念之间的关系：对任何一个服务项目，我们都会在脑海里建立这个服务项目的整体概念，那么，一个服务项目的概念可能和另外一个服务项目的概念有关系，这种概念上的关系，与服务项目的操作流搭接关系没有必然的联系，不是那么"可见"的，而是"可想"的关系，我们可以把这种服务项目概念之间的关系简称为"虚关系"。
实际上，UML业务建模标准的用例关系中的"泛化"关系就属于这种"虚关系"类型。"泛化"就是"一般化"的意思，"一般化"显然是用来描述两个概念之间的关系的，而非用来描述两个实际过程之间关系的，因为我们只能说：这个操作过程的这种说法（一个概念）是那种说法（另一个概念）的一种一般化形式，而不能说，这个操作过程是那个操作过程的一般化。
UML用一个椭圆来代表一个服务项目并取名为"某用例"。这个表达本身就包含了两层的含义：这个椭圆可以代表这个服务项目的实际的操作流，也可以代表我们头脑中建立的这个服务项目的概念。UML并没有在语义上将这两层含义分开来表达，这就导致了画在用例模型上的用例之间的箭头线出现多种型式。在ROSE建模工具中，提供了实线箭头和虚线箭头两种基本的关系线线型。我个人就倾向于用实线型表示实关系，用虚线表示虚关系。这和UML中用实线来表达真实事物之间的关系，用虚线表达模型构件之间的关系的本质含义是一致的，因为模型元素就是真实事物的概念化表达。
为了表达丰富的服务项目之间的关系类型，需要更多的"非标准语义"的用例关系，关于"非标准语义"的用例关系以及区分实关系和虚关系概念的重要性，我们在下一讲细说。
【编辑推荐】
