用例

，底 ？檔， 義：展系統系統構況，系統系統某連貫功單元義描述。拗，吧？ 系統功描述， 描述整系統功，邏輯完整功流程。程，需求 達， 輔助設計，類根據 ，測試例根據 ，包括整管務配，依據 組織。

，系統某項功。，識析 ，逐。 ，易識 ：    。  描述系統功， 圖，  系 箭示。，識 ，箭 指，示。

 式描述，語言（語，漢語，隨您），形式化語言（哇！酷吧！），各圖示。，圖描述 ，順序圖（ ）協圖（ ）

元素組成：

名稱

簡單描述

事件流

關係

活動圖和狀態圖

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)來設計測試用例，完全地測試用例的各種場景可以保證測試的完備性。

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包的劃分是否是恰當的。

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

1 使用 use case 十大誤區

1． 系統的boundary 沒有定義或經常改變；

2． 從系統觀點而不是actor觀點來定義Use Case；

3． Actor的名稱不一致；

4． Use Case 定義過多；

5． Use Case 和actor之間的關係像蜘蛛網一樣錯綜複雜；

6． Use Case的說明太長；

7． Use Case的說明不清楚；

8． Use Case沒有正確的描述功能需求；

9． 用戶無法理解Use Case；

10． 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圖中存在的許多實質性問題可以被發現，這種方法減少了當需求改變時需要做的重複工作。

主要行為者（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”

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

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

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

用例將系統的功能範圍分解成許多小的系統功能陳述。

一個用例代表了系統的一個單一的目標

用例是一個行為上相關的步驟序列

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