451
技術社區[雲棲]
連載：麵向對象葵花寶典：思想、技巧與實踐（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類圖的同學都應該很容易發現，領域模型和設計類圖非常相似，麵向對象終於有了雛形了
================================================
轉載請注明出處：https://blog.csdn.net/yunhua_lee/article/details/22794315
================================================
最後更新：2017-04-03 12:56:00