UML用例間包含關系與泛化關系的比較與分析

蘇晶

山東理工大學 山東 淄博 255049

引言

UML用例模型是系統需求獲取及分析的重要手段，是最終用戶與開發人員溝通和交流的有效途徑。一旦用例模型被確定，所有分析、設計和開發，包括之后的部署及測試等工作都需要以此為依據開展。

對于一個系統而言，不同參與者的需求千差萬別；另外，為了確保系統安全性，也需要為不同的參與者設置不同的訪問功能和權限。在系統分析和設計過程中，關系直觀體現了參與者訪問系統功能的具體方式，并直接影響和決定了系統的具體實現方式。由此可以看出，關系的識別在構建用例模型的過程中發揮著至關重要的作用。

其中包含關系和泛化關系在表現形式和使用方法上較為相似，容易產生混淆，本文以自主點餐系統為例，對兩種關系的建模要點進行分析和比較。

1 用例間的關系

1.1 包含關系

包含關系是指一個用例可以簡單地包含其他用例具有的行為，并將其所包含的用例行為作為自身行為的一部分，這兩個用例分別被稱為基礎用例和被包含用例。包含關系的具體表現形式為被包含用例的事件流可插入至基礎用例的事件流中。

在用例圖的建模過程中，一般有兩種情況需要使用到包含關系。第一種最為常用，在對用例的事件流進行描述的過程中，若發現多個用例同時使用到同一段行為，則可將這段共同的行為單獨抽象成為一個用例，然后建立兩者之間的包含關系，從而實現重用并簡化事件流描述的目的。

以自主點餐系統為例，客戶可以進行“預約餐臺”、“下單點餐”、“支付結算”和“發表評價”四個操作，所有操作均需在“登錄系統”后方可完成。根據描述，“登錄系統”為多個用例的共同行為，可將其抽象出來，成為一個新的用例，并建立其與4個基礎用例之間的包含關系。關系一旦創建，這4個基礎用例在用例規約的事件流描述中可直接對“登錄系統”用例的事件流進行引用，避免了對公共行為的重復描述，提高了模型的可維護性。

包含關系使用的第二種情況為某一個用例提供的功能過多，事件流過于復雜，此時可將該用例分解為粒度較小的幾個用例，然后建立分解后小用例與原來基礎用例之間的包含關系。

如自主點餐系統中管理員的“維護菜品”操作，由于功能過多，可將其分解為“添加菜品”、“修改菜品”和“刪除菜品”三個用例，則三個粒度較小用例與基礎用例間可建立包含關系。需要注意的是，這種方式的包含關系不允許參與者直接訪問包含用例，這也是兩種包含關系之間最大的區別。

1.2 泛化關系

用例間的泛化關系將特化的用例與一般化的用例聯系起來，這兩個用例分別被稱為子用例和父用例。子用例繼承了父用例所有的結構、行為和關系，并且可以添加、覆蓋或者改變繼承的行為。

在對用例的事件流進行描述的過程中，發現兩個或者多個用例在行為、結構和目的方面存在共性時，可以新建一個一般化的用例用于描述這些共有部分和一般過程，然后建立特化用例和一般化用例之間的泛化關系，從而實現重用并簡化事件流描述的目的。

在自主點餐系統的功能性需求中，有這樣一段描述，“支付結算”主要包括“支付寶結算”和“會員卡結算”兩種方式。經過分析發現，“支付寶結算”和“會員卡結算”兩個用例在行為、結構和目的方面都存在共性，都屬于“支付結算”的特殊方式，因此可將其抽象為父用例，兩種代表具體支付方式的用例抽象為子用例，建立泛化關系，并且箭頭方向從子用例指向父用例。

需要注意的是，為了降低系統耦合度，一般將父用例設計為抽象用例，即在父用例中并不提供具體的行為和功能，而將行為描述的職責交給子用例來完成[1]。

2 包含關系與泛化關系的比較

包含關系和泛化關系均屬于用例之間的關系，并且基本表現形式都是從現有用例的事件流中抽取出共有部分，將其作為一個單獨的用例，從而達到復用現有用例的行為，并提高模型可維護性的目的。但兩者在實際使用過程中又存在著顯著的區別。

以自主點餐系統為例，分析兩者的區別主要包括以下兩個方面：

2.1 原有用例的相似程度

在泛化關系中，子用例“支付寶結算”和“會員卡結算”不管在名稱、行為、結構還是目等方面都存在著共性，并且都屬于“支付結算”的特殊形式，因此原有用例是整體上的相似。

而在包含關系中，基礎用例“預約餐臺”、“下單點餐”、“支付結算”和“發表評價”在名稱、結構和目的方面可以完全不同，只不過它們都有一段相似的行為，也就是“登錄系統”而已，因此原有用例只是部分上的相似。

2.2 新用例是否一定被執行

在泛化關系中，需要將多個子用例中的共性抽象成為一個父用例，子用例在繼承父用例的基礎上可以進行修改，子用例間相互獨立，任何一個子用例的執行不受其他子用例的影響。如果父用例“支付結算”為抽象用例，不提供具體的查看方法，則子用例“會員卡結算”被參與者啟動后，父用例“支付結算”不會被執行。

而對于包含關系，是將多個基礎用例中的公共行為抽象為一個被包含用例，可以說被包含用例是基礎用例的重要組成部分，因此，基礎用例“支付結算”被參與者啟動后，被包含用例“登錄系統”必然會被執行[2]。

3 結束語

用例圖中的模型元素之間并非相互獨立，參與者之間、用例之間、參與者與用例之間均存在著不同類型的關系。從用戶層面來看，關系描述了模型元素間具體化的語義連接，反映了參與者使用系統的具體方式；從開發者層面來看，關系體現了事件處理的流程與協作，決定了系統功能的實現方式。因此，在用例建模過程中，需準確把握各種關系的使用方法和建模要點，避免因識別有誤而對后續的設計和開發過程產生不利影響。