上一篇筆者闡述了什麼是分析模型，我們爲什麼要使用分析模型，分析模型能給我們帶來什麼。這一篇來討論怎麼做分析模型。
開篇之前先說點題外話。筆者不厭其煩地一次次提到需求的可追溯性，是因爲軟件工程比UML更重要更本質。筆者自己在學習UML過程中，曾經也非常迷惑而不得要領，這麼多UML元素，每個都有其特定的含義，RUP中定義了更多更復雜的流程，模板，工具...雖然讀了很多資料，卻始終感覺UML信息太過於分散，不能很好的把UML應用到實際的項目中去。直到有一天突然轉變了思維，不是從UML的定義中去思考如何做軟件，而是站在軟件工程的角度，去UML中找尋需要的工具。正是這一轉變使我對UML的認識茅塞頓開。我想，初始學習UML的人可能也會經歷跟我同樣的困惑，在這裏我願意把我的領悟與大家分享。對軟件項目來說，OO也好，面向過程也好，UML也好，UC矩陣也好，這些都不是最重要的，軟件項目真正的靈魂是軟件工程。軟件工程的需要纔是這些工具誕生的原因。因此我建議閱讀我文章的朋友們，在討論如何應用UML之前，應當先系統學習軟件工程。只有掌握了軟件工程，你纔會知道爲什麼要有用例，爲什麼要有分析模型。站在軟件工程的立場，那些孤獨的UML圖符纔會變得有生命力，你隨時都會知道需要用什麼樣的UML圖符來表達軟件的觀點。UML也不再面目可憎，它們是一羣有着強大能力的精靈，幫助你在複雜的軟件工程道路上搭起一座座通向光明目標的橋樑。
雖然是不厭其煩，還是要再次提醒，注意需求的過追溯性，這是軟件工程的需要。這一篇我們要討論的話題裏，仍然逃不開這條主線的牽引，你會發現這一篇裏產生的任何一個成果都與之前的工作息息相關。如何做分析模型？在UML裏，RUP裏沒有明確的答案，我從軟件工程中找到了答案，正如上一篇所說，析模型是採用分析類，在系統架構和框架的約束下，來實現用例場景的產物。用例場景是什麼？是用戶需求的模擬，實現用例場景，就是實現需求。爲了達到需求可追溯的目的，分析模型需要以下這些輸入（還是採用用例分析系列文章中的例子）：
- 用例場景
![]()
- 與用例實現相關的領域模型
![]()
- 用例規約 以及
- 補充規約
在正式開始做分析模型之前，筆者有必要提醒一下，分析模型是系統的高層抽象，是高於實現語言和實現方式的。因此在做分析模型過程中，要跳出固有的java思維，C++思維，同時也暫時不要考慮設計模式的應用，而專心的，用OO思維把四個分析類的職責和交互，以及它們之間的關係定義清楚。如果說用例分析大部分情況下是程式化的（筆者正希望它是程式化的），那麼你會發現，分析模型大部分工作也是程式化的。let's begin!
現在，我們有這樣一些原料，用例場景提供了需求的輸入，領域模型提供了初始的業務原材料，還有用例規約和補充規約提供了詳盡的規則。正如筆者在之前的文章中提到的一句話：用例場景非常非常的重要，後續的工作就靠它了。這句話開始起作用，我們的第一步，就從用例場景開始。
做分析模型的建築材料就是四個分析類，我們要用它們來搭建用例場景。actor分析類來自用例分析中的actor，實體類來自領域模型，邊界類來自用例場景中actor-計算機交互，控制類來自業務規則（包括用例規約中的前置、後置條件、業務規則以及補充規約中的全局規則）。所使用的工具是時序圖，目標是實現用例場景。我們先來做一個草圖，對照着用例場景圖，一步步來，得到這個結果：
- 分析模型草圖（圖片比較大，由於Blog框架的問題，如果看不全，可以在圖上右鍵->圖片另存爲，保存到本機再看）
我們來分析一下上面的草圖。首先，這幅草圖大家可以看到，所有的實體類沒有做任何變動，直接照搬了業務實體(領域模型)，所謂的控制類，只是機械的在每一個實體前加了一個控制器，邊界類只用了一個。至於過程，更是和用例場景一模一樣，只不過形式不同而已，改用了計算機術語。這個例子只有一個用例場景，如果有多個，每個場景畫一次，重複用到的類直接拖過去，能用的方法直接用，還沒有的就加上，總之忠實的實現這些用例場景就好了。整個過程很簡單，很程式化，對嗎？不用腦子都能做。儘管如此，我們仍然得到了一個分析模型的靜態圖，就象下面這樣：
小提示：在做分析模型時，從時序圖開始做，需要用到一個分析類時，就轉到類圖中創建這個類，再從左邊的樹形列表裏把類拖到時序圖上。從一個對象畫一條表示交互消息的箭頭到另一個對象後，右鍵點擊線條，選擇"new operation"，再輸入操作名，這時Rose會在線上標明這個操作名稱的同時在對應的類上創建這個方法。這樣，在繪製時序圖的同時也生成了靜態類圖。最後再把類之間的交互用線連起來表示這個關聯關係，靜態圖就完成了。
- 分析模型靜態圖
再來一個小提示：rose對中文的支持不好，因此上面的圖中類下面無法完整的顯示用中文寫的方法名，不過雙擊open sepcification對話框能正確顯示。相信大家注意到我所有貼上來的圖文字都是仿宋體而不是通常用的宋體，這是因爲在字符集裏，宋體並沒有被限定爲GB2312，所以當把rose裏的圖全選並拷貝到畫圖或WORD裏時會文字會變成亂碼。大家一定也遇到過這種情況吧？一個小技巧就是用仿宋字體，預先設定字體或者全選（crtl+A會吧），再菜單format->font，選仿宋，你可以看到在仿宋字體後面帶了GB2312的字樣^_^。這樣就不用先屏拷再剪切，再拷貝到word裏了。用word2003的朋友幸運了，沒有這個問題。
不可否認，這個類圖很粗糙，但是一個系統原型已經出來了。我們得到了可以完全實現需求的一些類，主要的類方法也有了。如果你想偷懶的話，直接把它轉換成設計類圖，把中文方法名改爲英文，再把領域模型文檔（不記得了回頭查以前的文章）中提到的實體屬性填入，就已經可以交付開發了。因爲需求已經實現了，類有了，方法有了，類屬性有了，別忘了在用例分析過程中已經用靜態HTML做了系統原型，因此界面也有了。一切開發需要的東西都全了。比如我們用Strus+hibernate架構，一個實體類就是一個POJO，一個控制類就是一個action，至於界面，在靜態HTML裏填入java代碼改成JSP唄。如果你是一個開發人員，把這個圖給你，相信你也會覺得開發這個需求是很明確很簡單的事吧？呵呵，成就真不小，可是仔細想想，我們甚至都沒有動腦子啊！真是的，我們沒有動腦子，居然就做了一個設計，恩!？可事實就是這樣，誰說分析設計就一定要動腦子？不動腦子就不能做設計嗎？就不能體現一個設計師的價值嗎？設計的目的是什麼？漂亮？好看？採用了很多新技術？體現了設計師的高明手段和淵博知識？NONONO！設計的目的是爲了實現需求不是嗎？如果需求就是這樣簡單，我們已經實現了，還能不動腦子，幹嘛做那沒事找抽型的，老闆又不因此少付一分錢工資，能少乾點活兒不好嗎？很多設計師因爲懂得幾個設計模式，總要想方設法弄上去，把簡單的問題弄複雜，好象只有這樣才能體現他的價值。愛因斯坦說宇宙的法則是簡潔的纔是最美的，設計也是如此。設計師的真正價值，是用最簡單，最好懂，最簡潔的設計完成最複雜的要求，而不是相反！一項技術，正因爲能夠被大多數人掌握才能流行，否則就只能呆在實驗室裏，不是嗎？
話扯遠了，忍不住又抨擊了一下過度設計，很不幸被抨擊的對象也包括以前的自己^_^。好吧好吧，我知道盡管你會同意我的話，你還是會在心裏嘀咕，如果設計就只有這一點東西，連腦子都不用動，那設計師也太好乾了吧？分析模型如果就只有這一點內容，還要專門寫個系列文章，這個作者也是個欺世盜名的吧？
呵呵，爲了撫平你的失望，我告訴你。之所以我們沒動腦子，是因爲系統分析員們經過用例分析系列中的卓越工作，給我們打下了如此堅實的基礎，才使得我們的工作簡單到了不用動腦子的地步。你還得感謝UML用一套很好的方法，讓你可以輕而易舉的從需求轉化到類設計。你已經站在巨人的肩膀上了，所以就一邊兒偷着樂吧。
樂完了還得回到現實。在很多情況下，事情並沒有這麼簡單。這個粗糙的分析模型雖然可以工作，但的確有很多可以優化的地方。不用擔心你會因爲做了一份簡單而不用動腦子的工作而失去飯碗。因爲下一篇，我們將會討論怎麼樣，從哪些方面，以及如何依據補充規約，系統架構以及維護要求等來優化和調整這個模型。這下設計師有用武之地了，學習到的知識和積累的經驗要發揮作用了，失落的自我價值也能體現了。爲了證明設計師不是混吃喝的並且保住飯碗，敬請期待下篇，分析模型的優化和調整。
*********************************************************
作者coffeewoo 歡迎您訪問文章原始出處 : http://coffeewoo.itpub.net，閱讀中有任何問題可以在BLOG上留言或發郵件到 [email protected]，我將盡力爲您解答。具有代表性的問題我會以 Q &A的形式收錄到對應的文章之後。希望本系列文章對您有幫助。歡迎轉載，敬請註明，謝謝 ^_^