怎樣對客戶進行UML業務建模(二)

如何對服務項目的關系進行UML建模



前面講到對服務體系建模的時候，提到一個服務體系中最重要的部分之一就是服務項目之間的關系，這一講開始，我們專門來探討這個問題。

在現實的業務工作中，針對一個業務系統的任意兩個服務項目，要么它們之間有直接的關系，要么沒有，正是因為存在服務項目之間的關系，才將一系列的服務項目整合為業務系統整體的服務形象。那么，通常的服務項目之間可能存在的關系有哪些種類呢？對這些關系UML又怎樣來表達它們呢？

在UML標準語義中，只提供了三種用例關系的表達方法，聯系我在第三講中講到的服務項目的關系，對這三種用例關系的"精確解釋"如下：

1． 包含關系，其含義如下：

業務主角享受一個服務項目價值時，一定會享受到另一個服務項目的價值； 
前一個服務項目的服務內容串行地包含了后一個服務項目的服務內容； 
后一個服務項目的服務內容還可以是其他服務項目服務內容的必要組成部分； 
后一個服務項目不一定可以單獨提供服務。 
那么，用來表達前一個服務項目的業務用例就"包含"用來表達后一個服務項目的業務用例。UML中用一個帶"《包含》"文字說明的實線的單箭頭來表示用例的包含關系，箭頭指向被包含的用例。

2． 擴展關系，其含義如下：

業務主角在享受一個基本的服務項目的價值的基礎上，還可以享受更多的別的衍生價值； 
衍生的服務項目內容是"根植"在基本的服務項目的價值上的，但衍生的服務項目內容不是基本的服務項目的服務內容組成部分，而是并列地新冒出來的； 
享受基本服務項目服務內容時，不一定要享用衍生的服務內容； 
衍生的服務項目不一定可以單獨提供服務。 
那么，用來表達基本服務項目的業務用例就被表示衍生服務項目的業務用例所"擴展"。UML中用一個帶"《擴展》"文字說明的實線的單箭頭來表示用例的擴展關系，箭頭指向基本用例。

3． 泛化關系，其含義如下：

一種服務項目的操作過程模式和按這種操作過程模式實現的具體的服務項目； 
一個粗略的服務項目可具體化為一個精細的服務項目 
那么，用來表達粗略服務項目或服務項目模式的業務用例，和表示具體服務項目的業務用例就形成了"父子關系"，粗略空泛的用例為"父用例"，具體實在的用例為"子用例"。UML中用一個不帶文字說明的實線的空三角箭頭來表示用例的泛化關系，箭頭指向父用例。

初學UML的人，往往對被這三種基本的用例關系搞得很糊涂。包含、擴展、泛化，三個哲學味十足的詞語足以讓初學者不敢深入探究其中的精確含義。有必要搞那么復雜嗎？這是常見的初學者疑問。如果你覺得有些暈，你就把用例換成"服務項目"，再回頭記住上面我對每種關系所說的第一點解釋。聯系實際找幾個享受類似服務項目之間的關系的例子對照理解，相信就會比較清醒了。

比如：

到南方的酒店享受完一頓餐飲服務后，服務員會自動上一盤免費的水果拼盤，免費享受一碟水果甜品服務似乎已經包含在南方的酒店餐飲服務的內容之中了；另外的場合是：在某些酒店享受保健理療項目的同時，也可以同時享受一碟免費的水果甜品服務。

上面的例子中，同樣是"免費水果甜品服務"，對于"餐飲服務"而言，就可以理解為是被包含的用例，但對"保健理療"項目而言，則理解為是擴展用例更為合適。為什么呢？

首先，在服務的操作流程上，吃完飯后上水果在操作流程上是必選的串行流程，并且吃水果和吃飯一樣都是獲得享受美食，補充營養的價值，在價值上是一致的關系。而對做理療而言，吃水果則是根據客戶的喜好意愿來提供的，在操作流上是可選的并行的流程，并且做理療是為了放松和治療，吃水果是為美食和補充營養，在價值上是相關的，但不是一致的。

原文轉自：http://www.anti-gravitydesign.com