古今之成大事业、大学问者，必经过三种之境界，今之UML应用的三重境界能给你带来什么呢？本文主要讨论了两个问题：一是为什么软件开发过程需要建模，二是建模为什么要使用UML语言。

先从几年前的一次争论谈起吧。2002年5月某IT杂志刊登了一篇知名学者高展先生的文章：《UML三大“硬伤”》，文章说UML“上不着天、下不着地、一盘散沙”，后即引来业界关于UML的一场大讨论。

在细述这场论战之前，且让我们先来回答两个问题，第一个问题是为什么软件开发过程需要建模，第二个问题是建模为什么要使用UML语言。

想搭一个狗窝，备好木料、钉子和一些基本工具之后，就可以开始工作了，在没有别人帮忙的情况下，几个小时也可以完工；如果想为家庭建造一所房子，备好木料、钉子和一些基本工具之后，也能开始工作，但这将需要较长的时间，并且，除非曾经多次建造过房子，否则就需要事先制定出一些详细的计划，再开始动工，才能够成功；而如果要建设高楼时，仍然是先备好木料、钉子和一些基本工具就开始工作，那将是非常愚蠢的。

那么在软件开发中，如果我们不事先建立模型，做好计划，就开始仓促去实现，那就好比在使用建造狗窝的工具来建造一座大厦。而建模是一项经过检验并被广为接受的工程技术，模型提供了系统的蓝图。模型可以是结构性的，强调系统的组织。它也可以是行为性的，强调系统的动态方面。

通过建模，可以达到4个目的：模型有助于按照实际情况或按照所需要的样式对系统进行可视化；模型能够规约系统的结构或行为；模型给出了指导构造系统的模板；模型对做出的决策进行文档化。

下面让我们来到文章开头提到的那场论战。论战的发起者高先生也许当初也没有想到文章发表之后引来的激烈反应。综合高先生那篇文章的主旨，可以概括为UML“上不着天，下不着地，一盘散沙”，他认为：UML上不着天，也就是说用UML建立的模型无法与用户沟通；下不着地，采用UML设计的模型不能为程序员所用；一盘散沙，UML建立的各种模型之间关系凌乱，无法实际应用。

我的看法是，高先生此三点意见却恰恰就是UML的三大优点，关键在于应用。如果使用不好，则在应用过程中是会发生这样的错觉，认为使用了UML反而会给项目带来额外的负担；但是如果能有效地根据实际项目和人员情况对UML进行裁减，制定出适合的UML应用方法，并通过项目来逐步积累和推进，那么UML这个神兵宝器则会大放异彩，体现它应有的价值。就譬如金箍棒，倘若等闲之辈得之，不过是废铁一块；如若在悟空手中，则大如倚天之柱，小则化为绣花针，降妖除魔，变为至宝。

那么如何能有效利用UML呢？就如王国维所谈词作的三重境界，UML的利用也可以分为三种境界。

王国维在《人间词话》里谈到：“古今之成大事业、大学问者，必经过三种之境界：‘昨夜西风凋碧树。独上高楼，望尽天涯路’。此第一境也。‘衣带渐宽终不悔，为伊消得人憔悴。’此第二境也。‘众里寻他千百度，蓦然回首那人却在，灯火阑珊处’。此第三境也。”

第一重境界：雾里看花

属于UML的初级应用，对UML有了初步的一点了解，知道了用例图，类图，能画出简单的时序图、协作图等。初入UML的世界，各种图型的特性、适用范围、图形元素的功用都还一知半解，而UML庞大的体系足以让初入者无从着手，就好比驾一扁舟，漂游于大海之上，“望尽天涯路”而不知所归。在第一重境界的应用所要完成的目标是达到与客户的需求沟通，即解决前文所说的“上不着天”的问题。在初级阶段，如果能拥有扎实的面向对象设计基础，同时配合以良好的UML工具，那么可以很快度过这个阶段，来到下一重境界。

第二重境界：小楼一夜听春雨

从第一重境界的迷茫中走过来了，当然这是一个痛苦的过程，不然为何“衣带渐宽”呢。如果说在第一个阶段的UML应用是属于局部范围的应用，那么到第二重境界，则是全局的利用UML了。在这个阶段，开始初窥UML的奥妙，不仅可以借助于UML的用例图、时序图等完成与用户的需求沟通，而且在此基础上，可以使用UML的类图、交互图、部署图、组件图等指导程序员进行开发。在第二重境界下，解决了前文所说的“下不着地”的问题 。

第三重境界：如鱼得水

随着UML的项目实践增加，软件组织也在不断的成长。明白了UML只是一种方法，而独立于过程，在实践中，UML是贯彻整个软件开发过程，解决了“一盘散沙”的问题。通过在前期需求分析阶段形成的业务用例模型，通过细化，进一步描述业务的细节，并且通过UML的类图、交互图等可以建立目标系统的逻辑模型。而UML应用的最高层次则是将UML作为一种“高高级”语言，实现从目标系统逻辑模型向物理模型的直接转换。

通过在现有的高级语言基础上描述业务过程，而UML编程语言的编译器则可以实现UML语言的编译执行，这也是当前MDA（Model Driven Architecture, 模型驱动架构）所追求的目标。

可以说，UML对系统模型的表达能力超出了以往任何一种面向对象的分析和设计方法。随之出现的问题是，它的复杂性也超出了以往任何一种方法。由于UML的复杂性，对它的掌握和使用确实不是一件轻松的事。因此，从初入“雾里看花”的第一重境界，并逐步进入到“如鱼得水”是一个循序渐进的过程，是一个逐步学习，逐步应用与提高的过程。

首先，UML是一个复杂的体系，而且为了能够灵活的适应各种项目的需要，增加了很多符号，而并不是每一个项目都需要使用到这些符号。为了成功使用UML，在使用的过程中必须流程化使用，针对不同的项目实际情况，对UML符号进行裁剪。当然，这也意味着几乎任何项目都可以使用UML来建模。

第二，需要保持项目组对UML的统一一致的理解，这是建模成功的保障。毕竟，现在大型项目都是几十个甚至成百上千的人员牵涉其中，要确保负责设计与开发人员对UML的各种符号有统一的理解，不然，UML不但不能起到沟通桥梁的作用，反而会导致信息传递的失真。可以通过项目组的培训等方式来实现。

第三，简单有效才是最重要的。一般说来，项目组成员的设计分析能力、以及对UML的理解使用能力是层次不一的，即使通过培训能提高部分程序员的水平，但是，经验、阅历这是不能通过培训来解决的。因此，只有保持最简单有效的过程，使用最简单的UML图形，才能使得UML的应用达到最佳的效果。而如果我们为了详尽的描述一个用例，使用了一系列完整的时序图、协作图、状态图、部署图、用例图和类图，这样，可能导致一个团队完全脱离面向对象分析和设计。

第四，抉择画图。画UML图是一种非常有用的活动，它也可能成为一种浪费时间的、可怕的活动。不需要制定什么都必须画图的规则，因为这样的规则将比不用更糟糕。项目的大量时间和精力将会被浪费在追逐那个根本没有人去读的图上。下面列举了需要画图的情况：

当许多人一起需要同时进行开发时，这些人需要都理解一个系统的特定部分的设计结构时，开始画图。当所有的人都已经声明理解了的时候，结束画图。

当两个人或更多人不同意一个特定的元素如何设计的时候，需要团队意见一致的时候，要找一个时间进行讨论做出决定，比如投票，或一个公正的宣告的方式进行，这时需要画图。当决定做出来后，擦掉这些图。

当需要探讨一个设计的想法时，画图能够帮我们更好地思考。当得到了能够帮助我们完成思考的代码的要点的时候，扔掉这些图。

当需要向其他人或自己解释一部分代码的结构的时候，可以画图。当觉得其实最好看代码来进行解释的时候，停止画图。

当项目快要结束，顾客需要我们将图与其他文档一起提供的时候，开始画图。

在项目中使用UML，需要时刻记住的是保持简单，并且结合软件工程文档，同时让项目组对过程有统一的认识。很多成功的项目都采用用例驱动，迭代，递增方法的。如果能把过程细化并且让项目组掌握技巧，那么UML项目已经离成功不远了。

系统开发过程

UML简介

UML起源于面向对象的分析与设计方法。

在80年代末至90年代中，对面向对象分析与设计方法的研究发展到一个高潮。但是，诸多流派在思想和术语上有很多不同的提法，在术语、概念上的运用也各不相同，需要一种统一的符号来描述面向对象的分析和设计活动。UML应运而生。它不仅统一了Booch、Rumbaugh和Jacobson的表示方法，而且有进一步的发展，最终成为大众所共同接受的标准建模语言。

UML是一种定义良好、易于表达、功能强大且普遍适用的建模语言。它融入了软件工程领域的新思想、新方法和新技术。不仅支持面向对象的分析与设计，还支持从需求分析开始的软件开发全过程。