## 連載：面向對象葵花寶典：思想、技巧與實踐（23） - 領域建模三字經 看起來有點不可思議，需求階段“白紙黑字”的用例文檔，經過我們一步一步的操作，逐步就得到了“圖形化”的領域模型，面向對象初具雛形。 領域建模的三字經方法：**找名詞、加屬性、連關系**。 我們接下來以一個樣例看看領域模型具體如何建模。 ## 1.1.?找名詞 我們以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機領域類，詳細如下： **顧客、收銀員、商品、掃描儀、錢、信用卡、會員卡、小票、買單、鍵盤、屏幕** ## 1.2.?加屬性 找出領域模型的名詞后，接下來一個重要工作就是將這些名詞相關的屬性找出來，使其更加準確。 但加屬性和前面找名詞有一點點差別：有的屬性并沒有在用例中明確給出，需要分析人員和設計人員額外添加，此時也是分析師的行業和領域經驗起決定作用。 | 名詞| 屬性| 備注| |--|--|--| | 顧客| NA| 對于POS機來說，并不需要識別顧客的相關信息，因此在領域模型中，顧客是沒有屬性的| | 收銀員| 國籍、編號| “國籍”由找名詞步驟中的“中國人”提煉| | 商品| 條形碼、名稱、價格|名稱和價格并沒有在用例中體現，但毫無疑問這是商品最基本的屬性| | 掃描儀| NA| 掃描儀是POS機的一個輸入設備，POS機不需要識別掃描儀的相關信息，因此在領域模型中，掃描儀也是沒有屬性的| | 錢（現金）| 數量，幣別| 從領域分析的角度來講，“現金”更專業一些| | 信用卡|卡號| NA| | 會員卡| 會員號、積分、有效期| NA| | 小票| 交易信息、POS機信息、收銀員信息|小票的屬性在用例中并沒有詳細體現，但有經驗的分析師能夠很容易識別出來| | 買單（交易）| 商品列表、日期時間、總額、支付信息|這里的屬性看起來和“小票”一樣，是因為“小票”本質上是給客戶的一個交易記錄。這里為了更加符合軟件系統的屬于習慣，可以將“買單“改為“交易”。| | 鍵盤| NA| 和掃描儀類似，POS機不需要識別鍵盤信息| | 屏幕| NA | 和掃描儀類似，POS機不需要識別屏幕信息| ## 1.3.?連關系 有了類，也有了屬性，接下來自然就是找出它們的關系了。 有了前面的工作，看起來連關系自然也是睡到渠成的事情，但不要忘了我們的這個例子是非常簡單的，在一些復雜的系統中，領域模型之間的關系并不那么明顯，菜鳥可能就只能看到最顯而易見的一些聯系，而系統分析師和設計師可以憑著豐富的經驗、良好的技巧識別出來，這也是系統分析師和設計師的價值所在。 POS機的領域類關系如下（僅供參考，并不要求每個分析師和設計師都一定是這么理解，但總體來說應該相似）： ?? 看起來有點不可思議，需求階段白紙黑字的用例文檔，經過我們一步一步的操作，最后得到了圖形化的領域模型。 只要曾經畫過甚至只是看過UML類圖的同學都應該很容易發現，領域模型和設計類圖非常相似，面向對象終于有了雛形了