UML用例圖之泛化(generalization)、擴展(extend)和包含(include)關係--UML一波流系列講解
Peter Wei
在畫用例圖的時候，理清用例之間的關係是重點。用例的關係有泛化(generalization)、擴展(extend)和包含(include)。其中include和extend最易混淆。下面我們結合實例徹底理清三者的關係。
基本概念
用例圖（Use Case Diagram）:用例圖顯示誰是相關的用戶，用戶希望系統提供什麼服務（用例），以及用例之間的關係圖。用例圖主要的作用是獲取需求、指導測試。
用例圖的4個基本組件：參與者(Actor)、用例(Use Case)、關係(Relationship)和系統。
泛化(generalization)：泛化關係是一種繼承關係，子用例將繼承基用例的所有行爲，關係和通信關係，也就是說在任何使用基用例的地方都可以用子用例來代替。泛化關係在用例圖中使用空心的箭頭表示，箭頭方向從子用例指向基用例。
擴展(extend)： extend關係是對基用例的擴展，基用例是一個完整的用例，即使沒有子用例的參與，也可以完成一個完整的功能。extend的基用例中將存在一個擴展點，只有當擴展點被激活時，子用例纔會被執行。 extend關係在用例圖中使用帶箭頭的虛線表示(在線上標註<<extend>>)，箭頭從子用例指向基用例。
包含(include)： include爲包含關係，當兩個或多個用例中共用一組相同的動作，這時可以將這組相同的動作抽出來作爲一個獨立的子用例，供多個基用例所共享。因爲子用例被抽出，基用例並非一個完整的用例，所以include關係中的基用例必須和子用例一起使用纔夠完整，子用例也必然被執行。include關係在用例圖中使用帶箭頭的虛線表示(在線上標註<<include>>)，箭頭從基用例指向子用例。
實例需求場景
聯通客戶響應OSS。系統有故障單、業務開通、資源覈查、割接、業務重保、網絡品質性能等功能模塊。現在我們抽出部分需求做爲例子講解。
需求1：客戶響應用戶和國際客服可以進行割接通知查詢，在頁面上有骨幹割接查詢、省間割接查詢、省級割接查詢的Tab。
分析：可以很容易看出割接查詢和不同的割接子查詢Tab之間是繼承的關係，所以此處用泛化。用戶和客戶響應、國際客服也是繼承的Actor關係。
需求2：客戶響應用戶和國際客服可以查看某條割接通知信息，可以在頁面上導出割接信息Excel格式，可以查詢和該條割接相關聯的故障單信息。
分析：因爲導出割接和查看相關聯的故障單信息都是可選的，就是說我查看割接的時候，也可以不進行這些操作，所以這裏用extend關係。也就是導出割接和查看故障單信息擴展了查看割接信息。
需求3：客戶響應用戶可以以網管系統爲來源創建割接通知，在創建割接通知時可以保存爲草稿，也可以直接發佈割接通知。
分析：由於創建割接通知時，發佈割接通知可以同時進行，也可以先存爲草稿，所以發佈割接是可選的，用extend就比較合適。也就是發佈割接擴展了創建割接通知。
需求4：用戶在進行業務開通、發佈割接通知、發佈重保通知及相關跨省的業務時需要進行數據分發。
分析：由於業務開通、重保、割接及其它跨省的業務都需要用到數據分發用例，我們可以將數據分發用例單獨抽出來，供各業務使用，這裏用include就比較合適。實際的系統中數據分發也是單獨抽出來用jms和webservice實現的接口服務。
其它需求：可以看到刪除割接通知和查看割接明細也可以做爲割接通知查詢用例的擴展，因查詢列表時，一般可以選擇繼續查看明細或者刪除操作。但在實際化圖中，這兩個extend可以不畫，這裏只是爲了讓大家理解概念。
用例圖
大家可以參照着圖，好好理解。
加深理解
我們再用另外一個場景的用例說明一下include和extend,因爲就這兩個玩意比較容易搞混。
銷戶：因爲銷戶必需先進行賬戶結算，所以這裏用include
停機提醒：有兩個可選項，短信提醒和郵件提醒，所以用extend.
經過以上的分析，相信大家對三種關係已經有比較好的理解了。大家有什麼其它想法或好的見解，歡迎拍磚。
PS：以上用例圖用Enterprise Architect 7.5所畫，在此推薦一下EA,非常不錯。可以替代Visio和Rose了。Visio功能不夠強大，Rose太重。唯有EA比較合適。