對服務項目的關系進行UML業務建模行之有效的辦法
本節和大家學習一下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中用實線來表達真實事物之間的關系，用虛線表達模型構件之間的關系的本質含義是一致的，因為模型元素就是真實事物的概念化表達。
為了表達豐富的服務項目之間的關系類型，需要更多的"非標準語義"的用例關系，關于"非標準語義"的用例關系以及區分實關系和虛關系概念的重要性，我們在下一講細說。
【編輯推薦】
