"UML 沒有排斥任何特殊的軟件開發方法或過程；它只不過標準化了標記法的格式。"Granville Miller 語不是UML的問題。是開發者對面向對象的方法掌握的問題。高先生的方法是可能是一種好方法。但你應弄清楚你只是其中的一種。不要弄不清楚問題的實質就大貶一通。我覺得你說的三個發面都不對！ 1“上不著天”這種隔閡使建模結果無法與用戶溝通確認所謂的需求，埋下了軟件危機的禍根； USE CASE 圖是一種很好的用來表達用戶需求的工具。何以“上不著天”？ 2“下不著地”這種隔閡使千辛萬苦得到的建模結果無法指揮程序員編碼，最后得到的軟件與用戶期望的結果很遠，返工、誤工、煩惱無窮； CLASS 圖是程序編寫的圖紙�？粗涂梢詠韺懘a。coder 們不需要了解設計的全部就可以施工。何以“下不著地”？ 3“一盤散沙”這種隔閡讓建模圖形之間的關系凌亂不堪，建模過程千辛萬苦，建模結果很難自圓其說。目前在 UML 規范中有九種圖。重不同的視角反映需求。你的設計“一盤散沙”。UML有何罪之有？ 高先生你認真對待你的“驚世”高論。您是一位學者�。。。。。�！
elkel (2002-5-19 19:31:36)
真好笑，作者根本不懂UML，拿著Rose胡畫，還對UML妄加評論。惡心... 本人忍受胃痙攣的痛苦，讀完此文。力圖修正作者使用UML的錯誤，提醒初學者不要象他一樣胡畫。（其實我也是初學者:)）對于Playcase，我沒用過，不敢妄加評論，以免犯與作者一樣的錯誤。但我可以確定我今生今世都不會用它。 西門吹雪忽然道：“你學劍?” 葉孤城道：“我就是劍�！� 西門吹雪道：“你知不知道劍的精義何在?” 葉孤城道：“你說�！� 西門吹雪道：“在于誠。 葉孤城道：“誠?” 西門吹雪道：“唯有誠心正義，才能到達劍術的顛峰，不誠的人，根本不足論劍�！� 好，現在開始切入正題 1. 圖3，作者應該畫的是用例圖吧。首先，用例圖不能用來描述企業的組織結構。其次，作者用包來表示企業和部門是胡畫，包在C++和java中分別映射為namespace和package。另外，作者用用例表示職責，算沾了一點邊，但是這仍然是錯誤的，用例應該代表業務過程中角色的行為。作者所提的“不能直觀地將職責展開為步驟”，應該用協作圖表示。以作者的觀點看來，建模是以企業組織結構為中心，而UML的觀點是以業務為中心。以企業組織結構為中心，就要根據企業組織結構建立業務流，以業務為中心，企業組織結構要適應業務流程。哪個合理，很明顯。（扯的太遠了） 2. 圖5，作者的目的是描述業務流程嗎？那么請用協作圖吧，雖然順序圖和協作圖可以互相轉換，但它們是有區別的，順序圖是針對開發人員的，協作圖才是針對領域專家的。 3. 圖6，作者畫了泳道吧？胡畫��！角色的職責應該在這里表現，每一個泳道應屬于一個角色，泳道內的活動就是角色的職責。這是活動圖嗎？起始和結束點在哪呢？ 作者提出的UML三大硬傷，更本不能成立，作者根本不懂UML。
grantguo (2002-5-19 14:59:52)
還是那句話：沒有銀彈。。。。軟件開發過程中沒有銀彈 啊。
kendy_yin (2002-5-19 11:24:16)
其實你未必要去評論uml的好壞，就象linux的愛好者去說windows的壞話一樣。如果你的產品真的好地話，時間可以證明一切的。覺得還是多花點心事集他人之長，補己之短吧。希望能見到你更好的產品。其實我都不知道作者是寫什么的，從上面評論看，你是不是playcase的作者呀？
文章來源于領測軟件測試網 http://www.kjueaiud.com/
