領域模型系列：概述

          領域模型是對領域內的概念類或現實世界中對象的可視化表示。又稱概念性模型、領域物件模型、分析物件模型。它專註於分析問題領域本身，發掘重要的業務領域概念，並建立業務領域概念之間的關係。

概念

　　業務物件模型（也叫領域模型 domain model）是描述業務用例實現的物件模型。它是對業務角色和業務實體之間應該如何聯絡和協作以執行業務的一種抽象。 業務物件模型從業務角色內部的觀點定義了業務用例。該模型為產生預期效果確定了業務人員以及他們處理和使用的對象（“業務類和對象”）之間應該具有的靜態和動態關係。它注重業務中承擔的角色及其當前職責。這些模型類的對象組合在一起可以執行所有的業務用例。 核心元素 　　業務角色顯示了一個人承擔的一系列職責。業務實體表示使用或產生的可交付工件、資源和事件。業務用例實現顯示了協作的業務角色和業務實體如何執行某個工作流程。使用以下幾種圖來記錄業務用例實現： 圖顯示參與的業務角色和業務實體。活動圖表，其中泳道顯示業務角色的職責，而物件流程顯示如何在工作流程中使用業務實體。 順序圖表描述業務角色和業務主角之間互動的詳細情況，並顯示如何在業務用例執行過程中訪問業務實體。 　　業務物件模型將結構的概念和行為的概念結合了起來。 　　它是一個紐帶工件，用於對業務關係進行清晰的表述，表述方式與 軟體開發人員的思考方式類似，同時仍保留一些純粹的業務內容。將我們所知道的有關業務的資訊按照對象、屬性和職責進行了合并。 　　它探索業務領域知識的本質，所採用的方式使我們能夠從對業務問題的思考轉變到對軟體 應用程式的思考上來。 　　它是一種確定需求的方法，使需求能夠為待建資訊系統使用，並得到該系統的支援。 　　確定業務對象定義、對象間關係、對象名稱和對象間關係名稱的流程使我們能夠以一種能被業務領域專家理解和驗證的精確方式來表達業務領域知識。   

領域模型 命名 　　對每個業務角色和實體進行命名，要求名稱能夠表示對象的職責。 　　一個好的名稱通常是名詞或動詞的名詞形式， 每個名稱都必須是唯一的。避免使用發音或拼字類似的詞以及同義字作為名稱，可能需要用好幾個單詞來組成一個明確的、無需額外說明的名稱。 對象 　　當您研究參與業務中不同用例的業務角色和業務實體時，可能會發現某些對象如此相似，以致於實際上是一個類。即使不同的業務用例沒有相同的要求，類是之間也可能相似到足以被視為一個相同現象的程度。如果是這種情況，您應該將相似的類合并在一起。這就產生了一個業務角色或業務實體，它擁有足以滿足不同業務用例要求的關係、屬性和操作。 　　因此，多個業務用例可以對同一個類有不同的要求。對於業務角色來說，如果有些僱員有能力擔當所描述的一組角色，那麼同樣還要有一些比較靈活可以勝任多個職位的僱員。這會使您的業務更加靈活。 模型 　　在業務物件模型中，業務角色代表僱員將擔當的角色，而業務實體則代表僱員將處理的對象。一方面，可以使用業務物件模型來確定業務僱員將如何進行互動，以產生業務主角所期望的結果。另一方面，系統用例模型和設計模型指定了業務的資訊系統。 　　 業務建模和系統建模解決不同的問題，其抽象程度也不一樣。所以一般而言，資訊系統不應該直接出現在業務模型中。 　　另一方面，僱員作為業務角色來使用資訊系統，實現相互之間的通訊、與主角的通訊以及對業務實體資訊進行訪問。所有的連結、關聯關係或屬性都有某個潛在的資訊系統對其進行支援。 　　這兩類建模環境有以下關係： 　　作為特定業務角色的僱員與資訊系統的一個系統主角相對應。如果建立的資訊系統使該僱員在業務用例中的所有工作都得到一個系統用例的支援，則他最有可能得到最好的支援。 另外，如果業務用例規模大、生存期長或者合并了多個獨立領域中的工作，資訊系統用例將可以支援業務角色的操作。 僱員工作的對象（建模為業務實體）常在資訊系統中得到表現。在資訊系統的物件模型中，這些業務實體作為實體類出現。業務實體之間的關聯關係和彙總關係常常使設計模型中實體類之間產生對應的關聯關係和彙總關係。 因此，系統用例訪問並操作設計模型中的實體類，這些實體類代表由被支援業務用例訪問的業務實體。最後，直接使用 商務資訊系統的業務主角也成為資訊系統的系統主角。 當確定對支援業務的資訊系統的需求時，這些關係十分關鍵。 主角 　　有時候，一個業務的僱員與另一個業務的僱員使用其他業務的資訊系統進行聯絡。從建模後業務的角度來看，這個資訊系統就是一個業務主角。 　　樣本： 某個軟體開發人員努力去理解他所負責的產品中出現的問題。為了瞭解問題是否源於他所使用的編程工具，他與供應商的全球資訊網伺服器聯絡，並仔細研究編程工具目前的版本中已知問題的列表。通過這種方式，業務角色“軟體開發人員”與業務角色“供應商的全球資訊網伺服器”進行互動。 定位 　　通常的做法是不在業務物件模型中對資訊系統進行明確建模，因為資訊系統只是業務角色所使用的工具而已。但當業務的資訊系統被客戶直接使用時，這種做法就不合適了。如果這個互動是商務服務的主要部分，您可能會出於商業上重要性的考慮而希望在業務物件模型中將其展示出來。電話銀行業務就是此類資訊系統的一個很好的例子。 　　從業務建模的觀點來看，建議使用以下方法： 　　將資訊系統看做一個和主角互動的完全自動化的業務角色。如果資訊系統和任何其他業務角色或業務實體相關，則考慮使用連結或關聯關係來說明這種關係。系統可能會向某個業務角色通知其進度，或者使用與某個業務實體相關的資訊。 簡單地說明業務角色，同時列出代表業務物件模型中資訊系統的服務。在資訊系統模型中對資訊系統和其環境的所有細節和特徵進行建模。引入一個命名規範，這樣可以容易地在業務角色中確定那些完全自動化的業務角色，例如，一個首碼或尾碼，如“自動<業務角色名稱>”或“<業務角色名稱>（IT 系統）”。您甚至可以使用一個特殊的表徵圖來定義構造型。 特徵 　　總的來看，業務角色和業務實體執行業務用例中描述的所有活動，絕不多一點，也絕不少一點。業務物件模型有效、全面地對組織進行了展示。 設計 　　舉一個簡單的例子來說明如何進行領域模型設計。 　　假如我們要為一個小賣店設計一套 進銷存系統，她為我們提供的業務描述是這樣的：每天淩晨從布吉農批市場買蘋果、梨、 葡萄、橘子、香蕉、荔枝、核桃等等，反正哪些好賣她就買回來賣。葡萄、荔枝不能長久保留，一般要當天賣出去…。 　　針對上面這段業務描述，我們怎麼進行領域模型設計。我給出以下幾個步驟來完成領域模型設計。 　　總結業務描述中的名詞 　　首先建一個名詞表，把涉及到的名詞列出來： 　　序號名詞備忘；　 　　1. 布吉農批市場 　　2. 買東西的人是一個隱含的名詞，每天淩晨從農批市場拿貨 　　3. 蘋果 　　4. 梨 　　5. 葡萄 　　6. 橘子 　　7. 香蕉 　　8. 荔枝 　　9. 核桃 　　10. 顧客是一個隱含的名詞，買回來賣的對象 　　11. 淩晨、當天時間名詞，與實體及角色無關 　　這個名詞列表包括了業務的行為主體：角色，以及業務過程中的操作實體：模型，對我們接下來的用例描述、領域模型分析、需求分析很有協助。當然這個名詞列表需要經過進一步分析提煉，成為領域模型 　　確定業務實體 　　序號名詞描述； 　　1. 布吉農批市場不是本業務的一個實體 　　2. 買東西的人是本業務的一個角色 　　3. 蘋果是一個實體 　　4. 梨是一個實體 　　5. 葡萄是一個實體 　　6.橘子是一個實體 　　7. 香蕉是一個實體 　　8. 荔枝是一個實體 　　9. 核桃是一個實體 　　10. 顧客是本業務的一個角色 　　11. 淩晨、當天時間名詞，與實體及角色無關 抽象業務模型 　　經過分析，我們得出的實體是蘋果、梨、葡萄、橘子、香蕉、荔枝、核桃，這些是不是模型呢。應該說還不是，還要經過進一步分析：在我們分析的業務領域內，它們有沒有共性。蘋果、梨、葡萄、橘子、香蕉、荔枝屬於水果，核桃屬於乾果，它們都是果品的一個具體執行個體。而在水果中葡萄和荔枝屬於不宜儲存水果，通過這樣進一步的分析得出如下的領域模型圖例： 　　果品 進銷存領域模型 　　這個領域模型不但能反映目前的經營實體，同時給我們需求分析人員和系統功能提供了一定的擴充視野：將來會不會經營食品，短期保持水果採取什麼利潤空間來促銷，長期儲存的水果會不會因為儲存成本而導致利潤下降。

關係　　

認為領域模型它是一個分析模型，協助系統分析人員、使用者認識現實業務的工具，描述的是業務中涉及到的實體及其相互之間的關係，它是需求分析的產物，與問題領域相關。領域模型是需求分析人員與使用者交流的有力工具，是需求分析人員與使用者共同理解的概念，是彼此之間交流的語言。而資料模型是系統設計、實現的一部分，描述的是對使用者需求在資料結構上的實現，僅此而已。當然資料模型中的概念性模型設計與領域模型類似，缺乏的是實體之間更廣泛的關係描述。 　　通常大家會考慮資料怎麼存放的問題，我的理解是領域模型設計期間不用考慮資料的存放問題，只考慮業務描述中涉及的實體以及實體之間的關係。 　　實體之間的關係，很多書都講了，無非是泛化、依賴和關聯，關聯又分了一般關聯、彙總、組合等等，我這裡就不列了。 總結 　　領域模型設計是需求分析的 關鍵步驟。它協助使用者及需求分析人員建立業務概念，確定使用者業務的問題域，系統涉及的業務範圍等等。 　　領域模型設計的步驟為： 　　1. 從業務描述中提取名詞； 　　2. 從提取出來的名詞中總結業務實體，區分名詞中的屬性、角色、實體、執行個體，形成問題域中操作實體的集合； 　　3. 從業務實體集合中抽象業務模型，建立問題域的概念（例如在前面的例子中，我們把容易變質的水果稱之為“短期保持水果”，當然也可以是其它說法，只要能跟使用者達成共識即可）； 　　4. 用UML提供的方法和圖例進行領域模型設計、確定模型之間的關係；