有个问题说出来大家讨论一下哈

Rational Rose大家都用过吧. 我想知道一下：

1。Rational Rose赚不赚钱
2. 如果赚钱，是不是赚大钱
3. 她是怎么赚钱的？因为UML modeling技术是开放的，OOA/OOD的技术也是开放
的。就靠卖软件赚钱吗？还是Training / consulting?
4. 如果这里有企业级的Rational Rose用户，还想请教一下一般企业都用的
Rational Rose的哪些功能? Class Diagram / UseCase / Collaboration Diagram
/ State Chart Diagram / Code generation / Reverse Engineering. 有没有这
方面的统计数据呀? 哪种应用最常见.

谢谢

 回复: Rational Rose的商业模式
　

---

都点击了10次了咋就没有人吭声捏.....

 估计你对精英式的软件开发比对工程化的软件开发了解得更多
　

---

简单答复：
1、Rose是前Rational公司的系列CASE中的一个，现在Rational好象被IBM收购，Rational公司是盈利的。
2、前Rational公司盈大利，但对大陆考虑微小。
3、估计你对精英式的软件开发比对工程化的软件开发了解得更多，此系列工具用好了确实能提高公司的软件开发效率。但如果没有哪个综合实力，就不要邯郸学步了。
4、前Rational公司的官方网站对此多有统计，数据非常真实。有时间可以去看看。
另外，建议：对软件工程要有个客观认识，首先，她不是银蛋；其次，她确实是一门科学。
祝你更快进步！

 回复: Rational Rose的商业模式
　

---

不是我不想开口，只是自身水平不足呀，UML是这个学期学的，也是大学的完结学期学的，了解不是很深，rose用过，不过，只是学校的练习而已。技术问题虽然谈不来，不过，就能不能挣钱的话题，，咱也插个嘴吧，过去的一段的时间rational公司的财务还是不容乐观的，不过，就其技术的前景还是很明朗的啦，据说IBM公司为了在UML市场占稳脚，于是吞并了她，这也足以见其技术还是能领导一时潮流的，

 回复: 我们在做和UML类似的东东，所以才问
　

---

谢谢哈。

我这样问其实是因为我们实验室正在开发一套和UML类似的东西。所以想了解一下商业前景。

UML好，可是也有他的问题。其实Rational Rose就不是很好用。我觉得如果不是IBM买了他，而是Microsoft买了他，那至少界面上会有很大的不同。就好像visio。我现在画diagram都用visio.

看来这位前辈对UML有很深的理解，将来还有很多地方要请教哈. :)

精英开发模式，是CMM level 0 或 1吧？英雄开发模式? 软件开发的确是件非常难的工作，所以才会有OOA/OOD. 目的就是为了最大程度的重用代码。不过这样也带来了模型的复杂性。普通的世界里的对象之间的关系一般都是Decompositioin(分解关系）可是OOA/OOD里面还有继承性和多态性。我觉得这样做的目的就是为了配合代码重用。不过反而增加了模型的复杂性。对吗?

 回复: 对了，因为是我们实验室的研究方向。所以我说的话还是有知识产权的问题的。怕搞出问题来被老板骂:p
　

---

如果要引用，请注明出处：
Sofeware Research Lab
Arizona State University
USA.

 既然是做技术探讨，就不要客气
　

---

既然是做技术探讨，就不要客气！交流当然欢迎哦。
不是打消你的积极性，不知你们实验室处于什么级别？UML思想工具化，做到啥层次？两年前，与我同时做论文的一个同学，就是画UML做为他论文的一部分（自己做了一个工具），更前一些时间，高展（扬某的得意门生）个人做了个Playcase，与UML比较相关，当年还得过奖。
如果你要更进一步，把它真正做得象个东西，个人认为可能性较小，中国能真正做系统级软件，但成功的很少。当然也有，如Kingdee的Apusic近来就不错。
知识产权？个人认为不应该是你现在担心的问题。
就UML的不同版本，变化还是比较大，而Rose对其的扬弃也明显。
单纯做UML，好象对公司运作这样的系统工程意义不够大。你可以和北航的周伯生、吴超英老师联系，他们前段时间取得了SEI的CMM的评估师资格。我们公司本计划请他们做咨询，但由于我们是做CMMI3，故无法实现。

 回复: 欢迎讨论。我们也是刚起步，如果我说我们打算取消OO 模型的 继承 和 多态 特性，你是不是又要大跌眼镜了?
　

---

为什么要这样做呢。我们先分析一下为什么OO模型要有继承和多态特性。其本质原因，或者说原始动机，就是最大限度的代码（模型）重用。但是这样一来，模型的复杂性也大大提高了。可以说，为了代码重用，实际上程序员要写的代码量增加了（从一个对象变成了一个父类和若干了子类，或者一个虚函数和若干个重载函数）。反过来看现实世界，其实现实世界中对象和对象间的关系很简单，只有“包含”关系。一个汽车包含4个门，一个门上又包含一个门锁。有人要说还有“继承”和“多态”的关系。先别急，如果没有一个抽象的门，又哪来的从抽象的门到每个不同的门的继承关系，又何谈从一个门到若干不同的门的多态关系。那么现实世界中存不存在一个抽象的门呢？不存在。抽象的门只存在于人的思维中。而且对具体的不同应用，这个抽象的门也不是唯一的。比如要是抽象汽车的门，那这个抽象的门就一般是金属的；要是抽象卧室的门，那这个抽象的门一般就是木头的。既然这样，为什么需要一个抽象的门呢？为了更好的对现实世界建模？不是的。当然我可以先有一个抽象的门，然后为每个具体的门生成一个门的实例。可是我同样可以为每个不同的门都建立一个模型，不管他们之间有多模相似，我都为每个门建立一个只描述它自己的模型。这样做有问题吗？完全没有，因为这样建立的模型依然正确。那问题在哪里呢？在于模型的（以及将来的代码的）重用。因为没有这个抽象的门，我的模型虽然能用，但缺乏良好的重用机制。随之而来的几个问题，一个是我建模的复杂度大大提高了，要是有1000个门，我的80％的工作要重复1000遍。一个是模型修改何扩展的难度提高了，要是哪天我突发奇想，想把所有的门从左右开变成上下开，那我又要去修改这1000个门。不过如果我们抛开“重用”不考虑。那我的模型中没有一个抽象的门则根本不是问题。这样做带来什么好处呢。我不需要在写代码（建模型）之前去费心考虑，这个抽象的门到底应该如何。因为依照刚才的例子，如果我的这个抽象的门没有抽象这个开门关门的方向，那要改这个左右开到上下开，我还是要改1000个门。我也不用为了已经有一个抽象的门而费心怎样把一个实在的门套到这个已经设计好的抽象的门上了。我也不用为了把前人已经写好的500个不同的门的都改成从这个抽象的门上派生出来而重写这500个门了。这样是不是简化了我建模的思想复杂度呢？是的，因为我的建模过程就是直接了当的一一对应。是不是模型和现实世界更接近呢？是的，因为在现实世界中，无论两个门多没的相似，它们还是两个门，而不是一个抽象的门的两个实例。那接下来的问题就是，既然这么好，干吗还是要一个抽象的门呢？因为我不能放弃“重用”。没有人会笨到写1000个不同的门，而不去抽象一个门然后实例化1000遍。可是，如果我有一种相当的或者更好的“重用”机制，那我是不是可以放弃“继承”和“多态”特性？我想，答案是肯定的。不过到底该怎么做呢，我也没有想好。说了这么半天，没有一个实质的方法上的突破，并不是想故意的浪费你的时间。我只是想指出，UML还是有很多东西可以做的。弄不好，还能做出本质上的突破。一孔之见哈. :)

还有阿，不是所有语言都支持gp,你的建模工具不能规定用户只能使用C++吧。

另外，stl::vector是不行的。

UML从建模工具的角度来看，则现实世界的模型化，在此则采取的方法之一则对现实世界的抽象，也就是一般和特殊；模型化的目的则是找出一般，在一般下细化出特殊。
继承和多态实际上是对于这种一般和特殊规律在OO世界内的一种表现形式。因此从建模的角度来看，这个概念（继承和多态）是不可避免的，但是在此也仅仅是表现形式而已，如果能够找到较好的概念来描述此特征，也未尝不可。

 回复: 恩，这也是我们思考问题的方向。其实抽象化一个模型确实是人的思维惯性。。。。
　

---

恩，这也是我们思考问题的方向。其实抽象化一个模型确实是人的思维惯性。说不好听一点，这也是人的惰性的一种体现。心理学有这样的发现，在认识新事务的时候，人总是试图用他们熟悉的东西去进行简化。可是反过来想一下，当有了一个抽象的模型之后，把这个抽象的模型细化到每个具体对象还是一件相对比较复杂的工作。因此，抽象的模型固然有助于人们理解新事务，它带来的问题也还是不少的。反映到软件工程上就可能出现这样的局面，做设计的人设计好了class diagram，可是最后的实现却要为了这个class diagram削足适履。因此，如果能有一种很好的方法，在充分照顾人的惰性的同时，尽量减少模型和实际情况不匹配的可能，那将是一个很好的解决方案。

 回复: Rose应该不是你说的这种公司吧
　

---

感觉上Rose还是走高端的路线。他们的东西，书都出了很多本了，OOA/OOD的大旗也打了很多年了哈.

 回复: Rose应该不是你说的这种公司吧
　

---

grandy booch写的东西，说实在的，也就是给别人写的prologe谢的最好。
公司倒是不错，但是也有那么神奇。
IBM买了rational，主要是看中“三剑客“在OMG/UML的地位和影响力，以及对UML未来的看好。现在走了一个，亏大了。

而且，我认为boost:any虽然比void进步，但在设计中使用依然是需要讨论的。

 Rational Rose的搞笑
　

---

Rose 2000发布时顺带出了几本书，小的跟着老板去参加了亚太的发布会。记得场面非常热闹，在座的不少是软件工程方向的教授，还有些公司的人，来介绍的新书作者非常牛哄哄，40多的女人，Rational公司的创始人之一，自我介绍说是小学数学老师，由她的3孩子开始讲到大谈Rose的牛B，然后谈她大作的指导意义，下面笑声一片。提问开始时，大家可以想象下面这帮学术界的人提的都时苛刻的学术问题，感觉象拿着她的书一页页翻着提问,就看她开始练太极了，问到什么技术不清晰时答案一律是under research，问到什么功能没提供时一律是we have some partner companies building those for Rose. 有个印度哥哥比较狠，一针见血的问，除了class diagram以外，你到底觉得还有其他任何功能对industry真有用吗？小学数学老师傻眼了。

痛快！

“源代码就是设计”我没听说过，我只听说“源代码就是文档”和“源代码可以表达设计”，想解决的是文档与实现的脱节问题，“抽象的设计和具体实现脱节”产生的原因往往是设计者和实现者的水平脱节，有时设计者设计出的东西实现者不懂怎么做，或者设计者水平不够，设计出的东西太差或者无法实现，考虑也不周全所至，而不是抽象不抽象的问题。

不过我同意你的一个看法，继承是一个潘多拉的盒子。区别在于，我认为继承是无法回避的。

在这一点上，我（私下）认为，这不是建模方式的问题了，而是建模方法的问题了，也就是说，和结构化方法和OO方法的平行的一个问题。当我们看待世界的角度是从结构化的方法，自然不会出现继承和多态的问题，但是会出现功能的分解和模块耦合等在此方法上的问题。如果我们把建模的方法建立在使用实体来描述世界时，实际上就是从抽象的角度来看待。不良制度不是建模方式，建模方式仅仅是在制度下一个的方法。导致继承的原因之一则是我们现在描述系统的方式是OO的；同样我们也可以在设计的过程中不是用继承。那么这种脱节的冲突不是消失了，而是上升到了我们建模的层次。也就是说我们必须在分析模型时处理这种一般和特殊的冲突。一般和特殊的冲突，并不是仅仅存在OO建模中，同样在结构化同样存在，只不过，结构化的建模方式，是从另外的角度去看待，因此没有确切的描述一般和特殊的关系。
另：抽象思维可以看作人的一种惰性的体现，但是换个角度，实际上我们认识世界的一个很好的方法。
我们此时将认识世界的方法一脉相承的到了分析模型，也就是说分析模型和我们认识世界的方法没有太大脱节，OO的设计模型和我们分析模型没有太大的脱节，在实现上我们使用继承和多态保证了实现模型和设计模型的没有脱节，但是却直接导致了一系列相关的其他问题。我感觉是不是我们的实现方式需要有新的变化。

 回复: 恩，我的意思是......
　

---

你说的都是人的问题。可是换个思路，我觉得可以这么看，我们目前没有很好的工具辅助人来做这件事。就说抽象模型吧。UML, OOA/OOD可以用来描述一个抽象模型。可是到目前为止，把芸芸对象抽象成一个模型还是完全在人的大脑里进行的。只有在抽象成了这个模型之后，才能用UML, class diagram画出来，具化成文档。在这个抽象工作完成前，设计者只能独自在黑暗中摸索。到目前为止，提高设计者的能力的法门只有一途，就是设计者自身经验的积累。那么有没有办法来辅助人的抽象过程呢？在抽象完成之后，有没有办法来直接检验这个抽象的结果呢？如果有好的工具来辅助这两件事，那么设计过程才能真正摆脱经验的窠臼，摆脱设计者自身能力的限制。才能更系统化。才能成为一门科学，而不是一门技艺。好方法我没想到，不过不那么好的方法到有一箩筐。就是怕不入大家的法眼哈. :)

 回复:en, 我说的就是方法上可能需要有新的突破... 呵呵，中文退步了.
　

---

你说的正是我想讨论问题的关键。我觉得有几个问题需要认真思考，

1 抽象模型是不是必须
2 如果必须，是不是有必要放进软件模型
3 如果有必要，有没有方法(a)辅助抽象过程；或者(b)直接检验抽象结果
4 如果不必须，有没有别的方法来保证有效的模型重用

我在另外一个帖子里说：目前在3上还是空白的。而且我感觉3和传统的方法差距也比较小。目前我的工作方向也是想先在这个问题上有所突破。在解决这个问题的同时，可以积累一些经验，然后再回头看看2和4。

btw: 这个坛子上真是卧虎藏龙的.很佩服的说。:)

设计的好坏不和设计者的能力相关反而是和工具相关，呵呵，我觉得你可能经验少一点，但想象力是足够了。

即使在高度工程化的电子行业，一个好的设计也是来源于设计者自身的能力包括经验。

真正需要解决的是如何确保项目的成败不依赖于某一两个骨干，产品的质量不依赖于程序员的水平，或至少如何降低这种依赖。而不是如何降低对设计者的水平要求，一将无谋，累死千军，一个错误的设计会害死整队人马。

 回复: haha, 说我想象力好，是夸我还是损我? ;)
　

---

我给你发过email. 赏脸回一下喽. :) 有MSN吗?

回了，是夸你:-)