作為OOAD中的第二步，概念模型的識別顯得比用例識別更加困難。

為什么要創建領域模型

降低與OO建模之間的表示差異。

領域層軟件類的名稱要源于領域模型中的名稱，以使對象具有源于領域的信息和職責。

打個比方，你可以用一長串0和1來表示“薪水冊”，可是這種軟件表示與我們腦中的薪水冊領域模型之間存在巨大的差異，這將影響我們對軟件的理解和修改。而OO建模則可以減小這一差異。

如何創建領域模型

那又如何創建領域模型呢？

可以通過以下三個步驟：

尋找概念類將其繪制為UML類圖中的類添加關聯添加屬性

如何找到概念類

1）重用和修改現有的模型。

這是首要、最佳且最簡單的辦法。可以從已發布的領域模型和書籍中獲得。

2）使用分類列表

示例：

（圖二）

3）確定名詞列表

在對領域的文本性描述中識別名詞和名詞短語，將其作為候選的概念類或屬性。

缺點：自然語言的不精確性，不同名詞短語可能表示同一概念類或屬性，此外可能還有歧義。

建議與概念類分類列表一同使用。

在實踐中，在發現概念類時，一般直接為其繪制UML類圖。

了解了幾種識別概念類的方法，我們接下來討論過程中可能出現的問題。

1）最常見錯誤：把應該是概念類的事物表示為屬性。

準則：如果我們認為某概念類X不是現實世界中的數字或文本，那么X可能是概念類而不是屬性。

考慮一下航空預定領域。destination應該作為Flight的屬性，還是作為單獨的概念類Airport?

（圖三）

在現實世界里，目的地機場不會被看作是數字或文本，而是一占據大規模空間的事物。因此，Airport應該是個概念，而不是屬性。

2）缺少描述類

描述類包含描述其他事物的信息。例如，ProductDescription記錄Item的價格、圖片和文字描述。

為什么使用描述類？

假設：雀巢咖啡，大受歡迎，銷售一空。這就意味著雀巢咖啡的所有Item實例都從計算機存儲器中被刪除。這時如果有人問：雀巢咖啡多少錢一盒？那將沒法回答。因為價格是記錄在實例上的，而這些實例都已經被刪除。由此可以看出，需要其他事物來記錄雀巢咖啡的描述（規格說明）。

（圖四）

又比如，虹橋機場每天有很多航班，同一架飛機有多個航線，但其一架飛機只有一個飛機號碼。如果僅僅有兩個概念類Flight和Airport，假設有一天天降大霧，所有航班取消，我們刪除了所有Flight記錄。這時如果我們想知道是否存在號碼為12345的一架飛機，那我們將無法查到。由此可以看出，我們還需要一個描述類FlightDescription。

何時需要？

1. 需要有關商品或服務的描述，獨立于任何商品或服務的現有實例。

2. 刪除其所描述事物（如Item）的實例后，導致信息丟失，而這些信息是需要維護的，但是被錯誤地與所刪除的事物關聯起來。

3. 減少冗余或重復信息。

關聯

什么是關聯？

關聯是類（類的實例）之間的關系，表示有意義和值得關注的連接。

（圖五）

關聯名

關聯名來描述一個關聯的本質。

角色（Role）

用來描述離角色名較近一端的類在另一端的類面前所呈現的面貌。

何時表示關聯？

1. 如果存在需要保持一段時間的關系，將這種語義表示為關聯（“需要記住”的關聯）。

2. 從常見關聯列表中派生的關聯。

準則：要避免在領域模型中加入太多的關聯。

在領域建模過程中，關聯不是關于數據流、數據庫外鍵聯系、實例變量或軟件方案中的對象連接的語句；關聯聲明的是針對現實領域從純概念角度看有意義的關系。

在UML中如何對關聯命名

以“類名－動詞短語－類名”的格式為關聯命名，其中的動詞短語構成了可讀的和有意義的順序。

圖五對應于：VideoStore Stocks Video

多重性

多重性定義了類A有多少個實例可以和類B的一個實例關聯。（見圖五）

多重性的值表示在特定時刻（而不是在某個時間跨度內）有效關聯的實例數量。

（圖六）

多重性是和語境有關的。

兩個類之間的多重關聯：

（圖七）

常見關聯列表

（圖八）

一個例子

屬性

在UML中，一個屬性的完整語法是：visibility name : type multiplicity = default {property-string}，即可見的名稱 ： 類型 = 默認值 {性質}。

什么是屬性？

屬性是對象的邏輯數據值。

何時展示屬性？

當需求（例如，用例）建議或暗示需要記住信息時，引入屬性。

（圖九）

導出屬性（derived attribute）：可以由其他信息導出的屬性。

準則：大部分屬性類型應該是“簡單”數據類型，例如數字和布爾。通常，屬性的類型不應該是復雜的領域概念，例如Sale或AirPort。

準則：領域模型中屬性的類型更應該是數據類型。

準則：通過關聯而不是屬性來表示概念類之間的關系。

（圖十）

領域模型是概念透視圖，不是軟件透視圖。在設計模型中，屬性可以是任何類型。

準則：任何屬性都不表示外鍵。

（圖十一）

結論

沒有所謂唯一正確的領域模型。所有模型都是對我們試圖要理解的領域的近似。領域模型主要是在特定群體中用于理解和溝通的工具。有效的領域模型捕獲了當前需求語境下的本質抽象和理解領域所需要的信息，并且可以幫助人們理解領域的概念、術語和關系。

參考資料：

1. 《UML和模式應用》（第三版）

總結

以上是生活随笔為你收集整理的如何定义领域模型（概念模型）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。