用例

那麼，到底什麼是Use Case呢？在UML的文檔中，Use Case的定義是：在不展現一個系統或子系統內部結構的情況下，對系統或子系統的某個連貫的功能單元的定義和描述。有點拗口，對吧？其實Use Case就是對系統功能的描述而已，不過一個Use Case描述的是整個系統功能的一部分，這一部分一定要是在邏輯上相對完整的功能流程。在使用UML的開發過程中，需求是用Use Case來表達的，界面是在Use Case的輔助下設計的，很多類是根據Use Case來發現的，測試實例是根據Use Case來生成的，包括整個開發的管理和任務分配，也是依據Use Case來組織的。

對不同的Actor來説，他要使用系統的某項功能也不同。所以，在識別和分析Use Case時，我們要對每個Actor逐一進行。對於ToDo User，我們可以輕易的識別出兩個Use Case：Add Task 和 Remove Task。ToDo User主動使用這兩個Use Case所描述的系統功能，所以在我們的Use Case圖上，ToDo User和這兩個Use Case的關係是用從ToDo User發出的箭來表示的。對於FileSystem，我們識別出的也是同樣的兩個Use Case，不過這次箭頭從Use Case指向FileSystem，表示FileSystem是被動的。

Use Case可以用很多方式來描述，我們可以用自然語言（英語，漢語，隨您的便），可以用形式化語言（哇！太酷了吧！），也可以用各種圖示。在UML中，通常用兩種圖來描述Use Case，它們就是順序圖（Sequence Diagram）和協作圖（Collaboration Diagram）。 ^[1] 

Use Case 由以下元素組成：

1.1 參與者和用例從用户的角度來看，他們對於系統的內部結構和設計的瞭解受到了限制，他們能夠接觸到的是系統所能提供的服務，也就是被開發出來的系統將是如何被使用的，這就用例方法的基本思想。用例模型主要由以下模型元素構成： 參與者(Actor)參與者是指存在於被定義系統外部並與該系統發生交互的人或其他系統，他們代表的是系統的使用者或使用環境。 用例(Use Case)用例用於表示系統所提供的服務，它定義了系統是如何被參與者所使用的，它描述的是參與者為了使用系統所提供的某一完整功能而與系統之間發生的一段對話。 通訊關聯(Communication Association)通訊關聯用於表示參與者和用例之間的對應關係，它表示參與者使用了系統中的哪些服務（用例），或者説系統所提供的服務（用例）是被哪些參與者所使用的。 以銀行自動提款機(ATM)為例，它的主要功能可以由下面的用例圖來表示。ATM的主要使用者是銀行客户，客户主要使用自動提款機來進行銀行賬户的查詢、提款和轉帳交易。 通訊關聯表示的是參與者和用例之間的關係，箭頭表示在這一關係中哪一方是對話的主動發起者，箭頭所指方是對話的被動接受者；如果你不想強調對話中的主動與被動關係，可以使用不帶箭頭的關聯實線。在參與者和用例之間的信息流不是由通訊關聯來表示的，該信息流是缺省存在的（用例本身描述的就是參與者和系統之間的對話），並且信息流向是雙向的，它與通訊關聯箭頭所指的方向亳無關係。

1.2 用例的內容用例圖使我們對系統的功能有了一個整體的認知，我們可以知道有哪些參與者會與系統發生交互，每一個參與者需要系統為它提供什麼樣的服務。用例描述的是參與者與系統之間的對話，但是這個對話的細節並沒有在用例圖表述出來，針對每一個用例我們可以用事件流來描述這一對話的細節內容。如在ATM系統中的"提款"用例可以用事件流表述如下：

1. 用户插入銀行卡 2. 輸入密碼 3. 輸入提款金額 4. 提取現金 5. 退出系統，取回銀行卡 但是這隻描述了提款用例中最順利的一種情況，作為一個實用的系統，我們還必須考慮可能發生的各種其他情況，如銀行卡無效、輸入密碼錯、用户賬號中的現金餘額不夠等，所有這些可能發生的各種情況（包括正常的和異常的）被稱之為用例的場景(Scenario)，場景也被稱作是用例的實例(Instance)。在用例的各種場景中，最常見的場景是用基本流(Basic Flow)來描述的，其他的場景則是用備選流(Alternative Flow)來描述。對於ATM系統中的"提款"用例，我們可以得到如下一些備選流：

備選流一：用户可以在基本流中的任何一步選擇退出，轉至基本流步驟5。

備選流二：在基本流步驟1中，用户插入無效銀行卡，系統顯示錯誤並退出銀行卡，用例結束。

備選流三：在基本流步驟2中，用户輸入錯誤密碼，系統顯示錯誤並提示用户重新輸入密碼，重新回到基本流步驟2；三次輸入密碼錯誤後，信用卡被系統沒收，用例結束。 … 通過基本流與備選流的組合，就可以將用例所有可能發生的各種場景全部描述清楚。我們在描述用例的事件流的時候，就是要儘可能地將所有可能的場景都描述出來，以保證需求的完備性。

1.3 用例方法的優點用例方法完全是站在用户的角度上（從系統的外部）來描述系統的功能的。在用例方法中，我們把被定義系統看作是一個黑箱，我們並不關心繫統內部是如何完成它所提供的功能的。用例方法首先描述了被定義系統有哪些外部使用者（抽象成為Actor），這些使用者與被定義系統發生交互；針對每一參與者，用例方法又描述了系統為這些參與者提供了什麼樣的服務（抽象成為Use Case），或者説系統是如何被這些參與者使用的。所以從用例圖，我們可以得到對於被定義系統的一個總體印象。 與傳統的功能分解方式相比，用例方法完全是從外部來定義系統的功能，它把需求與設計完全分離開來。在面向對象的分析設計方法中，用例模型主要用於表述系統的功能性需求，系統的設計主要由對象模型來記錄表述。另外，用例定義了系統功能的使用環境與上下文，每一個用例描述的是一個完整的系統服務。用例方法比傳統的SRS更易於被用户所理解，它可以作為開發人員和用户之間針對系統需求進行溝通的一個有效手段。 在RUP中，用例被作為整個軟件開發流程的基礎，很多類型的開發活動都把用例作為一個主要的輸入工件(Artifact)，如項目管理、分析設計、測試等。根據用例來對目標系統進行測試，可以根據用例中所描述的環境和上下文來完整地測試一個系統服務，可以根據用例的各個場景(Scenario)來設計測試用例，完全地測試用例的各種場景可以保證測試的完備性。 ^[2] 

Ivar Jacobson在1967年定義愛立信AXE系統的構架時開始書寫使用場境usage scenarios。

二十世紀八十年代中期Jacobson花了很多精力來思考過去十多年的工作方法。他造了一個術語anvendningsfall，大意是“使用情況”（situation of usage）或用況（usage case）。但當用英文出版的時候，他發現“useage case”在英語裏説不通，所以寫作用例“use case”。

用例是短文。

用例可以是一個場景，包括動作和互交。

用例可以是一組場景，描述不同場景下的行為。這種書寫格式可以在任何時候描述有變體的行為，例如黑盒需求，業務流程，系統設計説明。

用例裏不要有系統設計。

用例裏不要有界面設計。

用例裏不要有特性列表。

用例裏不要有測試。

用例應該描述行為需求。

用例的主場景不要超過九步。可以在適當的層次上得到子目標和移除設計説明。

用例的最大價值不在於主場景，而是在於備選行為。主場景可能只佔用例長度的四分之一到十分之一。

Use Case具有一個基本事件流（可稱為"理想路徑"）、多個例外流，包括：

基本變化

特殊情況

處理錯誤情況的異常事件流

Use Case 説明書應包括以下內容：

功能描述

可用性

可靠性

性能

可支持性

設計約束

試圖決定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看起來通常是不準確的或含糊的，作為測試説明的資源和參考，它也是很難使用的。

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

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

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

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

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

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

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

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

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

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

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

這裏是Use Cases的圖形符號描述，UML中一個單一的"Stick-Man"符號標示角色（Actor），用橢圓標示Use Cases，如這些圖對於你想看到Use Cases之間如何關聯的"大圖"和獲得系統上下文的大體描述來説是非常重要的。

Use Cases圖沒有顯示不同的場景，它們的意圖是顯示角色和Use Cases之間的關係。所以Use Cases圖需求用結構化敍述文本來補充。UML提供一些可供選擇的圖來顯示不同的場景，這些常規的圖形有交互圖、活動圖、順序圖、狀態圖等。使用這些圖的主要缺點是它們不象文本一樣是緊密的，但它們能用於給出Use Case的整體感覺。

是否每個Use Case 都包括至少一個actor？

是否每個Use Case 都獨立於其他Use Case？

是否每個Use Case 都有一個簡單的行為或事件流？

是否每個Use Case 都有一個唯一的、直觀的、可擴展的名稱，使它不至於在後期被混淆。

用户是否容易理解Use Case 的名稱和描述。

Use Case模型顯示系統中的Use Case與Actor 及其相互關係。其評價標準有：

Use Case 模型是可理解的嗎？

通過對Use Case 模型的研究是否能對系統功能有一個清晰的概念。

所有的actor都定義了嗎？所有的功能需求都滿足了嗎？

Use Case 模型是否存在多餘的行為。

從模型到Use Case包的劃分是否是恰當的。 ^[3] 

由於具有簡單的圖形符號、易理解的自然語言説明書，Use Case在文檔系統和軟件需求領域成為一 項越來越受歡迎的技術。Use Case對開發小組極具吸引力，即使小組成員對正式的需求文檔沒有經驗，但這些簡單性卻具有欺騙性，即使項目小組在開始使用Use Case 時沒有任何麻煩，當他們將其應用於大項目時常常會遇到許多同樣的問題。

使用 use case 十大誤區

2 如何避免以上問題

清楚的確定系統的boundary.

簡單來説，系統的boundary就像一個加了標籤的盒子，actor在盒子外，而Use Case在盒子內。我們稱之為系統的這個盒子究竟是什麼呢？一個計算機系統？一個應用系統？或一個完整的企業？…Use Case 可以用來合理地描述任意系統。但一次只能用來描述一個系統，在一個系統中恰當定義的actor和Use Case用於另一個不同的系統中就會出現錯誤。

使用標準模板書寫Use Case 説明書

Use Case 圖形符號已經被標準化並作為對象管理小組UML的一部分，但自然語言的Use Case 説明書還沒有被標準化。為了成功書寫Use Case 説明書，我們需要一個標準模板來保證Use Case 的一致性。

關注actor的真正目的，從actor的觀點而不是系統觀點來命名Use Case

面向Use Case 的需求與傳統的功能性系統需求之間最顯著的區別在於actor ，以面向Use Case的觀點，系統存在是由於actors 要通過該系統實現某些目標，actor與系統進行交互來實現其目標，我們將這些交互行為定義為Use Case 。

不要將Use Case 説明書與用户接口設計相混淆

有一種很流行的觀點：由於Use Case 是actors 與系統之間的交互，所以將所有的用户接口設計圖放在Use Case説明書中是一個好辦法。初看時，這的確很有用，因為它將在説明書中描述的actor/系統之間的交互行為以圖的形式表示出來，非常直觀。但是這樣做的負面影響卻遠遠大於其好處，用户接口設計可能會隨着時間而改變，我們不應該讓系統需求依賴於用户接口設計，相反地，用户接口設計應該滿足Use Case 需求。如果我們將用户接口設計置於Use Case 説明書中，當需求需要被認可和定為基線時，很自然地，這些設計元素可能仍然在改變，這就使得用户接口設計成為不完整的、不正確的和/或不一致的。

將用户接口設計置於Use Case 説明書還會出現另一個問題，為了在Use Case 之間和接口之間建立一對一的通信，我們會選擇反映用户接口的Use Case塊而不是反映用户目標的Use Case 塊，這樣，為了表達一個完整的用户目標，我們使用交互Use Case 關係，將不同的、基於用户接口的Use Case 聯接起來，結果在Use Case 模型中，我們得到了一幅類似蜘蛛網的關係圖。實際上，這副圖是用户接口説明圖，雖然它在系統文檔中是很重要的一部分，但他屬於用户接口設計文檔，而不是Use Case 需求文檔。

實現用户接口和Use Case 交互之間的鬆散耦合

鬆散耦合是比較合適的，低逼真度的用户接口圖有助於理解Use Case ，但要注意不要過度的將基本交互與用户界面機制相連，用户界面很有可能會改變。在功能説明書中，要注意actor做些什麼（如"提交請求"）而不是交互是怎樣完成的(如"雙擊提交按鈕")。

不要在Use Case 和用户接口之間建立通信

試圖在Use Case 和用户接口之間建立通信可能會存在潛在的、不正確的功能操作。Use Case 不僅與只能訪問某個接口的actor相聯，而且與那些能夠更新該接口的actors相連（這可能是例外流），結果就造成了不正確的功能操作。我們應該在基於實際用户目標和功能操作的基礎上拆分Use Case ，而不是在基於用户接口的基礎上組合Use Case ，只有這樣才能得到正確的Use Case 模型。

回顧Use Case 模型和Use Case 説明書，如果你不能防止所有的誤區，你應該儘早認識問題並確定問題

這個觀點並不是什麼新東西，有關代碼檢查的經典算法已有大約25年曆史了，但怎樣將其應用於Use Case 呢？ 首先，回顧Use Case 模型，回顧一下Use Case 的簡單説明（Use Case 名稱、目標、簡單描述）。這項工作應在繪製草圖時儘早執行，並在寫詳細的Use Case 説明書之前完成。接着是回顧Use Case 草圖，保證圖是正確的，並且詳細的Use Case説明書是完整的。最後是正式回顧最終的Use Case 圖和Use Case 説明書。

我們發現這種三階段式回顧比單一的"宇宙大爆炸"式回顧有效，在我們花大量的時間寫説明書之前，Use Case圖中存在的許多實質性問題可以被發現，這種方法減少了當需求改變時需要做的重複工作。 ^[4] 

主要行為者（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，如性能需求和系統容量的需求。另外的一些不是關聯的而是要單獨地去捕獲，它們是以下的需求：

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

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

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

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

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

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

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

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

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

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

Use Case 是系統提供的功能塊，換句話來説Use Case演示了人們如何使用系統。通過Use Case觀察系統，能夠將系統實現與系統目標分開，有助於瞭解最重要的部分――滿足用户要求和期望，而不會沉浸於實現細節。通過Use Case 用户可以看到系統提供的功能，先確定系統範圍再深入開展項目工作。 ^[6]