washine (2002-5-16 20:39:35)
什么是好的建模工具？我認為其本身有多精辟或有多深奧并不重要，重要的是是否簡單易懂。 為什么要建模呢？就是要越來越生動，便于理解，說得難聽點，最好讓傻瓜也一看就懂。 建模是給誰看的呢？并不是給軟件設計者和項目經理看的，它是連接開發人員和客戶的橋梁。 成功的建模應該具備極強的溝通能力及連貫性，條理清晰且容易接受。在這一點上UML明顯先天不足（說老實話有很多程序員都看不懂更別說客戶了）。從某種意義上說UML過于專業，熟悉面向對象的軟件設計師或許能體會它的精妙，但從一般的客戶及普通程序員來講，他們需要的是一個生動的模型，而這個模型或許并不是UML。 國人有能力有魄力推出有價值的東西，我們為何不站出來給予支持呢？哪怕它僅有一個優點，也勝過一味地跟隨。全程建模有他的可取之處，肯定也有許多不足之處（比如不夠面向對象），但一般人（包括不懂設計的程序員）卻更容易看懂它。我們要討論的不是要用誰，摒棄誰，而是哪種方法更適合項目開發，給出更佳的效率。對任何事物都不要一棍子打死，難道就不能讓它們共存么？
wangqiyy (2002-5-16 17:17:45)
各打50大板！ 1、人無完人，金無足赤。每一種軟件工程方法都有其獨到的特點和所要解決的問題，UML的方法著重業務模型的建立，而I2DEF的全程建模的思想確實不錯，對于工具Rose和Playcase我都接觸過。我認為UML主要在描述做什么，逐步逐步提升到怎么做，最后到內部的類，最后編程實現；而I2DEF的感覺就像是崗位責任書，每個角色各司其職，所有的責任和角色組成整個業務。如果單單使用某一表示方法，我還沒有聽說哪家公司成功過，例如Rational自己，它就有一系列產品（像什么Request之類的工具）支持，只有把這些都用上了，才有可能是解決軟件工程問題的方法，而單獨使用都是有缺陷的，Rose內部也是建議使用大量的文檔嵌入來描述其細節和關系的。老實說，如果全部使用符合UML的工具來分析實現系統，我認為首先要解決的問題是成本（資金、時間），其次是思想的普及，只有深刻理解了UML的思想，才可能真正正確的是用它表示業務。 2、順應潮流，如果和外界交流，用UML吧！英語比起我們的漢語，那算什么��！原始的垃圾！但是老外都說，沒辦法，學唄！ 3、UML是發展的，它的存在是合理的。 4、與其在此爭執孰是孰非，不如靜下心，學習吧！
youyuan (2002-5-16 16:17:35)
看到此君的文章不禁想起了馮小剛電影《大腕》中那個搜狗網的c*o,他說要想網站要想火就要雇一幫寫手，誰火啐誰，誰火滅誰，它就像這種寫手，哈哈哈，我看他是想造個轟動效果，借以讓自己成名，無聊的很，我想uml的用況在誕生時就已經說得很清楚: Use Cases are a critical technique in developing an application. Within the UML Use Cases are used primarily to capture the high level user-functional requirements of a system. This long winded description is important because Use Cases cannot usefully be used to capture non-functional requirements. Nor can they usefully be used to capture "internal" functional requirements. Attempting either or both is a sure path to disaster for two reasons. Firstly because Use Cases are an informal and imprecise modelling technique. But then they were never intended to be anything else. Secondly because the other use that we make of Use Cases is to define the fundamental structure of our application. The Use Case is not only important as a unit of requirement definition but also as our unit of estimation and our unit of work.
文章來源于領測軟件測試網 http://www.kjueaiud.com/
