用「衝刺0」打好Scrum專案的地基（四）

經過前面一連串的架構設計之後，我們要產出基金系統的使用案例圖，其實是件再容易不過的小事了。請你看到圖1的示意圖，我們可以從前面的新架構循序圖中，推出基金系統使用案例圖中的使用案例與參與者。當然，這也是我們前面進行架構設計，所衍生出來的價值之一。

圖1 查詢基金基本資料[基金系統]

其實，當我們運用了類別來表達子系統，並且使用循序圖來呈現子系統之間的互動後，就可以把發送給基金系統的訊息對應成類別中的操作，正如圖2所示。

圖2 訊息與操作[基金系統]

然後，我們還可以再進一步把基金系統中的操作對應成使用案例，所以打開對應基金系統的類別，就可以看到所有的基金系統必須提供的使用案例了，如圖3所示。

圖3 操作與使用案例[基金系統]

另外，如果有遇到系統物件發送訊息給自己的情況，可以對應成能見度為「私有」（Private）等級的操作，並且對應成使用案例之間的包含關係或擴充關係，如圖4所示。

圖4 回覆基金交易[基金系統]

基金系統的使用案例圖
經由上述的步驟，我們可以輕易推得初步的基金系統使用案例，為了方便觀看，將依照參與者把基金系統使用案例，分置於四張使用案例圖中，如圖5、圖6、圖7、圖8所示。

圖5 跟網路銀行有關的使用案例[基金系統]

圖6 跟排程服務有關的使用案例[基金系統]

圖7 跟基金公司伺服器有關的使用案例[基金系統]

圖8 跟銀行行員有關的使用案例[基金系統]

特殊的雙介面使用案例
不過，在圖8中的查詢客戶基金交易明細、查詢客戶投資明細、查詢基金淨值，這三個使用案例比較特別。我們希望基金系統在提供這三個使用案例時，可以實作成雙介面，分別為：

● Web UI：由銀行行員所啟動的這三個使用案例，我們希望基金系統可以提供網頁型的圖形介面。

● Web Service：但是，我們也希望網銀客戶可以透過網路銀行啟動這三個使用案例，因此基金系統還必須提供無圖形的Web Services介面。

遇到這種雙介面的使用案例，我們可以在參與者與使用案例之間的溝通線上，特別標示出這兩個介面，如圖9所示。

圖9 特殊的雙介面使用案例[基金系統]

圖10 基金系統的使用案例總圖[基金系統]

不過，如果遇到比較複雜的使用案例圖時，將介面標示在通訊線上，會讓圖面變得複雜、難以閱讀。或者，我們也可以善用顏色，像在圖10的基金系統使用案例總圖中，特別將雙介面的使用案例填上深藍色，藉以強調它們的雙介面特性，也是不錯的方法。調整基金系統的使用案例圖
在編寫使用案例簡述之前，我們可以再度查看一下圖10的總圖，稍作調整。看完圖10之後，我們發現其中六個使用案例，好像有重複的狀況，如圖11所示。

圖10 基金系統的使用案例總圖[基金系統]

圖11 這六個使用案例有重疊的現象[基金系統]

當查詢客戶基金交易明細、查詢客戶投資明細、查詢基金淨值，這三個使用案例變成雙介面之後，似乎就跟原先網路銀行啟動的查詢基金交易、查詢基金投資組合、查詢基金基本資料，這三個使用案例有所重疊。所以，我們決定將這六個使用案例，兩兩合併，調整後形成三個使用案例，並且同時更名如圖12所示。

圖12 兩兩合併成為三個使用案例[基金系統]

總歸，包含上述的合併並更名，還有兩個新增使用案例，一個更名，一共有四個調整之處，條列如下：

1. 合併相同的使用案例並更名：

● 查詢基金交易明細：合併原先的「查詢客戶基金交易明細」和「查詢基金交易」，最後更名為「查詢基金交易明細」。

● 查詢基金投資明細：合併原先的「查詢客戶投資明細」和「查詢基金投資組合」，最後更名為「查詢基金投資明細」。

● 查詢基金基本資料：合併原先的「查詢基金淨值」和「查詢基金基本資料」，最後採用「查詢基金基本資料」名稱。

2. 自動產生投資績效表：此外，我們還發現遺漏了一個使用案例：自動產生投資績效表；由排程服務在每個月初1號時，自動產生給客戶的投資績效表。

3. 匯入贖回款：再者，如果客戶要求贖回基金的話，基金公司伺服器在回覆基金交易結果時，還會額外執行匯入贖回款的動作。所以，我們也需要增添一個使用案例：匯入贖回款，由於不是每次都會執行匯入贖回款使用案例，所以它與回覆基金交易結果使用案例之間，使用擴充關係。

4. 申購定期定額基金：原先的「定期定額申購基金」，更名為「申購定期定額基金」，讓它的命名可以與「申購單筆基金」一致。

做了上述的調整之後，最後初步定案的基金系統使用案例，如圖13所示。

圖13 基金系統的使用案例總圖[基金系統]

基金系統的使用案例簡述
最後，我們將針對圖13中的18個使用案例，用一兩句話簡述它們的主要目的，這是為了方便後續編列「產品待辦清單」（Product Backlog）時，可以有個參考的依據，如下表所示。