【UML實戰智慧第7回】如何用UML類別圖產出領域模型

老實說，我在UML專案現場，從來沒見過那個專案的系統分析師有認真推敲並且正式產出「領域模型」（Domain Model）的！系統分析師或建置團隊不重視、省略甚至放棄建構領域模型，除了專案時程壓迫的通病外，我推敲可能的原因如下：

1. 系統分析師缺乏領域知識，也不想花精力去跟領域專家學習領域知識，當然也就建構不出什麼有用的領域模型了。

2. 系統分析師不重視領域模型，所以鮮少練習領域建模的技術，也不知道怎樣跟領域專案溝通，在這種負向循環下，也就更難建構出領域模型了。

3. 即便系統分析師大費周章地產出領域模型，但是系統設計師並未重視領域模型，也不以領域模型作為系統內部的核心結構。

總之，現在最主要的困境是：前頭在分析階段所花費的領域建模成本，無法在後續的設計、實作及維護階段產生高價值的效益。因此，導致專案經理、系統分析師都不願意投注時間在領域建模上頭，更別說系統設計師和程式設計師對領域模型的視而不見了。

所以，十分期盼從你接觸這系列文章開始，讓我們一起來打破不重視領域模型的負向循環，而且，更可以像定期定額申購基金般地，也定期定額地投入一些時間和精力在關注領域模型上頭。

領域模型

在維基百科中，對領域模型的英文定義是：
A domain model in problem solving and software engineering can be thought of as a conceptual model（概念模型） of a domain of interest （often referred to as a problem domain） which describes the various entities（實體）, their attributes（屬性）, roles（角色） and relationships（關係）, plus the constraints（限制） that govern the integrity of the model elements comprising that problem domain（問題領域）。

而中文定義則是：
領域模型可以被看作是一個系統的概念模型，用於以可視化的形式描述系統中的各個實體及其之間的關係。

領域模型記錄了一個系統中的關鍵概念和詞彙表，顯示出了系統中的主要實體之間的關係，並確定了它們的重要的方法和屬性。

因此，對應於用例所描述的動態視圖，領域模型提供了一種對整個系統的結構化的視圖。領域模型的一個好處是描述並限制了系統邊界。領域模型的語義可以被用在原始碼中，因此領域模型可以被應用在底層的軟體開發階段中。實體可以演化為類，方法和屬性可以直接演化至代碼之中。在UML中，類圖被用來描述領域模型。

上述中文定義，因是以簡體中文的用詞來描述，和正體中文的用語略有不同。英文的Use Case，正體中文多半翻譯成「使用案例」，簡體中文則多數翻譯成「用例」。至於，英文的Class，正體中文多半翻譯成「類別」，簡體中文則多數翻譯成「類」。UML中的Class Diagram，正體中文會翻譯成「類別圖」，簡體中文則翻譯成「類圖」。

維基百科對領域模型的定義，中英文定義都有。唯獨此處的中文的定義，並非是英文定義的中譯，而且中文定義中有凸顯其他的重點，所以此處我們就一併列出來供你參考了。彙總中英文定義可以得到下列幾項重點：
1. 領域模型是一種概念模型，用來呈現問題領域中的重要概念。

2. 領域模型描述了問題領域中的實體（entity），以及實體的屬性（attribute）、操作（operation）、角色（role）、關係（relationship）和限制（constraint）。

3. 對於使用案例所描述的互動過程，領域模型可以做為支撐在使用案例背後的重要結構。

4. 在UML圖款中，通常使用類別圖（Class Diagram）來描述領域模型。

5. 領域模型除了可以用來溝通領域知識外，也可以被用在後續的設計階段，甚至進一步實作出對應的程式碼。

最後，我們先來簡單看一下，類別圖如何反映上述的重點：
● 實體、屬性、操作：類別代表領域實體。類別的矩形圖示內部，第一格是類別（實體）名稱、第二格放置屬性、第三格放置操作。

● 關係：類別之間的靜態關係有多種，最常見的是實線圖示的「結合關係」（Association）。

● 角色：結合關係的兩個端點可以標示「角色」（Role）名稱，說明實體是以什麼樣的角色參與這項關係的。

● 限制：限制可以用很多方式呈現，最常見的是「個體數目」（Multiplicity），標示在結合關係的兩個端點，用來限制兩種實體之間的數量關係。

產出初版的使用案例

還記得在使用案例建模的作業程序中，最後一個步驟是要產出初版的領域模型，如圖1所示。

圖1 使用案例建模的作業程序

在下一回文章中，我將以查詢基金基本資料這個使用案例為例，分步驟來示範如何從使用案例導出初版的領域模型。這個步驟大概如下：

Step 1. 先查看使用案例敘述，把出現在其中的資料項目，依照領域概念做初步的分類。

Step 2. 新增一個「類別」（Class）代表領域概念，並將該分類下的資料項目放置在類別圖示的第二格（屬性）中

Step 3. 接著是查看概念之間的關係，以及概念參與關係所扮演的角色。既然，基金公司和基金這兩個概念會出現在同一個使用案例中，也就意味著，這兩個概念之間或許有一些關聯，所以要把這個關係找出來，

Step 4. 最後再結合關係兩端加上個體數目。

經過這樣的分析之後，系統分析師可以不斷從使用案例敘述萃取出相關的領域概念，產出初版的領域模型，正如圖2所示。

圖2 領域模型範例