OO系統分析員之路--用例分析系列（7）--用例規約的編寫--商務規則和實體描述

先說說商務規則。筆者習慣將商務規則分為三種。

一種是全域規則，這種規則一般與所有用例都相關而不是與特定用例相關，例如actor要操作用例必須獲得相應的授權，用例的操作與授權層級相關，或者使用者在系統中的所有操作都要被記錄下來等等。這類規則筆者習慣於，並且也建議將它們寫到用例的補充規約裡面去，因為它們一般與具體的業務功能性要求沒有直接關係。有時候，這類規則也被寫到軟體架構文檔中。關於用例補充規約以後再討論。

第二種是互動規則。這種規則產生於用例情境當中，例如當提交一份定單時，哪些資料是必須填寫的，使用者身份是否合法。當然也包括一般理解上的商務程序流轉規則等，例如金額大於一萬元的定單被定為VIP定單進入特殊流程等。這類規則一般要寫到用例規約中。互動規則實際上還有兩個是比較特殊的，一個允入準則，也稱為前置條件，即actor滿足什麼條件才能啟動用例;另一個是出口條件，也稱為後置條件，即用例結束後會產生哪些後果。稍後參看樣本。

第三種是內稟規則。所謂內稟規則是指業務實體本身具備的規則，並且不因為外部的互動而變化的規則。例如，每張定單至少要有一件商品，同一類商品數量不能大於5件等。同時也包括大家所熟悉的資料效驗規則，例如社會安全號碼必須是15或18位，郵編必須是6位等等。這類規則是業務實體的內在規則，因此應該寫到領域模型文檔中，稍後參看樣本。

讀者或許對把規則這麼分類有不同的習慣和理解，可能會覺得麻煩。但是筆者這麼做有充分的理由。首先，全域規則與具體用例無關，它實際是系統應該具備的特性，這些規則把它分出來目的就是為了讓系統去負責這些特性的實現。讀者可以結合實際考慮一下，通常授權，事務，備份等特性都是由系統架構去實現的，具體的功能中並不去實現它們。如果讀者有過基於某個架構開發應用的經曆的話一定會認同筆者的話。其次，互動規則是在用例情境當中產生的，它們規定了滿足什麼條件後業務將如何反應。通常，這部分規則是最複雜，也最不穩定，最容易變化的。大家所說的需求經常變更相信絕大部分就來自於此。因此將這些規則單獨列出來並給予關注和管理是很有必要的。同時這部分規則通常在系統中以Control類去實現，MVC模式如此，SOA架構中的BPEL也是如此。如果需求無可避免的要變更，那麼，將互動規則單獨提取出來，並設計成為擴充性很強的結構就是一種有效應對手段。第三，內稟規則與外部互動無關，不論誰，在什麼情況下提交定單，必須有至少有一件商品；不論你在哪個國家，在什麼公路上開車，刹車都是必不可少的。這種內在的性質讓你想到了什嗎？物件導向的封裝原則對嗎？這類規則應該實現到你的實體類中去，不論你的業務實體是EntityBean,JavaBean,POJO還是COM+，根據物件導向的封裝原則，內稟的邏輯一定不要讓它暴露到外部去。

這麼分類以後，對軟體成熟度等級比較高的組織來說，提供了很好的Level Reference。如果你是架構師，應該關注的是全域規則；如果你是設計師，應該關注的是互動規則；如果你是程式員，應該關注的是內稟規則。

在這裡筆者想說點題外話：）。筆者曾經看過一篇《架構師已死》的文章(很抱歉已經記不起出處和作者，如有冒犯之處請海涵)，作者的觀點認為架構設計完成後，通常到最後改得面目全非，既然一開始不可能考慮到所有可能，何不如在開發過程中持續總結，重構，最後架構會自然而然出來的，如果這樣，架構師有何用處呢？筆者認為這個說法是有一定道理的，不過要看軟體組織架構和軟體過程的定義，不可一概而論。《架》一文的作者是XP的fans，對XP軟體過程來說，本來就不需要架構師這個角色，甚至連設計都不需要，開發，測試，改進，重構...，當然，從一開始就沒打算按照一個stable的方法去做，架構師也就沒有存在的必要。架構師在XP中已死，不過在RUP中還活著：）。軟體界一直對XP和RUP有著爭論，筆者無意在本文中界入這個爭執，只是話已經到此，就順便表達一下筆者觀點。XP和RUP都是非常優秀的軟體方法，只是它們各有各的適應範圍。對於中小型公司和中小型軟體來說，XP是非常有效管理方法，它能大大降低管理、開發成本和技術風險。不過要是對於大公司和大型項目來說，XP就不適用了，這時RUP卻非常適合。你能想象洛克希德·馬丁公司用XP的方法來開發F-35戰鬥機會是一個什麼情形嗎？沒有人清楚的知道將來的飛機整體是什麼樣，反正先造一架出來，摔了找找原因，改進改進，重構一下，再造一架....再摔了，沒關係，咱們擁抱變更，再造就是了。呵呵，那XP什麼情況下適用呢？如果你是一個雜貨店的老闆，不知道什麼樣的商品受歡迎，沒關係，先各進一小批貨，賣上一段時間，受歡迎的貨品多進，不受歡迎的不進，跟顧客多交流，顧客喜歡什麼商品咱就進什麼，不斷改進，最後一定會顧客盈門的。這時如果這個老闆先做商務分析，客戶關係分析，消費曲線分析....還沒開業呢，估計就破產了。另外，RUP和XP也不是非此即彼的關係，在造F-35的過程中，對整體飛機來說，用RUP是適合的，具體到發動機的供應商，倒是大可XP一把，最終只要提供合格的發動機就OK了。

題外話說了不少，書歸正傳。商務規則分類以後，就應該按分類去調研了。

全域規則很難從使用者處調研得來，通常這方面是使用者的盲點。這主要是由有經驗的系統分析員，或架構師以及客戶方的IT部門(如果有的話)，從業務特點、應用環境、行業規定、法律規章等等方面去總結，再求得客戶方的認可。

互動規則從用例情境而來，每一個情境，情境中每一個互動的過程可能都隱含著規則。這就需要與客戶多討論。請參考本系列文章的第3篇關於涉眾的討論，互動規則最主要的來源是業務提出者和業務管理者，最好不要去找業務執行者。

內稟規則是針對業務實體的，因此要對每個業務實體的屬性進行羅列，並找出它們的規則。內稟規則最主要的來源是業務執行者，需求人員應該更多的去與他們交流。

現在來談談業務實體的屬性。業務實體的屬性在這個階段應該用業務術語來描述，而非電腦術語。調研範圍是上一篇模型中得到的領域模型中的每一個實體，而屬性的原始來源是客戶的各類實際表單，以及在交流過程中客戶提出的各種要求。如果業務實體有狀態，並且是比較複雜的，那麼在建模的時候應該有一個狀態圖來說明。請參看本系統文章提供的建模執行個體中'圖書'業務實體下面的狀態圖。請讀者注意，在本文後面提供的例子中，業務實體描述看上去象是一張資料表，但它絕對不是資料表。它是對業務中實體屬性的業務角度描述。系統分析不是做設計，腦子裡不要有任何關於設計或實現方法的想法，這些想法會誤導你做出不適合的決定。你的職責是通過一個合理的模型完整的將業務描述出來，並求得客戶方的認可。任何替客戶和架構師，設計師甚至程式員“著想”的方法其實都是不恰當的。

最後本文提供一個用例規約的例子，每個用例都應該寫一份用例規約。本文提供的這個例子基本上來自RUP提供的模板，不過在實際工作中筆者做了些修改，供讀者參考。這個例子的藍本還是本系統文章一直在使用的網上圖書館的執行個體。點這裡下載用例規約例子，點這裡下載建模執行個體。

到這裡，需求過程差不多也該結束了。但是我們的確還有一些工作要做。如果讀者所工作的組織是用RUP來做需求的，而客戶方或者監理方未必會對這種需求文檔表示滿意。他們會以國標來要求你。同時，到目前為止，我們產生的成果都是一些分離的圖形和文檔，對於客戶來說，這的確是不好的文檔結構。難道客戶的採購清單裡還需要包括Rational Rose，這樣才能閱讀你提供的需求文檔嗎？顯然這是不可能的，所以，給使用者提供的文檔還是以傳統的《需求規格說明書》為好。下一篇就討論一下如何將我們的分析成本整合到《需求規格說明書》中。順帶討論一下用例補充規約和系統原型的產生以及它的作用。敬請期待。