程序员眼中的UML
UML自1997年诞生以来，受到无数厂商、组织、专家学者的追捧和拥护，短短几年时间，便有一统天下之势。提起建模语言，舍UML其谁？
UML相关标准
OMG组织作为影响力最大的面向对象技术的机构，早早便将UML收入囊中，力捧其为标准建模语言。OMG在CORBA取得成功之后，最大的着力点便是MDA架构，而MDA架构的四大标准UML、MOF、XMI和CWM中，围绕着UML的技术便有三种：UML本身自不必说，版本已经到了2.0；MOF作为“建模语言的语言”，似乎就是为UML量身定做的，虽说MOF有能力创建出与UML并驾齐驱的建模语言，但是似乎没有看到谁这么干，大家只是在努力的发展UML的“方言”，例如UML Profile for CORBA，UML Profile for EJB等等；XMI是“模型的标准存储交换格式”，为了解决不同的建模工具创建的模型不能互用的问题，OMG创建了XMI作为模型的存储交换标准。这样一来，UML工具更加可以大行其道，使用不同的建模工具创建的UML模型可以互相交流，只要它们都基于XMI。
UML相关工具
工具的多寡与优劣可以看出某个技术的受欢迎程度，在建模工具中，不说100％，大概也有90％支持了UML语言。最出名的UML工具Rational Rose，被IBM收购了；Eclipse下面的UML工具EclipseUML让开发它的小公司Omondo也出名了；国内也有一个UML工具，听说效果也不错，就是楚凡科技的Trufun Plato 2005。至于其他国际上有点名气的UML工具，更是不胜枚举，几乎有点软件实力的国家，都有自己的UML工具。
当然，UML不仅仅出现在专用的UML工具中，它也频繁出现在最新的各种开发环境中。例如编程开发环境JBuilder，具有将代码转换为UML类图的功能；Together就更进一步，直接实现了代码和类图的同步转换；Eclipse作为最优秀的开放式开发平台，拥有众多的UML相关插件，除了前面提到的EclipseUML，比较有名的还有EMF和UML2。
UML在MDA出现之后，在OMG的概念中，成为了MDA的一个子集（虽然UML的名气远远大于MDA）。因此众多的MDA工具中，几乎都少不了UML功能。我认为很多MDA工具就是从UML工具直接改过来的。
UML使用现状
照理说来，如火如荼的标准和工具应该催生出如火如荼的应用才对，可是UML的使用状况实在不尽如人意。无论是身边的还是网络上的朋友，在项目中使用UML的都是凤毛麟角，即便使用了UML，也是在很小的范围内，完全没有发挥出1％的功效。现在总结一下目前我所知道的UML使用现状：
l 读代码时，用UML工具进行逆向工程，可以清晰的观察代码结构，方便理解代码。
l 写代码时，由于开发平台可以自动生成UML类图，因此有时观察UML类图得到比较清晰的代码结构。例如Together或者JBuilder等工具。当然，如果没有自动生成的UML图，大部分人也不会寻找其他工具去生成UML类图的。
l 撰写科技论文时，使用UML来表达系统架构或者系统流程等。
l 部分对UML非常熟悉的程序员，在开始写代码时，先画UML类图，然后利用工具生成代码，最后对代码进行扩展。
从上面的使用现状可以看出，很多人把UML当成一种可有可无的技术。即使使用了UML，也只是围绕着UML中的类图，其他的UML图都抛到一边去了。造成这种状况的原因，一方面固然是因为国内的正规大型软件项目比较少，软件工程技术起步很晚；另一方面是由于国内不管是架构师、系统分析员、软件工程师、程序员、测试人员等等实质上都是程序员而已，很多人是赶着鸭子上架成了架构师或者系统分析员的。这种状况下，软件工程的概念难以深入人心，UML更加成了一个国内项目的鸡肋。
看看国外的架构师、UML专家们，往往都是满脸大胡子，在计算机领域中浸淫了3，40年；而中国最古老的程序员，也只有十几年经验，除去在黑暗中摸索的几年，有十年以上开发经验的程序员少之又少。不经历几个大型项目，要使用软件工程技术是不可能的，也是不能起到什么效果的。因此，有人堂而皇之的撰文“UML的三大硬伤”，将UML驳斥得一无是处。高喊口号打倒某东西是很容易的，关键是打倒了UML何以取而代之？
程序员眼中的UML
既然国内90％以上的软件开发人员都是程序员，那么程序员眼中的UML到底应该是什么样子的呢？我很期望有一本好书能够让程序员们快速的掌握自己所需的UML知识，遗憾的是目前还没有看到这样的一本书。无论是“三友”的UML经典教材还是国内的一些“xx天精通UML”都不符合这样的要求。没有一本是“有中国特色的UML教材――一本写给程序员的UML入门书”。
作为一个程序员，我很了解其他同僚的心理，如果拿到一本书，翻了一个小时还没有找到可以run的HelloWorld，90％的人会大叫一声“去nmd”，然后把书扔进废纸堆。不能怪我们急功近利，在这个技术术语满天飞，连底层平台都动荡不安的年代，谁还有时间和兴趣看一些与自己无关的东西呢？
我很能想象一个程序员，好不容易空出时间来看看最近很热的UML技术，当他拿到一本UML入门以后，开始寻找对自己有用的东西。在开始的一个小时，满篇都是需求分析，use case，甚至书的作者还在饶有兴趣的介绍use case有六种译法：用例、用况、用案……对不起，老子一百年都没做过需求分析了，也不想知道这个狗屁的use case到底叫什么。于是开始后悔在china-pub上又白花了这么多银子。
还有些书上信誓旦旦的说“学好UML，走遍天下都不怕”，如果你做需求分析，你可以用UML和客户交流；如果你做系统分析员，你可以用UML设计系统；如果你做程序员，你可以用UML生成程序；如果你做测试员，你可以基于UML设计测试用例。而实际情况是什么呢？国内的客户有几个懂UML？懂UML的人差不多自己都可以把软件写出来了，还需要请你做需求分析么？别说客户了，上次听同学说和北京某大科研所的工程师们交流，无意中说起了UML，在场的竟然只有一个稍微了解，而且坚持认为那是一种画图工具（那位仁兄其实也没错，Visio不就是一个画图工具么）。
虽然状况如此不堪，但是UML确实是一个很优秀的“交流语言”、“代码生成工具”和“系统设计工具”。让我们擦干身上的献血，掩埋战友的尸体，睁大迷蒙的双眼来看清UML对程序员的作用。UML有九种图，作用各自不同，基本上涵盖了软件工程的各个方面，很多人就是不堪于忍受知识不足的困惑与“侮辱”（很多程序员认为一种技术自己看不懂就是对自己的侮辱），从而放弃了整片UML森林。他们怕的不是在UML这棵树上吊死，而是怕在UML森林里面迷路。但是我想说，知识学习的过程就是去芜存精，找出对自己有用的东西，然后掌握之。对于程序员来说，UML的价值就体现在三个方面：
一、UML是最好的交流语言，无论是与其他程序员交流，还是与领域专家、测试员或者用户交流。原因只有一点，UML是标准的，就像英语一样，无论多么该死，大家还是忙着把自己的论文改成英文的。当然，在小的领域可能有更好的交流方言，但是在大而长远的交流中，使用标准的交流语言是稳妥的。
二、UML是很好的代码生成工具，其实代码生成功能并不是由UML语言和规范提供的，而是由UML工具提供的，而且不同的UML工具提供的代码生成功能还不尽相同。例如Rose提供简单的代码框架生成，而Eclipse插件EMF可以生成功能丰富，提供了各种设计模式的代码包。无论如何，如果程序员可以从UML入手来写程序，比直接敲代码要高级那么一点点。从文档、版本控制、维护、测试等各方面来说，画UML类图比直接写代码都要高那么一点点。
三、UML是很好的系统设计工具。对于程序员来说，很少用到“设计”这个词，大部分时候我们都是在“编写”或者“实现”。但是勿庸置疑，程序员的许多工作中还是需要“设计”的。包和组件之间的依赖关系、复杂操作的流程、对象之间的关联和状态、程序的部署等等，都经常是程序员的工作。那么上面的四种情况可以用UML的组件图、序列图、对象图和部署图来设计。虽然，不同的程序员有不同的设计方法或者设计图例，不过，UML是标准的。不要忽视标准的力量，标准的东西意味着在全世界范围内都有可能会被看懂，不标准的东西可能出了你的办公室就没人能够清晰、准确的理解了。
后记
Blog好久没有更新，因为最近一直忙于一些俗物，于是想写点清高的东西。但是写完之后再看，好像也不怎么清高，反而更俗了。
前段时间写论文时，需要用到UML2.0的类图元模型，在UML2.0的规范中寻觅了好久，发现类图元模型已经被拆分到三个包里面了，因为UML2.0的规范实在是太大太繁琐了。于是有感于UML之博大精深，说好听是博大精深，难听点就是乱七八糟。不过OMG历来如此，当初的CORBA如果更简约一点，也许J2EE根本就没有立足之地。
感慨之后就是想把UML中对自己有用的部分整理出来，在整理之前免不了到处翻资料，这篇文档就是翻资料的一些感触了。希望能够将UML的有用部分都整理出来，形成一个系列的文档。