5. 領域模型

領域模型是面向對象分析和設計的第一步！！

完成了需求分析以後，咱們已經有了一個良好的開端，但咱們的主角「面向對象」還不見蹤跡。前面咱們提到，需求分析和麪向對象是沒有直接關係的，需求分析階段是不區分是面向對象仍是面向過程，那麼何時才真正開始面向對象的工做呢？

答案就在本章：領域建模。

從領域模型開始，咱們就開始了面向對象的分析和設計過程，能夠說，領域模型是完成從需求分析到面向對象設計的一座橋樑。

領域模型，顧名思義，就是需求所涉及的領域的一個建模，更通俗的講法是業務模型。

參考百度百科（http://baike.baidu.cn/view/757895.htm ），領域模型定義以下：

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

從這個定義咱們能夠看出，領域模型有兩個主要的做用：

• 發掘重要的業務領域概念
• 創建業務領域概念之間的關係

5.1 領域模型三字經

    領域模型如此重要，不少同窗可能會認爲領域建模很複雜，須要很高的技巧。然而事實上領域建模很是簡單，簡單得有點難以讓人相信，領域建模的方法歸納一下就是「找名詞」！

    許多同窗看到這個方法後估計都會笑出來：太假了吧，這麼簡單，找個初中生都會啊，那咱們公司那些分析師和設計師還有什麼用哦？

    分析師和設計師固然有用，後面咱們會看到，即便是簡單的找名詞這樣的操做，也涉及到分析和提煉，而不是簡單的摘取出來就可，這種狀況下分析師和設計師的經驗和技能就可以派上用場了。但領域模型分析也確實相對簡單，即便沒有豐富的經驗和高超的技巧，至少也能完成一個能用的領域模型。

    雖然咱們說「找名詞」很簡單，但一個關鍵的問題尚未說明：從哪裏找？

    若是你還記得領域模型是「需求到面向對象的橋樑」，那麼你確定一會兒就能想到：從需求模型中找，具體來講就是從用例中找。

    概括一下域建模的方法就是「從用例中找名詞」。

    固然，找到名詞後，爲了可以更加符合面向對象的要求和特色，咱們還須要對這些名詞進一步完善，這就是接下來的步驟：加屬性，連關係！

    最後咱們總結出領域建模的三字經方法：找名詞、加屬性、連關係。

    接下來咱們經過一個樣例來看看具體如何創建領域模型。

5.2 找名詞

咱們經過POS機買單的用例來看看具體如何建領域模型。

首先，將用例中全部的名詞挑選出來（以下用例文檔中黑色加粗的詞組）：

【用例名稱】 買單 【場景】 Who：顧客、收銀員 Where：商店的收銀臺 When：營業時間 【用例描述】 1. 顧客攜帶選擇好的商品到收銀臺； （這一步沒有異常） 2. 收銀員逐一掃描商品條形碼，系統根據條形碼查詢商品信息； 2.1 掃描儀壞了，必須支持手工輸入條形碼； 2.2 商品的條形碼沒法掃描，必須支持手工輸入條形碼； 2.3 條形碼可以掃描，但查詢不到信息，須要收銀員和顧客溝通，放棄購買此產品 3. 掃描完畢，系統顯示商品總額，收銀員告訴顧客商品總額； （這一步沒有異常） 4. 顧客將錢交給收銀員； 4.1 顧客的錢不夠，顧客和收銀員溝通，刪除某商品； 4.2 顧客的錢不夠，顧客和收銀員溝通，刪除某類商品中的一個或幾個（例如買了5包煙，去掉兩包） 4.3 顧客以爲某個商品價格過高，要求刪除某商品； 4-A：顧客使用信用卡支付 4-A.1 信用卡支付流程（請讀者自行思考完善，能夠寫在這裏，若是太多，也能夠另外寫一個子用例） 4-B：顧客使用購物卡支付         4-B.1 購物卡支付流程 4-C：顧客使用會員卡積分支付         4-C.1 會員卡積分支付流程 5. 收銀員清點錢數，輸入收到的款額，系統給出找零的數目； （這一步沒有異常） 6. 收銀員將找零的錢還給顧客，並打印小票； 7. 買單完成，顧客攜帶商品和小票離開； 【用例價值】 顧客買完單之後，就能夠攜帶商品離開，而超市也將獲得收入； 【約束和限制】 1. POS機必須符合國標XXX； 2. 鍵盤和屏幕使用中文，由於收銀員都是中國人； 3. 一次買單數額不能超過99999RMB； 4. POS機要很是穩定，至少一天內不要出現故障；

名詞列表：

顧客、收銀員、收銀臺、商品、條形碼、掃描儀、錢、5包煙、信用卡、會員卡、小票、買單、鍵盤、屏幕、中文、中國人。

經過這種簡單的方法，咱們很輕鬆的就識別出了領域中的各類概念，可是還不能高興的太早，識別領域概念的工做尚未結束，接下來咱們還須要提煉。

有了前面步驟識別的名詞列表後，提煉的工做就相對很簡單了，只須要刪除不是領域對象的名詞便可。

但具體應該刪除什麼名詞，是和不一樣的業務領域強相關的，並無徹底統一的標準，此時分析師的行業和領域經驗起決定做用，而這也正是菜鳥和專家的區別。

以咱們的收銀機爲例，提煉的過程以下：

1）刪除「收銀臺」：收銀臺只是一個物理設備，且這個設備與咱們的POS機也沒有任何交互，因此不能算做領域模型中的一個概念；

2）刪除「5包煙」：5包煙只是用例中舉例時的一個實例，是一個具體的商品，已經包含在「商品」中了；

3）刪除「中文」：「中文」只是「鍵盤」和「屏幕」的一個屬性，並非一個獨立的領域概念；

4）刪除「中國人」：「中國人」只是「收銀員」的一個屬性，並非一個獨立的領域概念；

5）刪除「條形碼」：「條形碼」只是「商品」的一個屬性，並非一個獨立的領域概念；

通過上面的提煉步驟後，就獲得了真正的POS機領域類，詳細以下：

顧客、收銀員、商品、掃描儀、錢、信用卡、會員卡、小票、買單、鍵盤、屏幕

5.3 加屬性

找出領域模型的名詞後，接下來一個重要工做就是將這些名詞相關的屬性找出來，使其更加準確。

但加屬性和前面找名詞有一點點差異：有的屬性並無在用例中明確給出，須要分析人員和設計人員額外添加，此時也是分析師的行業和領域經驗起決定做用。

名詞	屬性	備註
顧客	NA	對於POS機來講，並不須要識別顧客的相關信息，所以在領域模型中，顧客是沒有屬性的
收銀員	國籍、編號	「國籍」由找名詞步驟中的「中國人」提煉
商品	條形碼、名稱、價格	名稱和價格並無在用例中體現，但毫無疑問這是商品最基本的屬性
掃描儀	NA	掃描儀是POS機的一個輸入設備，POS機不須要識別掃描儀的相關信息，所以在領域模型中，掃描儀也是沒有屬性的
錢（現金）	數量，幣別	從領域分析的角度來說，「現金」更專業一些
信用卡	卡號	NA
會員卡	會員號、積分、有效期	NA
小票	交易信息、POS機信息、收銀員信息	小票的屬性在用例中並無詳細體現，但有經驗的分析師可以很容易識別出來
買單（交易）	商品列表、日期時間、總額、支付信息	這裏的屬性看起來和「小票」同樣，是由於「小票」本質上是給客戶的一個交易記錄。 這裏爲了更加符合軟件系統的屬於習慣，能夠將「買單「改成「交易」。
鍵盤	NA	和掃描儀相似，POS機不須要識別鍵盤信息
屏幕	NA	和掃描儀相似，POS機不須要識別屏幕信息

5.4 連關係

有了類，也有了屬性，接下來天然就是找出它們的關係了。

有了前面的工做，看起來連關係天然也是睡到渠成的事情，但不要忘了咱們的這個例子是很是簡單的，在一些複雜的系統中，領域模型之間的關係並不那麼明顯，菜鳥可能就只能看到最顯而易見的一些聯繫，而系統分析師和設計師能夠憑着豐富的經驗、良好的技巧識別出來，這也是系統分析師和設計師的價值所在。

POS機的領域類關係以下（僅供參考，並不要求每一個分析師和設計師都必定是這麼理解，但整體來講應該類似）：

  

看起來有點難以想象，需求階段白紙黑字的用例文檔，通過咱們一步一步的操做，最後獲得了圖形化的領域模型。曾經畫過甚至只是看過UML類圖的同窗都應該很容易發現，領域模型和設計類圖很是類似，面向對象終於有了雛形了

5.5 FAQ

    1. 爲何在POS機的領域模型的類中沒有看到類的方法呢？

        答：領域模型中的類不是軟件類，而只是用於描述領域的實體，不須要關注方法。

    2. 若是沒有用例，是否就無法獲得領域模型？

        答：不必定，對於那些經驗豐富的分析師來講，沒有用例一樣可以分析出領域模型。

    3. 若是是面向過程，須要進行領域模型分析嗎？

        答：基本不須要，面向過程的分析只須要分析數據結構和算法。

    4. 在用例模型中提到鍵盤和屏幕須要使用中文，這種信息在領域建模後就丟失了嗎？    

        答：確實是這樣，領域建模沒法關注用例的約束和限制，例如：性能、可靠性等。但咱們不用擔憂這些

               需求不能知足，由於後面設計的時候還會回過頭來覈對用例。

5.6 小結

• 領域模型是「需求到面向對象的橋樑」。
• 領域建模的三字經方法：找名稱、加屬性、連關係。
• 從用例中能夠找到領域模型的名稱。
• 不是全部的屬性都在用例中存在。
• 領域模型中的類不是軟件類，而只是用於描述領域的實體，不須要關注方法。