領域模型（轉）

按照通常的項目管理過程，「需求」以後是「分析」，那麼在分析階段對應的技術流程又是哪一個？如何將需求階段和分析階段聯繫起來呢？答案就是「領域模型」

什麼是「領域模型」呢？只要抓住「領域（Domain）」二字就能夠理解，也就是說領域模型是幫助咱們理解相關領域知識的模型。

進一步來問：爲何須要領域模型？前面不是有「用例模型」嗎，看起來用例模型好像就是描述相關領域知識的，是否完成用例模型就能夠進行設計了？

若是你曾經寫過用例文檔，或者仔細看過用例文檔，那麼你確定知道「用例」自己和「面向對象」、「類」這些都沒有關係，用例就是純天然的語言（好比英語、漢語）寫的，由於用例實際上由客戶口述給咱們、而後由咱們造成文檔化的用例文檔，客戶才無論咱們是什麼面向對象仍是面向過程仍是阿貓阿狗的。

所以，單純從用例來看，是沒有類的概念的，沒法完成從天然語言到面嚮對象語言的轉換。可是，既然咱們已經完成了用例模型，那麼就必須基於用例模型進行分析(不然用例模型豈不是白作了)，而「領域模型」就是天然語言向面嚮對象語言的一座橋樑。

讓咱們來看看「領域模型」階段咱們要作什麼、該怎麼作。其實很簡單，簡單歸納就是「找名詞」，分爲四個步驟：（1）找出用例模型中的名詞，（2）而後識別這些名詞自己的相關信息，（3）以及名詞之間的相互關聯關係，（4）用UML畫出領域模型。

咱們來看在「用例模型」章節中的POST用例如何得出領域模型。

第一步：找出用例模型中的名詞

原有用例以下，用藍色加黑標出名詞（重複的就不標了）：

1）顧客攜帶商品到收銀臺；

2）收銀員掃描商品條形碼；

3）系統根據條形碼獲取並顯示商品信息；

4）收銀員重複2~3步，直到全部商品掃描完畢；

5）系統計算商品總額；

。。。。。。。。。。。。。。。。。。。。

n）系統打出商品清單，完成交易。

這個用例中的名詞有「顧客」、「商品」、「收銀臺」、「收銀員」、「商品條形碼」、「系統」、「商品信息」、「商品總額」、「商品清單」、「交易」。稍加整理：

1）「顧客」、「收銀員」是系統的外部對象，不須要咱們進行設計，但這些對象要和系統進行交互；

2）「商品」、「商品條形碼」、「商品信息」、「商品總額」、「商品清單」、「交易」是領域對象，但「商品條形碼」、「商品信息」能夠算做「商品」的屬性、「商品總額」能夠算做「交易」的屬性，最後從這個用例總結出來的領域對象有「商品」、「商品清單」、「交易」三個。

第二步：識別這些名詞自己的相關信息

一個對象的屬性可能分佈在多個用例中，所以能夠經過迭代不斷的完善一個對象的屬性，你們能夠看到，咱們在第一步中的樣例就已經分析了一部分了：「商品條形碼」、「商品信息」能夠算做「商品」的屬性。

對象除了屬性外，還有一些約束或者限制，這些在用例中可能有，也可能沒有，這就須要分析人員來發現了。好比說交易金額必須大於0.1元小於99999元這種約束，用例中不必定會體現，可能須要分析人員向客戶諮詢。

第三步：識別對象間的關係

面向對象設計就是依靠對象間的互相協做來配合完成相應的功能，所以識別出對象和對象自己的屬性外，還要識別對象間的關係，例如1對多、1對一、依賴等，詳細的各類關係能夠參考UML的標準定義。

咱們以第一步識別的三個對象爲例：「商品清單」包含多個「商品」、一次「交易」對應一個「商品清單」、一個「商品」只能屬於一個「交易」等。

第四步：畫出領域模型UML圖

UML這裏就不囉嗦了，咱們結合前三步的分析，畫出這個樣例的UML領域模型圖：

 

你們能夠看到，通過「領域模型」的分析後，已經完成了天然語言到面嚮對象語言的初步轉化了，領域對象已經識別出來，面向對象已經初具雛形。

須要提醒的是：領域模型過程當中識別出來的對象和具體的語言無關，也沒有方法。換句話說，public、private、函數這些面向對象的屬性在領域模型階段不須要分析出來。

轉自：http://www.cnblogs.com/ppgeneve/p/5089113.html