1. 第九章 面向对象方法学引论
9.1 面向对象方法学概述
9.2 面向对象的概念
9.3 面向对象建模
9.4 对象模型
9.5 动态模型
9.6 功能模型
9.7 3 种模型之间的关系

2. 9.1 面向对象方法学概述
 传统方法学存在的问题
 生产率提高的幅度远不能满足需要
 软件重用程度很低
 软件仍然很难维护
 软件往往不能满足用户的需求

3. 9.1 面向对象方法学概述
 传统方法学出现问题的原因
 瀑布模型的缺点
 僵化
 瀑布模型要求
 生命周期各阶段间遵守严格的顺序
 预先定义并“冻结”软件需求
 实际情况
 软件开发往往在反复实践中完成
 某些系统的需求的一个逐渐明确的过程 , 且预先定义的
需求到软件完成时可能已经过时

4. 9.1 面向对象方法学概述
 对象？（面向对象语言）
在问题空间中，对象是……
• 现实世界中存在的实体
• 应用所关心的抽象概念 , 具有明确边界和
意义的具 体事物
在解空间 ( 计算机系统 ) 中，对象是……
• 封装 (encapsulation) 了数据和操作的
通信单位

5. 9.1 面向对象方法学概述
特点
尽可能模拟人类习惯的思维方式 , 即问
题域与求解域在结构上尽可能一致 . 与传统方
法相反 ,OOM 以数据或信息为主线 , 把数据和
操作结合构成统一体 . 这时程序不再是一系列
工作在数据上的函数集合 , 而是相互协作又彼
此独立的对象的集合 .

6. 9.1 面向对象方法学概述
面向对象方法具有下述 4 个要点：
OO=Objects+Classes+Inheritance+
Communication with messages
对象：世界是由对象组成
类： 对象可划分为类 , 单个对象可视为某一类的
实例
继承 : 下层子类与上层父类有相同特征
消息传递：对象之间只能通过传递消息实现
彼此通信

7. 9.1.2 面向对象方法学的优点
与人类习惯的思维方法一致
稳定性好
可重用性好
较易开发大型软件产品
可维护性好

8. 9.2 面向对象的概念
对象的定义
 定义 1
 对象是具有相同状态的一组操作的集合。
 该定义是从面向对象程序设计的角度看“对象”。
 定义 2
 对象是对问题域中某个东西的抽象，这种抽象反映
了系统保存有关这个东西的信息或与它交互的能力
。也就是说，对象是对属性值和操作的封装。
 这个定义着重从信息模拟的角度看待“对象”。

9. 9.2 面向对象的概念
对象的定义
 定义 3 ： 对象∷ = 〈 ID,MS,DS,MI 〉。其
中， ID 是对象的标识或名字， MS 是对象中
的操作集合， DS 是对象的数据结构， MI 是
对象受理的消息名集合 ( 即对外接口 ) 。

10. 9.2 面向对象的概念
 对象的特点
(1) 以数据为中心。
(2) 对象是主动的。
(3) 实现了数据封装。
(4) 本质上具有并行性。
(5) 模块独立性好。

11. 9.2 面向对象的概念
 类（ class ）
 实例（ instance ）
 方法（ method ）
 属性（ attribute ）
 封装（ encapsulation ）
 继承（ inheritance ）
 多态性（ polymorphism ）
 重载（ overloading ）

12. 9.3 面向对象建模
建立问题模型是人们理解表达问题的方法
之一。
模型是对事物作出的一种抽象，是对事物
的一种形式化的描述。
模型常由专门的语言 ( 一组图示符号和规
则 ) 来描述 .

13. 9.3 面向对象建模
面向对象方法需要建立 3 种形式的模型 :
l描述系统数据结构的对象模型
l描述系统控制结构的动态模型
l描述系统功能的功能模型
在不同的应用问题中，这 3 种模型的相对重要程
度会有所不同，对象模型始终都是最重要、最基本、最
核心的。
典型的软件系统组合了上述 3 方面内容：
使用数据结构 ( 对象模型 ) ，执行操作 ( 动态模
型 ) ，并且完成数据值的变化 ( 功能模型 ) 。

14. 9.4 对象模型
对象模型模拟客观世界实体的对象以及对象
彼此间的关系的映射，描述了系统的静态结
构。
对象模型由 UML 提供的类图 ( 类和类间关系
) 构成 .

15. 9.4.1 类图的基本符号
类图描述类及类与类之间的静态关系。
类图是一种静态模型，它是创建其他 UML 图的
基础。
一个系统可以由多张类图来描述，一个类也可
以出现在几张类图中。
1. 定义类

16. 9.4.1 类图的基本符号
图 9.4 表示类的图形符号

17. 9.4.2 表示关系的符号
类与类之间通常有关联、泛化（继承）、依赖和细化
等 4 种关系。
1. 关联
关联表示两个类的对象之间存在某种语义上的联系。
例如，作家使用计算机，我们就认为在作家和计算机
之间存在某种语义连接，因此，在类图中应该在作家
类和计算机类之间建立关联关系。

18. 9.4.2 表示关系的符号
（ 1 ） 普通关联
普通关联是最常见的关联关系，只要在类与类之间存
在连接关系就可以用普通关联表示。

19. 9.4.2 表示关系的符号
在表示关联的直线两端可以写上重数（ multiplicity ）
，它表示该类有多少个对象与对方的一个对象连接。
重数的表示方法通常有：
0…1 表示 0 到 1 个对象
0…* 或 * 表示 0 到多个对象
1+ 或 1…* 表示 1 到多个对象
1…15 表示 1 到 15 个对象
3 表示 3 个对象
如果图中未明确标出关联的重数，则默认重数是 1 。

20. 9.4.2 表示关系的符号
（ 2 ） 关联的角色
在任何关联中都会涉及到参与此关联的对象所扮演的
角色（即起的作用） .
如果没有显式标出角色名，则意味着用类名作为角色
名。

21. 9.4.2 表示关系的符号
（ 3 ） 限定关联
限定关联通常用在一对多或多对多的关联关系中，可
以把模型中的重数从一对多变成一对一，或从多对多
简化成多对一。
在类图中把限定词放在关联关系末端的一个小方框内
。

22. 9.4.2 表示关系的符号
（ 4 ） 关联类
为了说明关联的性质可能需要一些附加信息。可以引
入一个关联类来记录这些信息。关联中的每个连接与
关联类的一个对象相联系。关联类通过一条虚线与关
联连接。

23. 9.4.2 表示关系的符号
2. 聚集
聚集是关联的特例。
聚集表示类与类之间的关系是整体与部分的关系
。
在陈述需求时使用的“包含”、“组成”、“分
为……部分”等字句，往往意味着存在聚集关系
。
除了一般聚集之外，还有两种特殊的聚集关系，
分别是共享聚集和组合聚集。

24. 9.4.2 表示关系的符号
（ 1 ） 共享聚集
如果在聚集关系中处于部分方的对象可同时参与多个
处于整体方对象的构成，则该聚集称为共享聚集。
在表示关联关系的直线末端紧挨着整体类的地方画一
个空心菱形。

25. 9.4.2 表示关系的符号
（ 2 ） 组合聚集
如果部分类完全隶属于整体类，部分与整体共存，整
体不存在了部分也会随之消失（或失去存在价值了）
，则该聚集称为组合聚集（简称为组成）。
组成关系用实心菱形表示。

26. 9.4.2 表示关系的符号
图 9.10 组合聚集示例

27. 9.4.2 表示关系的符号
3. 泛化
UML 中的泛化关系就是通常所说的继承关系 .
在 UML 中，用一端为空心三角形的连线表示泛化关系
，三角形的顶角紧挨着通用元素。
注意，泛化针对类型而不针对实例。
泛化可进一步划分成普通泛化和受限泛化。

28. 9.4.2 表示关系的符号
（ 1 ） 普通泛化
普通泛化与 9.2.2 节中讲过的继承基本相同 .
没有具体对象的类称为抽象类。抽象类通常作为父
类，用于描述其他类（子类）的公共属性和行为。
图示抽象类时，在类名下方附加一个标记值
{abstract} 。

29. 9.4.2 表示关系的符号
图下方的两个折角矩形是模型元
素“笔记”的符号，其中的文字
是注释，分别说明两个子类的操
作 drive 的功能。
图 9.11 抽象类示例

30. 9.4.2 表示关系的符号
具体类有自己的对象，并且该类的操作都有具体的实
现方法。
图 9.13 复杂类图示例

31. 9.4.2 表示关系的符号
（ 2 ） 受限泛化
预定义的约束有 4 种： 多重、不相交、完全和不完全
。
多重继承指的是，一个子类可以同时多次继承同一个
上层基类。

32. 9.4.2 表示关系的符号
完全继承指的是父类的所有子类都已在类图中穷举出
来了，图示符号是指定 { 完全 } 约束。
不完全继承与完全继承恰好相反，父类的子类并没有
都穷举出来，随着对问题理解的深入，可不断补充和
维护，这为日后系统的扩充和维护带来很大方便。不
完全继承是一般情况下默认的继承关系。
人
性别
{ 完全 }
男人 女人

33. 9.4.2 表示关系的符号
4. 依赖和细化
（ 1 ） 依赖关系
依赖关系描述两个模型元素（类、用例等）之间的语
义连接关系： 其中一个模型元素是独立的，另一个模
型元素依赖于独立的模型元素，如果独立的模型元素
改变了，将影响依赖于它的模型元素。
在 UML 的类图中，用带箭头的虚线连接有依赖关系的
两个类，箭头指向独立的类。

34. 9.4.2 表示关系的符号
（ 2 ） 细化关系
当对同一个事物在不同抽象层次上描述时，这些描述
之间具有细化关系。
细化用来协调不同阶段模型之间的关系，表示各个开
发阶段不同抽象层次的模型之间的相关性，常常用于
跟踪模型的演变。

35. 9.5 动态模型
它规定了对象模型中的对象的合法变化
序列。
UML 提供的状态图来描绘对象的状态、触发状
态转换的事件以及对象的行为（对事件的响
应）。
每个类的动态行为用一张状态图来描绘 .
动态模型是基于事件共享而互相关联的一组状
态图的集合。

36. 9.6 功能模型
功能模型指明了系统应该“做什么” 。
功能模型用一组数据流图表示。
UML 提供的用例图是进行需求分析和建立功能
模型的强有力工具。（面向对象方法 )
用例模型描述的是外部行为者 (actor ）所理解
的系统功能。（从用户的角度来看待系统）

37. 9.6.1 用例图
一幅用例图包含的模
型元素有系统、行为
者（角色）、用例
（系统的一个对某个
行为者可见的完整功
能）、行为者与用例
之间的（可见）关系
、用例与用例之间的
（使用 / 扩展）关系。

38. 9.6.1 用例图
1. 系统
系统被看作是一个提供用例的黑盒子，内部如何
工作、用例如何实现，这些对于建立用例模型来说
都是不重要的。
2. 用例
一个用例是可以被行为者感受到的、系统的一
个完整的功能。
3. 行为者
行为者是指与系统交互的人或其他系统，它代表
外部实体。使用用例并且与系统交互的任何人或物
都是行为者。

39. 9.6.1 用例图
4. 用例之间的关系
UML 用例之间主要有扩展和使用两种关系，它们是
泛化关系的两种不同形式。
（ 1 ） 扩展关系
向一个用例中添加一些动作后构成了另一个用例
，这两个用例之间的关系就是扩展关系，后者继承
前者的一些行为，通常把后者称为扩展用例。
（ 2 ） 使用关系
当一个用例使用另一个用例时，这两个用例之
间就构成了使用关系。如果在若干个用例中有某些
相同的动作，则可以把这些相同的动作提取出来单
独构成一个用例（称为抽象用例）

40. 含扩展和使用关系的用例图

41. 9.6.2 用例建模
一个用例模型由若干幅用例图组成。创建用
例模型的工作包括：
定义系统
寻找行为者和用例
描述用例
定义用例之间的关系
确认模型

42. 9.7 3 种模型之间的关系
面向对象建模技术所建立的 3 种模型，分别从 3 个不同
侧面描述了所要开发的系统。
对象模型则定义了做事情的实体 ;
动态模型明确规定对象在何种状态下接受了什么事件
的触发；
功能模型指明了系统应该“做什么” .

43. 9.7 3 种模型之间的关系
对象模型 动态模型 功能模型
静态结构 交互次序 数据变换
适用于： 涉及交互和时序的 运算量很大的问题
所有问题 问题
服务 行为 / 事件 处理
属性值 对象的生命周期 数据流

44. 第 10 章 面向对象分析
10.1 面向对象分析的基本过程
10.2 需求陈述
10.3 建立对象模型
10.4 建立动态模型
10.5 建立功能模型
10.6 定义服务
10.7 小结

45. 10.1 面向对象分析的基本过程
 面向对象分析
抽取和整理用户需求并建立问题域精确模型的过
程.
理解 ---- 用户和分析员
表达 ---- 需求规格说明书 （对象模型、动态模型
、功能模型）
验证 ---- 二义性、完善性
对象模型最基本、最重要、最核心。

46. 10.1 面向对象分析的基本过程
 3 个子模型
从不同的角度描述问题进行划分：
静态结构（对象模
型）
3 个子模型 交互次序（动态模型）
数据变换（功能模
型）
解决问题不同，三个子模型的重要程度也不同
。

47. 10.1 面向对象分析的基本过程
主题指读者理解
 复杂问题的对象模型的 5 个层次 大型、复杂模型
的一种机制（记
忆的 7+2 原则）
五个层次像是对象模型的 5 张水平切片，
一层比一层显示出对象模型的
更多细节。

48. 10.1 面向对象分析的基本过程
 面向对象分析的过程
寻找类与对象
识别结构
识别主题
定义属性
建立动态模型
建立功能模型
定义服务
分析不可能严格地按照预定顺序进行，
大型、复杂系统的模型需要反复构造多遍才能建
成。

49. 10.2 需求陈述
 需求陈述是阐明“做什么”，而不是“怎样
做”
问题范围
功能需求
性能需求
应用环境
假设条件

50. 10.2 需求陈述
 自动取款机（ ATM ）系统的需求描述

51. 10.3 建立对象模型
 10.3.1 确定类与对象
 1. 找出候选的类与对象
 2. 筛选出正确的类与对象
 10.3.2 确定关联
 1. 初步确定关联
 2. 筛选（根据下述标准删除候选关联）
 3. 进一步完善

52. 10.3 建立对象模型
ATM 系统原始的类图

53. 10.3 建立对象模型
 10.3.3 划分主题
 按问题领域确定主题
 使不同主题内的对象相互间依赖和交互最少
的原则确定主题
 10.3.4 确定属性
 既与问题域有关，也和目标系统的任务有关
。
 应该仅考虑与具体应用直接相关的属性，不
要考虑那些超出所要解决的问题范围的属性
。

54. 10.3 建立对象模型
经过筛选之后，得到 ATM 系统中各个类的属性，如图所示。

55. 10.3 建立对象模型
 10.3.5 识别继承关系
 自底向上： 抽象出现有类的共同性质泛化出
父类，这个过程实质上模拟了人类归纳思维
过程。
 自顶向下： 把现有类细化成更具体的子类，
这模拟了人类的演绎思维过程。
 10.3.6 反复修改
 一次建模过程很难得到完全正确的对象模型
。

56. 10.4 建立动态模型
 动态模型：表示瞬时的系统行为，规定对象
的合法变化序列。
 不适合：仅存储静态数据的系统 ( 例如数据库 )
 适合：交互式系统
 步骤：
 编写典型交互行为的脚本。
 不可能包括每个偶然事件，但必须不遗漏常见
的交互行为。
 从脚本中提取出事件，确定触发每个事件的动作
对象以及接受事件的目标对象。
 按事件发生的次序，确定每个对象可能有的状态
及状态间的转换关系，并用状态图描绘它们。
 比较各个对象的状态图，检查一致性。

57. 10.4 .1 编写脚本
 脚本：是一个事件序列，描述用户 ( 或其他外部设备 )
与目标系统之间的典型交互过程。
 实质：分析用户对系统交互行为的要求。
 编写脚本时，需要与用户充分交换意见，编写后还需用户审查
与修改。
 典型交互行为的脚本
 正常情况
 特殊情况
 如：输入或输出的数据为最大值 / 最小值
 出错 / 异常情况
 出错处理，是大多数交互式系统最难实现的部分。
 比如提供：“异常中止，取消，帮助，状态查询”等功能

58. 10.4.2 设想用户界面
 分析阶段重在分析“应用逻辑”，但也不能完
全忽略“用户界面”，此阶段的用户界面
 不重在细节，
 重在在界面下的信息交换方式：必须能完成全部必
要的信息交换，而不会丢失重要的信息。
 方法：
 快速建立用户界面的原型，供用户试用与评价。

59. 图 10.7 初步设想出的 ATM 界面格式

60. 10.4.3 画事件跟踪图
 是简化的 UML 顺序图
 竖线：对象；
 水平线：事件，箭头方向从事件的发送对象指
向接受对象；
 时间：从上向下，表示事件发生的先后。
 箭头线之间的间距并没有具体含义。
图 10.8 ATM 系统正常情况下的事件跟踪图

61. 储户 ATM 总行 分行
插卡
要求密码
输入密码
请求验证帐户
请求分行验证帐户
帐户有效
要求事务类型 帐户有效
输入类型
要求输入取款额
输入取款额
请求处理事务
请求分行处理事务
分行事务成功
吐出现金 事务成功
请求拿走现金
拿走现金
请求继续此事务
结束
印帐单退
请求拿走卡
卡
拿走卡
显示主屏幕

62. 10.4.4 画状态图
 类的状态图：描绘一类对象由事件序列引出
的状态序列。
 圆角矩形：状态
 有向边： 由事件引起的状态 “转换”。
 根据事件跟踪图，画某个类的状态图：
 该类：对应事件跟踪图中的某条竖线
 事件： 射入该竖线的那些水平箭头线。
 状态： 射出该竖线的那些水平箭头线。
 do/ 在该状态时会做的行为 ( 往往是引起另一类对象状
态转换的事件 )

63. 10.4.5 审查动态模型
将各个类的状态图通过共享事件合并，则构
成系统的动态模型。
应检查系统级的一致性

64. A
T
M
类
状
态
图

65. 10.5 建立功能模型
 功能模型 用数据流图描述：数据之间的
依赖关系，以及数据处理功能（可用 IPO
图、伪码等进一步描述）。
 10.5.1 画出基本数据流图
 10.5.2 画出功能级数据流图
 10.5.3 描述处理框功能

66. 10.6 定义服务
 “ 对象”封装了：
 属性
 可施加在这些属性上的操作 ( 即服务 )
 在建立动态模型和功能模型之后，才能最终确定
类的服务：

67. 10.6 定义服务
 常规操作
 无需在对象图中显式地表示
 如：读、写属性的操作
 从事件中导出的操作
 对象收到消息，须有消息指定的操作，该操作改变对
象的状态并启动相应的服务
 与处理框相对应的操作
 每个处理框都与一个 / 多个对象上的操作相对应
 利用继承机制减少冗余操作
 尽量抽取相似类的公共属性和操作，以建立新父类

68. 10.7 OOA 小结
 面向对象分析使得软件工程师能够通过对对
象 , 属性和操作的表示来对问题建模 . 虽然
有很多不同的方法 , 但所有的方法均有共同
的特征 :
 类和类层次的表示
 对象—关系模型的创建
 对象—行为模型的导出