andy2ray (2002-5-17 21:44:20)
UML三位大師開宗明義，UML是一種語言，而不是方法，因此他本身不提供軟件開發的過程指導。如果你不清楚或想獲得在軟件開發上的過程指導，可以參考RUP。這點不知高先生是否注意到？
111222 (2002-5-17 15:41:31)
寫的很好，UML本來就是垃圾！
enlightenment (2002-5-17 15:22:06)
有句話是對的：盡信XX則不如無XX！
wuhan_wanhui (2002-5-17 14:14:50)
UML”三大硬傷”之我見 2002年第5期高展先生的文章《UML“三大硬傷“》以管理軟件為實例，闡述了UML的三大硬傷，敘述的十分精彩。軟件開發過程中的一些問題都被高先生提出，使我受益匪淺。但是高先生的許多觀點，我不敢茍同。 UML是一種建模語言，語言是來供人們來交流，也就是供不同領域的人來交流的一個標準，就好像世界語。因此UML不是一種方法，UML建模和軟件開發過程是兩個不同的概念。UML適用于很多重軟件開發過程。因此高先生有把用UML建模的軟件開發過程和UML混淆的嫌疑，把軟件開發過程中出現的硬傷歸于UML，實屬誤解。 “上不著天”論。文中說，“建模結果無法于用戶溝通確認所謂的需求”，“用戶專家無法理解UML所描述的業務流程”。實際上業務流程是很細致的，以前我們用系統流程圖直接處理這些業務流程，用戶專家能得到很好的溝通。而現在用UML來描述業務流程，是不是有點趕時髦的嫌疑？軟件開發過程中的問題并不是UML建模都能解決的，可以這么說用UML來描述業務流程曲解了建模的本義。三位大師的著作《UML參考手冊》中說道，“模型從某一個建模觀點出發，抓住事物最重要的方面而簡化或忽略其他方面”，“ U M L是一個建模型語言，不是對開發過程的細節進行描述的工具”�？梢娊Ｊ且リP鍵和重要的東西，高展先生文中說到，“UML難以從宏觀把控業務流程的完整與準確”，并舉了UML不能描述到原子級工作步驟，這與建模的思想是相違背的，建模需要的只是到關鍵的一定層次（如文中所述的職責級），而不是詳細的細枝末節�？梢哉f這正是UML的精華之處，只關注重要和關鍵而不關心細節。詳細的細節問題屬于軟件開發過程中的問題。 “下不著地”論。建模只是建立了一個模型，至于具體的詳細設計、編碼當然需要程序員去理解和思想。試想，模型和詳細設計之間不存在這個隔閡的話，從事詳細設計的軟件藍領都不要下崗了？UML存在的意義在于作為一種通用的建模語言，提供了一種建模者之間交流的標準，這當然也適用于上游的分析員和下游程序員之間的交流。UML其實也向下著地，著于這種相互之間的交流上。從模型轉換到程序代碼屬于case工具的范疇，并不能說是UML的硬傷。再說現在Rational Rose對于模型到代碼的轉換工作已經取得令人驚喜的效果。
dearmite (2002-5-17 11:31:19)
看了這么多，想寫點什么，其實我這兩種工具都沒用過，ROSE只是聽說，不過，沒下過雞蛋，總還見過，別人用的時候，唉，我總是很羨慕！為什么？不是UML多么高、多么好，也不是他那東西真的能轉換多少價值， 因為他開的錢比我多！我們學這些、那些建模做什么，不是做事業，我們是為了錢！ 從文章的受益度講，從文章的深度講，我想這一點，高先生一定是最高分！ 但是問題是為什么IBM的OS/2沒有比過MICROSOFT的Windows呢，因為市場！如果是我，boss讓我又做建模，又做程序，那我一定不用UML，用高先生的東西沒錯！因為一切為了實用嘛， 但是問題是，建模的人不寫代碼，寫代碼的人不建模，建模的人把關系搞好就能弄到錢，你的程序多好，你的公司通過cmm,但是你賣的程序真的用了CMM了么，不是！，都是為了多掙一點錢罷了，所以我只能以心靈上贊助高先生，如果我要學，我還是要學UML，因為這就是錢！全程建模大家一看就懂，那還了得，客戶還能買單？他不懂就對了，這就是UML的最最高明之處！
文章來源于領測軟件測試網 http://www.kjueaiud.com/
