解析UML用例圖中include與extend的區(qū)別
本文和大家重點(diǎn)討論一下UML用例圖中include與extend的區(qū)別，include是指用例中的包含關(guān)系，通常發(fā)生在多個(gè)用例中，有可以提取出來(lái)的公共部分，而extend則恰好相反。下面請(qǐng)看本文詳細(xì)介紹。
UML用例圖中include與extend的區(qū)別
最近上論壇，看到在爭(zhēng)論UseCase中include與extend的區(qū)別。其實(shí)這兩者是很容易區(qū)分的。
include是指用例中的包含關(guān)系，通常發(fā)生在多個(gè)用例中，有可以提取出來(lái)的公共部分（就象提取公因式一樣），例如UseCaseA中包括了a和b兩個(gè)流程，而UseCaseC中包含了c和b兩個(gè)流程。為了提高復(fù)用性，可以把b提取出來(lái)，形成另一個(gè)用例UseCaseB，此時(shí)，UseCaseAincludeUseCaseB（表現(xiàn)為一條指向UseCaseB的虛線，箭頭在UseCaseB側(cè)），UseCaseC也includeUseCaseB。因而，當(dāng)有include關(guān)系時(shí)，被include的用例通常會(huì)被兩個(gè)以上的其他用例include（否則就不需要重用，也就不需要提取出來(lái)了），UML用例圖如下：
在include關(guān)系中，“UseCaseA和UseCaseC知道UseCaseB的存在，而UseCaseB根本不知道有UseCaseA和UseCaseC）；
extend則恰好相反。假設(shè)UseCaseA的功能描述為“發(fā)送一條通知”，可是，發(fā)送通知的方式可能有許多種，例如通過(guò)郵件發(fā)送、通過(guò)短信發(fā)送等。在需求分析階段，可能無(wú)法明確到底有多少種方式，在用例分析階段，UseCaseA需要留出擴(kuò)展接口，然后把已知的發(fā)送方式作為擴(kuò)展用例給出，例如UseCaseB是“通過(guò)短信發(fā)送”，而UseCaseC是“通過(guò)郵件發(fā)送”，此時(shí)，UseCaseB和UseCaseCextend了UseCaseA，表現(xiàn)為兩根虛線，箭頭指向UseCaseA，UML用例圖如下：
在extend關(guān)系中，UseCaseA不知道UseCaseB和UseCaseC的存在，但UseCaseB和UseCaseC卻是知道UseCaseA并且知道如何在UseCaseA中作擴(kuò)展的。
另：在UML用例圖中，有時(shí)會(huì)看到兩個(gè)用例之間有依賴關(guān)系（表現(xiàn)為一條單向或雙向的實(shí)線），這是錯(cuò)誤的，說(shuō)明用例沒(méi)有提純。
也許有人會(huì)問(wèn)“如果兩個(gè)用例之間，一個(gè)要調(diào)用另一個(gè)時(shí)，怎么辦？”（有可能是混淆了用例和模塊的關(guān)系），那么，首先要區(qū)分概念，用例就是用例，用例不是模塊，也不是組件（雖然一個(gè)用例能發(fā)展成為“一個(gè)或多個(gè)”模塊或組件）；其次，從用例分析的角度來(lái)看，如果用例A確實(shí)要調(diào)用到用例B，那么，可以進(jìn)一步分析：A是調(diào)用了B的所有流程呢，還是其中一部分流程？
（1）如果是調(diào)用了一部分，此時(shí)可以把B中的那部分流程提取出來(lái)，形成用例C，然后A和B都includeC；
（2）如果是調(diào)用了所有流程，那么，A直接includeB即可；
（3）如果A沒(méi)有調(diào)用B中的任何流程……faint，那還畫那條代表依賴的實(shí)線干嘛？
【編輯推薦】
- 解析繪制UML用例圖的基本步驟
- UML用例圖實(shí)例解析
- UML建模：創(chuàng)建UML用例圖
- 揭秘三大UML用例圖關(guān)系
- 學(xué)習(xí)筆記 解析UML用例圖元素之間的關(guān)系
