面向对象技术引论练习题
一, 给出下列概念的定义, 并说明它们在软件开发中的作用：
(1)对象 (2)类 (3)属性 (4)服务 (5)继承
(6)封装 (7) 关联 (8)聚合 (9) 消息 (10)抽象
二, 介绍面向对象方法的主要思想, 论述该方法为什么有利
于改进软件开发 。
三, 以你所学习的 OOA方法为背景, 阐述 OOA的主要过程与
策略 。
第三部分
面向对象的设计
概而言之，面向对象的设计（ OOD）就是运用面向对
象方法进行系统设计；但不同时期有不同内容及特点。
第一章 什么是面向对象的设计（ OOD）？
一、早期的 OOD（八十年代至九十年代初）：
历史：从 OOP发展到 OOD
G,Booch 1982 年发表, Object-Oriented Design”,
首次称, 面向对象的设计, 。
1986 年发表, Object-Oriented Development”
较完整地阐述了 OOD思想。
两个术语都用 OOD作为缩写，内容上也没有根本区别
R,J,Abbott 1983年提出正文分析方法，用规范的英语描述对一个问
题的解释，然后从描述中提取对象及其特征。 例：名词 —— 对象，动词
—— 操作。 被后来的许多 OOD方法所采用。
1986年后,相继出现了一批（早期的） OOD方法
早期的 OOD方法
Booch86—— Object-Oriented Development
面向对象的开发
GOOD—— General Object-Oriented Development
通用面向对象的开发
HOOD—— Hierarchical Object-Oriented Design
层次式面向对象的设计
OOSD—— Object-Oriented Structured Design
面向对象的结构设计
……
1、不是基于 OOA的
大多基于结构化分析结果（数据流图）
2、是 OO编程方法的延伸
多数方法与编程语言有关，特别受 Ada影响很大
3、不是纯 OO的
对某些 OO概念（如继承）缺少支持，
搀杂一些非 OO 概念（如数据流、包、模块等）
4、不是只针对软件生命周期的设计阶段
OOD中的,D” —— 指的是 Design 或 Development
多少涉及分析问题（如识别问题域的对象），但很不彻底
—— 早期的 OOD可看作现今 OOA&D方法的雏形
早期 OOD的特点：
二、现今（ 90年代）的 OOD
背景：
从结构化分析文档识别 OOD的对象并非良策，识别对象
的关键问题在于用 OO方法进行系统分析。
OO方法从设计发展到分析，出现 OOA方法。
OOA和 OOD构成完整的 OOA&D方法体系。
OOD基于 OOA，
识别对象由 OOA完成，
OOD的主要定义对象如何实现。
定义：
面向对象的设计（ OOD）就在是 OOA模型基础上运用
面向对象方法进行系统设计，目标是产生一个符合具
体实现条件的 OOD模型。
特点：
1,以面向对象的分析为基础, 一般不依赖结构化分析 。
2,与相应的 OOA方法共同构成一种 OOA&D方法体系 。 OOA
和 OOD采用一致的概念与原则, 但属于软件生命周期的
不同阶段, 有不同的目标及策略 。
3,较全面地体现面向对象方法的概念与原则 。
4,大多数方法独立于编程语言, 通过面向对象的分析
与设计所得到的系统模型可以由不同的编程语言实现 。
有多种 OOA&D方法,
Booch方法
Coad-Yourdon方法
Firesmith方法
Jacobson方法 (OOSE)
Martin-Odell方法
Rumbaugh方法 (OMT)
Wirfs-Brock方法
……
本课重点讲授
Coad/Yourdon
方法，加以适
当改进
Coad/Yourdon方法：
概念,对象、类、属性、服务、整体 -部分结构、一般 -特殊
结构、实例连接、消息连接、主题。
原则,抽象、封装、继承、关联、消息通讯、通用的组织方
法、粒度控制、行为分类。
识别类及对象
识别结构
识别主题
定义属性
定义服务
OOA过程
—— 五个活动
对象层
结构层
主题层
属性层
服务层
OOA模型
—— 五个层次
人机交互
部分
（ HIC）
问题域
部分
（ PDC）
任务管理
部分
（ TMC）
数据管理
部分
（ DMC）
对象层
结构层
主题层
属性层
服务层
OOD模型
—— 五个层次，四个部分
OOD过程 针对四个部分，进行四个相应的活动
设计问题域部分
设计人机交互部分的
设计任务管理部分
设计数据管理部分
上述每个活动都包含与 OOA相同的五个活动 ——
识别类及对象、识别结构、识别主题、定义属性、定义服务。
1、提高软件生产率
开发阶段：提高 20%，维护阶段提高更多。原因：
设计的投入在编程、测试时得到回报
OO方法使系统更易于理解
分析文档、设计文档、源程序对应良好
功能变化引起的全局性修改较少
OOD结果的复用
2、提高质量
现今的质量观点：
不仅是事后通过测试排除错误，而是着眼与软
件开发过程的每个环节，从分析、设计阶段开
始质量保证。
高质量不只是没有错误，而是好用、易用、可
移植、易维护，用户由衷地满意。
三,OOD的根本目标：
3、加强可维护性
需求是不断变化的（尽管可阶段性地“冻结”）
因素：客户业务、竞争形式、技术发展、规章制度 ……
—— 要求设计结果对变化有弹性
设计如何适应不可预见的变化？
—— 把易变部分和较稳定的部分隔离，
将变化的影响限制在局部
易变性：服务 >接口 >属性 >类
1,OOA与 OOD的分工
—— 两种不同的观点
做
什
么
怎
么
做
问题域与
系统责任
与实现有
关的因素
分
析
设
计
第
一
种
观
点
分 析 设 计
第二种观点
第二种观点的理由：
（ 1）在各种分析 /设计方法中
“做什么”和“怎么做”实际上
没有严格的划分”。
（ 2）过分强调, 分析不考虑怎
么做, 将使某些必须在 OOA考虑
的问题得不到完整的认识。
（ 3）由于 OO方法表示形式的一
致，不存在把细化工作留给设计
人员的必然理由。
（ 4）避免重复地认识同一事物，
并有利于分析结果的复用。
关键问题：对象的特征细节（如属
性的数据类型和服务流程图），是
在分析时定义还是在设计时定义？
例,Rumbaugh方法 (OMT)
和 Coad/ Yourdon方
法
四,O OA与 OOD的关系
2、一致的概念与表示法
前端 —— OOA 可以全部用 OO概念建模；
后端 —— OOP 可以全部用 OOPL支持的 OO概念编程。
OOD是承前启后中间环节
—— 使用与 OOA和 OOP一致的概念建立完整的、可实现的设计
模型。
3、不同的目标、内容和抽象层次
内容与目标：
OOA—— 主要 内容 是研究问题域和用户需求，运用面向对
象的观点和原则发现问题域中与系统责任有关的对象，以
及对象的特征和相互关系。 目标 是建立一个直接映射问题
域，符合用户需求的 OOA模型。
OOD—— 主要 内容 是以 OOA模型为基础，按照实现的要求进
行设计决策，包括全局性的决策和局部细节的设计。 目标
是产生一个满足用户需求，并且完全可实现的 OOD模型。
全局性设计决策,体系结构、分布方案、并发控制、人机
交互、数据管理等。 OOD方法应支持用户以 OO概念表达对
这些问题的设计。
局部细节的设计,对每个对象类的每个属性和每个服务给
出详细的定义 。
抽象层次：
OOA模型,OOD模型、源程序 都是对现实世界的抽象
—— 忽略了与系统责任无关的事物及特征。
三者又都是对计算机概念的抽象：
源程序忽略了与计算机硬件有关的细节，
OOD模型忽略了源程序的许多细节，
OOA模型进一步忽略了与实现条件有关的设计决策。
从对计算机概念的抽象而言,OOD模型的抽象级别低于
OOA模型而高于源程序。
概念,运用与 OOA部分相同的概
念 —— 没有增加新概念
对象、类、属性、服务 (操作 )、
封装、继承、消息、关联、聚合、
多态、主动对象 等
表示法,采用与 OOA一致的表示法
分析 设计
数据流图
（ DFD）
模块结构图 （ MSD）
实体 -关系图（ ERD）
传统方法分析与设
计之间的鸿沟
使分析
与设计
之间不
存在鸿
沟
OOA OOD
一致的
概念
一致的
表示法
类
图
类
图
面向对象的分析与设计
之间不存在鸿沟
第二章 OOD方法概貌
基本按 Coad/Yourdon方法讲授，做适当的改进和补充
新增的组成部分，隔
离实现条件
OOD—— 按实现条件对 OOA模型进行调整，并补充几
个新的组成部分（也是由对象构成）
与实现有关的因素：
图形用户界面系统
硬件、操作系统及网络
数据管理系统
其他 —— 编程语言、可复用构件库 ……
按实现条件调整
OOA模型
实现条件
实
现
条
件
基本思想：
尽可能隔离实现
条件对系统的影
响 —— 提供独立
的接口
对不可隔离的因
素，按实现条件
调整 OOA模型
实
现
条
件
OOD模型
—— 从两个侧面来描述
人
机
交
互
部
分
数
据
接
口
部
分
控制接口部分
问题域
部分
从一个侧面观察
OOD模型包括几个主要部分
—— 一个核心部分加几个外围部分
交
互
图 主
题
图
类
图
详
细
说
明
从另一侧面观察
OOD模型每个部分
如何用 OO概念表达
—— 采用 OOA的概念及
模型组织方式
OOA与 OOD的关系：
1、从 OOA到 OOD不是转换，不是细化；
—— 是调整和增补
问题域
部分
OOA
模型
将 OOA模型搬到 OOD；
进行必要的调整，
作为 OOD模型的问题域
部分；
人
机
交
互
部
分
数
据
接
口
部
分
控制接口部分
增补其它三个部分，成
为完整的 OOD模型。
2、采用一致的概念和表示法
—— 不存在分析与设计之间的鸿沟
3、有不同的侧重点和不同的策略
OOA主要针对问题域，识别有关的对象以及它们之
间的关系，产生一个映射问题域，满足用户需求，独立
于实现的 OOA模型。
OOD主要解决与实现有关的问题，基于 OOA模型，
针对具体的软、硬件条件（如机器、网络,OS,GUI、
DBMS等）产生一个可实现的 OOD模型。
4,OOA与 OOD可适合不同的生命周期模型
—— 瀑布模型、螺旋模型、增量模型、喷泉模型
OOA与 OOD之间可以顺序进行，也可交叉进行
OOD过程：
逐个设计 OOD模型的四个部分
问题域部分的设计
人机交互部分的设计
控制接口部分的设计
数据接口部分的设计
不强调次序
每个部分均采用与 OOA一致的 概念, 表示法 及 活动,
但具有自己独特的策略。
一、什么是问题域部分？
对 OOA结果按实现条件进行补充与调整就是问题域部分。
不是传统方法的“转换”，不存在鸿沟。
主要不是细化，但 OOA未完成的细节定义要在 OOD完成。
是对 OOA模型的补充与调整
第三章 问题域部分（ PDC）的设计
二、为什么需要问题域部分的设计？
在 OOA阶段只考虑问题域和系统责任,OOD则要考虑与具
体实现有关的问题，需要对 OOA结果的补充与调整；
使反映问题域本质的总体框架和组织结构长期稳定，而
细节可变；
稳定部分（ PDC）与可变部分（其它部分）分开，使系统
从容地适应变化；
有利于同一个分析用于不同的设计与实现；
支持系统族和相似系统的分析设计及编程结果复用；
使一个成功的系统具有超出其生存期的可扩展性。
三、如何进行问题域部分的设计？
1、继续运用 OOA的方法
—— 概念、表示法及一部分策略
2、使用 OOA结果，并加以修改
—— 需求的变化，新发现的错误
3、使用 OOA结果，并进行补充与调整（本节的重点）
（ 1）为复用设计与编程的类而增加结构
（ 2）增加一般类以建立共同协议
（ 3）按编程语言调整继承
（ 4）提高性能
（ 5）为数据存储管理增补属性与服务
（ 6）为编程方便增加底层成分
（ 1）为复用设计与编程的类而增加结构
OOA识别和定义的类是本次开发中新定义的，需要进行
编程。
如果已存在一些可复用的类，而且这些类既有分析、设
计时的定义，又有源程序，那么，复用这些类即可提高
开发效率与质量。
可复用的类可能只是与 OOA模型中的类相似，而不是完
全相同，因此需对二者进行修改。
目标：尽可能使复用成分增多，新开发的成分减少
不同程度的复用
当
前
所
需
的
类
的
信
息
比
可
复
用
类
定
义
的
信
息
＝ 直接复用
＜ 通过继承复用
＞ 删除可复用类的多余信息
≈ 删除多余信息，通过继承而复用
对第四种情况的做法：
把要复用的类加到 PDC，
标以,OTS” 记号，或者中文“复用”
划掉（或标出）不用的属性与服务
建立从复用类到 PDC原有的类之间的一般 -特殊关系
由于 PDC的类继承了 OTS类的特征，
所以有些属性和服务不需要了 —— 划掉。
修改 PDC原有类的结构和连接，必要时移到 OTS类
例：
车辆
序号
颜色
式样
出厂年月
序号认证
PDC的类
（ OTS）车辆
序号
厂商
式样
序号认证
可复用的类
（ 2）增加一般类以建立共同协议
增加根类,将所有的类组织在一起
提供全系统通用的协议
例：提供创建、删除、复制等服务
增加其他一般类,提供局部通用的协议
例：提供永久存储及恢复功能
Object
(复用 )
B C E
A
属性
服务
D F
1,m
1
属性
服务
属性
服务
属性
服务
属性
服务
属性
服务
例：
（ 3）按编程语言调整继承
起因,OOA强调如实地反映问题域,OOD考虑实现问题
，
所用语言不支持多继承，甚至不支持继承
多继承模式
狭义菱形 广义菱形
方法 1：采用整体部分结构
公司人员
顾主 职员
顾主职员
公司人员
身份
顾主身份 职员身份
1,2
1
问题：道理何在？
方法 2：采用实例连接
公司人员
顾主 职员
顾主职员
公司人员
身份
顾主身份 职员身份
1,2
1
问题：与方法 1有何区别？
方法 3：压平
公司人员
顾主 职员顾主职员
问题：有什么缺点？
（ 4）提高性能
*增加属性
*合并通讯频繁的类
流速调节器
指定流速
……
流速调节
… …
流速探测器
当前流速
……
流速探测
取当前流速
… …
流速控制器
指定流速
当前流速
……
流速调节
流速探测
… …
合并前 合并后
*增加低层成分
帧
显示
背景 前景
1 1
0,m 0,1
显示显示
（ 5）为数据存储管理增补属性与服务
在数据接口部分设计中介绍
（ 6）为编程方便增加底层成分
—— 细化对象的分类
例：将几何图形分成
多边形、椭圆、扇形
等特殊类 几何图形
多边形 扇形椭圆
一、什么是人机交互部分
系统中负责人机交互的部分（由一些对象类构成）
OOA和 OOD都要考虑人机交互，但目的不同
OOA：通过人机界面反映需求（原型开发）
OOD：设计人机交互的细节
人机交互部分既取决于需求，又与 GUI密切相关
HIC的设计可以与 OOA同时进行，但要互相分离
—— 为了隔离实现条件的影响
第四章 人机交互部分（ HIC）的设计
二、为什么需要人机交互部分
为了隔离 GUI的变化对问题域部分的影响
人机界面是系统中一个比较独立的部分
集中表现：
人如何向系统下达命令
系统如何向人提交信息
三、如何设计人机交互部分
研究使用系统的人
设计人机交互命令
用对象表示界面成分
1、研究使用系统的人，建立任务脚本
类别、身份、水平 …...
目的、任务、习惯、感情、关键性要求 ……
任务脚本
—— 描述用户如何通过与系统交互而进行工作
2、设计人机交互命令
（ 1）学习、研究广泛流行的人机界面，
熟悉大家习惯的命令方式及界面风格
例：
Windows
Motif
VB,VC,Delphi
Web
…...
（ 2）设计高层命令
什么是高层命令（以 Turbo C为例）？
A）对应着系统的一项大的功能（或操作步骤）的命令
例,Edit,Compiler,Run
B）当命令分为多个层次时，位于最上层的命令
例,Edit,Debug
C）若干功能接近的小命令的总称
例,File,Options
做法：
* 从需求出发发现各种命令 —— 考察活动者和 use case
* 从对象（特别是主动对象）的服务出发发现各种命令
* 符合 A,B条件的作为高层命令
* 剩下的按 C的原则进行组合 —— 如果太多，再组合
方式：
主菜单条，图符，菜单屏面
关键问题：
* 适当的命名 ——
反映命令提供的功能，符合流行的习惯
* 合理的顺序
按用户工作顺序，按使用频繁度，按功能类似性
* 适当的宽度与深度
深度不超过 3，宽度不超过 7± 2
（ 3）设计细化的命令
按任务脚本，将每一条高层命令细化为一系列满
足用户交互要求的底层命令
评价准则
* 一致性 —— 术语、风格、步骤、活动的一致
* 减少操作步骤，包括减少键盘及鼠标操作
* 容错性
* 减少人脑记忆
至理名言,界面设计是给机器编程，不是给人编程！
*减少重复输入
* 及时反馈
* 趣味性、外观与感受
……
（ 4）设计详细的交互
（ 5）设计 HIC的类
—— 用面向对象的概念与表示法表达所有的界面成分
1）以窗口作为基本的 类
2）以窗口的部件作为窗口的部分对象类，
与窗口类形成 整体 -部分结构
例：菜单，工作区，对话框 ……
3）发现窗口与部件的共性，定义较一般的窗口类和
部件类，形成 一般 -特殊结构
4）用 属性 表示窗口或部件的静态特征
如：尺寸、位置、颜色、选项等
5）用 服务 表示窗口或部件的动态特征
如：选中、移动、滚屏等
6）建立与系统内部其它对象之间的 消息连接
界面对象服务往往要请求系统内部其它对象的服务
一、什么是任务管理部分
任务（ task） —— 进程（ process）的别称
有多个任务（进程）并发执行的系统
称作 多任务系统 或 并发系统
任务管理部分 ——
是 OOD模型的组成部分之一，用来定义和表
示并发系统中的每个任务。
用主动对象表示每个任务
所有的主动对象类构成任务管理部分
第五章 任务管理部分（ DMC）的设计
二、为什么需要任务管理部分
并发行为是现实中固有的
当前大量的系统都是并发系统（多任务系统），例如：
设备与计算机并发工作的系统
有多个窗口进行人机交互的系统
多用户系统
多个子系统并发工作的系统
单处理机上的多任务系统
多处理机系统
……
多任务的设置
描述问题域固有的并发行为
表达实现所需的设计决策
为了隔离硬件、操作系统、网络的变化对整个系统的影
响
1） OOA定义的主动对象
主动对象类的每个对象事例都是一个任务
2）系统的并发需求所要求的多任务
要求多项工作同时进行，
则每一项工作就是一个任务
3）系统分布方案所要求的多任务
每一个分布站点至少有一个任务（主动对象）
4）为提高性能而增设的任务
高优先任务，低优先任务，关键任务
5）为实现方便设立的任务
例：负责处理机之间通讯的任务
6）为协调多任务的执行设立的任务
三、如何设计 TMC
1、识别每个任务
C/Y方法
着眼于：
事件驱动
的任务
时钟驱动
的任务
优先任务
关键任务
协调者任
务
2、审查与筛选
去掉不必要的任务
多余的并发性意味着执行效率的损
失
每个任务应该有以上列举的理由
之一
不要人为地增加任务
3、任务的表示与分类
用主动对象表示每个任务
用主动对象类描述每一类任务
用主动对象的主动服务描述任务的功能
原有的主动对象
原有的普通对象标为主动对象
新定义的主动对象
@类名
属性
……
@服务
……
数据管理部分是 OOD模型中负责在特定的数据管理系
统中存储和检索对象的组成部分。
问题范围：
对象在永久性存储介质上的存储
只存储对象的属性部分
可能只有一部分对象需要长久存储
第六章 数据管理部分（ TMC）的设计
一、什么是数据管理部分
不同的数据管理系统：
文件系统,R-DBMS,OO-DBMS
—— 对数据管理部分的设计有不同的影响
为了隔离数据管理系统对其它部分的影响
使选用不同的数据管理系统时，问题域部分基本相同
二、为什么需要数据管理部分
三、如何设计数据管理部分
1、选择数据管理系统
文件系统,R-DBMS,OO-DBMS
（以下仅针对 R-DBMS）
2、数据存放设计
—— 每个类使用一个数据库表
1）列出每个类的所有属性（包括继承来的属性）
2）规范化 —— 一般按第三范式，按时间与空间权衡
3）定义数据库的表
列：规范化之后的一个属性
行：一个对象实例
3、设计数据管理部分的类
并修改问题域部分
—— 两种方案
方案 1：
问题域部分：每个类的对象自己存储自己
数据管理部分：设立一个对象，提供两个服务 ——
（ 1）通知问题域部分的对象自己存储自己
（ 2）检索被存储的对象
为了存储自己，对象要知道什么？
本类对象的属性数据结构
本类对象对应哪个数据库表
对象实例对应数据库表的哪一行
方案 2：
数据管理部分设立一个对象，负责问题域部分所有
对象的存储与检索
问题域部分的对象通过消息使用数据管理部分对象
的服务
为了存储各个类的对象,DMC的对象要知道什么？
每个要求存储、检索的类的属性数据结构
每个要求存储、检索的类的对象存放在哪个数据库表
当前要求存储或检索的对象属于哪个类，对应数据库
表的哪一行
关于面向对象的数据库管理系统（ OO-DBMS）
三种做法：
在 R-DBMS之上增加 OO功能
对 OOPL增加永久对象功能
全新的设计
对照 E-R模型的存储，理解对象存储
对象的属性部分相当于 E-R模型中的一个实体
当使用 OO-DBMS时，不需要上述工作
一, 给出下列概念的定义, 并说明它们在软件开发中的作用：
(1)对象 (2)类 (3)属性 (4)服务 (5)继承
(6)封装 (7) 关联 (8)聚合 (9) 消息 (10)抽象
二, 介绍面向对象方法的主要思想, 论述该方法为什么有利
于改进软件开发 。
三, 以你所学习的 OOA方法为背景, 阐述 OOA的主要过程与
策略 。
第三部分
面向对象的设计
概而言之，面向对象的设计（ OOD）就是运用面向对
象方法进行系统设计；但不同时期有不同内容及特点。
第一章 什么是面向对象的设计（ OOD）？
一、早期的 OOD（八十年代至九十年代初）：
历史：从 OOP发展到 OOD
G,Booch 1982 年发表, Object-Oriented Design”,
首次称, 面向对象的设计, 。
1986 年发表, Object-Oriented Development”
较完整地阐述了 OOD思想。
两个术语都用 OOD作为缩写，内容上也没有根本区别
R,J,Abbott 1983年提出正文分析方法，用规范的英语描述对一个问
题的解释，然后从描述中提取对象及其特征。 例：名词 —— 对象，动词
—— 操作。 被后来的许多 OOD方法所采用。
1986年后,相继出现了一批（早期的） OOD方法
早期的 OOD方法
Booch86—— Object-Oriented Development
面向对象的开发
GOOD—— General Object-Oriented Development
通用面向对象的开发
HOOD—— Hierarchical Object-Oriented Design
层次式面向对象的设计
OOSD—— Object-Oriented Structured Design
面向对象的结构设计
……
1、不是基于 OOA的
大多基于结构化分析结果（数据流图）
2、是 OO编程方法的延伸
多数方法与编程语言有关，特别受 Ada影响很大
3、不是纯 OO的
对某些 OO概念（如继承）缺少支持，
搀杂一些非 OO 概念（如数据流、包、模块等）
4、不是只针对软件生命周期的设计阶段
OOD中的,D” —— 指的是 Design 或 Development
多少涉及分析问题（如识别问题域的对象），但很不彻底
—— 早期的 OOD可看作现今 OOA&D方法的雏形
早期 OOD的特点：
二、现今（ 90年代）的 OOD
背景：
从结构化分析文档识别 OOD的对象并非良策，识别对象
的关键问题在于用 OO方法进行系统分析。
OO方法从设计发展到分析，出现 OOA方法。
OOA和 OOD构成完整的 OOA&D方法体系。
OOD基于 OOA，
识别对象由 OOA完成，
OOD的主要定义对象如何实现。
定义：
面向对象的设计（ OOD）就在是 OOA模型基础上运用
面向对象方法进行系统设计，目标是产生一个符合具
体实现条件的 OOD模型。
特点：
1,以面向对象的分析为基础, 一般不依赖结构化分析 。
2,与相应的 OOA方法共同构成一种 OOA&D方法体系 。 OOA
和 OOD采用一致的概念与原则, 但属于软件生命周期的
不同阶段, 有不同的目标及策略 。
3,较全面地体现面向对象方法的概念与原则 。
4,大多数方法独立于编程语言, 通过面向对象的分析
与设计所得到的系统模型可以由不同的编程语言实现 。
有多种 OOA&D方法,
Booch方法
Coad-Yourdon方法
Firesmith方法
Jacobson方法 (OOSE)
Martin-Odell方法
Rumbaugh方法 (OMT)
Wirfs-Brock方法
……
本课重点讲授
Coad/Yourdon
方法，加以适
当改进
Coad/Yourdon方法：
概念,对象、类、属性、服务、整体 -部分结构、一般 -特殊
结构、实例连接、消息连接、主题。
原则,抽象、封装、继承、关联、消息通讯、通用的组织方
法、粒度控制、行为分类。
识别类及对象
识别结构
识别主题
定义属性
定义服务
OOA过程
—— 五个活动
对象层
结构层
主题层
属性层
服务层
OOA模型
—— 五个层次
人机交互
部分
（ HIC）
问题域
部分
（ PDC）
任务管理
部分
（ TMC）
数据管理
部分
（ DMC）
对象层
结构层
主题层
属性层
服务层
OOD模型
—— 五个层次，四个部分
OOD过程 针对四个部分，进行四个相应的活动
设计问题域部分
设计人机交互部分的
设计任务管理部分
设计数据管理部分
上述每个活动都包含与 OOA相同的五个活动 ——
识别类及对象、识别结构、识别主题、定义属性、定义服务。
1、提高软件生产率
开发阶段：提高 20%，维护阶段提高更多。原因：
设计的投入在编程、测试时得到回报
OO方法使系统更易于理解
分析文档、设计文档、源程序对应良好
功能变化引起的全局性修改较少
OOD结果的复用
2、提高质量
现今的质量观点：
不仅是事后通过测试排除错误，而是着眼与软
件开发过程的每个环节，从分析、设计阶段开
始质量保证。
高质量不只是没有错误，而是好用、易用、可
移植、易维护，用户由衷地满意。
三,OOD的根本目标：
3、加强可维护性
需求是不断变化的（尽管可阶段性地“冻结”）
因素：客户业务、竞争形式、技术发展、规章制度 ……
—— 要求设计结果对变化有弹性
设计如何适应不可预见的变化？
—— 把易变部分和较稳定的部分隔离，
将变化的影响限制在局部
易变性：服务 >接口 >属性 >类
1,OOA与 OOD的分工
—— 两种不同的观点
做
什
么
怎
么
做
问题域与
系统责任
与实现有
关的因素
分
析
设
计
第
一
种
观
点
分 析 设 计
第二种观点
第二种观点的理由：
（ 1）在各种分析 /设计方法中
“做什么”和“怎么做”实际上
没有严格的划分”。
（ 2）过分强调, 分析不考虑怎
么做, 将使某些必须在 OOA考虑
的问题得不到完整的认识。
（ 3）由于 OO方法表示形式的一
致，不存在把细化工作留给设计
人员的必然理由。
（ 4）避免重复地认识同一事物，
并有利于分析结果的复用。
关键问题：对象的特征细节（如属
性的数据类型和服务流程图），是
在分析时定义还是在设计时定义？
例,Rumbaugh方法 (OMT)
和 Coad/ Yourdon方
法
四,O OA与 OOD的关系
2、一致的概念与表示法
前端 —— OOA 可以全部用 OO概念建模；
后端 —— OOP 可以全部用 OOPL支持的 OO概念编程。
OOD是承前启后中间环节
—— 使用与 OOA和 OOP一致的概念建立完整的、可实现的设计
模型。
3、不同的目标、内容和抽象层次
内容与目标：
OOA—— 主要 内容 是研究问题域和用户需求，运用面向对
象的观点和原则发现问题域中与系统责任有关的对象，以
及对象的特征和相互关系。 目标 是建立一个直接映射问题
域，符合用户需求的 OOA模型。
OOD—— 主要 内容 是以 OOA模型为基础，按照实现的要求进
行设计决策，包括全局性的决策和局部细节的设计。 目标
是产生一个满足用户需求，并且完全可实现的 OOD模型。
全局性设计决策,体系结构、分布方案、并发控制、人机
交互、数据管理等。 OOD方法应支持用户以 OO概念表达对
这些问题的设计。
局部细节的设计,对每个对象类的每个属性和每个服务给
出详细的定义 。
抽象层次：
OOA模型,OOD模型、源程序 都是对现实世界的抽象
—— 忽略了与系统责任无关的事物及特征。
三者又都是对计算机概念的抽象：
源程序忽略了与计算机硬件有关的细节，
OOD模型忽略了源程序的许多细节，
OOA模型进一步忽略了与实现条件有关的设计决策。
从对计算机概念的抽象而言,OOD模型的抽象级别低于
OOA模型而高于源程序。
概念,运用与 OOA部分相同的概
念 —— 没有增加新概念
对象、类、属性、服务 (操作 )、
封装、继承、消息、关联、聚合、
多态、主动对象 等
表示法,采用与 OOA一致的表示法
分析 设计
数据流图
（ DFD）
模块结构图 （ MSD）
实体 -关系图（ ERD）
传统方法分析与设
计之间的鸿沟
使分析
与设计
之间不
存在鸿
沟
OOA OOD
一致的
概念
一致的
表示法
类
图
类
图
面向对象的分析与设计
之间不存在鸿沟
第二章 OOD方法概貌
基本按 Coad/Yourdon方法讲授，做适当的改进和补充
新增的组成部分，隔
离实现条件
OOD—— 按实现条件对 OOA模型进行调整，并补充几
个新的组成部分（也是由对象构成）
与实现有关的因素：
图形用户界面系统
硬件、操作系统及网络
数据管理系统
其他 —— 编程语言、可复用构件库 ……
按实现条件调整
OOA模型
实现条件
实
现
条
件
基本思想：
尽可能隔离实现
条件对系统的影
响 —— 提供独立
的接口
对不可隔离的因
素，按实现条件
调整 OOA模型
实
现
条
件
OOD模型
—— 从两个侧面来描述
人
机
交
互
部
分
数
据
接
口
部
分
控制接口部分
问题域
部分
从一个侧面观察
OOD模型包括几个主要部分
—— 一个核心部分加几个外围部分
交
互
图 主
题
图
类
图
详
细
说
明
从另一侧面观察
OOD模型每个部分
如何用 OO概念表达
—— 采用 OOA的概念及
模型组织方式
OOA与 OOD的关系：
1、从 OOA到 OOD不是转换，不是细化；
—— 是调整和增补
问题域
部分
OOA
模型
将 OOA模型搬到 OOD；
进行必要的调整，
作为 OOD模型的问题域
部分；
人
机
交
互
部
分
数
据
接
口
部
分
控制接口部分
增补其它三个部分，成
为完整的 OOD模型。
2、采用一致的概念和表示法
—— 不存在分析与设计之间的鸿沟
3、有不同的侧重点和不同的策略
OOA主要针对问题域，识别有关的对象以及它们之
间的关系，产生一个映射问题域，满足用户需求，独立
于实现的 OOA模型。
OOD主要解决与实现有关的问题，基于 OOA模型，
针对具体的软、硬件条件（如机器、网络,OS,GUI、
DBMS等）产生一个可实现的 OOD模型。
4,OOA与 OOD可适合不同的生命周期模型
—— 瀑布模型、螺旋模型、增量模型、喷泉模型
OOA与 OOD之间可以顺序进行，也可交叉进行
OOD过程：
逐个设计 OOD模型的四个部分
问题域部分的设计
人机交互部分的设计
控制接口部分的设计
数据接口部分的设计
不强调次序
每个部分均采用与 OOA一致的 概念, 表示法 及 活动,
但具有自己独特的策略。
一、什么是问题域部分？
对 OOA结果按实现条件进行补充与调整就是问题域部分。
不是传统方法的“转换”，不存在鸿沟。
主要不是细化，但 OOA未完成的细节定义要在 OOD完成。
是对 OOA模型的补充与调整
第三章 问题域部分（ PDC）的设计
二、为什么需要问题域部分的设计？
在 OOA阶段只考虑问题域和系统责任,OOD则要考虑与具
体实现有关的问题，需要对 OOA结果的补充与调整；
使反映问题域本质的总体框架和组织结构长期稳定，而
细节可变；
稳定部分（ PDC）与可变部分（其它部分）分开，使系统
从容地适应变化；
有利于同一个分析用于不同的设计与实现；
支持系统族和相似系统的分析设计及编程结果复用；
使一个成功的系统具有超出其生存期的可扩展性。
三、如何进行问题域部分的设计？
1、继续运用 OOA的方法
—— 概念、表示法及一部分策略
2、使用 OOA结果，并加以修改
—— 需求的变化，新发现的错误
3、使用 OOA结果，并进行补充与调整（本节的重点）
（ 1）为复用设计与编程的类而增加结构
（ 2）增加一般类以建立共同协议
（ 3）按编程语言调整继承
（ 4）提高性能
（ 5）为数据存储管理增补属性与服务
（ 6）为编程方便增加底层成分
（ 1）为复用设计与编程的类而增加结构
OOA识别和定义的类是本次开发中新定义的，需要进行
编程。
如果已存在一些可复用的类，而且这些类既有分析、设
计时的定义，又有源程序，那么，复用这些类即可提高
开发效率与质量。
可复用的类可能只是与 OOA模型中的类相似，而不是完
全相同，因此需对二者进行修改。
目标：尽可能使复用成分增多，新开发的成分减少
不同程度的复用
当
前
所
需
的
类
的
信
息
比
可
复
用
类
定
义
的
信
息
＝ 直接复用
＜ 通过继承复用
＞ 删除可复用类的多余信息
≈ 删除多余信息，通过继承而复用
对第四种情况的做法：
把要复用的类加到 PDC，
标以,OTS” 记号，或者中文“复用”
划掉（或标出）不用的属性与服务
建立从复用类到 PDC原有的类之间的一般 -特殊关系
由于 PDC的类继承了 OTS类的特征，
所以有些属性和服务不需要了 —— 划掉。
修改 PDC原有类的结构和连接，必要时移到 OTS类
例：
车辆
序号
颜色
式样
出厂年月
序号认证
PDC的类
（ OTS）车辆
序号
厂商
式样
序号认证
可复用的类
（ 2）增加一般类以建立共同协议
增加根类,将所有的类组织在一起
提供全系统通用的协议
例：提供创建、删除、复制等服务
增加其他一般类,提供局部通用的协议
例：提供永久存储及恢复功能
Object
(复用 )
B C E
A
属性
服务
D F
1,m
1
属性
服务
属性
服务
属性
服务
属性
服务
属性
服务
例：
（ 3）按编程语言调整继承
起因,OOA强调如实地反映问题域,OOD考虑实现问题
，
所用语言不支持多继承，甚至不支持继承
多继承模式
狭义菱形 广义菱形
方法 1：采用整体部分结构
公司人员
顾主 职员
顾主职员
公司人员
身份
顾主身份 职员身份
1,2
1
问题：道理何在？
方法 2：采用实例连接
公司人员
顾主 职员
顾主职员
公司人员
身份
顾主身份 职员身份
1,2
1
问题：与方法 1有何区别？
方法 3：压平
公司人员
顾主 职员顾主职员
问题：有什么缺点？
（ 4）提高性能
*增加属性
*合并通讯频繁的类
流速调节器
指定流速
……
流速调节
… …
流速探测器
当前流速
……
流速探测
取当前流速
… …
流速控制器
指定流速
当前流速
……
流速调节
流速探测
… …
合并前 合并后
*增加低层成分
帧
显示
背景 前景
1 1
0,m 0,1
显示显示
（ 5）为数据存储管理增补属性与服务
在数据接口部分设计中介绍
（ 6）为编程方便增加底层成分
—— 细化对象的分类
例：将几何图形分成
多边形、椭圆、扇形
等特殊类 几何图形
多边形 扇形椭圆
一、什么是人机交互部分
系统中负责人机交互的部分（由一些对象类构成）
OOA和 OOD都要考虑人机交互，但目的不同
OOA：通过人机界面反映需求（原型开发）
OOD：设计人机交互的细节
人机交互部分既取决于需求，又与 GUI密切相关
HIC的设计可以与 OOA同时进行，但要互相分离
—— 为了隔离实现条件的影响
第四章 人机交互部分（ HIC）的设计
二、为什么需要人机交互部分
为了隔离 GUI的变化对问题域部分的影响
人机界面是系统中一个比较独立的部分
集中表现：
人如何向系统下达命令
系统如何向人提交信息
三、如何设计人机交互部分
研究使用系统的人
设计人机交互命令
用对象表示界面成分
1、研究使用系统的人，建立任务脚本
类别、身份、水平 …...
目的、任务、习惯、感情、关键性要求 ……
任务脚本
—— 描述用户如何通过与系统交互而进行工作
2、设计人机交互命令
（ 1）学习、研究广泛流行的人机界面，
熟悉大家习惯的命令方式及界面风格
例：
Windows
Motif
VB,VC,Delphi
Web
…...
（ 2）设计高层命令
什么是高层命令（以 Turbo C为例）？
A）对应着系统的一项大的功能（或操作步骤）的命令
例,Edit,Compiler,Run
B）当命令分为多个层次时，位于最上层的命令
例,Edit,Debug
C）若干功能接近的小命令的总称
例,File,Options
做法：
* 从需求出发发现各种命令 —— 考察活动者和 use case
* 从对象（特别是主动对象）的服务出发发现各种命令
* 符合 A,B条件的作为高层命令
* 剩下的按 C的原则进行组合 —— 如果太多，再组合
方式：
主菜单条，图符，菜单屏面
关键问题：
* 适当的命名 ——
反映命令提供的功能，符合流行的习惯
* 合理的顺序
按用户工作顺序，按使用频繁度，按功能类似性
* 适当的宽度与深度
深度不超过 3，宽度不超过 7± 2
（ 3）设计细化的命令
按任务脚本，将每一条高层命令细化为一系列满
足用户交互要求的底层命令
评价准则
* 一致性 —— 术语、风格、步骤、活动的一致
* 减少操作步骤，包括减少键盘及鼠标操作
* 容错性
* 减少人脑记忆
至理名言,界面设计是给机器编程，不是给人编程！
*减少重复输入
* 及时反馈
* 趣味性、外观与感受
……
（ 4）设计详细的交互
（ 5）设计 HIC的类
—— 用面向对象的概念与表示法表达所有的界面成分
1）以窗口作为基本的 类
2）以窗口的部件作为窗口的部分对象类，
与窗口类形成 整体 -部分结构
例：菜单，工作区，对话框 ……
3）发现窗口与部件的共性，定义较一般的窗口类和
部件类，形成 一般 -特殊结构
4）用 属性 表示窗口或部件的静态特征
如：尺寸、位置、颜色、选项等
5）用 服务 表示窗口或部件的动态特征
如：选中、移动、滚屏等
6）建立与系统内部其它对象之间的 消息连接
界面对象服务往往要请求系统内部其它对象的服务
一、什么是任务管理部分
任务（ task） —— 进程（ process）的别称
有多个任务（进程）并发执行的系统
称作 多任务系统 或 并发系统
任务管理部分 ——
是 OOD模型的组成部分之一，用来定义和表
示并发系统中的每个任务。
用主动对象表示每个任务
所有的主动对象类构成任务管理部分
第五章 任务管理部分（ DMC）的设计
二、为什么需要任务管理部分
并发行为是现实中固有的
当前大量的系统都是并发系统（多任务系统），例如：
设备与计算机并发工作的系统
有多个窗口进行人机交互的系统
多用户系统
多个子系统并发工作的系统
单处理机上的多任务系统
多处理机系统
……
多任务的设置
描述问题域固有的并发行为
表达实现所需的设计决策
为了隔离硬件、操作系统、网络的变化对整个系统的影
响
1） OOA定义的主动对象
主动对象类的每个对象事例都是一个任务
2）系统的并发需求所要求的多任务
要求多项工作同时进行，
则每一项工作就是一个任务
3）系统分布方案所要求的多任务
每一个分布站点至少有一个任务（主动对象）
4）为提高性能而增设的任务
高优先任务，低优先任务，关键任务
5）为实现方便设立的任务
例：负责处理机之间通讯的任务
6）为协调多任务的执行设立的任务
三、如何设计 TMC
1、识别每个任务
C/Y方法
着眼于：
事件驱动
的任务
时钟驱动
的任务
优先任务
关键任务
协调者任
务
2、审查与筛选
去掉不必要的任务
多余的并发性意味着执行效率的损
失
每个任务应该有以上列举的理由
之一
不要人为地增加任务
3、任务的表示与分类
用主动对象表示每个任务
用主动对象类描述每一类任务
用主动对象的主动服务描述任务的功能
原有的主动对象
原有的普通对象标为主动对象
新定义的主动对象
@类名
属性
……
@服务
……
数据管理部分是 OOD模型中负责在特定的数据管理系
统中存储和检索对象的组成部分。
问题范围：
对象在永久性存储介质上的存储
只存储对象的属性部分
可能只有一部分对象需要长久存储
第六章 数据管理部分（ TMC）的设计
一、什么是数据管理部分
不同的数据管理系统：
文件系统,R-DBMS,OO-DBMS
—— 对数据管理部分的设计有不同的影响
为了隔离数据管理系统对其它部分的影响
使选用不同的数据管理系统时，问题域部分基本相同
二、为什么需要数据管理部分
三、如何设计数据管理部分
1、选择数据管理系统
文件系统,R-DBMS,OO-DBMS
（以下仅针对 R-DBMS）
2、数据存放设计
—— 每个类使用一个数据库表
1）列出每个类的所有属性（包括继承来的属性）
2）规范化 —— 一般按第三范式，按时间与空间权衡
3）定义数据库的表
列：规范化之后的一个属性
行：一个对象实例
3、设计数据管理部分的类
并修改问题域部分
—— 两种方案
方案 1：
问题域部分：每个类的对象自己存储自己
数据管理部分：设立一个对象，提供两个服务 ——
（ 1）通知问题域部分的对象自己存储自己
（ 2）检索被存储的对象
为了存储自己，对象要知道什么？
本类对象的属性数据结构
本类对象对应哪个数据库表
对象实例对应数据库表的哪一行
方案 2：
数据管理部分设立一个对象，负责问题域部分所有
对象的存储与检索
问题域部分的对象通过消息使用数据管理部分对象
的服务
为了存储各个类的对象,DMC的对象要知道什么？
每个要求存储、检索的类的属性数据结构
每个要求存储、检索的类的对象存放在哪个数据库表
当前要求存储或检索的对象属于哪个类，对应数据库
表的哪一行
关于面向对象的数据库管理系统（ OO-DBMS）
三种做法：
在 R-DBMS之上增加 OO功能
对 OOPL增加永久对象功能
全新的设计
对照 E-R模型的存储，理解对象存储
对象的属性部分相当于 E-R模型中的一个实体
当使用 OO-DBMS时，不需要上述工作
