在學習UML的過程中經常會遇到UML建模誤區問題，這里和大家討論一下，無論你遵從的是重量級的方法,比如EnterpriseUnifiedProcess(EUP)，還是輕量級的開發過程，如ExtremeProgramming(XP)，UML建模在軟件開發中都是不可或缺的。

UML建模的誤區

通過理解和避開UML建模的誤區，你能夠是得你自己、你的項目組和你的組織更加有效地進行軟件開發。在揭示這些普遍存在誤區的過程中，我已經表述了AgileModeling(AM)的許多原則。AgileModeling以前叫做ExtremeModeling(XM)。我希望我所給于你的是精神上的食糧。
--------------------------------------------------------------------------------
無論你遵從的是重量級的方法,比如EnterpriseUnifiedProcess(EUP)，還是輕量級的開發過程，如ExtremeProgramming(XP)，UML建模在軟件開發中都是不可或缺的。但不幸的是其中充斥著各種謬誤與迷思。這來自于各個方面，有從理論家錯誤的研究、數十年來信息技術領域內的文化沉積、軟件工具開發商天花亂墜半的市場宣傳以及象ObjectManagementGroup(OMG)和IEEE這類組織的標準。這個月，我要揭示UML建模中的誤區，指出其相應的事實真相。

誤區一：UML建模就等于是寫文檔

這很可能是其中***破壞力的一條，因為開發人員可以此為借口而完全放棄UML建模。許多優秀的軟件開發人員會說他們不想把時間浪費在這些“無用的“文檔上。他們沉溺于編碼之中，制造著一些脆弱而劣質的系統。另外，甚至于許多盡責的開發人員現在也認為UML建模是一件討厭的事，而不愿去學習相應的UML建模技術。

事實分析：“模型”與“文檔”這二者在概念上是風馬牛不相及的—你可以擁有一個不是文檔的模型和不是模型的文檔。一幅設計圖就是一個模型，而不論是被畫在餐巾紙的背面，或寫在一塊白板上，或在ClassResponsibilityCollaboration(CRC)卡片中，還是根據記錄在報紙和便簽紙上的流程圖而生成的一個粗略的用戶界面原型。雖然這些都不能說是文檔，但他們卻都是有價值的模型。

UML建模很象是作計劃：作計劃的價值在于計劃編制的過程中，而非計劃本身；價值體現在UML建模的活動中，而非模型本身。實際上，模型不是你系統中的一部分正式的文檔，而且在完成它們的使命后可以被丟掉。你會發現值得保留的只有很少的模型，而且它一定是非常***。

誤區二：從開始階段你可以考慮到所有的一切

這種說法流行于二十世紀七十年代到八十年代早期，現今的許多經理都是在那個時候學習的軟件開發。對這一點的迷信會導致在前期投入可觀的時間去對所有的一切UML建模以期把所有一切都弄正確，試圖在編碼開始前就“凍結”所有的需求（見誤區四），以致于患上“分析期麻痹癥”–要等到模型非常***之后才敢向前進。基于這個觀點，項目組開發了大量的文檔，而不是他們真正想要得到的—開發滿足需要的軟件。

事實分析：怎么才能走出這個誤區呢？首先，你必須認識到你不能考慮到所有的細枝末節。第二，認識到編碼員可能會對UML建模者的工作不以為然（這是可能的，事實上UML建模者所作的工作在實際價值中只占很少的部分），他們或許會說模型沒有反應出真實的情況。第三，認識到不管你的最初所作的規格說明書有多好，但注定代碼會很快地與之失去同步，即便是你自己UML建模自己編碼。一個基本的道理就是代碼永遠只會和代碼保持一致。第四，認識到迭代法（小規模地UML建模，編一些代碼，做一些測試，可能還會做一個小的工作版本）是軟件開發的準則。它是現代重量級的軟件開發過程（如EUP），以及輕量級（如XP)的基本原理。

誤區三：UML建模意味著需要一個重量級的軟件開發過程

走入這個誤區（經常與誤區一有聯系）的項目組常常是連UML建模都徹底地放棄了，應為這樣的軟件開發過程對他們來說太復雜太沉重了。這不亞于一場天災。

事實分析：你可以用一種敏捷的方式取而代之。關于用簡單的工具進行簡單地UML建模的詳細內容可參看AgileModeling(AM)。而且，你可以丟棄你的模型當使命完之后，同樣也可以很基本的方式進行UML建模（比如，從辦公桌起來，來到白板前就開始構略草圖）。只要你愿意，你就可以輕松地UML建模。

誤區四：必須“凍結”需求

這個要求常常來自高級經理，他們確切地想知道他們從這個項目組能得到什么東西。這樣的好處就是在開發周期的早期確定下需求，就可以確切地知道所要的是一個什么樣的東西；缺點就是他們可能沒有得到實際上所需要的（不全或錯誤的需求，譯者）。

事實分析：變化總會發生的。由于優先級的變化和逐漸對系統有了更進一步的理解，都會引起需求的變化。與凍結需求相反，估計項目成功的風險，盡量去接受變化而且相應地采取行動，就象XP所建議的一樣。

誤區五：設計是不可更改的

如同誤區四，要求每一個開發人員必須嚴格遵從“設計“，導致開發人員為了符合“設計“而作了錯誤的事情或以錯誤的方式作正確的事情。或者是簡單地忽略了設計，否定了所有設計可能帶來的好處。凍結了設計，你就不能從在項目進程中所學到知識進一步獲益。另外一個很大的趨勢就是開發出大量的文檔而不是實際的軟件，使用面向文檔的CASE工具而不是能給項目帶來實際價值的面向應用的工具。

事實分析：事實上，設計會經常根據開發人員和數據庫管理員的反饋進行修改，因為他們是最接近實際應用的人，通常他們對技術環境的理解要好于UML建模者。我們必須的面對這樣一個事實：人無完人，他們所作的工作也不可能盡善盡美。難道您真的想將一個并不完善的設計固定下來而不再去修改其中的錯誤嗎？另外，如果需求并沒有被凍結，其實就意味著你不能凍結你的設計，因為任何需求的修改勢必影響設計。對之，正確的態度是：只要你的代碼還在改動，涉及就沒完。
 

【編輯推薦】

1. UML建模基礎 UML類圖的組成元素和關系解析
2. 選擇UML建模工具的幾個標準
3. 技術分享 解析圖書管理系統的UML建模分析與設計
4. 學習筆記 UML建模的要點總結
5. 經驗總結 選擇一種***UML建模工具的標準