.NET應用架構設計—面向對象分析與設計四色原型模式（彩色建模、領域無關模型）（概念版）

閱讀目錄：

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

1.背景介紹

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

在我如今看來，他的意思也就是說建立出來的UML類圖模型是領域無關模型（領域通用模型），能夠用任何一種編程技術去實現他，做爲建模者不須要考慮這些實現細節，考慮的越多越容易分散你對真實業務的等價建模，容易犯技術人員的通病（用技術的思惟來考慮業務）。

我當時心想這個容易啊，不就是用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]所著，謝謝你們。

 

做者：王清培

出處：http://www.cnblogs.com/wangiqngpei557/

本文版權歸做者和博客園共有，歡迎轉載，但未經做者贊成必須保留此段聲明，且在文章頁面