第九章 面向对象方法学引论

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

9.1 面向对象方法学概述

传统方法学存在的问题 生产率提高的幅度远不能满足需要 软件重用程度很低 软件仍然很难维护 软件往往不能满足用户的需求

9.1 面向对象方法学概述

传统方法学出现问题的原因 瀑布模型的缺点

僵化 瀑布模型要求

生命周期各阶段间遵守严格的顺序 预先定义并“冻结”软件需求

实际情况 软件开发往往在反复实践中完成 某些系统的需求的一个逐渐明确的过程 , 且预先定义的需求

到软件完成时可能已经过时

9.1 面向对象方法学概述

对象？（面向对象语言）

在问题空间中，对象是……• 现实世界中存在的实体• 应用所关心的抽象概念 , 具有明确边界和意义的具 体事物

在解空间 ( 计算机系统 ) 中，对象是……• 封装 (encapsulation) 了数据和操作的通信单位

9.1 面向对象方法学概述

特点

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

9.1 面向对象方法学概述

面向对象方法具有下述 4 个要点：OO=Objects+Classes+Inheritance+ Communication with messages

对象：世界是由对象组成类： 对象可划分为类 , 单个对象可视为某一类的实例继承 : 下层子类与上层父类有相同特征 消息传递：对象之间只能通过传递消息实现

彼此通信

与人类习惯的思维方法一致稳定性好可重用性好较易开发大型软件产品可维护性好

9.1.2 面向对象方法学的优点

9.2 面向对象的概念

对象的定义 定义 1

对象是具有相同状态的一组操作的集合。 该定义是从面向对象程序设计的角度看“对象”。

定义 2 对象是对问题域中某个东西的抽象，这种抽象反映了系

统保存有关这个东西的信息或与它交互的能力。也就是说，对象是对属性值和操作的封装。

这个定义着重从信息模拟的角度看待“对象”。

对象的定义 定义 3 ： 对象∷ = 〈 ID,MS,DS,MI 〉。其

中， ID 是对象的标识或名字， MS 是对象中的操作集合， DS 是对象的数据结构， MI 是对象受理的消息名集合 ( 即对外接口 ) 。

9.2 面向对象的概念

9.2 面向对象的概念

对象的特点

(1) 以数据为中心。(2) 对象是主动的。(3) 实现了数据封装。(4) 本质上具有并行性。(5) 模块独立性好。

9.2 面向对象的概念

类（ class ）实例（ instance ）方法（ method ）属性（ attribute ）封装（ encapsulation ）继承（ inheritance ）多态性（ polymorphism ）重载（ overloading ）

9.3 面向对象建模

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

9.3 面向对象建模

面向对象方法需要建立 3 种形式的模型 :1)描述系统数据结构的对象模型2)描述系统控制结构的动态模型3)描述系统功能的功能模型

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

对象模型模拟客观世界实体的对象以及对象彼此间的关系的映射，描述了系统的静态结构。

对象模型由 UML 提供的类图 ( 类和类间关系 )构成 .

9.4 对象模型

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

1. 定义类

9.4.1 类图的基本符号

图 9.4 表示类的图形符号

9.4.1 类图的基本符号

类与类之间通常有关联、泛化（继承）、依赖和细化等 4 种关系。1. 关联关联表示两个类的对象之间存在某种语义上的联系。

例如，作家使用计算机，我们就认为在作家和计算机之间存在某种语义连接，因此，在类图中应该在作家类和计算机类之间建立关联关系。

9.4.2 表示关系的符号

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

9.4.2 表示关系的符号

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

9.4.2 表示关系的符号

（ 2 ） 关联的角色在任何关联中都会涉及到参与此关联的对象所扮演的角色（即起的作用） .

如果没有显式标出角色名，则意味着用类名作为角色名。

9.4.2 表示关系的符号

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

9.4.2 表示关系的符号

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

9.4.2 表示关系的符号

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

9.4.2 表示关系的符号

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

9.4.2 表示关系的符号

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

9.4.2 表示关系的符号

图 9.10 组合聚集示例

9.4.2 表示关系的符号

3. 泛化UML 中的泛化关系就是通常所说的继承关系 .

在 UML 中，用一端为空心三角形的连线表示泛化关系，三角形的顶角紧挨着通用元素。

注意，泛化针对类型而不针对实例。

泛化可进一步划分成普通泛化和受限泛化。

9.4.2 表示关系的符号

（ 1 ） 普通泛化普通泛化与 9.2.2节中讲过的继承基本相同 .

没有具体对象的类称为抽象类。抽象类通常作为父类，用于描述其他类（子类）的公共属性和行为。图示抽象类时，在类名下方附加一个标记值 {abstract} 。

9.4.2 表示关系的符号

图 9.11 抽象类示例

9.4.2 表示关系的符号

图下方的两个折角矩形是模型元素“笔记”的符号，其中的文字是注释，分别说明两个子类的操作 drive 的功能。

具体类有自己的对象，并且该类的操作都有具体的实现方法。

图 9.13 复杂类图示例

9.4.2 表示关系的符号

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

9.4.2 表示关系的符号

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

{完全 }

人人

女人女人男人男人

性别

9.4.2 表示关系的符号

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

9.4.2 表示关系的符号

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

9.4.2 表示关系的符号

它规定了对象模型中的对象的合法变化序列。

UML 提供的状态图来描绘对象的状态、触发状态转换的事件以及对象的行为（对事件的响应）。

每个类的动态行为用一张状态图来描绘 .

动态模型是基于事件共享而互相关联的一组状态图的集合。

9.5 动态模型

功能模型指明了系统应该“做什么” 。

功能模型用一组数据流图表示。

UML 提供的用例图是进行需求分析和建立功能模型的强有力工具。（面向对象方法 )

用例模型描述的是外部行为者 (actor ）所理解的系统功能。（从用户的角度来看待系统）

9.6 功能模型

9.6.1 用例图

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

9.6.1 用例图

1. 系统 系统被看作是一个提供用例的黑盒子，内部如何工作、

用例如何实现，这些对于建立用例模型来说都是不重要的。

2. 用例 一个用例是可以被行为者感受到的、系统的一个完整的功能。

3. 行为者 行为者是指与系统交互的人或其他系统，它代表外部实

体。使用用例并且与系统交互的任何人或物都是行为者。

9.6.1 用例图

4. 用例之间的关系 UML 用例之间主要有扩展和使用两种关系，它们是泛

化关系的两种不同形式。 （ 1 ） 扩展关系 向一个用例中添加一些动作后构成了另一个用例，这两

个用例之间的关系就是扩展关系，后者继承前者的一些行为，通常把后者称为扩展用例。

（ 2 ） 使用关系 当一个用例使用另一个用例时，这两个用例之间就构成

了使用关系。如果在若干个用例中有某些相同的动作，则可以把这些相同的动作提取出来单独构成一个用例（称为抽象用例）

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

9.6.2 用例建模

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

面向对象建模技术所建立的 3 种模型，分别从 3 个不同侧面描述了所要开发的系统。

对象模型则定义了做事情的实体 ;

动态模型明确规定对象在何种状态下接受了什么事件的触发；

功能模型指明了系统应该“做什么” .

9.7 3 种模型之间的关系

对象模型 动态模型 功能模型

静态结构 交互次序 数据变换

适用于：所有问题

涉及交互和时序的问题

运算量很大的问题

服务 行为 / 事件 处理

属性值 对象的生命周期 数据流

9.7 3 种模型之间的关系

第 10 章 面向对象分析

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

10.1 面向对象分析的基本过程

面向对象分析 抽取和整理用户需求并建立问题域精确模型的过程 .

理解 ---- 用户和分析员 表达 ---- 需求规格说明书（对象模型、动态模型、功能模型

）

验证 ----二义性、完善性

对象模型最基本、最重要、最核心。

10.1 面向对象分析的基本过程

3 个子模型

从不同的角度描述问题进行划分：

静态结构（对象模型） 3 个子模型 交互次序（动态模型） 数据变换（功能模型）

解决问题不同，三个子模型的重要程度也不同。

10.1 面向对象分析的基本过程

复杂问题的对象模型的 5 个层次

五个层次像是对象模型的 5张水平切片， 一层比一层显示出对象模型的更多细节。

主题指读者理解大型、复杂模型的一种机制（记忆的7+2原则）

面向对象分析的过程 寻找类与对象 识别结构 识别主题 定义属性 建立动态模型 建立功能模型 定义服务

分析不可能严格地按照预定顺序进行，大型、复杂系统的模型需要反复构造多遍才能建成。

10.1 面向对象分析的基本过程

10.2 需求陈述

需求陈述是阐明“做什么”，而不是“怎样做”

问题范围功能需求性能需求应用环境假设条件

自动取款机（ ATM ）系统的需求描述

10.2 需求陈述

10.3 建立对象模型

10.3.1 确定类与对象 1.找出候选的类与对象 2.筛选出正确的类与对象

10.3.2 确定关联 1.初步确定关联 2.筛选（根据下述标准删除候选关联） 3.进一步完善

10.3 建立对象模型

ATM 系统原始的类图

10.3 建立对象模型

10.3.3 划分主题按问题领域确定主题使不同主题内的对象相互间依赖和交互最少的原则确定主题

10.3.4 确定属性既与问题域有关，也和目标系统的任务有关。 应该仅考虑与具体应用直接相关的属性，不要考虑那些超出所要解决的问题范围的属性。

经过筛选之后，得到 ATM 系统中各个类的属性，如图所示。

10.3 建立对象模型

10.3 建立对象模型

10.3.5 识别继承关系自底向上： 抽象出现有类的共同性质泛化出父

类，这个过程实质上模拟了人类归纳思维过程。自顶向下： 把现有类细化成更具体的子类，这

模拟了人类的演绎思维过程。

10.3.6 反复修改 一次建模过程很难得到完全正确的对象模型。

10.4 建立动态模型

动态模型：表示瞬时的系统行为，规定对象的合法变化序列。 不适合：仅存储静态数据的系统 ( 例如数据库 ) 适合：交互式系统

步骤：编写典型交互行为的脚本。

不可能包括每个偶然事件，但必须不遗漏常见的交互行为。

从脚本中提取出事件，确定触发每个事件的动作对象以及接受事件的目标对象。

按事件发生的次序，确定每个对象可能有的状态及状态间的转换关系，并用状态图描绘它们。

比较各个对象的状态图，检查一致性。

10.4 .1 编写脚本

脚本：是一个事件序列，描述用户 ( 或其他外部设备 ) 与目标系统之间的典型交互过程。

实质：分析用户对系统交互行为的要求。 编写脚本时，需要与用户充分交换意见，编写后还需用户审查与修改。

典型交互行为的脚本 正常情况 特殊情况

如：输入或输出的数据为最大值 /最小值 出错 /异常情况

出错处理，是大多数交互式系统最难实现的部分。 比如提供：“异常中止，取消，帮助，状态查询”等功能

10.4.2 设想用户界面

分析阶段重在分析“应用逻辑”，但也不能完全忽略“用户界面”，此阶段的用户界面 不重在细节， 重在在界面下的信息交换方式：必须能完成全部必要的

信息交换，而不会丢失重要的信息。 方法：

快速建立用户界面的原型，供用户试用与评价。

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

10.4.3　画事件跟踪图

是简化的 UML 顺序图竖线：对象；水平线：事件，箭头方向从事件的发送对象指向接

受对象； 时间：从上向下，表示事件发生的先后。箭头线之间的间距并没有具体含义。

　　图 10.8 ATM 系统正常情况下的事件跟踪图

储户 ATM 总行 分行插卡

要求密码输入密码

请求验证帐户 请求分行验证帐户帐户有效帐户有效要求事务类型

输入类型要求输入取款额输入取款额 请求处理事务 请求分行处理事务

分行事务成功事务成功吐出现金请求拿走现金拿走现金

请求继续此事务结束

印帐单退卡请求拿走卡拿走卡显示主屏幕

10.4.4 画状态图

类的状态图：描绘一类对象由事件序列引出的状态序列。圆角矩形：状态 有向边：　由事件引起的状态 “转换”。

根据事件跟踪图，画某个类的状态图： 该类：对应事件跟踪图中的某条竖线 事件：　　射入该竖线的那些水平箭头线。 状态：　　射出该竖线的那些水平箭头线。

do/ 在该状态时会做的行为 ( 往往是引起另一类对象状态转换的事件 )

10.4.5 审查动态模型

将各个类的状态图通过共享事件合并，则构成系统的动态模型。

应检查系统级的一致性

ATM类

状态图

10.5 建立功能模型

功能模型 用数据流图描述：数据之间的依赖关系，以及数据处理功能（可用 IPO图、伪码等进一步描述）。

10.5.1 画出基本数据流图 10.5.2 画出功能级数据流图 10.5.3 描述处理框功能

10.6 定义服务

“ 对象”封装了： 属性 可施加在这些属性上的操作 ( 即服务 )

在建立动态模型和功能模型之后，才能最终确定类的服务：

10.6 定义服务

常规操作 无需在对象图中显式地表示 如：读、写属性的操作

从事件中导出的操作 对象收到消息，须有消息指定的操作，该操作改变对象的

状态并启动相应的服务 与处理框相对应的操作

每个处理框都与一个 /多个对象上的操作相对应 利用继承机制减少冗余操作

尽量抽取相似类的公共属性和操作，以建立新父类

10.7 OOA 小结

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