浅谈UML在软件工程中的应用

谈到UML在软件工程中的应用，首先要谈一下为什么软件开发需要建模。如果想搭一个狗窝，备好木料、钉子和一些基本工具之后，就可以开始工作了，在没有别人帮忙的情况下，几个小时也可以完工；如果想为家庭建造一所房子，备好木料、钉子和一些基本工具之后，也能开始工作，但这将需要较长的时间，并且，除非曾经多次建造过房子，否则就需要事先制定出一些详细的计划，再开始动工，才能够成功；而如果要建设高楼时，仍然是先备好木料、钉子和一些基本工具就开始工作，那将是非常愚蠢的。 那么在软件开发中，如果我们不事先建立模型，做好计划，就开始仓促去实现，那就好比在使用建造狗窝的工具来建造一座大厦。而建模是一项经过检验并被广为接受的工程技术，模型提供了系统的蓝图。模型可以是结构性的，强调系统的组织。它也可以是行为性的，强调系统的动态方面。因此在软件工程中建模时非常重要的。

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

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项目已经离成功不远了。