中科永聯高級技術培訓中心（www.itisedu.com）
Use Case（用例）是一個UML中非常重要的概念，在使用UML的整個軟體開發過程中，Use Case處於一個中心地位。
那么，到底什麼是Use Case呢？在UML的文檔中，Use Case的定義是：在不展現一個系統或子系統內部結構的情況下，對系統或子系統的某個連貫的功能單元的定義和描述。有點拗口，對吧？其實Use Case就是對系統功能的描述而已，不過一個Use Case描述的是整個系統功能的一部分，這一部分一定要是在邏輯上相對完整的功能流程。（唔？Use Case也沒什麼特別的嘛！怎么這玩意兒會在開發中處於一個中心地位呢？）在使用UML的開發過程中，需求是用Use Case來表達的，界面是在Use Case的輔助下設計的，很多類是根據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）
Use Case 由以下元素組成：
名稱
簡單描述
事件流
關係
活動圖和狀態圖
Use Case 圖
特殊需求
前條件
後條件
一、談談對use case有關術語翻譯的看法。
筆者認為“用例”是目前較好的譯法，這個詞可能來源於大家熟知的“測試用例”。有人認為把use case翻譯成“用例”是錯誤的，理由是：“‘例’是被列舉出來以說明某種情況的個別事物，use case是對一項系統功能使用情況的普遍適應的描述，而不是對個別actor或者在個別條件下使用這項功能才適應，它也不是通過舉例的方式來描述的”，所以不能叫作“用例”。此種說法不盡全面,而且有些牽強（先不管它正確與否），其實use case到底是個別的，還是群體的（普遍適應），取決於我們的視點。雖然對於單個的scenario來說，use case是多個情節的疊加，是一個整體的複合概念，但是我們知道，一個系統的功能必定是可數的、有限的，而每一個功能都可以?能需求的集合這個層面上，use case又是一個一個可數的個體（“橢圓”），每一個都代表了不同的用戶目標，適用於個別的actor和個別特定的前置條件。同一個事物既是個體的又是整體的，這種現象並不足怪，例如在UML對象-類-類元關係中，通常對象是類的實例，而類又是類元的實例，對類元來說，類、接口、子系統、use case等等就是一個個個體的概念，類既是其對象實例的集合又是其類元集合的個別元素。可見，把use case的“case”譯成“例”並沒有錯。
有的地方把use case翻譯成“用況”，即“使用的情況”之意，意思的確不錯（use case的另一種說法是“使用的方式”）！可我總感覺這個詞比較突兀、拗口，類似的還有“用案”，把scenario叫作“案況”，大概這些詞讀起來不太符合大家的習慣（類似地，既然可以叫“用況”，為什麼不能叫“用情”呢？），所以現在“用例”的叫法還是越來越多了。
其實“用例”這個譯法還有個附帶的好處，通過它我們很容易把原本就存在緊密聯繫的use case和test case（test case來自於對scenario的分析，而scenario是用例的一次執行）從中文名稱上也方便地統一起來。不過，這裡我們需要做一個小小的改進。中文的“測試用例”到底是指test case（帶定語的名詞詞組）呢，還是指對用例進行測試（testing the use cases，動賓詞組）呢？顯然這兩者不易分辨，而且若“用例”和“測試用例”兩個詞同時出現在一囉個句子或一段話中，常常會讓人感覺嗦和便扭。為了消除歧義，乾脆以後把test case都叫做“測例”，這樣不但比以前的叫法更加簡潔明了，而且無論字面上還是語義上都很貼切。當然，用例和測例是不同層面的“例”。
現在市面上Actor也有多種譯法，常見的包括“參與者、執行者、主角”等等。“參與者、執行者”的問題主要是不準確。首先，“參與者” 通常讓大家馬上想到的詞是participant，而且請注意，一個用例的真正參與者決不是只有外部的Actor，它們必然還包括系統本身及其內部的各種元素。“執行者”的問題與此類似：一個用例的真正執行者應該是系統本身！因此嚴格地講這樣譯是錯誤的，興許叫作“外部參與者”、“外部執行者”才更為恰當。“主角”的譯法同樣存在著矛盾。如果把Actor叫作“主角”，那么Primary Actor就應該叫作“主主角”了。看來Actor的譯法中是不能含有“主”的，那么就剩下“角”了，而UML已經有了一個專門術語role（角色），我們又不能把Actor直接叫作“角色”。
目前看來，把Actor意譯成“使用者”是比較妥當的。在大多數情況下Actor的的確確就是用戶（確切地說是系統用戶所扮演的一種角色），所以我們可以用“使用者”這個詞從字面上與“用戶”（user）進行區分，但同時又保持兩者語義上的聯繫。我們還可以把為系統服務的Supporting/Secondary Actor（見下文）叫做“被使用者”（為了簡化可以省略“被”字）或“輔使用者”。除了指系統的用戶之外，“使用者”還有另一層含義，即Actor是use case的使用者（或被使用者），這種關係在UML用例圖上應該可視化地表示為它們之間的連線（關聯）。這樣解釋不但說的通，而且更便於不熟悉軟體技術的業務人員理解。
當然，我們也不排除將來會找到“use case”、“actor”等術語更好的譯法。
二、USE CASE的來歷
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 說明書應包括以下內容：
功能描述
可用性
可靠性
性能
可支持性
設計約束
六、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看起來通常是不準確的或含糊的，??
七、Use Cases的說明
Use Cases的好處是一些情節能用不同程度的正規化的文字說明。每個情節涉及Use Cases中單一的途徑，細節是條件組。
不正規的文本描述也能使用，不過當條件較多和可能失敗的情況下它們很難跟隨下去。開始試圖理解需求時，不正規的敘述風格也是非常有用的，然而隨著Use Cases的進展，使用更加正規的機制去說明Use Cases才是有用的。
下面是客戶對Use Case“下定單”的粗略概略：
“確定客戶，找出需要的並且倉庫里還有的物品並檢查客戶信用額是否夠用”
結構化敘述的格式已經被證明是非常有效的。這個格式所做的事是描述每一個情節的行為者：目標語句對順序的敘述。在這個順序中，每一個行為者：目標的語句對都假設前一個的目標是成功的，右面是一個簡單的範例：
Use Cases認為我們正在設計的系統是一個單一的黑盒，根本沒有任何內部結構被記錄下來，並且它被認為是一個情節產生的目的及對應單一的行為者（Actor）。這些Use Cases沒有表示任何關於系統內部的東東，只是表示系統將達到什麼樣的目標及由什麼（人或其它系統）操作和負責。
八、Use Cases使需求有利於回顧
Use Cases已經得到越來越廣泛的套用，它與其它需求捕獲技術相比，它成功的原因在於：
1 Use Cases把系統當作一個黑盒
2 Use Case 使在需求中看到實現的決定變得更加容易
最後一點源於第一點的補充，一個Use Case沒有指定任何這些需求相關的系統的內部結構，所以說，如果這個Use Case中陳述了"提交改變到定單資料庫"、"顯示結果到Web頁面"等的話，那么內部結構是顯而易見的，並造成對設計的潛在約束。
為什麼這些需求不指定內部結構的原因是，說明的內部結構給設計者帶來了額外的約束，沒有這些約束設計者們能更自由地建立一個正確實現客觀可見行為的系統，並存在出現突破方案的可能性。
九、Use Cases的圖形符號
這裡是Use Cases的圖形符號描述，UML中一個單一的"Stick-Man"符號標示角色（Actor），用橢圓標示Use Cases，如
（圖一）所示。這些圖對於你想看到Use Cases之間如何關聯的"大圖"和獲得系統上下文的大體描述來說是非常重要的。
Use Cases圖沒有顯示不同的場景，它們的意圖是顯示角色和Use Cases之間的關係。所以Use Cases圖需求用結構化敘述文本來補充。UML提供一些可供選擇的圖來顯示不同的場景，這些常規的圖形有互動圖、活動圖、順序圖、狀態圖等（本文暫不討論這些圖）。使用這些圖的主要缺點是它們不象文本一樣是緊密的，但它們能用於給出Use Case的整體感覺。
十、Use Case 的評價標準
是否每個Use Case 都包括至少一個actor？
是否每個Use Case 都獨立於其他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對開發小組極具吸引力，即使小組成員對正式的需求文檔沒有經驗，但這些簡單性卻具有欺騙性，即使項目小組在開始使用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圖中存在的許多實質性問題可以被發現，這種方法減少了當需求改變時需要做的重複工作。
十三、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，如性能需求和系統容量的需求。另外的一些不是關聯的而是要單獨地去捕獲，它們是以下的需求：
· 系統範圍
· 系統用戶的目標
· 用戶界面原型
· 一般規則
· 約束
· 算法
運行時期和建立時期的需求比較
一個重要的因數要記住，就是系統的贊助者是大過用戶團體的。系統中有許多的風險承擔者，Use Cases僅僅捕獲其中一些風險承擔者的需要，具體說，Use Cases僅僅捕獲系統運行時期的需求而忽略做為系統開發組織的風險承擔者的需求，開發組織最有興趣的是對建立時期需求的描述。
運行時期需求包括：系統範圍、用戶組織對產品的期望和目標、Use Cases、其它非功能性需求。
建立時期需求包括：減少開發成本、較少的變更處理、現存組件的重用。
建立時期的需求可以部分的由Use Cases把握。但許多方面是需要由開發組織的處理的。
· 項目範圍和目標：項目必須提交什麼。（和系統範圍的區別是它提交的是所有項目的東西）
· 增長性和變更請求：這些可以在捕獲為常規Use Cases格式中的“Change Cases”
· 開發負責人的約束：包括標準、習慣、工具、品質度量標準、品質保證原則、及品質保證的習慣。
十四、Use Cases的適用性
Use Cases首先用於需要回響客觀事件的系統。它們能用於提供了一個有很容易理解的目標的清楚的行為者的環境。當結果不可定義或不清晰時不能用Use Cases。意思是如果目標成功或目標失敗不能有一個明確的定義，那么Use Cases不能用來捕獲需求。
然而說到這，現在大部分對象方法都使用Use Cases。因為Use Cases被證明是捕獲需求的非常有效的機制。
十五、小結
Use Case 是系統提供的功能塊，換句話來說Use Case演示了人們如何使用系統。通過Use Case觀察系統，能夠將系統實現與系統目標分開，有助於了解最重要的部分――滿足用戶要求和期望，而不會沉浸於實現細節。通過Use Case 用戶可以看到系統提供的功能，先確定系統範圍再深入開展項目工作。
十六、補充
名字格式：謂詞 賓語
