關鍵字：uml

歡迎大家回到我的連載，從這一期開始，我們正式進入ICONIX的世界。閑話少說，進入正題。
　　什么是域建模呢？我們設計一個系統，總是希望它能解決一些問題，這些問題總是映射到現實問題和概念。很明顯我們的系統依賴于這些問題，對這些問題進行歸納、分析的過程就是域建模（這個域，指的就是問題域）。
　　好了，講理論大家要昏昏欲睡，我這個小小的連載也沒辦法把所有的概念說的一清二楚，要是有興趣的話可以打電話跟我暢談（前提是不許打手機），現在我來用一個實際的例子講述域建模。
　　用個比較簡單的例子吧，本來昨天我是想用HelloWorld來的，可是它實在太簡單了，不能說明問題，考慮再三，我使用一個猜數游戲來說明問題。這個游戲相信學過編程語言的都應該很熟悉了：輸入一個數，如果猜中了顯示“你好棒啊”然后結束，如果不對，系統告訴你是太大還是太小，然后重新讓你輸入，直到猜中為止。
　　現在請拿一張白紙，我們開始歸納問題。
+--------------------------------------------+
|　　系統應該準備一個正確答案　　　　　　　　|
|　　　　　　　　　　　　　　　　　　　　　　|
|　　玩家可以輸入一個答案　　　　　　　　　　|
|　　　　　　　　　　　　　　　　　　　　　　|
|　　系統應該比較玩家輸入的答案和正確答案　　|
|　　　　　　　　　　　　　　　　　　　　　　|
|　　系統應該顯示玩家每次輸入的結果　　　　　|
+--------------------------------------------+
　　遺憾我這個例子還是太過于簡單，不過簡單也有簡單的好處，從這個簡單的例子可以看出歸納問題的基本要點。
　　第一是不要涉及內部的流程，別出現“如果輸入不正確，就怎么怎么樣”的句子，這些并不是正確的問題，正確的問題必須明確的，清晰的，如果可能的話全部按照“什么可以干什么”的格式來寫。
　　第二是不要一開始就進入細節（抱歉，我這個例子例外，它實在是太簡單了），包涵太多細節的問題將會是一個長長的清單，這種清單根本沒什么用。盡量從最高一層分析，但也不要簡單到“用戶可以玩游戲”這種籠統的問題?？傊粋€原則是全面、清晰、明確。要做好問題域分析完全取決于設計師的水平與能力，這就不是可以簡單的看看書能達到的了。
　　好了，現在我們有了一個系統問題域的清單，可以進行下一步工作：發現類。
　　把問題清單中的名詞都提出來，得到一個名詞列表，這就是類的來源（不過不忙，這只是初步過程）
+----------------+
|　　系統　　　　|
|　　玩家　　　　|
|　　正確答案　　|
|　　答案　　　　|
|　　游戲結果　　|
+----------------+
　　不是所有的名詞都能作為類的，接下來需要進行篩選。
　　玩家是參與者，應該放到用例圖上去
　　系統太籠統，不能成為一個對象的名稱
　　答案和正確答案容易混淆，但稱為輸入答案又容易被誤解成一個動作，干脆叫做玩家答案
　　結果不明確，察看前面的需求，應該分解成錯誤信息和完成信息
　　篩選完畢后，得到下面一個名詞列表：
+----------------+
|　　正確答案　　|
|　　玩家答案　　|
|　　錯誤信息　　|
|　　完成信息　　|
+----------------+
　　這個列表缺少了系統，顯得太單薄，回過頭再仔細察看需求，應該引入一個游戲引擎，由它來充當調度者。
+----------------+
|　　游戲引擎　　|
|　　正確答案　　|
|　　玩家答案　　|
|　　錯誤信息　　|
|　　完成信息　　|
+----------------+
　　同時修改前面的問題域，現在系統已經明確是一個游戲引擎。這種替換當然是一種理想情況，通常都會發生分解和關聯，那時候需要擴充問題域，有時候還需要建立新的問題域。
+--------------------------------------------+
|　　游戲引擎應該準備一個正確答案　　　　　　|
|　　　　　　　　　　　　　　　　　　　　　　|
|　　玩家可以輸入一個答案　　　　　　　　　　|
|　　　　　　　　　　　　　　　　　　　　　　|
|　　游戲引擎應該比較玩家答案和正確答案　　　|
|　　　　　　　　　　　　　　　　　　　　　　|
|　　游戲引擎應該顯示玩家每次輸入的結果　　　|
+--------------------------------------------+
　　現在可以用Rose來制作Class Diagram了，同時可以用RAD工具來搞一個小小的GUI來看看效果，發現類工作到此告一段落。不過問題域分析還沒完，類與類之間的關系還沒有歸納，當然，那是下一段要講的事情了。