九大UML建模誤區如何避免(2)

　　比如，我經常使用UML建立模型來表示類、它們的屬性及一些關鍵的業務操作，但并不畫出屬性的存取操作(get和set)，以及維護與其它類關系的框架代碼，或者其他一些瑣碎的實現細節。我通過建模尋找解決問題的方法，讓我和我的同事能繼續前進去實現這個模型。以這樣靈活的方式，大多數情況下我并不需要一個CASE工具來支持建模工作，一塊白板，或者一臺數字相機足以。這樣，我就不用花時間去評估CASE工具，不用去和工具供應商討論許可證的問題，也免去了人員培訓開銷。CASE工具只有當它能體現最佳性價比時(相對你自己的情況而言)，才值得購買。大多數情況下，我都能不用它而達到目的(完成建模)。我經常使用的工具有Together/J(http://www.togethersoft.com/)–因為它能產生數目可觀的Java框架代碼;還有ERWin(http://www.cai.com/)--因為它能規劃數據庫。這兩個工具真正地幫助我實現了軟件開發的目的–制造滿足用戶要求的軟件。但我絕大多數得建模工作仍然使用的是簡單的工具，而不是CASE工具。

　　UML建模誤區七：建模是在浪費時間

　　許多新手都這樣認為，這主要是因為他們所接受的教育僅僅局限于如何編寫代碼，對于完整的開發流程鮮有接觸。而且他們的經驗也僅限于如何實現代碼，就如初級程序員。他們放棄了提高效率和學習技能的機會，這些技能能夠使他們很容易地適應不同的項目或組織。他們應該為此感到羞愧。

　　事實分析：在大多數情況下，在開始編碼之前畫一個草圖、開發一個粗率的原型或者制作一些索引卡片都能提高你的生產效率。高效的開發者在編碼之前都要進行建模工作。另外，建模是一種很好的在項目組成員與項目負責人之間溝通途徑。你們在這個過程中探討問題，從而對所要的是一個什么樣的東西可以得到更好的理解，涉及到該項目中的每個成員也可得到對該項目有一個從分的了解。

　　UML建模誤區八：數據模型(DataModel)就是一切

　　許多組織基于數據模型就蹣跚啟動新的開發工作，也許正如你所在的組織：IT部門對于數據有非常嚴格的規定，控制著你的開發項目;或者你以前的數據庫是一團糟，別無選擇。

　　事實分析：數據模型是一個重要的但不是最重要的建模，它最好是建立在另外的模型之上。(參見“ExtremeModeling”，ThinkingObjectively，Nov.2000)。這即使在象數據倉庫這類面向數據的項目中也如此。如果沒有很好的理解用戶是如何使用該數據倉庫的(在數據模型中沒有表示出來)，這些項目經常是以可悲的失敗而告終。你可以使用的模型有很多–使用案例(usecases)，業務規則(businessrules)，activitydiagrams，類圖(classdiagrams)，componentdiagrams，用戶界面流程圖(userinterfaceflowdiagrams)和CRC，等等。數據模型僅僅是其中的一種。每種模型都有其長處和短處，應該正確地使用。

　　UML建模誤區九：所有的開發人員都知道如何建模

　　我們現在面臨照這樣一個嚴重的問題：許多不是開發人員的人，包括高級經理和用戶，不知道軟件是如何建成的。其結果，他們不能夠區分開熟練的開發者和一般的程序員(當然也分不清高級程序員和一般程序員)，他們想當然地認為所有的開發人員都具備從頭到尾開發整個系統的技能。

　　事實分析：這肯定是不正確的。建模的技能，是只有當一個開發者通過學習它，并經過長期的實踐才能夠掌握。一些非常聰明的程序員常常相信自己無所不能，畢竟他們終究只是程序員。正因為這樣的狂妄自大，他們承當的一些任務是他們根本就沒有相應的技能去完成的。軟件開發是如此的復雜，單單一個人是很難具備所有的技能去成功地進行開發，甚至也不可能去配置有一定復雜程度的系統。開發這應該有自知之明，明白他們自己的弱點，學無止境。通過互相取長補短，建模者可從程序員身上學到一項技術的具體細節，程序員也可從建模者那里學到有價值的設計和體系結構的技術。我個人認為所有的人，包括我自己，都是新手。

　　AgileModeling

　　通過理解和避開建模的誤區，你能夠是得你自己、你的項目組和你的組織更加有效地進行軟件開發。在揭示這些普遍存在誤區的過程中，我已經表述了AgileModeling(AM)的許多原則。AgileModeling以前叫做ExtremeModeling(XM)。我希望我所給于你的是精神上的食糧。

原文轉自：http://www.anti-gravitydesign.com