程序员眼中的UML(3)

--类图，就是比你高一点

UML的成功80％是因为类图，提到UML的时候有90％的人想到了类图，应用UML的时候100％应用了类图。如果类图和源代码走到一起，肯定是要代码抗钉耙的，因为论武功和智慧，类图都高了那么一点点。

乱谈类图

如果说程序是一个人，那么类图就是这个人的躯体。也就是说，光有类图，一个程序已经成型了，看上去很像那么一回事了。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天的时间，因此这篇随笔就作为类图的引文先发了。也希望志同道合者和我一起研究上面的问题。

后记

周末了，想偷懒了，结果适得其反，刚刚完成这篇blog就停电了，后面的几百字全没了。这一点告诉我们，持久化存储是多么重要啊～