maxsuy (2002-5-18 19:17:38)
作者的人品確實存在問題。 PLAYCASE我用過，我承認國內的公司能弄出這么一個東西確實不容易，可是你也犯不著這么咒罵UML吧。 PLAYCASE那玩意純熟垃圾。做出設計來到最后呢，還是沒有用。放廁所里都嫌PLAYCASE臭。
pattern (2002-5-18 19:07:48)
作為一個又搞分析，又編碼的軟件工程師（存在于大多數有中國特色的軟件公司）。有一條經驗應該銘記在心：不要指望可以完全掌握用戶的需求，大多情況下，業務領域專家也無法給你一個細化到原子級的需求。所以，才有object-oriented 軟件工程的出現，才有增量開發方法，才有敏捷建模，這些都是告訴我們要順應人的思維習慣，漸進開發，逐步挖掘需求，層次建模。軟件工程與建筑工程有很多共通點，但他們有一個根本的不同就是：軟件最終是可以被修改的，但你不會為一個不很合理的自動扶梯設計而修改造好的大樓，只能將就著用。所以建筑工程的需求可以被認為是確定的，而軟件則是相反。
whack (2002-5-17 23:53:21)
呵呵，弄了半天才是一個軟件的作者在說自己的軟件比別人的好，怪不得口氣和論述都是說得那么具有商業的味道。那我們也不妨來看看文中的幾個技術的例子： 1。面向對象開發中和用戶交流的關鍵描述工具是use case圖。所以一個工具在這個階段對用戶最重要的就是構造use case描述（必要地時候也需要對一些重要的類或者包，以及相關的一些交互細節做某種程度的描述），通常component的構造細節在和用戶交流過程中通常用到得很少。 那么use case圖作者會怎么描述呢？從文章中的對一個需求的建模結果看，也是類似的一系列圖形和符號描述方式，但是不同的是在作者的表達方式和uml有所不同，更重要的是作者列舉自己的建模圖例和uml的圖例的時候，設計的程度是不一樣的，作者的建模圖例其實是uml中的“靜態圖（類，包等）+ 一些usecase + 一些時序圖（或者順序圖）”，也就是說作者的圖形里面其實是夾雜了uml中的好幾種圖形（當然是把uml的描述方式有所簡化和變化），但是在列舉uml的設計圖形的時候，卻缺少了類的動態成分的表達（也就是方法及其順序），但是在uml中有很多的圖可以更進一步細化類或者包的設計（序列圖，交互圖，conponent圖等）。 這反映了作者對于面向對象系統描述的理解不同，uml之所以把幾種圖形分別描述，一是當需求比較復雜的時候，幾種圖加在一起的方式可能會變得無法描述，因為一張圖形可能變得已經畫不下來了。二是uml的方式認為系統具有一系列的特性，不同的特性需要有專門的方式來分別描述。圖形多看不過來，但是混合在一起，如果描述同樣的細節程度，恐怕還是很長。 2。對于微觀設計，那就要看是系統分析階段還是系統開發了。系統分析的時候做很多細節，有必要嗎？本來系統開發就是有很多細節要到系統實現階段來進行的。而且同樣的，對于任何一個小模塊，同樣地畫出component 圖，序列圖，交互圖（只不過粒度不同），想不出來這時候為什么不可以編碼？所謂的偽代碼不就是一種這些圖形的文字描述方式嗎？在描述留成的時候，其本質上是同構的（只不過偽代碼是結構化的流程圖方式來描述類或者方法的關系）。 3。實在弄不懂作者遺漏用戶需求的意思，遺漏了用戶功能是系統分析沒做完的問題，和怎么描述實在聯系不上。作者在某個流程上加了個注解，這是解決方法��？ 4。作者認為uml中間的好幾種圖形和某些元素無關，或者不能轉化為邏輯語句。這就是對uml的語法的理解問題了。這些圖形用系統工具現在都可以直接生成c++或者java代碼，那么語法轉化還需要什么。 5。uml的描述方法里面還存在著某些復雜性或者戎余，包括rose工具對于某些圖形的構造方法也存在著需要改進的部分，這些不用多討論了，只要是軟件或者標準，都是在不斷進行版本修訂中。 看了一下原文我怎么有點兒懷疑作者到底用uml做了多少項目，如果是為了宣傳產品，沒有必要做那些并不特別的例子，有些例子就只有一個自己的分析結果，就來了個結論。要知道很多在編碼過程中好像很“好看”的東西，構造成一個產品后，就成了一堆不能維護的零件了。大家都用自己“喜歡”的，結果卻往往是不能用的。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
