讓技術人員看得懂的流程（3）——領域模型

讓技術人員看得懂的流程（3）

——領域模型

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

什麼是“領域模型”呢？隻要抓住“領域（Domain）”二字就可以理解，也就是說領域模型是幫助我們理解相關領域知識的模型。

進一步來問：為什麼需要領域模型？前麵不是有“用例模型”嗎，看起來用例模型好像就是描述相關領域知識的，是否完成用例模型就可以進行設計了？

如果你曾經寫過用例文檔，或者仔細看過用例文檔，那麼你肯定知道“用例”本身和“麵向對象”、“類”這些都沒有關係，用例就是純自然的語言（比如英語、漢語）寫的，因為用例實際上由客戶口述給我們、然後由我們形成文檔化的用例文檔，客戶才不管我們是什麼麵向對象還是麵向過程還是阿貓阿狗的。

因此，單純從用例來看，是沒有類的概念的，無法完成從自然語言到麵向對象語言的轉換。但是，既然我們已經完成了用例模型，那麼就必須基於用例模型進行分析(否則用例模型豈不是白做了)，而“領域模型”就是自然語言向麵向對象語言的一座橋梁。

讓我們來看看“領域模型”階段我們要做什麼、該怎麼做。其實很簡單，簡單概括就是“找名詞”，分為四個步驟：（1）找出用例模型中的名詞，（2）然後識別這些名詞本身的相關信息，（3）以及名詞之間的相互關聯關係，（4）用UML畫出領域模型。

我們來看在“用例模型”章節中的POST用例如何得出領域模型。

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

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

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

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

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

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

5）係統計算商品總額；

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

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

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

1）“顧客”、“收銀員”是係統的外部對象，不需要我們進行設計，但這些對象要和係統進行交互；

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

第二步：識別這些名詞本身的相關信息

一個對象的屬性可能分布在多個用例中，因此可以通過迭代不斷的完善一個對象的屬性，大家可以看到，我們在第一步中的樣例就已經分析了一部分了：“商品條形碼”、“商品信息”可以算作“商品”的屬性。

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

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

麵向對象設計就是依靠對象間的互相協作來配合完成相應的功能，因此識別出對象和對象本身的屬性外，還要識別對象間的關係，例如1對多、1對1、依賴等，詳細的各種關係可以參考UML的標準定義。

我們以第一步識別的三個對象為例：“商品清單”包含多個“商品”、一次“交易”對應一個“商品清單”、一個“商品”隻能屬於一個“交易”等。

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

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

（由於CSDN關閉了圖片上傳功能，因此無法貼出，大家可以根據前三步自己畫一個）

大家可以看到，經過“領域模型”的分析後，已經完成了自然語言到麵向對象語言的初步轉化了，領域對象已經識別出來，麵向對象已經初具雛形。

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

最後更新：2017-04-02 04:01:45