关于详细设计/代码的同步问题--请教

03-09-22 blues
我一直这样做:用rose做model->生成代码->修改代码->reverse->修改model如此循环,结果都是:到后期,文档和代码对应不上,慢慢地文档就没有用了。因此请教各位:有没有好方法,可以保证详细设计/代码一致性?

--刚才请教一个人,他的说法是:让详细设计文档和代码分开,不要使用reverse功能。当rose model修改时,也不用rose的代码生成功能。

但这种方法,不知道有什么潜在缺陷?

这问题令我困惑已久!望有经验的前辈不吝赐教!

blues
2003-09-22 13:46
按照"设计文档/代码"分开的原则做,越做越怕:

rose model中的那些注释等,还要一个一个的copy到代码中,工作量已经很大了。等rose model发生修改了,该怎么办呀...

zingers
2003-09-24 15:55
Together Control Center6.0好象可以实现这个功能。

arthurlian
2003-09-24 17:16
尝试过一些做法,都不尽如意,最后的做法还是在代码中加些注释,详细设计文档中只记录一些不易改变的内容。按照xp的做法,只有代码是可以运行的,不要写没人看的文档。

zz
2003-09-25 19:17
没必要在rose里为每个类写注释,可以把这些时间用到代码的注释上去

生成javadoc一样可以很方便的查看,需要的时候再对整个source code做

一次完整的逆向工程

rose里记录的更重要的信息是整个系统的actors and cases,关键的

state chart等

wuliang
2003-09-26 09:03
用together吧,有几个版本

together cc不知怎样,

together for jbuilder不好用的,要在两个窗口切换,而且特耗内存

强烈推荐together for eclipse,不用双向操作,做到即时同步,当然用eclipse做web还不太方便,但是做java project,我觉的比jbuilder强,特别是refactor功能

我现在把一个web项目分两部分,一个是核心java prj,另一个web prj,引用java prj生成的jar

blues
2003-10-17 13:37
传统方法的缺点--难以维持设计/文档/程序的一致性。这么久以来都没能解决这个问题(相信很多人有这个感受)。所以不得不怀疑传统开发方法的适用性。看看国标的文档模板,真TMD恶心,在实际应用过程中效果如何?我是没有遇到用的很好的。

所以现在想换一种开发方法,使用XP方法尝试一下。

但我对xp方法了解甚少,现有一问题请教:(问题较弱,莫笑话我)

xp过程,会有哪些文档,其中哪些是过程性文档,哪些是最终留下来的文档?在做的过程中不断涌现出来的一些想法,算法,结构,需要记录成文档吗?如果是,记录到最终留下来的文档中吗?

robbin
2003-10-17 15:48
楼主我不得不告诉你,你对Rose误用了,Rose不是用来生成代码的,只是一个设计工具,不要在Rose设计的类图里面添加太详细的注释,并且期望把这些注释导入到代码中去。

Rose你做到系统分析级别,也就是说到设计的系统不依赖于具体语言实现就该结束了。不要再细化到具体每个类的每个具体属性了,这就误入歧途了。

开发阶段对类的修改是非常频繁的,需要不断的根据系统实现的考虑修正设计,折衷,如果你在Rose里面都详细到每个Java类的每个属性和方法,改起来你会累死的。

blues
2003-10-17 17:35
> Rose你做到系统分析级别,也就是说到设计的系统不依赖于具体语言实现就该结束了。不要再细化到具体每个类的每个具体属性了,这就误入歧途了。

同意。从发完那个帖子之后,我也没有再那么做了。原因很简单,如果一种方法屡屡失败,就有问题了。

但即使如此,还是无法解决设计/文档/程序同步的大量工作。所以要尝试另一种设计/开发方法,从减少“中间环节”开始。说白了,就是减少文档的数量。

我这里说的“减少文档数量”,是指那些最终要提交的正式文档。还有很多非正式的中间过程文档,作为我们自己的交流文档和备忘录,还是要的。

iceant
2003-10-18 21:48
也许你们需要引入 Process. 方法都是好方法,但是操作的过程不同结果往往大相径庭。

我以前在 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 走通了,才应该考虑如何引入软件来减少操作上的复杂度。

teliduxing
2003-10-20 09:58
设计与编码的同步,照我现在的经验看来,基本上没有什么工具可用,主要还是靠管理和手动的同步。

我现在的项目用的也是Rose做类设计,然后生成初始的Java代码,但在以后的开发中,往往很多类都被删除或改名或修改了内部结构,所以我现在的做法是:一段时间后,从Rose里面Reserve一下源代码,但Reserve代码只能让类设计部分保持一些同步,对其它更复杂的设计部分根本不能同步,只能手工修改其他的设计部分。

要保持设计文档与源码的同步,我觉得要做好以下2点:

1、设计文档尽量简洁,不要涉及太多实现中的细节,不然以后实现有大的变化后,设计文档就有的改了;

2、定期对设计文档和实现做同步;

呵呵,其实以上2点我自己现在根本也没有做到…… :(

efang
2003-11-11 16:49
可用Together来确保详细设计、代码的同步

refactor
2003-11-12 14:56
其实如果详细设计做到这个地步,一旦需求变化频繁,反而增加不少额外的工作量。设计关键在于从更高层的角度来规划全个系统,很多人看到together能和代码结合起来就好像捉到了什么法宝,实际上工具永远是工具,关健是你怎么去用它,这就是上面iceant 提到的process。

我最喜欢用word文档+代码注释,这里还有一个原因,直接在together或rose修改没法清晰反映出相应的版本改动,而在word是可以一目了然的。

albert_qhd
2003-11-12 15:21
> Rose你做到系统分析级别,也就是说到设计的系统不依赖于具体语言实现就该结束了。不要再细化到具体每个类的每个具体属性了,这就误入歧途了。

不太同意!如果最后代码与设计类图不一致,那设计类图还有什么用呢?又不是像画家一样画出来欣赏的

类图就应该跟代码保持一致,这样,后来者就可以通过设计类图来把握系统全局。

当然,手工同步是比较不爽,建议用Together for Jbuilder 或者Together for Eclipse

refactor
2003-11-12 15:41
实际上说到“详细设计与代码”同步,有一点要清楚,究竟设计出来的什么样的设计模型和代码同步,一般详细设计模型是分很多种的,除了提到的一些类模型,可能还有一些用例,DFD,甚至最详细的关于算法的伪代码,所以就算你用rose或together,也就是方便了你类模型和代码的同步,其他怎么办呢?所以说关键还是要从开发过程去控制和管理这个同步问题。

猜你喜欢