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.
文章来源于领测软件测试网 https://www.ltesting.net/
