發信人: wym (Evan), 信區: SoftEng
標 題: 建模的誤區
發信站: BBS 水木清華站 (Thu Jun 12 10:05:00 2003), 轉信
【以下文字轉載自中文JAVA技術網】
【原文地址http://www.cn-java.com/target/news.php?news_id=1479】
建模的誤區
出處 http://www.sdmagazine.com/documents/s=844/sdm0108k/0108k.htm
[中文JAVA技術網 2002-04-01]
http://www.sdmagazine.com/documents/s=844/sdm0108k/0108k.htm
無論你遵從的是重量級的方法,比如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工具
只有當它能體現最佳性價比時（相 對你自己的情況而言），才值得購買。大多數情
況下，我都能不用它而達到目的（完成建模）。我經常使用 的工具有Together/J(http
://www.togethersoft.com/) – 因爲它能產生數目可觀的Java框架代碼；還有ERWin
（http://www.cai.com/） -- 因爲它能規劃數據庫。這兩個工具真正地幫助我實現
了軟件開發的目的 – 製造滿足用戶要求的軟件。但我絕大多數得建模工作仍然使用
的是簡單的工具，而不是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
(AM)的許多原則。Agile Modeling 以前叫做 Extreme Modeling(XM)。我希望我所給
於你的是精神上的食糧。
在此我要感謝Blueprint Technologies（http://www.blueprinttech.com）的Doug
Smith，Evanetics （http://www.evanetics.com）的Gary Evans，以及在Agile Modeling
郵件列表（可訪問 http://www.agilemodeling.com加入）中對本文做出貢獻的人們
。我同樣要感謝Martin Fowler，Ron Jeffries和其他一些XP社區中成員，因爲我想
我已經融入了一些他們的觀點。
建模十條原則
僅有數據模型對於現代軟件是不夠的。
接收變化，並且允許你的模型能夠隨着時間進行改進。 你不能凍結它們，然後就期
待着成功。
模型並不一定就是文檔，文檔也不一定就是模型。
大多數的模型可能也應該被丟棄。
只有代碼才能與代碼保持真正的同步。
一些簡單的工具，比如白板，就完全足以應付大多數建模工作。
思考，然後再編碼。
你總能從別人身上學到東西。
建模可以用一種輕盈的方式。
設計直到代碼發佈以後纔算完成。
※ 來源:·BBS 水木清華站 smth.org·[FROM: 210.42.103.200]
標 題: 建模的誤區
發信站: BBS 水木清華站 (Thu Jun 12 10:05:00 2003), 轉信
【以下文字轉載自中文JAVA技術網】
【原文地址http://www.cn-java.com/target/news.php?news_id=1479】
建模的誤區
出處 http://www.sdmagazine.com/documents/s=844/sdm0108k/0108k.htm
[中文JAVA技術網 2002-04-01]
http://www.sdmagazine.com/documents/s=844/sdm0108k/0108k.htm
無論你遵從的是重量級的方法,比如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工具
只有當它能體現最佳性價比時（相 對你自己的情況而言），才值得購買。大多數情
況下，我都能不用它而達到目的（完成建模）。我經常使用 的工具有Together/J(http
://www.togethersoft.com/) – 因爲它能產生數目可觀的Java框架代碼；還有ERWin
（http://www.cai.com/） -- 因爲它能規劃數據庫。這兩個工具真正地幫助我實現
了軟件開發的目的 – 製造滿足用戶要求的軟件。但我絕大多數得建模工作仍然使用
的是簡單的工具，而不是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
(AM)的許多原則。Agile Modeling 以前叫做 Extreme Modeling(XM)。我希望我所給
於你的是精神上的食糧。
在此我要感謝Blueprint Technologies（http://www.blueprinttech.com）的Doug
Smith，Evanetics （http://www.evanetics.com）的Gary Evans，以及在Agile Modeling
郵件列表（可訪問 http://www.agilemodeling.com加入）中對本文做出貢獻的人們
。我同樣要感謝Martin Fowler，Ron Jeffries和其他一些XP社區中成員，因爲我想
我已經融入了一些他們的觀點。
建模十條原則
僅有數據模型對於現代軟件是不夠的。
接收變化，並且允許你的模型能夠隨着時間進行改進。 你不能凍結它們，然後就期
待着成功。
模型並不一定就是文檔，文檔也不一定就是模型。
大多數的模型可能也應該被丟棄。
只有代碼才能與代碼保持真正的同步。
一些簡單的工具，比如白板，就完全足以應付大多數建模工作。
思考，然後再編碼。
你總能從別人身上學到東西。
建模可以用一種輕盈的方式。
設計直到代碼發佈以後纔算完成。
※ 來源:·BBS 水木清華站 smth.org·[FROM: 210.42.103.200]
