第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等結構化控制片斷來描述業務流程，強迫模組化人員用這種方式去思考。對于現狀确實亂七八糟的流程，描述起來相對要困難，甚至需要按照場景分開畫很多張序列圖來表達，但這也揭示了業務流程的糟糕現狀。