怎樣對客戶進行UML業(yè)務(wù)建模
簡單而言，客戶就是準(zhǔn)備購買或使用、或者已經(jīng)購買或使用了一個組織（下稱業(yè)務(wù)系統(tǒng)）的產(chǎn)品或服務(wù)的人。對于這個描述中，站在不同的角度，對客戶的實質(zhì)理解可能不同，而UML業(yè)務(wù)建模，則抓住了客戶的這樣一個實質(zhì)含義：客戶是站在這個業(yè)務(wù)系統(tǒng)的外部，和這個業(yè)務(wù)系統(tǒng)發(fā)生交互行為的對象。早期有專家把Actor 翻譯為"外部動作者"，雖然有些拗口，但意義非常精準(zhǔn)。
為什么UML一定要站在交互行為的角度來看客戶呢？這是因為一個客戶的重復(fù)進行的行為能最清楚地表達客戶的真實需求（即所謂肢體語言表達更豐富且真實），對客戶和業(yè)務(wù)系統(tǒng)之間的交互行為的描述和記錄，不但可以指引未來類似的過程重復(fù)進行，更本質(zhì)的意義在于，這些交互行為，清楚地表達了客戶和業(yè)務(wù)系統(tǒng)之間價值轉(zhuǎn)移發(fā)生的全過程。
一個業(yè)務(wù)系統(tǒng)是必須是一個開放的系統(tǒng)，也就是說，它必須接受來自外部的刺激，這種刺激，包括物質(zhì)，能量和信息的交換，才能驅(qū)動業(yè)務(wù)系統(tǒng)內(nèi)部的要素持續(xù)地運轉(zhuǎn)下去，否則，這個系統(tǒng)最終會走向沉寂。這就是一個企業(yè)沒有外部的客戶，沒有供應(yīng)商，沒有水電供應(yīng)，沒有電信服務(wù)，這個企業(yè)就只能關(guān)門的內(nèi)在道理。
如果從"外部動作者"這個本質(zhì)的定義反過來尋找一個實際的業(yè)務(wù)系統(tǒng)的對應(yīng)物，我們會發(fā)現(xiàn)，在一個業(yè)務(wù)系統(tǒng)外部，除了"客戶"，還存在大量其他"外部動作者"，如：供應(yīng)商、政府機構(gòu)、行業(yè)協(xié)會、投資機構(gòu)、甚至某些自動化的服務(wù)系統(tǒng)等等。圍繞在一個實際業(yè)務(wù)系統(tǒng)的周圍的"外部動作者"是多種類型，而且數(shù)量眾多的。這些外部動作者，要么向業(yè)務(wù)系統(tǒng)提供服務(wù)，收取報償；要么接受業(yè)務(wù)系統(tǒng)的服務(wù)，提供報償，這就是業(yè)務(wù)系統(tǒng)的上、下游的價值鏈關(guān)系，這些價值鏈實際上就是靠外部動作者與業(yè)務(wù)系統(tǒng)的交互行為來建立和維持的。
從價值鏈的角度，我們就能理解"業(yè)務(wù)主角"這個名詞的真實含義了，正是由于有這些系統(tǒng)外的"動作者"，懷有各自的目的，來到業(yè)務(wù)系統(tǒng)跟前，和業(yè)務(wù)系統(tǒng)進行一系列的交互行為，最終獲得業(yè)務(wù)系統(tǒng)提供的服務(wù)，支付給業(yè)務(wù)系統(tǒng)報償，即進行完價值交換后，揚長而去，這才使得業(yè)務(wù)系統(tǒng)找到自身存在的價值，所以，業(yè)務(wù)主角是主持業(yè)務(wù)系統(tǒng)生死攸關(guān)的外部角色，稱其為"主"，是恰如其分的。
由于現(xiàn)在全球經(jīng)濟環(huán)境目前出現(xiàn)的狀態(tài)是買方市場占優(yōu)的狀態(tài)，也就是說，是產(chǎn)品和服務(wù)過剩，需求不足的狀況，對于所有的業(yè)務(wù)系統(tǒng)而言，誰能擁有和維持客戶，誰就獲得提供產(chǎn)品和服務(wù)的機會，誰就能夠活下來，并長大，所以，流行"顧客是上帝"，"以客戶為中心"的口號才盛行。在個別的局部環(huán)境下，存在賣方市場的狀況時，則會出現(xiàn)"供應(yīng)商是上帝"的局面。如果戴著UML業(yè)務(wù)建模的"有色眼鏡"來看，不管是客戶還是供應(yīng)商，大家都是"業(yè)務(wù)主角"，都是業(yè)務(wù)系統(tǒng)的"上帝"。明眼人可能已經(jīng)看出，單是從"業(yè)務(wù)主角"這個建模元素，我們已經(jīng)可以體會到UML業(yè)務(wù)建模令人驚嘆的抽象表達能力。
如何對服務(wù)項目進行UML業(yè)務(wù)建模
一個服務(wù)項目是一個業(yè)務(wù)系統(tǒng)對外提供的一項有價值的服務(wù)過程。每個組織或企業(yè)（業(yè)務(wù)系統(tǒng)）存在的理由都是因為它們能夠?qū)ν饨缣峁┻@些服務(wù)項目。
需要辨析的是，服務(wù)項目不是籠統(tǒng)的價值描述，而是對應(yīng)確實可行的一系列的行為過程的指稱，也就是說，提到一個服務(wù)項目的名稱，我們就知道意味著可以啟動執(zhí)行的一個具體的事例。比如說，暢享網(wǎng)列舉的主要服務(wù)如下：
結(jié)識全球各地的管理、信息化、投融資等領(lǐng)域的人脈。
發(fā)起、加入自己感興趣的圈子，創(chuàng)建同好、校友、同事聯(lián)絡(luò)區(qū)，組織線上線下活動。
發(fā)布、獲取、討論商業(yè)機會，招聘人才、獲取工作，進行服務(wù)及物品的交易。
在最早、最豐富、最權(quán)威的管理和信息化知識庫里獲取專業(yè)實用的理論研究、實踐經(jīng)驗、案例探討、解決方案、可用資源。
同專業(yè)人士分享您在管理和信息化領(lǐng)域的思考、心得、經(jīng)歷、體驗。
第一時間獲取業(yè)內(nèi)知名企業(yè)、企業(yè)家、專家的新聞動態(tài)。
創(chuàng)建個人博客，記錄人生感悟、展示自我風(fēng)采，用拖拉方式DIY博客，完全個性化。
其中談到了很多暢享網(wǎng)可以提供的服務(wù)項目，也談到了暢享網(wǎng)能提供的價值。如：同專業(yè)人士分享您在管理和信息化領(lǐng)域的思考、心得、經(jīng)歷、體驗。就是對服務(wù)價值的描述，而創(chuàng)建個人博客，記錄人生感悟、展示自我風(fēng)采，用拖拉方式DIY博客，完全個性化。則是一個具體的服務(wù)項目。服務(wù)價值是通過提供服務(wù)項目來實現(xiàn)的。進行這樣的區(qū)分是非常重要的，因為建模的關(guān)鍵之一就是要仔細辨識一些概念的微妙關(guān)系與區(qū)別，只有這樣，我們才能真正認清事物的關(guān)鍵部分和本質(zhì)部分。
UML 業(yè)務(wù)建模正是通過對服務(wù)項目的建模來體現(xiàn)業(yè)務(wù)系統(tǒng)的價值的。UML使用"業(yè)務(wù)用例"（Business Usecase）一詞來稱呼服務(wù)項目。很多初學(xué)者對"用例"這個名字感覺很不習(xí)慣，為什么要取這么個怪名字呢？我想，主要還是為了突出服務(wù)項目的動態(tài)交互性和價值的明確性。
Usecase這個名字首先告訴我們這是一單Case，什么叫Case？Case就是當(dāng)回事，當(dāng)回事就是有開始、有過程、有結(jié)尾、有收獲，還可以做了一回又做一回，即可重復(fù)。Use有兩層含義：
可用：說明這是一件可以操作的具體的事；
有用：說明這是一項有價值的事。
UseCase合起來，就是"可用的和有用的事例"，簡稱"用例"，還是蠻講得通的。Business UseCase 就是"業(yè)務(wù)系統(tǒng)提供的可用的和有用的事例"的意思了，其實，這不就是"服務(wù)項目"這個名稱的含義嗎？
我們常說，要做有用的人，要做有價值的企業(yè)。什么是有用的人，有價值的企業(yè)呢？有用的人，是通過這個人能做有用的幾件事來體現(xiàn)的，有價值的企業(yè)，也是通過企業(yè)能提供有價值的服務(wù)來表現(xiàn)的。價值是人的根本需求，"用例"則是對實現(xiàn)和表達需求的肢體語言的描述，是一個過程?？梢哉f，用戶的需求是很少變化的，變化的是用戶實現(xiàn)需求的過程。在對業(yè)務(wù)系統(tǒng)的分析中，發(fā)現(xiàn)業(yè)務(wù)需求與業(yè)務(wù)用例（業(yè)務(wù)價值與業(yè)務(wù)過程）的映射關(guān)系是非常重要的。我們通過表達業(yè)務(wù)系統(tǒng)可用和有用的事，就能間接地表達業(yè)務(wù)系統(tǒng)有什么價值。
為了說明需求與用例的關(guān)系，我再舉一個簡單的例子。
比如問，水果刀有什么用（價值）？
我們一般會馬上回答：可以用來削皮，切開水果。
我們回答的實際上是"用水果刀能做什么事？"這個問題，得到了"削皮"和"切果"兩個答案，也就是兩個"用例"。
那么，真正的需求是什么呢？也就是"水果刀有什么用（價值）？"這個問題的真實答案應(yīng)該是什么呢？應(yīng)該是：1.使水果吃起來更衛(wèi)生；2.使水果吃起來更方便。這才是真正的水果刀的價值。
我們可以看到，實現(xiàn)水果刀價值的過程，不一定只有"削皮"和"切果"這兩個過程，也不一定只有水果刀能提供這些過程，比如削皮機，果汁機等都可以用不同或相同的過程來滿足兩項需求。用例是滿足需求的過程，而需求則是過程背后所實現(xiàn)的價值。這正是UML用例建模的核心思想。
怎樣對服務(wù)體系進行UML業(yè)務(wù)建模
我們知道，客戶是從業(yè)務(wù)系統(tǒng)的外部啟動并享用服務(wù)項目的人或機構(gòu)，在現(xiàn)代供應(yīng)鏈管理模式下，服務(wù)過程是客戶驅(qū)動的，即，如果沒有客戶出現(xiàn)，服務(wù)項目的實例服務(wù)過程就不會被啟動和執(zhí)行，否則，我們就找不到"誰讓你做這事的？"的答案，自然沒有人愿意來為你的勞動買單。此外，客戶可以分為很多類型，不同類型的客戶，需要的服務(wù)項目可能有相同的部分，也可能有不同的部分。
從業(yè)務(wù)系統(tǒng)外部看來，一個業(yè)務(wù)系統(tǒng)對外提供的服務(wù)項目一般不是單一的，而是多項的，并且多個服務(wù)項目之間還存在一定的聯(lián)系。這些服務(wù)項目之間的聯(lián)系，也是客戶所知道和所需要的，所謂"一條龍"服務(wù)，就是系統(tǒng)性地為客戶提供全方位的服務(wù)，是最大限度地提高客戶的滿意度的，體系化的服務(wù)。
只有通過特定的客戶和服務(wù)項目之間的聯(lián)系，不同服務(wù)項目之間的聯(lián)系，業(yè)務(wù)系統(tǒng)才能把不同類型的客戶或供應(yīng)商集結(jié)起來，這就構(gòu)成了業(yè)務(wù)系統(tǒng)對外的服務(wù)體系。對于企業(yè)來說，只要能夠?qū)m當(dāng)?shù)目蛻羧禾峁┫到y(tǒng)性的、體系化的服務(wù)，一般就都具備了長盛不衰的基礎(chǔ)。
我們已經(jīng)知道，對客戶和供應(yīng)商等業(yè)務(wù)系統(tǒng)外部的交互者，UML用"業(yè)務(wù)主角"的概念來建模，對業(yè)務(wù)系統(tǒng)對外提供的服務(wù)項目，UML用"業(yè)務(wù)用例"的概念來建模。對上述業(yè)務(wù)系統(tǒng)的對外服務(wù)體系，UML則運用了最基本的模型-"業(yè)務(wù)用例模型"來表達。
一個組織面對什么客戶群，提供怎樣的服務(wù)體系，是決定一個組織業(yè)務(wù)架構(gòu)的基礎(chǔ)。比如：供電局和環(huán)保局的業(yè)務(wù)架構(gòu)就不同，學(xué)校和醫(yī)院的業(yè)務(wù)架構(gòu)也不同，商場和工廠的業(yè)務(wù)架構(gòu)也不同，原因就是他們各自對外提供的服務(wù)體系是非常不同的。
UML 業(yè)務(wù)用例模型用一個帶箭頭的線段來連接業(yè)務(wù)主角和業(yè)務(wù)用例，或連接一個業(yè)務(wù)用例到另一個業(yè)務(wù)用例。這樣就把分散獨立的業(yè)務(wù)主角和業(yè)務(wù)用例連接成了一個網(wǎng)絡(luò)關(guān)系的圖。也就是"業(yè)務(wù)用例圖"。業(yè)務(wù)用例圖是業(yè)務(wù)用例模型的圖示化的表達，能清晰、完整細致地表現(xiàn)業(yè)務(wù)系統(tǒng)對外的服務(wù)體系。
這個帶箭頭的線段，用于連接業(yè)務(wù)主角和業(yè)務(wù)用例的時候，表達了如下的含義：
這里有一個交互操作的過程，交互操作的發(fā)起者在線段的起始端，響應(yīng)者則在箭頭指向端；
這里有一個服務(wù)價值轉(zhuǎn)移的過程，服務(wù)的請求者、受益者和支付者在線段的起始端，服務(wù)的提供者、實現(xiàn)者和受酬者則在箭頭的指向端。
這里有一個信息流向的過程，在交互操作的過程中，雖然信息一般是雙向流動的，但從總的信息流量和信息交換的主被動關(guān)系來看，接受信息多的一方往往也是被動交換信息的一方，因此，也是箭頭指向的一方。
以上三層含義就分別表達了對外服務(wù)體系中的三層關(guān)系，即有形的操作交換關(guān)系以及無形的價值交換和信息交換關(guān)系。這三層關(guān)系組合結(jié)果，可能出現(xiàn)的情況如下：
這三層的關(guān)系的方向指向在絕大多數(shù)情況下，可以認為是一致，不出現(xiàn)矛盾的情況，這種情況下，箭頭方向選擇沒有任何疑問；
在某些情況下，某層關(guān)系可能不明顯和直接，但總有某一層關(guān)系是明顯的；這時，箭頭方向表達最明確的層次關(guān)系。
當(dāng)實際的三個表達層次出現(xiàn)矛盾的時候，則可以取最希望表達的層次來理解，這時，箭頭方向的選擇代表了建模者在特定場景下主觀意圖上對某個層次的重視。
當(dāng)箭頭線用于連接兩個不同的業(yè)務(wù)用例的時候，表示在兩個業(yè)務(wù)用例所表達的服務(wù)項目之間存在某種關(guān)聯(lián)關(guān)系，可能的關(guān)系含義包括但不限于如下幾種：
箭頭的起始端業(yè)務(wù)用例與其業(yè)務(wù)主角的關(guān)系，可以順著箭頭線，"傳導(dǎo)"到箭頭指向的業(yè)務(wù)用例。也就是說，箭頭線起始端業(yè)務(wù)用例的主角，同樣是箭頭線指向端業(yè)務(wù)用例的主角。
業(yè)務(wù)主角在享受一個服務(wù)項目的價值的過程中，一定會要享受另一個服務(wù)項目的價值；
業(yè)務(wù)主角在享受一個服務(wù)項目的價值的基礎(chǔ)上，還可以享受更多的別的具有衍生價值的項目服務(wù)；
業(yè)務(wù)主角在享受一個服務(wù)項目之前，依賴于先前享受過另一個服務(wù)項目的服務(wù)；
一項總的服務(wù)項目和組成這個總服務(wù)項目中的某個分項目；
一種服務(wù)項目的操作模式和按這種操作模式實現(xiàn)的具體的服務(wù)項目；
一個粗略的服務(wù)項目可具體化為一個精細的服務(wù)項目；
一個服務(wù)項目的意圖過程和實現(xiàn)這個意圖過程的具體的服務(wù)項目。
用來表達以上多種業(yè)務(wù)用例關(guān)系的箭頭線有不同的畫法，為了能區(qū)分到底表達的是哪種用例的關(guān)系，可能在線的旁邊用文字來標(biāo)識，也可能用不同的箭頭形狀，線型表示不同的關(guān)系類型。詳細的表達方法我們在討論具體的用例關(guān)系表達時做專題討論。
最后需要強調(diào)的是：業(yè)務(wù)用例模型只需要表達一個業(yè)務(wù)系統(tǒng)對外界的服務(wù)體系，不需要對業(yè)務(wù)系統(tǒng)內(nèi)部的服務(wù)和協(xié)作關(guān)系進行表達。對于后者，UML業(yè)務(wù)建模會用" 業(yè)務(wù)對象模型"這種更適合表達協(xié)作過程的模型來表達，這是UML業(yè)務(wù)建模的最基本的模型分工。這樣分工帶來的好處是：一方面可以讓我們在建立業(yè)務(wù)用例模型的時候，把主要精力集中到要滿足的客戶業(yè)務(wù)需求上面來；另一方面使得模型的表達內(nèi)外有別，內(nèi)外呼應(yīng)，使模型信息的組織更加具有系統(tǒng)性，并符合我們認識事物由遠而進，由外向內(nèi)的一般規(guī)律。
如何對客戶體驗進行UML業(yè)務(wù)建模
前面我們從業(yè)務(wù)系統(tǒng)的客戶談到服務(wù)項目，從服務(wù)項目談到對外服務(wù)體系，可以說，這些是"站在離業(yè)務(wù)系統(tǒng)比較遠一點的地方"看到的業(yè)務(wù)系統(tǒng)比較宏觀的外部景象。如果我們再"走近"一點，但仍然保持是"站在業(yè)務(wù)系統(tǒng)外面"的觀察點來仔細觀察一個業(yè)務(wù)系統(tǒng)，那么，我們就會"看到"業(yè)務(wù)系統(tǒng)的客戶是如何享受每一個服務(wù)項目的服務(wù)的，我們可以描述客戶的詳細的體驗過程，這是發(fā)現(xiàn)和評價服務(wù)項目的價值最直接的辦法。
UML通過事件流描述的辦法來記錄（設(shè)計）客戶在服務(wù)項目上的交互過程。此時，我們需要把業(yè)務(wù)系統(tǒng)看成是一個"黑箱"，要想象客戶與業(yè)務(wù)系統(tǒng)的交互過程發(fā)生在"黑箱"的某個對外開放的"窗口"上，這個窗口就代表一個服務(wù)項目，我們只能看到客戶以及業(yè)務(wù)系統(tǒng)在這個窗口上所發(fā)生的全部事件，窗口里面所發(fā)生的一切，我們暫時不去細究。
這個"窗口"，實際上就是客戶和業(yè)務(wù)系統(tǒng)進行交互活動的一個"界面"。UML事件流描述的方法從界面交互的細節(jié)為切入點，能抓住業(yè)務(wù)系統(tǒng)為了滿足客戶的體驗需求而必須做出的所有活動，從而為下一步在設(shè)計業(yè)務(wù)系統(tǒng)內(nèi)部運作過程時提供了目標(biāo)每一個業(yè)務(wù)系統(tǒng)內(nèi)部的活動都必須是以滿足界面上必須表現(xiàn)的行為為目標(biāo)的，而且每一個界面上所發(fā)生的業(yè)務(wù)系統(tǒng)的響應(yīng)事件，都必需要有內(nèi)部活動來支持。在"窗口"上所作的事件流記錄，集中體現(xiàn)了以下重要的模型價值：
對客戶行為和業(yè)務(wù)系統(tǒng)的行為進行了耦合；
對客戶提供了過程清晰，價值明確的服務(wù)向?qū)Ш椭改希?
對客戶的體驗進行了直接和真實的記錄，以利于和客戶溝通，發(fā)現(xiàn)問題及時改進；
對客戶的需求與業(yè)務(wù)系統(tǒng)的功能提供了良好的匹配；
通過"近距離"觀察客戶和業(yè)務(wù)系統(tǒng)交互的界面，業(yè)務(wù)建模的焦點從客戶逐漸轉(zhuǎn)移到業(yè)務(wù)系統(tǒng)身上來了，為接下來進入業(yè)務(wù)系統(tǒng)內(nèi)部探究找到了可以跟蹤返回的入口。
對業(yè)務(wù)系統(tǒng)的邊界（即對外功能范圍）提供了詳盡的描述；
對業(yè)務(wù)系統(tǒng)的服務(wù)項目的服務(wù)功能和性能提供了測試的詳細依據(jù)。
如何來描述一個服務(wù)項目的事件流呢？
事件流的描述，實際上就是對觀察到的現(xiàn)實的或者設(shè)計想象的虛擬的客戶體驗過程進行詳細的文字錄像。把客戶在什么樣的背景條件下，啟動業(yè)務(wù)系統(tǒng)的某個服務(wù)項目，向業(yè)務(wù)系統(tǒng)提出怎樣的服務(wù)請求，業(yè)務(wù)系統(tǒng)又如何回應(yīng)，要了解客戶的哪些信息，要客戶做出什么配合行動，要為客戶做出什么行動，要交付客戶什么物品，要在多長時間內(nèi)完成等等，按先后順序和邏輯過程詳細地用文字一句一句地記錄下來。
相信大多數(shù)讀者有到食堂吃飯的經(jīng)歷，下面，我們就以食堂的客戶的身份，來考察一下"食堂"這個業(yè)務(wù)系統(tǒng)的"賣飯"這個服務(wù)項目，看看它的事件流表達是怎樣的。
業(yè)務(wù)系統(tǒng) ：食堂。
業(yè)務(wù)用例名 ：賣飯。
業(yè)務(wù)主角 ：職工。
主角價值 ：得到一份自己比較喜歡的飯菜。
啟動條件 ：
食堂開飯時間到;
餐具已經(jīng)準(zhǔn)備好；
飯菜已經(jīng)做好，并擺上了賣飯窗口的賣飯臺;
賣飯師傅到位。
事件流：
職工到餐具領(lǐng)取處領(lǐng)取餐具；
餐具領(lǐng)取處給每位來就餐的職工提供一套餐具；
職工到打菜窗口排隊；
輪到職工打菜；
職工說出自己喜歡的菜名；
職工通過用餐電子卡打卡付帳；
職工遞過空餐盤給打飯師傅；
打菜師傅將打好菜的餐盤交回給職工；
職工接過打好菜的餐盤到打飯?zhí)幣抨牐?
職工根據(jù)飯量自己打適量的米飯；
用例結(jié)束。
例外1，餐卡余額不足：
例外發(fā)生點：6. 職工通過用餐電子卡打卡付帳；
例外事件流：
6.1. 電子餐卡機發(fā)現(xiàn)職工餐卡中余額不足；
6.2. 職工交餐票；
6.3. 如果餐票超額，打菜師傅找回零票；
例外返回點：7. 職工遞過空餐盤給打飯師傅；
例外2，餐票不足，重點菜
例外發(fā)生點：6.2職工交餐票；
例外事件流：
6.2.1. 職工發(fā)現(xiàn)自己餐票不足；
6.2.2. 職工重新點菜，直到餐票夠用；
例外返回點：7. 職工遞過空餐盤給打飯師傅；
例外3，餐票不足，無法重點菜
例外發(fā)生點：6.2職工交餐票 或6.2.2職工重新點菜，直到餐票夠用；
例外事件流：
6.2.3. 職工發(fā)現(xiàn)自己的餐票不夠用，點不到合適的菜；
6.2.4. 職工放棄打菜，離開打菜隊伍；
例外返回點：11. 用例結(jié)束。
從以上事件流的描述中我們可以看到，事件流著重描述的是客戶在業(yè)務(wù)系統(tǒng)界面與系統(tǒng)交互的行為產(chǎn)生的事件，而對業(yè)務(wù)系統(tǒng)內(nèi)部的事件則基本忽略，如：缺菜的信息是怎么傳遞到廚房的，菜又是怎么從廚房補充到打菜臺的這些完全是在食堂內(nèi)部發(fā)生的事件，暫時就不必出現(xiàn)在用例的事件流的描述中，這些過程信息可以在進行后續(xù)工作設(shè)計業(yè)務(wù)用例內(nèi)部流程時得到表達。
如何對服務(wù)項目的關(guān)系進行UML建模
前面講到對服務(wù)體系建模的時候，提到一個服務(wù)體系中最重要的部分之一就是服務(wù)項目之間的關(guān)系，這一講開始，我們專門來探討這個問題。
在現(xiàn)實的業(yè)務(wù)工作中，針對一個業(yè)務(wù)系統(tǒng)的任意兩個服務(wù)項目，要么它們之間有直接的關(guān)系，要么沒有，正是因為存在服務(wù)項目之間的關(guān)系，才將一系列的服務(wù)項目整合為業(yè)務(wù)系統(tǒng)整體的服務(wù)形象。那么，通常的服務(wù)項目之間可能存在的關(guān)系有哪些種類呢？對這些關(guān)系UML又怎樣來表達它們呢？
在UML標(biāo)準(zhǔn)語義中，只提供了三種用例關(guān)系的表達方法，聯(lián)系我在第三講中講到的服務(wù)項目的關(guān)系，對這三種用例關(guān)系的"精確解釋"如下：
1． 包含關(guān)系，其含義如下：
業(yè)務(wù)主角享受一個服務(wù)項目價值時，一定會享受到另一個服務(wù)項目的價值；
前一個服務(wù)項目的服務(wù)內(nèi)容串行地包含了后一個服務(wù)項目的服務(wù)內(nèi)容；
后一個服務(wù)項目的服務(wù)內(nèi)容還可以是其他服務(wù)項目服務(wù)內(nèi)容的必要組成部分；
后一個服務(wù)項目不一定可以單獨提供服務(wù)。
那么，用來表達前一個服務(wù)項目的業(yè)務(wù)用例就"包含"用來表達后一個服務(wù)項目的業(yè)務(wù)用例。UML中用一個帶"《包含》"文字說明的實線的單箭頭來表示用例的包含關(guān)系，箭頭指向被包含的用例。
2． 擴展關(guān)系，其含義如下：
業(yè)務(wù)主角在享受一個基本的服務(wù)項目的價值的基礎(chǔ)上，還可以享受更多的別的衍生價值；
衍生的服務(wù)項目內(nèi)容是"根植"在基本的服務(wù)項目的價值上的，但衍生的服務(wù)項目內(nèi)容不是基本的服務(wù)項目的服務(wù)內(nèi)容組成部分，而是并列地新冒出來的；
享受基本服務(wù)項目服務(wù)內(nèi)容時，不一定要享用衍生的服務(wù)內(nèi)容；
衍生的服務(wù)項目不一定可以單獨提供服務(wù)。
那么，用來表達基本服務(wù)項目的業(yè)務(wù)用例就被表示衍生服務(wù)項目的業(yè)務(wù)用例所"擴展"。UML中用一個帶"《擴展》"文字說明的實線的單箭頭來表示用例的擴展關(guān)系，箭頭指向基本用例。
3． 泛化關(guān)系，其含義如下：
一種服務(wù)項目的操作過程模式和按這種操作過程模式實現(xiàn)的具體的服務(wù)項目；
一個粗略的服務(wù)項目可具體化為一個精細的服務(wù)項目
那么，用來表達粗略服務(wù)項目或服務(wù)項目模式的業(yè)務(wù)用例，和表示具體服務(wù)項目的業(yè)務(wù)用例就形成了"父子關(guān)系"，粗略空泛的用例為"父用例"，具體實在的用例為"子用例"。UML中用一個不帶文字說明的實線的空三角箭頭來表示用例的泛化關(guān)系，箭頭指向父用例。
初學(xué)UML的人，往往對被這三種基本的用例關(guān)系搞得很糊涂。包含、擴展、泛化，三個哲學(xué)味十足的詞語足以讓初學(xué)者不敢深入探究其中的精確含義。有必要搞那么復(fù)雜嗎？這是常見的初學(xué)者疑問。如果你覺得有些暈，你就把用例換成"服務(wù)項目"，再回頭記住上面我對每種關(guān)系所說的第一點解釋。聯(lián)系實際找?guī)讉€享受類似服務(wù)項目之間的關(guān)系的例子對照理解，相信就會比較清醒了。
比如：
到南方的酒店享受完一頓餐飲服務(wù)后，服務(wù)員會自動上一盤免費的水果拼盤，免費享受一碟水果甜品服務(wù)似乎已經(jīng)包含在南方的酒店餐飲服務(wù)的內(nèi)容之中了；另外的場合是：在某些酒店享受保健理療項目的同時，也可以同時享受一碟免費的水果甜品服務(wù)。
上面的例子中，同樣是"免費水果甜品服務(wù)"，對于"餐飲服務(wù)"而言，就可以理解為是被包含的用例，但對"保健理療"項目而言，則理解為是擴展用例更為合適。為什么呢？
首先，在服務(wù)的操作流程上，吃完飯后上水果在操作流程上是必選的串行流程，并且吃水果和吃飯一樣都是獲得享受美食，補充營養(yǎng)的價值，在價值上是一致的關(guān)系。而對做理療而言，吃水果則是根據(jù)客戶的喜好意愿來提供的，在操作流上是可選的并行的流程，并且做理療是為了放松和治療，吃水果是為美食和補充營養(yǎng)，在價值上是相關(guān)的，但不是一致的。
服務(wù)項目之間的泛化關(guān)系也是很常見的，
比如
你報某旅行社的"珠海一日游"這個服務(wù)項目，作為一個空泛的服務(wù)流程模式可能只說明，上午做景點光觀，中午享受海鮮美食，下午市容參觀購物等這么一個框架式的安排，也是一個價值明確的服務(wù)項目。當(dāng)你實際隨團旅游的時候，這個項目一定會落實為指定了時間地點的具體活動項目，比如：上午9：00-11：30到園明新園光觀；中午12：00-1：30到得月舫享受海鮮美食；下午到珠海魚女參觀然后到九州城免稅商場購物。
不用解釋，前面這個空泛的"珠海一日游"服務(wù)項目就是后面這個"珠海一日游"服務(wù)項目的泛化。二者的關(guān)系就是泛化關(guān)系。
盡管UML提供了三種基本的用例關(guān)系的模型，但這三種關(guān)系模型對表達我在第三講中講到的一般的服務(wù)項目的關(guān)系來看，顯然是不夠充分的。我在ROSE工具中也發(fā)現(xiàn)，ROSE工具并不限制我們在不同的用例之間畫具有其他的關(guān)系語義的連線，換句話說，只要使用得當(dāng)，為了表達更豐富的服務(wù)項目之間的關(guān)系，我們是可以在用例之間任意選用不同型式關(guān)系連線來建立合適的其他的用例關(guān)系的，甚至可以通過改寫連線上的"關(guān)系型"說明文字，來建立自己所要表達的用例關(guān)系。
從我個人的分析和總結(jié)看來，所有服務(wù)項目之間的關(guān)系可以分為最基本的兩類：
1． 實際的服務(wù)項目操作過程的關(guān)系：也就是一個服務(wù)項目的操作流直接和另一個服務(wù)項目的操作流進行了搭接，在兩個服務(wù)項目之間存在操作流轉(zhuǎn)移的通路。我們可以將其簡稱為"實關(guān)系"；UML標(biāo)準(zhǔn)的用例關(guān)系中的"包含"和"擴展"關(guān)系就屬于這種"實關(guān)系"類型。
2．抽象的服務(wù)項目概念之間的關(guān)系：對任何一個服務(wù)項目，我們都會在腦海里建立這個服務(wù)項目的整體概念，那么，一個服務(wù)項目的概念可能和另外一個服務(wù)項目的概念有關(guān)系，這種概念上的關(guān)系，與服務(wù)項目的操作流搭接關(guān)系沒有必然的聯(lián)系，不是那么"可見"的，而是"可想"的關(guān)系，我們可以把這種服務(wù)項目概念之間的關(guān)系簡稱為"虛關(guān)系"。
實際上，UML標(biāo)準(zhǔn)的用例關(guān)系中的"泛化"關(guān)系就屬于這種"虛關(guān)系"類型。"泛化"就是"一般化"的意思，"一般化"顯然是用來描述兩個概念之間的關(guān)系的，而非用來描述兩個實際過程之間關(guān)系的，因為我們只能說：這個操作過程的這種說法（一個概念）是那種說法（另一個概念）的一種一般化形式，而不能說，這個操作過程是那個操作過程的一般化。
UML 用一個橢圓來代表一個服務(wù)項目并取名為"某用例"。這個表達本身就包含了兩層的含義：這個橢圓可以代表這個服務(wù)項目的實際的操作流，也可以代表我們頭腦中建立的這個服務(wù)項目的概念。UML并沒有在語義上將這兩層含義分開來表達，這就導(dǎo)致了畫在用例模型上的用例之間的箭頭線出現(xiàn)多種型式。在ROSE建模工具中，提供了實線箭頭和虛線箭頭兩種基本的關(guān)系線線型。我個人就傾向于用實線型表示實關(guān)系，用虛線表示虛關(guān)系。這和UML中用實線來表達真實事物之間的關(guān)系，用虛線表達模型構(gòu)件之間的關(guān)系的本質(zhì)含義是一致的，因為模型元素就是真實事物的概念化表達。
為了表達豐富的服務(wù)項目之間的關(guān)系類型，需要更多的"非標(biāo)準(zhǔn)語義"的用例關(guān)系，關(guān)于"非標(biāo)準(zhǔn)語義"的用例關(guān)系以及區(qū)分實關(guān)系和虛關(guān)系概念的重要性，我們在下一講細說。
如何對服務(wù)項目之間的實關(guān)系進行UML建模
上一講講到我把服務(wù)項目之間的關(guān)系歸為兩類：一類是實關(guān)系，另一類是虛關(guān)系。
服務(wù)項目之間的實關(guān)系，是服務(wù)項目實際操作過程中實實在在存在的關(guān)系，這是對業(yè)務(wù)系統(tǒng)建模工作本來就要表達的內(nèi)容。
任何一個服務(wù)項目，都是過程與目的的綜合，也就是操作流與價值流的合流，通俗地說就是既“可用”又“有用”的事例，“可用”表明可操作，有操作流程，“有用 ”表明有價值，能達到某些目的。UML標(biāo)準(zhǔn)語義中的用例包含關(guān)系和擴展關(guān)系，正是在服務(wù)項目之間的過程關(guān)系與目的關(guān)系上，進行了兩種最基本的分類表達。
仔細分析包含關(guān)系和擴展關(guān)系的區(qū)別，我們會發(fā)現(xiàn)，兩種關(guān)系是從過程的“內(nèi)”與“外”，目的的“同”與“異”兩個維度來確定的：包含關(guān)系所涉及的兩個服務(wù)項目，其中一個服務(wù)項目的操作過程是包含在另一個服務(wù)項目之內(nèi)的，兩者實現(xiàn)相同類型的同一個目的；擴展關(guān)系則正好相反，一個服務(wù)項目過程連接在另一個服務(wù)項目過程之外，兩者實現(xiàn)不同類型的兩個相關(guān)目的。
服務(wù)項目之間的實關(guān)系，從本質(zhì)上來說雖然不外乎包含關(guān)系和擴展關(guān)系兩種，但如果僅僅只使用這兩種關(guān)系，會導(dǎo)致模型表達不夠細膩和具體，對抽象思維水平要求過高，同時會增加建模的難度，也會帶來模型在溝通效果上的欠缺。因為，從通俗意義上的服務(wù)項目關(guān)系來看，還存在許多看上去更豐富多彩的實關(guān)系類型可供表達。下面，我們還是順著“實際的服務(wù)項目關(guān)系有哪些類型，用 UML又如何表達它們”的思路來舉例分析。
我們先來看包含關(guān)系的一個例外：從服務(wù)項目的操作流關(guān)系上看，即使是把一部分操作流看成是構(gòu)成整體操作流的內(nèi)部組成部分，這部分的操作流與其他部分操作流的執(zhí)行關(guān)系不一定只有串行操作的關(guān)系，而可能也存在并行操作的關(guān)系。
比如：播放電影的服務(wù)是同時播放畫面和播放音響的服務(wù)；看電影就是在用眼睛欣賞動態(tài)的畫面同時，用耳朵欣賞音樂和對白，確實是兩個同步、并列、相關(guān)進行的過程。假設(shè)我們用包含關(guān)系來表達播放電影的服務(wù)和播放圖像和播放音響的服務(wù)之間的關(guān)系，雖然可以準(zhǔn)確地表達出播放電影的服務(wù)和播放圖像和播放音響之間的整體包含部分的關(guān)系，但也會錯誤地把播放圖像和播放音響之間關(guān)系表達為串行操作的關(guān)系，顯然是不妥的。比較準(zhǔn)確的表達還必須在上述包含關(guān)系的基礎(chǔ)上，添加播放圖像和播放音響之間相互擴展的關(guān)系才能表達到位，但這樣會讓模型看起來顯得太復(fù)雜了。
對此，更直觀的表達是“組成關(guān)系”，把播放電影的服務(wù)建模為由播放圖像和播放音響兩項服務(wù)組成的，就可以相對簡單而準(zhǔn)確地表達出被包含的多個操作流的并行操作的含義。
我們再來看一個例子，這個例子中兩個服務(wù)項目之間確實存在直接的關(guān)系，而這種關(guān)系又不是直接的操作流銜接關(guān)系，在這種情況下，直接用包含關(guān)系和擴展關(guān)系來表達都是不大適合的。
公共汽車公司為乘客提供公交線路旅客運輸服務(wù)的服務(wù)項目，在有人售票的公共汽車上，售票本來只是線路客運服務(wù)過程中的一個操作步驟。在改用無人售票線路客運服務(wù)之后，售票的過程被分解為打卡的操作和乘車卡充值的服務(wù)，于是，公共汽車公司新增了一項“乘車卡充值”的服務(wù)項目。
現(xiàn)在來考究“無人售票線路客運”用例和“乘車卡充值”用例的關(guān)系？應(yīng)該是什么關(guān)系呢？如何來表達呢？我們知道，在“無人售票線路客運”的“打卡”操作步驟上，有一個依賴的前提是：乘客的卡中必須是有足夠的余額的，而“讓乘客的卡中有足夠的余額”這個價值，正好就是由“乘車卡充值”用例來實現(xiàn)的。兩個用例之間沒有直接的操作流搭接，而是通過乘車卡的余額這個對象的屬性建立關(guān)聯(lián)，由于充值的過程又不是在乘車的過程中進行的，所以，用擴展關(guān)系表達這個關(guān)系也不夠準(zhǔn)確。
最簡明的處理辦法是：將二者的關(guān)系定義為“依賴關(guān)系”，即“無人售票線路客運”用例依賴于“乘車卡充值”用例，表達方法是：用帶普通箭頭的線段從依賴用例指向被依賴用例，然后再在線段關(guān)系型名稱上寫上“《依賴》”即可。
值得一提的是，本例對服務(wù)項目進行拆分的技巧，這才是業(yè)務(wù)用例建模真正的技術(shù)所在：通過對服務(wù)項目的巧妙拆分或組合，改變了服務(wù)項目的劃分和相互的關(guān)系，讓業(yè)務(wù)系統(tǒng)整體的效率和效益獲得提升，這才是真正需要運用業(yè)務(wù)經(jīng)驗和智慧，體現(xiàn)業(yè)務(wù)用例建?；顒颖旧韮r值的關(guān)鍵所在。
用例之間的實關(guān)系存在哪些類型還可以從另一個思路來分析，研究用例關(guān)系，需要抓住的核心要點是操作流和價值流的關(guān)系。一個用例，可以類比為操作流和價值流兩種類型直線段絞合而成的折線段，它和其他用例所有可能的關(guān)系類型，可以從空間中折線段與折接段之間關(guān)系類型得到啟發(fā)。根據(jù)折線段與折線段的關(guān)系類型有單點交叉、部分重合、并列合股、分岔、匯合，首尾對接，延長對接等等可數(shù)的關(guān)系類型以及這些關(guān)系類型的簡單組合，我們完全可以類比地找到符合這些幾何意義的操作流與價值流的關(guān)系類型，從而確定不同服務(wù)項目之間的關(guān)系類型。根據(jù)這個思路可以系統(tǒng)性地對操作流和價值流的拆分和整合進行測試，對改進服務(wù)項目非常有啟發(fā)性。
圖中存在如下的服務(wù)項目的“幾何關(guān)系”：
服務(wù)項目1和服務(wù)項目3在X點處存在“單點交叉”情況。舉例：交通工具旅行中，不同線路服務(wù)項目出現(xiàn)中轉(zhuǎn)交叉點的情況?？啥x服務(wù)項目1和3之間存在的轉(zhuǎn)接關(guān)系；
服務(wù)項目1和服務(wù)項目2在AB段存在“部分重合”的情況，則可分別建立服務(wù)項目1和服務(wù)項目2對AB段服務(wù)的包含關(guān)系。
服務(wù)項目2和服務(wù)項目4之間存在分岔和匯合的組合關(guān)系，服務(wù)項目6也是服務(wù)項目3的分岔，那么服務(wù)項目4和6就分別是服務(wù)項目2和3的擴展用例。
服務(wù)項目5連接在服務(wù)項目1的延長線上，這種情況就是依賴關(guān)系。
服務(wù)項目7直接連接在服務(wù)項目3的末端，這種情況可以定義為銜接關(guān)系，或調(diào)用關(guān)系。
服務(wù)項目8銜接在服務(wù)項目7后，其中的服務(wù)項目8.1和8.2存在并列合股的情況，可以定義服務(wù)項目8與服務(wù)項目8.1和8.2之間的組成關(guān)系。
建模工作的挑戰(zhàn)之一就是要克服被建模系統(tǒng)的復(fù)雜性，系統(tǒng)的復(fù)雜性不僅僅表現(xiàn)在組成系統(tǒng)元素類型的多樣性，更表現(xiàn)在元素之間關(guān)系類型的多樣性上面。要克服系統(tǒng)的復(fù)雜性，關(guān)系類型的多樣性問題是不能回避的。談到這里，沒有“鉆進來”初學(xué)者也許會感到服務(wù)項目的關(guān)系太過復(fù)雜了，“鉆進來”了的初學(xué)者則可能會發(fā)現(xiàn)，原來只提供包含關(guān)系和擴展關(guān)系2種關(guān)系建模，反而顯得過于簡單了。
我們時常需要檢討，當(dāng)我們抱怨某種表達過于復(fù)雜，在我們常借言“簡單才是美”的時候，我們是否為了片面地追求簡單的表達，而回避了系統(tǒng)真正復(fù)雜的核心問題的解決，最終落入膚淺？說一個表達是否簡單，應(yīng)該是相對該表達要解決的問題的復(fù)雜程度而言的，而不是相對其它簡單問題的簡單表達而言的。不管用例關(guān)系有多復(fù)雜，只要抓住操作流和價值流的關(guān)系組合這個核心，我們就總可以找到“來時的路”而不致迷失。
經(jīng)過建模，實際的服務(wù)項目轉(zhuǎn)變成用例模型中用例的概念，對服務(wù)項目概念層的關(guān)系進行再加工的結(jié)果，就建立了用例概念上的虛關(guān)系。虛關(guān)系的建立讓模型表達更簡練，更清晰。
如何對服務(wù)項目的虛關(guān)系進行UML建模
前面已經(jīng)多次講到，虛關(guān)系就是概念關(guān)系。對于不大習(xí)慣抽象思維的讀者，可能對于什么是概念關(guān)系可能仍然不是很清楚。下面舉個簡單的例子來說明：
這里有兩句話:
1. “客戶吃了一個蘋果。”
2. “蘋果是水果的一種。”
第一句話講到客戶和蘋果之間的一個關(guān)系：客戶吃蘋果，這里，“蘋果”一詞指的是一個實在的蘋果，代表蘋果的實物，所以，“客戶吃蘋果”這個關(guān)系就是實關(guān)系：我們可以用眼睛實實在在地看到這樣的關(guān)系發(fā)生；
第二句話講到蘋果和水果之間的一個關(guān)系：蘋果是水果的一種；這里，“蘋果”一詞泛指所有的蘋果，代表蘋果的概念，所以，“蘋果是水果的一種”這個關(guān)系就是虛關(guān)系：我們只能在頭腦中形成這樣的一個概念知識。
建模的過程之一就是認識被建模對象的過程，認識事物和事物關(guān)系的過程是：首先建立事物的實概念和事物關(guān)系的實概念，然后對這些實概念進行思維加工，總結(jié)出抽象概念，于是就會出現(xiàn)實概念和實概念、抽象概念和實概念、抽象概念和抽象概念之間的關(guān)系。具體事物的同類特征和關(guān)聯(lián)就被濃縮到概念和概念的關(guān)系之中，從而大大提高表達的效率，這正是概念建模的基本原理之一。
需要細心注意的是：事物實概念之間的關(guān)系和事物關(guān)系的實概念是不同的，前者是虛關(guān)系，后者才是實關(guān)系，雖然，有時看上去它們的形態(tài)可能完全相同，但含義卻有微妙的區(qū)別。比如：“貓是會吃老鼠的動物”與“貓吃老鼠是正常的”這兩句話中，同樣是“貓吃老鼠”的關(guān)系，含義上就有微妙的區(qū)別，前者表明：我們知道“貓”這個概念所指的動物能吃“老鼠”這個概念所指的動物，但我們永遠也看不到“貓”這個概念吃掉“老鼠”這個概念的事情發(fā)生，所以，“貓”概念和“老鼠”概念之間的“吃”關(guān)系是虛關(guān)系；后者則表明：我們能看到“貓吃老鼠”這樣的事情發(fā)生，所以，這里的“貓吃老鼠”的關(guān)系是實關(guān)系。
對于服務(wù)項目和服務(wù)項目之間的關(guān)系，認識它們的規(guī)律和認識人和蘋果、貓和老鼠的規(guī)律并沒什么不同，因此，在服務(wù)項目之間也存在虛關(guān)系需要表達。前面我們也已經(jīng)講到，用例之間的泛化關(guān)系就是一種虛關(guān)系。除了泛化關(guān)系之外，用例之間還可以存在虛包含、虛擴展、精化、衍生等虛關(guān)系。
“虛包含”關(guān)系就是一個用例所定義的內(nèi)容包含在另一個用例所定義的內(nèi)容之中，此時的用例，完全理解為是模型的部件。虛包含關(guān)系的使用，可以重復(fù)使用被包含用例的定義內(nèi)容，從而減少模型信息的冗余，提高模型表達的效率。
“虛擴展”關(guān)系也是用來表達一個用例所定義的內(nèi)容，是在另一個基本用例定義的內(nèi)容的基礎(chǔ)上的擴充。這樣，也可以避免基本用例定義的內(nèi)容的重復(fù)表達。
“精化”關(guān)系用來表達多個下層的用例所定義的內(nèi)容，是對某個高層用例定義的內(nèi)容更精確細化的表達。一般用在對大型的服務(wù)項目分層進行表達的時候，頂層的用例對應(yīng)高層組織作為整體對外提供的服務(wù)，下層的用例則使對應(yīng)該項服務(wù)為落實到下級組織后，精化表達的結(jié)果。
“ 衍生”關(guān)系用來表達圍繞一個主要的服務(wù)項目周圍，可以衍生一系列的周邊相關(guān)的服務(wù)項目出來。比如，圍繞長途汽車旅客運輸服務(wù)，會衍生車站旅店住宿服務(wù)，車站餐館的飲食服務(wù)等服務(wù)項目來。衍生關(guān)系實際上是一種在概念上的依賴關(guān)系，衍生出來的項目在概念上是依賴于主要服務(wù)項目的，也就是說，雖然衍生的服務(wù)本身是一種獨立完整的服務(wù)，但如果沒有主服務(wù)的存在，衍生服務(wù)也會逐漸消亡。
