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

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



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

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

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

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

业务主角享受一个服务项目价值时，一定会享受到另一个服务项目的价值； 
前一个服务项目的服务内容串行地包含了后一个服务项目的服务内容； 
后一个服务项目的服务内容还可以是其他服务项目服务内容的必要组成部分； 
后一个服务项目不一定可以单独提供服务。 
那么，用来表达前一个服务项目的业务用例就"包含"用来表达后一个服务项目的业务用例。UML中用一个带"《包含》"文字说明的实线的单箭头来表示用例的包含关系，箭头指向被包含的用例。

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

业务主角在享受一个基本的服务项目的价值的基础上，还可以享受更多的别的衍生价值； 
衍生的服务项目内容是"根植"在基本的服务项目的价值上的，但衍生的服务项目内容不是基本的服务项目的服务内容组成部分，而是并列地新冒出来的； 
享受基本服务项目服务内容时，不一定要享用衍生的服务内容； 
衍生的服务项目不一定可以单独提供服务。 
那么，用来表达基本服务项目的业务用例就被表示衍生服务项目的业务用例所"扩展"。UML中用一个带"《扩展》"文字说明的实线的单箭头来表示用例的扩展关系，箭头指向基本用例。

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

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

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

比如：

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

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

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

原文转自：http://www.ltesting.net