前言
簡單整理一下領域模型。
正文
領域模型是對領域內的概念類或現實中的對象的可視化表示
領域模型也稱概念模型、領域對象模型和分析對象模型
領域模型是可以在業務建模科目中創建的製品之一
領域模型是up業務對象模型的特化。
領域模型在軟件設計圖的關係:
一開始是梳理需求，寫出用例文本，建立用例模型。
然後領域模型是業務模型的一環，領域模型通過用例模型抽取出概念類、術語、概念、屬性、關聯。
當在業務模型中建立了領域模型之後，反過來豐富了用例模型，多了些操作契約。多了契約操作的話，那麼可以以此來編寫順序圖。
在uml中，領域模型被描述爲一組沒有定義操作的類圖。
值得注意的是領域模型不是在設計階段，不要帶軟件中的設計或者數據庫設計。
現實中的思想，事務或者對象。關注現實世界，而非軟件對象。
領域模型創建的步驟:
- 尋找概念類
- 繪製UML類圖
- 加關聯屬性
如果尋找概念類?
- 重用修改現在的模型
- 常見分類列表
- 名詞短語(從詳述用例)
什麼是概念類:
概念類是思想、事物或對象。更正正式地講，概念類可以從其符號、內涵和外延來考慮。
舉個例子:
領域模型和數據模型是一回事嗎？
- 領域模型不是數據模型(持續化數據)
- 在領域模型中不會排除沒有明確要求記錄其相關信息的類，也不會排除沒有屬性的概念類
- 在領域內充當純行爲角色，而不是信息角色的概念類也是有效的
動機: 降低與oo建模之間的表示差異
例如:
面向對象開發者在創建類時收到真實世界領域的啓發
因此，涉衆所設想的領域與其在在在軟件的表示之間的表示差異被降低。
準則： 像地圖繪製者一樣思考：使用領域術語
- 使用地域中現有的名稱。在圖書館模型中，將顧客命名爲"借書者"、"贊助者"等，這是圖書管理員使用的術語
- 排除無關或超出範圍的特性
- 不要憑空增加事物
準則： 如何對非現實世界建模
- 有些軟件系統的領域與自然領域或業務領域幾乎沒有類似指出，例如：電信軟件
- 此時需要高度的抽象，對常見的非00設計進行回顧，並認真汲取領域專家所使用的核心詞彙和概念
- 例如，電信軟件的候選概念類：消息、連接、端口、會話、路由、協議
準則： 屬性與類的常見錯誤
常見錯誤： 把應該是概念類的事務表示屬性
判別準則： 如果我們認爲某概念X不是現實中的數字或者文本，那麼x可能是概念類而不是屬性。
準則： 何時使用"描述"類建模
描述包含描述事物的信息：如productDescription 記錄Item的價格、圖片和文字描述。
命名方式：項目-描述符
- 描述有關商品或服務的描述，獨立於任何商務或服務現有實例
- 刪除所描述事物的實例後，導致信息丟失，而這些信息是需要維護的，但是被錯誤低於所刪除的事務關聯起來
- 減少冗餘或重複信息
關聯:
關聯是類之間的關係，表示有意義和值得關注的連接。
在uml中，關聯被定義爲"兩個或多個類之間的語義聯繫"，涉及這些類元實例之間的連接。
觀點：關聯是否在軟件中實現
- 在領域建模中，關聯不是關於數據流、數據庫外鍵的聯繫、實例變量或軟件方案的對象連接語句；
關聯聲明是針對現實領域從純概念角度看有意義的關係 - 這些關係的大部分作爲導航(設計模型和數據模型中的)和可見性路徑再軟件中加以實現。
結
下一節順序圖