UML统一建模基础教程[图书]

2.1.1类的含义 17
2.1.2消息和事件 17
2.1.3面向过程 18
2.2面向对象的特征 19
2.2.1抽象19
2.2.2封装20
2.2.3继承21
2.2.4多态22
2.3面向对象的开发 22
2.3.1系统调查和需求分析 23
2.3.2面向对象分析 23
2.3.3面向对象设计 26
2.3.4面向对象实现 27
2.4基于 UML的面向对象建模29
2.5扩展练习29
第 3章建模工具 Rational Rose 30
3.1Rational Rose的基础知识30
3.2Rational Rose的安装 32
3.3Rational Rose的使用 34
3.3.1Rational Rose的启动界面34
3.3.2Rational Rose的主界面36
3.3.3Rational Rose的常用操作41
3.4Rational Rose的 4种视图模型 50
3.4.1用例视图 51
3.4.2逻辑视图 55
3.4.3部署视图 60
3.4.4构件视图 61
3.5利用 Rational Rose生成代码 63
3.5.1生成代码的方法63
3.5.2逆向工程 68
3.6扩展练习69
第 4章初识 UML71
4.1UML的构成71
4.1.1视图71
4.1.2图72
4.2模型元素74
4.2.1事物74
4.2.2关系78
4.3通用机制79
4.3.1规格说明 79
4.3.2UML的修饰79
4.3.3通用划分 80
4.4UML中的扩展机制 80
4.4.1体系结构 81
4.4.2构造型85
4.4.3标记值88
4.4.4约束89
4.5对象约束语言 91
4.5.1OCL概述91
4.5.2OCL的标准类型92
4.5.3OCL的表达式 97
4.5.4OCL的应用 98
4.6扩展练习99
第 5章用例图100
5.1用例图的概念100
5.1.1参与者 100
5.1.2用例102
5.2参与者之间的关系 103
5.3用例的确定104
5.3.1识别用例104
5.3.2用例粒度105
5.3.3用例规约105
5.3.4用例间的关系类型 106
5.4系统边界 109
5.5绘制用例图110
5.5.1创建用例图 111
5.5.2绘制参与者112
5.5.3绘制用例114
5.5.4绘制用例和参与者的关系 115
5.5.5绘制用例间的关系 116
5.6用例图建模实例——图书管理系统用例图117
5.6.1需求分析117
5.6.2识别参与者117
5.6.3识别用例118
5.6.4构建用例模型 119
5.7扩展练习 120
第 6章类图和对象图122
6.1类图 122
6.1.1类图的概念122
6.1.2类的组成123
6.1.3类的类型128
6.1.4类的构造型128
6.2类图中的关系130
6.3类图到数据库的转换 134
6.3.1基本映射转换 134
6.3.2类到表的转换 136
6.3.3关系的转换139
6.3.4完整性与约束验证 140
6.3.5父表的约束140
6.3.6子表的约束141
6.4对象图 141
6.4.1对象图的概念 141
6.4.2对象图中的对象 142
6.4.3对象图中的链 143
6.5绘制类图 143
6.5.1类图和类的绘制 143
6.5.2类关系的绘制 152
6.6绘制对象图154
6.7类图和对象图的建模实例——图书管理系统 155
6.7.1确定系统中的类 155
6.7.2确定类的属性和操作156
6.7.3确定类的关系 157
6.7.4根据类图绘制对象图158
6.8扩展练习 158
第 7章包图160
7.1包图的概念160
7.1.1模型的组织结构 160
7.1.2包和包图161
7.2包的构成 162
7.2.1包的名称163
7.2.2包的元素163
7.2.3包的可见性163
7.2.4包的构造型164
7.2.5包的子系统165
7.3包图中的关系166
7.3.1依赖关系166
7.3.2泛化关系168
7.4包的嵌套 168
7.5绘制包图 169
7.5.1包的创建169
7.5.2包中类的添加 171
7.5.3绘制包的关系 172
7.6包图的建模实例——图书管理系统包图 172
7.6.1确定包的分类 172
7.6.2确定包的关系 173
7.7扩展练习 173
第 8章序列图174
8.1序列图的概念174
8.2序列图的组成175
8.2.1对象175
8.2.2生命线 176
8.2.3激活177
8.2.4消息177
8.3序列图的对象行为 179
8.3.1创建与销毁对象 179
8.3.2分支与从属流 180
8.4绘制序列图180
8.4.1创建序列图181
8.4.2创建对象182
8.4.3绘制和设置消息 184
8.4.4绘制生命线186
8.4.5销毁对象188
8.5序列图的建模实例——系统管理员添加图书序列图 188
8.5.1需求分析188
8.5.2确定序列对象 189
8.5.3完成序列建模 190
8.6扩展练习 190
第 9章协作图193
9.1协作图的概念193
9.2协作图的组成195
9.2.1对象195
9.2.2消息195
9.2.3链 196
9.3绘制协作图196
9.3.1协作图的创建 197
9.3.2对象的创建198
9.3.3链和消息的创建 200
9.3.4序列图和协作图的转换201
9.4协作图的建模实例——系统管理员添加图书协作图201
9.4.1创建协作图的步骤 202
9.4.2需求分析202
9.4.3确定协作图元素 202
9.4.4确定元素之间的关系203
9.4.5创建完整的协作图 203
9.5扩展练习 204
第 10章活动图 206
10.1活动图的概念 206
10.2活动图的组成元素208
10.2.1 动作状态 208
10.2.2 活动状态 208
10.2.3 组合状态 209
10.2.4 分支与合并 209
10.2.5 分叉与结合 210
10.2.6 泳道 211
10.2.7 对象流 211
10.3活动图的绘制 213
10.3.1 创建活动图 214
10.3.2 绘制初始和终止状态 215
10.3.3 绘制动作状态215
10.3.4 绘制活动状态216
10.3.5 绘制泳道 218
10.3.6 绘制转换 219
10.3.7 绘制分支 220
10.4活动图的建模实例——借阅者借书活动图 221
10.4.1 确定需求分析221
10.4.2 确定用例路径222
10.4.3 完成活动图创建223
10.5扩展练习223
第 11章状态图 225
11.1状态图的概念 225
11.1.1状态机225
11.1.2状态图226
11.2状态图的组成 228
11.2.1状态 228
11.2.2转换 231
11.2.3判定 234
11.2.4同步 235
11.2.5事件 236
11.2.6初始状态和终止状态237
11.3状态图的绘制 237
11.3.1创建状态图 238
11.3.2绘制初始和终止状态239
11.3.3绘制状态 239
11.3.4绘制转换 240
11.3.5绘制事件 241
11.3.6绘制动作 241
11.3.7绘制监护条件242
11.4状态图的建模实例——图书状态图 243
11.4.1确定状态间的实体 243
11.4.2确定状态图中实体的状态 243
11.4.3确定相关事件244
11.5扩展练习244
第 12章构件图和部署图 246
12.1构件图的概念 246
12.1.1 构件 246
12.1.2 接口 249
12.1.3 关系 250
12.2构件图的绘制251
12.2.1 创建构件图 251
12.2.2 创建构件 253
12.2.3 绘制构建关系254
12.3部署图的概念 254
12.4部署图的组成 255
12.4.1 节点 255
12.4.2 连接 256
12.4.3 设备 256
12.5部署图的绘制 257
12.5.1 绘制节点 257
12.5.2 设置节点 258
12.5.3 绘制连接 260
12.6构件图和部署图的建模实例——图书管理系统261
12.6.1 确定系统构件图261
12.6.2 确定系统部署图262
12.7扩展练习264
第 13章Rational统一过程265
13.1软件开发过程的概念265
13.2 Rational统一过程的概念266
13.3 Rational统一过程的结构268
13.3.1 核心工作流 269
13.3.2 迭代开发模式270
13.4 Rational统一过程的最佳实现 271
13.4.1 软件变更控制271
13.4.2 软件质量验证271
13.4.3 建立可视化的软件模型 272
13.4.4 基于构件的架构应用 272
13.4.5 需求管理 273
13.4.6 迭代式软件开发274
13.5 Rational统一过程的开发模型275
13.5.1 动态开发 275
13.5.2 静态开发 280
13.5.3 面向架构的过程281
13.6 Rational统一过程的配置和实现 283
13.6.1 Rational统一过程的配置284
13.6.2 Rational统一过程的实现 284
13.7扩展练习285
第 14章学籍管理系统286
14.1系统需求分析 286
14.2系统建模288
14.2.1 创建系统用例模型 289
14.2.2 创建系统静态模型 291
14.2.3 创建系统动态模型 294
14.2.4 创建系统部署模型 305
附录 A 新闻发布系统308
A.1需求分析308
A.2系统建模308
A.3创建系统动态模型 310
A.4创建系统部署模型 313
附录 B 网上教学系统315
B.1 需求分析315
B.2 系统建模315
B.3 创建系统动态模型 318
B.4 创建系统部署模型 320
附录 C 网上购物商店321
C.1 需求分析321
C.2 系统建模322
C.3 创建系统动态模型 324
C.4 创建系统部署模型 326
附录 D 汽车租赁系统328
D.1需求分析328
D.2系统建模328
D.3创建系统动态模型 330
D.4创建系统部署模型 333
附录 E 超市管理系统335
E.1 需求分析335
E.2 系统建模335
E.3 创建系统动态模型 338
E.4 创建系统部署模型 340

.　　鸣谢
　　本书主要由刘小松编写，此外，王坚宁、胡书敏、王相羽、袁润非、杨阳、王炳乾、苏宝保、张琴、李龙、王华、李辉、刘峰、徐浩、李建国、马建军、唐爱华、苏小平、朱丽云、马淑娟、周毅、张乐、李大勇、许小荣、魏勇、王云等同志也参与了本书的部分编写工作。
　　由于作者水平有限，书中错误、纰漏之处难免，欢迎广大读者、同仁批评斧正。
　　
　　编者
　　2014年 3月
　　

.　　到了 20世纪 60年代末期，软件危机已相当严重，这促使计算机领域的科学家们开始探索缓解软件危机的方法。他们提出了“软件工程”的概念，即利用现代工程的原理、技术和方法进行软件的开发、管理、维护和更新。于是，开创了计算机科学技术的一个新的研究领域。1968年，北大西洋公约组织召开计算机科学会议，由 Fritz Bauer首次提出了“软件工程”的概念。
　　软件工程是一门研究如何用系统化、规范化、数量化等工程原则和方法去进行软件的开发和维护的学科。它应用计算机科学、数学及管理科学等原理，借鉴传统工程的原则和方法创建软件以达到提高质量、降低成本的目的。其中，计算机科学和数学用于构造模型与算法；管理科学用于计划、资源、质量和成本等的管理。软件工程包括两方面内容：软件开发技术和软件项目管理。
　　软件开发技术包括软件开发方法学、软件工具和软件工程环境。
　　软件项目管理包括软件度量、项目估算、进度控制、人员组织、配置管理、项目计划等。
　　1.1.2 软件工程的内容和基本原理
　　软件工程研究的主要内容是软件开发技术和软件开发管理两个方面。在软件开发技术中，主要研究软件工程方法、软件工程过程、软件开发工具和环境。
　　软件工程方法为软件开发提供了“如何做”的技术。它包括了多方面的任务，如项目计划与估算、软件系统需求分析、数据结构、系统总体结构的设计、算法的设计、编码、测试以及维护等。软件工程方法常采用某种特殊的语言或图形的表达方法，以及一套质量保证标准。
　　软件工程过程是将软件工程的方法和工具综合起来以达到合理、及时地进行计算机软件开发的目的。软件工程过程定义了软件工程方法的使用顺序、要求交付的文档资料，为保证质量和协调变化所需要的管理及软件开发各个阶段完成的里程碑。
　　软件开发工具和环境为软件工程方法提供了自动的或半自动的软件支撑环境。目前，人们已经开发出了许多软件工具来支持上述的软件工程方法，而且已经有人把诸多软件工具集成起来，使得一种工具产生的信息可以被其他的工具所使用，从而建立起一种称为计算机辅助软件工程（CASE）的软件开发支撑系统。 CASE将各种软件工具、开发机器和一个存放开发过程信息的工程数据库组合起来形成一个软件工程环境。
　　对于软件工程基本原理，早在 1983年，B.W.Boehm归纳提出了 7条基本原则。
　　1．利用分阶段的生命周期计划严格管理
　　有人统计过，在不成功的软件项目中有 50%左右是由于计划不周造成的。应该把软件生命周期划分为若干阶段，并制定出相应的切实可行的计划，严格按照计划对开发和维护进行管理。B.W.Boehm认为，应制定和严格执行 6类计划：项目概要计划、里程碑计划、项目控制计划、产品控制计划、验证计划、运行维护计划。
　　2．坚持进行阶段评审
　　设计的错误占软件错误的 63%，编码错误只占 37%，而且在后期纠正错误的代价非常高，因此，必须严格坚持阶段评审，及早发现和纠正错误。
　　3．实行严格的产品质量控制
　　在现实中由于外部原因或要求对需求等进行修改是难免的，但必须有严格的管理制度和措施。
　　4．采用现代程序设计技术和软件工程技术
　　5．结果应能清楚地审查
　　多年来，人们一直致力于研究新的程序设计技术，例如结构化程序分析（Structured Analysis）和结构化设计（ Structured Design）等。
　　由于软件是一种看不见摸不着的逻辑产品，对它的检验和审查很困难。因此，应提供可视化的检验标准和方法。
　　6．开发人员应少而精
　　软件开发小组的人员素质应该较高，人员不宜过多。人员素质低和人员过多，都会导致软件的错误率高，且开发效率下降，成本增加。
　　7．承认不断改进软件工程的必要性
　　软件工程是一门不断迅速发展的学科，必须学习和跟踪先进的技术和方法，也要不断总结经验、改进方法，要不断进行技术创新。
　　1.1.3 现代软件工程
　　软件不是纯物化的东西，其中包含着人的因素，于是就有很多变动的东西，不可能像理想的物质生产过程一般，基于物理学的原理来做。早期的软件开发仅考虑人的因素，传统的软件工程强调物性的规律，现代软件工程强调的是人和物的关系，即人和机器（工具、自动化）在不同层次的不断循环发展中的关系。
　　面向对象的分析、设计方法（OOA和 OOD）的出现使传统的开发方法发生了翻天覆地的变化。随之而来的是面向对象建模语言（以 UML为代表）、软件复用、基于组件的软件开发等新的方法和领域。
　　与之相应的是从企业管理的角度提出的软件过程管理，即关注于软件生存周期中所实施的一系列活动，并通过过程度量、过程评价和过程改进等涉及对所建立的软件过程及其实例进行不断优化的活动，使得软件过程循环往复，螺旋上升式地发展。其中昀著名的软件过程成熟度模型是美国卡内基梅隆大学软件工程研究所（ SEI）建立的 CMM（Capability Maturity Model），即能力成熟度模型。此模型在建立和发展之初，主要目的是为大型软件项目的招投标活动提供一种全面而客观的评审依据，而发展到后来，又同时被应用于许多软件机构内部的过程改进活动中。
　　1.2 建模概述
　　建模是所有建造优质软件活动中的中心环节，也是软件成功的一个基本因素，它在软件开发中是不可或缺的。
　　1.2.1 什么是模型
　　模型就是对现实客观世界的形状或状态的抽象模拟和简化。模型提供了系统的骨架（Sketch）和蓝图（ Blueprint）。模型给人们展示系统的各个部分是如何组织起来的，模型既可以包括详细的计划，也可以包括从很高的层次考虑系统的总体计划。一个好的模型包括那些有广泛影响的主要元素，而忽略那些与给定的抽象水平不相关的次要元素。每个系统都可以从不同的方面用不同的模型来描述，因而每个模型都是一个在语义上闭合的系统抽象。模型可以是结构性的，强调系统的组织，也可以是行为性的，强调系统的动态方面。对象建模的目标就是要为正在开发的系统制定一个精确、简明和易理解的面向对象模型。
　　通常，开发一个计算机系统是为了解决某个领域的特定问题。问题的求解过程就是从领域问题到计算机系统的映射。软件系统的模型用建模语言来表达，如 UML。模型包含语义信息和表示法，可以采用图形和文字等多种不同形式。建立模型是因为在某些用途中模型使用起来比操作实物更容易和方便。
　　模型主要包含两个方面：语义方面的信息（语义）和可视化的表达方法（表示法）。
　　语义方面用一套逻辑组件表达应用系统的含义，如类、关联、状态、用例和消息。语义模型元素携带了模型的含义，即它们表达了语义，用于代码生成、有效性验证、复杂度的度量等，其可视化的外观与大多数处理模型的工具无关。语义信息通常称做模型。一个语义模型具有一个词法结构、一套高度形式化的规则和动态执行结构。这些方面通常分别加以描述，但它们紧密相关，并且是同一模型的一部分。
　　可视化的表达方式以可供人观察、浏览和编辑的形式展示语义信息。表达式元素携带了模型的可视化表达方式，即语义是用一种可被人直接理解的方式来表达的。它们并未增添新的语义，但用一种有用的方式对表达式加以组织，以强调模型的排列，因此它们对模型的理解起指导作用。表达式元素的语义来自于语义模型元素，但是，由于是由人来绘制模型图，所以表达式元素并不是完全来自于模型的逻辑元素。表达式元素的排列可以表达出语义关系的其他含义。
　　UML作为一种可视化的建模语言，提供了丰富的基于面向对象概念的模型元素及其图形表示元素。
　　1.2.2 建模的原理
　　选择创建什么模型很重要，因为模型要反映难以处理的开发问题。建模的原理有以下 10个：
　　选择建立什么样的模型对如何发现和解决问题具有重要的影响，正确的模型有助于提高开发者的洞察力。
　　模型要在不同的精度级别上来表示。
　　可以根据观察的角色和观察的原因来选择精度。
　　建造模型要和现实相连。
　　重要的系统需要用一组独立的模型去处理。在面向对象的软件体系中，为了理解系统的体系结构，需要几个互补和连锁的视图：用例图、设计视图、进程视图、实现视图和实施视图。
　　构造模型的基本技术是抽象，应突出与问题有关的特征，将与问题无关的性质略去。
　　不必追求绝对的真实和完整，只需从期望的角度看其是否充分。
　　应当刻画问题的关键方面，略去相对次要的因素。
　　建模语言应支持人们由模糊到清晰、由粗到细逐渐完善的认识过程。
　　应采用可视化的图形建模语言。
　　1.2.3 为什么要建模
　　使用模型建模不仅仅适用于建筑行业，例如，城市在进行规划的时候通常都有自己的规划模型等。如果不首先构造这些模型就进行城市的建设，那简直是难以想象的。一些电气设备，例如， ATM机也需要一定程度的建模，以便更好地理解系统。在社会学、经济学和商业管理领域也需要建模，以证实理论的正确性。
　　建模是为了能够更好地理解正在开发的系统。通过建模，要达到以下 4个目的：
　　模型有助于按照实际情况或按照所需要的样式对系统进行可视化。
　　模型能够规约系统的结构或行为。
　　模型给出了指导构造系统的模板。
　　模型可对做出的决策进行文档化。
　　那么具体到软件所涉及到的人员，包括系统用户、软件开发团队、软件的维护者和技术支持者，系统建模都有什么样的作用呢？
　　对于软件系统用户，软件的开发模型向他们描述了软件开发者对于软件系统需求的理解。让系统用户查看软件对象模型并且找到其中的问题，这样可以使用户开发者不至于从一开始就发生错误。需求分析阶段的错误将会导致大量的修复成本，让系统用户一开始就指出一些需求错误并修正它们，能够在很大程度上节约这些成本。
　　对于软件开发团队，软件的对象模型有助于帮助他们对软件的需求以及系统的架构和功能进行沟通。需求和架构的一致理解对于软件开发团队是非常重要的，可以减少不必要的麻烦。软件对象建模的受益者不仅仅包括代码的编写者，还包括软件的测试者和文档的编写者。
　　对于软件的维护者和技术支持者，在软件系统开始运行后的相当长的一段时间内，软件的对象模型能够帮助他们理解程序的架构和功能，迅速地对软件所出现的问题进行修复。
　　建模并不仅仅针对的是大型的软件系统，甚至一个小型的电话簿软件也能从建模过程中受益。事实上，系统越大、越复杂，建模的重要性就越大，一个很简单的原因就是：人对复杂问题的理解能力是有限的，人们往往不能完整地理解一个复杂的系统，所以要对它建模。
　　通过建模，可以缩小所研究问题的范围，一次只需要重点研究它的一个很小的方面，这就是“分而治之”的策略方法，即把一个困难问题划分成一系列能够解决的小问题，对这些小问题的解决也就构成了对复杂问题的解决。一个适当选择的模型可以使建模人员在较高的抽象层次上工作。
　　1.2.4 建模的目标和原则
　　建立模型可以帮助开发者更好地了解正在开发的系统。通过建模，要实现以下 4个目标：
　　便于开发人员展现系统。
　　允许开发人员制定系统的结构或行为。
　　提供指导开发人员构造系统的模板。
　　记录开发人员的决策。
　　在工程学科中，对模型的使用有着悠久的历史，人们从中总结出了 4条基本的建模原则。
　　选择要创建什么模型，对如何动手解决问题和如何形成解决方案有着意义深远的影响。换句话说，就是要认真地选择模型。正确的模型将清楚地表明最棘手的开发问题，提供不能轻易地从别处获得的洞察力；错误的模型将使人误入歧途，把精力花在不相关的问题上。
　　可以在不同的精度级别上表示每一种模型。如果正在建造一座大厦，有时需要从宏观上让投资者看到大厦的样子，感觉到大厦的总体效果。而有时又需要认真考虑细节问题，例如，对复杂管道的铺设，或对少见的结构件的安装等。无论如何，使用者的身份和使用的原因是评判模型优劣的关键。分析者和最终用户关心的是“这是什么”，而开发者关心的是“如何实现”。所有的参与者都想在不同的时期、从不同的角度了解系统。
　　最好的模型是与现实相联系的。如果建筑的物理模型不能以与真实的建筑相同的方式做出反应，则它的价值是很有限的；飞机的数学模型，如果只是假定了理想条件和完美制造，则可能掩盖真实飞机的一些潜在的、致命的现实特征。最好是有能够清晰地联系实际的模型，而当联系很薄弱时能够精确地知道这些模型怎样与现实脱节。所有的模型都对现实进行了简化，但有一点要记住，简化不要掩盖任何重要的细节。
　　孤立的模型是不完整的。每个重要的系统都是由多个几乎独立的模型组合出来的。如果正在建造一所建筑物，会发现没有任何一套单项设计图能够描述该建筑的所有细节。至少需要楼层平面图、立面图、电气设计图、采暖设计图和管道设计图。并且，在任何种类的模型中都需要从多视角来把握系统的范围（例如不同楼层的蓝图）。既能够单独地研究电气设计图，也能看到它如何映射到楼层平面图中，以及它与管道设计图中管道排布的相互影响。
　　1.3 UML概述
　　UML的目标是以面向对象的图形方式来描述任何类型的系统，其应用领域非常广泛。其中昀常用的是建立软件系统的模型，但它同样可以用于描述非软件领域的系统，如机械系统、企业机构或业务过程，以及处理复杂数据的信息系统、具有实时要求的工业系统或工业过程等。总之， UML是一个通用的标准建模语言，可以对任何具有静态结构和动态行为的系统进行建模。
　　1.3.1 UML的起源和发展
　　在面向对象建模上，被公认的面向对象建模语言昀早出现于 20世纪 70年代中期。在面向对象建模的竞争过程中，昀繁盛的时期是 1989年~1994年，在这短短的几年时间内，面向对象建模语言的数量从不到十种增加到了五十多种。从 20世纪 90年代中期开始，一些比较成熟的方法受到了学术界与工业界的推崇和支持，其中昀具代表性的是 Booch 1993、OOSE和 OMT-2等，它们是当时影响昀大的几种面向对象方法论。
　　尽管这些面向对象方法都比较优秀，但是不同程度和不同领域的开发人员却无法鉴别这些面向对象开发方法的长处，为了能够让不同程度和不同开发领域的开发人员能够进行很好的沟通，并交流他们在开发各种系统的过程中积累的经验和成果，业内研究人员和众多的厂商都开始意识到有必要对这些已经存在的并且比较好的方法进行充分分析，汲取众长，创建一种统一的建模语言。
　　统一的建模语言的创建开始于 1994年 10月，Grady Booch和 Jim Rumbaugh首先致力于这一工作的研究，他们将 Booch 93和 OMT-2统一起来，并于 1995年 10月发布了第一个公开版本，称之为统一方法 UM 0.8（Unfitied Method）。
　　而后，面向对象软件工程（ Object-Oriented Software Engineer，OOSE）方法的创始人 Iar Jacobson也加入到这个队伍中，并且带来了其在 OOSE方法中的成果。经过 Grady Booch、 Jim Rumbaugh和 Iar Jacobson三人的共同努力，于 1996年 6月和 10月分别发布了两个新的 UML版本，即 UML 0.9和 UML 0.91，并且正式将 UM重新命名为 UML（Unified Modeling Language）。
　　1996年，一些机构将 UML作为其商业策略已日趋明显。 UML的开发者得到了来自公众的正面反应，并倡议成立了 UML成员协会，以完善、加强和促进 UML的定义工作。当时的成员有 DEC、HP、I-Logix、Itellicorp、IBM、ICON Computing、MCI Systemhouse、Microsoft、 Oracle、Rational Software、TI以及 Unisys等 700多家公司。这些公司表示支持采用 UML作为其标准建模语言。这一机构对 UML 1.0（发布于 1997年 1月）及 UML 1.1（发布于 1997年 11月 17日）的定义和发布起到了重要的促进作用。 1997年 11月 17日，对象管理组织（OMG）开始采纳 UML为其标准建模语言，成为业界的标准。从此， UML的相关发布、推广等工作交由 OMG负责。
　　至此，UML作为一种定义良好、易于表达、功能强大且普遍适用的建模语言，溶入了软件工程领域的新思想、新方法和新技术，成为面向对象技术学习中不可缺少的一部分。UML的作用不仅在于支持面向对象的分析与设计，还支持从需求分析开始的软件开发的全过程。
　　从 UML纳入到 OMG开始， OMG对于 UML的修订工作就从来没有停止过，产生了 UML
　　1.2、UML 1.3、UML 1.4和 UML 2.0版本，目前，该组织正在为 UML 2.x版本努力。
　　目前，许多的软件工具开发厂商在自己的产品中支持或计划支持 UML标准。许多的软件工程方法学家也正在使用 UML的表示法进行以后的研究工作。 UML的出现深受计算机界
　　的欢迎，因为它集中了许多专家的经验，减少了各种软件开发工具之间无谓的分歧。
　　1.3.2 UML的主要特点
　　标准建模语言 UML的主要特点可以归纳为以下三点：
　　UML统一了 Booch、OMT和 OOSE等方法中的基本概念。
　　UML吸取了面向对象技术领域中其他流派的长处，其中也包括非 OO方法的影响。 UML符号考虑到了各种方法的图形表示，删掉了大量易引起混乱的、多余的和极少使用的符号，也添加了一些新符号。因此，在 UML中汇入了面向对象领域中很多人的思想。这些思想并不是 UML的开发者们发明的，而是开发者们依据最优秀的 OO方法和丰富的计算机科学实践经验综合提炼而成的。
　　UML在演变过程中还提出了一些新的概念。在 UML标准中添加了模板（Stereotypes）、职责（Responsibilities）、扩展机制（Extensibility mechanisms）、线程（ Threads）、过程（ Processes）、分布式（ Distribution）、并发（ Concurrency）、模式（Patterns）、合作（ Collaborations）、活动图（ Actiity Diagram）等新概念，并清晰地区分类型（ Type）、类（ Class）和实例（ Instance）、细化（ Refinement）、接口（Interfaces）和组件（Components）等概念。
　　因此，可以认为，UML是一种先进实用的标准建模语言，但其中某些概念尚待实践来验证，UML也必然存在一个进化过程。
　　1.3.3 UML的应用领域
　　UML的目标是以面向对象图的方式来描述任何类型的系统，具有很宽的应用领域。其中昀常用的是建立软件系统的模型，但它同样可以用于描述非软件领域的系统。总之， UML是一个通用的标准建模语言，可以对任何具有静态结构和动态行为的系统进行建模。
　　此外，UML适用于系统开发过程中从需求规格描述到系统完成后测试的不同阶段。在需求分析阶段，可以用用例来捕获用户需求。通过用例建模，描述对系统感兴趣的外部角色及其对系统（用例）的功能要求。分析阶段主要关心问题域中的主要概念（如抽象、类和对象等）和机制，需要识别这些类以及它们相互间的关系，并用 UML类图来描述。为实现用例，类之间需要协作，这可以用 UML动态模型来描述。在分析阶段，只对问题域的对象（现实世界的概念）建模，而不考虑定义软件系统中技术细节的类（如处理用户接口、数据库、通信和并行性等问题的类）。这些技术细节将在设计阶段引入，因此设计阶段为构造阶段提供更详细的规格说明。
　　UML模型还可作为测试阶段的依据。系统通常需要经过单元测试、集成测试、系统测试和验收测试。不同的测试小组使用不同的 UML图作为测试依据：单元测试使用类图和类规格说明；集成测试使用部件图和合作图说明；系统测试使用用例图来验证系统的行为；验收测试由用户进行，以验证系统测试的结果是否满足在分析阶段确定的需求。
　　总之，标准建模语言 UML适用于以面向对象技术来描述类型的系统，而且适用于系统开发的不同阶段，包括从需求规格描述直至系统完成后的测试和维护。
　　1.3.4 UML的模型种类
　　软件有孕育、诞生、成长、成熟和衰亡的生存过程，我们称为“软件生命周期”。软件生命周期可以分为多个阶段，即制定计划、需求分析、设计、编码、测试、运行和维护。软件开发可以采用多种途径进行。软件开发模式是跨越整个软件生存周期的系统开发，并运行和维护所实施的全部内容的结构框架，它给出了软件开发活动各个阶段之间的关系。软件项目可以遵循不同类型的开发过程，目前，可以将常见的软件开发模式大致分为如下几种类型。
　　在第一代软件开发过程模式中，软件需求是要求完全确定的，如瀑布模型。这类开发模式的特点是软件需求在开发阶段已经基本确定，软件生命周期的各项活动依顺序固定，软件开发阶段性进行。其缺点是如果在开发后期要改正早期已经存在的问题需要付出昂贵的代价，从用户角度来讲，开发需要等待较长时间才能够看到软件产品，这样大大增加了软件开发的风险系数。并且，如果在开发过程中存在开发瓶颈，则将严重影响开发效率。根据开发的瓶颈制定开发计划，成为第一代软件开发过程不可缺少的一部分。
　　对于第一代软件开发过程模式的改进诞生了在开始阶段只提供基本需求的渐进式开发模型，如喷泉模型和演化模型等。这类开发模型的特点是在软件开发的开始阶段只需要提供基本的需求，软件开发过程的各个活动是迭代的，所以也被称为迭代式开发。通过迭代过程实现软件的逐步演化，最终得到软件产品。在此引入了风险管理，采取早期预防措施，增加项目成功几率，提高软件质量。其缺点是由于在开始阶段需求的不完全性，对于软件的总体设计带来了困难，从而也削弱了产品设计的完整性，这样就对风险技能管理水平提出了很大的挑战。
　　以体系结构为基础或基于构件的开发模型，如基于构件的开发模型和基于体系结构的开发模型等。这类模型的特点是首先利用获取的需求分析结果设计出软件的总体结构，然后通过基于构件的组装方法来构造软件系统。这样软件体系结构的出现使得软件的结构框架更清晰，有利于系统的设计、开发和维护。
　　轻量级的开发模型，这种开发模型强调适应性而非预测性，强调以人为中心，而不以流程为中心，以及对变化的适应和对人性的关注，其特点是轻载、基于时间、紧凑、并行并基于构件的软件过程。在所有的敏捷方法中， XP（eXtreme Programming）是一种最引人注目的轻型开发方法。
　　下面简单地对每种类型的代表，即瀑布模型、螺旋模型、基于构件的开发模型、 XP（eXtreme Programming）方法等软件开发模型进行分析。
　　1. 瀑布模型
　　瀑布模型也被称为“生存周期模型”，其核心思想是按照相应的工序将问题进行简化，将系统功能的实现与系统的设计工作分开，便于项目之间的分工与协作，即采用结构化的分析与设计方法将逻辑实现与物理实现分开。瀑布模型将软件生命周期划分为软件计划、需求分析、软件设计、软件实现、软件测试、软件运行和维护这 6个阶段，并且规定了它们自上而下的次序，如同瀑布一样下落。每一个阶段都是依次衔接的。采用瀑布模型的软件开发过程如图 1-1所示。
　　图 1-1 采用瀑布模型的软件过程
　　瀑布模型是昀早出现的软件开发模型，在软件工程中占有重要的地位，它提供了软件开发的基本框架。其过程是：从上一项活动接收该项活动的工作对象作为输入，利用这一输入实施该项活动应完成的内容，给出该项活动的工作成果，并作为输出传给下一项活动。同时评审该项活动的实施，若确认，则继续下一项活动；否则返回前面，甚至更前面的活动。
　　瀑布模型为项目提供了按阶段划分的检查点，这样有利于软件开发过程中人员的组织及管理。瀑布模型让你在完成当前阶段后，才去关注后续阶段，这样有利于开发大型项目，然而软件开发的实践表明，瀑布模型也存在一定的缺陷。
　　只有在项目生命周期的后期才能看到结果：由于开发模型呈线性，所以当开发成果尚未经过测试时，用户是无法看到软件效果的，不能在开发过程中得到及时反馈，增加了项目开发过程的风险。在软件开发前期未发现的错误传到后面的开发活动中，进而可能会造成整个软件项目开发失败。
　　通过过多的强制完成日期和里程碑来跟踪各个项目阶段：在每个项目开发阶段，瀑布模型是通过强制固定的完成日期和里程碑进行项目跟踪的，在项目开发过程中缺乏足够的灵活性，特别是对于需求不稳定的项目更加麻烦。
　　在软件需求分析阶段，要完全确定系统用户的所有需求是一件比较困难的事情，甚至可以说是不太可能的。
　　尽管瀑布模型存在一定的缺陷，但是它对很多类型的项目而言依然是有效的，特别是一些大型的项目。如果使用正确，可以节省大量的时间和金钱。对于所开发的项目而言，是否使用这一模型主要取决于能否理解客户的需求以及在项目的进程中这些需求的变化程度，对于能够在前期进行确定的需求分析项目，瀑布模型还是具有一定价值的。
　　2. 喷泉模型
　　喷泉模型是一种以对象为驱动、以用户需求为动力的模型，主要用于描述面向对象的软件开发过程。该模型认为软件开发过程自下而上的各阶段是相互重叠和多次反复的，就像水喷上去又可以落下来，类似一个喷泉。各个开发阶段没有特定的次序要求，并且可以交互进行，可以在某个开发阶段中随时补充其他任何开发阶段中的遗漏。采用喷泉模型的软件开发过程如图 1-2所示。
　　图 1-2 采用喷泉模型的软件过程
　　喷泉模型主要用于面向对象的软件项目，软件的某个部分通常被重复多次，相关对象在每次迭代中随之加入渐进的软件成分。各活动之间无明显边界，例如设计和实现之间没有明显的边界，这也称为“喷泉模型的无间隙性”。
　　喷泉模型不像瀑布模型那样，需要在分析活动结束后才开始设计活动，设计活动结束后才开始编码活动。该模型的各个阶段没有明显的界限，开发人员可以同步开发。其优点是可以提高软件项目的开发效率，节省开发时间，适应于面向对象的软件开发过程。由于喷泉模型在各个开发阶段是重叠的，因此在开发过程中需要大量的开发人员，不利于项目的管理。此外这种模型要求严格管理文档，使得审核的难度加大，尤其是在面对可能随时加入各种信息、需求与资料的情况下。
　　3. 基于构件的开发模型
　　基于构件的开发模型利用模块化方法将整个系统模块化，并在一定构件模型的支持下复用构件库中的一个或多个软件构件，通过组合手段高效率、高质量地构造应用软件系统。基于构件的开发模型融合了螺旋模型的许多特征，由软件的需求分析和定义、体系结构设计、构件库建立、应用软件构建、测试和发布 5个阶段组成，采用这种开发模型的软件过程如图 1-3所示。
　　图 1-3 采用基于构件的开发模型的软件过程
　　构件作为重要的软件技术和工具得到了极大的发展，这些新技术和工具有 Microsoft的 DCOM、Sun的 EJB，以及 OMG的 CORBA等。基于构件的开发活动从标识候选构件开始，通过搜查已有构件库，确认所需要的构件是否已经存在。如果已经存在，则从构件库中提取出来复用；否则采用面向对象方法开发它。之后利用提取出来的构件通过语法和语义检查将这些构件通过胶合代码组装到一起实现系统，这个过程是迭代的。
　　基于构件的开发方法使得软件开发不再一切从头开发，开发的过程就是构件组装的过程，维护的过程就是构件升级、替换和扩充的过程。其优点是构件组装模型导致了软件的复用，提高了软件开发的效率。构件可由一方定义其规格说明，被另一方实现，然后供给第三方使用，构件组装模型允许多个项目同时开发，降低了费用，提高了可维护性，可分步提交软件产品。
　　但由于该模型采用自定义的组装结构标准，缺乏通用的组装结构标准，因而引入了较大的风险。可重用性和软件高效性不易协调，需要精干的有经验的分析和开发人员，并且由于过分依赖于构件，所以构件库的质量影响着产品质量。
　　4. XP方法
　　敏捷方法是近几年兴起的一种轻量级的开发方法，它强调适应性而非预测性，强调以人为中心，而不以流程为中心，以及对变化的适应和对人性的关注，其特点是轻载、基于时间、紧凑、并行并基于构件的软件过程。在所有的敏捷方法中， XP（eXtreme Programming）是一种昀引人注目的轻型开发方法。它规定了一组核心价值和方法，消除了大多数重量型开发过程中的不必要产物，建立了一个渐进型开发过程。该方法将开发阶段的 4个活动（分析、设计、编码和测试）混合在一起，在全过程中采用迭代增量开发、反馈修正和反复测试的方法。它把软件生命周期划分为用户场景、系统架构、发布计划、迭代、验证测试和小型发布共 6个阶段，采用这种开发模型的软件过程如图 1-4所示。
　　图 1-4 采用 XP方法的软件过程
　　XP模型通过对传统软件开发的标准方法进行重新审视，提出了由一组规则组成的简便易行的过程。由于这些规则是通过在实践中观察使软件高效或缓慢的因素而得出的，因此它既考虑了保持开发人员的活力和创造性，又考虑了开发过程的有组织、有重点和持续性。 XP模型是面向客户的开发模型，重点强调用户的满意程度。开发过程中对需求改变的适应能力较高，即使在开发的后期，也可较高程度地适应用户的改变。
　　XP开发模型与传统模型相比具有很大的不同，其核心思想是交流（ Communication）、简单（Simplicity）、反馈（ Feedback）和进取（ Aggressieness）：XP开发小组不仅包括开发人员，还包括管理人员和客户，该模型强调小组内成员之间要经常进行交流；在尽量保证质量的前提下力求过程和代码的简单化；来自客户、开发人员和昀终用户的具体反馈意见可以提供更多的机会来调整设计，保证把握正确的开发方向；进取则包含于上述 3个原则中。
　　XP开发方法中有许多新思路，如采用“用户场景”代替传统模型中的需求分析。“用户场景”是由用户用自己领域中的词汇并且不考虑任何技术细节准确地表达自己的需求。 XP模型的优点如下：
　　采用简单计划策略，不需要长期计划和复杂模型，开发周期短。
　　全过程采用迭代增量开发、反馈修正和反复测试的方法，软件质量有保证。
　　能够适应用户经常变化的需求，提供用户满意的高质量软件。
　　上面的开发模型或方法或许不能一概而论地说是以面向对象的建模为基础的开发模式，但是在各种开发方法中，都包含了软件的需求分析、软件的设计、软件的开发、软件的测试和软件的部署。在每一个阶段，都可以借助于面向对象的建模和这些开发模型形成一套适合自己或企业的开发方式，主要体现在以下几个方面。
　　在软件的需求分析阶段，对系统将要面临的具体管理问题以及用户对系统开发的需求进行调查研究，即先弄清要干什么的问题，然后分析问题的性质和求解问题，在繁杂的问题域中抽象地识别出对象以及其行为、结构、属性、方法等。一般称之为面向对象的分析，即 OOA。
　　在软件的设计阶段整理问题，对分析的结果作进一步的抽象、归类、整理，并最终
　　以范式的形式将它们确定下来。一般称之为面向对象的设计，即 OOD。
　　在软件的开发阶段，即程序实现阶段，用面向对象的程序设计语言将上一步整理的范式直接映射（即直接用程序设计语言来取代）为应用软件。一般称之为面向对象的程序，即 OOP。
　　1.4 扩展练习
　　1. 简述建模的重要性、目标以及原则。
　　2. UML是什么？它的主要特点和应用领域在哪里？
　　3. 简述软件开发的生命周期。
　　4. 常见的软件开发模式有哪几种？
　　5. 简述软件工程的内容和基本原理。