用例模型是系統既定功能及系統環(huán)境的模型，它可以作為客戶(hù)和開(kāi)發(fā)人員之間的契約。用例是貫穿整個(gè)系統開(kāi)發(fā)的一條主線(xiàn)。同一個(gè)用例模型即為需求工作流程的結果，可當作分析設計工作流程以及測試工作流程的輸入使用。

      下圖顯示了回收機系統用例模型的一部分：

用例圖，顯示包含主角和用例的用例模型示例。

      系統建模有許多種方法，每種建模方法可以滿(mǎn)足不同的目的。然而，用例模型最重要的作用是將系統行為傳達給客戶(hù)或最終用戶(hù)。因此，模型必須易于理解。

      可能與該系統交互的用戶(hù)和任何其他系統都是主角。由于主角代表了系統用戶(hù)，它們協(xié)助界定系統并提供十分明確的系統用途說(shuō)明。編寫(xiě)用例依據主角的需求來(lái)進(jìn)行。這樣就確保該系統成為用戶(hù)期望得到的系統。

一、用例模型如何演進(jìn)

      主角和用例都是通過(guò)將客戶(hù)需求及潛在用戶(hù)當作重要的信息查找到的。找到這些用例和主角后，應對它們作簡(jiǎn)要說(shuō)明。在詳細說(shuō)明這些用例之前，客戶(hù)應復審該用例模型以核實(shí)所有的用例和主角都已經(jīng)找到，并且它們可以提供客戶(hù)所需要的東西。

      在迭代開(kāi)發(fā)環(huán)境中，您可以選擇用例的子集以便在每個(gè)迭代中詳細描述。另請參見(jiàn)活動(dòng)：確定用例的優(yōu)先級。

      主角和用例找到后，需要詳細說(shuō)明每個(gè)用例的事件流。這些說(shuō)明指出系統與主角交互的方式以及在各個(gè)獨立用例中系統執行的有關(guān)操作。

      最后，對已完成的用例模型（包括用例說(shuō)明）進(jìn)行復審，開(kāi)發(fā)人員和客戶(hù)使用該模型對系統應執行的操作達成一致意見(jiàn)。

二、避免功能分解

      用例模型退化導致系統功能分解的情況并不罕見(jiàn)。為避免發(fā)生這種情況，必須注意以下故障現象：

      “小”用例，即對事件流的說(shuō)明只有一個(gè)或少數幾個(gè)句子。
      “許多”用例，即用例的數量有好幾百，而不是好幾十。
      用例名的構造類(lèi)似于“根據這一特定數據執行本操作”或“利用這一數據執行本功能”等。例如，“在 ATM 機上輸入個(gè)人識別號”不應建模為 ATM 機的一個(gè)單獨用例，原因是沒(méi)有人會(huì )使用系統僅執行這一操作。用例是一個(gè)完整事件流，它可以產(chǎn)生對主角有價(jià)值的東西。

      為避免功能分解，您需要確保該用例模型有助于回答諸如以下的問(wèn)題：

      系統的環(huán)境是什么？
      為什么要建立系統？
      用戶(hù)在使用系統時(shí)希望獲得什么？
      系統將給用戶(hù)創(chuàng )造什么價(jià)值？

三、非功能性需求

      不難發(fā)現，用例是一個(gè)很好的獲取系統功能性需求的方法。但是對于非功能性需求，情況又如何呢？什么是非功能性需求，可以在何處獲得它們？

      非功能性需求通常分為可用性需求、可靠性需求、性能需求以及可替換性需求（另請參閱概念：需求）。它們通常是指定需要符合任意法律法規要求的需求。它們也可以是由于所使用的操作系統、環(huán)境平臺、兼容性或所采用的任何應用標準等問(wèn)題產(chǎn)生的設計約束。通常，任何不允許有一個(gè)以上設計選項的需求都可以認為是一個(gè)設計約束。

      許多非功能性需求適用于一個(gè)單獨的用例，并且可以在該用例的特征內獲得這些需求。在這種情況下，這些需求可以在用例的事件流內獲取，或者作為用例的一個(gè)特殊需求來(lái)獲?。ㄕ垍㈤喼改希河美?。

      示例：

      在回收機系統中，返還儲存項用例的一個(gè)特定非功能性需求是：

      該機器識別儲存項的可靠性必須高于 95%。

      通常，功能性需求適用于整個(gè)系統。此類(lèi)需求可以在補充規約中獲得（請參閱工件：補充規約）。

      示例：

      在回收機系統中，一個(gè)適用于整個(gè)系統的非功能性規約是：

      機器每次只允許一個(gè)用戶(hù)使用。

四、內容與方式的兩難局面

      學(xué)習如何確定用例應該在哪個(gè)明細級別上“開(kāi)始和結束”是一件比較困難的事情。特征和用例開(kāi)始于何處，而用例結束和設計開(kāi)始又在什么地方？我們通常說(shuō)，用例或軟件需求應該規定系統做“什么”而不是“如何”做的問(wèn)題。以下圖為例：

一個(gè)人的終點(diǎn)是另一個(gè)人的起點(diǎn)。

      根據個(gè)人背景，您可以使用不同的環(huán)境來(lái)確定您對“什么”以及“如何”的理解。當決定是否應該將某個(gè)細節擯棄于用例模型之外時(shí)，需要仔細考慮這一問(wèn)題。

五、具體用例和抽象用例

      具體用例和抽象用例之間存在一個(gè)區別。具體用例由主角來(lái)啟動(dòng)，并且構成一個(gè)完整的事件流。“完整”意味著(zhù)該用例的一個(gè)實(shí)例執行由主角調用的全部操作。

      抽象用例本身從來(lái)不會(huì )被實(shí)例化。抽象用例包括在（請參閱指南：包含關(guān)系）其他用例中，擴展到（請參閱指南：擴展關(guān)系）或泛化關(guān)系（請參閱指南：用例泛化關(guān)系）其他用例。在啟動(dòng)一個(gè)具體用例時(shí)，也就創(chuàng )建了該用例的一個(gè)實(shí)例。這一實(shí)例還展示了由其關(guān)聯(lián)關(guān)系的抽象用例指定的活動(dòng)。因而，從抽象用例中無(wú)法創(chuàng )建單獨的實(shí)例。

      由于主角在系統中“看見(jiàn)”和啟動(dòng)的是具體用例，因此這兩種用例之間的區別非常重要。

      表明一個(gè)用例為抽象用例時(shí)，可以將其名稱(chēng)格式設置為斜體。

      示例：

“創(chuàng )建任務(wù)”用例包括在“注冊單”用例中“創(chuàng )建任務(wù)”用例是一個(gè)抽象用例。

      在庫房管理系統中，“創(chuàng )建任務(wù)”抽象用例包括在“注冊單”用例中。啟動(dòng)“注冊單”用例后，將創(chuàng )建一個(gè)注冊單實(shí)例。該實(shí)例除了遵循注冊單的事件流之外，它還遵循在所包含的用例“創(chuàng )建任務(wù)”內說(shuō)明的事件流。“創(chuàng )建任務(wù)”本身從來(lái)不被執行，但始終作為“注冊單”（或其他任何包含“創(chuàng )建任務(wù)”的用例）的一個(gè)部分。因此，“創(chuàng )建任務(wù)”是一個(gè)抽象用例。

六、構建用例模型

      構建用例模型有三個(gè)主要的原因：

      使用例更易于理解。
      將在許多用例內說(shuō)明的公有行為分離出來(lái)。
      使用例模型更易于維護。

      然而，構建模型并不是首先要做的事情。在您對用例的行為有更深入的了解（而不是一句話(huà)簡(jiǎn)要說(shuō)明）之前，千萬(wàn)不要構建該用例。您至少需要為該用例的事件流建立一個(gè)分步說(shuō)明大綱，確保您的決策是建立在對該行為有精確而充分的理解基礎之上。

      有三種關(guān)系可以用于構建用例。您可以使用這些關(guān)系來(lái)分析出用例部件，這些部件可以在其他用例中復用，或者作為該用例的特例或選項。表示修改的用例稱(chēng)為附加用例。被修改的用例稱(chēng)為基本用例。

      如果基本用例中有一部分功能，該用例的執行與否由它的結果唯一決定，而不是由產(chǎn)生該結果的方法來(lái)決定，則可以將這一部分功能分離出來(lái)，放到一個(gè)附加用例中。采用包含關(guān)系，可以將附加用例顯式插入基本用例中。另請參見(jiàn)指南：包含關(guān)系。

      如果基本用例的一部分是可選的，或對于理解該用例的主要目的來(lái)說(shuō)不是必需的，那么您可以將這部分分離出來(lái)，形成一個(gè)附加用例，以簡(jiǎn)化基本用例的結構。利用擴展關(guān)系，可以將附加用例隱式插入基本用例中。另請參見(jiàn)指南：擴展關(guān)系。

      如果用例在行為和結構上具有共同點(diǎn)而且在目的上又很相似，則可以將它們的共同部分分離出來(lái)，形成一個(gè)基本用例（父用例）。而附加用例（子用例）可以繼承該父用例。子用例可以在從父用例繼承的結構中插入新的行為或修改現有的行為。另請參見(jiàn)指南：用例泛化關(guān)系。

      您可以使用主角泛化關(guān)系來(lái)顯示主角之間的特化情況。另請參見(jiàn)指南：主角泛化關(guān)系。

      示例：

      以訂單管理系統的用例模型部分為例進(jìn)行說(shuō)明。

      由于他們具有略微不同的特征，因此將普通客戶(hù)從 Internet 客戶(hù)中分離開(kāi)來(lái)是非常有用的。然而，因為 Internet 客戶(hù)的確顯示了一個(gè)客戶(hù)具有的所有特征，所以您可以說(shuō) Internet 客戶(hù)是客戶(hù)的一個(gè)特例，并且能夠通過(guò)主角泛化關(guān)系來(lái)指示。

      在本圖中，具體用例分別是“電話(huà)訂購”（由客戶(hù)主角發(fā)出）和“Internet 訂購”（由 Internet 客戶(hù)發(fā)出）。這些用例都是更普通的“訂購”用例的變形。在本示例中，“訂購”用例是一個(gè)抽象用例。“請求目錄”用例代表一個(gè)可選行為段，它不是“訂購”用例主要目標的組成部分。它已經(jīng)被分離出來(lái)，形成了一個(gè)抽象用例，用于簡(jiǎn)化“訂購”用例。“提供客戶(hù)數據”用例是一個(gè)已分離出的行為段。它之所以被分離出來(lái)，是因為它是一個(gè)獨立功能，只有它的結果才能影響“訂購”用例。“供給客戶(hù)數據”用例還可以在其他用例中復用。“請求目錄”用例和“供給客戶(hù)數據”用例在本示例中都屬于抽象用例。

本用例圖顯示訂單管理系統的用戶(hù)模型部分。

下表顯示了三個(gè)不同用例關(guān)系之間更詳細的比較：

      為達到更易于理解的目的，組織用例模型的另一個(gè)方法是對用例進(jìn)行分組，形成多個(gè)包。用例模型可以組織為一個(gè)有層次的用例包結構，而主角或用例是該結構中的“樹(shù)葉”。另請參見(jiàn)指南：用例包。

本圖顯示用例模型的分層結構。箭頭表示可能存在所有權關(guān)系。

七、用例是否始終和主角有關(guān)？

      每個(gè)用例的執行都包含與一個(gè)或多個(gè)主角的交流。用例實(shí)例始終通過(guò)主角要求系統執行某些任務(wù)來(lái)啟動(dòng)。這意味著(zhù)每個(gè)用例需要與主角建立通信關(guān)聯(lián)關(guān)系。此規則的理由是強迫系統只提供用戶(hù)需要的功能，而不提供任何其他的東西。如果存在無(wú)人請求的用例，則表明在該用例模型或需求中存在錯誤。

      然而，此規則也有一些例外情況：

      如果用例是抽象的（不是可獨立實(shí)例化的），則其行為可能不包括與主角的交互。這種情況下，將不存在任何從該抽象用例到主角的通信關(guān)聯(lián)關(guān)系。
如果父用例說(shuō)明了所有的主角通信，則泛化關(guān)系中的子用例不需要與主角相關(guān)聯(lián)。
      如果包含用例說(shuō)明了所有的主角通信，則包含關(guān)系中的基本用例不需要與主角相關(guān)聯(lián)。
      一個(gè)用例可能按照時(shí)間表（例如，一星期一次或一天一次）來(lái)啟動(dòng)，這意味著(zhù)系統時(shí)鐘即為啟動(dòng)程序。由于用例不是由主角而是由內部系統事件啟動(dòng)的，因此系統時(shí)鐘對于該系統而言是內在的。如果在該用例中沒(méi)有發(fā)生其他的主角交互，則它與主角之間不存在任何關(guān)聯(lián)關(guān)系。然而，為了清楚起見(jiàn)，您可以在用例圖中使用一個(gè)虛構的主角“時(shí)間”來(lái)顯示該用例是如何啟動(dòng)的。

八、調查說(shuō)明

      用例模型的調查說(shuō)明應該：

      聲明哪些是系統的主要用例（系統建立的原因）。
      總結有關(guān)系統的重要技術(shù)實(shí)際情況。
      指出系統定界 - 系統將不執行的操作。
      概述系統的環(huán)境，例如目標平臺和現有的軟件。
      描述在該系統中正常執行用例的任意序列。
      詳細說(shuō)明用例模型未處理的功能。

      示例：

      以下是關(guān)于回收機的用例模型的調查說(shuō)明示例：

      本模型包括三個(gè)主角和三個(gè)用例。主要用例是“回收項”，它說(shuō)明回收機的主要用途。

      支持用例有：

      “打印日常報告”，操作員可以使用它獲得關(guān)于已經(jīng)回收多少項目的報告。
      “管理儲存項”，操作人員可以使用它來(lái)變更某個(gè)儲存項類(lèi)型的退款金額，或增加新的儲存項類(lèi)型。