用了Together，还会想用Rose吗？

together的link by pattern我还没试过,惭愧惭愧

有个小问题,link和link by pattern, 生成变量名都是lnk开头的,Together会默认在类图隐藏它们,我觉得这样不是很好,所以我一般会按照我的习惯把它们改了,这样的话关联线还是在的,而在类图又会显示出来,不知道你们一般会不会这样做?

另外, 用实现接口和继承的时候,它不会自动帮你生成方法,一般我是拷贝粘贴,不知道有没有地方改的?让它自动生成?

奇怪，生成的变量名可以在properties框里改啊，变量名你想取什么就取什么嘛（当然符合java的命名规范），对于类图没有任何影响

奇怪，生成的变量名可以在properties框里改啊，变量名你想取什么就取什么嘛（当然符合java的命名规范），对于类图没有任何影响

楼上，我理解错你的意思了，sorry
     的确together会出现这样的情况，尤其是接口方法的实现类中的生成，好烦躁。呵呵，不过可以用IDE工具implement或者overide接口中的方法就是，jbuilder和eclipse都支持

Rational Rose VS Together 实质，个人在工作中一些体会，请大家讨论。
　
--------------------------------------------------------------------------------

Rational ROSE最吸引人的地方不在于其架构或建模或逆向导入的功能。而是存在一个标准的过程（RUP方法论的指引）贯穿在其中。
同样作为一个标准的过程，必然有其适用范围，甚至RUP本身也支持过程裁剪。也就是说，我们可以在任何的实现工具中采用RUP方法（或经过裁剪的RUP方法）的指导进行架构分析（改进架构）、用例分析、分析类、设计元素的确定等等的过程实现。
如果仅仅作为图形工具，Rose和Together不如白板和白板笔更直接和方便，甚至在一定程度上制约和影响了工作的开展。
也就是说如果有了正确的方法，无论采用Together还是Rose都可以获得良好的效果，甚至使用Together可以更加方便。
比如：Use Case图中Together可以提供System Boundary（系统边界、非常好的概念），在每个用例的描述中：有pre-conditions（前置条件）、post-conditions（后置条件）、normal-flow（基本事件流）、alternate-flow（备选）事件流等属性提供。这些在Rose中是需要加强的。

瘦驼  回复: 这么说，ROSE可以说是一个过程导引的工具了？
　
--------------------------------------------------------------------------------

呵呵，应该说使用任何一种建模工具，都会有一种与其相对的方法（论）指引。
对于UML这种图形化的语言工具。Rational提供了RUP方法作为OO建模指引。我们使用Rose或Together（我除了在工作最初使用Rose98以外，以后一直使用Together）进行OOAD的过程如果有了正确的方法（不一定是RUP方法，但Rose与RUP的融合是其他工具难以达到的），会有好的结果（理论上）。

换句话将即使我们使用Rose或Together，但在OOAD过程中没有掌握好的方法所产生的结果应该一定不好。


瘦驼  回复: 用Rose跟together比较不太好比吧？应该是XDE跟Together相比较
　
--------------------------------------------------------------------------------

作为它们在技术上的概念Rose VS Together应该比XDE VS Toether更为贴近。
但大多的使用者对OOAD的理解以及在什么方法作为指导的概念不了解的情况下，自然是从简单的使用上来看，而不是从方法论的实践中去看。
Borland收购Together其目的，在于整理中Borland自身的"RUP"（不太贴切，如果我们把Borland所制定的OOAD方法称之为 BUP 的话），BUP 附加在Together中。并且绑定在其所有可能的产品中。


XDE For Java就应该于 Together for JBuilder Edition 更为相近了。
XDE For .Net 就应该于 Borland Sidewinder 更为相近了。

请问Rose和Together哪个更好?

youlq  回复: Rose和Together

--------------------------------------------------------------------------------
其实这个问题没有答案。。不同情况有不同的需要嘛。。。

就我个人体会，rose的画图功能很烂！！！但是，他和rational其他产品结合使用的话。。。呵呵。。。功能太多了（注意，只是太多，不一定强大）。。总是让人眼花缭乱，无从下手，呵呵，功能太多和没有功能没什么区别。。。我想，大部分人都仅仅把他当作高级画图工具使用巴。。。那就不如用visio吧。。

如果是个人或者小团体使用，我觉得together是不二选择！！尤其是应用在java项目上。。。就仅以uml的支持而言，有一点，rose绝对作不到，就是对序列图的双向工程支持。而且他还引入了特有的图，对于企业级应用很有帮助。当然，最爽的是他的 图形<－>程序 之间双向工程的功能。。。呵呵。。不可思议。。。

当然，我觉得together也有不足之处，他在团队协同建模方面支持的不太好。至于速度马。。。我倒是不觉得java编写的together会太慢。。

li_zjun  回复: Rose和Together

--------------------------------------------------------------------------------
上面这位仁兄是说软件工程的正向和反向工程吧，ROSE也是可以做到的阿，只是目前国内使用ROSE很普遍，而Together则很少，其实ROSE我也不是很清楚，但Together的确不错，我不知道Together的创始人或者是开发者是什么样的，我只知道ROSE 是由世界级的5大软件工程方法学家，面向对象专家共同创建，且他们推动了软件工程方法学的发展，创造了不同的软件工程方法理论并成为主导流派，并不断将这些方法理论的优点不断整合到一起——ROSE中。说能告诉我Together的来龙去脉，或者其创造者的背景？

youlq  回复: Rose和Together

--------------------------------------------------------------------------------
hehe..没错。。就双向工程这个功能上看，两个工具各有优势。

rose的优点在于几乎对大部分流行的语言都提供了双向工程支持。但是，由于他本身不是ide，所以用起来很麻烦，要在rose和ide之间频繁切换。。。

together的优势在于，他是一个全能的工具！软件工程的各个阶段所需要的工具他几乎都有了。。而且提供design patterns支持，代码审核，等等难以想象的功能（至少对我来说很神奇）。。如果要说有什么缺点的话，第一，他不支持对delphi的双向工程（呵呵。。。我本人是从来不用delphi的）.第二，他不支持我们熟悉的“拖放式”编程功能。。。不过，我认为，至少在java语言上，现在的其他ide如：jbuilder通过“拖放”生成的代码，有一半是有用的垃圾，还有一半是没用的垃圾:－）所以，没这个功能也没什么大碍。

btw：如果我没记错的话，together的大头很有来头。。呵呵。。好像也是祖师爷级的人物。。。而且together原来好像叫另外一个名字。。

我本来不想参与这个讨论，因为我从来没有怎么使用过ROSE，TOGETHER也是一样，只是试用过几次。所以我就不说太多中两个工具的好坏，而说些别的东西。
首先这些工具是否可以做到大规模的团队使用，决定不是在这些工具本身，而是在其输出的文档的格式，是否可以被很好的SCM管理。所以大家不要去非议输出格式只是SVG，这在我看来根本就不是问题，如果觉得难受可以使用XSLT去把它转换为XMI或者PDF，网上工具应该很多，不过我自己没有查过。同时由于我没有使用过ROSE，所以我就不能告诉你MDL文件在CVS这样的工具中支持是怎么样的。是否可以很好的合并，也就是是否很好的判断两个文件的不同，这些我都不能告诉你。希望知道的朋友，给我一个说明。
每一个的CASE工具背后都只少有一个方法学家作后盾，也都有一种自己的方法。TOGETHER背后的方法学家是coad，方法是FDD。ROSE背后是三友（现在应该是两友了），方法是RUP。我认为从方法层面上来说FDD比RUP更加优秀。首先FDD在分析和设计的技术层面上比RUP优秀。feature对于用户需求的良好量化是RUP中所没有对应的。color UML也是比RUP所推荐使用的名词法更加简单明了。FDD的组织原则和实践，也比RUP的更加具有直观性和可操作性。造成这样的结果其实很简单，RUP要考虑其很多的用户都是那些传统的组织。而together出现比较晚，没有那些历史的包袱。
最后说说USE CASE的问题，一个工具是否支持USE CASE DIAGRAM根本就不是什么新闻，也不是什么卖点，支持USE CASE的几种关系更加不是什么可以夸耀的。而我认为应该把USE CASE DIAGRAM从UML中清楚的予以删除。USE CASE 根本就不能显示太多的信息，只是在一个整体的层面反映系统的整体的功能之间的逻辑。但是由于多数的面向对象团队都使用增量开发，这样在开始的时候就没有必要去建立这样一个图。而项目结束以后或者项目的后期，我认为可以通过包图或者组件图以反映这些大型逻辑之间的关系（即使现在很多情况下，UML中也是把包的概念引入USE CASE中）。同时就如同多数的敏捷学家都反对过分额分析USE CASE的关系一样，对于扩展和相识的关系，在我看来绝大部分时间都是被浪费了。
而我对于这些CASE工具最不放心的是他们不能很好的支持TDD，而我们由于使用CASE习惯性的会从分析到设计以一个连续的动作进行完成，这个时候很少会停下来在适当的时候先建立其测试的方案。仅此一点，我就不会认为有必须使用CASE的必要。同时我看使用这些CASE的朋友基本上在使用的时候很少考虑层的概念，都是直接从分析模型到设计模型。这当然不是CASE本身的问题，而是使用者自是的问题，不过我认为大家应该考虑为什么使用CASE就容易犯这样的错误。

最后提醒一下jinbo朋友，转贴请注明。

sorry,我以为可以明显地看出是转贴就没注明了，加上用的是快速回复。下次注意了。

Rose是可以分不同的Unit，每个人做一部分然后导入合并吧？

其实我觉得这个不是问题，只是一个习惯吧，真的需要的话，在设计目录下面分几个目录，按照人名每人一个目录，通过CVS合作，不是也一样吗？

呵，昨天以为和那篇一样就没有留意，原来东西都在这里。

我刚才又打开确认了一下，我用的版本是 Together ControlCenter 6.0 (不是ConsoleCenter)。

从一开始Together就是TogetherSoft的产品而不是JBuilder的插件，从4.0起Together就以其独有的Realtime Code-UML round trip 在业界竖立起自己的名声。它提倡的是FDD方法，背后的的专家是Peter Coad 。(他主持的 CoadLetter http://community.borland.com/coadletter/ 值得推荐)

Together ControlCenter 宣称自己是一个 Model-Build-Deploy Platform， 因为除了 Java，它还支持C++, C#, VB6, VB.net 以及 CorbaIDL的Model-Build-Deploy。它带有一个成熟IDE所应有的全部特性。编辑，编译，调试，发布，CVS，Refactor，JUnit，Ant……。特别地，它强大的ColorUML和代码质量审核最为让人称道。可以说，相比当时腐朽的JBuilder和稚嫩的Eclipse，Together的确重新定义了IDE的含义，因而屡获大奖。

就Together ControlCenter的设计功能，值得大书特书，不是一篇回帖的篇幅所能涵盖的。具个小例子，Together支持ER图，能够生成完整的建表SQL，还近一步，这个SQL能直接在Together中连上数据库，建立所需要的数据表。

可惜的是，这些功能，在Together被Borland收购之后出的N个裁剪版本中，都被“裁剪”了。一个成功的收购导致市场上从此失去了一个如此优秀的工具，殊为可惜。