【导读】本文作者在现有UML现状的基础上，和我们探讨了目前的UML热潮是怎么产生的？为什么会存在形式主义？以及RUP之类的工具究竟存在哪些问题。作者根据自己的经验，给出了解决的建议。
UML在国内不少地方获得了应用。这应该说是个好事，然而背后我们也看到，这种应用大多属于不够冷静的炒作和跟风，UML在很多时候已经变成了一种形式主义的东西。实际上，UML本身所倡导的主旨是很好的，它保证了程序员之间的交流语言，RUP之类的工具也保证了软件开发过程的规范性，严格保证了先设计后开发，设计阶段有翔实的规范化的文档等。接下来，我们要看看目前的UML热潮是怎么产生的？为什么会存在形式主义？以及RUP之类的工具究竟存在哪些问题。
第一是目前几乎所有的UML工具都非常不好用，不美观、不直观、更不方便，在项目中进行同步维护也很困难。很多项目中用UML基本上可归于形式主义的范畴。事实上，UML本身是一种规范，而规范本身的目的在于更好的交流沟通和更快更好的设计质量，事实上现在UML的发展已经背离了这些更基本的宗旨。我崇尚简单就是美，最传统的流程图每个人都能看懂（甚至不是程序员也可以），现在的UML呢？太多不够体贴和人性化的东西了，过于抽象化和公式化。我想未来会有新的更轻量级的类似的东西取代落后、冗肿和封闭的UML。我个人崇尚简单就是美……
第二个问题是目前程序员的普遍素质不够。UML本身基本是于面向对象的软件设计思想的，没有足够优良的OO设计能力，很难有真正需要UML类别设计工具去表达自己设计意图的必要。这个观点不算夸张，其实有的人OO理论很强，但真正在实践中往往过度设计，或者设计本身极度不平衡，把项目开发改成了科研实验和上机实验。另外更多的一些人对自己的动手能力很信任，往往忽视设计环节，基本上项目的设计一直处于反复和动荡中。这些程序员不给他们一段时间学习和实践，是很难成为成熟的设计师的，在基本成熟之前，UML对他们将是一个形式化的东西，不会有很强的意义。Andrei曾经说程序员要到35岁才会成熟，而代码员可能20多岁就可以了。这句话里大概也有“设计本身是个很需要经验的工作”的意思。
第三个问题是少数社会层面的宣传误导。印度海归派、外企员工、IT译书作者和出版社、职业培训机构等处于各自的经验、目的和原因，大部分人完全背离现实的盲目鼓吹UML，甚至几乎片面的认为UML就是软件工程。外企应用UML其实也并不很成功，不过他们有成熟的培训体系，所以一定程度的弥补了UML过于晦涩的弱点，作为已经掌握他们的外企员工有一些可能会比较片面的欢迎UML。而印度海归派的目的就不用多说了，至于培训和译书的人很多都学者成分大于实战成分，他们需要鼓吹UML，不过早晚他们会发现更好的东西而放弃对UML的鼓吹。事实上，现在已经有人开始考虑这样作了。
第四个问题是少数程序员非常依赖自动代码框架生成，而这其实根本不是UML的关键问题。他们为了使用某些工具生成的一点也不符合中国人阅读习惯的代码，情愿放弃其他的一切。对他们来说UML只是一个代码生成工具而已，所以他们作的UML大都没有多大价值，比较形式化。
第五个问题是项目资源的问题。国内大多数项目实际可支配的资源非常有限，如果给其他外国公司的开发人员看无论开发周期还是资金人力都基本是荒唐可笑的。UML实际上应该贯穿始终，而不是只在最初的设计阶段，也应该贯穿整个项目组，包括设计、管理、开发、测试所有的人都应该应用它。
我想一般的公司如果没有极大的把握不用太迷信UML/RUP，其实某些基于轻量级项目并不需要RUP或UML。现在正打算学习UML的同行们，也尽可以先放下它，将来一定会有更优秀的技术取代它，现在不如多花点时间学习和实践一下OO设计等更基础的东西。其实仅仅熟悉一下工具软件和交流范式，将来对你来说只是几天到个把月的事情，不用那么在意。而对于那些现在已经决定了实战UML的项目，要想获得成功，我的建议如下：
第一，项目周期至少延长通常计划的50%至100%。你必须跟所有人解释说，只有这样才能让UML本身有意义，才能切实提高项目的设计质量。
第二，在项目开始集中提供一段时间的UML开发培训。贯穿项目始终，都要经常进行全方位面向对象设计思想的交流（当然是结合UML的），力图通过交流提高设计质量。
第三，顶住客户和公司领导方面的压力，坚持把尽可能多的设计问题在最初的设计阶段解决，而不要被迫匆匆完成形式主义的UML设计，然后把设计丢在一边，开始编码。
第四，妥善处理部分“精英”程序员的抵触情绪。能疏导就疏导，不能疏导应考虑压服甚至将他彻底排除在项目组外。UML量级的团队开发并不鼓励个人英雄主义，不下狠心将根本没机会推进下去。
第五，对项目的期望不要太高。无论是面对急于验收向上级邀功的政府客户，还是公司里不懂技术只懂蛮干的领导，都要保持低调，把它当做一个并不见得立竿见影的实验……
好了，就写这么多，祝大家好运。