UML用例圖中泛化、擴展、包括


在畫用例圖的時候,理清用例之間的關系是重點。用例的關系有泛化(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比較合適。


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM