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我没有用过，瘦驼兄能否进一步讲讲...

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

---

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

换句话将即使我们使用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 更为相近了。

使用什么过程思想,关键是靠人来实现.
工具可以减轻大量的重复性,甚至人工难以完成的枯燥劳动,也可以提供一定的过程约束和指引作用.但前提还在人.
评价一个工具,应首先看它降低了多少人的劳动强度,让人把主题集中到创造性的设计工作中去.