【UML實戰智慧第8回】如何繪製領域模型實例 (上)

還記得在使用案例建模的作業程序中，最後一個步驟是要產出初版的領域模型，此處，我們以一個常見的維護型使用案例「維護基金公司基本資料」為例來示範，首先先更新功能架構圖與使用案例圖，分別如圖1、圖2和圖3所示。
其實，這裡有一個潛藏的常識（common sense）性業務規則是，基金公司是唯一的，所以資料當然不能重覆。也就是說，在系統的資料庫中，一家基金公司應該只會有一筆基金公司基本資料，不允許重覆。在這種情況下，常見兩種做法：其一是設置前置條件；另一種做法是不設置前置條件，而是把資料是否重覆的檢查步驟放置在主要流程中。

先來看第一種做法，設置前置條件，先確認公司編號是否存在。但是，這一種做法涉及到另外兩個條件必須成立的情況下，系統才能夠檢驗這項前置條件，這兩個條件包括了：1.基金公司編號必須唯一。2.銀行行員可以在他處事先取得基金公司編號。前置條件如圖4所示。

另一種不設置前置條件，而是把資料是否重覆的檢查步驟放置在主要流程中，如圖5所示。

對系統效能而言，「先檢查基金公司編號，確認不存在資料庫中，才讓銀行行員輸入其他資料」，效能比較差，因為可能會需要連到資料庫兩次。所以，我們也可以改用另一種流程，效能可能會比較好，如圖6。

此處，無論採用哪一種設計方式，其實都不影響領域模型，還記得原先的領域模型如圖7所示，現在我們更新領域模型如圖8所示。對了，維護型的使用案例通常包含新增、刪除、修改、查詢，此處我們僅示範了新增，其餘就先略過了。

領域建模的作業程序
有了初版的領域模型之後，系統分析師就可以按照圖9的作業程序，一邊套用樣式調整結構，一邊增修業務規則和加入重要操作。

套用樣式調整結構
其實，分析階段的樣式（Pattern）挺多，我在實務上和教學上，最常使用的是Peter Coad大師所提出來的「交易樣式」（Transaction Patterns），原始出處為《Object Models： Strategies, Patterns, & Allipcation》一書。

不過，我自己在使用上，做了一些簡化，如圖10所示。簡單來說，交易樣式的核心概念是「交易」（Transaction），交易泛指需要記錄起來的重要事件，並不侷限在商業交易上頭。以交易為核心，建立起交易涉及的人、事、地、物，以及日後可能發生的後續交易。我在《寫給SA的UML/UseCase實務手冊》和《學會UML/OOAD這樣開始就對了》這兩本書中，都有詳細解釋並示範如何使用交易樣式，你要是有興趣的話，歡迎你去把這兩本書找來翻一翻。
接著，我們先來新增一個名為「申購單筆基金」的使用案例，更新功能架構圖和使用案例圖，如圖11和圖12所示，以及撰寫申購單筆基金的主要流程如圖13：

在申購單筆基金的主要流程中，提到了很多資料項目，我們可以先套用交易樣式，把這些資料項目歸類一下，如圖14所示。

在初步套用交易樣式時，系統分析師可能發現有些概念對不上，這恰好是一個可以請教領域專家的好機會。拿著這個雛型跟領域專家討論之後，做了一些修訂，如下：

原先的基金交易一詞，改成「投資組合」這個領域術語，如圖15所示。再把基金交易（投資組合）中的部分屬性，搬移到交易明細中，如圖16所示。並在基金交易（投資組合）與基金之間，增加一條結合關係，如圖17所示。彙整剛才加入領域專家的意見後幾個修訂，最後得出圖18的領域模型。

增修業務規則

顧名思義，業務規則（Business Rule）意味著企業組織必須遵守的規則，它可能用來限制企業人員、業務流程、企業行為等地方。當然，要是建置新系統時，忽略了這些重要的業務規則，那可就麻煩了呢！

在網路上查詢一下，就可以發現許多關於業務規則的概念和分類，但是我們不以這個角度來討論業務流程。此處，我們只討論業務規則的呈現，無論業務規則是什麼樣的分類，或者來自於何處，只要需要建置到系統中，就得盡可能地彙整到領域模型中，才不致於遺漏重要的業務規則。

在領域模型中，有兩處可以呈現業務規則：其一是可以透過結合關係和個體數目，來表達攸關靜態結構的業務規則；其二則是可以透過操作來表達計算公式，以及一些需要查驗或檢核的業務規則。比方說，每一個投資組合只會涉及到一檔基金，這就是一項攸關靜態結構的業務規則，可以呈現在投資組合和基金之間的結合關係及個體數目上頭，如圖19所示。另外，從申購單筆基金的主要流程中，如圖20，也可以找到許多需要執行計算或查驗的動作，請一一記錄到操作中。

首先，我們先來看看有哪些計算公式或查驗規則，如下：

1. 系統查驗投資金額須通過最低投資金額的限制：投資金額≧最低投資金額。

2. 系統查驗投資金額須通過投資金額千元倍數的限制：投資金額∕1000=整數。

3. 系統計算手續費：手續費=投資金額*手續費費率。

4. 系統計算扣款金額：扣款金額=投資金額+手續費。

依據上述的計算公式，我們先找出這幾個計算公式涉及到的資料項目，以及它們所屬的類別，如圖20所示。

由於，查驗投資金額是否為千元倍數以及計算扣款金額，這兩個業務規則所需要的資料項目，都在交易明細這個類別中，所以就理所當然地把這兩項業務規則歸類於此，如圖21所示。

至於，查驗投資金額是否有通過最低投資金額的限制，以及計算手續費，就比較不那麼直觀，需要再進一步討論。最低投資金額和手續費費率可能會依據每一檔基金而有所不同，而且應該在交易還未成立之前，就可以執行這項查驗或計算，所以或許把這兩項業務規則歸類到基金類別中，也還算可以接受啦，如圖22所示。

除此之外，針對使用案例中的每一個數目、數量、數字種類的資料項目，都得仔細察看一番，避免遺漏了重要的業務規則。從圖23的申購單筆基金主要流程中，我們可以找到：手續費、扣款金額和基金單位數，前兩者我們已經處理了，剩下一個基金單位數。

基金單位數就是投資金額可以申購到的基金單位數，它的計算公式是：基金單位數=投資金額∕基金的目前淨值。最後，我們再把這項業務規則加到基金類別中，並且更新領域模型，如圖24所示。

最後，我們在同步修訂一下申購單筆基金的主要流程，讓它可以更為直觀地對應到領域模型的用詞，如圖25。