UML的类图

在visio中这个称为静态结构图。

两年前我就买过一本UML。当时很起劲，还拉了一个朋友一起探讨code generation技术，UML的一个非主流的流派就是xUML， executable UML，换言之就是让UML可以自动生成可执行的程序。因为UML是平台无关的东西，这个想法很有吸引力，如果可行，程序员就不必探究平台差异的编程了。

UML的起源很复杂，所以学习UML就象学习计算机网络一样，林林总总的标准和意图，让这个技术变得不那么纯粹，甚至是颇为混乱。同样和网络一样，UML也是由为了解决很多工程上实际遇到的问题出现的，它更像一箱子组合工具而不是一把万能工具。

我一直被这样的问题困扰着：随着程序不断膨胀，类和函数越来越多，文件也越来越多；类之间的关系让人很头疼，无论代码还是文档都不直观。我也尝试过用powerpoint和mindmanager画了很多图，仍然不方便，所以这两天又把UML的书翻出来看了看。有点心得了。

好处：
1。UML类图可以很好的给程序结构一个总览。这是其他工具很难做到的。
2。UML有关于类之间的关系的严格定义，这比MindManager或者Powerpoint流程图那种不规范的东西好的多，规范的一个好处就是强迫你去按照严格的逻辑去思考，而不是在字面的意思上较劲。

缺点：
1。UML关于关系的定义需要花满多时间去学习。
2。UML并不是能表达所有的关系

底限：
1。不要试图把代码中的所有东西都放到UML中去，一些一望可知的东西和次要的东西不必放进去。
2。UML的目的是帮助理解代码，而不是和代码建立严格的逻辑关系或者生成代码，简单、直观、没有歧义是最重要的。

UML类图对开发进度的管理也因该有很大帮助，可以在代码和UML图之间往返工作：

1。先根据文档想清楚关键的算法和逻辑
2。在UML中画出除了基础类之外的类，尤其是那些需要在不同类之间作为参数传递的类，在开始的时候就统一一下，不要在写程序的时候不断添加这样的类。
3。把这张图画的平衡一些，把一些很小的、有强依赖关系的类合并到其他类中去，可以作为一个public成员存在。这样可以有效减少类之间的关系数量。
4。仔细考虑一下那些会很很多的类打交道的类，看看这样的类是不是功能很单一，是不是可以作为一个包中最大的容器类的一个函数存在，而不是作为一个类存在。

减少类之间的关系有助于理解和简化结构，当然，不能为了这个目的把类中大量添置操作，把不相关的操作都放到一个类中去，这也违反封装的独立性原则。要平衡类的操作数量和类的关系数量。