3.2 用例關系和描述

用例除了與其參與者發生關聯外，還可以具有系統中的多個關系，這些關系包括包含關系、擴展關系和泛化關系，而應用這些關系的目的是從系統中抽取出公共行為和其變體。

3.2.1 泛化關系

泛化是一種表示UML中項目的繼承關系的技術。泛化可以應用于參與者和用例中來表示其子項從父項繼承的功能，而且泛化還表示了父項的每個子項都有略微不同的功能或目的，以確保自己的唯一性。泛化可以用于用例，也可以用于參與者。

1．泛化用例

相對于參與者而言，用例泛化更易理解。用例泛化是指一個用例（一般為子用例）和另一個用例（父用例）之間的關系，其中父用例描述了子用例與其他用例共享的特性，而這些用例是有著同一父用例的。

泛化將特化用例和一般用例聯系起來。即子用例是父用例的特化，子用例除具有父用例的特性外，還可以有自己的另外特性。父用例可以被特化成一個或多個子用例，然后用這些子用例來代表父用例的更多明確的形式。

泛化的標記非常簡單，它使用一條實線和三角箭頭連接父用例和子用例，由子用例指向父用例，如下圖所示。

因為父用例“身份驗證”是抽象的，它并不提供具體的身份驗證方法，所以一個具體的子用例必須提供具體的功能。

子用例“口令驗證”提供的身份驗證方法為：

□　從主數據庫獲得密碼。

□　請求使用密碼。

□　用戶提供密碼。

□　在用戶登錄時檢查密碼。

子用例“指紋驗證”提供的身份驗證方法為：

□　得到來自主數據庫的指紋特征。

□　掃描用戶的指紋特征。

□　將主數據庫指紋特征和掃描特征比較。

深入研究本示例，會發現身份驗證不只有兩個子用例。下圖演示了一個父用例的多個子用例。

泛化甚至可以分層，父用例的子用例也可以有自己的子用例，如下圖所示。

2．泛化參與者

與用例一樣，也可以對參與者進行泛化。泛化后的參與者也在系統中扮演較為具體的角色。如下圖所示，假設圖書管理系統中，管理員分為對系統進行維護的管理員和完成借書、還書等日常操作的圖書管理員。參與者“經理”描述了參與者“圖書管理員”和“管理員”所扮演的一般角色。如果不考慮與系統交互時的職責，可以使用一般角色的參與者“經理”。如果強調管理員的職責，那么用例須使用精確的參與者，即子類“圖書管理員”和“管理員”。

除此之外，還可以將泛化后的用例與泛化后的參與者相聯系起來，如下圖所示的泛化的用例與泛化的參與者相關聯。

3.2.2 包含關系

在對系統進行分析時，通常會發現有些功能在不同的環境下都可以被使用。在編寫代碼時，希望編寫可重用的構件，這些構件包括諸如可以從其他代碼中調用或參考的類庫、子過程以及函數。雖然每個用例的實例都是獨立的，但是一個用例可以用其他的更簡單的用例來描述。用例圖中UML包含關系就支持這種做法。

包含關系指：一個用例可以簡單地包含其他用例具有的行為，并把它所包含的用例行為作為自身行為的一部分。這種情況下，新用例不是初始用例的一個特殊例子，并且不能被初始用例所代替。包含關系把幾個用例的公共步驟分離成一個單獨的被包含用例。

如果兩個以上用例有大量一致的功能，則可以將這個功能分解到另一個用例中。其他用例可以和這個用例建立包含關系。

一個用例的功能太多時，可以用包含關系建模兩個小用例。

被包含用例稱作提供者用例，包含用例稱作客戶用例，提供者用例提供功能給客戶使用。

在UML中，包含關系表示為虛線箭頭加<<include>>字樣，箭頭指向被包含的用例。如下圖所示是圖書管理系統中的包含關系。

為了更好地理解包含關系是如何起作用的，下面列出了“商品信息系統”和“建材信息系統”使用已經存在的被包含用例，如下圖所示。

為了使用包含關系，用例必須遵循以下兩個約束條件。

□　客戶用例只依賴于提供者用例的返回結果，不必了解提供者用例的內部結構。

□　客戶用例總會要求提供者用例執行，對提供者用例的調用是無條件的。

在為系統建模時，使用包含關系是十分明智的。因為它有助于在將來實現系統時，確定哪里可以重用某些功能，在編寫代碼時就可實現代碼的重用，從而從長遠意義上縮短系統的開發周期。

3.2.3 擴展關系

擴展關系是一種依賴關系，它指一個用例可以增強另一個用例的功能，是把新的行為插入到已有用例中的方法。

基礎用例的擴展增加了原有的功能，此時是基礎用例被作為用例使用，而不是擴展用例。

基礎用例提供了一組擴展點，在這些新的擴展點中可以添加新的行為，而擴展用例提供了一組插入片段，這些片段能夠被插入到基礎用例的擴展點上。

基礎用例不必知道擴展用例的任何細節，它僅為其提供擴展點。

基礎用例即使沒有擴展用例也是完整的，這點與包含關系有所不同。

一個用例可能有多個擴展點，每個擴展點也可以出現多次。一般情況下，基礎用例的執行不會涉及擴展用例，只有特定的條件發生，擴展用例才被執行。

擴展關系為處理異常或構建靈活的系統框架提供了一種十分有效的方法。

在UML中，擴展關系表示為虛線箭頭加<<extend>>字樣，箭頭指向被擴展的用例（即基礎用例），箭頭的尾部則處在擴展用例上，如下圖所示是擴展關系標識符。

下面的示例將演示在圖書管理系統中如何使用擴展關系：超期處理用例由通知超期用例進行擴展，如下圖所示。

在本示例中，基礎用例是超期處理，擴展用例是通知超期。如果借閱者按時歸還圖書，那么就不會執行通知超期用例。而當歸還圖書時超過了規定的時間，則超期處理用例就會調用通知超期用例提醒管理員對此進行處理。

正如上圖中所表示的，通知超期用例指向超期處理用例。這樣繪制的原因是因為通知超期用例擴展了超期處理用例，即通知超期用例是添加到超期處理用例中的一項功能，而不是超期處理用例每次都調用通知超期用例。如果每次檢查是否超期時都要提醒圖書管理員，那么就要使用如下圖所示的包含關系。

在理解了什么是擴展用例，以及使用它的原因后，那么如何知道圖書管理員何時被提醒呢？畢竟這只在所借閱的圖書超期時才被提醒，而且不是隨時提醒的。本示例設定為當某學生所借閱的圖書中有超期借閱時，圖書管理員才會被提醒。為此，UML提供了擴展點來解決該問題。擴展點的定義為：基礎用例中的一個或多個位置，在該位置會衡量某個條件以決定是否啟用擴展用例。下圖為一個擴展點的標記符。

如上圖所示，一個水平線分隔了基礎用例，而基礎用例的用例名移到了橢圓的上半部分。橢圓的下半部分則列出了啟用擴展用例的條件。

下圖使用包含擴展點標記符的基礎用例來表明如果借閱者有超期的借閱信息，那么基礎用例則啟用擴展用例通知圖書管理員。

如上圖所示，擴展點中有一個判斷條件，以決定擴展用例是否會被使用，在包含關系中沒有這樣的條件。擴展點定義了啟用擴展用例的條件，一旦該條件滿足，則擴展用例將被使用。例如，當某學生的借閱信息中有超期的借閱信息時，則基礎用例ProcessOverTime會使用NotifyOverTime用例，以通知圖書管理員該學生有圖書超期未還。當執行完擴展用例NotifyOverTime后，基礎用例將繼續執行。

擴展點的表示符號可以按照下面的格式添加到橢圓中，即：

      <extension point>::=<name>
[:<explanation>]

其中，name指擴展點的名稱，因為一個基礎用例可以有多個擴展用例。擴展點的名稱描述了用例中的某個邏輯位置。因為用例描述的是功能和行為，所以該位置通常是對象在執行過程中某時間的狀態。explanation為對擴展點的解釋，它為一個可選項。該項可以是任何形式的文本，只要把問題交代清楚即可。需要注意，在繪制擴展點時，并不是所有的UML建模工具都支持上述命名方法。

除在基礎用例上使用擴展點控制什么時候進行擴展外，擴展用例自身也可以包含條件。擴展用例上的條件是作為約束使用的，在擴展點成立的時候，如果該約束表達式也得到了滿足，則擴展用例才執行，否則不會執行。

3.2.4 用例描述

用例圖描述了參與者和系統特征之間的關系，但是它缺乏描述系統行為的細節。所以一般情況下，還會以書面文檔的形式對用例進行描述，每個用例應具有一個用例描述。在UML中對用例的描述并沒有硬性規定，但一般情況下用例描述應包括以下幾個方面內容。

1．名稱

名稱無疑應該表明用戶的意圖或用例的用途，如上面示例中的“借閱圖書”“歸還圖書”。

2．標識符[可選]

唯一標識一個用例，如“UC200601”。這樣就可在項目的其他元素（如類模型）中用它來引用這個用例。

3．參與者[可選]

與此用例相關的參與者列表。盡管這則信息包含在用例本身當中，但在沒有用例圖時，它有助于增加對該用例的理解。

4．狀態[可選]

指示用例的狀態，通常為以下幾種之一：進行中、等待審查、通過審查或未通過審查。

5．頻率

參與者使用此用例的頻率。

6．前置條件

一個條件列表。前置條件描述了執行用例之前系統必須滿足的條件。這些條件必須在使用用例之前得到滿足。前置條件在使用之前，已經由用例進行過測試。如果條件不滿足，則用例不會被執行。

前置條件非常類似于編程中的調用函數或過程，函數或過程在開始部分對傳遞的參數進行檢測。如果傳遞的參數無法通過合法檢查，那么調用的請求將會被拒絕。同樣這也適用于用例。例如，當學生借閱圖書時，借出圖書用例需要獲取學生借書證信息，但如果學生使用了一個已經被注銷的借書證，那么用例就不應該更新借閱關系；另外，如果學生歸還了從系統中已經刪除的一本圖書，那么用例就不能讓還書操作完成。

借閱圖書用例的前置條件可以寫成下面的形式。

前置條件：學生出示的借書證必須是合法的借書證。

7．后置條件

后置條件將在用例成功完成以后得到滿足，它提供了系統的部分描述。即在前置條件滿足后，用例做了什么？以及用例結束時，系統處于什么狀態？因為并不知道用例終止后處于什么狀態，因此必須確保在用例結束時，系統處于一個穩定的狀態。例如，當借閱圖書成功后，用例應該提供該學生的所有借閱信息。

借閱圖書用例的后置條件可以寫成下面的形式。

后置條件：借書成功，則返回該學生借閱信息；借書失敗，則返回失敗的原因。

8．假設[可選]

為了讓一個用例正常運行，系統必須滿足一定的條件，在沒有滿足這些條件之前，系統不會調用該用例。假設描述的是系統在使用用例之前必須滿足的狀態，這些條件并沒有經過用例的檢驗，用例只是假設它們為真。例如，身份驗證機制，后繼的每個用例都假設用戶是在通過身份驗證以后訪問用例的。應該在一定的時候檢驗這些假設，或者將它們添加到操作的基本流程或可選流程中。

下面是借閱圖書用例的假設條件。

假設：圖書管理員已經成功登錄到系統。

9．基本操作流程

參與者在用例中所遵循的主邏輯路徑。因為它描述了當各項工作都正常進行時用例的工作方式，所以通常稱其為適當路徑或主路徑。操作流程描述了用戶和執行用例之間交互的每一步。描述操作流程是一項將個別用例進行合適細化的任務。通過這種做法，常常可以發現自己原始的用例圖遺漏了哪些內容。

借出圖書用例的基本操作流程如下。

（1）管理員輸入借書證信息。

（2）系統要確保借書證信息的有效性。

（3）檢查是否有超期的借閱信息。

（4）管理員輸入要借閱的圖書信息。

（5）系統將學生的借閱信息添加到數據庫中。

（6）系統顯示該學生的所有借閱信息。

10．可選操作流程

可選操作流程包括用例中很少使用的邏輯路徑，那些在變更工作方式、出現異常或發生錯誤的情況下所遵循的路徑。例如，借出圖書用例的可選操作流程包括：輸入的借書證信息不存在，該借書證已經被注銷或有超期的借閱信息等異常情況下，系統采取的應急措施。

11．修改歷史記錄[可選]

修改歷史記錄是關于用例的修改時間、修改原因和修改人的詳細信息。下表是一個對用例“歸還圖書”的描述。

上表所示的格式和內容只是一個示例，開發人員可以根據自己的情況定義。但要記住，用例描述及它們所包含的信息，不僅是附屬于用例圖的額外信息。事實上，用例描述讓用例變得完整，沒有用例描述的用例沒什么意義。

隨著更多的用例細節被寫到用例描述中，往往還會發現用例圖中遺漏的某些功能。在模型的各個方面也會出現同樣的問題：加入的細節越多，越可能必須回頭更正以前所做的事。這是一個反復系統開發工作的內涵。進一步精煉系統模型是件好事，開發工作的每一次反復，都可以使系統模型更好、更準確。