建模的誤區—— 走出一般性的設計誤區，邁向成功之途

建模的誤區—— 走出一般性的設計誤區，邁向成功之途  uml模型

關鍵字：設計誤區無論你遵從的是重量級的方法,比如Enterprise Unified Process(EUP)，還是輕量級的開發過程，如Extreme Programming(XP)，建模在軟件開發中都是不可或缺的。但不幸的是其中充斥著各種謬誤與迷思。 
這來自于各個方面，有從理論家錯誤的研究、數十年來信息技術領域內的文化沉積、軟件工具開發商天花亂墜半的市場宣傳以及象Object Management Group (OMG)和IEEE這類組織的標準。這個月，我要揭示建模中 的誤區，指出其相應的事實真相。 


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

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


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


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

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

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


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

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