第十一章 OOD
? OOD的准则
? 启发式规则
? 软件重用
? 系统分解
? 设计问题域子系统
? 设计人 —机交互子系统
? 设计任务管理子系统
? 设计数据管理子系统
? 设计类中的服务
? 设计关联
? 设计优化
OOD的准则
? 模块化
? 抽象
? 信息隐蔽
? 弱耦合
– 交互耦合
– 继承耦合
? 强内聚
– 服务内聚
– 类内聚
– 一般 —特殊内聚
? 可重用
启发式规则
? 设计结果应该清晰易懂
– 用词一致
– 使用已有的协议
– 减少消息模式的数目
– 避免模糊的定义
? 深度适当
? 设计简单的类
– 避免包含过多的属性
– 有明确的类定义
– 尽量简化对象之间的合作关系
– 不要提供太多服务
? 使用简单的协议
? 把设计变动最小化
软件重用
? 重用的三个层次
– 知识重用
– 方法和标准的重用
– 软件成分的重用
? 软件成分重用的三个级别
– 代码重用
? 源代码剪贴
? 源代码包含
? 继承
– 设计结果重用
– 分析结果重用
软件重用的效果
? 实现重用的代价
– 创建构件库的代价
– 保证可重用构件质量的代价
– 更新和维护构件库的代价
? 重用率与生产率的关系
软件重用技术
? 三种重用技术
– 软件组合技术
– 软件生成技术
– OO软件重用技术
? 可重用构件应具备的特点
– 模块独立性强
– 具有高度可塑性
– 接口清晰、简明、可靠
? 类构件的重用方式
– 实例重用
– 继承重用
– 多态重用
系统分解
? 设计模型的五个层次
– 主题
– 类和对象
– 结构
– 属性
– 服务
? 多数软件系统由四个子系统组成
– 问题域子系统
– 人机交互子系统
– 任务管理子系统
– 数据管理子系统
系统分解（续）
? 子系统之间的交互方式
– 客户 ——供应商关系 (Client —Supplier)
– 平等伙伴关系（ peer to peer)
? 组织系统的两种方案
– 层次组织
? 开放式
? 封闭式
– 块状组织
– 混合组织
? 设计系统的拓扑结构
– 管道形
– 树形
– 星形
设计问题域子系统
? OOD和 OOA的区别
– OOA从描述问题域的角度 建立 三视点模型
– OOD从实现的角度 补充, 修改 三视点模型
– 从 OOA到 OOD能够保持问题域组织框架的稳定性
? 主要任务
– 调整需求（两个方面）
– 重用已有的类（ P244描述了重用的四个典型过程）
– 引入根类以组合问题域的类
– 为类的公共协议定义一组相似的服务而增添附加类
– 调整继承层次
设计问题域子系统（续）
? 调整继承层次所注意的问题
– 使用多继承机制时，避免属性和服务命名的冲突
两种多重继承模式
? 窄菱形模式（图 11.4）
? 阔菱形模式（图 11.5）
– 将多重继承转换为单继承机制
? 利用组合关系分解多重继承（图 11.6）
? 利用归纳关系简化多重继承
– 尽量选用具有继承机制的语言
? ATM系统的问题域子系统的结构（ P247）
设计人 —机交互子系统
? 设计人 —机交互界面的准则
– 一致性（术语、步骤、动作）
– 减少步骤
– 及时提供反馈信息
– 提供撤消命令
– 无须记忆
– 易学
– 富有吸引力
? 设计人 —机交互子系统的策略
– 分类用户
? 按照技能水平分类
? 按照职务分类
? 按照所属集团分类
– 描述用户
? 用户类型
? 使用系统欲达到的目的
? 特征（年龄、性别、文化程度、限制因素等）
? 关键的成功因素（需求、爱好、习惯等）
? 技能水平
? 完成本职工作的脚本
– 设计命令层次（可供选用的服务的表示形式）
? 研究现有的人机交互的含义和准则（ Windows)
? 确定初始的命令层次
? 精化命令层次 (次序、整体与部分关系、宽度和深度、操作方式）
– 设计人机交互类
设计任务管理子系统
? 分析并发性
– 依据：动态模型
– 并发性：如果两个对象彼此之间不存在交互，
或同时接受事件，则这两个对象在本质上是
并发的。
– 控制线：一条遍及状态图集合的路径，在这
条路径上每次只有一个对象是活动的。能够
把若干个非并发的对象归并到一条控制线上。
– 多任务：多个任务并发执行
设计任务管理子系统（续）
? 确定任务类型并把任务分配给适当的单元
– 事件驱动型任务
– 时钟驱动型任务
– 优先任务
– 关键任务
– 协调任务
? 尽量减少任务数量
? 确定资源需求
设计数据管理子系统
? 选择数据存储管理模式
– 文件管理系统
– 关系数据库管理系统 (DBMS)
– OO数据管理系统 (ODBMS)
? 设计数据格式
? 设计相应的服务
三种数据存储管理模式的比较
? 文件管理系统
– 属于 OS，文件操作级别低，对于高级操作须额外的代
码
– 通用性差
? 关系数据库管理系统 (DBMS)
– 提供各种最基本的数据管理功能（共享、事务支持等）
– 为多种应用提供一致的接口
– 标准化语言（ SQL）
– 运行开销大
– 难于应付数据类型丰富或操作不标准的应用
– 与程序设计语言连接不自然,SQL语言支持面向集合的
操作
三种数据存储管理模式的比较（续）
? OO数据管理系统 (ODBMS)
– 扩展 DBMS
? 增加抽象数据类型、继承机制；
? 增加了创建管理类对象的通用服务
– 扩展 OO语言
? 扩充 OO语言的语法和功能，增加在数据库中存储和
管理对象的机制
? 准确存储对象，而不是仅仅存储对象值 ——―永久对
象”方法
设计数据格式
? 文件系统
– 定义第一范式表：列出类的属性表并规范成第一范式
– 为每个第一范式表定义一个文件
– 测量性能和需要的存储容量
– 修改原设计的第一范式，以满足性能和存储需求
? DBMS
– 定义第三范式表：列出类的属性表并规范成第三范式
– 为每个第三范式表定义一个数据库表
– 测量性能和需要的存储容量
– 修改原设计的第三范式，以满足性能和存储需求
? ODBMS
– 扩展 DBMS途径：同上
– 扩展 OO语言途径,ODMS本身具有把对象映射成存储值
的功能，故不需要规范属性的步骤。
设计相应数据管理的服务
? 文件系统
– 被存储的对象需要知道打开哪些文件
– 怎样把文件定位到正确的记录上
– 怎样检索、更新
– 定义一个“对象服务器”类，并创建它的实例
? 通知对象保存自己
? 检索已存储的对象，以便将这些对象提供给其它子系统使用
? DBMS
– 被存储的对象需要知道打开哪些数据库表
– 怎样把文件定位到正确的行上
– 怎样检索、更新
– 定义一个“对象服务器”类，并声明它的对象，以提供以下服务
? 通知对象保存自己
? 检索已存储的对象，以便将这些对象提供给其它子系统使用
? ODBMS
– 扩展 DBMS途径：同上
– 扩展 OO语言途径,ODMS已经给每个对象提供了“保存自己”的
功能，故不需要增加服务。但要给需长期保存的对象加上标记，由 ODBMS负责存储和恢复这类对象。
OOD—设计类中的服务
? 确定类中应有的服务
– 在不同状态下接受同一事件所采取的行为不
同，实现服务的算法需要一个依赖于状态的
DO_CASE型控制结构
– 确定操作的目标对象（ P256）
– 确定处理的归属（ P256）
? 设计实现服务的方法
– 设计实现服务的算法
– 选择数据结构
– 定义内部类和内部操作
OOD—设计关联
? 关联的遍历
– 单向遍历
– 双向遍历
? 实现单向关联
– 用指针实现单向关联（图 11.11)
? 实现双向关联
– 只用属性实现一个方向的关联
– 两个方向的关联都用属性实现（图 11.12)
– 用独立的关联对象实现双向关联（图 11.13）
? 链属性的实现
– 1, 1
– 1, N
– N, M
OOD—设计优化
? 确定质量指标的优先级
? 提高效率的技术（ P259）
– 增加冗余关联以提高访问效率
– 调整查询次序
– 保留派生属性
? 调整继承关系
– 抽象与具体
– 为提高继承程度而修改类定义
– 利用委托实现行为共享
? OOD的准则
? 启发式规则
? 软件重用
? 系统分解
? 设计问题域子系统
? 设计人 —机交互子系统
? 设计任务管理子系统
? 设计数据管理子系统
? 设计类中的服务
? 设计关联
? 设计优化
OOD的准则
? 模块化
? 抽象
? 信息隐蔽
? 弱耦合
– 交互耦合
– 继承耦合
? 强内聚
– 服务内聚
– 类内聚
– 一般 —特殊内聚
? 可重用
启发式规则
? 设计结果应该清晰易懂
– 用词一致
– 使用已有的协议
– 减少消息模式的数目
– 避免模糊的定义
? 深度适当
? 设计简单的类
– 避免包含过多的属性
– 有明确的类定义
– 尽量简化对象之间的合作关系
– 不要提供太多服务
? 使用简单的协议
? 把设计变动最小化
软件重用
? 重用的三个层次
– 知识重用
– 方法和标准的重用
– 软件成分的重用
? 软件成分重用的三个级别
– 代码重用
? 源代码剪贴
? 源代码包含
? 继承
– 设计结果重用
– 分析结果重用
软件重用的效果
? 实现重用的代价
– 创建构件库的代价
– 保证可重用构件质量的代价
– 更新和维护构件库的代价
? 重用率与生产率的关系
软件重用技术
? 三种重用技术
– 软件组合技术
– 软件生成技术
– OO软件重用技术
? 可重用构件应具备的特点
– 模块独立性强
– 具有高度可塑性
– 接口清晰、简明、可靠
? 类构件的重用方式
– 实例重用
– 继承重用
– 多态重用
系统分解
? 设计模型的五个层次
– 主题
– 类和对象
– 结构
– 属性
– 服务
? 多数软件系统由四个子系统组成
– 问题域子系统
– 人机交互子系统
– 任务管理子系统
– 数据管理子系统
系统分解（续）
? 子系统之间的交互方式
– 客户 ——供应商关系 (Client —Supplier)
– 平等伙伴关系（ peer to peer)
? 组织系统的两种方案
– 层次组织
? 开放式
? 封闭式
– 块状组织
– 混合组织
? 设计系统的拓扑结构
– 管道形
– 树形
– 星形
设计问题域子系统
? OOD和 OOA的区别
– OOA从描述问题域的角度 建立 三视点模型
– OOD从实现的角度 补充, 修改 三视点模型
– 从 OOA到 OOD能够保持问题域组织框架的稳定性
? 主要任务
– 调整需求（两个方面）
– 重用已有的类（ P244描述了重用的四个典型过程）
– 引入根类以组合问题域的类
– 为类的公共协议定义一组相似的服务而增添附加类
– 调整继承层次
设计问题域子系统（续）
? 调整继承层次所注意的问题
– 使用多继承机制时，避免属性和服务命名的冲突
两种多重继承模式
? 窄菱形模式（图 11.4）
? 阔菱形模式（图 11.5）
– 将多重继承转换为单继承机制
? 利用组合关系分解多重继承（图 11.6）
? 利用归纳关系简化多重继承
– 尽量选用具有继承机制的语言
? ATM系统的问题域子系统的结构（ P247）
设计人 —机交互子系统
? 设计人 —机交互界面的准则
– 一致性（术语、步骤、动作）
– 减少步骤
– 及时提供反馈信息
– 提供撤消命令
– 无须记忆
– 易学
– 富有吸引力
? 设计人 —机交互子系统的策略
– 分类用户
? 按照技能水平分类
? 按照职务分类
? 按照所属集团分类
– 描述用户
? 用户类型
? 使用系统欲达到的目的
? 特征（年龄、性别、文化程度、限制因素等）
? 关键的成功因素（需求、爱好、习惯等）
? 技能水平
? 完成本职工作的脚本
– 设计命令层次（可供选用的服务的表示形式）
? 研究现有的人机交互的含义和准则（ Windows)
? 确定初始的命令层次
? 精化命令层次 (次序、整体与部分关系、宽度和深度、操作方式）
– 设计人机交互类
设计任务管理子系统
? 分析并发性
– 依据：动态模型
– 并发性：如果两个对象彼此之间不存在交互，
或同时接受事件，则这两个对象在本质上是
并发的。
– 控制线：一条遍及状态图集合的路径，在这
条路径上每次只有一个对象是活动的。能够
把若干个非并发的对象归并到一条控制线上。
– 多任务：多个任务并发执行
设计任务管理子系统（续）
? 确定任务类型并把任务分配给适当的单元
– 事件驱动型任务
– 时钟驱动型任务
– 优先任务
– 关键任务
– 协调任务
? 尽量减少任务数量
? 确定资源需求
设计数据管理子系统
? 选择数据存储管理模式
– 文件管理系统
– 关系数据库管理系统 (DBMS)
– OO数据管理系统 (ODBMS)
? 设计数据格式
? 设计相应的服务
三种数据存储管理模式的比较
? 文件管理系统
– 属于 OS，文件操作级别低，对于高级操作须额外的代
码
– 通用性差
? 关系数据库管理系统 (DBMS)
– 提供各种最基本的数据管理功能（共享、事务支持等）
– 为多种应用提供一致的接口
– 标准化语言（ SQL）
– 运行开销大
– 难于应付数据类型丰富或操作不标准的应用
– 与程序设计语言连接不自然,SQL语言支持面向集合的
操作
三种数据存储管理模式的比较（续）
? OO数据管理系统 (ODBMS)
– 扩展 DBMS
? 增加抽象数据类型、继承机制；
? 增加了创建管理类对象的通用服务
– 扩展 OO语言
? 扩充 OO语言的语法和功能，增加在数据库中存储和
管理对象的机制
? 准确存储对象，而不是仅仅存储对象值 ——―永久对
象”方法
设计数据格式
? 文件系统
– 定义第一范式表：列出类的属性表并规范成第一范式
– 为每个第一范式表定义一个文件
– 测量性能和需要的存储容量
– 修改原设计的第一范式，以满足性能和存储需求
? DBMS
– 定义第三范式表：列出类的属性表并规范成第三范式
– 为每个第三范式表定义一个数据库表
– 测量性能和需要的存储容量
– 修改原设计的第三范式，以满足性能和存储需求
? ODBMS
– 扩展 DBMS途径：同上
– 扩展 OO语言途径,ODMS本身具有把对象映射成存储值
的功能，故不需要规范属性的步骤。
设计相应数据管理的服务
? 文件系统
– 被存储的对象需要知道打开哪些文件
– 怎样把文件定位到正确的记录上
– 怎样检索、更新
– 定义一个“对象服务器”类，并创建它的实例
? 通知对象保存自己
? 检索已存储的对象，以便将这些对象提供给其它子系统使用
? DBMS
– 被存储的对象需要知道打开哪些数据库表
– 怎样把文件定位到正确的行上
– 怎样检索、更新
– 定义一个“对象服务器”类，并声明它的对象，以提供以下服务
? 通知对象保存自己
? 检索已存储的对象，以便将这些对象提供给其它子系统使用
? ODBMS
– 扩展 DBMS途径：同上
– 扩展 OO语言途径,ODMS已经给每个对象提供了“保存自己”的
功能，故不需要增加服务。但要给需长期保存的对象加上标记，由 ODBMS负责存储和恢复这类对象。
OOD—设计类中的服务
? 确定类中应有的服务
– 在不同状态下接受同一事件所采取的行为不
同，实现服务的算法需要一个依赖于状态的
DO_CASE型控制结构
– 确定操作的目标对象（ P256）
– 确定处理的归属（ P256）
? 设计实现服务的方法
– 设计实现服务的算法
– 选择数据结构
– 定义内部类和内部操作
OOD—设计关联
? 关联的遍历
– 单向遍历
– 双向遍历
? 实现单向关联
– 用指针实现单向关联（图 11.11)
? 实现双向关联
– 只用属性实现一个方向的关联
– 两个方向的关联都用属性实现（图 11.12)
– 用独立的关联对象实现双向关联（图 11.13）
? 链属性的实现
– 1, 1
– 1, N
– N, M
OOD—设计优化
? 确定质量指标的优先级
? 提高效率的技术（ P259）
– 增加冗余关联以提高访问效率
– 调整查询次序
– 保留派生属性
? 调整继承关系
– 抽象与具体
– 为提高继承程度而修改类定义
– 利用委托实现行为共享
