簡介 用例是文本形式的情節描述，廣泛應用于需求的發現和記錄工作中。用例會影響項目的眾多方面（包括OOA/D），用例也將作為本書案例研究中許多后繼制品的輸入。圖6-1描述了UP制品的影響力，其中特別強調了文本形式的用例。將高階目標和用例圖作為輸入，來創建用例文本。反之，用例也能夠影響其分析、設計、實現、項目管理和測試制品。
示例 圖6-1中的用例不是圖形，而是文本。用例初學者的常見錯誤就是注重于次要的UML用例圖，而非重要的用例文本。
用例通常比上述例子更為詳細或結構化更強，但其本質仍然是通過編寫使用系統實現用戶目標的情節來來發現和記錄功能性需求，也就是使用的案例。用例不是什么復雜的概念，盡管發現需求，并適當地編寫通常有一定的困難。
定義：參與者、場景和用例 參與者（actor）是某些具有行為的事物，可以是人（由角色標識）、計算機系統或組織。
場景（scenario）是參與者和系統之間的一系列特定的活動和交互，也稱為用例實例（use case instance）。場景是使用系統的一個特定的情節或用例的一條執行路徑。
通俗地講，用例(use case)就是一組相關的成功和失敗場景集合，用來描述參與者如何使用系統來實現其目標。
用例和用例模型 UP在需求科目中定義了用例模型（Use-Case Model）。首先，這是所有書面用例的集合；同時，它是系統功能性和環境的模型。 用例是文本文檔，而非圖形；用例建模主要是編寫文本的活動，而非制圖。
用例模型在UP中不是唯一的需求制品。其他制品還有補充性規格說明、詞匯表、設想和業務規則。這些制品都有助于需求分析，但并不是最主要的。
用例模型還可以包含UML用例圖，以顯示用例和參與者的名稱及其關系。UML用例圖可以為系統及其環境提供良好的語境圖（context diagram），也為按名稱列出用例提供了快捷方式。
用例不是面向對象的，編寫用例時也不會進行OO分析。但這并不妨礙其有效性，用例可以被廣泛應用。也就是說，用例是經典OOA/D的關鍵需求輸入。
動機：為什么使用用例 雖然這種方法看起來像隨意的注釋，但是極為重要。研究人員設計了他們自己能夠理解的復雜分析方法，但是會使一般的業務人員迷惑不解。而在軟件項目中，缺少用戶參與是項目的主要原因之一，所以任何有利于用戶參與的方法是絕對值得的。
用例的另一個價值是強調了用戶的目標和觀點。 我們會提出這樣的問題：“誰使用系統？他們使用的典型場景是什么？他們的目的是什么？”與查詢系統特性清單相比，以上問題更強調以客戶為中心。
富有創造力的人經常會將簡單的思想變得晦澀并且過于復雜。我們經常會發現，用例建模新手過于關心那些次要的問題，比如用例圖、用例關系、用例包等，而不是致力于簡單地編寫文本情節的實際工作中。
用例的優越性就在于，能夠根據需要對復雜程度和形式化程度進行增減調節。
定義：用例是功能性需求嗎 用例就是需求，主要是說明系統如何工作的功能性或行為性需求。按照“FURPS+”需求類型，用例強調了“F”（功能性或行為性），但也可以用于其它類型，特別是與用例緊密相關的那些類型。在統一過程和其他現代方法中，用例被推薦作為發現和定義需求的核心機制。
記住，用例是真正的需求（盡管不是所有的需求）。 用例的主要思想（通常）是：為功能性需求編寫用例，從而降低詳細的老式特性列表的重要性或減少這種列表的使用。
定義：參與者的三種類型 參與者（actor）是任何具有行為的事物，在所討論系統（System under Discussion ,SuD）調用其他系統的服務時，還包括其自身。主要參與者和協助參與者會出現在用例文本的活動步驟中。參與者不僅是人所扮演的角色，也可以是組織、軟件和計算機。相對于SuD，有三種外部參與者：
》主要參與者（primary actor）：具有用戶目標，并通過使用SuD的服務完成。例如，收銀員
》協助參與者（supporting actor）：為SuD提供服務（例如，信息服務）。自動付費授權服務即是一例。協助參與者通常是計算機系統，但也可以是組織或人。
》幕后參與者（offstage actor）：在用例行為中具有影響或利益，但不是主要或協助參與者。例如，政府稅收機構。
- 為何要確定幕后參與者？這是為了確保確定并滿足所有必要的重要事物。如果不明確地對幕后參與者進行命名，則有時很容易忽略其影響或利益。
表示法： 用例的三種常用形式 用例能夠以不同形式化程度或格式進行編寫：
》摘要--簡潔的一段式摘要，通常用于主成功場景，前例中的處理銷售就是摘要形式的用例。
- 何時使用？ 在早期需求分析過程中，為快速了解主題和范圍。可能只需要幾分鐘進行編寫。
》非正式--非正式的段落格式。用幾個段落覆蓋不同場景。前例中處理退貨就是非正式形式的用例。
》詳述--詳細編寫所有步驟及各種變化，同時具有補充部分，如前置條件和成功保證。
- 何時使用？確定并以摘要形式編寫了大量用例后，在第一次需求討論會中，詳細地編寫其中少量（例如10%）的具有重要架構意義和高價值的用例。
示例：詳述風格的處理銷售 詳述用例（fully dressed use case）是結構化的，它展示了更多細節，并且更為深入。（P50~P55） 在迭代和進化式UP需求分析中，第一次需求討論會應該以這種形式編寫10%的關鍵用例。隨后，對這10%中最具有重要架構意義的用例或場景進行設計和編程。
對于詳細的用例有各種格式的模板。自20世紀90年代早期以來，使用最為廣泛的格式是alistair.cockburn.us上提供的模板，該模板由Alistair Cockburn創建，他是用例建模方法和暢銷書的作者，PPT3闡述了這種風格。
各小節的含義
緒言元素
》范圍 范圍界定了所要設計的系統。通常，用例描述的是對一個軟件系統（或硬件加軟件）的使用，這種情況下稱之為系統用例（system use case） 。在更廣義的范圍上，用例也能夠描述顧客和有關人員如何使用業務。這種企業級的過程描述被稱為業務用例（business use case），這也是廣泛使用用例的極好示例，但這并不是本書所要介紹的內容。
》級別 在Cockburn的系統中，用例主要分為用戶目標級別或子功能級別。 用戶目標級別（user-goal level）是通常所使用的級別，描述了實現主要參與者目標的場景，該級別大致相當于業務流程工程中的基本業務流程（Elementary Business Process，EBP）。子功能級別（subfunction-level）用例描述支持用戶目標所需的子步驟，當若干常規用例共享重復的子步驟時，則將其分離出來，創建為子功能級別用例（以避免重復公共的文本）;信用卡支付就是子功能用例的例子，該用例可以被許多常規用例所共享。
》主要參與者 調用系統服務來完成目標的主要參與者
》涉眾及其關注點列表--重要！ 該列表比看上去要重要和實用的多。它建議并界定了系統必須要做的工作。見以下引用： “[系統]實現了涉眾之間的契約，同時用例詳細描述了該契約的行為部分.......用例作為行為的契約，專門和完整地捕獲與滿足涉眾關注點相關的行為” 這就回答了以下問題：用例應該包含什么？ 答案是：用例應該包含滿足所有涉眾關注點的事物
》前置條件和成功保證（后置條件） 前置條件（precondition）給出在用例中場景開始之前必須永遠為真的條件。要注意的是，有些條件也必須為真，但是不值得編寫出來。前置條件傳達的是編寫者認為應該引起讀者警惕的那些值得注意的假設。成功保證（或后置條件）給出用例成功結束后為真的事物，包括主成功場景及其替代路徑。該保證應該滿足 所有涉眾的需求。
》主成功場景和步驟（或基本流程） 也被稱為“理想路徑”場景，或更樸實的“基本流程”及“典型流程”。它描述了滿足涉眾關注點的典型成功路徑。要注意的是，它通常不包括任何條件或分支。雖然包含條件或分支并不是錯誤，但是，保持一定的連貫性，并且將所有條件處理都推延至擴展部分，這種具有爭議的做法更易于理解和擴展。
場景記錄以下三種步驟：
1、參與者之間的交互
2、確認過程（通常由系統來完成）
3、系統完成的狀態變更
》擴展（或替代流程） 擴展是重要的，并且通常占據了文本的大部分篇幅。擴展部分描述了其他所有場景或分支，包括成功和失敗路徑。 在整個用例編寫當中，理想路徑與擴展場景相結合應該滿足“幾乎”所有涉眾所關注的問題。
擴展場景是主成功場景的分支，因此能夠以對應的步驟1...N對其進行標識。
在擴展處理結束時，默認情況下，擴展場景將重新并入主成功場景，除非擴展指出了其他方式（例如，系統中斷） 。 有時候，某個擴展點將非常復雜，例如“信用卡支付”擴展。在這種情況下可以使用單獨的用例來表達該擴展。
如果想要描述在任何步驟（至少大多數步驟）都可能發生的擴展條件，那么可以使用“*a”、“*b”這樣的標記。
有時，用例會產生分支以執行其他用例場景。在Cockburn表示法中，使用下劃線表示所執行的第二個用例。假設通常使用超鏈接工具編寫用例，那么點擊具有下劃線的用例名稱將會顯示對應的文本。
》特殊需求 如果有用例相關的非功能性需求、質量屬性或約束，那么應該將其寫入用例。其中包含需要考慮的和必須包含的質量屬性（如性能、可靠性和可用性）和設計約束（通常對于I/O設備）
》技術和數據變元表 需求分析中通常會發現一些技術變元，這些變元是關于必須如何實現系統的，而非實現系統哪些功能，這種變元需要記錄在用例中。常見的例子是，涉眾制定了關于輸入或輸出技術的約束。
表示法：有其他格式嗎？兩欄變體 有時提倡使用兩欄或對話的格式，這種格式強調參與者和系統之間的交互。P60
準則：以無用戶界面約束的本質風格編寫用例 以本質風格編寫用例；摒除用戶界面并且關注參與者的意圖。 這種對根源目標的發現過程能夠拓展視野，以促成新的和改進的解決方案。
準則：編寫簡潔的用例 刪除“噪音”詞匯，因為即使一些細微之處也會累積為繁瑣，例如編寫時應用“系統認證......”，而不是“這個系統認證......”
準則：編寫黑盒用例 黑盒用例（black-box use case）是最常用和推薦使用的類型；它不對系統內部工作、構件或設計進行描述。反之，它以通過職責來描述系統，這是面向對象思想中普遍統一的隱喻主題--軟件元素具有職責，并且與其他具有職責的元素進行協作。
通過使用黑盒用例定義系統職責，人們可以規定系統必須做什么（行為和功能需求），而不必決定系統如何去做（設計）。實際上，“分析”與“設計”的區別就在于“什么”和“如何”的差異。這是在優秀軟件開發中的重要主題：在需求分析中應該避免進行“如何”的決策，而是規定系統的外部行為，就像黑盒一樣。此后，在設計過程中創建滿足該規格說明的解決方案。
準則：采用參與者和參與者目標的視點 以下是RUP的用例定義，源于用例創立者Ivar Jacobson：【一組用例實例，每個實例是系統所執行的一系列活動，以此產生對特定參與者具有價值的可觀察結果】 短語“對特定參與者具有價值的可觀察結果”是細微而又重要的概念，Jacobson認為這是關鍵，因為它強調了需求分析的兩個態度：
》關注系統的用戶或參與者來編寫需求，詢問其目標和典型情況
》關注理解參與者所考慮的有價值的結果
準則：如何發現用例 為滿足主要參與者的目標而定義用例。因此，基本的過程如下：
1》選擇系統邊界 系統僅僅是軟件應用，還是將硬件和應用作為整體？是一個人使用，還是整個組織在使用？
2》確定主要參與者--通過使用系統的服務實現其目標的那些人或事物
3》確定每個主要參與者目標
4》定義滿足用戶目標的用例，根據其目標對用例命名。通常，用戶目標級的用例和用戶目標是一一對應的，但這里至少有一個例外，后面將對此進行討論。
詳細步驟1-4見P63~P65
準則：什么樣的測試有助于發現有用的用例 一般來說不要提出“什么是有效用例”這樣的問題，更為實際的問題是“對應用需求分析來說，表示用例的有效級別是什么？”下面給出一些經驗方法：
老板測試 EBP測試 規模測試
EBP測試 EBP即基本業務過程（Elementary Business Process），是源于業務過程領域的術語，定義如下：【一個人于某一時刻在一個地點所執行的任務，用以響應業務事件。該任務能夠增加可量化的業務價值，并且以持久狀態留下數據，例如，批準信用卡的信用額或者確定訂購的價格】ERP測試與老板測試類似，尤其是對業務價值可量化這一限制而言。用例是在會話過程中完成的任務。用例可能只需幾分鐘或一個小時就能完成。正如UP的定義，用例增強可觀察或可量化的業務價值，由此形成了這樣的解釋：系統和數據具有穩定和持久狀態。
規模測試 用例很少由單獨的活動或步驟組成，相反，用例通常包含多個步驟，在詳述形式的用例通常需要3~10頁文本。用例建模中的一個常見錯誤就是僅將一系列相關步驟中的一個步驟定義為用例。
測試的合理違例 盡管應用中主要用例的定義和分析可以滿足上述測試，但是常常會出現例外。有時，需要為子任務或常規EBP級別用例中的步驟編寫單獨的子功能級別用例。例如，諸如“信用卡支付”等子任務或擴展可能在多個基本用例中出現。如果有這種現象，即使不能真正滿足EBP和規模測試，也需要考慮將其分離為單獨的用例，并且將其連接到各個基本用例上，以避免文字上的重復。
認證用戶這一用例可能無法通過老板測試，但是其步驟極為復雜，需要引起重視進行細致的分析，例如需要考慮“單點登錄”特性。
應用UML：用例圖 UML提供了用例圖表示法，用以描述用例名稱和參與者及其之間的關系（圖6-3）。 【用例圖和用例關系在編寫用例工作中是次要的。用例是文本文檔。編寫用例意味著編寫文本】Flower和Cockburn等世界級的用例專家都對用例圖和用例關系不予重視，而是注重編寫文本。借鑒大師經驗的同時，簡單的用例圖還是能夠為系統提供簡潔可視的語境圖，能夠闡述外部參與者及其對系統的使用。【準則：繪制簡單的用例圖，并與參與者-目標列表關聯。】
用例圖是一種優秀的系統語境圖(context diagram)；也就是說，用例圖能夠展示系統邊界、位于邊界之外的事物以及系統如何被使用。用例圖可以作為溝通工具，用以概括系統及其參與者的行為。
準則：制圖 圖6-4為制圖提供了建議。為了明確起見，某些人建議使用其他表示法萊突出外部計算機系統參與者，圖6-5所示。
準則：不要倚重于制圖，保持其簡短 再次重申，用例工作之重在于編寫文本，而非圖形或用例關系。
應用UML：活動圖 UML包含一種有助于工作流和業務過程可視化的圖：活動圖。因為用例涵蓋過程和工作流分析，所以活動圖能夠成為編寫用例文本的有用的輔助措施，對于那些描述復雜工作流的業務用例來說更是如此，因為其中涉及大量參與者和并發活動。
動機：用例還有其他益處么？語境中的需求 用例的動機在于關注誰是關鍵參與者，其目標和一般的任務是什么。除此之外，就其本質而言，用例是一種簡單的、被廣泛理解的形式（情節或場景形式）
正如Uses Case:Requirements in Context的書名所暗示的那樣，在使用系統的典型場所的語境下，用例組織了一組需求。這是件好事，以面向用戶的場景（例如用例）作為公共線索，考慮并組織需求，可以增強對需求的理解，并且能夠提高需求分組的內聚性。
無論用例多么重要，但它并不是唯一必要的需求制品。最好將非功能性需求、報表布局、領域規則和其他不知所置的元素寫入UP的補充性規格說明中去。
示例： Monopoly游戲 見P70
過程：在迭代方法中如何使用用例 用例是UP和其他眾多迭代方法的核心。UP提倡用例驅動開發（use-case driven development）這意味著：
》功能需求首先記錄在用例（用例模型）中；無論如何使用，其他需求技術（例如功能列表）都是上次要的
》用例是迭代計劃的重要部分。迭代的工作是通過選擇一些用例場景或整個用例來（部分地）定義的。同時，用例是預算的關鍵輸入。
》用例實現（use-case realization）驅動設計。也就是說，小組設計協作對象和子系統是為了執行或實現用例。
》用例通常會影響用戶手冊的組織
》功能或系統測試應當符合用例的場景
》為重要用例的最常用場景創建UI "向導" 或快捷方式可以方便執行常用任務
在迭代中如何演化用例和其他規格說明 本節重申了進化式迭代開發的關鍵思想：規格說明的工作任務在各迭代中的時間量和級別。PPT4展示了一個樣例（而非真正的解決方案），表明了如何開發需求的UP策略。
在UP中，提倡在需求討論會上編寫用例。圖6-7對完成此項工作提出了時間和地點方面的建議。
何時創建各種UP制品（含用例） PPT5描述了一些UP制品，及其開始和凈化的時間表示例。
【在初始階段如何編寫用例？細化階段如何編寫用例？構造階段如何編寫用例？ 研究PPT3，參考P74】