第4章 業務模組化 之 業務序列圖
我像是一顆棋子，來去全不由自己
《棋子》；詞：潘麗玉，曲：楊明煌，唱：王靖雯；1994
上一章我們得到了待改進組織的業務用例圖，本章我們将讨論業務模組化中最繁重的工作——描述業務用例的實作，即業務流程，然後改進它，推導出待引入系統的用例。
4.1 描述業務流程的手段
描述業務流程的可選手段有文本、活動圖和序列圖，下面先比較一下它們的優劣。
4.4.1 文本
例如針對财務部“員工→報帳”用例的實作，書寫業務用例規約如下：
1. 員工把報帳單交給财務主管
2. 财務主管确認報帳單已經過員工上司審批
3. 财務主管審批報帳單
4. 财務主管将審批好的報帳單返還給員工
5. 員工把報帳單交給會計
6. 會計複核報帳單
7. 會計記錄報帳單
8. 會計把報帳單交給出納
9. 出納付款
擴充：
2a. 報帳單未經員工上司審批：
……
文本的缺點是不夠生動，是以在描述業務流程時很少使用文本的方式。不過，描述系統用例（即系統需求）的流程時，文本是常用的，因為此時更注重精确，而且還要表達業務規則、性能等目前尚未被UML标準覆寫的内容。
4.1.2 活動圖
用UML圖形描述業務流程有兩種選擇：活動圖和序列圖。
活動圖的前身流程圖，應該是在開發人員中使用頻率最高的圖形了。流程圖最早出現于1921年[Gilbreth 1921]，用于機械工程領域。在Goldstine和von Neumann将其引入計算機領域之後，流程圖變得流行起來，主要用于在編寫文本源代碼之前表達跳轉邏輯。不過，随着程式設計語言表達能力也越來越強，針對簡單的分支、循環邏輯畫一張圖很多情況下已經變得沒有必要。
活動圖在流程圖的基礎上添加了分區（Partition，即UML1.x中的泳道）、分叉（Fork）、結合（Join）等元素，UML2.x進一步增加了Petri網的元素，表達能力更加豐富。
如果活動圖用來表示組織内部的業務流程，那就是業務流程圖。上面的報帳業務流程用活動圖可以表示如下：
圖4-1 用活動圖描述業務流程
4.1.3 序列圖
UML2.x序列圖的符号辨別來自ITU（國際電信聯盟）制定的消息序列圖（MSC）标準[ITU-T Z.120]。Ivar Jacobson在“The Object Advantage”一書[Jacobson 1995]中将序列圖用于描述業務流程，把業務流程看作是一系列業務對象之間為了完成業務用例而進行的協作。1997年Ivar Jacobson又出了UML版的“Software Reuse”[Jacobson 1997]，其中也有描述。
上面的報帳業務流程用序列圖可以表示如下：
圖4-2 用序列圖描述業務流程
4.1.4 序列圖和活動圖比較
本書所授方法采用序列圖來描述業務流程。做出這個選擇基于以下幾點理由：
（1）活動圖隻關注人，序列圖把人當作系統。
使用活動圖描述業務流程時，模組化人員往往隻注意人或部門的活動，忽略了非人智能系統的責任。上一章已經提到，現在的業務流程中已經有很多領域邏輯是封裝在業務實體而不是業務勞工中。如果忽略非人智能系統，很多重要資訊就丢掉了。
例如，圖4-1的活動圖未能表達出會計記錄報帳單和出納記錄付款資訊都需要用到現有的電腦系統SCS這個事實，而圖4-2的序列圖表達出來了。雖然活動圖可以稍作變通，将非人系統也單列為分區，但我見過的絕大多數活動圖，分區的擡頭隻是描述人或部門。
（2）活動圖表示動作，序列圖強迫思考動作背後的目的。
對比圖4-3和圖4-4：
圖4-3 活動圖表示動作
圖4-4 序列圖強迫思考背後的目的
圖4-4不但表達了非人系統的責任，同時也清晰地揭示出來營業員這個崗位對外暴露的責任是：受理申請，這也是市民對于營業員的期望。期望和承諾是用例和對象技術的關鍵思想。使用序列圖來做業務模組化，“對象協作以完成用例”的思想就可以統一地貫徹業務模組化和系統模組化的始終。
（3）活動圖“靈活”，序列圖不“靈活”。
不少人認為活動圖勝過序列圖的地方是它靈活，但這種靈活是一把雙刃劍。活動圖很靈活，它的控制流箭頭可以指向任何地方，就像編碼原始時代的Goto語句，是以活動圖很容易畫。不過，“很容易畫”的活動圖，也比較容易掩蓋模組化人員對業務流程認識不足或者業務流程本身存在缺陷的事實。
圖4-5 活動圖的靈活是把雙刃劍
序列圖通過alt、loop等結構化控制片斷來描述業務流程，強迫模組化人員用這種方式去思考，如圖4-6。對于現狀确實亂七八糟的流程，描述起來相對要困難，甚至需要按照場景分開畫很多張序列圖來表達，但這也揭示了業務流程的糟糕現狀。
圖4-6 帶有結構塊的序列圖
本書選擇用序列圖來做業務模組化，最主要原因還是理由（1）——把人腦系統和電腦系統平等看待。如果您使用活動圖或其他方法做業務模組化已經做得很好，而且能解決這個問題，就不一定要切換到序列圖。畢竟在目前已有的業務流程模組化資料中，活動圖或類似活動圖的手段（如BPMN）占絕大多數，積累了比序列圖多得多的參考資料和模型。
這裡展開說一個問題：多，不代表有價值。經常有開發人員問我，“潘老師，UML用得好的團隊多不多？”我隻能回答“不多”（參見第一章關于“冠軍的心”的闡述）。于是提問者就釋然了，哦，用得好的不多，看起來這個東西用處不大，我不學也沒關系的。
圍棋下得好的、足球踢得好的、腦外科手術做得好的、長得漂亮的女性…都不多，但是一旦突破門檻進入這個圈子，就會有很大的競争優勢。就拿編碼來說，可能讀者覺得會編碼的人挺多的，周圍的人大多都會。其實會編碼的人數和會吃喝拉撒的人數相比少得可憐，編碼編得好的就更少了，但不能由此推導出“編碼沒用”的結論，相反，正是因為編碼有門檻，是以大多數程式員盡管買不起房，衣食無憂是做得到的。
會用活動圖（或者再退一步，會用流程圖）來模組化業務流程的人已經算是少的了，更多的是随意而畫的“草圖”，更更多的應該是什麼都不會畫或者懶得畫，把膿包一遮了之。
UML提供了互動概述圖（Interaction Overview diagram），采用活動圖的形式将各個場景的序列圖串起來，相當于結合了活動圖和序列圖的特點，如圖4-7。不過，用序列圖也可以把其他序列圖串起來，是以互動概述圖不是必要的。
4-7 互動概述圖
4.2 業務序列圖要點
4.2.1 消息代表責任配置設定而不是資料流動
我給圖4-2的業務序列圖加了一些注解，如圖4-8所示。
圖4-8 業務序列圖主要元素
序列圖最重要的要點是消息的含義。A指向B的消息，代表“A請求B做某事”，或者“A調用B做某事的服務”，做某事是B的一個責任。例如，圖4-8中，指向财務主管的消息“審批報帳單”映射了财務主管的“審批報帳單”責任。注意，消息名稱中不用帶“請求”二字，消息箭頭已經有請求的意思。
在序列圖中，資料流僅僅作為消息的輸入輸出參數存在。如果不了解這一點，就容易把消息的方向當成資料流動的方向，不但消息名稱沒寫對，還會出現成對的消息，如圖4-9所示。
圖4-9 錯把消息當成資料流
4.2.2 抽象級别是系統之間的協作
業務模組化的研究對象是組織，出現在業務序列圖生命線上的對象，其最小顆粒是系統，包括人和非人系統。如果模組化人員不把這一點時刻記在心中，打哪指哪，抽象級别随着興之所至跳躍，就會使業務序列圖中混入不該有的内容。
圖4-10的業務序列圖中，CRM系統的一個元件“客戶表”露了出來，因為模組化人員突然想到客戶資料應該儲存在資料庫的“客戶”表中。其實這個抽象級别不關心CRM系統中是不是使用關系資料庫儲存資料以及資料庫中是不是有一個表叫“客戶”。如果真的要考慮系統内部元件這個抽象級别，“配置設定銷售專員”操作也會影響一些表，怎麼不畫出來？銷售支援使用CRM系統記錄資料時，大腦指揮，心髒提供能量，手指錄入，大腦、心髒、手指怎麼沒畫出來？因為當時的“靈感”沒顧及，是以選擇性忽略了。
圖4-10 系統内部的元件露出來了
另外一種抽象級别跳躍錯誤如圖4-11。要表達銷售支援使用CRM系統記錄客戶資料，隻需要在銷售支援和CRM系統之間畫一條消息“記錄客戶資料”就夠了。不過模組化人員剛好想到記錄客戶資料的過程會有多次互動，于是把這些互動步驟畫了出來。其實，圖的左側營運部和銷售支援打交道時也有多次互動，同樣被選擇性忽略了。
圖4-11 表達了過細的互動步驟
圖4-10中提到的系統内部的元件，應該在分析和設計工作流中描述；圖4-11中提到的互動步驟，應該在需求工作流中描述。
過早把不同抽象級别的知識混雜，大腦需要處理的邏輯就會從M+N+O+P增加到M*N*O*P。正确的做法是分開表達，這一點本書第8章還會進一步闡述。
4.2.3 隻畫核心域相關的系統
業務流程中涉及到的非人智能系統，遠遠比我們意識到的多，業務序列圖上隻能表現出其中一部分。例如，圖4-11中，營運部請求銷售支援處理客戶資料時，有可能是通過微信聯系的，那麼，微信需不需要作為一個業務實體出現在業務序列圖中？
大緻的判斷标準是：如果是核心域相關的系統，應該出現在業務序列圖中，如果不是，可以不出現。如圖4-13，從業人員制作文檔，還是從業人員用Word制作文檔？如果描述的是采購的流程，可能左側就可以，如果描述的是制作文檔相關的流程，可能應該畫成右側。具體問題還需要具體分析，是以以上用詞是“大緻”、“可能”。
圖4-13 Word要不要畫出來？
核心域/非核心域的概念，在後面的工作流中還會不斷提到，此處先不詳細讨論。有時很難判斷也沒關系，您想過這個問題，就已經比沒想過要好了！可以先畫出來，然後如果發現它跟改進無關，再把它删掉。例如圖4-13先畫出Word，後來發現從業人員用Word還是WPS制作文檔，不影響采購流程的改進結果，再把它删掉。
4.2.4 把時間看作特殊的業務實體
業務序列圖中，我們把時間看作特殊的業務實體。時間就像上帝造好挂在天上的一個大鐘，向全世界各種系統發送時間消息。這樣，就和後面需求工作流中映射系統用例的時間執行者一緻了，同時也幫助理清什麼情況下使用時間執行者的問題。
圖4-14 把時間當作一個系統
注意：時間和定時器不是一個概念。時間是外系統，定時器是其他系統用來和時間打交道的邊界類。世界上隻有一個時間系統，但有無數的定時器。有的模組化人員在識别系統用例時說“執行者是定時器”，這樣說是錯的，執行者是時間。
圖4-15 時間和定時器的差別