作者：張克強??? 作者微博：張克強-敏捷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系

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

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

總結

以上是生活随笔為你收集整理的需求用例分析之七：业务用例之小结的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。