關鍵字: uml 讀書筆記
通俗地講，用例是文本形式的情節描述， 用以說明某參與者使用系統以實現某些目標。
注意：用例不是圖形，而是文本。 用例初學者的常見錯誤就是注重於次要的UML用例圖，而非重要的用例文本。
本質上，用例是通過編寫使用系統實現用戶目標的情節來發現和記錄功能性需求 ，也就是使用的案例(cases of use)
定義：參與者、場景和用例
參與者 (actor)是某些具有行爲的事物，可以是人(由角色標識)、計算機系統或者組織。例如：收銀員
場景 (scenario)是參與者和系統之間的一系列特定的活動和交互，也稱爲用例實例 (use case instance)。場景是使用系統的一個特定情節或用例的一條執行路徑。例如，使用現金成功購買商品的場景，或者由於信用開付款被拒絕造成的購買失敗場景。
通俗地講，用例 (use case)就是一組相關的成功和失敗場景集合，用來描述參與者如何使用系統來實現其目標。
RUP對用例進行如下的定義:
用例和用例模型
UP在需求製品中定義了用例模型 (Use-Case Model)。首先，這是所有書面用例的集合；同時，它是系統功能性和環境的模型。
用例模型可以包含UML用例圖，以顯示用例和參與者的名稱和其關係。UML用例圖可以爲系統及其環境提供良好的語境圖 (context diagram)，也爲按名稱列出用例提供了快捷方式。
用例不是面向對象的，編寫用例時也不會進行OO分析。但這並不妨礙其有效性，用例可以被廣泛應用。也就是說，用例是經典OOA/D的關鍵需求輸入 。
動機：爲什麼使用用例
在軟件項目中，缺少用戶參與是項目失敗的主要原因之一。研究人員設計了他們自己能夠理解的複雜分析方法，但是一般的業務人員卻對此迷惑不解。因此，任何有利於用戶參與的方法都是絕對值得的。
用例是一種優秀的方法，是領域專家或者需求提供者自己編寫(或者參與編寫用例)用例成爲可能，使與用戶溝通 的工作難度降低。
用例的另一個價值在於：強調了用戶的目標和觀點。
用例的優越性在於，能夠根據需要，對複雜程度和形式化程度進行增減調整。
定義：用例是功能性需求
用例就是需求，主要是說明系統如何工作的功能性或行爲性需求。按照"FURPS+"需求類型，用例強調了"F"(功能性或行爲性)，但也可以用於其他類， 特別是於用例緊密相關的那些類型。在UP和其他的現代方法中（XP，TDD），用例被推薦作爲發現和定義需求的核心機制。
用例是真正的需求(儘管不是所有的需求)。用例的主要思想(通常)是：爲功能性需求編寫用例，從而降低詳細的老式特性列表的重要性或減少這種列表的使用。
定義：參與者的三種類型
參與者 (actor)是任何具有行爲的事物，在所討論系統(System under Discussion, SuD)調用其他系統的服務時，還包括起本身。主要參與者和協助參與者會出現在用例文本的活動步驟中。相對於SuD,有三種參與者：
- 主要參與者 (primary actor)：具有用戶目標，並通過使用SuD的服務完成。例如：收銀員。爲何要確定主要參與者？發現驅動用例的用戶目標。
- 協助參與者 (supporting actor)：爲SuD提供服務(例如，信息服務)。協助參與者一般是計算機系統，也可以是組織或者人。爲何要確定協助參與者？爲了明確外不接口和協議。
- 幕後參與者 (offstage actor)：在用例行爲中具有影響或者利益，但不是主要或者協助參與者。如，政府稅收機構。爲何要確定幕後參與者？這是爲了確保確定並滿足所有必要的重要事物。如果不明確地對幕後參與者進行命名，則有時容易忽略其影響活利益。
用例的三種常用表示法
用例能夠以不同形式化程度或格式進行編寫：
- 摘要——簡潔的一段式概要，通常用於主成功場景。用於早期需求分析過程中，爲了快速瞭解主題和範圍。
- 非正式——非正式的段落格式。用幾個段落覆蓋不同場景。同樣，用於早期需求分析過程中，爲了快速瞭解主題和範圍。
- 詳述——詳細編寫所有步驟及各種變化，同時具有補充部分，如前置條件和成功保證。何時使用?確定並以摘要形式編寫了大量用例後，在第一次需求討論會中，詳細的編寫其中少量(例如：10％)的具有重要架構意義和高價值的用例。
