簡介：領域模型是OO分析中最重要和經典的模型。它闡述了領域中的重要概念。本次將介紹有關領域模型的基本技術。 領域模型：是對領域內的概念類或現實世界中對象的可視化表示[MO95,Fowler96]。領域模型也稱為概念性模型，領域物件模型和分析物件模型。 UP對領域模型的定義是，可以在業務建模科目中建立的製品之一。更準確地講，UP領域模型是UP業務對物件模型（BOM）的特化，“專用於解釋業務領域中重要的‘事物’和產品”[RUP]。 BOM覆蓋整個業務及其所有子域。 應用UML標記法，領域模型被描述為一組沒有定義操作的類圖。它提供了概念透視圖。它可以展示： 1）領域類之間的關聯 2）概念類之間的關聯 3）概念類的屬性 領域模型是可視化字典，表示領域的重要抽象、領域詞彙和領域的內容資訊。 領域模型是軟體業務對象圖嗎？ UP領域模型是對所關注的現實世界領域中事物的可視化，而不是諸如JAVA或C#類的軟體對象，或有職責軟體對象。因此，以下元素不適用於領域模型： 1）軟體製品 2）職責或方法 概念類：概念類是思想、事物或對象。概念類可以從其符號、內涵和外延來考慮。 符號：表示概念類的詞語或圖形 內涵：概念類的定義 外延：概念類所適用的一組樣本 領域模型和資料模型是一回事嗎？ 領域模型不是資料模型，所以在領域模型裡，並不會排除需求中沒有明確要求記錄其相關資訊的類，也不會排除沒有屬性的概念類。例如，沒有屬性的概念類是合法的，或者是領域內充當純行為角色而不是資訊角色的概念類也是有效。 如何建立領域模型 1）尋找概念類 2）將其繪製為UML類圖中的類 3）添加關聯和屬性。 如何找到概念類 1）重用和修改現有的模型：這是首要、最佳且最簡單的方法。
2）使用分類列表
3）通過識別名詞短語尋找概念類
領域模型是重要領域概念和詞彙的可視化。其中某些術語來源於用例。加外一些術語則源於其他文檔，或是專家的想法。
下面是幾個準則
準則：敏捷建模——繪製類圖的草圖
準則：敏捷建模——是否使用建模工具維護模型
如果採用敏捷建模方法，建立領域模型的目的是為了快速理解和溝通大致的關鍵概念。完美不是目的，敏捷模型在建立後通常很快就被拋棄了。基於這種觀點，則沒有理由去維護或更新這些模型，但是也不意味著更新模型就是錯的。
準則：報表對象——模型中是否要包括“票據”
票據是POS領域的重要術語。但也許它只是銷售和支付資料的報表，因此是一種資訊的重複，以下是一些因素的考慮：
1）一般來說，在領域模型中顯示其他資訊的報表並沒有意義，因為其所有資訊都是源於或複製於資訊源的。這是排除它的理由
2）另一方面，就商務規則而言，它有特殊的作用：通常持有票據的人有退貨的權利，這是在模型中要表示它的原因
準則：像地圖繪製者一樣思考：使用領域術語
準則：如何對非現實世界建模
有些軟體系統的領域與自然領域或業務領域幾乎沒有類似之處，例如電信軟體。然而還是有可能為這些領域建立領域模型。此時需要高度的抽象，對常見的非OO設計進行回顧，並且認真汲取領域專家所使用的核心詞彙和概念。 準則：屬性和類的常見錯誤
在建立領域模型時最常見的錯誤是，把應該是概念類的事物表示為屬性。
如果我們認為某概念類X不是現實世界中的數字或文本，那麼X可能是概念類而不是屬性
準則：何時使用“描述”類建模？
描述類包含描述其他事物的資訊，例如，ProductDescription記錄Item的價格、圖片和文字描述。這種類最早被命名為項目—描述類（Item—Descriptor）模式 準則：何時需要描述類？
在以下情況下需要增加描述類（例如，ProductDescription）：
1）需要有關商品或服務的描述，獨立於任何商品或服務的現有執行個體
2）刪除其所有描述事物的執行個體後，導致資訊丟失，而這些資訊是需要維護的，但是被錯誤地與所刪除的事物關聯起來
3）減少冗餘或重複資訊 關聯：關聯是類之間的關係，表示有意義和值得關注的串連
在UML中，關聯被定義為“兩個式多個類元之間的主義聯絡，涉及這些元執行個體之間的串連” 關聯圖
準則：何時表示關聯？由於領域模型是從概念角度出發的，所以是否需要記錄關聯，要基於現實世界的需要，而不是基於軟體的需要，儘管在實現過程中，會有出現大量對關聯的需要。
在領域模型中要考慮如下關聯：
1）如果存在需要保持一段時間的關係，將這種主義表示為關聯
2）從常見關聯列表中派生的關聯
準則：為什麼應該避免加入大量關聯？
我們要避免在領域模型中加入太多的關聯。回顧離散數學的相關知識，可以知道，在具有N個節點的圖中，節點間有（n*(n-1)）/2個關聯，這可能是個非常大的數值。連線太多會產生“視覺幹擾”，使圖變得混亂。所在要謹慎地增加關聯線。
準則：在UML中如何對關聯命名
以“類名—動詞短語—類名”的格式為關聯命名，其中的動詞短語構成了可讀的和有意義的順序。
例如，Sale Paid—by CashPayment 反面樣本，應改為Sale Uses CashPayment
Player Is—on Square 反面樣本，應以為 Player Has Square
關聯名稱應該使用首字母大寫的形式。在UML中，類元應該首字母大寫。以下是複合性關聯名稱的兩種常見並且等價的合法格式：
Records—current RecordsCurrent
應用UML：角色
關聯的每一端稱為角色。角色具有如下可選項：
1）多重性運算式
2）名稱
3）導航
應用UML：多重性
多重性定義了類A有多少個執行個體可以和類B的一個執行個體關聯的Store的一個執行個體可以和Item的“多個”（*表示零個或多個）執行個體關聯 關聯性多重性應用UML：兩個類之間的多重關聯在UML類圖中，兩個類之間可能會有多重關聯，這並不罕見。 屬性：是對象的邏輯資料值
準則：何時展示屬性
當需求建議或暗示需要記住資訊時，引入屬性。
例如，在處理銷售用例中的票據通常含有工期和時間、店名和地址以及收銀員ID等因此， 1）Sale需要dataTime屬性
2）Store需要name和address屬性
3）Cashier需要ID屬性在UML中，屬性的完整文法是：
visibility name：type multiplicity=default{property—string} UML屬性工作表示法
準則：什麼樣的屬性類型是適當的十分常見的資料類型包括：Boolean、Date(or DataTime)、Number、Character、String(Text)和Time等 準則：何時定義新的資料類型類下述情況下，在領域模型裡，把最初被認為是數字或字串的資料類型表示為新的資料類型類： 1）由不同的小節組成 2）具有與之相關的操作，例如解析或校正 3）具有其他屬性 4）單位的數量 5）具有以上性質的一個或多個類型的抽象 準則：任何屬性都不表示外鍵領域模型裡的屬性不應該用於表示概念類的關係。違反這一原則的常見情況是像在關聯式資料庫設計中的那樣增加一種外鍵屬性，用以關聯兩個類型。再強調一次，應該使用關聯而不是屬性來將類型關聯起來。 UP中的領域模型 初始：初始階段決不會發起領域模型，因為初始階段的目標不是進行嚴格的調查，而是決定項目是否值得在細化階段進行深入調查 細化：領域模型主要是在細化階段的迭代中建立的，這種裡最需要理解那些重要概念，並且會通過設計工作將其映射為軟體類。 UP業務物件模型與領域模型UP領域模型是較為少見的UP業務物件模型（BOM）的正式變體。不要與其他對BOM的定義混淆，UP BOM是一種描述整個業務的企業模型。BOM可以用來進行業務過程或再工程，而不依賴於任何軟體應用。 結束語：看了《UML和模式應用》第九章：領域模型後寫的這篇文章，基本上是摘了點書上我覺得關鍵的東西，希望能對和我一樣在學習UML的朋友來說，能有點協助。。。。
