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

除了業務規則外，在使用案例敘述中，也經常會出現一些重要的動作。例如，在申購單筆基金的主要流程中，就有一個「產生信託帳號」的動作，因為信託帳號這個資料項目歸納在投資組合類別中，那我們就順理成章地把「產生信託帳號」這個操作，也同樣歸於此處了，如圖1所示。目前已經累積那些領域知識了，如圖2所示。

現場使用的圖示

類別
重要且需要保存在系統中的領域概念，可以對應到一個類別。類別採用矩形圖示，常見有三格，第一格放置類別名稱、第二格放置屬性、第三格放置操作，如圖3所示。大部分的UML軟體工具都有隱藏屬性格或操作格的功能，所以也經常可以看到矩形圖示內部只有一格、或兩格的情況，如圖4所示。
 

屬性

當然，不可能把每一個領域概念都當類別來看待，有些單純的資料項目，其實可以直接歸屬到相關的領域概念底下，記錄在類別的屬性格中。屬性的標準格式為：

屬性名稱：資料型別＝初始值
 

操作
至於，操作則意味著行為、動作，所以可以將領域概念涉及到需要計算、查驗等等的業務規則，或者是需要執行的重要動作，全都放置在類別的第三格操作格中。操作的標準格式為：

操作名稱（參數：資料型別）：回覆值的資料型別

結合關係

結合關係代表兩個領域概念之間存在著，重要且須要永久保存的靜態關係。結合關係的圖示是實線，實線兩端連接兩個類別，如圖5所示。

單向結合
一般看到無箭頭的結合關係代表雙向結合，如果想要特別表達單向的結合關係時，就要在實線的其中一端加上箭頭，這樣就成了單向結合。

以圖6為例，意味著我們可以從基金公司（來源端），連結（link）到它有在本銀行代售的基金（目標端）。但是，由於是單向結合，所以我們無法從基金反向找到它所屬的基金公司。

個體數目
此外，另一個更常見且十分重要的概念是「個體數目」（multiplicity），它被用來表示某一個概念的實例（instance）連結到另一個概念的實例時，最多可以連結多少個實例，以及最少一定要連結多少個實例。

個體數目的標準格式是「下限..上限」。個體數目最小為零（0），最大為無限大（*）；也就是說，個體數目的數字只能是非負整數（整數和零），或者是代表無限大的星號（*）。個體數目標示在結合關係的端點，用來限制一個來源端的實例，可以連結到多少個目標端的實例。以圖7為例，代表一家基金公司可以在本銀行販售多檔基金，最少一檔，而且無上限。一般看到的無箭頭實線，其實是代表雙向的結合關係，所以兩個端點都會標示個體數目，如圖8所示。

聚合關係
聚合關係（Aggregation）是一種特殊的結合關係，它意味著除了結合關係本身的意涵和特性外，還會額外加上「整體-部分」（whole-part）的特性。聚合關係所採用的圖示，當然也跟結合關係一樣，都是實線，不過它會在代表整體的端點上標示一個小的空心菱形，如圖9所示。當然，結合關係原有的單向結合和個體數目的概念，在聚合關係上頭，也都是共用的，如圖10所示。

組合關係
聚合關係是一種約束力比較弱的整體-部分關係，另一種約束力更強的整體-部分關係，稱之為「組合關係」（Composition）。由於，組合關係是一種特殊的聚合關係，因此聚合關係具有的特性，它全數都會擁有。除此之外，組合關係還擁有額外的特性如下：

● 部分物件（part object）只會連結到一個整體物件（whole object），不允許數個整體物件共享同一個部分物件的情況出現。

● 部分物件的誕生和消滅，掌握在整體物件手中。換言之，整體物件可以決定部分物件的生滅，一旦整體物件被刪除掉了，部分物件會一併刪除。

請你看到圖11的範例，組合關係的菱形是實心的，有別於聚合關係的空心菱形。舉例來說，如果需要紀錄基金每日的淨值時，我們可能會把原本基金類別中的目前淨值屬性拉出來，放在另一個淨值的新類別中，然後透過組合關係來連接基金與淨值之間的關係。