閱讀目錄：

• 1.背景介紹
• 2.問自己，UML對你來說有意義嗎？它幫助過你對系統進行分析、建模嗎？
• 3.一直以來其實我們被一個縫隙隔開了，使我們對OOAD遙不可及
• 4.四色原型模式填補這個歷史縫隙，讓我們真的看見OOAD的希望
• 5.在四色原型上運用彩色建模增強視覺衝擊力
• 6.通過四色原型模式建模出領域無關模型
• 7.結束語：建模時你可以不考慮具體實現，但是建模者要懂技術實現

1.背景介紹

至今我都清楚的記得我第一次被面試官問起什麼叫”建模“技術時的情景，那是好幾年前的事情了，當時是胸有成竹的去面試一個有關係統分析、設計的.NET高階軟體工程師崗位。面試官幾乎沒問我有關.NET方面的任何技術實現，他就簡單的問了問：“你如何把握你所分析出來的系統的正確性？”，我當時有點小激動，覺得這個問題應該很簡單嘛，都是概念而已，讓他直接點問，結果他來一句：“你懂建模嗎？，能給我解釋一下建模的作用嗎？“，接著他出了一個小例子，讓我對這個例子進行建模，要考慮到各種擴充套件性、業務穩定性的關鍵點，要邊建模邊說出為什麼要這麼建模，要說出思路。他最後重點強調了一下：“創建出來的模型是不允許跟任何具體的程式碼、工具有關聯的”。

在我現在看來，他的意思也就是說創建出來的UML類圖模型是領域無關模型（領域通用模型），可以用任何一種程式設計技術去實現他，作為建模者不需要考慮這些實現細節，考慮的越多越容易分散你對真實業務的等價建模，容易犯技術人員的通病（用技術的思維來考慮業務）。

我當時心想這個容易啊，不就是用UML搞點圖出來做做秀嘛，體現出分析、設計的高階嘛，其他還能有啥作用；其實我當時之所以這麼想是因為我對UML、建模也嘗試過學習、理解和運用，結果我發現這就是一個作秀的工具罷了，對這個東西很不屑，甚至對軟體工程中的“建模”領域有一種抵觸心理。

我當時隨口說了一些我學習UML建模時的心得，心想這個也就是最終答案了，因為它確實就是這個作用（”作秀“），然後我通過程式碼驅動建模，倒著推匯出UML的類圖，

在我感覺非常良好的等著面試官接著問下一個問題的時候，情況出現了。面試官說我漏掉了東西，說我沒有充分考慮到業務場景，沒有將業務概念中的關鍵概念劃分清楚，甚至疏忽了很重小的領域實體屬性，按照我這個模型圖開發出來的軟體是不能夠滿足現在的業務要求的。我當時就蒙了，啥叫關鍵概念，哪個概念不是關鍵概念啊，又有哪裡不能用了，心理有點委屈，一時不理解，覺得面試官在為難我。

其實我現在能明白當時面試官說的是什麼意思，他是指我未能清晰的表達出各個類的職責，看上去每個類扮演的角色都是一樣的，無非就是屬性、方法這些類元素，我未能捕獲到核心領域概念，未能站在領域考慮建模，而是站在程式碼的層面上來從低往上看的，很多東西是看不清楚的，說白了，開發人員拿到這個類圖能否明白自己將要面對的領域，如果能明白，此時類圖模型是健康的，如果不明白那就是有問題的，因為模型圖不是給自己看的，而是給整個團隊交流共享的。

後來我自己調整了一下心情，就算面試失敗我也要有總結才行，面試本來就是一個被虐的過程。（“佛曰：此時正是修行時”，就當是鍛鍊好了。）

我虛心的向面試官請教我這個模型圖哪裡有問題，他指出了有可能我這輩子都無法看見的分析盲點，他說這個問題是程式設計師用技術思維來分析建模的通病。為什麼他能看見這些盲點，而我不能，我很想知道這其中的精髓，我當時就要求降薪到這裡來學習，面試官不降薪願意讓我過來，他也是一個對技術有追求的人吧。但是後來我有特殊事情未能去貴公司就職，此後我一直遺憾，這個建模精髓我有可能一輩子都搞不懂了。

現在我能明白，其實如果用程式碼級別的分析思維來輔助你建模就一定會有盲點，因為程式碼級別的“設計模式”，“設計原則”並非建模時的“分析模式”，這是兩個不同的問題域，也就是說彼此用在不同的業務領域的，不能夠一概而論，如果交叉使用就會誤導你目前的重心，你會往裡面添油加醋。

“建模”這個非常抽象且神聖的詞是多麼的霸氣，貌似是已經觸及軟體工程的最高境界了；崇拜，自卑；搞軟體開發也有幾年了，居然連建模都不懂；那一夜我徹底失眠了，從那以後我在技術上充滿了無助感，為什麼？因為我已經清楚自己要想在軟體領域有一定的成果，必須學會對真實世界建模，從那開始”建模“一詞在我腦子的已經和UML關係不大了。

之後我在軟體分析、設計的海洋裡苦苦尋找這個曾經在我面前就像流星一樣劃過的”建模金鑰匙“，有了它我就可以去一個神聖的世界。輾轉反側幾年過去了，在前不久我終於知道“建模的金鑰匙”是什麼了，這類東西在網路上很少見，寫的很少，下面我們來詳細瞭解它。

2.問自己，UML對你來說有意義嗎？它幫助過你對系統的分析、建模嗎？

我想學過軟體開發的人都多多少少了解UML，簡單講它就是一個用來建模的語言，你可以純粹的把它理解成是一個畫圖工具，定義了一些元素，用來表達不同的概念。這裡我們關心的是UML類圖，也就是用來進行面向物件結構建模用的，通過各種不同的圖形來表達抽象的物件結構。

圖1：簡單的訂單類圖

上圖是一個很簡單的“訂單”與“產品”相關的類圖，我們都能懂這裡面的意思，因為我們對這塊的業務很瞭解；知道在什麼地方應該有什麼，比如Order中的計算商品總價的演算法，有相關業務背景的人都知道這裡是會存在的極大邏輯變化的地方，所以我們需要通過介面來隔離這塊邏輯。

我們之所以能夠畫出這張類圖跟UML這個語言本身其實沒關係，重要的是你對相關的業務非常之瞭解，在你腦子裡可以不使用UML來建模，你可以用任何一個草圖來建模，也就是說UML並不等於建模，這個要清楚的認識。那我們使用UML有何用？它並沒有幫助我們來分析系統；沒錯，UML從某個角度講它沒有直接幫助我們對系統盡心分析建模，幫助我們分析建模的是那些業務知識，懂業務的人可以不使用UML來建模，隨便用一種圖形表示法來說明業務概念即可。其實UML只不過是一個通用的模型表達語言而已，是用來幫助我們交流模型用的，並非是建模的思想和方法。

既然UML不能夠幫助我們分析系統，那我們如何才能準確的建模出我們不是很熟悉的領域呢？我們必須承認，領域專家如果懂技術肯定是建模的最適合人選，但是現實並非這樣，需要我們技術人員去熟悉領域然後建立模型，但是這中間難免會漏掉重要的業務概念，因為畢竟從真實的業務到最終的模型是有一個過程的，而最讓我們無助的是在這個過程中沒有任何可行的指導思想可以借鑑的，只有通過經驗來把握最終的質量。

總是通過經驗來建模不符合軟體行業的發展方法，顯然不行，這種建模技術難道不可以傳遞嗎？答案是可以傳遞的，說明這個可以傳遞的技術正是本文的目的。我們繼續往下看。

3.一直以來其實我們被一個縫隙隔開了，使我們對OOAD遙不可及

上節中其實已經丟擲建模的核心問題域了，只不過不是很明顯；我們用本節來重點突出這個長久以來一直困擾我們建模者的問題域，以引起我們對它的重視，因為它也是軟體工程中的一個重要的研究領域。

如本節標題所說，其實我們被一個建模時所產生的一個縫隙隔開了，而這個縫隙很長一段時間內沒有人關注過，也沒有引起相關重視，所以導致我們的建模技術很難提升。

建模是一個過程，這個過程大概是這樣子的，需要我們將真實的業務場景準確的用某種建模語言表達出來，換句話說用什麼建模語言表達出來很容易，重點是如何得出這個模型，而得出這個模型的過程就是我們這裡所說的建模縫隙。

圖2：

從“業務概念”到“類模型”中間夾著一個“建模過程”，這個地方其實一直以來就是分析建模的鴻溝，這個空白的地方一直沒有成熟的經驗可以學習。在我們對當前分析的業務不是很瞭解的時候如何正確的建出對應的類模型，表層的領域概念我們可以根據自己的經驗去夠發現它，但是這畢竟是無法傳遞的知識。很多OOAD的書籍甚至包括很多軟體工程中的經典書籍都未給出這裡的答案，如果用一句準確的技術術語來形容這個過程的話，其實就是缺少一套建模分析模式，缺少一個可以讓我們不管針對什麼樣的業務進行分析時都是一套不變的指導模式。我想這個問題對我們建模者來說肯定是共同的問題，我們需要解決它。只有這樣我們才不會遇見自己所不熟悉的業務領域時而束手無策，當然你可以說你也一樣可以進行OOA，但是你一定會漏掉什麼的，這是分析盲點，是沒有正確指導思想的必然結果。正如上圖中的”下訂單“和”退貨“兩個核心的領域模型未能在右邊的”類模型“中建模出來，大部分開發人員的通病就是無法識別出潛在的領域概念，認為”表層“ 的領域概念就是類模型中的”實體“，其實這樣我們到最後就回到了表驅動的開發過程當中去，因為你只有通過E-R模型來思考時才能發現這種平面的結構，但是這又和正確的軟體開發訪問論背道而馳了。

4.四色原型模式填補這個歷史縫隙，讓我們真的看見OOAD的希望

本節我們將討論一個分析模式，它存在有一段時間了，值得我們高興的是它就是專門用來解決上述小節中闡述的“分析”鴻溝的，通過這套模式我們幾乎可以分析任何一個業務領域，再也不用怕由於自己對該領域不熟悉而漏掉了重要的領域模型，而導致程式碼混亂、難以重構的最大問題就是丟失重要的領域概念，讓各個物件的職責未能正確的在自己的空間中。

這個分析模式就是”四色原型“模式，根據名字我們就可以大概猜出它是基於四個概念來分析我們的業務概念，下面我們來了解一下哪四個概念：

1.實體：也可以叫做物品，表示一個參與者，比如：客戶、商品。

2.角色：實體、時刻時段的角色，如：訂單的配送型別，使用者的等級角色。

3.描述：用來對實體、時刻時段的公共屬性進行描述，比如：客戶實體的地址描述，這部分資訊是可以通用的。

4.時刻時段：實體在某個時間段內的參與事件，如：訂單，某個客戶在某個時間段內購買了某個商品。此概念就是用來跟蹤實體發生的所有需要跟蹤的事件。

當我們使用四色原型模式去分析業務概念時就很難丟失領域概念，下面我們依然以上面的業務領域為例使用四色原型模式進行分析。

圖3：

基本上我們可以使用四色原型模式去直接套某個業務領域，我們可以根據模式的思想來推斷領域模型是否需要四色中的一種。這樣我們基本上不會漏掉重要的業務概念。通過將“四色原型”模式與“RUP"製品中的“業務詞彙表”、"補充性規格說明“集合可以完成美妙的OOAD敏捷過程。使用四色原型模式來驗收RUP過程製品中的業務詞彙表，可以判斷出自己是否遺漏了重要的業務分支。

可以說四色原型模式是通往OOAD之門的金鑰匙，有了它我才相信我們現在分析的系統是OO的。

模型是讓人去閱讀理解的，上圖中我們很難看出哪個是”實體“哪個是”角色“哪個是”時刻時段“和”描述“，所以大師們借鑑了其他領域的彩色思想來建立軟體模型，這樣我們就夠能一眼的看出模型的具體意思，帶來強大的視覺衝擊力，下節我們詳細的來看看彩色建模。

5.在四色原型上運用彩色建模增強視覺衝擊力

為了能夠突出模型的視覺效果，在四色原型上運用不同的顏色來增加模型的視覺衝擊力。使用彩色模型能夠激發人類天生的視覺敏感性，讓人一目瞭然的知道整體的模型是個什麼結構。

圖4：

使用綠色來表示實體（參與者），使用黃色表示角色，使用灰色表示描述，使用桃紅色表示時刻時段。當然這裡的顏色不是很準確，由於我對顏色分的不是很清楚，所以未能調出最合適的顏色，但是差不多也就行了。

這樣當我們面對一個大型的UML類圖模型時就可以一眼識別出每個模型所代表的概念它的職責也就清晰明瞭了。

6.通過四色原型模式建模出領域無關模型

建模時我們是不需要考慮該模型將要被什麼技術落地，也就是說該模型是領域（技術、工具、平臺）無關的，可以使用任何技術來實現它。通過四色原型模式構建出來的模型圖更具有可塑性，概念非常的清晰，所有的模型都是概念明確的，不存在人為的設計在裡面，對於任何一個建模者來說這是非常寶貴的建模技術。如果沒有四色原型模式的背景，每個建模者都根據自己的經驗來假設出很多主觀的模型出來，其實這部分模型是很難讓別人理解的，因為每個人的理解角度不同，得出的模型自然也就差別很大，所以建模時使用四色原型模式是一個比較通用的模式，得出的最後模型也是一個通用的且團隊交流也是通用的。

技術無關是領域無關模型的一個面，領域無關也有另外一層含義，當我們有了四色原型模式時你是否發現你具有了征服所有業務領域的祕訣，就好比E-R模型一樣，一個可以用無邊際的抽象的模式，這個模式由四色基本的原型組成，而這個四個原型也是領域無關模型。

7.結束語：建模時你可以不考慮具體實現，但是建模者要懂技術實現

儘管建模高手會告訴我們建模時不要去考慮最後具體用什麼技術去實現它，其實跟你說這個話的人要麼就是精通某個技術的高手，要麼就是一個理論主義者，只知道畫圖而不知道如何具體落地領域模型的分析員，前者其實他已經做到心中有數了，為什麼這麼說，因為不懂技術實現的人來建模時是無法創建出能用的模型的，因為概念畢竟是概念，一旦落地到程式碼上、架構上一切都變了，並不是那麼的簡單直接落地的，需要考慮到讀寫、業務流、職責等等問題，這裡面是有很強的技術問題在裡面的。

好了文章到此結束，希望本文能對那些對OOAD、UML、建模有興趣的朋友起到一個拋磚引玉的作用，對本文的內容想進一步學習的可以參考《彩色建模》一書，這本書是OOAD大師[Peter coad]所著，謝謝大家。