你知道人的硬伤是什么吗？自私？贪婪？懒惰？不宽容？...都不是，是死亡。死亡是一切宗教的核心秘密。如果有人以“他会死”（没错，这确实是事实）来攻击一个人的人品，您觉得这样的攻击能够服人吗？

《程序员》杂志有一篇《UML三大硬伤》（以下简称《程》文）。我们认为，《程》文作者在文中把建模语言，方法，工具，管理...等概念混在一起，许多观点是不正确的。因此，我们综合了前一段时间在UMLChina和CSDN所进行讨论的网友观点，撰写此文进行澄清，并阐释初学者对UML的一些误解，希望有所助益。

我们认为，作者所描述的“硬伤”，很多属于刚开始学习UML时感到困惑的问题。如果实践者在运用UML碰到问题时，都是象《程》文作者所言“怪自己无法理解三位UML创始人的深度思想”，必然就会更深入地去查资料，看资料，思考...如果能这样，相信随着学习的深入，多数问题都会不成其问题。一般来说，学习某个东西的过程总是这样的：

1.刚开始学习和使用：很多概念不理解或者与原有知识不合拍，觉得到处是“硬伤”；
2.深入一点了：觉得原来的“硬伤”，原来只是自己没有领会－－大部分“硬伤”消失，剩下部分可看作是这个层次的真的硬伤；
3.再深入：在更深的层次发现更多的“硬伤”，这时人已经谦逊多了，不敢确定是不是真的“硬伤”；
4.再再深入：发现其中部分“硬伤”是假的，但也确定某些“硬伤”是真的。
5.循环往复，螺旋式上升。

照这个过程来看，至少是到了2的阶段，给出中肯“硬伤”意见的概率才会大一些。

诚然，使用UML的统一过程中几大核心工作流之间的衔接、几大视图的演化，以及业务模型到实现模型的转化，这方面的详细资料和书籍，目前虽然在国外已经出版了很多，但正式在国内出版的还不多，这也使得国内开发人员在应用UML和统一过程建模时，无所依从。但这种情况正在好转，目前有分量的UML相关书籍的中文翻译版权都已经被国内各大出版社所瓜分，不断推出精品书籍，推出频率看起来越来越高。如果说以前的结构化方法，包括早期的OO方法，国内的资料都严重缺乏，那么一批批UML相关书籍的推出，将为以前没有建模习惯的软件公司提供强有力的启蒙和参考。

《程》文：在国内的公开报道中，几乎众口一词地充斥着对UML的褒奖，即使有公开抱怨也只是怪自己无法理解三位UML创始人的深度思想，怪自己水平不够，没有料到UML本身却存在着种种问题。

评论：

1. “三位UML创始人的深度思想”这种说法可能会引起一些误解，误认为“UML是这三个人创造出来的，与其他人关系不大”。事实上，UML是一种工业标准。我们来回顾一下UML的历史：

面向对象的编程语言发展得比较成熟以后，人们开始将面向对象扩展到分析和设计领域，任何新生事物一开始总是比较混乱的，到1994年，有一定影响的OOAD方法有50多种。【1】对同一个概念，不同流派的表述方法都有所区别，例如对类的操作（operation），当时的表示方法有：

　

Wirfs-Brock	Responsibility（责任）
Booch	Operation（操作）
Coad/Yourdon	Service（服务）
Stroustrup	Function（函数）
×××××	Method（方法）

任何学科要得到持续发展，都必须有一种大家公认的标识符把思想留存下来。没有+-×÷∈∏∑∞∮∫≈，很难想像数学的发展；没有五线谱，贝多芬们如何能精确表达灵感？（也反面印证了中国科学的衰落－－没有符号体系使得科学无法持续发展）

UML的最重要贡献是符号的统一

Grady Booch看到了这一点，他在文章中提到，“科学的一个普遍问题是，必须对被观测的对象和情况，建立一种有意义的分类方法，以便人们理解这些观测结果，也有助于科学理论的持续发展。”【2】1993年，Grady Booch开始工作。1996年Rational发布UML0.9。1997年，多家软件公司组成的UML联合组织成立，并把UML1.0提交到OMG。1997年11月4日，OMG发布UML1.1。目前UML的最新版本版本是1.4，正在筹划的UML2.0将以成为ISO标准为目标。【1，3】

UML对各个流派的建模符号和概念进行了归纳，并提供了非常严谨的定义和描述，成为真正的建模语言。虽然Booch、Jacobson、Rumbaugh三人的表示法在UML中占了主要部分，但还是有很多部分来自各方。接口来自Microsoft，包的符号来自Apple Macintosh，活动图来自James Odell，状态图来自David Harel【3,4,5,6】

Martin Fowler在1997年就指出：“你应该使用UML吗？一个字：是！旧的面向对象符号正在快速地消逝。它们还会残留在UML稳固前出版的书上面，但新的书、文章等等将会全部以UML作为符号。如果你正在使用旧的符号，你就应该在1998年间转换到UML。如里你正要开始使用建模符号，你就该直接学习UML。”【2】。五年过去了，我们可以翻翻能买到的国外1998年以后出版的和面向对象有关的书籍，事实证明正是如此。如果使用面向对象的方法来开发软件，用UML作为建模语言是最好的选择，如果不是基于面向对象方法开发，那就不一定要理会UML了。

【误区一：UML是三个人的。】

《程》文：本文作者在北京大学计算机系同行那里发现他们撰文对UML的有效性提出了质疑。与公开报道相左，业界私下流行的观点形象地说明了UML存在的问题和为软件开发设置的障碍，那就是“上不着天，下不着地，一盘散沙”

评论：

1. “北京大学计算机系同行”的文章是哪一篇呢？北大的邵维忠先生是写过一篇“统一建模语言UML述评”【7】，但文章里面也算不上质疑“UML的有效性”。我们在网络上找到一篇邵维忠先生的新文章《UML的现状及未来发展》【8】，也算不上质疑“UML的有效性”。

2. “业界私下流行的观点”是“上不着天，下不着地，一盘散沙”－－此言何来？是在业界何处流行呢？如果是“私下流行”，那应该在网络上会有一些痕迹吧？再经google查询关键词“上不着天 下不着地 一盘散沙”【9】－－一个和软件相关的网页也没有。

《程》文：“上不着天”这种隔阂使建模结果无法与用户沟通确认所谓的需求，埋下了软件危机的祸根；

评论：UML引入了用例，用例已经被证明是捕获功能需求的有效手段。【10】

《程》文：“下不着地”这种隔阂使千辛万苦得到的建模结果无法指挥程序员编码，最后得到的软件与用户期望的结果相差很远，返工，误工，烦恼无穷。

评论：

1. “千辛万苦”这个说法和后面的“相差很远”、“烦恼无穷”一样，我们认为不是一种严谨的说法。

2. “模型－代码转化”这个责任，不属于UML的责任范围，而是属于UML工具的职责。即使如此，各种UML工具还是取得了可喜的成绩。目前，UML工具可以把UML类图、状态图直接转换各种高级语言，甚至可立即执行的程序。Rose现在基本上已经能够和所有的主流代码工具连接，直接生成代码框架。我们根据一些资料做了统计，目前UML建模工具能进行代码正向、逆向的语言及开发环境有：Smalltalk, Eiffel, Pascal, Java, Corba, VB, VBA, XMI, C, C++, Ada, Python, C#, Delphi/Kylix, C++ Builder, Visual C++, Visual Basic, Visual Café， PowerBuilder，Delphi，JBuilder，VisualAge Smalltalk， BEA Tuxedo， BEA WebLogic Enterprise, PERL【11,15,16,17】

传统的其他方法建模工具也已经开始集成UML。象Sybase的PowerDesigner从7.5版开始支持UML，到现在的9.0版【12】。

不仅是建模工具产品，代码工具厂商也开始在产品里集成UML功能。微软的Visual Studio .NET Enterprise Architect集成了UML建模的功能（基于Visio）【13】；Borland的JBuilder6也集成了UML视图【14】

Rose的代码转化设置框

3. 《程》文全文的重点篇幅只是放在“上不着天”这一点上，大家可以对比一下《程》文的第一部分和二、三部分的长度，文章名字叫《UML一大“硬伤”》是否更合适一些呢？