建模的誤區

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

誤區六：必須使用CASE工具

建模常常被認為是一項複雜的工作，因此需要大量地使用CASE工具輔助進行。

事實分析：是的，建模可以是很複雜的。但你完全可以建立一個有效而簡單的模型表述其中關鍵的資訊，而不是將一些無關緊要的細節包括進來。

比如，我經常使用UML建立模型來表示類、它們的屬性及一些關鍵的業務操作，但並不畫出屬性的存取操作(get和set)，以及維護與其它類別關係的架構代碼，或者其他一些瑣碎的實現細節。我通過建模尋找解決問題的方法，讓我和我的同事能繼續前進去實現這個模型。以這樣靈活的方式，大多數情況下我並不需要一個CASE工具來支援建模工作，一塊白板，或者一台數位相機足以。這樣，我就不用花時間去評估CASE工具，不用去和工具供應商討論許可證的問題，也免去了人員培訓開銷。CASE工具只有當它能體現最佳性價比時（相對你自己的情況而言），才值得購買。大多數情況下，我都能不用它而達到目的（完成建模）。我經常使用的工具有Rose 和Visio ；還有PowerDesigner。這兩個工具真正地協助我實現了軟體開發的目的 – 製造滿足使用者要求的軟體。但我絕大多數得建模工作仍然使用的是簡單的工具，而不是CASE工具。

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

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

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

誤區八：資料模型(Data Model)就是一切

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

事實分析：資料模型是一個重要的但不是最重要的建模，它最好是建立在另外的模型之上。（參見“Extreme Modeling”，Thinking Objectively，Nov.2000）。這即使在象資料倉儲這類面向資料的項目中也如此。如果沒有很好的理解使用者是如何使用該資料倉儲的（在資料模型中沒有表示出來），這些項目經常是以可悲的失敗而告終。你可以使用的模型有很多 – 使用案例（use cases），商務規則（business rules），activity diagrams，類圖（class diagrams），component diagrams，使用者介面流程圖（user interface flow diagrams）和CRC，等等。資料模型僅僅是其中的一種。每種模型都有其長處和短處，應該正確地使用。

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

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

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

Agile Modeling

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

建模十條原則

僅有資料模型對於現代軟體是不夠的。
接收變化，並且允許你的模型能夠隨著時間進行改進。 你不能凍結它們，然後就期待著成功。
模型並不一定就是文檔，文檔也不一定就是模型。
大多數的模型可能也應該被丟棄。
只有代碼才能與代碼保持真正的同步。
一些簡單的工具，比如白板，就完全足以應付大多數得建模工作。
思考，然後再編碼。
你總能從別人身上學到東西。
建模可以用一種輕盈的方式。
設計直到代碼發布以後才算完成。