在「衝刺0」階段中，必須要分析並繪製現行的軟體架構圖，並且設計出未來的軟體架構圖。上一回我們已經使用了UML的類別圖（Class Diagram）來呈現現行的子系統，以及子系統之間的通訊關係，並且設計出未來的系統關係圖了，現在要使用UML的使用案例圖（Use Case Diagram）來呈現出現行的子系統合力提供了哪些重要的服務。
不過，在討論系統使用案例圖之前，我們要先來界定一下系統範圍。請你看到圖1，我們把現行架構中所包含的子系統框在一起，把這些子系統合稱為「銀行系統」。也就是說，銀行系統裡頭主要包含了網路銀行、基金系統、IBM EAI和銀行主機。
特別提醒一下，實際上，銀行包含了多項業務，所以銀行內部理所當然包含了許多子系統。但是，這系列文章舉的範例僅鎖定在跟基金相關的業務上頭，所以銀行系統中只包含了跟基金有關的子系統，是一個簡化後的範例。
現行的系統使用案例圖
前面我們了解了整個專案涉及到的子系統，以及子系統之間的關係之後，現在要來看現行架構下的銀行系統大致提供了哪些重要的服務。此處，我們可以使用UML的「使用案例圖」（Use Case Diagram）來呈現整個銀行系統對外提供的服務，如圖2所示。
此處，我們來簡單說明一下UML使用案例圖的用途和重要元素，為了說明使用案例圖，節錄了原先圖2的局部放置在圖3中，方便說明使用案例圖中的元素。
在UML2的十四款圖中，使用案例圖算是最容易上手的圖款之一，主要用來呈現系統對外提供的服務，它所包含的主要元素簡述如下：
● 系統：其實，使用案例圖中的大方框真正的名稱為「主題」（Subject），其為使用案例執行的環境。只不過，系統或子系統是最常見的主題，所以我們有時就直接稱大方框為「系統」了。
● 使用案例：使用案例（Use Case）採用橢圓圖示，代表系統對外提供的功能或服務。因為，在使用案例圖上，使用案例一定會擺在系統方框內部。
● 參與者：參與者（Actor）位於系統外部，它會與系統直接互動，以便啟動使用案例或支援使用案例。最常見的參與者就是一般的人類使用者，還有連線系統也是十分常見且重要的參與者，另外還有硬體設備、外部資料庫，以及近年來的網路服務、雲端服務，還有比較特別的像是用來定時啟動使用案例的排程服務，這些都算是位於系統外部的參與者。
最後，我們將常見的參與者分類整理成下表，供你參考。
新的系統使用案例圖
你還記得前面提到改造後的新架構，主要有下列4項特色：
1. 分散運算到開放系統中。
2. 開放系統間可以直接溝通。
3. 定時執行批次作業。
4. 減少銀行行員的日常工作。
在上述的新架構特色中，其實對於網銀客戶是沒有影響的，主要受到影響的是銀行行員，特別是上述的第3、4條。因此，請你看到圖4現行架構的系統使用案例圖中，上半區域跟網銀客戶相關的使用案例，目前看起來是不會受到影響；但是，下半區域跟銀行行員相關的使用案例，應該會有所變動。
接著，請你再看到圖5，這還是現行架構下的系統使用案例圖。不過，此處為了方便後續的說明，我們先把原先的系統使用案例圖，依照參與者的不同切分成2張系統使用案例圖。其實，在實際的專案中，我們也經常會依照參與者或某些條件，分組擺放使用案例在不同的使用案例圖中，來提升溝通的品質和效能。
在調整系統使用案例圖的版面之後，回過頭來看新架構下的系統使用案例圖，可有什麼變動。目前看起來，跟網銀客戶有關的使用案例應該不會變動。
排程服務相關的新系統使用案例圖
在我們規畫的新架構中，原先屬於銀行行員需要執行的日常工作，我們都轉為透過排程服務，來負責執行自動化的批次作業。因此，在新架構中，會新增一些由排程服務自動啟動的使用案例，如圖6所示。
基金公司伺服器相關的新系統使用案例圖
雖然，在新舊架構中，銀行系統內部的子系統個數沒有變動，但是仔細了解會發現，其實銀行系統外部的參與者已經改變了。請你先看到圖7的舊架構中，基金公司伺服器並沒有直接接觸銀行系統。
具體來說，銀行系統內部的子系統並沒有直接連線到基金公司伺服器，而是經由銀行行員登入基金公司伺服器執行相關業務。在這種情況下，我們並沒有將基金公司伺服器定義成銀行系統的參與者。
但是，在我們規畫的新架構下，基金公司伺服器會直接接觸銀行系統，如圖8所示。
所以，在我們規畫的新架構下，基金公司伺服器會被定義成銀行系統的參與者，如圖9所示。
另外在圖9中，基金公司伺服器主要會啟動兩條流程，條列說明如下：
1. 更新基金交易結果：一旦，基金公司伺服器確定基金交易的結果之後，便會主動回報基金交易結果，並且啟動更新客戶的基金單位數的使用案例。
2. 更新基金基本資料：在現行架構中，由銀行行員手動更新基金基本資料；在新架構中，則改由基金公司伺服器連線更新基金基本資料。
由於，圖9有使用到使用案例之間的「包含關係」（Include），所以我們來簡單認識一下使用案例之間的關係。使用案例之間有兩個主要的關係，其一是標示<
當兩使用案例之間有包含關係時，意味著大使用案例執行期間會包含執行另一個小使用案例。所以請你看到圖10的示意圖，當「更新基金交易結果」大使用案例包含一個「更新客戶的基金單位數」小使用案例時，則意味著銀行系統執行更新基金交易結果的過程中，必定會執行另一個更新客戶基金單位數的小流程。
但是，如果我們想要表達特定條件成立，才需要執行小使用案例的話，那就不能使用包含關係了，而是得改用「擴充關係」（Extend）了。舉個例子，假設我們有提供一個貼心服務，讓網銀客戶可以自行設定是否要接到基金交易完成的通知電郵。可能有些網銀客戶想收到通知電郵，另外一些網銀客戶不想收到通知電郵。
在這種情況下，我們可以使用擴充關係來連接「更新基金交易結果」這個大使用案例，和「發送基金交易完成電郵」這個小使用案例，如圖11所示。
特別注意，包含關係意味著執行大使用案例期間，一定也會連帶執行小使用案例。
但是，擴充關係則不然，在條件未成立的情況下，它只會單純執行大使用案例；條件成立時，才會在執行大使用案例期間，連帶執行擴充的小使用案例。請你看到圖12的示意圖，擴充關係意味著兩條流程。銀行行員相關的新系統使用案例圖
在現行架構中，銀行行員主要會涉及三個使用案例，分別為：彙整基金交易、更新基金基本資料、更新客戶的基金單位數。但是在新架構中，這三個使用案例分別轉移給排程服務和基金公司伺服器來啟動，如圖13所示。
從圖13來看，銀行行員似乎已經沒有涉及到任何使用案例了。其實，銀行行員還是會有需要使用銀行系統的，所以我們另外新增了四個使用案例，如圖14所示。
最後，我們來看看在新的架構下，銀行系統擁有哪些使用案例，如圖15所示。雖然，總圖看起來頗為壯觀，不過實在不清楚，所以還是建議你在實務上採用前面的做法，分成數張使用案例圖較佳。
未來的系統使用案例圖
在未來的架構中，我們打算把更多原先在銀行主機上頭的服務，逐步轉移到開放系統上，像是財富管理系統、消金核貸系統等等，如圖16所示。不過，這是對未來架構的延伸說明，不是這系列文章的重點。所以，就不進一步舉例說明了。
作者介紹
邱郁惠
研究UML/OOAD十餘年，創辦UML Blog(www.umltw.com)推廣UML，出版多本UML/OOAD專業書籍，擁有OCUP/UML三級認證、PMP、ITIL、OOAD認證。目前為自由工作者，專職於企業內訓、專案輔導、自辦課程、專欄寫作。
施奇宏
投身軟體開發領域逾15年，任職於金融產業，有豐富金融IT實戰開發經驗。對於Java、.NET、C++等都有涉獵。最近著迷於軟體工程，尤其是測試驅動開發（TDD）及領域驅動設計（DDD）。
熱門新聞
2025-01-20
2025-01-20
2025-01-20
2025-01-20
