1. 程式人生 > >再看包含、擴充套件和泛化、繼承

再看包含、擴充套件和泛化、繼承

    我們知道包含和擴充套件是用例圖中所特有的關係,而泛化和繼承則不僅用於用例圖,同時也適用於其他圖,如類圖。這兩對概念相信對於學習面向物件中的我們來說是很容易混淆的,很多時候自己都不知道包含和擴充套件箭頭到底該指向哪裡,是虛線還是實線,泛化到底跟繼承什麼關係?經常為此大家爭

得面紅耳赤,下面我就來捋一捋(本篇部落格想要表達的意思已經用紅色標出,如果有什麼不妥之處歡迎批評指教~)。

(1)   包含(include)關係

    當可以從兩個或兩個以上的用例圖中提取公共行為時,應該使用包含關係來表示它們。其中這個提取出來的公共用例成為抽象用例,而把原始用例成為基本用例或基礎用例。例如,圖1中的“登記外借資訊”和“查詢外借資訊”兩個用例都需要登陸,為此,可以定義一個抽象用例“使用者登入”。用例“登記外借資訊”和“查詢外借資訊”與用例“使用者登入”之間的關係就是包含關係。其中<<include>>是包含關係的構造型,箭頭指向抽象用例。

 

    當多個用例需用使用同一段事件流時,抽象成為公共用例,可以避免在多個用例中重複地描述這段事件流,也可以防止這段事件流在不同用例中的描述出現不一致。當需要修改這段公共的需求時,也只要修改一個用例,避免同時修改多個用例而產生的不一致性和重複性工作。另外,當某個用例的事件流過於複雜時,為了簡化用例的描述,也可以將某一段事件流抽象成為一個被包含的用例。

(2)   擴充套件(extend)關係

    如果一個用例明顯的混合了兩種或兩種以上的不同場景,即根據情況可能發生多種分支,則可以將這個用例分為一個基本用例和一個或多個擴充套件用例,這樣使描述可能更加清晰。如上圖中的圖書管理員進行“查詢書籍資訊”操作時,如果發現書籍資訊有誤,他可以使用“修改書籍資訊用例來完成錯誤的修改。所以用例“查詢書籍資訊”和“修改書籍資訊”之間的關係就是擴充套件關係。其中<<extend>>是擴充套件關係的構造型,箭頭指向基本用例。

(3)   泛化和繼承

    當多個用例共同擁有一種類似的結構和行為時,可以將它們的共性抽象成為父用例,其他的用例作為泛化關係中的子用例。在用例的泛化關係中,子用例是父用例的一種特殊形式,子用例繼承了父用例所有的結構、行為和關係。例如下圖中:使用者註冊有多種方式,可以是“現場註冊”也可以是“網上註冊”。所以“使用者註冊”用例就是“現場註冊”和“網上註冊”用例的泛化。其中三角箭頭指向父用例。


而繼承關係是泛化關係的反關係,也就是說子類是從父類繼承的,而父類則是子類的泛化。

    從UML事物關係的本質上來看,包含關係和擴充套件關係都屬於依賴關係(所以呢,都是虛線啦)。對包含關係而言,抽象用例中的事件流是一定會插入到基本用例中取得,並且插入點只有一個。擴充套件用例的事件流往往可以抽象為基本用例的備選事件流,在擴充套件關係中,可以根據一定的條件來決定是否將擴充套件用例的事件流插入到基本用例的事件流中,並且插入點可以有多個。在實際應用中,很少使用泛化關係,子用例的特殊行為都可以作為父用例中的備選事件流而存在。

    在實際工作中,要謹慎選用這些關係。從上面的介紹可以看出,包含、擴充套件和泛化關係都會增加用例的個數,從而增加用例模型的複雜度。另外,一般都是在用例模型完成之後才對它進行調整,在用例模型建立之初不必急於抽象用例之間的關係。