用例建模
（
Use Case Modeling
）是使用
用例
的方法來描述系統
的功能
需求
的過程，
用例模型
主要包括以下兩部分內容：
用例圖
(
Use Case Diagram
)
確定系統中所包含的參與者、用例和兩者之間的對應關係，用例圖描述的是關於系統功能的一個概述。
用例規約(
Use Case
Specification)
針對每一個用例都應該有一個用例規約文檔與之相對應，該文檔描述用例的細節內容。
在用例建模的過程中，我們建議的步聚是先找出參與者，再根據參與者確定每個參與者相關的用例，最後再細化每一個用例的用例規約。
用例描述用來詳細描述用例圖中每個用例，用文本文檔來完成。
一. 用例圖(Use Case Diagram)
用例圖由參與者（Actor）、用例（Use Case）、系統邊界、箭頭組成，用畫圖的方法來完成。
參與者不是特指人，是指系統以外的，在使用系統或與系統交互中所扮演的角色。因此參與者可以是人，可以是事物，也可以是時間
或
其他系統等等。還有一點要注意的是，參與者不是指人或事物本身，而是表示人或事物當時所扮演的角色。比如小明是圖書館的管理員，他參與圖書館管理系統的交
互，這時他既可以作爲管理員這個角色參與管理，也可以作爲借書者向圖書館借書，在這裏小明扮演了兩個角色，是兩個不同的參與者。參與者在畫圖中用簡筆人物
畫來表示，人物下面附上參與者的名稱。
用例是對包括變量在內的一組動作序列的描述，系統執行這些動作，併產生傳遞特定參與者的價值的可觀察結果。這是
UML
對用例的正式定義，對我們初學者可能有點難懂。我們可以這樣去理解，用例是參與者想要系統做的事情。對於對用例的命名，我們可以給用例取一個簡單、描述性的名稱，一般爲帶有動作性的詞。用例在畫圖中用橢圓來表示，橢圓下面附上用例的名稱。
系統邊界是用來表示正在建模系統的邊界。邊界內表示系統的組成部分，邊界外表示系統外部。系統邊界在畫圖中方框來表示，同時附上系統的名稱，參與者畫在邊界的外面，用例畫在邊界裏面。因爲系統邊界的作用有時候不是很明顯，所以我個人理解，在畫圖時可省略。
箭頭用來表示參與者和系統通過相互發送信號或消息
進行交互的關聯關係。箭頭尾部用來表示啓動交互的一方，箭頭頭部用來表示被啓動的一方，其中用例總是要由參與者來啓動。
二. 用例規約(Use Case Specification)
用例圖只是簡單地用圖描述了一下系統，但對於每個用例，我們還需要有詳細的說明，這樣就可以讓別人對這個系統有一個更加詳細的瞭解，這時我們就需要寫用例描述。
對於用例描述的內容，一般沒有硬性規定的格式，但一些必須或者重要的內容還是必須要寫進用例描述裏面的。用例描述一般包括：簡要描述（說明）、前置（前提）條件、基本事件流、其他事件流、異常事件流、後置（事後）條件等等。下面說說各個部分的意思：
簡要描述：對用例的角色、目的的簡要描述；
前置條件：執行用例之前系統必須要處於的狀態，或者要滿足的條件；
基本事件流：描述該用例的基本流程，指每個流程都“正常”運作時所發生的事情，沒有任何備選流和異常流，而只有最有可能發生的事件流；
其他事件流：表示這個行爲或流程是可選的或備選的，並不是總要總要執行它們；
異常事件流：表示發生了某些非正常的事情所要執行的流程；
後置條件：用例一旦執行後系統所處的狀態；
三． 用例圖和用例描述設計
實例
這裏用我開發的一個家教網站
來簡單的分析用例圖的畫法和用例描述的寫法。這個網站我用UML完整的分析一下，以下我提取了用例圖和用例描述的部分。這個家教網站分爲前臺客戶系統和後臺管理系統。
前臺客戶系統的用例圖如下：
後臺管理系統用例圖如下：
用例
系統邊界
對於用例描述，篇幅有限，我在這裏只列了後臺管理系統中的網站公告發布這個用例的描述。如下：
| 用例名稱： 網站公告發布 |
| 用例標識號：
202 |
| 參與者：
負責人
|
| 簡要說明：
負責人用來填寫和修改家教網站首頁的公告，公告最終顯示在家教網站的首頁上。 |
| 前置條件：
負責人已經登陸家教網站管理系統 |
| 基本事件流：
1． 負責人鼠標點擊“修改公告”按鈕 2． 系統出現一個文本框，顯示着原來的公告內容 3． 負責人可以在文本框上修改公告，也可以完全刪除，重新寫新的公告 4． 負責人編輯完文本框，按“提交”按鈕，首頁公告就被修改 5． 用例終止 |
| 其他事件流
A1：
1．在按“提交”按鈕之前，負責人隨時可以按“返回”按鈕，文本框的任何修改內容都不會影響網站首頁的公告 |
| 異常事件流：
1． 提示錯誤信息，負責人確認 2． 返回到管理系統主頁面 |
| 後置條件：
1．網站首頁的公告信息被修改 |
| 註釋： 無 |
四、用例建模的步聚
在用例建模的過程中，我們建議的步聚是先找出參與者，再根據參與者確定每個參與者相關的用例，最後再細化每一個用例的用例規約。
1、尋找參與者
所謂的參與者是指所有存在於系統外部並與系統進行交互的人或其他系統。通俗地講，參與者就是我們所要定義系統的使用者。尋找參與者可以從以下問題入手：
系統開發完成之後，有哪些人會使用這個系統？
系統需要從哪些人或其他系統中獲得數據？
系統會爲哪些人或其他系統提供數據？
系統會與哪些其他系統相關聯？
系統是由誰來維護和管理的？
這些問題有助於我們抽象出系統的參與者。對於ATM機的例子，回答這些問題可以使我們找到更多的參與者：操作員負責維護和管理ATM機系統、ATM機也需要與後臺服務器進行通訊以獲得有關用戶帳號的相關信息。
1.1 系統邊界決定了參與者
參與者是由系統的邊界所決定的，如果我們所要定義的系統邊界僅限於ATM機本身，那麼後臺服務器就是一個外部的系統，可以抽象爲一個參與者。
如果我們所要定義的系統邊界擴大至整個銀行系統，ATM機和後臺服務器都是整個銀行系統的一部分，這時候後臺服務器就不再被抽象成爲一個參與者。
1.2 特殊的參與者――系統時鐘
有時候我們需要在系統內部定時地執行一些操作，如檢測系統資源使用情況、定期地生成統計報表等等。從表面上看，這些操作並不是由外部的人或系統觸發的，應該怎樣用用例方法來表述這一類 功能需求呢？對於這種情況，我們可以抽象出一個系統時鐘或定時器參與者，利用該參與者來觸發這一類定時操作。從邏輯上，這一參與者應該被理解成是系統外部的，由它來觸發系統所提供的用例對話。
2、確定用例
找到參與者之後，我們就可以根據參與者來確定系統的用例，主要是看各參與者需要系統提供什麼樣的服務，或者說參與者是如何使用系統的。尋找用例可以從以下問題入手（針對每一個參與者）：
參與者爲什麼要使用該系統？
參與者是否會在系統中創建、修改、刪除、訪問、存儲數據？如果是的話，參與者又是如何來完成這些操作的？
參與者是否會將外部的某些事件通知給該系統？
系統是否會將內部的某些事件通知該參與者？
綜合以上所述，ATM系統的用例圖可表示如下，
可視化建模 的主要目的之一就是要增強 團隊 的溝通，用例模型必須是易於理解的。用例建模往往是一個團隊開發的過程，系統分析員在建模過程中必須注意參與者和用例的名稱應該符合一定的命名約定，這樣整個用例模型才能夠符合一定的風格。如參與者的名稱一般都是名詞，用例名稱一般都是動賓詞組等。
對於同一個系統，不同的人對於 參與者和用例都可能有不同的抽象結果，因而得到不同的用例模型。我們需要在多個用例模型方案中選擇一種"最佳"（或"較佳"）的結果，一個好的用例模型應 該能夠容易被不同的涉衆所理解，並且不同的涉衆對於同一用例模型的理解應該是一致的。
3、描述用例規約
應該避免這樣一種誤解――認爲由參與者和用例構成的用例圖就是用例模型，用例圖只是在總體上大致描述了系統所能提供的各種服務，讓我們對於系統的功能有 一個總體的認識。除此之外，我們還需要描述每一個有例的詳細信息，這些信息包含在用例規約中，用例模型是由用例圖和每一個用例的詳細描述――用例規約所組 成的。RUP 中提供了用例規約的模板，每一個用例的用例規約都應該包含以下內容：
簡要說明 (Brief Description)
簡要介紹該用例的作用和目的。
事件流 (Flow of Event)
包括基本流和備選流，事件流應該表示出所有的場景。
用例場景 (Use-Case Scenario)
包括成功場景和失敗場景，場景主要是由基本流和備選流組合而成的。
特殊需求 (Special Requirement)
描述與該用例相關的非功能性需求（包括性能、可靠性、可用性和可擴展性等）和設計約束（所使用的 操作系統 、開發工具 等）。
前置條件 (Pre-Condition)
執行用例之前系統必須所處的狀態。
後置條件 (Post-Condition)
用例執行完畢後系統可能處於的一組狀態。
用例規約基本上是用文本方式來表述的，爲了更加清晰地描述事件流，也可以選擇使用 狀態圖 、 活動圖 或 序列圖 來輔助說明。只要有助於表達的簡潔明瞭，就可以在用例中任意粘貼用戶界面和流程的圖形化顯示方式，或是其他圖形。如活動圖有助於描述複雜的決策流程，狀態轉移圖有助於描述與狀態相關的系統行爲，序列圖適合於描述基於時間順序的消息傳遞。
3.1 基本流
基本流描述的是該用例最正常的一種場景，在基本流中系統執行一系列活動步驟來響應參與者提出的服務請求。我們建議用以下格式來描述基本流：
(1) 每一個步驟都需要用數字編號以清楚地標明步驟的先後順序。
(2) 用一句簡短的標題來概括每一步驟的主要內容，這樣閱讀者可以通過瀏覽標題來快速地瞭解用例的主要步驟。在用例建模的早期，我們也只需要描述到事件流步驟標題這一層，以免過早地陷入到用例描述的細節中去。
(3) 當整個用例模型基本穩定之後，我們再針對每一步驟詳細描述參與者和系統之間所發生的交互。建議採用雙向(roundtrip)描述法來保證描述的完整性， 即每一步驟都需要從正反兩個方面來描述1)參與者向系統提交了什麼信息；(2)對此係統有什麼樣的響應。具體例子請參見附錄。
在描述參與者和系統之間的信息交換時，需指出來回傳遞的具體信息。例如，只表述參與者輸入了客戶信息就不夠明確，最好明確地說參與者輸入了客戶姓名和地址 。通常可以利用詞彙表讓用例的複雜性保持在可控範圍內，可以在詞彙表中定義客戶信息等內容，使用例不至於陷入過多的細節。
3.2 備選流
備選流負責描述用例執行過程中異常的或偶爾發生的一些情況，備選流和基本流的組合應該能夠覆蓋該用例所有可能發生的場景。在描述備選流時，應該包括以下幾個要素：
(1) 起點：該備選流從事件流的哪一步開始；
(2) 條件：在什麼條件下會觸發該備選流；
(3) 動作：系統在該備選流下會採取哪些動作；
(4) 恢復：該備選流結束之後，該用例應如何繼續執行。
備選流的描述格式可以與基本流的格式一致，也需要編號並以標題概述其內容，編號前可以加以字母前綴A(Alternative)以示與基本流步驟相區別。
3.3 用例場景
用例在實際執行的時候會有很多的不同情況發生，稱之爲用例場景；也可以說場景是用例的實例，我們在描述用例的時候要覆蓋所有的用例場景，否則就有可能導 致需求的遺漏。在用例規約中，場景的描述可以由基本流和備選流的組合來表示。場景既可以幫助我們防止需求的遺漏，同時也可以對後續的開發工作起到很大的幫 助：開發人員必須實現所有的場景、測試人員可以根據用例場景來設計測試用例 。
3.4 特殊需求
特殊需求通常是非功能性需求，它爲一個用例所專有，但不適合在用例的事件流文本中進行說明。特殊需求的例子包括法律或法規方面的需求、應用程序 標準和所構建系統的質量屬性（包括可用性、可靠性、性能或支持性需求等）。此外，其他一些設計約束，如操作系統及環境 、兼容性需求等，也可以在此節中記錄。
需要注意的是，這裏記錄的是專屬於該用例的特殊需求；對於一些全局的非功能性需求和設計約束，它們並不是該用例所專有的，應把它們記錄在《補充規約》中。
3.5 前置和後置條件
前置條件是執行用例之前必須存在的系統狀態，後置條件是用例一執行完畢後系統可能處於的一組狀態。
4、檢查用例模型
用例模型完成之後，可以對用例模型進行檢查，看看是否有遺漏或錯誤之處。主要可以從以下幾個方面來進行檢查：
功能需求的完備性
現有的用例模型是否完整地描述了系統功能，這也是我們判斷用例建模工作是否結束的標誌。如果發現還有系統功能沒有被記錄在現有的用例模型中，那麼我們就需要抽象一些新的用例來記錄這些需求，或是將他們歸納在一些現有的用例之中。
模型是否易於理解
用例模型最大的優點就在於它應該易於被不同的涉衆所理解，因而用例建模最主要的指導原則就是它的可理解性。用例的粒度、個數以及模型元素之間的關係複雜程度都應該由該指導原則決定。
是否存在不一致性
系統的用例模型是由多個系統分析員協同完成的，模型本身也是由多個工件所組成的，所以我們要特別注意不同工件之前是否存在前後矛盾或衝突的地方，避免在模型內部產生不一致性。不一致性會直接影響到需求定義的準確性。
避免二義性語義
好的需求定義應該是無二義性的，即不同的人對於同一需求的理解應該是一致的。在用例規約的描述中，應該避免定義含義模糊的需求，即無二義性。