本節(jié)和大家學習一下怎樣對服務(wù)體系進行UML業(yè)務(wù)建模，從業(yè)務(wù)系統(tǒng)外部看來，一個業(yè)務(wù)系統(tǒng)對外提供的服務(wù)項目一般不是單一的，而是多項的，并且多個服務(wù)項目之間還存在一定的聯(lián)系。

怎樣對服務(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當?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)就不同，學校和醫(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)系。
當實際的三個表達層次出現(xiàn)矛盾的時候，則可以取最希望表達的層次來理解，這時，箭頭方向的選擇代表了建模者在特定場景下主觀意圖上對某個層次的重視。

當箭頭線用于連接兩個不同的UML業(yè)務(wù)建模用例的時候，表示在兩個業(yè)務(wù)用例所表達的服務(wù)項目之間存在某種關(guān)聯(lián)關(guān)系，可能的關(guān)系含義包括但不限于如下幾種：

◆箭頭的起始端業(yè)務(wù)用例與其業(yè)務(wù)主角的關(guān)系，可以順著箭頭線，"傳導"到箭頭指向的業(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)系，可能在線的旁邊用文字來標識，也可能用不同的箭頭形狀，線型表示不同的關(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ī)律。

【編輯推薦】

1. 對服務(wù)項目進行UML業(yè)務(wù)建模方法揭秘 
2. 名師引導 如何對客戶進行UML業(yè)務(wù)建模
3. UML應(yīng)用實作細節(jié)——UML業(yè)務(wù)建模
4. UML建模時需要注意的四大問題
5. UML業(yè)務(wù)建模實例中如何作需求分析