UML學習之用例圖

參考《UML面向對象系統分析與設計教程》

第四章    用例圖

一    在獲取用例前要先確定系統的活動者，系統分析人員可以根據以下一些問題來尋找系統的活動者。

1. 系統的主要客戶是誰
   

2. 誰從該系統獲取信息

3. 誰向系統提供信息

4. 誰來安裝、操作該系統

5. 誰來關閉該系統

6. 在預定的時刻，是否有時間自動發生

7. 誰使用或刪除系統中的信息

8. 系統從何處獲得信息

    一般的確定活動者應首先確定系統的範圍和邊界，並從應用的角度考慮系統的作用，確定將有哪些外部事物與系統進行交互。

二    用例（Use Case）是對一個活動者（參與者）使用系統的一項功能是所進行的交互過程的一個文字描述序列。

1. 用例（Use Case）是對系統的用戶需求（主要是功能需求）的描述，Use Case表達了系統的功能和所提供的服務
   

2. Use Case描述活動者與系統交互中的對話，這種對話表達了活動者與系統的交互的一系列步驟。

3. Use Case只描述活動者和系統在交互過程中做些什麼，並不描述怎麼做。

4. 一個活動者可以運行多個Use Case，而一個Use Case可以有多個活動者運行它。但是，也有的Use Case很難有與它明確關聯的活動者。

三    用例之間聯繫

1. 泛化聯繫

   當系統中具有一個或多個用例是較一般用例的特化時，就使用用例泛化。

2. 使用聯繫

   使用聯繫是指一個用例使用另一個用例的功能行爲。使用聯繫是一種泛化聯繫，如下例子中，用例“刪除教師”和用例“查找教師”之間、用例“更新教師”和“查找教師”之間存在着使用聯繫，在更新和刪除教師信息之前，必須要首先找出要處理的教師。

   
   

3. 包含聯繫

   包含聯繫是一種依賴聯繫，指一個基本用例的行爲包括了另一個用例的行爲。

4. 擴展聯繫

   擴展聯繫是把新行爲插入到已有用例的方法。基礎用例必須申明若干“擴展點”，而擴展用例只能在這些擴展點上增加新的行爲。如下用例圖，基礎用例是“還書”。如果借閱人所借圖書超期，按規定應繳納一定數額的罰金，這時就不能執行用例提供的常規動作。如果更改“還書”用例，必然會增加系統的複雜性。因此可以在還書用例中增加擴展點，特定條件是超期，如果滿足特定條件，將執行擴展用例“繳納罰金”，這樣顯然能使系統更容易被理解。

四    用例建模

    前面已經說過，用例圖（Use Case圖）是一種描述Use Case 的可視化工具，它用簡單的圖形元素表示出系統的活動者、Use Case及他們之間的關係，準確地表達了活動者與系統的交互情況和系統所能提供的服務。建立用例圖一般可以按照以下步驟進行。

1. 確定系統的邊界和範圍，明確系統外部的活動者和外部系統。
   

2. 確定每個活動者所期望的系統行爲。

3. 把這些系統行爲作爲系統的用例（Use Case）。

4. 把公共的系統行爲分解爲新的用例，供其他用例引用。把變更的行爲分解爲擴展用例。

5. 編制每一個用例的劇本。

6. 繪製用例圖。

7. 區分主業務流和異常情況的事件流。可以把表達異常情況的事件流的用例畫成一個單獨的子用例圖。

8. 精化用例圖。解決用例圖的重複與衝突問題，簡化用例中的對話序列。高層次的用例可以分解爲若干下屬子系統中的用例。

五    用例建模中應注意的問題（截取一些）

1. 用例應簡單明瞭，具有較強的可讀性。在建模時一個使用例儘可能簡短但要切中要點，用動詞短語命名用例。
   

2. 應該用文本和其他UML圖來描述用例是如何啓動和停止的。

3. 應從活動者的角度並以主動語態編寫用例。一方面，應該儘可能以主動語態而不是被動語態來編寫用例；另一方面，用例是用來描述用戶如何和系統進行交互的，故應儘可能從活動者的角度來編寫用例。

4. 用例只記載行爲需求，用例既不是類的規約，也不是數據部規約。

5. 應始終如一地組織用例圖。一般的做法是垂直地繪製繼承和擴展聯繫，水平地繪製包含聯繫。

6. 應讓用例帶動用戶文檔。

7. 應讓用例帶動演示。

8. 用例應對系統的作用域、系統所提供的功能以及爲支撐這些功能所必須依賴的元素進行定義。

六    小結

1. 用例圖是從用戶的角度而不是開發者的角度來描述對軟件產品的需求，分析產品所需的功能和動態行爲的。
   

2. 活動者是系統外部的一個實體（可以是任何的事物或人），它以某種方式參與了用例的執行過程。

3. 用例是對一個活動者使用系統的一項功能時所進行的交互過程的一個文字描述序列。用例之間可以存在一定的聯繫，這些聯繫包括泛化聯繫，使用聯繫，包含聯繫，擴展聯繫等。