【IT168 技术文章】得了一个机会(1)，我问Ivar：“UML什么时候才会死掉呀”。我无意用这个透着促狭味道的问题去为难大师，实在是因为这是我一直以来思考着的问题。向UML之父去求解，自然是最好。

Ivar细毫没有认为我是在为难他，他诚恳的回答让我在那个会议中陷入了深思。他说：“什么时候面向对象死掉了，UML就死掉了”。(2)

一个问题看起来很复杂，但它的答案可能非常简单。一个答案看起来非常简单，但它可能是最正确的。一个正确的答案，也许毫无意义，但也许，那就是大师的答案。

很多我们现在看起来是非常“理所当然”的事情，就曾经困扰着大师们。比如说，我们现在都知道程序的基本逻辑是顺序、分支与循环。那么，“为什么顺序、分支与循环是基本逻辑呢”？“作为基本逻辑，它们充备吗？”谁能回答我？如何回答我？

这是一个艰深的问题吗？我们知道答案，但即使知道答案，我们也答不出“为什么”。然而，真正的大师们是论证过这个问题的。那个提出“GOTO有害”的大 师Edsgar Wybe Dijkstra（戴克斯特拉/迪杰斯特拉）就为此写了篇“札记”。他是怎么论证的呢？他说计算机可以理解的人的思想方式，有三种。分别是枚举、归纳与抽 象。而，重要的是，Dijkstra进一步的说明，分支(if)是
计算机实现枚举的方法、循环(for)是实现归纳的方法。当他进一步的解释“抽象”时，他说“在现阶段，我发现很难把抽象的作用说得非常清楚”。

Dijkstra大概是做好全部的准备，来完成这篇札记。他通过数学方法来证明了“分支如何以及为什么能实现枚举”。也就是说明分支对于“枚举”这种思 想方法来说，是否是完备的。Dijkstra在写出了大量的数学推理之后，说“上述的笨重证明，也使我自己感到烦恼！但是，在现在，如果真的希望证明这个 程序的正确性，我确实没有更好的办法。”Dijkstra引以为佐证的是，“以前，平面几何里的第一批定理的荒诞证明，也常常使我感到同样的愤怒，因为这 些定理所论证的事情几乎和欧几里得公理自身一样的‘明显’”。

Oh! Dijkstra愤怒的原因，在于原本看起来是如此“显然”、“理所当然”的事情，却需要无比笨重的过程去证明它！如同我们明明知道“1+1＝2”，但证明这一点，既无趣又令人愤恨。

Dijkstra这样的证明过程，奠定了“程序正确性证明”这门学科的基础；它的证明结果，是说明了程序的结构性是有限的，例如顺序、分支与循环。这个 有“结构有限”的理论，开创了“结构化编程”这样的一个时代。我在《代码之美》的序中说“我们如今仍然在这个时代之中而不知觉于这本书的深远影响”，是意 有所指的。因为所谓的“面向对象程序设计”，其根基就是“结构化程序设计 + 在结构上更高层次的抽象”。而这“更高层次的抽象”，就是“对象”。

Dijkstra在1970年前后就完成了这篇札记，而我们接下来这40年的时间，仍未逃离大师最初的思想。然而，对这所有的一切，大师最初创见性的想法可以归结于一句：“可用来理解一个程序的种种思维方法之中，我提及以下三种：枚举法、数学归纳法、抽象。”

为什么是这三种？是不是只有这三种？能不能有更多种？大师没有解释，他只是“提及以下三种”而已。Dijkstra一方面给我们留下了空间，一方面，他足够完备的“论证”说明了基础逻辑必须至少具备“顺序、分支、循环”。而我们，40年来，无有突破。

Ivar把UML之死，归于一种抽象的失败，或其被更高的抽象所替代。实在是无比正确的，因为UML也是建立在结构化、抽象这样一些基元的理论之上。 Dijkstra的那篇札记，被收入《结构程序设计》一书，书里的另外两篇，一篇是“层次结构设计”，讨论的是面向对象程序设计；另一篇是“数据结构札记 ”，讨论的是数据基本抽象。三部文章，三位图灵奖得主，一个跨越40年的时代，以及程序设计语言分类中的1/2（命令式语言）都承受着这种影响。

然而，Dijkstra仍然无法论证，或未曾说明过“三种基础逻辑的唯一性”，他只是想当然地说“我认为”而已。

同样只是从“我认为”开始的，还有图灵机。如果有一个毛头小子跳出来说，“我认为”计算机应该象一个大笨象吃意大利面条；大笨象要有肚子，面条上要打 孔。Oh，很好，这个毛头小子立即会被哄出“计算机科学”的神圣殿堂。问题是，图灵就是这样一个毛头小子。于是他的这一构想就被称为“天才式的创想”。

然而，真的只是这样吗？

算盘用了几千年，谁问过“算盘为什么能算东西”？算珠、进位、栏，这些东西，是不是基本的存储结构？用算盘的“我们”，是不是计算单元？珠算表是不是运算规则？那些珠子表达出来的“0~9”的排列，是不是输入输出的界面？

“我们+算盘”就是一个完整的计算系统。这个计算系统的完整性，是图灵用了一个假想来说明的。图灵不过是用一个假想描述了一个事实，而这个事实，“看起来”能被机器实现。于是，我们的计算机时代就开始了。

图灵是否证明过“大笨象吃意大利面条为什么是一个完备的计算机系统”呢？不，最初等的问题，往往难于证明。往往，他的证明过程，或应用过程，只是触发了一个想象。

对计算机根本问题的思考，许多会追溯到哲学思想的层面。IOPD和PDIO的问题，程序＝算法+结构的问题等等，就是这一类。还有一些会追溯到人类行为 学、语言学等层面，例如语言、语法、语义，以及有没有语用这样的问题。大多数时候，真正推动了计算机发展的，不是对具体问题的推理求解，而是对问题本身的 抽象。在Dijkstra的叙述中，抽象更象是终极武器。按照Brooks的观点，“数据的表现形式（数据结构，抽象的结果之一）是编程的根本”；按照 Dijkstra的引述，“引用未解释过的名词阐述公理或定理和作用于未解析过的操作数的（命了名的）运算两者之间有着某种平行的相似性”。

无论如何，我们“做一个计算机”，原始的目的不外两个。其一是“让它计算数学”，其二是“让它像人一样思考”。注意，我的确是说“计算数学”，数学是人 类的理论学科，“怎么算”，以及算的内容等等，都是我们自己设定的。而计算机的能力，只是计算“数学”这个它未知的对象而已。事实上，我们现在在讲的“命 令式”，以及“函数式”，或“说明式”，就只是我们为计算机设定的“最基础的运算方式”。在这个“运算系统”中，“数学”并不是最初设定的。

命令式如何计算，函数式如何计算……类似于此的问题了解清楚了，我们对这类语言也就了解了。再谈什么高阶函数（higher-order function）、克里化（Currying）、延续（Continuation），或发生-迭代器（Generator-Iterator）之类，那 已经是具体语言的表象，而非“这一类语言”的本质了。举例来说，JavaScript 1.5还没有实现过“生成器对象(Generator Object)”，但并没有人否认它是函数式语言。反过来说，Generator Object原本就不是函数式语言的必备要素。

LISP表达了函数式语言的全部“必备要素”，然而LISP七个原子运算也是针对于“LIST”这个结构抽象来说的。对于一个“（顺序的）表”，这七个原 子运算是必须的，而对于另一个“（关系的）表”就未必如此了。所以，那这些原子运算，也不必放在函数式的必备要素中。象LUA这样的函数式语言实现方法的 出现，也证明了这一点(3)。

函数式还剩什么？

真正理解函数式的秘密，是要一个语言一个语言的学习下去么？是要一种 运算法一种运算法地学习下去么？我们听完人家说“持续”，于是就开始了解持续，而不去问持续为什么出现在函数式里面？亦或是不是函数式的必备要素？还是函 数式运算系统的自身的“问题”？我们正是迷失于种种语言和概念的表象，而最终没能象大师一样去思考“计算机不过是大笨象吃意大利面条”这样的抽象层面的问 题。

我们要改变的是思想，我们要增强的是能力。大多数人只是增强能力，而不改变思想。这就是“我们”——大多数人不是大师的原因。

感谢Ivar。并不仅仅是因为他给出了一个问题的答案，以及他的谦谨和微笑，还感谢他告诉我们：答案并不是表面上的正误，真正的答案是答案背后的思想。

UML关系解析思维导向图

引用解析

UML类图中5中关系的辨析(修订)

问题域、解域混合，编译时、运行时混合是这5种关系的特点。

关系	用词	问题域	解 域	编译时	运行时
Dependency	uses a	短暂的或者对非业务类的（如工具类）依赖	作用域在方法内部的reference（可能是方法参数或方法内部声明的 reference ）	作用域在方法内部的reference（可能是方法参数或方法内部声明的 reference ）	短暂的
Association	has a	相对固定的，对业务类的依赖	类属性	类属性	持续一定时间的
Aggregation	owns but may share	owns but may share	类属性	类属性	生命线可能相关联
Composition	is part of	is part of	类属性	类属性	生命线总是关联
Generalization	is a type of	is a type of	继承	继承

引用解析

UML系列学习之——关系定义

uml定义的关系主要有六种：依赖、类属、关联、实现、聚合和组合。下面对其定义和表示方法逐一说明。

依赖 （Dependency）：元素A的变化会影响元素B，但反之不成立，那么B和A的关系是依赖关系，B依赖A；类属关系和实现关系在语义上讲也是依赖关 系，但由于其有更特殊的用途，所以被单独描述。uml中用带箭头的虚线表示Dependency关系，箭头指向被依赖元素。

类属（Generalization）：通常所说的继承（特殊个体 is kind of 一般个体）关系，不必多解释了。uml中用带空心箭头的实线线表示Generalization关系，箭头指向一般个体。

实现（Realize）：元素A定义一个约定，元素B实现这个约定，则B和A的关系是Realize，B realize A。这个关系最常用于接口。uml中用空心空心箭头和虚线表示Realize关系，箭头指向定义约定的元素。

关联（Association）：元素间的结构化关系，是一种弱关系，被关联的元素间通常可以被独立的考虑。uml中用实线表示Dependency关系，箭头指向被依赖元素。

聚合（Aggregation）：关联关系的一种特例，表示部分和整体（整体 has a 部分）的关系。uml中用带空心菱形头的实线表示Aggregation关系，菱形头指向整体。

组 合（Composition）：组合是聚合关系的变种，表示元素间更强的组合关系。如果是组合关系，如果整体被破坏则个体一定会被破坏，而聚合的个体则可 能是被多个整体所共享的，不一定会随着某个整体的破坏而被破坏。uml中用带实心心菱形头的实线表示Composition关系，菱形头指向整体。

关系 J+m1d\lBu

后面的例子将针对某个具体目的来独立地展示各种关系。虽然语法无误，但这些例子可进一步精炼，在它们的有效范围内包括更多的语义。 xE- �_Fv9 l_\9J913

依赖（Dependency） > 1=].

实体之间一个“使用”关系暗示一个实体的规范发生变化后，可能影响依赖于它的其他实例（图D）。 更具体地说，它可转换为对不在实例作用域内的一个类或对象的任何类型的引用。其中包括一个局部变量，对通过方法调用而获得的一个对象的引用（如下例所 示），或者对一个类的静态方法的引用（同时不存在那个类的一个实例）。也可利用“依赖”来表示包和包之间的关系。由于包中含有类，所以你可根据那些包中的 各个类之间的关系，表示出包和包的关系。

图D

MB+a?u关联（Association） Sb^o`~ Eh

实体之间的一个结构化关系表明对象是相互连接的。箭头是可选的，它用于指定导航能力。如果没有箭头，暗示是一种双向的导航能力。在Java中，关联（图E） 转换为一个实例作用域的变量，就像图E的“Java”区域所展示的代码那样。可为一个关联附加其他修饰符。多重性（Multiplicity）修饰符暗示 着实例之间的关系。在示范代码中，Employee可以有0个或更多的TimeCard对象。但是，每个TimeCard只从属于单独一个 Employee。

图E

聚合（Aggregation） { a_&L

聚合（图F）是关联的一种形式，代表两个类之间的整体/局部关系。聚合暗示着整体在概念上处于比局部更高的一个级别，而关联暗示两个类在概念上位于相同的级别。聚合也转换成Java中的一个实例作用域变量。 7MIrrhk
yC7lR#N8j0
关联和聚合的区别纯粹是概念上的，而且严格反映在语义上。聚合还暗示着实例图中不存在回路。换言之，只能是一种单向关系。

图F

V`}u:t7r xn a合成（Composition） {/i&o

合成 （图G） 是聚合的一种特殊形式，暗示“局部”在“整体”内部的生存期职责。合成也是非共享的。所以，虽然局部不一定要随整体的销毁而被销毁，但整体要么负责保持局 部的存活状态，要么负责将其销毁。局部不可与其他整体共享。但是，整体可将所有权转交给另一个对象，后者随即将承担生存期职责。

Employee和TimeCard的关系或许更适合表示成“合成”，而不是表示成“关联”。

图G

泛化（Generalization） _% i!LyG

泛化（图H）表示一个更泛化的元素和一个更具体的元素之间的关系。泛化是用于对继承进行建模的UML元素。在Java中，用extends关键字来直接表示这种关系。

图H

= oTj3+7 实现（Realization） 3\K;y>NK

实例（图I）关系指定两个实体之间的一个合同。换言之，一个实体定义一个合同，而另一个实体保证履行该合同。对Java应用程序进行建模时，实现关系可直接用implements关键字来表示。

图I

引用解析1

常见的关系有：一般化关系（Generalization），关联关系（Association），聚合关系（Aggregation），合成关系（Composition），依赖关系（Dependency）。 其中，聚合关系（Aggregation），合成关系（Composition）属于关联关系（Association）。

一般关系表现为继承或实现关系(is a)，关联关系表现为变量(has a )，依赖关系表现为函数中的参数(use a)。

一般化关系：表示为类与类之间的继承关系，接口与接口之间的继承，类对接口的实现关系。
表示方法： 用一个空心箭头＋实线，箭头指向父类。或空心箭头＋虚线，如果父类是接口。

关联关系：类与类之间的联接，它使一个类知道另一个类的属性和方法。
表示方法：用 实线＋箭头， 箭头指向被使用的类。

聚合关系：是关联关系的一种，是强的关联关系。聚合关系是整体和个体的关系。关联关系的两个类处于同一层次上，啊聚合关系两个类处于不同的层次，一个是整体，一个是部分。
表示方法：空心菱形＋实线＋箭头，箭头指向部分。

合成关系：是关联关系的一种，是比聚合关系强的关系。它要求普通的聚合关系中代表整体的对象负责代表部分的对象的生命周期，合成关系不能共享。
表示方法：实心菱形＋实线＋箭头，

依赖关系：是类与类之间的连接，表示一个类依赖于另一个类的定义。例如如果A依赖于B，则B体现为局部变量，方法的参数、或静态方法的调用。
表示方法：虚线＋箭头

引用解析2

1依赖：最弱的关系，A依赖B，就是说A的声明或者实现必须include B类的头文件。

2关联：在设计模式中叫做‘相识’。具有这种关系的两个类彼此没有拥有关系，并且互相之间没有创建和销毁的责任，只是存在某种调用关系。

3聚集：和关联比较想象，A聚集B的确切含义指：A类的某个成员是B类实例的指针，B类对象实例不是在构造A对象时隐含构造的，必须通过其它途径构造，但是在A类对象析构的时候必须析构B类对象实例。

4包含：实际上是值聚集，A包含B的确切含义指：A类的某个成员是B类的对象实例，A类构造时同时构造B类，A类析构时也必须析构B类。

5继承：较容易理解。

参考资料

• UML系列学习之——关系定义
  
• http://fluagen.blog.51cto.com/146595/46634
• UML系列学习之——关系定义

这是一个Beta版的文档，随时可能会更新和完善。