【UML實戰智慧第6回】使用案例常用技巧實例

在上一回文章中，我們介紹如何從業務流程圖導出初版的使用案例，並依此來繪製功能架構圖和使用案例圖，以及撰寫使用案例敘述。系統分析師要繪製使用案例圖時，有一些現場常用的圖示。

參與者

圖1 參與者與結合關係 圖2 主要參與者與次要參與者 圖3 外部服務

參與者位於系統外部，會與系統共同執行使用案例敘述中所載明的一套動作。參與者的圖示是人形圖示，放置在系統方框外，以結合關係的實線連接使用案例，如圖1所示。

此外，在結合關係的實線上，我們會建議系統分析師加上箭頭，用來區分主要參與者與次要參與者。主要參與者負責啟動使用案例，因此又稱為「啟動者」。而次要參與者則負責支援系統執行使用案例，所以也稱為「支援者」。如圖2所示。

參與者並不侷限是人類用戶，也可能是連線系統、外部資料庫、外部服務等。外部服務最常見的例子是排程服務，我們建議系統分析師可以善用排程服務來啟動定時啟動的使用案例，如圖3所示。

使用案例實務技巧
使用案例規範著一套動作，經由這套動作，系統可以產出明顯且有價值的服務或產品。在使用案例圖面上，橢圓圖示代表的使用案例放置在系統方框內，並且將使用案例的一套動作記錄在使用案例的主要流程中。

圖4 查詢基金基本資料使用案例的主要流程與替代流程

在主要流程中載明的是一般的、正常的基本流程，執行期間發生較少出現的特殊支流時，則另外記錄在替代流程中。以查詢基金基本資料為例，系統提供匯出Excel檔的附加功能，方便銀行客戶取得查詢結果作為他用。針對主要流程第3步驟，可能出現一個匯出Excel檔的支流，記錄成編號3.a的替代流程，如圖4。

步驟前的數字編號意味著按照數字依序執行；英文編號則意味著未按照順序，可能發生其中一個步驟，也可能發生其中多個步驟，但是就是不需要按照順序，所以沒有數字編號。

舉例來說，在主要流程的第2步驟下方編列了2.a、2.b、2c，而不是2.1、2.2、2.3，意味著銀行客戶可以只擇一輸入基金公司名稱、基金名稱、關鍵字，也可以隨意混用這三個查詢條件，所以沒有依序執行的限制。

至於，替代流程是主要流程的支流，所以在替代流程的步驟編號上，會先帶出主要流程的步驟編號，後面才是自己的編號。例如，此處替代流程3.a意味著關係到主要流程的第3步驟。

附帶一提的是，有些使用案例可能會被要求必須在通過某些限制條件時，才能夠執行。在這種情況下，可以為使用案例加入前置條件（pre-condition），用來限制使用案例的啟動。

圖5 申辦基金帳戶的前置條件

以開基金帳戶的業務流程為例，銀行會要求銀行客戶必須先擁有本銀行的綜合存款帳戶。因此，系統分析師可以把這個條件設為啟動「申辦基金帳戶」使用案例的前置條件，意味著必須通過這項前置條件，才能夠啟動這個使用案例，如圖5。

圖6 申辦基金帳戶的後置條件

有前置條件，相對的，也有後置條件（post-condition）。前置條件做為執行使用案例前的把關，後置條件則為執行後做把關。一旦，使用案例正常執行完畢後，就應該可以通過後置條件，否則會意味著該使用案例並未正常執行完畢。同樣以申辦基金帳戶為例，後置條件可能是已經取得了申辦案件序號，如圖6。

包含關係與擴充關係

圖7 包含關係與擴充關係

使用案例之間的主要關係有兩種，一為「包含關係」（include），另一為「擴充關係」（extend）。兩者都採用帶箭頭虛線，而且得在虛線旁邊標示出《include》或《extend》字眼，特別需要注意的是，兩者的箭頭方向恰好相反，如圖7所示。

包含關係和擴充關係兩者在概念上，最大的差異在於，基礎使用案例一定會連帶執行被包含的使用案例；但是，不一定會執行擴充的使用案例。用具體的例子來說明，會更容易理解抽象的概念，所以，我們還是來看實例吧！

包含關係實例

圖8 向銀行系統查驗綜存帳戶資料

舉例來說，申辦基金帳戶使用案例的前置條件是，銀行客戶已經擁有綜合存款帳戶了。但是，綜存帳戶的資料並不是存在基金系統中，而是由另一個銀行系統負責保管的。所以，常見的做法，可能使將銀行系統列為次要參與者，如圖8所示。 可是，系統分析師可能會有如下的考慮：

1. 基金系統中可能有多個使用案例，都需要查詢綜合存款帳戶的資料。

圖9 介接服務的功能模組 圖10 包含關係 圖11 標記出前置條件 圖12 申辦基金帳戶的前置條件 圖13 申辦基金帳戶的操作流程 圖14 人工查驗 圖15 申辦基金帳戶的操作流程（修訂後） 圖16 查驗綜存帳戶的操作流程 圖17 申辦基金帳戶的後置條件

2. 再者，綜存帳戶的資料其實完全由另一個銀行系統所提供，為了將基金系統與其他系統之間的相依性侷限在一處，所以系統分析師會切分出「介接服務」的功能模組，專門用來安置委託其他系統執行的使用案例。

基於上述的兩項考慮，所以系統分析師決定把查驗綜存帳戶的流程切出來，新增另一個小的使用案例，並且放置在介接服務功能模組中，如圖9所示。

對於申辦基金帳戶使用案例而言，一定要確認綜存帳戶已經存在，才能夠被啟動，所以兩個使用案例之間就可以使用「包含關係」了，如圖10所示。

此外，系統分析師也可以在包含關係旁，特別標記出「前置條件」的字眼，意味著系統是因為要檢驗申辦基金帳戶的前置條件，才設置這條包含關係的，如圖11所示。

對應圖11的情況，在申辦基金帳戶的使用案例敘述中，我們可能做如下的敘述，如圖12所示。在操作流程上，我們也可以有如圖13的設計：

剛才我們看到的是基金系統自動查驗綜存帳戶存在與否的設計，此處我們來看另一種設計，讓理財專員人工查驗綜存帳戶。在這種設計下，我們調整了下列二處：

1. 申辦基金帳戶的前置條件，可以刪去了。

2. 申辦基金帳戶的使用案例，不需要包含查驗綜存帳戶這個小的使用案例了，所以可以刪去兩者之間的包含關係，改由理財專員直接啟動查驗綜存帳戶，如圖14所示。

如此一來，操作流程可能也要同步修訂，得把查驗綜存帳戶跟申辦基金帳戶切開來描述，如圖15和圖16。

最後，我們再來整理一下。兩個使用案例之間具有包含關係時，有下列三項特色：

1. 被包含的小使用案例無法脫離基礎使用案例，而獨立存在。

2. 基礎使用案例一定會執行被包含的小使用案例。

3. 兩者加起來是一條流程，正如圖17所示。

擴充關係
當兩個使用案例之間具有擴充關係時，基礎使用案例不一定會執行擴充的小使用案例，通常是在符合特定的條件下，才會額外執行擴充使用案例的小流程。因此，擴充關係的特色為：

1. 擴充的小使用案例無法脫離基礎使用案例，而獨立存在。

2. 基礎使用案例「不一定」會執行擴充的小使用案例。

3. 兩者加在一起，形成兩條流程：其一是單獨執行基礎使用案例，另一條流程是基礎使用案例外加擴充使用案例，如圖18所示。

圖18 兩條流程

還記得我們前面提到查詢基金基本資料使用案例，有一個替代流程是可以把查詢結果打包成Excel檔，方便銀行客戶匯出做為其他用途。隨後，系統分析師發現另一個「查詢基金投資明細」的使用案例，也需要提供Excel查詢結果檔。此時，系統分析師考慮將「匯出Excel查詢結果檔」切分出來，成為另一個小的擴充使用案例，這樣就可以讓查詢基金基本資料和查詢基金投資明細這兩個使用案例，共用匯出Excel查詢結果檔，如圖19和圖20所示。

圖19 擴充關係

圖20 查詢基金基本資料和查詢基金投資明細的替代流程