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

在衝刺0階段中，我們用UML來繪製出系統的軟體架構模式，在前面文章中，介紹了如何用類別圖（class diagram）來呈現子系統和子系統間的通訊關係，另外也介紹如何透過使用案例圖（use case diagram）來呈現出子系統所合力提供的重要服務。在這回文章中則是要介紹，如何透過循序圖（sequence diagram），來呈現出子系統之間的互動概況。

為什麼使用類別圖表達系統關係？
不過，在正式進入系統循序圖之前，我們先來解釋一下，為何要挑選類別圖來表達系統關係，而不是挑選別款UML圖？其實，在UML規格書中，並沒有特別說明UML2的十四款圖中，哪一款圖適合用來表達系統關係，或者哪一款圖不適合用來表達系統關係。

也就是說，實務上，當然可以視專案的需求，自行挑選覺得適用的UML圖，來呈現想要表達的分析設計。至於，我們挑選類別圖來呈現系統關係，其主要原因有兩個，包括了重用既有且常見的技術，以及有助於後續的分析設計。

重用既有且常見的技術
挑選類別圖來呈現系統關係，對於許多讀者來說，不僅不再需要額外花成本學習新技能，只要懂得將類別圖拿來應用在軟體架構設計的主題中，即可保有且重用原先對於類別圖的學習投資，進一步創造出不同應用價值。

再者，UML類別圖是官方初級認證的考題範圍，也就是說，以UML官方的角度背書，類別圖是初級且常見的UML圖款。此外，如果從物件導向技術來看，類別的概念也是基礎的概念之一。

換言之，由於許多開發人員都已經學過且熟知類別圖了，正好可以利用這個機會多多善用過去學習的技能，別讓辛苦習得的技能生鏽了。

有助於後續的分析設計
當然，挑選類別圖做為系統關係圖，除了可以善用過去的學習資產外，我們還想要讓類別圖可以有助於後續的其他分析設計產出。由於，我們在使用類別圖表達系統關係之後，還想要透過循序圖來表達子系統之間的互動狀況。而多數的UML工具，對於類別圖與循序圖之間的關係支援完善，所以挑選類別圖之後，其實是有助於產出後續的循序圖。

最後，回到基金系統來看，一開始採用類別圖來表達系統關係圖，接著繪製整體系統的系統使用案例圖，如圖1、圖2所示。

接著，我們要採用循序圖來表達子系統之間的互動，然後再以此推出子系統使用案例圖，如圖3、圖4所示。

現行的系統循序圖
好了，接下來，針對現行架構的使用案例圖，如圖5所示，來繪製循序圖，以便呈現出子系統之間互動，有助於改造軟體架構，以及找出基金系統的子系統使用案例。


登入網銀
由於，網路銀行保有網銀客戶相關資料，所以可以發現在圖6子系統互動中，網銀客戶直接連線登入網路銀行即可，不需要其他子系統的協助。

對了，藉由圖6這張循序圖，簡單說明一下循序圖中的主要元素。循序圖主要用來呈現一群物件之間的互動，當我們把一般的物件換成子系統物件時，就可以用來呈現一群子系統之間的互動了。

在循序圖中，垂直排列出參與者物件與子系統物件；物件之間透過發送訊息來互相溝通、互動，所以訊息線會橫跨在垂直的虛線上頭，並且由發送端指向接收端。所以，在圖6中主要表達出，網銀客戶會跟網路銀行要求登入網銀。

接著，請你看到的圖7示意圖，可以從系統循序圖對應推出子系統使用案例圖。



申購單筆基金
網銀客戶透過網路銀行，挑選想要申購的基金，以及申購金額；網路銀行會將申購基金的相關資料，透過EAI傳給銀行主機。接著，銀行主機會先行記錄並扣款。此外，申購基金細分成「單筆申購」與「定期定額申購」兩種，此處先看到單筆申購的狀況，如圖8所示。

請你看到圖8，在銀行主機虛線上頭，有一條轉頭射向自己的訊息線，意味著發送訊息給自己。物件除了接收其他物件發送的訊息外，當然也可以發送訊息給自己。雖然，銀行主機通常依照不同的業務細分成很多個子系統。但是，因為本書的範例焦點不在銀行主機上頭，所以此處僅將它簡化視為一個系統。

如果從圖8推出銀行主機的子系統使用案例圖的話，也可以對應成使用案例之間的關係，如圖9所示。當然，不一定對應成包含關係，也可能對應成擴充關係，要視案例實際的情況而定。



定期定額申購基金
除了申購單筆基金外，網銀客戶也可以設定特定的扣款日，比方說每個月的6日、16日或者26日之類的。在設定日期到的時候，銀行就會依照網銀客戶所約定的申購金額，自動執行申購、扣帳的手續。

不過，再進一步仔細分析實際的運作狀況，會發現要完成定期定額申購基金的業務，其實會在四個不同的時間點發生四個不同的事件，事件發生的順序如下：

1. 約定：一開始網銀客戶透過網路銀行，首次約定要定期定額申購基金。

2. 扣帳：在網銀客戶約定扣款的當日凌晨1點鐘到的時候，排程服務會自動啟動銀行主機的批次作業，執行扣帳的動作。其實，不一定得在凌晨1點鐘啟動批次作業；對銀行來說，僅需要在營業日之間，安排適當的時間執行批次作業，讓客戶可以在下一個營業時間開始之際，看到最新的資料就好了。

3. 彙整：雖然，銀行主機已經執行扣帳了，可是銀行其實還未正式向基金公司下單。後續銀行行員會彙整基金交易，然後才連線到基金公司伺服器，代替銀行向基金公司下單來申購基金。通常，扣款包含了，申購基金的購買金額以及申購的手續費。

4. 更新：銀行行員等待數日之後，主動向基金公司伺服器確認基金交易，才會更新客戶的基金單位數。

所以，回過頭來看現行架構下的系統使用案例圖中，可以發現到，此處根本就遺漏了定時扣帳的自動作業，如圖10所示。

不過，現在先不忙著補上遺漏的使用案例，等先看完圖11定期定額申購基金的循序圖之後，再馬上補上遺漏的使用案例。



自動定期定額申購基金
在實務上，其實經常會發現遺漏使用案例的狀況，而且通常是往下進行更細節的分析時，才會發現遺漏。想要徹底杜絕遺漏的問題，恐怕不容易，但是積極的面對之道還是有的，就是盡快地轉換另一個觀點，這樣就容易看到遺漏之處了。

譬如，在基金系統的範例中，當我們轉換觀點去分析子系統之間的互動時，便可能發現先前繪製使用案例圖時，遺漏了某些使用案例。

在圖12中，我們補上了遺漏的使用案例，同時也別忘了要同步更新系統關係圖，如圖13所示。

接著，繼續來看，排程服務啟動「自動定期定額申購基金」使用案例期間，子系統之間會怎麼樣互動，正如圖14所示。

此外，我們發現自動定期定額申購也用到扣帳申購基金，所以在基金主機的使用案例圖上，也可以讓此處的大使用案例包含前面已經獨立出來的小使用案例，如圖15所示。



贖回基金
贖回基金就是將基金賣掉，拿回現金。網銀客戶可以指定某一支基金，全部贖回，也可以指定只要贖回多少金額的基金。

請你看到，在贖回基金時，銀行主機當然不會立即折算現金給網銀客戶，也是要經過後續銀行行員的彙整交易之後，才會代為向基金公司下單。所以，在中，銀行主機僅會記錄贖回基金的申請。

查詢基金交易
由於，現行架構大量依賴銀行主機，所以我們可以看到，網銀客戶如果想要查詢基金交易、基金基本資料、基金投資組合等等之類的資料，其實都是透過網路銀行，然後向銀行主機查詢這些資料，我們以查詢基金交易為例。

最後，我們看到銀行行員主要涉及的三個使用案例，分別為：彙整基金交易、更新基金基本資料、更新客戶的基金單位數。

在我們規畫的新架構中，這三個使用案例分別被轉移給排程服務和基金公司伺服器來啟動。

所以，此處我們就不繪製這三個使用案例的循序圖了，稍後將直接說明新架構中的子系統會如何互動完成這三個使用案例。新的系統循序圖
由於，新架構下的使用案例有20多個，如圖17所示。所以，我們就不一一繪製它的系統循序圖了，僅從按照參與者分組的四組使用案例中，各挑選一些使用案例來繪製它們的循序圖。



網銀客戶相關的使用案例
請你看到圖18，我們把跟網銀客戶有關的使用案例分為三組，並從每一組中挑選一個使用案例做為示範，繪製新架構下的循序圖。
此處，我們以三個使用案例為代表，但是僅繪製其中兩個使用案例的循序圖，條列說明如下：

● 登入網銀：在新舊架構下，對登入網銀使用案例的支援沒有變動，所以就不重新繪製新架構下的使用案例圖了。

● 申購單筆基金：在新架構下，我們將基金業務盡量轉移到基金系統下，不過跟帳務有關的運算還是暫時得依賴銀行主機。請你比較一下圖19的舊架構，與圖20的新架構，我們把基金系統加到新架構中了。其他的定期定額申購基金、贖回基金、轉換基金、變更定期定額設定，這四個使用案例的循序圖大約比照圖20的新架構設計，此處我們就不再舉例了。



● 查詢基金基本資料：查詢基金基本資料、查詢基金交易、查詢基金投資組合，這三個使用案例都是相同的設計。此處僅以查詢基金基本資料為例。請你比較一下圖21的舊架構，只是簡單的查詢資料都得連到銀行主機；在新架構圖22的中，理所當然將這樣的工作移到基金系統執行。



排程服務相關的使用案例
同樣的，我們仍然將跟排程服務有關的使用案例分為兩組，如圖23所示。而且每組僅挑選一個使用案例為代表，繪製它們的循序圖。

在舊架構下，銀行行員必須在每個營業日的營業時間結束後，登入基金系統彙整基金交易，隨後再登入基金公司伺服器進行實質的基金交易。但是，在我們規畫的新架構中，這些單調的日常作業都可以交由排程服務自動執行，屆時便可以幫銀行行員節省許多工作時間，讓他們可以去從事更有價值的工作。

基金公司伺服器相關的使用案例
在新架構下，我們主要提供了兩個使用案例讓基金公司伺服器使用。不過，我們發現之前取名「更新基金交易結果」的使用案例，它的名稱似乎不夠貼切。所以，此處我們將這個使用案例改名為「回覆基金交易結果」。以基金公司伺服器做為主詞，就可以唸成「基金公司伺服器回覆基金交易結果」，看起來似乎更為貼近實際的狀況。

銀行行員相關的使用案例
在新架構下，除了將銀行主機的基金業務轉移到基金系統外，還額外新增了一些給銀行行員使用的服務。所以，你可以發現圖24的使用案例，其實是原先舊架構中沒有提供的。

跟銀行行員相關的這四個使用案例都很簡單，而且預定都由基金系統來負責，所以我們只有挑選查詢基金淨值做為範例，繪製出它的循序圖，如圖25所示。


未來的系統循序圖
基於新規畫的架構，我們也幫銀行進一步推想出未來可以發展的架構，同時也舉例出三個提供給理財專員使用的使用案例，這三個新增加的系統包括了，財富管理系統、贖回基金系統、查詢客戶投資組合系統，如圖26所示。



最後，我們先來回顧一下未來架構下的系統關係，如圖27所示。然後，我們才針對這三個未來可能提供的使用案例，繪製了各自的子系統互動圖，如圖28、圖29和圖30所示。



此處，請你對照一下圖29和圖30的設計。由於，在未來架構中，外幣定存業務還沒從銀行主機移出來，所以要查詢外幣定存時，還是需要連線到銀行主機，如圖29所示。而且，在風險與成本考量下，將系統功能由大型主機轉移到開放系統，泰半是逐步進行的。

但是，在新架構中已經將基金業務轉移到基金系統上頭；而且，在未來架構中，我們也計畫將遺留在銀行主機中，關於基金交易所涉及的帳務運算部分，轉移到未來架構中的基金系統。所以，在圖30的贖回基金，才能夠不再需要銀行主機在背後的支援。

關於現行架構、新架構以及未來架構的初步規畫，我們已經大致交待完畢。由於，在這個軟體架構改造的案例中，除了進行軟體架構的規畫外，我們還需要連帶開發基金系統。因此，後續文章中，我們就要開始聚焦在「基金系統」這個子系統內部了。