ROSE使用中的一些问答

Question

转自http://www.chinajavaworld.com/bbsoffline/jinghuaforum54/75.html

理解得委好所以转过来
问之部

1:UML中的sequence图与我们写
程序的流程图有那些区别？？

2：在sequence图中一些class的方法，已经
在生成的代码中改变，我怎样可以把sequence图
的信息也随着改变？

3。在逆向工程中，我只看到倒入的class图，在package
中有一个class Hierarchy图，能否生成sequence图或
别的功能？

4。在使用rose的过程中，我怎样保持文档(一些设计时的补
助说明)，Rose文件，程序代码一致性，也就是说，客的需求
有改动，这些东西怎样保持一致？分别每个都该动？

5。我们在实际使用中，开始设计时使用了rose，可是在实际开发的过程
中出现了以下问题
1。发现设计时由于没有详细，考虑不周，要改动
2。客户的需求在改变
3。由于市场和老板的时间压力，时间很紧

我们就在该程序，没有时间改rose和文档，最后发现程序和
文档有很大的偏差？？？

6。使用rose,需要怎样的文档做补助说明？？

Answer 1

答之部

回复人：conquer   回复时间：Fri Feb 01 02:47:45 CST 2002
回复内容：
1：基本元素不同，一个是对象的方法交互细节，一个是代码级别的运行顺序。也就是说
  观察的角度不同，对象之间是逻辑性的交互只看被分解出来的小任务是如何完成的，流程图是代码的运行，代码的一步流程一般来说是不能完成一个逻辑功能的，但是有的对象的方法如果考虑到效率写的比较复杂的话，会使用流程图来描述。可以说序列图隐藏了实现细节。你可以看成是把一些流程图变成一个名字，他可以完成一个明确的逻辑功能，然后他成为一个对象的某个方法，然后你使用这些名字来描述你的系统件的对象是如何交互的来完成最后的一个更大的或是完成的逻辑上的一个功能，例如，流程图会描述出你是如何把一个商品销售出去（记录定单表，明细表，修改库存表，记录财务表等等).但是在你的序列图中或许就表示为，可户发给销售对象的一个消息，就完了，至于如何记录如何保证事物完整等等这些细节就不会表现出来。我一向比较罗嗦，哈哈。（你妈贵姓？兄弟几？。。。。：）
2问题有些模糊。能说清楚一点吗？你是使用什么工具？
3这个就的看你到入的代码的质量了。幸运的话，你可以看见上帝。
4严格按照顺序做下来，每个对象，或者描述都应该来自于use case.rose就可以自动更新你的文档，但是程序说明是没有办法的。如果你的代码框架是用rose生成的，那么框架可以更新但是你天家的代码，嘿嘿，不用说你也知道了吧。
5.1 改动是不可避免的，所以改动的影响由你的最初的设计思想决定，如果你考虑可变更，那么祝福你，你是个聪明的幸运儿，否则，取决于改动。但是要记住，从use case 开始研究改动，不要急着改动细节，这样可以看到这个变更所影响的范围，然后从变更中心开始检查，直到确定，这个变更是可以接受的为止，再更新文档，记录变更，一个一个改动，测试。
5。2客户是上帝，但是我们也不是奴隶，之所以要和客户做需求分析，之所以要使用use case来描述，为的就是今早发现这些不确定的地方，避免陷入细节，引导客户，帮助他明白什么才是他想要的东西，才是做需求，如果客户只用几句很模糊的描述，自己回来就按照想象去做，这是个注定要失败的项目。至于变更的放发，同上。只是一个是自己的噩梦，一个外来的威胁。项目的开始就是噩梦的开始，不是我说的，是微软的专家说的偶，不要哭，坚强些，为了中国的所谓软件产业，要献了青春献终身，献了终身献子孙。
5.3时间紧张的情况下，最容易犯的错误就是：立即开始做，想要尽早看到东西，要给头和客户交差。如果这么做的话，那么你可以放弃这个项目了。做设计不仅仅就是做设计，很多人只是为了做文挡而做文档，大错特错。我门是为了理清楚如何做，做什么而讨论设计，在这个期间，整个项目的难点和逻辑流程和借口各种要遵守的规范都已经准备好了，做代码不过是个照设计稳当翻译的过程而已。所以第一：要对自己有信心，如果你没有信心，那么别指望你的小组有信心，也别指望你的头对你有信心。第二：要建立小组的信心，以坚决的不可改变的方式告诉所有的成员，在设计没有被审查通过，代码期没有开始的时候，谁也不准写一行代码，否则（看你权利而定怎么办^-^）。第三：对你的头说。你信任我那么就要信任我的小组，那么信任我们整个小组的计划，不要越过我管理我的小组，我会完成这个项目。我会定期向你汇报。你得让你的头明白为什么你要很多时间来做稳当而不是写代码。但是一般来说这个工作很困难，所以你要挺住。下面是我带领一个小组的经历。7个人一个月31天，完成一个网络游戏社区,包括客户段。使用java.7个人中有1个客户代表3个人对java 不熟悉，没有项目经验，时间紧的很。但是我用了18天一句代码也没有写，就是从use case 开始做分析，7天写代码，5天测试。最总完成了项目，在做分析的时候，我让3个部署系的人开始看要使用到的技术书籍，然后前8天，所有人在一起从use case 开始分析设计，大家讨论，8天以后，详细的分析和一些分析中要使用的规则已经定好了，7天每个人单独完成自己负责的分析，这7天每天晚上2个小时，每个人讲自己的分析，其他人看是否符合规范，和自己的分析接口是否正确，可能出现的问题等，剩下3天，把所有的设计汇总，一起来审查，修改，然后就严格按照这些文当做代码，不符合稳当的一率杀掉。结果在做文挡的着段时间内我们的分析就避免了很多将来可能遇到的错误。而且use case帮助我和客户代表，小组成员一起进行分析，很多东西都是我们和客户的理解不是一个意思，虽然是一个说法。代码完成后，由于设计期间就确保了逻辑和借口没有问题，集成测试非常顺利。基本没有很大的错误。
没有文档的代码是没有任何用处的。当你积极茫茫写代码的时候，或许就因为你没有看看稳当，而这个修改是会引起其他致命错误的情况发生。
6复杂的算法要另外写流程图。一些rose文当没有描述清楚的地方另外写文档。这个就看你的rose文当做的如何了。具体情况具体对待。一般来说需要另外在写很多文当的情况不多见。