--刚才请教一个人，他的说法是：让详细设计文档和代码分开，不要使用reverse功能。当rose model修改时，也不用rose的代码生成功能。
但这种方法，不知道有什么潜在缺陷？
这问题令我困惑已久！望有经验的前辈不吝赐教！
rose model中的那些注释等，还要一个一个的copy到代码中，工作量已经很大了。等rose model发生修改了，该怎么办呀...
生成javadoc一样可以很方便的查看，需要的时候再对整个source code做
一次完整的逆向工程
rose里记录的更重要的信息是整个系统的actors and cases，关键的
state chart等
together cc不知怎样，
together for jbuilder不好用的，要在两个窗口切换，而且特耗内存
强烈推荐together for eclipse，不用双向操作，做到即时同步，当然用eclipse做web还不太方便，但是做java project，我觉的比jbuilder强，特别是refactor功能
我现在把一个web项目分两部分，一个是核心java prj，另一个web prj，引用java prj生成的jar
所以现在想换一种开发方法，使用XP方法尝试一下。
但我对xp方法了解甚少，现有一问题请教:(问题较弱，莫笑话我)
xp过程，会有哪些文档，其中哪些是过程性文档，哪些是最终留下来的文档？在做的过程中不断涌现出来的一些想法，算法，结构，需要记录成文档吗？如果是，记录到最终留下来的文档中吗？
Rose你做到系统分析级别，也就是说到设计的系统不依赖于具体语言实现就该结束了。不要再细化到具体每个类的每个具体属性了，这就误入歧途了。
开发阶段对类的修改是非常频繁的，需要不断的根据系统实现的考虑修正设计，折衷，如果你在Rose里面都详细到每个Java类的每个属性和方法，改起来你会累死的。
同意。从发完那个帖子之后，我也没有再那么做了。原因很简单，如果一种方法屡屡失败，就有问题了。
但即使如此，还是无法解决设计/文档/程序同步的大量工作。所以要尝试另一种设计/开发方法，从减少“中间环节”开始。说白了，就是减少文档的数量。
我这里说的“减少文档数量”，是指那些最终要提交的正式文档。还有很多非正式的中间过程文档，作为我们自己的交流文档和备忘录，还是要的。
我以前在 R&D 的时候，一般就写 HLD,DD 等文档。每个软件版本都有 Feature List(这一般是由 PM 确定的),然后就有人根据 Feature 写 HLD 和 DD. 每份文档出来后都要有 Review, 要留底(通过 一个文档管理系统来管理),而且每个对文档的改动也都会产生一个新版本的 Document.
后来公司 Process 改进，要求程序员做好 Unit Test, 减轻 SIT 组的压力，于是我们开始承担一部分测试。测试时也要写 Test Plan，测试组的同事写了一个系统，可以在 WEB 上编制 Test Plan,然后产生 CheckList,测试时就对这些 CheckList 打钩，最后可以要求系统提交一份报告。如果有BUG，还要提 MR. MR 修改后，要写修改了什么，为什么修改,不写不能入库。
产品出来以后，会有Document Group 的人负责写操作指南
......
在我离开 R&D 时，公司的 Process 还在变化中。
我的感受是，软件只是一个辅助工具，只有 Process 走通了，才应该考虑如何引入软件来减少操作上的复杂度。
我现在的项目用的也是Rose做类设计，然后生成初始的Java代码，但在以后的开发中，往往很多类都被删除或改名或修改了内部结构，所以我现在的做法是：一段时间后，从Rose里面Reserve一下源代码，但Reserve代码只能让类设计部分保持一些同步，对其它更复杂的设计部分根本不能同步，只能手工修改其他的设计部分。
要保持设计文档与源码的同步，我觉得要做好以下2点：
1、设计文档尽量简洁，不要涉及太多实现中的细节，不然以后实现有大的变化后，设计文档就有的改了；
2、定期对设计文档和实现做同步；
呵呵，其实以上2点我自己现在根本也没有做到…… :(
我最喜欢用word文档＋代码注释，这里还有一个原因，直接在together或rose修改没法清晰反映出相应的版本改动，而在word是可以一目了然的。
不太同意!如果最后代码与设计类图不一致，那设计类图还有什么用呢？又不是像画家一样画出来欣赏的
类图就应该跟代码保持一致，这样，后来者就可以通过设计类图来把握系统全局。
当然，手工同步是比较不爽，建议用Together for Jbuilder 或者Together for Eclipse