http://blog.csdn.net/huaishu/article/details/39249383

活動圖，更準確地說是活動圖的“山寨版”——流程圖，應該是在開發人員中使用頻率最高的圖形了。

如果流程圖用來表示組織內部各系統（崗位）之間的協作，即業務流程，那就變成了業務流程圖，接近於活動圖。活動圖可以看作是流程圖的擴充套件，添加了分割槽（Partition，即UML1.x中的泳道）、分叉（Fork）、結合（Join）等元素，UML2.x進一步增加了Petri網的元素，表達能力更加豐富。

序列圖用面向物件的思想描述業務流程，把業務流程看作是一系列業務物件之間為了完成業務用例而進行的協作。

我剛開始為開發團隊提供服務的前幾年，講授描述業務流程的技能時選擇的是活動圖，2005年10月以後，改成了序列圖，所以本書主要採用序列圖來描述業務流程。做出這個選擇基於以下幾點理由：

（1）活動圖只關注人，序列圖把人當作系統。

軟體開發的目的就是要改進當前的現實，可能是引進一個新系統，也可能是升級現有的系統。資訊化發展到今天，待改進的當前現實中不只有人肉系統（即業務工人），還有大量的非人系統（即業務實體），這些非人系統封裝了許多最開始位於人肉系統中的邏輯。將來和新系統互動的系統（也就是新系統的執行者），有可能只有一部分是人，另外一部分是非人系統。網際網路的發展，更是使得許多商業或政府組織用來和大眾打交道的介面系統不再是人肉系統，而是電腦系統。

使用活動圖描述業務流程時，開發人員往往只注意人或部門的活動，忽略了非人系統的責任。待改進的現實中，會計記錄報銷單和出納記錄付款資訊都需要用到現有的電腦系統SCS，活動圖圖4-1未能表達出來，序列圖圖4-2表達出來了。雖然活動圖可以稍作變通，將非人系統也單列為分割槽

（2）活動圖表示動作，序列圖強迫思考動作背後的目的。

圖4-5不但表達了非人系統的責任，同時也清晰地揭示出來營業員這個崗位對外暴露的責任是：受理申請，這也是市民對於營業員的期望。期望和承諾，是用例和物件技術的關鍵思想。使用序列圖來做業務建模，“物件協作以完成用例”的思想就可以統一地貫徹業務建模和系統建模的始終。

（3）活動圖更“靈活”，序列圖更不“靈活”。

不少人認為活動圖勝過序列圖的地方是它靈活，我開始也是這麼認為，但現在我的觀點是：這種靈活是一把雙刃劍。活動圖很靈活，它的控制流箭頭可以指向任何地方，就像編碼原始時代的Goto語句，所以活動圖很容易畫。不過，“很容易畫”的活動圖，也比較容易掩蓋開發人員對業務流程認識不足或者業務流程本身存在缺陷的事實。

序列圖通過alt、loop等結構化控制片斷來描述業務流程，強迫開發人員用這種方式去思考。對於現狀確實亂七八糟的流程，描述起來相對要困難，需要按照場景分開畫很多張序列圖來表達，但這也揭示了業務流程的糟糕現狀。

這裡引出建模的一個基本原則：抽象級別一致。開發人員在建模和討論問題時，經常是想到哪畫到哪，打哪指哪，抽象級別和研究物件一會跳到這裡，一會跳到那裡。你跟他講業務流程，他跟你說系統；你跟他說系統，他跟你談類；你跟他談類，他跟你講業務流程……

瞭解繪製業務序列圖的一些要點後，我們開始來繪製改進前的、也就是現狀的業務序列圖。

4.3.1 錯誤：把“現狀”誤解為“純手工”

許多建模人員畫的業務流程中，只有人，沒有非人系統。前文已經闡述過，人只是系統的一種，現在這個時代的業務流程中，非人系統承擔的責任越來越大，以後我們要開發的新系統，很可能只有一些介面是和人肉系統打交道，另外一些介面是和非人系統打交道。

4.3.2 錯誤：把“現狀”誤解為“規範”

建模人員在建模業務流程時，照搬組織制定的規範，沒有去觀察實際工作中人們是如何做的，或者即使觀察到了人們實際沒有按照規範做，卻依然按照規範建模。這樣做，得到的業務流程是不真實的。上有政策，下有對策，人們在工作時往往會想出一些巧妙的方法，來規避不合理或對自己有損的規範，這些方法中的合理部分就值得計算機系統學習。如果視而不見，也就喪失了許多有價值的改進機會。

4.3.3 錯誤：以待開發系統為中心拼湊流程

業務建模就是要從業務流程中找到待開發系統的位置，證明您的系統如果有這些功能，對實現業務用例是有幫助的。這樣，這個系統就能賣得出去。如果已經認定了系統有這些功能，直接畫系統用例圖不就完了嗎，還裝模作樣做業務建模幹什麼呢？