1. 程式人生 > >需求用例分析之七:業務用例之小結

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

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的業務用例。在筆者親自參與的專案中,都是直接採用用例(系統用例),而在處理複雜並且不熟悉的業務時,繪製流程圖、活動圖等等來作為理解業務的載體。

更多相關文章