用Use Cases捕獲需求

用Use Cases捕獲需求 

Pete McBreen，譯：UMLChina.蘇康勝（cancan28@163.net） 



概述 

開發者們經常通過一些典型的情節去理解系統并知曉系統如何工作，不幸的是他們雖然努力地去做了這些工作卻很少以一種有效的方式去說明，Use Cases正是一種形式化捕獲這些情節的技術。 

僅管Use Cases在一本對象方面的書《Object Oriented Software Engineering》中有過定義，是跟那些對象結合在一起的，但這項技術實際上是獨立于面向對象的，Use Cases是既能捕獲商業處理流程又能捕獲系統需求的有效方法，并且它本身比較簡單和容易掌握。 



使需求有利于回顧 

以正規形式捕獲這些情節的原因是有利于用戶和開發者進行回顧，這里有2點關于一些實用需求符號的明確標準要遵循： 

1） 它必須讓情節的發起者和回顧者都很容易理解 

2） 它不需包括一些關于系統樣式和內容的決策 

實用的需求是評估設計和最終實現系統的客觀需求。 

對于這些需求來說，必須要做的是以一種可實現的并不受約束的方式去捕獲風險承擔者的需要和期望。 

Use Cases使需求有利于回顧 

Use Cases已經得到越來越廣泛的應用，它與其它需求捕獲技術相比，它成功的原因在于： 

1  Use Cases把系統當作一個黑盒 

2  Use Case 使在需求中看到實現的決定變得更加容易 

最后一點源于第一點的補充，一個Use Case沒有指定任何這些需求相關的系統的內部結構，所以說，如果這個Use Case中陳述了“提交改變到定單數據庫”、“顯示結果到Web頁面”等的話，那么內部結構是顯而易見的，并造成對設計的潛在約束。 

為什么這些需求不指定內部結構的原因是，說明的內部結構給設計者帶來了額外的約束，沒有這些約束設計者們能更自由地建立一個正確實現客觀可見行為的系統，并存在出現突破方案的可能性。 

Use Cases的工業接受 

Use Cases第一次被正式的描述是在6年前（1992年），從那以后它就被最主要的面向對象的方法采用，同時作為描述現在和將來的操作模式的有用技術被商業再生工程團體（Business Process ReEngineering Community）采用。 

Use Cases最近它們自己取得在UML（Unified Modeling Language）中有效的地位和位置而得到了突出的進步。UML已經被OMG（對象管理組織）計劃做為對象系統的標準語言。 

什么是Use Cases？ 

Use Cases本身是用戶或其它系統與正在設計的系統的一個交互，是為了達到一個目標。術語Actor（行為者）是用來描述有這個目標的人或系統，這個術語是用來強調有這個目標的任何人或系統。目標的本身是用行為動詞開始的短語表達的，如：“Customer : place order”、“Clerk : reorder stock”等。 

情節的角色 

在Use Cases中不同的情節顯示了目標怎樣成功或失敗，成功的情節是目標達到了，失敗的情節是目標沒有達到。這個的好處是因為目標總結了系統的各種使用的意圖，用戶能看到被設想怎樣地使用這個系統，并且不必等到出現第一個原型或是比較糟糕的等到系統被開發出來才發現什么時候系統并不全面地支持他們的目標。 



Use Cases將做成多大？ 

試圖決定Use Case的大小是一個很有趣的話題，處理這件事的一個方法是將Use Case的大小跟它的意圖和范圍關聯起來，對于一個真正大的范圍來說，一個Use Case并不要在一個系統中處理那么多，但這些系統都用于同一商業領域，稱為Business Use Case，它把整個公司看作一個黑盒和Actor關于公司目標的說明。這些Business Use Case的情節不容許假定任何公司內部的結構，一個客戶將向公司下一個定單而不是客戶服務部門。 

對于系統發展而言，Use Case的范圍限制一個單一的系統，這是Use Cases最通常的形式，我們稱之為System Use Case，它把整個系統看作是一個黑盒，它不指定任何內部結構并且僅受限于問題域的語言描述。 

Use Cases的另一范圍是設計子系統和系統內部組件的，稱為Implementation Use Cases，它把組件看作一個黑盒，并且這些Actors是區分它的成員。例如：可能會用Implementation Use Cases去說明應用系統中email組件的需求。 

給出了這些分類，關于Use Case的大小話題變得容易了，設計這些項的范圍來調整整個大小。幫助系統設計者，每個Use Case只描述沒有大的分支的行為的單個線索。違背這個規定，Use Case看起來通常是不準確的或含糊的，作為測試說明的資源和參考，它也是很難使用的。 

看看System Use Case的例子，“從數據庫中查詢低庫存的”它太小了，容易跟需求的實現細節混淆。對比一下，作為System Use Case，“倉庫管理”就太大了，它不能實現作為沒有大的分支的行為的單一線索的原則，并且從系統的觀點來說，它很難說明成功的目標，但它可以做為一個好的Business Use Case，對于配件部門來說，它可以定義“倉庫管理”這一成功的目標（可能是根據庫存調整、配件驗收、成本操作等）。 

這些Business Use Case的好處是它們能用于區分其它的Use Cases，就如：“倉庫管理”可用于組織這些用于實際管理倉庫的Use Cases。 

Use Cases的正式定義 

Use Case：特殊行為者（Actor）的價值的量化結果的提交 

正如前面所說的，Actors可以是人也可以是正在設計的系統與之交互的外部系統，一個Use Case要求有一個量化的結果，從單個線索的需要提交。做為量化結果的組成，目標要么成功要么失敗，沒有其它的情況。 

達到主要Actor的目標定義為成功，結果沒有迎合主要Actor的目標定義為失敗，不同的情節顯示了成功或失敗的途徑。 

Use Cases的說明 

Use Cases的好處是一些情節能用不同程度的正規化的文字說明。每個情節涉及Use Cases中單一的途徑，細節是條件組。 

不正規的文本描述也能使用，不過當條件較多和可能失敗的情況下它們很難跟隨下去。開始試圖理解需求時，不正規的敘述風格也是非常有用的，然而隨著Use Cases的進展，使用更加正規的機制去說明Use Cases才是有用的。 

下面是客戶對Use Case“下定單”的粗略概略： 

“確定客戶，找出需要的并且倉庫里還有的物品并檢查客戶信用額是否夠用” 


　結構化敘述的格式已經被證明是非常有效的。這個格式所做的事是描述每一個情節的行為者：目標語句對的順序。在這個順序中，每一個行為者：目標的語句對都假設前一個的目標是成功的，右面是一個簡單的范例： 

Use Cases認為我們正在設計的系統是一個單一的黑盒，根本沒有任何內部結構被記錄下來，并且它被認為是一個情節產生的目的及對應單一的行為者（Actor）。這些Use Cases沒有表示任何關于系統內部的東東，只是表示系統將達到什么樣的目標及由什么（人或其它系統）操作和負責。





處理目標失敗-----延伸部分 

下面要做的是確定以上的每一步中可能會發生的失敗，對于這種情況那些可能造成失敗的條件做為延伸部分來捕獲。這些擴展是通過在失敗條件下直到可以重新入軌或失敗的情節來處理的。 

失敗條件的分離使情節變得可讀了，一般情況都是以最簡單的途徑通過Use Cases的，它的每一步，行為者（Actor）的目標都是成功的。分開列出所有可能造成失敗的條件給予了更好的品質保證�；仡櫿呖梢院苋菀椎臋z查是否所有造成失敗的條件都被指定及哪些潛在的條件被忽略。失敗的情節要么可以恢復要么不可以恢復，可恢復的情節最終取得成功，不可恢復的情節直接失敗。 



失敗中的失敗 

當失敗情節下還有其它失敗發生，需特別的標示出來，也就是說，在延伸部分中用更長的前綴標記更深一層的失敗情節，如：1a1b、客戶是個不講信用的，它的恢復通過1a1b1。 



為什么使用結構化敘述格式 

結構化敘述的價值在于它是可駁倒的描述，所謂可駁倒的描述是它足夠明確，以至可以給人去爭辯和提出異議。 

“流程不是那樣的” 

“為什么開單之前不檢查是否有用呢？” 

“你少了好幾步哦” 

對比之下，那種用非正規敘述形式描述的粗略概略是很難去駁倒的，但它有利于早期對問題域的理解。 

可駁倒的描述方式的價值的另一種描繪是，當你說明Use Cases時期望從用戶和開發者處獲得關于Use Cases品質的反饋。自想在開發過程的中及早的得到修正，它是非常有價值的。用戶典型的反饋是不同順序的問題，可能是平行的或是缺少的步驟。開發者典型的反饋是關系到特殊失敗條件的意思和如何檢測到它是否清晰的要求。 



Use Cases的圖形符號 

這里是Use Cases的圖形符號描述，UML中一個單一的“Stick-Man”符號標示行為者（Actor），用橢圓標示Use Cases，如圖一所示。這些圖對于你想看到Use Cases之間如何關聯的“大圖”和獲得系統上下文的大體描述來說是非常重要的。 



Use Cases圖沒有顯示不同的情節，它們的意圖是顯示行為者和Use Cases之間的關系。所以Use Cases圖需求用結構化敘述文本來補充。UML提供一些可供選擇的圖來顯示不同的情節，這些常規的圖形有交互圖、活動圖、順序圖、狀態圖等。使用這些圖的主要缺點是它們不象文本一樣是緊密的，但它們能用于給出Use Case的整體感覺。對于這些圖的協定的參考請見《UML Distilled》，作者Martin Fowler。 



需求重用取得 

按行為者：目標（Actor：Goal）的格式來描述Use Case的作用是它容許公共的功能性分解出來做為獨立的Use Case。當執行公共部分的時候是指用于主要Use Case的。比如：Use Case下定單中的“確定客戶”這一步驟可以用于其他Use Cases。 

Use Cases之間的另一關系是“延伸部分”，如果Use Case有一個失敗恢復的步驟是復雜的，通常有三、四步，說是一個Use Case去擴展另一個Use Case。比如：當沒有可用庫存時，“Issue Raincheck”可能擴展Use Case“下定單”。 



Use Cases應用當中的復雜性和危險 

主要行為者（Actor）和Use Case之間沒有連結 

一些情況下，從Use Case中取值的行為者（Actor）和積極參與這個Use Case的行為者（Actor）之間沒有清晰的連結。如：財務主管能成為“發票確認”的行為者（Actor），但他未必是創建發票的人。這不是什么問題，這個Use Case仍然是正確的，它正說明行為者取值和設計的系統的范圍外的Use Case發生的初始化之間的關系。主要行為者是有用的，因為這個人扮演的角色是當你說明Use Case時需要跟他說的人。 



情節步驟不需要連續 

情節中步驟順序的情況是沒問題的，這里有一些機制去突出可能的并行步驟。在UML中活動圖是首選的機制，通過非正式地看Use Case的情節你可以注意到可能的平行步驟；可以看Use Case內一些鄰近的步驟；也可以有相同的行為者（Actor）對步驟負責。之前我們舉過的例子里，確認數量和確認信用額可能是平行的。有時候在Use Case的說明文檔中標記這些可能的平行步驟是有用的。 



Use Cases的大小 

當開始做Use Cases的時候有個很顯然的危險就是它要么有很多步驟要么就很少步驟。如果在Use Case中有超過15個步驟，它可能包含一些實現明細。如果它只有非常少的步驟則檢查它的目標是否是達到一個沒有很多分支的活動的單一線索。 



較少的人類行為者（Actor） 

如果Use Case有較少的人類行為者，而大多數行為者是其它系統，通常的做法是修改這個Use Case。尋找系統必須做出反映或公認的事件勝過會見這些行為者。 



需求捕獲和系統復雜性 

總而言之，這些情節捕獲到系統復雜度的同時行為者：目標語句對容許大的系統以相對壓縮的格式說明。Use Case的格式的作用是用戶和開發者能標志出行為者，然后確認這些行為者工作職責對應（或不對應）的目標，代替一個大的很難讀的功能規格說明書。 

僅僅這樣，用戶和開發者就有足夠的興趣進而研究那些情節的細節。 



系統不僅僅有應得的功能性需求 

一些Use Cases并沒有捕獲所有的客觀需求，僅僅是捕獲了系統怎么用的那些功能性需求。然而還有許多方面的需求需要去捕獲的。其中有的非功能性需求使用關聯以至于也能隸屬于個別的Use Case，如性能需求和系統容量的需求。另外的一些不是關聯的而是要單獨地去捕獲，它們是以下的需求： 

l 系統范圍 

l 系統用戶的目標 

l 用戶界面原型 

l 一般規則 

l 約束 

l 算法 



運行時期和建立時期的需求比較 

一個重要的因數要記住，就是系統的贊助者是大過用戶團體的。系統中有許多的風險承擔者，Use Cases僅僅捕獲其中一些風險承擔者的需要，具體說，Use Cases僅僅捕獲系統運行時期的需求而忽略做為系統開發組織的風險承擔者的需求，開發組織最有興趣的是對建立時期需求的描述。 

運行時期需求包括：系統范圍、用戶組織對產品的期望和目標、Use Cases、其它非功能性需求。 

建立時期需求包括：減少開發成本、較少的變更處理、現存組件的重用。 

建立時期的需求可以部分的由Use Cases把握。但許多方面是需要由開發組織的處理的。 

l 項目范圍和目標：項目必須提交什么。（和系統范圍的區別是它提交的是所有項目的東西） 

l 增長性和變更請求：這些可以在捕獲為常規Use Cases格式中的“Change Cases” 

l 開發負責人的約束：包括標準、習慣、工具、品質度量標準、品質保證原則、及品質保證的習慣。 



Use Cases的適用性 

Use Cases首先用于需要響應客觀事件的系統。它們能用于提供了一個有很容易理解的目標的清楚的行為者的環境。當結果不可定義或不清晰時不能用Use Cases。意思是如果目標成功或目標失敗不能有一個明確的定義，那么Use Cases不能用來捕獲需求。 

然而說到這，現在大部分對象方法都使用Use Cases。因為Use Cases被證明是捕獲需求的非常有效的機制。 



總結 

Use Cases以一種可讀的、可駁倒的格式捕獲需求。Use Cases是系統客觀必需機能的可駁倒的描述。 

可駁倒的意思是當你說明Use Cases時期望從用戶和開發者處獲得關于Use Cases品質的反饋。 

Use Cases并沒有從一開始就就明確的定義，它主要的開發順序如下： 

1、 指出行為者（Actor） 

2、 指出行為者的目標 

3、 指出每一行為者：目標語句對的成功或失敗的意思 

4、 指出每一Use Case的主要的成功的情節 

5、 在細化階段，指出失敗的條件及可恢復/不可恢復的情節 

只有做到了第四步才能決定哪一些的東西在Use Case中逐步開發出來。 



總而言之，Use Cases是非常有效的需求捕獲技術，它能使需求變得容易回顧，并且避免在需求中有實現細節的偏好出現。 



對照表：