OO系統設計師之路--分析模型系列（1）--什麼是分析模型 [從老部落格搬家至此]

分析模型是采用分析類，在系統架構和架構的限制下，來實作用例場景的産物。

（讓關心OO之路列的朋友們久等了，今天正式開始推出之路系列的第二部，OO系統設計師之路。在第一部OO系統分析員之路中，我們始于什麼是用例，結束于需求規格說明書。我們還記得在第一部中，最後的結果是系統用例。系統用例規定了系統範圍，通過用例場景，規定了系統藍圖，讓我們知道了系統将如何實作業務用例中規定的業務。這些工作，是由系統分析員來完成的。到這裡為止，我們還不知道如何讓計算機來執行這些業務。大家都知道，在需求過程結束後，即将進行的是分析設計過程，這是系統設計師的職責。OO之路第二部正是針對系統設計師的，筆者将試圖在接下來的文章裡，說明如何做系統設計，要運用哪些工具，産生哪些結果，以及如何來驗證我們的設計是否正确。

這是設計師之路的第一篇，筆者要讨論的是分析模型。我們經常會聽到分析模型這個詞，但真正懂得，或者用過分析模型的人卻少之又少。下面筆者将寫下一段對話，這段對話是筆者在招聘設計師的過程中與許多應聘者對話的場景模拟。90%以上的應聘者都不能很好的回答這些問題。讀者也可以試着回答，看看你對用UML進行OO系統設計有多深的了解。

對話場景：

-在需求過程結束以後，接下來你會做什麼？ 

-分析設計

-你的設計依據是什麼？ 

-需求結果，用例模型

-你是如何設計的？設計的結果是什麼？ 

-設計類圖，确定類的方法和屬性，會用時序圖來表達類之間的互動。還有會應用設計模式來增強系統的擴充性和複用能力。

-那你是如何确定出類來的呢？比如針對一個特定的需求，為什麼你決定用三個類而不是五個類？類方法又是如何确定的呢？為什麼設計七個方法而不是十個方法？ 

-短暫沉默後：經驗啊，從我多個項目的設計經驗和實際情況來看，用這幾個類和這些方法完全可以滿足業務要求，并且是經過優化的，是最好的方案。

-那麼你如何能夠保證，或者，你用什麼來證明，你的設計能夠滿足需求呢？除了經驗之外，你能用什麼方法來證明呢？ 

-沉默之後:我有很豐富的設計經驗，我的設計是經過深思熟慮的。設計會經過評審，讨論和充分的溝通，後面還有測試，不滿足需求時會再進行修改和補充的。

-剛才你也說了，需求結束後你将進行分析設計的工作。你能說說分析和設計的差别嗎？分析做什麼，設計做什麼？ 

-更長時間的沉默：分析和設計是同一個過程，分析是想的過程，設計是把想的内容用類表達出來。

-我們知道在UML裡有分析模型和設計模型，如果分析和設計是同一個過程，你能說說分析模型和設計模型的差別嗎？ 

-沉默...

是的，的确是這樣。很多人分不清分析和設計不同的目标，沒有使用過或根本不知道分析模型。更多的人無法回答他的設計如何能夠被證明是滿足需求的，那些類在他們看來，都是憑經驗，如同精靈一般從腦子裡蹦出來的。他們很自信自己的經驗和設計能力，津津樂道于一個又一個設計模式，他們認為，如此優秀的設計怎麼會不滿足需求呢？證明？很奇怪的問題，我設計的目的就是為了滿足需求，不滿足需求的設計我會不斷改進啊，最終它一定是滿足的啊。

可惜這并沒有回答我的問題，我問的是如何證明，而不是是不是滿足。即使設計師擁有豐富的經驗和超強的設計能力，設計結果的确滿足了需求，并且很優秀，但那隻是結果而不是過程，那是個人英雄的勝利，而不是軟體過程的勝利。

事實上，這一切問題，都隻是因為設計師們遺忘了很重要的一個過程，分析模型。那麼什麼是分析模型呢？為什麼分析模型能夠解決這些問題呢？

RUP裡對分析模型和分析類的定義是：分析類用于擷取系統中主要的“職責簇”。它們代表系統的原型類，是系統必須處理的主要抽象概念的“第一個關口”。如果期望獲得系統的“進階”概念 性簡述，則可對分析類本身進行維護。分析類還可産生系統設計的主要抽象：系統的設計類和子系統。

如果你對上面的定義感到迷惑不解（RUP的定義一向如此），下面是筆者在實際工作中對分析模型的了解和應用經驗，或許可以幫助讀者理清頭緒。

• 分析模型是采用分析類，在系統架構和架構的限制下，來實作用例場景的産物。在OO之路的第一部裡，我們說用例和用例場景規定了業務範圍和要求，如果分析類完全實作了這些用例和場景，我們就能肯定的說分析類已經滿足了需求。

  分析類是什麼呢？一般來說，分析類有：

  邊界類(boundary)

  

  實體類(entity)

  

  控制類(control)

  

  再加上實作用例場景需要的actor類，共四種。這些分析類将在後面的文章裡詳細讨論，讀者現在隻需要記住它們的樣子。
• 分析模型是高層次的系統視圖，在語義上，分析類不代表最終的實作。它是計算機系統元素的高層抽象。上述的四個分析類可以完全模拟計算機的執行過程。分析類具化以後産生真正的實作類，即所謂的設計類，也就是大多數設計師所說的類圖。
• 筆者認為分析模型正是OO設計的核心，而設計類隻是OO的實作手段。還記得上一部第一篇中筆者提到的複用的三個層次嗎？元件級的複用實際上是通過分析模型表達的，而設計模型中的複用，隻是利用了OO語言的特性，來實作複用的要求。
• 分析模型是MVC模式的經典應用。從分析類的名稱就可以看出來。筆者在上一部第四篇中講到的一個觀點：“商業系統無論多複雜，無論什麼行業，其本質無非是人，事，物， 規則。人是一切的中心，人做事，做事産生物，規則限制人事物。人驅動系統，事展現過程，物記錄結果，規則則是控制。無論OO也好，UML也好，複雜的表面下其實隻是一個簡單的規則，系統分析員弄明白有什麼人，什麼人做什麼事，什麼事産生什麼物，中間有什麼規則，再把人，事，物之間的關系定義出來，商業模組化也就基本完成了。”。根據這一段話，再對比分析類的名稱，想想MVC模式，讀者應該能夠發現分析類在OO和商業目标中精妙的對應關系：人，事，物，規則--actor,boundary,engity,control。這就是為什麼筆者說分析模型是OO設計的核心。

問題是為什麼要用分析模型呢？現在絕大多數系統的産生過程并沒有用分析模型，不也照樣運作？而且在RUP裡，分析模型也隻是一個Optional的過程，并非強制過程啊？

的确如此，這可能也是為什麼大多數設計師并不用分析模型的原因。但是，同時，文章前面的對話場景中的問題也産生了。有讀者要問，你說分析模型完全實作用例場景是以可以證明設計滿足需求，那麼我用設計類來實作用例場景，不也可以同樣證明？ 那分析模型又有何用呢？

而這正是分析模型要存在的原因。剛才，筆者說了，分析類不代表實作，它具化成設計類以後才是實作。分析類是系統元素的高層抽象。有經驗的設計師，特别是那些擅長于使用設計模式的設計師們都知道，OO系統要保持擴充能力，複用性要好，要把變更影響控制在小範圍内，就要應用高層次的抽象，用高層次的抽象接口來表達系統行為，而把具體實作delay到子類，配置文檔，甚至運作期去。所有的設計模式，不論采取了怎樣的技巧，均是為了這些目的。分析模型對系統設計來說也同樣延續了這樣的思想，用四個高度抽象的分析類來表達系統行為，而把實作delay到設計類中去。這些抽象透明于實作方式，也透明于實作語言，它表達的核心觀點是系統架構，業務實作模式和規範，需求可回溯的驗證。

比如，我們用一個實體分析類表達了某個業務實體，在分析模型中我們定義了所有針對該實體的互動和存取操作，對分析模型這個層次的抽象來說已經完整表達了計算機系統對業務需求的模拟實作。但其實這時并未真正的實作這個業務需求，一直到具化成設計類後，根據開發語言特性，架構，規範等等要求，這個實體分析類可以被具化成一個或多個SDO，POJO，EntityBean，可以用Hibernate，可以用 Webshpere BO，也可以用Weblogic XMLbean...等等。完全可以根據實際需要來确定實作方式和語言，是以實作得以delay，這就帶來了OO擴充和複用的潛在能力。并且這時設計師已經不用擔心具化出的設計類是否會脫離需求，它們已經在分析模型層次被驗證，而能專心考慮系統實作所要求的那些特性。在後續的文章裡筆者還會更詳細的讨論這些問題，這裡隻是舉一個例子。

為什麼要用分析類而不是設計類去驗證需求呢？這是由于抽象層次更高，分析類比設計類驗證需求的工作量以及可能的變化都要少很多。比如針對登入要求，如果用分析類來表達，我們隻需要向登入control類發一條登入請求就OK了。而設計類由于與實作方式相關，并且已經具化到了實作，是以根據安全驗證方式不同，LDAP，CA，SSL，或應用伺服器不同，登入方式和方法都不同，并且可能是很多個步驟，例如getUser(),getRole(),getGroup(),register()...你願意用這麼多說明才能表示已經驗證了一個簡單的登入要求嗎?慢着，如果更換了安全模式呢？更換了應用伺服器呢？這在現實情況中也很常見，對分析類來說，由于抽象層次高于實作方式，是以繼續有效，而設計類卻必須更改。這就是為什麼要用分析模型來驗證需求的原因之一。

較真的讀者或許會說，安全模式變了，就算不為了驗證需求，設計類本身也不得不改，這看起來沒什麼必然因果關系啊？考慮一下，在一個項目組裡，當一份設計文檔被share到負責各個摸塊的開發小組時，各小組對該文檔都形成了一個共同的認識。如果這個認識是基于分析模型而不是設計模型的，當安全模式改變，對負責安全子產品的開發小組來說，他可以改變他負責的設計類而無需通知其它小組。因為從分析模型的層次來看，一切都沒有改變。 這與大家熟悉的設計類中更換了類實作而保持接口不變的道理是一樣的，隻要接口不變就無須通知任何人。 而如果這個共識是基于設計模型的，一點小的改變都需要通知到各個小組，因為各小組的認識是基于類名，方法名的，改動了，能不通知他人麼？從OO角度來說，這就是松藕合和緊藕合的差别。

從上面的例子可以看出分析模型比設計模型要穩定得多，是以用它來驗證和表達系統到需求的映射是很好的。這有助于在開發過程中當實作類變來變去，一個類改兩個，突然又加了一個設計模式(這種情形非常的常見吧?)時，保持系統到需求映射的穩定，同時也就保持了一個穩定的系統視圖和業務架構。對開發小組來說，不會因為這些變動影響到他們對系統整體的認識。

分析模型較高的抽象層次有助于讓人們更容易了解系統行為。由于與實作無關，是以可以用大白話來表達系統互動過程，比如對于登入要求，我們可以直接用“登入()”來表示這個系統請求，相比于設計類中的getUser()，getRole()，getGroup()之類的方法名，分析模型明顯要直白得多。而開發人員對系統行為良好的了解顯然會對開發有着很大的幫助。 在一個項目比較複雜，而且是多個Team橫向合作的情況下，分析模型顯得更加有效。因為它的簡潔和穩定，會讓各個開發組減少細節溝通的成本。

最後，如果你所做的項目并非一次性項目，而是基于一個行業，不斷的有相似或相同的單子，更打算長期立足于這個行業，做精做深，形成完整的行業解決方案的話，分析模型更是必須要考慮的。在你的組織面對同行業不同客戶時，可能無法保證所有客戶都選擇同樣的語言，同樣的軟體平台，有着同樣的業務要求。在設計模型的層次上，這必然導緻很多個不同的實作版本。面對這麼多不同的版本，如何去維護一個“統一的行業解決方案”呢？正如上面所述，由于分析模型抽象層次高于實作方式和實作語言，你可以用分析模型來維護這一個方案。還是登入的例子，雖然客戶們可能有的用LDAP，有的用CA，将來可能還有新的模式，但對于分析模型來說，安全子產品始終可以保持一緻。這将非常有利于随着各個項目的進行，對分析模型的逐漸維護，而形成一個統一的，穩定的架構和行業解決方案，而針對不同的客戶要求，又可以提供不同的實作包。

這是OO系統設計師之路的第一篇。筆者讨論了什麼是分析模型，以及為什麼要用分析模型。下一篇将用一個示例說明分析模型如何做，它的結果是什麼樣的。敬請期待。

*********************************************************

作者coffeewoo 歡迎您通路文章原始出處 : http://blog.csdn.net/coffeewoo，閱讀中有任何問題可以在BLOG上留言或發郵件到 [email protected].com，我将盡力為您解答。具有代表性的問題我會以 Q &A的形式收錄到對應的文章之後。希望本系列文章對您有幫助。歡迎轉載，敬請注明，謝謝 ^_^