Page 1 ?
UML及软件建模
主讲人, 李 唯
clx7000@163.com
Page 2 ?
第十三章 在建模过程中运用 UML
Page 3 ?
1,模型
这一节将解释什么是模型，模型有何用途以及如何使用模
型。
这一节还要解释模型的不同层次：理想的，部分的和基于
工具的。
Page 4 ?
? 模型是用某种工具对同类或其他工具的表达方式。模型从
某一个建模观点出发，抓住事物最重要的方面而简化或忽
略其他方面。工程、建筑和其他许多需要具有创造性的领
域中都使用模型。
? 表达模型的工具要求便于使用。建筑模型可以是图纸上所
绘的建筑图，也可以是用厚纸板制作的三维模型，还可以
用存于计算机中的有限元方程来表示。一个建筑物的结构
模型不仅能够展示这个建筑物的外观，还可以用它来进行
工程设计和成本核算。
? 软件系统的模型用建模语言来表达，如 UML。模型包含语
义信息和表示法，可以采取图形和文字等多种不同形式。
建立模型的目的是因为在某些用途中模型使用起来比操纵
实物更容易和方便。
1.1,什么是模型
Page 5 ?
1.2、模型的用途
模型有多种用途
（ 1） 精确捕获表达项目的需求和应用领域中的知识，以
使各方面的利益相关者能够理解并达成一致。
建筑物的各种模型能够准确表达出这个建筑物在外观、交通、服务
设施、抗风和抗震性能，消费及其他需求。各方面的利益相关者则包括
建筑设计师、建筑工程师、合同缔约人、各个子项目的缔约人、业主、
出租者和市政当局。
软件系统的不同模型可以捕获关于这个软件的应用领域、使用方
法、试题手段和构造模式等方面的需求信息。各方面的利益相关者包括
软件结构设计师、系统分析员、程序员、项目经理、顾客、投资者、最
终用户和使用软件的操作员。在 UML中要使用各种各样的模型。
Page 6 ?
（ 2）进行系统设计
建筑设计师可以用画在图纸上的模型图、存于计算机
中的模型或实际的三维模型使自己的设计结果可视化，并用
这些模型来做设计方面的的试验。建造、修改一个小型模型
比较简单，这使得设计人员不需花费什么代价就可以进行创
造和革新。
在编写程序代码以前，软件系统的模型可以帮助软件开
发人员方便地研究软件的多种构架和设计方案。在进行详细
设计以前，一种好的建模语言可以让设计者对软件的构架有
全面的认识。
Page 7 ?
（ 3）使具体的设计细节与需求分开
建筑物的某种模型可以展示出符合顾客要求的外观。另
一类模型可以说明建筑物内部的电气线路、管线和通风管道
的设置情况。实现这些设置有多种方案。最后确定的建筑模
型一定是建筑设计师认为最好的一个设计方案。顾客可以对
此方案进行检查验证，但通常顾客对具体的设计细节并不关
心，只要能满足他们的需要即可。
软件系统的一类模型可以说明这个系统的外部行为和系
统中对应于真实世界的有关信息，另一类模型可以展示系统
中的类以及实现系统外部行为特性所需要的内部操作。实现
这些行为有多种方法。最后的设计结果对应的模型一定是设
计者认为最好的一种。
Page 8 ?
（ 4）生成有用的实际产品
建筑模型可以有多种相关产品，包括建筑材料清单
、在各种风速下建筑物的偏斜度、建筑结构中各点的应
力水平等。
利用软件系统的模型，可以获得类的声明、过程体、用
户界面、数据库、合法使用的说明、配置草案以及与其
他单位技术竞争情况的对比说明。
Page 9 ?
（ 5）组织、查找、过滤、重获、检查以及编辑大型系统的
有关信息。
建筑模型用服务设施来组织信息：建筑结构、电器、管
道、通风设施、装潢等等。除非利用计算机存储，否则对这
些信息的查找和修改没那么容易。相反，如果整个模型和相
关信息均存储在计算机中，则这些工作很容易进行，并且可
方便地研究多种设计方案，这些设计方案共享一些公共信息
。
软件系统用视图来组织信息：静态结构视图、状态机视
图、交互视图、反映需求的视图等等。每一种视图均是针对
某一目的从模型中挑选的一部分信息的映射。没有模型管理
工具的支持不可能使模型做得任意精确。一个交互视图编辑
工具可以用不同的格式表示信息，可以针对特定的目的隐藏
暂时不需要的信息并在以后再展示出来，可以对操作进行分
组、修改模型元素以及只用一个命令修改一组模型元素等等
。
Page 10 ?
（ 6）经济地研究多种设计过程中的解决方案
对同一建筑的不同设计方案的利弊在一开始可能不很清
楚。例如，建筑物可以采用的不同的子结构彼此之间可能有
复杂的相互影响，建筑工程师可能无法对这些做出正确的评
价。在实际建造建筑物以前，利用模型可以同时研究多种设
计方案并进行相应的成本和风险估算。
通过研究一个大型软件系统的模型可以提出多个实际方
案并可以对它们进行相互比较。当然模型不可能做得足够精
细，但即使一个粗糙的模型也能够说明在最终设计中所要解
决的许多问题。利用模型可以研究多种设计方案，所花费的
成本只是实现其中一种方案所花费的成本。
Page 11 ?
（ 7） 利用模型可以全面把握复杂的系统。
一个关于龙卷风袭击建筑物的工程模型中的龙卷
风不可能是真实世界里的龙卷风，仅仅是模型而已。
真正的龙卷风不可能呼之即来，并且它会摧毁测量工
具。许多快速，激烈的物理过程现在都可以运用这种
物理模型来研究和理解。
一个大型软件系统由于其复杂程度可能无法直接研
究，但模型使之成为可能。在不损失细节的情况下，
模型可以抽象到一定的层次以使人们能够理解。可以
利用计算机对模型进行复杂的分析以找出可能的“问
题点”，如时间错误和资源竞争等。在对实物做出改
动前，通过模型研究系统内各组成部分之间的依赖关
系可以得出这种改动可能会带来哪些影响。
Page 12 ?
1.2、模型的层次
针对不同目的，模型可以采取各种形式及不同的抽象层
次。模型中所包含的信息量必须对应于以下几种目的：
Page 13 ?
（ 1）指导设计思路
在项目早期所建立的高层模型用于集中利益相关者的思路和强调一些重要的
选择方案。这些模型描述了系统的需求并代表了整个系统设计工作的起点。早
期的模型帮助项目发起者在把精力放在系统的细节问题之前研究项目可能的选
择方案。随着设计工作的进展，早期模型被更为精确的模型所替代。没有必要
详细保存早期研究过程中的种种选择方案和返工情况。早期模型的目的是帮助
获得思路。但最后得到的“思路模型”要在进行详细设计前记录下来。早期模 型
不需要达到实现阶段的模型的精确程度，无须涉及有关系统实现的一套概念。
建立这种模型只使用了 UML定义的组件的一个子集，比后期的设计阶段的模型
使用的组件要少得多。
当早期模型发展到具有一定精度的完整的视图模型时 — 例如，分析系统需求
的模型 — 那么要在开发过程进入下一阶段时将其保存下来。不断向模型中填加
信息的增量式开发（在这种情况下开发的推理过程也要保存和记录）与一般的
针对“死端点”进行研究直到得出正确的解决方案的随意漫步式开发之间一个 重
要的区别。后一种情况通常使人不知怎么着手，并且根本没有必要对整个开发
过程进行记录保存，除非遇到特殊情况需要对开发过程进行回溯。
Page 14 ?
在分析阶段和初步设计阶段所建立的模型以关键概念和最
终系统的各种机制为中心。这些模型以某种方式与最终系统匹
配。但是模型中丧失了细节信息，在设计过程中必需显式地补
充这些信息。使用抽象模型的目的是在处理局部细节问题前纠
正系统高层次的普遍问题。通过一个仔细的开发过程，这些模
型可以发展成最终模型，该过程保证最终获得的模型能够正确
实现初期模型的设计意图。必须具备跟踪能力来跟踪从基本模
型到完备模型的过程，否则无法保证最终系统正确包含了基本
模型所要表达的关键特性。基本模型强调语义，它们不需要涉
及系统实现方面的细节。有时确实会出现这种情况：在低层实
现方面的差别会使逻辑语义模糊不清。从基本模型到最后的实
现模型的途径必须清晰和简明，不论这个过程由代码生成器自
动实现还是由设计者人工实现。
（ 2） 系统基本结构的抽象说明
Page 15 ?
（ 3） 最终系统的详细规格说明
系统实现模型包含能够建造这个系统的足够信息，它不仅
要包括系统的逻辑语义和语法、算法、数据结构和确保能正确
完成系统功能的机制，而且还要包括系统制品的组织决定，这
些制品对个人之间的相互协作和使用辅助工具来说十分必要。
这种模型必须包括对模型元素进行打包的组件以便于理解和用
计算机进行自动处理。这不是目标应用系统的特性，而是系统
构造过程应具有的特性。
Page 16 ?
（ 4）典型或可能的系统范例
精心挑选的实例可以提高人们的观察能力并使系统的说
明和实现有实际效果。然而，即使有非常多的例子，也起不
到一段详细定义所起的效果。我们最终希望的是要让模型能
够说明一般的情形，这也是程序代码所要做的事情。不过典
型的数据结构、交互顺序或对象生命历程的例子对于理解复
杂系统很有益处。必须小心使用例子。从逻辑上来说，从一
大堆特例中归纳出最一般的情况是不可能的，但是大部分人
思考某一问题时总是首先考虑一些被精心挑选出来的有关该
问题的例子。范例模型仅是对模型的示例而不带有一般性的
描述，因此，人们会觉得这两种模型之间有差异。范例模型
一般只使用 UML定义的组件的子集。说明型模型和范例模型
在建模中都很有用。
Page 17 ?
模型可以完全描述一个独立系统，并且不需要参考外部信息
。更通常的情况是，模型是用相互区别的、不连续的描述单元组
织起来的，每个单元作为整体描述的一部分可以被单独进行存储
和操纵。这种模型带有必须与系统其他模型联系在一起的散件。
因为这些散件具有相关性和含义，因此它们能够与其他散件通过
各种方式结合来构造不同的系统。获得重用是一个好的建模方法
的重要目标。
模型要随时间发展变化。深度细化的模型源于较为抽象的
模型，具体模型源于逻辑模型。例如，开始阶段建立的模型是整
个系统的一个高层视图。随着时间的推进，模型中增加了一些细
节内容并引入了一些变化。再随着时间的推进，模型的核心焦点
从一个以用户为中心的前端逻辑视图转变成了一个以实现为中心
的后端物理视图。随着开发过程的进行和对系统的深入理解，必
须在各种层次上反复说明模型以获得更好的理解，用一个单一视
角或线性过程理解一个大型系统是不可能的。对模型的形式无所
谓“正确和错误”之分 。
（ 4）对系统全面的或部分的描述
Page 18 ?
1.3、模型内容
模型包含两个主要方面：语义方面的信息（语义）和
可视化的表达方法（表示法）。
语义方面用一套逻辑组件表达应用系统的含义，如类
、关联、状态、用例和消息。语义模型元素携带了模型的含
义即，它们表达了语义。语义建模元素用于代码生成、有效
性验证、复杂度的度量等，其可视化的外观与大多数处理模
型的工具无关。语义信息通常被称作模型。一个语义模型具
有一个词法结构、一套高度形式化的规则和动态执行结构。
这些方面通常分别加以描述（定义 UML的文献即如此），但
它们紧密相关，并且是同一模型的一部分。
Page 19 ?
可视化的表达方式以可使人观察、浏览和编辑的形式展示
语义信息。表示方式元素携带了模型的可视化表达方式，即
语义是用一种可被人直接理解的方式来表达的。它们并未增
添新的语义，但用一种有用的方式对表达式加以组织，以强
调模型的的排列。因此它们对模型的理解起指导作用。表达
式元素的语义来自于语义模型元素。但是，由于是由人来绘
制模型图，所以表达式元素并不是完全来自于模型的逻辑元
素。表达式元素的排列可能会表达出语义关系的另外含义，
这些语义关系很不明显或模棱两可，以至于在模型中不能形
式化地表达，但可给人启迪模。
Page 20 ?
1.4、模型说明了什么
一个模型是一个系统潜在配置的发生器；系统是它的范围
，或值。按照模型来进行系统配置是一种理想化的情况。然
而，有时模型所要求的种种条件在现实中无法实现。模型还
是对系统含义和结构的一般性说明。这种描述是模型的范围
，或含义。模型总是具有一定的抽象层次。它包含了系统中
的最基本的成分而忽略了其他内容。对模型来说，有以下几
方面需要考虑：
Page 21 ?
（ 1）抽象和具体
模型包含了系统的基本成分而忽略了其他内容。哪些是基
本内容哪些不是基本内容需要根据建模的目的来判定。这不
是说要把模型所含信息的精度一分为二，即只有精确和不精
确两种情况。可能会存在一系列表达精度不同但逐渐提高的
模型。建模语言不是程序设计语言。建模语言所表达的内容
可能很不精确，因为多余的详细内容与建模目的无关。具有
不同精度级别的模型可应用于同一个项目的各个阶段。用于
程序设计编码的模型要求必须与程序设计语言有关。典型的
情况是，在早期分析阶段使用高层次的，表达精度低的模型
。随着开发过程的深入，所用的模型越来越细化，最终所使
用的模型包含了大量的细节内容，具有很高的精度。
Page 22 ?
一个模型可以告诉我们“做什么”（说明），也可以告
诉我们“一个功能是如何实现的 ——— 即怎么做”（实现）
。建模时要注意区分这两方面。在花大量时间研究怎么做之
前很重要的一点就是要正确分析出系统要做什么。建模的一
个重要的侧面是对具体实现细节进行抽象。在说明和实现之
间可能有一系列相关关系，其中在某层次中的说明就是对它
上一层次的实现。
(2) 说明和实现
Page 23 ?
模型主要是描述性的。模型所描述的是一个个实
例，这些实例仅是作为例子才出现在模型中的。大
部分实例仅在运行的一部分时间中才存在。有时，
运行实例自身是对其他事物的描述。我们把这些混
杂对象称做元模型（ Metamodel）。更深一层次的看
，认为任何事物不是描述性的就是实例性的，这种
观点是不符合实际情况的。某一事物是实例还是描
述不是孤立区分的，与观察角度有关，大部分事物
都可以用多种角度来考察。
（ 3）阐述和举例
Page 24 ?
(4) 解释的变更
用一种建模语言对模型可能会有多种的解释。可以定义语
义变更点（ semantic variation point） ——— 可能会出现多种
解释的地方 ——— 给每一个解释一个语义变更名，以便可以标
识究竟使用了哪种解释。例如,Smalltalk语言的使用者要避免
在系统实现模型种出现多重继承关系，因为 Smalltalk语言不支
持多重继承。而其他程序设计语言使用者可能会在模型种使用
多重继承。语义变更点支持多种具体的实现过程 。
Page 25 ?
2,建 模
建模的定义：
建模是对现实的简化。 就是把复杂的系统变成小的系统，
采用“各个击破”的原则逐一解决。
Page 26 ?
2.1、为什么要建模
建立大厦和建立茅草屋的区别是建设茅草屋不需要设计。
要生产合格的软件就要有一套关于体系结构、过程和工具的
规范。
Page 27 ?
2.2、建模的目标
1）模型帮助我们按照实际情况或按照我们所需要的样式对
系统进行可视化。
2）模型允许我们详细说明系统的结构和行为。
3）模型给出一个知道我们构造系统的模板。
4）模型对我们的决策进行文档化。
Page 28 ?
2.3、建模的误区
? 无论你遵从的是重量级的方法,比如 Enterprise Unified
Process(EUP)，还是轻量级的开发过程，如 Extreme
Programming(XP)，建模在软件开发中都是不可或缺的。
但不幸的是其中充斥着各种谬误与迷思。
这来自于各个方面，有从理论家错误的研究、数十年来信
息技术领域内的文化沉积、软件工具开发商天花乱坠半的
市场宣传以及象 Object Management Group (OMG)和 IEEE
这类组织的标准
Page 29 ?
误区一：建模就等于是写文档
? 事实分析：“模型”与“文档”这二者在概念上是风马牛
不相及的－－－－你可以拥有一个不是文档的模型和不是
模型的文档。
建模很象是作计划：作计划的价值在于计划编制的过程中
而非计划本身；价值体现在建模的活动中，而非模型本身
实际上，模型不是你系统中的一部分正式的文档，而且在
完成它们的使命后可以被丢掉。你会发现值得保留的只有
很少的模型，而且它一定是非常完美。
Page 30 ?
误区二：从开始阶段你可以考虑到所
有的一切
怎么才能走出这个误区呢？
首先，你必须认识到你不能考虑到所有的细枝末节。
第二，认识到不管你的最初所作的规格说明书有多好，但
注定代码会很快地与之失去同步，即便是你自己建模自己
编码。一个基本的道理就是代码永远只会和代码保 持一致。
第三，认识到迭代法（小规模地建模，编一些代码，做一些
测试，可能还会做一个小的工作版本）是软件开发的准则。
它是现代重量级的软件开发过程（如 EUP），以及轻量级
（如 XP)的基本原理。
Page 31 ?
误区三：建模是在浪费时间
? 许多人都这样认为，这主要是因为他们所接受的教育仅仅
局限于如何编写代码，对于完整的开发流程鲜有接触。而
且他们的经验也仅限于如何实现代码，就如初级程序员。
他们放弃了提高效率和学习技能的机会，这些技能能够使
他们很容易地适应不同的项目或组织。
? 事实分析：在大多数情况下，在开始编码之前画一个草图
、开发一个粗率的原型或者制作一些索引卡片都能提高你
的生产效率。高效的开发者在编码之前都要进行建模工作
。另外，建模是一种很好的在项目组成员与项目负责人之
间沟通途径。你们在这个过程中探讨问题，从而对所要的
是一个什么样的东西可以得到更好的 理解，涉及到该 项目
中的每个成员也可得到对该项目有一个从分的了解。
Page 32 ?
误区四：所有的开发人员都知道如何建模
? 我们现在面临照这样一个严重的问题：许多不是开发人员的
人，包括高级经理和用户，不知道软件是如何建 成的。其
结果，他们不能够区分开熟练的开发者和一般的程序员（当
然也分不清高级程序员和一般程序 员），他们想当然地认
为所有的开发人员都具备从头到尾开发整个系统的技能。
? 事实分析：这肯定是不正确的。建模的技能，是只有当一个
开发者通过学习它，并经过长期的实践才能够掌握。一些非
常聪明的程序员常常相信自己无所不能，正因为这样的狂妄
自大，他们承当的一些任务是他们根本就没有相应的技能去
完成的。软件开发是如此的复杂，单单一个人是很难具备所
有的技能去成功地进行开发，甚至也不可能去配置有一定复
杂程度的系统。开发者应该有自知之明，明白他们自己的弱
点，学无止境。通过互相取长补短，建模者可从程序员身上学
到一项技术的具体细节，程序员也可从建模者那里学到有价值
的设计和体系结构的技术。
Page 33 ?
2.4、建模十条原则
? 仅有数据模型对于现代软件是不够的。
? 接收变化，并且允许你的模型能够随着时间进行改进。 你不能
冻结它们，然后就期待着成功。
? 模型并不一定就是文档，文档也不一定就是模型。
? 大多数的模型可能也应该被丢弃。
? 只有代码才能与代码保持真正的同步。
? 一些简单的工具，比如白板，就完全足以应付大多数建模工作。
? 思考，然后再编码。
? 你总能从别人身上学到东西。
? 建模可以用一种轻盈的方式。
? 设计直到代码发布以后才算完成。
Page 34 ?
2.5、怎样成为优秀的软件模型设计者
? 1,人远比技术重要
? 2,理解你要实现的东西
? 3,谦虚是必须的品格
? 4,需求就是需求
? 5,需求其实很少改变，改变的是你对需求的理解
? 6,经常阅读
? 7,降低软件模块间的耦合度
? 8,提高软件的内聚性
? 9,考虑软件的移植性
? 10,接受变化
Page 35 ?
? 11,不要低估对软件规模的需求
? 12,性能仅仅是很多设计因素之一
? 13,管理接口
? 14,走近路需要更长的时间
? 15,别信赖任何人
? 16,证明你的设计在实践中可行
? 17,应用已知的模式
? 18,研究每个模型的长处和弱点
? 19,在现有任务中应用多个模型
? 20,教育你的听众
? 21,带工具的傻瓜还是傻瓜
? 22,理解完整的过程
Page 36 ?
? 23,常做测试，早做测试
? 24,把你的工作归档
? 25,技术会变，基本原理不会
UML及软件建模
主讲人, 李 唯
clx7000@163.com
Page 2 ?
第十三章 在建模过程中运用 UML
Page 3 ?
1,模型
这一节将解释什么是模型，模型有何用途以及如何使用模
型。
这一节还要解释模型的不同层次：理想的，部分的和基于
工具的。
Page 4 ?
? 模型是用某种工具对同类或其他工具的表达方式。模型从
某一个建模观点出发，抓住事物最重要的方面而简化或忽
略其他方面。工程、建筑和其他许多需要具有创造性的领
域中都使用模型。
? 表达模型的工具要求便于使用。建筑模型可以是图纸上所
绘的建筑图，也可以是用厚纸板制作的三维模型，还可以
用存于计算机中的有限元方程来表示。一个建筑物的结构
模型不仅能够展示这个建筑物的外观，还可以用它来进行
工程设计和成本核算。
? 软件系统的模型用建模语言来表达，如 UML。模型包含语
义信息和表示法，可以采取图形和文字等多种不同形式。
建立模型的目的是因为在某些用途中模型使用起来比操纵
实物更容易和方便。
1.1,什么是模型
Page 5 ?
1.2、模型的用途
模型有多种用途
（ 1） 精确捕获表达项目的需求和应用领域中的知识，以
使各方面的利益相关者能够理解并达成一致。
建筑物的各种模型能够准确表达出这个建筑物在外观、交通、服务
设施、抗风和抗震性能，消费及其他需求。各方面的利益相关者则包括
建筑设计师、建筑工程师、合同缔约人、各个子项目的缔约人、业主、
出租者和市政当局。
软件系统的不同模型可以捕获关于这个软件的应用领域、使用方
法、试题手段和构造模式等方面的需求信息。各方面的利益相关者包括
软件结构设计师、系统分析员、程序员、项目经理、顾客、投资者、最
终用户和使用软件的操作员。在 UML中要使用各种各样的模型。
Page 6 ?
（ 2）进行系统设计
建筑设计师可以用画在图纸上的模型图、存于计算机
中的模型或实际的三维模型使自己的设计结果可视化，并用
这些模型来做设计方面的的试验。建造、修改一个小型模型
比较简单，这使得设计人员不需花费什么代价就可以进行创
造和革新。
在编写程序代码以前，软件系统的模型可以帮助软件开
发人员方便地研究软件的多种构架和设计方案。在进行详细
设计以前，一种好的建模语言可以让设计者对软件的构架有
全面的认识。
Page 7 ?
（ 3）使具体的设计细节与需求分开
建筑物的某种模型可以展示出符合顾客要求的外观。另
一类模型可以说明建筑物内部的电气线路、管线和通风管道
的设置情况。实现这些设置有多种方案。最后确定的建筑模
型一定是建筑设计师认为最好的一个设计方案。顾客可以对
此方案进行检查验证，但通常顾客对具体的设计细节并不关
心，只要能满足他们的需要即可。
软件系统的一类模型可以说明这个系统的外部行为和系
统中对应于真实世界的有关信息，另一类模型可以展示系统
中的类以及实现系统外部行为特性所需要的内部操作。实现
这些行为有多种方法。最后的设计结果对应的模型一定是设
计者认为最好的一种。
Page 8 ?
（ 4）生成有用的实际产品
建筑模型可以有多种相关产品，包括建筑材料清单
、在各种风速下建筑物的偏斜度、建筑结构中各点的应
力水平等。
利用软件系统的模型，可以获得类的声明、过程体、用
户界面、数据库、合法使用的说明、配置草案以及与其
他单位技术竞争情况的对比说明。
Page 9 ?
（ 5）组织、查找、过滤、重获、检查以及编辑大型系统的
有关信息。
建筑模型用服务设施来组织信息：建筑结构、电器、管
道、通风设施、装潢等等。除非利用计算机存储，否则对这
些信息的查找和修改没那么容易。相反，如果整个模型和相
关信息均存储在计算机中，则这些工作很容易进行，并且可
方便地研究多种设计方案，这些设计方案共享一些公共信息
。
软件系统用视图来组织信息：静态结构视图、状态机视
图、交互视图、反映需求的视图等等。每一种视图均是针对
某一目的从模型中挑选的一部分信息的映射。没有模型管理
工具的支持不可能使模型做得任意精确。一个交互视图编辑
工具可以用不同的格式表示信息，可以针对特定的目的隐藏
暂时不需要的信息并在以后再展示出来，可以对操作进行分
组、修改模型元素以及只用一个命令修改一组模型元素等等
。
Page 10 ?
（ 6）经济地研究多种设计过程中的解决方案
对同一建筑的不同设计方案的利弊在一开始可能不很清
楚。例如，建筑物可以采用的不同的子结构彼此之间可能有
复杂的相互影响，建筑工程师可能无法对这些做出正确的评
价。在实际建造建筑物以前，利用模型可以同时研究多种设
计方案并进行相应的成本和风险估算。
通过研究一个大型软件系统的模型可以提出多个实际方
案并可以对它们进行相互比较。当然模型不可能做得足够精
细，但即使一个粗糙的模型也能够说明在最终设计中所要解
决的许多问题。利用模型可以研究多种设计方案，所花费的
成本只是实现其中一种方案所花费的成本。
Page 11 ?
（ 7） 利用模型可以全面把握复杂的系统。
一个关于龙卷风袭击建筑物的工程模型中的龙卷
风不可能是真实世界里的龙卷风，仅仅是模型而已。
真正的龙卷风不可能呼之即来，并且它会摧毁测量工
具。许多快速，激烈的物理过程现在都可以运用这种
物理模型来研究和理解。
一个大型软件系统由于其复杂程度可能无法直接研
究，但模型使之成为可能。在不损失细节的情况下，
模型可以抽象到一定的层次以使人们能够理解。可以
利用计算机对模型进行复杂的分析以找出可能的“问
题点”，如时间错误和资源竞争等。在对实物做出改
动前，通过模型研究系统内各组成部分之间的依赖关
系可以得出这种改动可能会带来哪些影响。
Page 12 ?
1.2、模型的层次
针对不同目的，模型可以采取各种形式及不同的抽象层
次。模型中所包含的信息量必须对应于以下几种目的：
Page 13 ?
（ 1）指导设计思路
在项目早期所建立的高层模型用于集中利益相关者的思路和强调一些重要的
选择方案。这些模型描述了系统的需求并代表了整个系统设计工作的起点。早
期的模型帮助项目发起者在把精力放在系统的细节问题之前研究项目可能的选
择方案。随着设计工作的进展，早期模型被更为精确的模型所替代。没有必要
详细保存早期研究过程中的种种选择方案和返工情况。早期模型的目的是帮助
获得思路。但最后得到的“思路模型”要在进行详细设计前记录下来。早期模 型
不需要达到实现阶段的模型的精确程度，无须涉及有关系统实现的一套概念。
建立这种模型只使用了 UML定义的组件的一个子集，比后期的设计阶段的模型
使用的组件要少得多。
当早期模型发展到具有一定精度的完整的视图模型时 — 例如，分析系统需求
的模型 — 那么要在开发过程进入下一阶段时将其保存下来。不断向模型中填加
信息的增量式开发（在这种情况下开发的推理过程也要保存和记录）与一般的
针对“死端点”进行研究直到得出正确的解决方案的随意漫步式开发之间一个 重
要的区别。后一种情况通常使人不知怎么着手，并且根本没有必要对整个开发
过程进行记录保存，除非遇到特殊情况需要对开发过程进行回溯。
Page 14 ?
在分析阶段和初步设计阶段所建立的模型以关键概念和最
终系统的各种机制为中心。这些模型以某种方式与最终系统匹
配。但是模型中丧失了细节信息，在设计过程中必需显式地补
充这些信息。使用抽象模型的目的是在处理局部细节问题前纠
正系统高层次的普遍问题。通过一个仔细的开发过程，这些模
型可以发展成最终模型，该过程保证最终获得的模型能够正确
实现初期模型的设计意图。必须具备跟踪能力来跟踪从基本模
型到完备模型的过程，否则无法保证最终系统正确包含了基本
模型所要表达的关键特性。基本模型强调语义，它们不需要涉
及系统实现方面的细节。有时确实会出现这种情况：在低层实
现方面的差别会使逻辑语义模糊不清。从基本模型到最后的实
现模型的途径必须清晰和简明，不论这个过程由代码生成器自
动实现还是由设计者人工实现。
（ 2） 系统基本结构的抽象说明
Page 15 ?
（ 3） 最终系统的详细规格说明
系统实现模型包含能够建造这个系统的足够信息，它不仅
要包括系统的逻辑语义和语法、算法、数据结构和确保能正确
完成系统功能的机制，而且还要包括系统制品的组织决定，这
些制品对个人之间的相互协作和使用辅助工具来说十分必要。
这种模型必须包括对模型元素进行打包的组件以便于理解和用
计算机进行自动处理。这不是目标应用系统的特性，而是系统
构造过程应具有的特性。
Page 16 ?
（ 4）典型或可能的系统范例
精心挑选的实例可以提高人们的观察能力并使系统的说
明和实现有实际效果。然而，即使有非常多的例子，也起不
到一段详细定义所起的效果。我们最终希望的是要让模型能
够说明一般的情形，这也是程序代码所要做的事情。不过典
型的数据结构、交互顺序或对象生命历程的例子对于理解复
杂系统很有益处。必须小心使用例子。从逻辑上来说，从一
大堆特例中归纳出最一般的情况是不可能的，但是大部分人
思考某一问题时总是首先考虑一些被精心挑选出来的有关该
问题的例子。范例模型仅是对模型的示例而不带有一般性的
描述，因此，人们会觉得这两种模型之间有差异。范例模型
一般只使用 UML定义的组件的子集。说明型模型和范例模型
在建模中都很有用。
Page 17 ?
模型可以完全描述一个独立系统，并且不需要参考外部信息
。更通常的情况是，模型是用相互区别的、不连续的描述单元组
织起来的，每个单元作为整体描述的一部分可以被单独进行存储
和操纵。这种模型带有必须与系统其他模型联系在一起的散件。
因为这些散件具有相关性和含义，因此它们能够与其他散件通过
各种方式结合来构造不同的系统。获得重用是一个好的建模方法
的重要目标。
模型要随时间发展变化。深度细化的模型源于较为抽象的
模型，具体模型源于逻辑模型。例如，开始阶段建立的模型是整
个系统的一个高层视图。随着时间的推进，模型中增加了一些细
节内容并引入了一些变化。再随着时间的推进，模型的核心焦点
从一个以用户为中心的前端逻辑视图转变成了一个以实现为中心
的后端物理视图。随着开发过程的进行和对系统的深入理解，必
须在各种层次上反复说明模型以获得更好的理解，用一个单一视
角或线性过程理解一个大型系统是不可能的。对模型的形式无所
谓“正确和错误”之分 。
（ 4）对系统全面的或部分的描述
Page 18 ?
1.3、模型内容
模型包含两个主要方面：语义方面的信息（语义）和
可视化的表达方法（表示法）。
语义方面用一套逻辑组件表达应用系统的含义，如类
、关联、状态、用例和消息。语义模型元素携带了模型的含
义即，它们表达了语义。语义建模元素用于代码生成、有效
性验证、复杂度的度量等，其可视化的外观与大多数处理模
型的工具无关。语义信息通常被称作模型。一个语义模型具
有一个词法结构、一套高度形式化的规则和动态执行结构。
这些方面通常分别加以描述（定义 UML的文献即如此），但
它们紧密相关，并且是同一模型的一部分。
Page 19 ?
可视化的表达方式以可使人观察、浏览和编辑的形式展示
语义信息。表示方式元素携带了模型的可视化表达方式，即
语义是用一种可被人直接理解的方式来表达的。它们并未增
添新的语义，但用一种有用的方式对表达式加以组织，以强
调模型的的排列。因此它们对模型的理解起指导作用。表达
式元素的语义来自于语义模型元素。但是，由于是由人来绘
制模型图，所以表达式元素并不是完全来自于模型的逻辑元
素。表达式元素的排列可能会表达出语义关系的另外含义，
这些语义关系很不明显或模棱两可，以至于在模型中不能形
式化地表达，但可给人启迪模。
Page 20 ?
1.4、模型说明了什么
一个模型是一个系统潜在配置的发生器；系统是它的范围
，或值。按照模型来进行系统配置是一种理想化的情况。然
而，有时模型所要求的种种条件在现实中无法实现。模型还
是对系统含义和结构的一般性说明。这种描述是模型的范围
，或含义。模型总是具有一定的抽象层次。它包含了系统中
的最基本的成分而忽略了其他内容。对模型来说，有以下几
方面需要考虑：
Page 21 ?
（ 1）抽象和具体
模型包含了系统的基本成分而忽略了其他内容。哪些是基
本内容哪些不是基本内容需要根据建模的目的来判定。这不
是说要把模型所含信息的精度一分为二，即只有精确和不精
确两种情况。可能会存在一系列表达精度不同但逐渐提高的
模型。建模语言不是程序设计语言。建模语言所表达的内容
可能很不精确，因为多余的详细内容与建模目的无关。具有
不同精度级别的模型可应用于同一个项目的各个阶段。用于
程序设计编码的模型要求必须与程序设计语言有关。典型的
情况是，在早期分析阶段使用高层次的，表达精度低的模型
。随着开发过程的深入，所用的模型越来越细化，最终所使
用的模型包含了大量的细节内容，具有很高的精度。
Page 22 ?
一个模型可以告诉我们“做什么”（说明），也可以告
诉我们“一个功能是如何实现的 ——— 即怎么做”（实现）
。建模时要注意区分这两方面。在花大量时间研究怎么做之
前很重要的一点就是要正确分析出系统要做什么。建模的一
个重要的侧面是对具体实现细节进行抽象。在说明和实现之
间可能有一系列相关关系，其中在某层次中的说明就是对它
上一层次的实现。
(2) 说明和实现
Page 23 ?
模型主要是描述性的。模型所描述的是一个个实
例，这些实例仅是作为例子才出现在模型中的。大
部分实例仅在运行的一部分时间中才存在。有时，
运行实例自身是对其他事物的描述。我们把这些混
杂对象称做元模型（ Metamodel）。更深一层次的看
，认为任何事物不是描述性的就是实例性的，这种
观点是不符合实际情况的。某一事物是实例还是描
述不是孤立区分的，与观察角度有关，大部分事物
都可以用多种角度来考察。
（ 3）阐述和举例
Page 24 ?
(4) 解释的变更
用一种建模语言对模型可能会有多种的解释。可以定义语
义变更点（ semantic variation point） ——— 可能会出现多种
解释的地方 ——— 给每一个解释一个语义变更名，以便可以标
识究竟使用了哪种解释。例如,Smalltalk语言的使用者要避免
在系统实现模型种出现多重继承关系，因为 Smalltalk语言不支
持多重继承。而其他程序设计语言使用者可能会在模型种使用
多重继承。语义变更点支持多种具体的实现过程 。
Page 25 ?
2,建 模
建模的定义：
建模是对现实的简化。 就是把复杂的系统变成小的系统，
采用“各个击破”的原则逐一解决。
Page 26 ?
2.1、为什么要建模
建立大厦和建立茅草屋的区别是建设茅草屋不需要设计。
要生产合格的软件就要有一套关于体系结构、过程和工具的
规范。
Page 27 ?
2.2、建模的目标
1）模型帮助我们按照实际情况或按照我们所需要的样式对
系统进行可视化。
2）模型允许我们详细说明系统的结构和行为。
3）模型给出一个知道我们构造系统的模板。
4）模型对我们的决策进行文档化。
Page 28 ?
2.3、建模的误区
? 无论你遵从的是重量级的方法,比如 Enterprise Unified
Process(EUP)，还是轻量级的开发过程，如 Extreme
Programming(XP)，建模在软件开发中都是不可或缺的。
但不幸的是其中充斥着各种谬误与迷思。
这来自于各个方面，有从理论家错误的研究、数十年来信
息技术领域内的文化沉积、软件工具开发商天花乱坠半的
市场宣传以及象 Object Management Group (OMG)和 IEEE
这类组织的标准
Page 29 ?
误区一：建模就等于是写文档
? 事实分析：“模型”与“文档”这二者在概念上是风马牛
不相及的－－－－你可以拥有一个不是文档的模型和不是
模型的文档。
建模很象是作计划：作计划的价值在于计划编制的过程中
而非计划本身；价值体现在建模的活动中，而非模型本身
实际上，模型不是你系统中的一部分正式的文档，而且在
完成它们的使命后可以被丢掉。你会发现值得保留的只有
很少的模型，而且它一定是非常完美。
Page 30 ?
误区二：从开始阶段你可以考虑到所
有的一切
怎么才能走出这个误区呢？
首先，你必须认识到你不能考虑到所有的细枝末节。
第二，认识到不管你的最初所作的规格说明书有多好，但
注定代码会很快地与之失去同步，即便是你自己建模自己
编码。一个基本的道理就是代码永远只会和代码保 持一致。
第三，认识到迭代法（小规模地建模，编一些代码，做一些
测试，可能还会做一个小的工作版本）是软件开发的准则。
它是现代重量级的软件开发过程（如 EUP），以及轻量级
（如 XP)的基本原理。
Page 31 ?
误区三：建模是在浪费时间
? 许多人都这样认为，这主要是因为他们所接受的教育仅仅
局限于如何编写代码，对于完整的开发流程鲜有接触。而
且他们的经验也仅限于如何实现代码，就如初级程序员。
他们放弃了提高效率和学习技能的机会，这些技能能够使
他们很容易地适应不同的项目或组织。
? 事实分析：在大多数情况下，在开始编码之前画一个草图
、开发一个粗率的原型或者制作一些索引卡片都能提高你
的生产效率。高效的开发者在编码之前都要进行建模工作
。另外，建模是一种很好的在项目组成员与项目负责人之
间沟通途径。你们在这个过程中探讨问题，从而对所要的
是一个什么样的东西可以得到更好的 理解，涉及到该 项目
中的每个成员也可得到对该项目有一个从分的了解。
Page 32 ?
误区四：所有的开发人员都知道如何建模
? 我们现在面临照这样一个严重的问题：许多不是开发人员的
人，包括高级经理和用户，不知道软件是如何建 成的。其
结果，他们不能够区分开熟练的开发者和一般的程序员（当
然也分不清高级程序员和一般程序 员），他们想当然地认
为所有的开发人员都具备从头到尾开发整个系统的技能。
? 事实分析：这肯定是不正确的。建模的技能，是只有当一个
开发者通过学习它，并经过长期的实践才能够掌握。一些非
常聪明的程序员常常相信自己无所不能，正因为这样的狂妄
自大，他们承当的一些任务是他们根本就没有相应的技能去
完成的。软件开发是如此的复杂，单单一个人是很难具备所
有的技能去成功地进行开发，甚至也不可能去配置有一定复
杂程度的系统。开发者应该有自知之明，明白他们自己的弱
点，学无止境。通过互相取长补短，建模者可从程序员身上学
到一项技术的具体细节，程序员也可从建模者那里学到有价值
的设计和体系结构的技术。
Page 33 ?
2.4、建模十条原则
? 仅有数据模型对于现代软件是不够的。
? 接收变化，并且允许你的模型能够随着时间进行改进。 你不能
冻结它们，然后就期待着成功。
? 模型并不一定就是文档，文档也不一定就是模型。
? 大多数的模型可能也应该被丢弃。
? 只有代码才能与代码保持真正的同步。
? 一些简单的工具，比如白板，就完全足以应付大多数建模工作。
? 思考，然后再编码。
? 你总能从别人身上学到东西。
? 建模可以用一种轻盈的方式。
? 设计直到代码发布以后才算完成。
Page 34 ?
2.5、怎样成为优秀的软件模型设计者
? 1,人远比技术重要
? 2,理解你要实现的东西
? 3,谦虚是必须的品格
? 4,需求就是需求
? 5,需求其实很少改变，改变的是你对需求的理解
? 6,经常阅读
? 7,降低软件模块间的耦合度
? 8,提高软件的内聚性
? 9,考虑软件的移植性
? 10,接受变化
Page 35 ?
? 11,不要低估对软件规模的需求
? 12,性能仅仅是很多设计因素之一
? 13,管理接口
? 14,走近路需要更长的时间
? 15,别信赖任何人
? 16,证明你的设计在实践中可行
? 17,应用已知的模式
? 18,研究每个模型的长处和弱点
? 19,在现有任务中应用多个模型
? 20,教育你的听众
? 21,带工具的傻瓜还是傻瓜
? 22,理解完整的过程
Page 36 ?
? 23,常做测试，早做测试
? 24,把你的工作归档
? 25,技术会变，基本原理不会
