如果说程序是一个人，那么类图就是这个人的躯体。也就是说，光有类图，一个程序已经成型了，看上去很像那么一回事了。UML在刻画程序的静态结构方面很成功，但是在刻画程序的动态语义时很失败，至今没有一个好的解决方案，或者说，没有一个能让各方面都接受的方案。如果UML动态语义的问题解决了，那么MDA的目标就真的达到了，模型可以完全代替代码了。

目前的MDA工具，号称模型代码同步的，号称代码生成的，号称PIM/PSM转换的，大部分都只是和类图打交道罢了。因为类图和代码之间的转换是如此自然，以至于出现了Together这样的工具，模型（类图而已）和代码是同步的。

类图是程序的躯体，动作语义才是程序的灵魂，可惜UML在刻画程序灵魂的事情上做得太不出色了。很多研究者仅仅把目光放在类图上，类图到代码的生成几乎已经没有什么可以研究了，还是抱住不放，在生成的代码中加入约束、加入设计模式、加入持久化存储等等。怒其不争、哀其无志。想到自己也是其中的一员，不由临表涕零。

类图是非常容易学习的，因为它和面向对象编程是孪生兄弟，如今的程序员哪有不懂面向对象的，因此类图对于他们，就如同奶瓶对于婴儿一般。下面从硬盘中翻出一幅曾经自己画的类图，相信大家一看便知：

类图是一门易学难精的技术，正如面向对象技术一样，一百个程序员九十九个都说自己懂面向对象，但是真正入门的可能不到十个，真正精通的也许只有一个，这个人还往往不是中国人，唉～

自己重新学习UML的动机就来自于一次论文撰写过程中，想查阅类图的元模型图，但是问遍同行，翻遍网络，找不到合适的图形或者描述，最后只能求救于OMG的UML规范。一查之下，大惊失色，原来很多东西原来都是懵懵懂懂，不甚了了。因此痛下决心，要弄懂类图中的疑点。

翻看类图，我发现有如下是疑点所在：

l         Attribute和Property的关系如何？区别和共同点是什么？

l         完整的描述一个操作（Operation），需要多少东西？

l         类之间可以有关系（Relationship），关系可以是关联（Association）或者泛化（Generalization），这个你知道么？

l         关联有七种：普通关联、递归关联、限定关联、或关联、有序关联、三元关联、聚合（聚合和组合），各自有什么含义？用法如何？

l         关联类（Association Class）的含义如何？应用场景如何？

l         类的实例化是对象，关联的实例化是什么呢？

总结出了这些疑点要归功于中文UML书籍的模糊和混乱，或者是翻译者的语焉不详。所以让我在复习时找出了这么多的疑点。

要查阅资料，解决疑难，并举例说明，起码需要3，4天的时间，因此这篇随笔就作为类图的引文先发了。也希望志同道合者和我一起研究上面的问题。

UML是一组图示符号的标准。所谓图示符号，就是一组定义好的图示，它们可以表达定义好的各种意思。用UML进行软件建模，就是用规定好的符号画图，这些图表达了开发人员脑中的软件系统。用UML进行软件建模，其难度并不比我们小时候上的美术课更难。在美术课上，一个圆形加上四根线条表示太阳，一个三角形加上一个矩形表示房子；同理，在UML的用例图中，一个椭圆表示用例，一个小人表示参与者。我并不认为它们之间有质的区别，想到我对这种小学生画图课恐惧了几年，不由得感到羞愧。

用例图是UML的九个图中较为重要和常用的一种图。常常用于软件开发的需求分析阶段，也能用于软件的系统测试阶段。简单的来说，用例图是描述系统的外部视图。

在开始设计一个软件系统时（更广义的情况下，可以用来设计任何系统），需要一种手段来发现系统的功能，用例图虽然是图示，但是这些图示隐含了一种启发系统功能的手段。其实所有的UML图都只包含图示和标准，并不包含方法，但是它们往往隐含了某种方法。UML和软件开发方法的关系，很类似于汉字和语文的关系。

用例图包含了三种基本的概念：用例、角色和系统。它们可以组合起来表达系统的外部视图。而且这种表达方式是如此直观和简单。

画用例图是一件很简单的事情，而且感觉还很舒适，因为用例图简洁、直观。虽然用例图不能像HelloWorld一样运行，也不能生成代码，不过画一张清晰的用例图还是很有成就感的。

我使用的工具是Eclipse+EclipseUML插件，功能不如Rose，但是是开源而且免费的（EclipseUML有free版也有企业版），而且效果也不错。第一张用例图如下：

可以看出图中有一个系统（保险商务系统），两个角色（客户和保险销售员）以及三个用例（签订保险单、销售统计资料、客户数据资料），另外还有四个连接线以及一个注释。如果在纸上或者合适的工具中，画这样一张用例大概只需要五分钟吧。不过仅仅画出来是没有意义的，需要弄清楚其背后真正的含义才行。

可以这样简单的理解用例图中的一些概念，系统（System）指的是软件系统，它可以包含一些用例，并界定系统的边界，边界之内的属于系统的功能和行为，边界之外的则不是系统所关心的内容。系统规定了一个具有某些功能的黑盒子，在系统之外看到的仅仅是这个系统的功能，而不能看到系统的内部细节。这一点也是用例图经常被用来做系统测试的原因。当然这些测试一般是黑盒测试。

角色（Actor）是与系统中的用例交互的一些实体，在实际情况中，角色可以是人，也可以是其他系统或者硬件设备。在画用例图的过程中，角色往往是第一个被确定的，因为系统或者用例在开始时是模糊的，但是参与系统的角色是最容易明晰的。有了角色之后，根据角色与系统的交互，以及角色要求的功能，可以进一步确定系统和用例。

用例（Use case）指的是系统的功能，它是系统某个功能的所有执行动作的集合。在UML图示中它是一个椭圆，但是具体分析用例的时候需要给出这个用例的所有执行动作的步骤。例如上图中的“签订保险单”用例，就可以分为几个步骤：第一，客户发出保险单请求；第二，系统给出保险单样式表；第三，用户填写保险单样式表；第四，系统检查用户提交的保险单格式是否规范；第五，如果不规范则返回第二步，如果规范则给保险单销售员发出消息；第六，保险单销售员填写保险单；第七，保险单销售员将填写好的保险单加入数据库，并将客户资料输入客户数据库。当然，以上步骤仅仅是我想象的，我还从来没有见过什么“保险单”，这次过了一把瘾。

连接（Assocation）是角色与用例的连接，表达此角色可以初始化此用例。 

注释（Note）可以添加到任何地方，对用例图的不同部分加以说明。

泛化（Generalization）在面向对象的技术中无处不在，它的另一个名字也许更为著名，就是“继承”。下图给出了一个使用泛化的用例图：

由此可知，在用例图中，角色和用例都能够泛化。角色的泛化/继承很容易理解，因为角色本来就是类（Class），它是一种版型（stereotype）为Actor的类，所以角色的继承直观而自然。但是用例的继承实际上分为两种情况，并不是简单的使用泛化，而是使用扩展（extended）和包含（include）两种泛化的特例。

扩展用于子用例的动作步骤基本上和父用例的动作步骤相同，只是增加了另外的一些步骤的情况下。包含用于子用例包含了所有父用例的动作，它将父用例作为了自己的一个大步骤，子用例常常包含一个以上的父用例。如下图：

小结

关于用例图基本上也就是上面提到的这些内容了。当然，用例图还常常和类图、活动图联合使用，不过那些知识还是等其他知识完备了以后再说比较好。

我总结的画用例图的步骤如下：

l         确定系统，拟出系统的名称，这个不难，例如电信计费系统；

l         找出所有与系统打交道的角色，角色要进行一些精简和整合；

l         站在角色的立场想象系统应该提供的功能，将这些功能画成系统中的用例；

l         对于每个用例给出详细的动作步骤；

l         找出用例图中角色、用例之间可能有的继承、扩展或者是包含关系；

以我现在的理解能力，认为用例图到此为止了。当然，我还可以想象，用例图会用来启发类图的构建，例如用例图中的某些部分（角色或者用例）会变成类图中的类或者接口。另外，可以想象用例图还可能会影响活动图中的流程。

让我恐惧了好久的用例图在今天便土崩瓦解了，心中却彷佛有一点茫然，因为我记得自己无数次的对自己说“好忙啊，这个技术肯定要花很多时间，还是以后再学吧”类似的话。当我用C的时候对C++这样说过，然后是Java、CORBA、JSP、XML、MDA、XMI、UML……

写blog不仅仅是一种爱好，对我来说，更是一种最好的学习方法，当我读小学的时候，班主任常常对我说“好记性不如烂笔头”，我当时的理解是把事情用笔记下来比用脑袋背下来更加持久（脑袋是内存？纸笔是数据库？）。但是，现在我理解到，要学习某个东西，最好的方法是用自己的语言把它表达出来，如果你能让别人理解这个技术，你自己当然已经精通了。在我写blog的过程中，常常会出现写到一半的时候猛然领悟的情况，这是因为当你在选择最佳的表达方式的时候，将你自己头脑中一团乱麻的线索都理清了的结果。

有朋友留言说，自己计算机本科毕业，在计算机领域学习了八年，竟然看不懂我的blog。这个我认为很正常，读本科的时候，所有同学都可以在一起讨论问题、实习；等到上研的时候，同学对我说他的课题，我只能模糊的听个大概，因为专业方向已经分开了；现在读博了，同学要拉着我说他的课题，我只能明白是哪个领域里面的问题，往往对这个问题的描述都听不懂了。这是因为研究方向已经非常精细的原因。我自问我的方向已经很大众化了，如果研究图像压缩算法的话，那满篇都是数学公式了；如果研究微电子技术，那么满篇都是集成电路图了。

UML自1997年诞生以来，受到无数厂商、组织、专家学者的追捧和拥护，短短几年时间，便有一统天下之势。提起建模语言，舍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。

工具的多寡与优劣可以看出某个技术的受欢迎程度，在建模工具中，不说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，也是在很小的范围内，完全没有发挥出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何以取而代之？

既然国内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是标准的。不要忽视标准的力量，标准的东西意味着在全世界范围内都有可能会被看懂，不标准的东西可能出了你的办公室就没人能够清晰、准确的理解了。