所以我非常同意高先生的全程建模思想，我最近也產生了一些類似的構想。我希望理想的設計工具如下：一：歸納各軟件開發階段的問題，和解決問題的方法和技巧，指導性地分析設計。二：有層次，有聯系的表達各階段，各模塊，各對象等元素的構成。三：和代碼保持同步。即設計到代碼的正反向功能。 ... 我的Mail:kmbaojun@msn.com 歡迎討論
zy422 (2002-6-11 10:15:19)
我是一個有個編程經驗多年的人，我也用 ROSE 來設計個一些東西，但我感覺到 ROSE 在給程序員一個交代時做得很不夠，應為程序員最關心的是這個函數要做什么事、怎么在這個函數里做，函數里到底要使用到設計的那些類和函數，這 ROSE 實在是做得不好，所以現在我們公司里的程序員一般都不看 ROSE 圖，靠和設計人員直接交流來完成對設計要求的認識。我希望 ROSE 在以后的版本中能做一些好的，能和程序員交流的工具或表達視圖。 UML 還有很長的一段路要走，我真正用好了的只有類設計，其他的我實在是用不好了。 我個人的觀點，實用的就是好的，管它是面向對象還是面向過程，關鍵是要大家都用，都能夠用好,多能方便的使用。對于 UML 我認為它站得太高了，現在很多人都還不能用好。
gale (2002-6-7 14:38:57)
3boy說的不錯，但離題了，希望不是槍手，更不要顧左右而言它讓我們重新看一下問題,作者說的是：UML的三大硬傷拋開工具，考慮一下思路這個UML三大硬傷的認識是錯誤的，理由我在前面的貼子已經描述過了我希望大家能就這“三大硬傷”提出意見，而不要偏離主旨 1,再駁“上不著天” 有什么形式化的方法能對問題域進行信息無損的描述？？？理論上還沒有，目前走在業界前面的，是國際標準的，就是UML了 XX建模方法我不熟悉，沒有發言權，但....這個不是國際標準 2，再駁“下不著地” XX建模方法有類和對象級的表達語法嗎？反正在這篇文章里沒有看到哎，我也不行，做不出自己的建模方法來，我“五十步笑百步” 3，再駁“一盤散沙” 昨日在《程序員》上拜讀了高先生的《XX建模方法》不用我說，各位明眼的人就能看的出哪種方法的形式化推導關系更嚴密了
3boy (2002-6-7 9:31:32)
我覺的以上的言論太過偏激了，火藥味太過于濃厚了，軟件分析的目的是為了讓大家都弄明白一個目的，那就是 “你該做什么？你要做什么？或則你要其別人做什么？”，而所謂的Rational產品，以及高先生的Playcase包括其它的一些建模工具都充其量和word差不多，只不過使用方便一些而已，“人”的因數還是最重要的，這就是對系統分析設計人員的素質要求。我覺的我們不能“神話”建模工具，而忽略了人，即使我們沒有好的“畫圖”工具只要有人在，我們甚至可以“手繪”全部工作流，以上的爭論好像就在討論“畫圖板”的優劣，而不是在探討軟件工程真正的要旨，我覺的應該討論的是“如何讓大家都明白，你要做什么，我能為你做什么，你有些什么可以為我而提供的，你是這樣的嗎？。。。。�！� 軟件工程是一個不確定標準的學科，不確定的原由是，每個人都有自己的主張，不管主張的好壞，至少要知道你在為誰分析，你的對象是如何的，如果你畫的東西別人都不理解，或者他們要花費很大的代價去理解，我認為那就是失敗的方法，那么我們就必須尋求其他的途徑去讓人理解。 “我的三大忠告” 1、“條條大路通羅馬” 2、“能解決問題的方法才是好方法” 3、“好的畫家，即使沒有豐富的顏料，和優良的畫筆，依舊可以做出優秀的傳世之作”
3boy (2002-6-7 9:26:54)
文章來源于領測軟件測試網 http://www.kjueaiud.com/
