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

Scrum敏捷開發是一種「增值流程」（value-up process），講具體些，就是每一次的「衝刺」（Sprint）都會具體實現「顧客價值」。再把話說的更加具體些，就是每一次的衝刺都會產出可以執行的程式碼，而且這些可執行碼能夠提供給顧客滿意的軟體服務。

但是，萬丈高樓平地起，住戶看不到的地基不重要嗎？顧客摸不著的基礎架構不重要嗎？因此，在開始傾全力往前衝刺之時，我們得先執行「衝刺0」，衝刺0的主要目標，就是在打好地基，做好基礎建設及規畫。

衝刺0主要執行的任務（task）和產出的工件（artifact）如下：

● 建構軟體架構模式：分析並繪製現行的軟體架構圖，以及設計出未來的軟體架構圖。

1. 系統關係圖：首先，我們會使用UML的類別圖（Class Diagram）來呈現現行的子系統，以及子系統之間的通訊關係。

2. 系統使用案例圖：接著，我們會使用UML的使用案例圖（Use Case Diagram）來呈現出現行的子系統合力提供了哪些重要的服務。

3. 系統循序圖：最後，我們會針對幾個比較重要的使用案例，為它們繪製循序圖（Sequence Diagram），以便呈現出現行子系統之間的互動概況。

● 編列產品待辦清單：在「產品待辦清單」（Product Backlog）中，我們會列出一項項的「產品待辦項目」（Product Backlog Item）。

1. 子系統使用案例圖：首先，我們會針對子系統繪製出個別的子系統使用案例圖。前述的「系統使用案例圖」描述的是整個系統，此處的「子系統使用案例圖」是針對特定的子系統。

2. 產品待辦清單：接著，我們會把所有子系統使用案例圖中的使用案例都匯集起來，成為產品待辦清單中的重要的產品待辦項目。然後，針對每一個產品待辦項目編寫相關說明。

在接下來的幾篇文章中，我們會以銀行系統的例子來說明，怎麼執行上述的任務，並且產出相關的工件。

在衝刺0的打地基工作任務中，首先我們將為現行的與未來的軟體架構建立模式（model）。

由於，我們的專案需要改造現行架構，要是對現行架構一無所知，那將要如何改造呢？所以，我們必須先行分析出現有的軟體架構，隨後才能提出未來的改造計畫。

現行的系統關係圖

首先，我們先分析出整個銀行中，涉及基金業務的現存子系統有哪些，並且繪製出它們之間的關係。在UML圖款上，我們挑選類別圖來呈現我們的系統關係圖。在UML類別圖中，我們將原先的「類別」（Class）對應成專案中的「子系統」（Subsystem），至於類別之間的「結合關係」（Association）則用來表達子系統之間的通訊協定，如圖1所示。

銀行主機
在我們的案例中，銀行主機使用IBM System Z系列產品，透過IBM EAI（Enterprise Application Integration）與其他系統交換資料。其他系統不能直接跟銀行主機互動，而是必須透過IBM EAI才能跟銀行主機交換資訊。

EAI主要用來整合企業內部各式的應用系統，方便企業可以整合新舊投資，發揮綜效。多年來，企業投資了許多資金在建構資訊系統上頭，因此企業內部多半存活著發展在各式異質平台上頭的應用系統。這些異質平臺上頭的應用系統面臨到無法需要合作，但是現況又是各說各話、沒有統一的通訊協定，因此出現了EAI這樣的產品，做為異質應用系統之間的共通溝通平台。

各大廠肯定不會放過EAI這樣的市場，向來在金融界呼風喚雨的IBM當然也提出了相關的EAI解決方案WBI來因應市場需求。

在我們的案例中，重要的帳務業務及其他被視為核心的業務，大部分都還是由銀行主機負責，其他開放系統的資料庫都不會儲存跟帳務有關的資料。比方說，網銀客戶每次下單申購基金時，網路銀行都會連線到銀行主機，請銀行主機計算出手續費，以及進行扣帳的動作。雖然，此時網銀客戶到底實際可以申購到多少基金單位數，其實是還不確定的，必須等基金公司的回覆才能真正確定。

此外，為了提高資訊系統支援業務的效能，開放系統逐步負責更多的業務，而且開放系統的運算結果，也會儲存在開放系統自己的資料庫中。不過，開放系統通常會複製一份運算結果，上傳集中儲存到銀行主機中。其實，開放系統上傳資料到銀行主機，是很花資源而且花時間的，如果遇到開放系統與銀行主機兩邊的資料不一致時，也以銀行主機為準。

再者，當銀行主機與開放系統儲存相同的資料時，開放系統會在夜間或非營業日的離峰時段，定期從銀行主機下傳全部的資料更新開放系統的資料，以此確保開放系統資料的正確性。從這些現象，可以看得出來大型主機的重要性，所以在目前，大型主機都還是金融界的核心命脈。


接著，請你看到圖2，我們要特別解釋一下圖中的雙角鍵號（<<>>）的使用。

前面我們曾說過，此處我們採用UML的類別圖來表達專案中可能會涉及的子系統，以及子系統之間的的通訊關係。類別會對應成子系統，同時我們採用雙角鍵號的模版（Stereotype），來區分不同種類的系統，條列如下：

● <>：此處是指一般的開放系統，常見用Java或.NET所開發的系統。在我們的專案中，將採用.NET技術來開發基金系統。

● <>：指的是IBM的產品，像此處的EAI就是指IBM的產品。

● <>：大型主機，在我們的專案中，是IBM SystemZ系列的系統。

此處，我們再多解釋一下UML的模版概念。簡單來說，模版是UML的擴充機制，方便用來擴充語意。使用或解讀模版時，特別注意下列三個特色：

1. 雙角鍵號（<<>>）：模版名稱會放置在雙角鍵號（<<>>）中，像是<>（大型主機）的字眼就會放在雙角鍵號中。所以，在UML中，只要看到雙角鍵號，就知道是模版。

2. 基礎元素：模版不會獨自存在，它一定用來擴充某一個基礎元素。比方說，前面的圖2中，<>、<>和<>都是搭配類別圖示出現，所以其類別就是這個範例的基礎元素。

3. 擴充語意：模版就是用來擴充基礎元素的語意，所以我們可以從模版的字眼得知擴充的語意為何。在我們的系統關係圖中，我們拿類別對應系統，然後再使用模版來擴充類別的語意，這樣我們就可以表達不同種類的系統了。


最後，請你再看到圖3，針對系統外部的參與者，我們也用套用模版來特別標示出系統型的參與者。在圖3中，我們用參與者來表示一般的人類使用者，如果是其他的連線系統，我們則使用<>模版特別標示出系統型的參與者。

我們的案例中，也是採用了IBM的WBI解決方案，所以在現行的舊架構圖中，或者是目前規畫的新架構圖中，都有一個IBM EAI的系統在架構圖中。EAI讓我們可以將大型主機和開放系統整合起來。現行架構的問題
在現行的舊架構中，最主要的特點便是，所有需要執行到基金相關的計算公式，都需要交由大型主機來運算。至於，網路銀行和基金系統等等的開放系統，都只是用來取代傳統終端機，讓使用者有更便利、好用的操作介面。

也正因如此，所以當網銀客戶連上網路銀行，進行基金交易時，網路銀行必須不斷地傳送交易電文到銀行主機。而且，經由銀行主機運算之後，銀行主機會將運算結果回傳給網路銀行，交由網路銀行顯示運算結果給網銀客戶。至於，銀行行員使用基金系統時，也是同樣的狀況，主要運算都是要依賴銀行主機。

總之，前述的現行舊架構主要有以下幾個窘境：

1. 過於依賴銀行主機：因為所有的計算都在銀行主機上頭，造成銀行對銀行主機的高度依賴。然而，隨著銀行業務的多元化，導致銀行主機必須不斷持續擴充，才能夠支援銀行推展新的業務。但是，基於大型主機技術封閉的獨特性，所以容易造成大型主機廠商的老大心態，讓銀行雖然貴為客戶，卻也無法大聲說話，只能任由大型主機廠商隨意擺佈，實為氣結。

2. 沒有善用開放系統的效能：對使用者來說，銀行主機的使用者介面其實非常不友善。因此，即便是銀行行員，也經常是透過開放系統連線銀行主機，執行相關業務，像是基金系統就被委化成為銀行行員與銀行主機間的溝通介面。但是，現在開放系統的伺服器其實效能都很強大，要是能夠將部分的運算轉移到開放系統上頭，或許更能符合經濟效益。

3. 無謂的共同開發耗費人力：由於，銀行經常推展新業務，也就需要增加新的系統功能來支援新業務。現階段，每次銀行主機增加新的功能時，經常需要銀行主機的開發人員與開放系統的開發人員共同合作，才能夠完成新需求，實在非常耗費人力。

4. 大量制式化的人工作業易造成錯誤：由於，銀行行員需要在開放系統與銀行主機之間進行人工轉移資料，除了耗費人力外，更是容易造成人為錯誤，這樣的現象實在令人感到頭痛。其實，經由開放系統定時執行批次作業，可以節省大量的人工作業，當然也就因此能夠避免掉許多人工作業上的疏失。

新架構

總之，為了解決上述的種種問題，我們決定將銀行主機上的業務逐步轉移到開放系統上頭，因此提出了軟體架構改造計畫。請你先看到圖4，這是我們預想進行改造的新架構。

你還可以看到圖5的示意圖，我們特別將新舊架構重疊在一起，方便你從圖形上立即看到新舊兩者的差別。在圖5中，舊架構放在下方，新架構重疊在上方。



最後，請你看到下列的新舊架構對照，條列如下：

1. 分散運算到開放系統中：在舊架構中，運算集中在銀行主機中；在新架構中，我們會將運算分散到各開放系統中，像是基金相關的運算就會轉移到基金系統上頭。

2. 開放系統可以直接溝通：在舊架構中，開放系統並沒有直接連線；在新架構中，採用Web Services做為開放系統之間的通訊協定。不過，為了確保交易的安全性，基金系統與基金公司伺服器之間的網路需採用「虛擬私有網路」（Virtual Private Network，VPN）。

3. 定時執行批次作業：在舊架構中，基金系統與基金公司伺服器之間的資料交換採用人工作業；在新架構中，不再需要人工作業了，我們可以在開放系統中設定好排程服務，定時執行採用批次作業。

4. 減少銀行行員的日常工作：在舊架構中，銀行行員需要執行大量制式且單調的人工作業；在新架構中，這些無趣的人工作業都轉為自動化，銀行行員只在需要時，才登入基金系統查詢相關的基金資料。

未來的系統關係圖

除了看到新的架構外，我們還規畫了軟體架構改造之後，日後可以延伸的未來架構。請你看到圖6，未來架構的重點之一在於，將其他重要的業務逐步轉移到開放系統平臺上。

在圖6中，我們可以看到未來可能的發展，像是將財富管理、消金核貸這兩項重要的業務也逐步轉移到開放平臺。所以，理財專員在服務高淨值的理財貴賓時，可以登入財富管理系統，協助高淨值客戶調整投資組合。


最後，我們來看如何用類別圖來表達系統提供的主要服務。請你看到圖7，當我們使用類別圖來表達系統之間的關係時，可以善用結合關係的兩個端點來標示出系統的主要服務。

作者介紹

邱郁惠
研究UML/OOAD十餘年，創辦UML Blog(www.umltw.com)推廣UML，出版多本UML/OOAD專業書籍，擁有OCUP/UML三級認證、PMP、ITIL、OOAD認證。目前為自由工作者，專職於企業內訓、專案輔導、自辦課程、專欄寫作。

施奇宏
投身軟體開發領域逾15年，任職於金融產業，有豐富金融IT實戰開發經驗。對於Java、.NET、C++等都有涉獵。最近著迷於軟體工程，尤其是測試驅動開發（TDD）及領域驅動設計（DDD）。