需求用例分析之七：業務用例之小結

作者：張克強    作者微網誌：張克強-靈活307

RUP雖然對于業務對象模組化進行了詳細的說明，但其本身并沒有把業務對象模組化（領域模型）、業務用例作為必須的工件。Rational系方法把業務用例作為需求規格說明（SRS）前的推薦工件。    

在《編寫有效用例》中，業務用例被放在很次要的位置，前面提到雲朵和風筝時，科伯恩并沒有清晰的指出這是業務用例，相反的還是在系統範圍内讨論用例。而且科伯恩還指出了2大“壞消息”。

Dean Leffinwell, Don Widrig所著《軟體需求管理用例方法》第2版中的一個小節：何時使用業務模組化：業務模組化不是我們對每個軟體工程工作的推薦。當應用環境是複雜而且橫跨多領域，并且許多人員直接參與到系統使用，業務模組化帶來最大價值。比如，如果你在一個既有通訊交換器上添加一個補充功能，你沒有必要考慮業務模組化。另一方面，如果你要為GoodAreUs建設訂單入口系統，那麼進行業務模組化為支援問題分析帶來好處。

附加說明，《軟體需求管理用例方法》書中前文是采用業務用例來進行業務模組化的，這與RUP是一樣的，此書總共502頁，業務模組化章節占了8頁。

在Frank Armour和Granville Miller的《進階用例模組化卷Ⅰ:軟體系統》一書中，沒有提及業務用例，有意思的是，提出了“發現概念層次的系統用例”，并且與科伯恩利用目标幫助識别用例的方法聯系起來了。這與《編寫有效用例》其實是一樣的觀點，《編寫有效用例》在前面說明不同目标的用例，并沒有提到業務用例，所分析範圍其實是在系統範圍内，恰是符合此書提出的“概念層次的系統用例”。

在KurtBittner，Ian Spence《用例模組化》（出版社 清華大學出版社，出版時間 2003-5-1）中，全書同樣沒有提及業務用例，其提出描述問題領域和環境的關鍵概念是必需的，有三種形态：1，簡單的文本詞彙表；2，正式的領域模型；3，帶有圖檔說明領域模型的文本詞彙表。從其說明可以看出，正式的領域模型包括業務用例。

Doug Rosenberg / Kendall Scott 的《UML用例驅動對象模組化》（出版社: 清華大學出版社

出版年: 2003-7-1），也即是著名的ICONIX方法，全書同樣沒有提到業務用例。

高煥堂編著的《USE CASE入門與執行個體》（2008年出版)全書沒有提到業務用例。

徐峰的《軟體需求最佳實踐》（ 出版社: 電子工業出版社 出版年: 2008）使用其它方式進行業務流程分析，沒有提到業務用例。

邱郁惠著的《系統分析師UML用例實戰》（2010年出版）是一本用例分析入門書，全書沒有提到業務用例。

譚雲傑的《大象Thinking in UML》第2版，全書有526頁，書中前後花費了17頁來說明了業務用例，其中提到“并不是所有的軟體需要從業務用例模組化開始”，其17頁中的将近一頁來是用來說明使用和不使用業務用例模型的理由，核心内容與Dean Leffinwell, Don Widrig所著《軟體需求管理用例方法》中的“何時使用業務模組化”是一緻的。

在某本我不願意提起書名但口氣超大的書中，花了前面的131頁來談業務模組化，而後面的需求分析占領101頁，是衆多用例類書的特例。

在最新的Use-Case 2.0中，業務用例在後半段被提到了一次，重點放在了引入Use-Case Slice。

通過以上，可以清楚的看到，業務用例在用例分析中的位置：1，不是必需的；2，可被替代的。

就筆者親身經曆而言，除了在RUP材料與及Rational後續文章中看到較好的業務用例之外，就沒有在實際使用中看到過合乎RUP的業務用例。在筆者親自參與的項目中，都是直接采用用例（系統用例），而在處理複雜并且不熟悉的業務時，繪制流程圖、活動圖等等來作為了解業務的載體。

更多相關文章

需求用例分析之一：異常流

需求用例分析之二：級别設定

需求用例分析之三：補充規約

需求用例分析之四：業務規則

需求用例分析之五：業務用例之Rational系

需求用例分析之六：業務用例之科伯恩系

需求用例分析之八：用例顆粒度