UML抽象、简洁、高于Java、C++诸等高级程序设计语言之上的形象表达，可以让我们真切领略到蕴藏于软件那纷繁芜杂的细节表面之后的一份简单、和谐之美。

软件究竟是什么？有很多比喻可以形容。静态的软件就像一座虚拟的建筑（Architecture），而运动时的软件有时就像一部开动的虚拟机器，或多条柔性的工厂流水线（进程与线程），有时又像一种虚拟的生物，可以肆意的复制和生长（比如软件病毒）。

过去有一种说法认为：程序 = 算法 + 数据结构，如今看来这种旧结构化时代的观点是不准确、不全面的，在新结构化时代我们至少可以得出这样大致的公式：程序 = 算法 + 软件结构 + 数据结构，在这里我们强调软件结构不同于数据结构，软件是操纵数据的程序，而软件结构（包括架构和设计模式）的质量对软件的质量同样具有决定性的影响。

过去这15年无疑是面向对象（OO）软件的天下，世界软件开发早已进入了OO时代。

人们知道，高质量的好软件是设计出来的，而软件的设计目前依然主要依赖于人们大脑的思考和判断，人类大脑的思考过程恰是一个对现实世界以及虚拟世界建模的过程。

而作为OO建模技术的事实上工业标准，统一建模语言（UML）正好为我们提供了一个运用OO思维进行软件建模和设计的工具。

UML 1.4.2成为正式国际标准ISO/IEC 19501是软件设计史上的一个重要事件，UML标准成熟之后的研发进展也比较顺利，当前最新版本为2.1。

UML有什么用？作为一种建模“语言”，促进沟通是一项基本功能，然而很多人忽视了UML独立于传统具象编程语言、擅长表达抽象OO概念的一大特点。

事实上，熟练掌握UML能够帮助我们的大脑学会快速、敏捷地运用OO方式进行思考。UML标准及其相关技术不但是近10年来各工程领域OO软件设计与建模的利器，还是当前表达软件设计模式最形象和最有效的工具。

在我看来，学会运用UML思考，抽象地用UML表达软件架构和设计方案，从而能透过现象看本质，是当今任何一名软件架构师乃至普通OO程序员都应该尽快掌握的基本功。所以，这几年世界各地的大专院校纷纷把OOAD/UML列为一门软件工程专业的必修课也在情理之中了。

建模（modeling）并不是软件行业所特有的做法，建模几乎是几千年来人类所有工程行业所共有的一项最佳实践。为什么我们要对软件建模？因为软件太复杂，难以理解和掌握，我们需要一种能够简单而深刻地反映软件设计本质的方法和工具。如何建模？就像对待建筑模型、机械模型一样，软件也是一个多面体（虚拟的），我们也需要选择视点、视角和视图，对模型做投影、做切片。Kruchten 博士提出的著名的 4+1 视图（逻辑视图、实现视图、构件视图和进程视图，再加上用例视图）为我们利用UML对复杂软件的结构和行为建模提供了很好的指导。

软件设计和UML建模既然那么重要，有什么简单易学、提纲携领的好方法、好原则吗？我曾经编写了一首建模口诀，多次在讲课咨询时与客户、学员们分享交流，取得了很好的效果。

这首太极建模诗（或叫十六字OO建模口诀）受到了Larman（《UML和模式应用》）、Cockburn（《编写有效用例》）、3 Amigos（《UML用户指南》）等世界级专家们睿智大作的启发，也凝结了我10多年来从事OO设计和编程的一点小小感悟。

我发现“外与内，高与低，静与动，粗与细”等基本二元辩证关系，不但适用于软件用例需求的建模，也适用于软件架构的OOAD/UML 建模。

当然，软件设计中的二元关系还远不止这些。充满了二元辩证、平衡之道的现代软件工程，竟然与两千年前中国古典哲学《阴阳太极》中的黑、白对立统一相暗合，这真的是历史的巧合，还是科学的必然？

由外而内

外与内，即软件系统本身与其外部环境的关系，大概是软件开发中最根本的一对关系。在软件开发之初需求调研时，我们通常视整个软件系统为一个黑盒子，我们划地为界，从系统外部来观察软件提供给其各个用户的功能，以及它与外部环境的各种动态关系（包括彼此之间的行为交互和信息数据的交换）。这种方法可以用UML用例图表示如下：

以银行证券帐户管理系统（类似于“银证通”）为例，图中用例“打印帐户报告!”的需求简述是：

主用角：用户

辅用角：外汇交易中心、证券交易所

范围：证券账户管理系统

层次：用户目标层

后置条件：系统打印客户帐号下已购买的所有币种的证券清单，包括每支证券的单价、份数、余额以及该客户账户下的资产总额（转换成用户指定的币种，缺省情况下为美元）。

前置条件：用户已登录，客户的账户、帐号已知。

触发事件：用户选择打印账户报告（证券余额清单）。

基本流：

1.用户根据系统提示选择结算币种（用于计算资产总额），缺省值为美元。

2.系统读取该客户帐号下的所有证券信息，打印每支证券的名称、份数、单价和总价（即证券余额，等于单价 * 份数），总价用原币种表示。

3.系统根据该账户下的证券币种读取相应的结算汇率，把所有证券余额都统一转换成结算币种，并通过累加该账户下所有证券的余额，计算出以结算币种表示的客户资产总额并打印输出。

扩展流：

2a.读取证券信息（份数、价格）失败;

2a1.系统报错，用例结束。

3a.读取汇率失败（某支证券的币种到结算币种的转换汇率不存在）：

3a1.系统告知用户结算汇率不存在，无法计算资产总额，用例结束。

明确需求后，当我们打开软件系统这只盒子，进入它的内部，把盒子内的一切东西、机关要害都搞清楚、弄明白，也就完成了软件开发从需求，到分析，到设计，到编程实现的这么一个过程，而我们最终送给客户的必须是一个高质量的大礼包。

那么，这只盒子内部有何宝物呢？由外而内，由大而小，一个软件分别由系统，子系统（subsystem）与构件（component），以及对象组成。一个系统由一个或多个子系统组成，而一个子系统可以由一个或更多的子系统（或构件）组成。构件里面装的则是对象，对象又由属性和方法（即通常所说的函数）组成。类（对象）正是现代软件的最小组成单元，就像组成有机人体的基本单元——细胞。

下图用UML包图表现了这样一种软件系统的嵌套解剖视图。

层次分明

“分而治之”是工程界对付复杂技术问题最常用的手段。作为一个复杂的系统，软件也不例外，清晰而严谨分层的结构往往是优秀软件设计的一个主要特征。

分层有横切、纵切两种。软件设计从系统，到子系统和构件，再到类与对象，再到类的内部属性和方法，以及某个方法的编程实现，既是由外而内，也是从高到低，从高层的架构设计（系统、子系统），到低层的类与类的关系、类内部的设计，就像山脉与山峰、森林与树叶的关系。

对应着这样的高、低层关系，在软件设计中，目前世界上已有大量的架构模式、设计模式、实现模式和各种分层的框架可供我们借鉴、重用。

动静结合

经常有初学者问：用UML建模的时候，我们到底要画几张图才算表达完整，哪些图最重要？其实有一个非常简单的回答:动静结合。客观世界是由物质（如微观粒子）组成的，而物质是运动的。

巧合的是，软件这个虚拟世界也不例外。因此在我们设计软件的时候，既要说明有哪些物质（如构件、对象、属性等）存在，也不要忘了描述物质之间的运动（如交互、状态变迁等），两者是相辅相成的。

以下我们展现了参与“打印帐户报告!”用例实现的主要对象之间，为了完成这一功能所结成的静态关系（用UML类图表示）和动态关系（我们选择了UML协作图）。

事实上，只有细致考虑了对象之间的静态和动态关系（不管利用何种媒介，大脑抑或文档），我们的软件设计才算是完整的，编程才有正确的依据。不然，您的程序代码从何而来？

逐步求精

软件开发从软件的需求（问题域）到可执行的高级程序设计语言源代码（解决域），这中间究竟经历了多少思考步骤和权衡过程？是一步到位吗？

实际上宏观地从软件需求，到代码实现;软件设计中的从分析对象，到设计对象，再到实现对象，或者从设计模式到模式的编程实现，这些都是一个逐步求精的过程。

结束语

UML建模对于软件设计的重要性，对于一名老练的OO程序员来说，是不言而喻的。

UML作为一种图形化建模语言规范，凝聚了世界上许多大师级OO建模、设计专家多年来的宝贵经验，它的表达手段异常灵活和丰富，面对UML 2.x十几种图符，希望我与Craig Larman大师合作的《太极建模诗》能给读者朋友们带来一些有效的帮助。

图1：银行证券账户管理系统用例图

图2：UML包图

协作图

协作图用于显示组件及其交互关系的空间组织结构，它并不侧重于交互的顺序。协作图显示了交互中各个对象之间的组织交互关系以及对象彼此之间的链接。与序列图不同，协作图显示的是对象之间的关系。

另一方面，协作图没有将时间作为一个单独的维度，因此序列号就决定了消息及并发线程的顺序。协作图是一个介于符号图和序列图之间的交叉产物，它用带有编号的箭头来描述特定的脚本，以显示在整个脚本过程中消息的移动情况。

图3：UML类图

图4：UML协作图

用例图

用例图（use case diagram）就是由主角、用例以及它们之间的关系构成的图。该图说明了用例模型中的关系。可以将用例图组织到用例包中，并归用例包所有，让特定包中仅显示互为关联关系的内容。

用例图由参与者（Actor）、用例（Use Case）、系统边界、箭头组成，用画图的方法来完成。

参与者不是特指人，是指系统以外的，在使用系统或与系统交互中所扮演的角色。因此参与者可以是人，可以是事物，也可以是时间或其他系统等等。还有一点要注意的是，参与者不是指人或事物本身，而是表示人或事物当时所扮演的角色。

组织简介 | 联系我们 |   Copyright 2002 ®  UML软件工程组织 京ICP备10020922号

京公海网安备110108001071号