《软件工程》课件 第十一章面向对象设计
合集下载
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
雇员 1+ 被雇用 公司
1、单向关联 例：
由雇员找其所属公司， 则设雇主为其属性，即 一单向指针
雇员 雇主
公司
由公司找其下属某一雇员，则有两种方法：
方法1：遍历所有雇员，找雇主匹配且满足特征的雇 员。（省空间）
2014年春 • 软件工程
方法 2 ：设公司 的属 性雇员 为 一指针集。 （快速） 2、双向关联
2014年春 • 软件工程
OOD模型分解
（1）问题论域部分，设计构造一组为底层应用建 立模型的类和对象，细化分析结果；
（2）人机交互部分，设计一组有关类接口视图的
用户模型的类和对象，设计用户界面； （2）任务管理部分，确定系统资源的分配，设计 用于系统中类的行为控制的对象/类； （4）数据管理部分，确定持久对象的存储，将对 象转换成数据库记录或表格；
11.4
系统分解
I P O
回顾SD：从DFD出发 OOD模型分解：
Category
问题域
Application Domain
人机交互 任务管理 数据管理
HumanTask Data Computer Management Management Interface (HCI)
Class-&-Object Structure Attribute Method
设计数据管理子系统
11.8.1 选择数据存储管理模式
1. 文件管理系统 2. 关系数据库管理系统 3. 面向对象数据库管理系统
11.8.2 设计数据管理子系统
设计数据管理子系统，既需要设计数据格式又需 要设计相应的服务。 1. 设计数据格式 2. 设计相应的服务
2014年春 • 软件工程
11.8.3
第11章 面向对象设计
11.1 11.2 11.3 11.4 11.5 11.6 面向对象设计的准则 启发规则 软件重用 系统分解 设计问题域子系统 设计人机交互子系统 11.7 设计任务管理子系统 11.8 设计数据管理子系统 11.9 设计类中的服务 11.10 设计关联 11.11 设计优化
2014年春 • 软件工程
P
O
2014年春 • 软件工程
2、设计实现方法 ⑴ 算法设计：要求做到易修改，并且复杂度低（即 效率高）; 易理解，易实现。 ⑵ 数据结构设计：需要考虑具体的物理结构的选择。 ⑶ 新添用于存放内部处理中间结果的class；引入新 的低层操作，进一步细化。
2014年春 • 软件工程
11.10
设计关联
2014年春 • 软件工程
2. 重用已有的类
重用已有类的典型过程如下： (1) 选择有可能被重用的已有类，标出这些候选类中 对本问题无用的属性和服务，尽量重用那些能使无用 的属性和服务降到最低程度的类。 (2) 在被重用的已有类和问题域类之间添加泛化关系 (即从被重用的已有类派生出问题域类)。 (3) 标出问题域类中从已有类继承来的属性和服务， 现在已经无须在问题域类内定义它们了。 (4) 修改与问题域类相关的关联，必要时改为与被重 用的已有类相关的关联。
2014年春 • 软件工程
11.5
设计问题域子系统
可能对面向对象分析所得出的问题域模型做 的补充或修改 1. 调整需求 有两种情况会导致修改通过面向对象分析所确定的 系统需求：一是用户需求或外部环境发生了变化； 二是分析员对问题域理解不透彻或缺乏领域专家 帮助，以致面向对象分析模型不能完整、准确地 反映用户的真实需求。
（2） 由数据管理子系统负责存储对象
账户类对象在接到“存储自己”的通知后，知道应该向数据管理子系统 发送什么消息，以便由数据管理子系统把它的状态保存起来，为此也需 要增加属性和服务来定义上述行为。使用这种方法的优点，是无须修改 问题域子系统。
2014年春 • 软件工程
如上一小节所述，应该定义一个数据管理类Objec tServer，并声明它的对象。这个类提供下列服务： 通知对象保存自身或保存需长期存储的对象的状态； 检索已存储的对象并使之“复活”。
1、设计结果清晰易懂，应做到： ① 用词一致 —— 按习惯用法命名。不同cla sses中相似的methods最好取同一名字。 ② 使用已有的protocol。 ③ 尽量减少message模式的数目。 ④ 避免模糊定义。 2、一般-特殊结构的深度应适当 （约100个classes,则设计7±2层）
2014年春 • 软件工程
方法和标准重用（例如OO方法和国家规定
的软件开发规范的重用）
软件成分的重用
重用软件成分有三个级别： ① 代码重用： • 源码剪贴 —— 无法溯源，无配置管理 • Include —— 修改后所有包含了此段代码的程 序都须重新编译。 • Inheritance —— 无须改动原有代码
2014年春 • 软件工程
2014年春 • 软件工程
5、内聚Cohesion： 服务内聚(service cohesion)：一个服务只完成一个功能。
类内聚(class cohesion)：一个类只有一个用途，否则分
解之。
一般-特殊内聚
6、复用性Reusability
2014年春 • 软件工程
11.2
启发规则
11.1
面向对象设计的准则
优秀软件设计的一个重要特点是容易维护 回顾：SD准则包括 模块化 抽象 信息隐藏 模块独立
2014年春 • 软件工程
对于 OOD有类似的准则： 1、模块化：Module = Object 2、抽象Abstraction：抽出事物的本质特性, 暂不考 虑其细节，使设计从具体实现方法中超脱。 3、信息隐藏Information hiding = 对象封装 Encapsulation of object 4、耦合Coupling: 交互耦合(interactive coupling):通过传递message 发生；要求降低参数个数和参数复杂性 继承耦合(inheritance coupling): 要求 Parent class IS_A child class as high as p ossible
2014年春 • 软件工程
4、使用简单的protocol，减少message 中传递的 parameters 5、使用简单的method(CASE 可考虑用 inheritance替代)。 6、把设计变动减至最小。
2014年春 • 软件工程
11.3
软件重用
知识 工程
概念： 知识重用（例如软件工程知识的重用）
2014年春 • 软件工程
3. 把问题域类组合在一起 通过引入一个根类而把问题域类组合在一起。 4. 增添一般化类以建立协议 一些具体类需要有一个公共的协议，即一组类似 的服务。在这种情况下可以引入一个附加类 (例如， 根类)，以便建立这个协议(即命名公共服务集合， 这些服务在具体类中仔细定义)。 5. 调整继承层次 (1) 使用多重继承机制 (2) 使用单继承机制
② 设计重用 —— 当移植系统时
③ 分析重用 —— 当需求未变，而系统结构改变时
重用效果的衡量： 额外代价： 创建可重用成分的专门投资 多花2 ~ 4倍时间测试以保证质量 构件库的建立与维护需要投资 以上投资将分摊到重用这些构件的新系统 成本中。重用次数越多，分摊成本越少。
2014年春 • 软件工程
2014年春 • 软件工程
一些设计人机交互子系统的策略
1. 分类用户 通常从下列几个不同角度进行分类： 按技能水平分类(新手、初级、中级、高级)。 按职务分类(总经理、经理、职员)。 按所属集团分类(职员、顾客)。 2. 描述用户 应该仔细了解将来使用系统的每类用户的情况，把获得的 下列各项信息记录下来： 用户类型。 使用系统欲达到的目的。 特征(年龄、性别、受教育程度、限制因素等)。 关键的成功因素(需求、爱好、习惯等)。 技能水平。 完成本职工作的脚本。
2014年春 • 软件工程
1、子系统之间的交互方式(collaboration)
① 客户-供应商(client-server)关系：
Client subsystem request Server subsystem contract
② 平等伙伴(peer-to-peer)关系：
Peer subsystem contract
雇员
公司 雇员
指针集
方法 1：将上述两种单向 关联结合使用
雇员 雇主 公司 雇员
方法 2：另设关联类（特 别适用于链属性）
公司
关联类
雇主 雇员 工资
指针集
2014年春 • 软件工程
例子
为具体说明数据管理子系统的设计方法，让我们再 看看图11.7所示的ATM系统。 从图中可以看出，惟一的永久性数据存储放在分行 计算机中。因为必须保持数据的一致性和完整性， 而且常常有多个并发事务同时访问这些数据，因此， 采用成熟的商品化关系数据库管理系统存储数据。 应该把每个事务作为一个不可分割的批操作来处理， 由事务封锁账户直到该事务结束为止。
2014年春 • 软件工程
request request
Peer subsystem contract
2、系统组织方案
① 水平层次组织： 将系统组织成hierarchy，同一层中的objects相 互独立，而上、下层间有 client-server关系。
一个client只能调用其相邻下层的server —— 封闭式(closed) 一个client可调用其下任一层的server —— 开放式(open)
2014年春 • 软件工程
11.9
设计类中的服务
Status 1 do: Action 1 Event Status 2 do: Action 2
—— 细化object model中的 methods
1、确立服务
⑴ 从 dynamic model出发：
……
⑵ 从function model出发：
I
优点：高效； 缺点：修改影响面广
2014年春 • 软件工程
② 垂直块组织： 将系统垂直分解成若干独立的子系统，一个子 系统相当于一块，每块提供一种类型的服务。
典型应用系统的组织结构
应 用 软 件 包
人机对 话控制
窗口图形 HCI 图形 屏幕图形 处理 象素图形
仿真 软件包
操 作 系 统 计 算 机 硬 件
2014年春 • 软件工程
3. 设计命令层次 (1) 研究现有的人机交互含义和准则 (2) 确定初始的命令层次 (3) 精化命令层次 4. 设计人机交互类 人机交互类与所使用的操作系统及编程语言 密切相关。例如，在Windows环境下运行的Vis ual C++语言提供了MFC类库，设计人机交互 类时，往往仅需从MFC类库中选出一些适用的 类，然后从这些类派生出符合自己需要的类就 可以了。
2014年春 • 软件工程
在这个例子中，需要存储的对象主要是账户类 的对象。为了支持数据管理子系统的实现，账户类 对象必须知道自己是怎样存储的，有两种方法可以 达到这个目的。 （1） 每个对象自己保存自己
账户类对象在接到“存储自己”的通知后，知道怎样把自身存储起来 (需要增加一个属性和一个服务来定义上述行为)。
2014年春 • 软件工程
6. ATM系统实例
图11.7 ATM系统问题域子系统的结构
2014年春 • 软件工程
11.6
设计人机交互子系统
人机交互部分的设计结果，将对用户情绪和 工作效率产生重要影响。人机界面设计得好，则 会使系统对用户产生吸引力，用户在使用系统的 过程中会感到兴奋，能够激发用户的创造力，提 高工作效率；相反，人机界面设计得不好，用户 在使用过程中就会感到不方便、不习惯，甚至会 产生厌烦和恼怒的情绪。
3、设计简单的class（定义不超过一页纸或两屏）。 应注意： ① 避免过多attributes； ② 能用简单的语句描述一个class的任务； ③ objects之间合作关系要简单； ④避免过多mLeabharlann Baiduthods( 7个)。 问题：设计出大量的classes，使结构复杂度增加。 解决：划分主题，提高可理解性。
2014年春 • 软件工程
11.7
设计任务管理子系统
1. 分析并发性 2. 设计任务管理子系统 （1） 确定事件驱动型任务 （2） 确定时钟驱动型任务 （3） 确定优先任务 （4） 确定关键任务 （5） 确定协调任务 （6） 尽量减少任务数 （7） 确定资源需求
2014年春 • 软件工程
11.8
1、单向关联 例：
由雇员找其所属公司， 则设雇主为其属性，即 一单向指针
雇员 雇主
公司
由公司找其下属某一雇员，则有两种方法：
方法1：遍历所有雇员，找雇主匹配且满足特征的雇 员。（省空间）
2014年春 • 软件工程
方法 2 ：设公司 的属 性雇员 为 一指针集。 （快速） 2、双向关联
2014年春 • 软件工程
OOD模型分解
（1）问题论域部分，设计构造一组为底层应用建 立模型的类和对象，细化分析结果；
（2）人机交互部分，设计一组有关类接口视图的
用户模型的类和对象，设计用户界面； （2）任务管理部分，确定系统资源的分配，设计 用于系统中类的行为控制的对象/类； （4）数据管理部分，确定持久对象的存储，将对 象转换成数据库记录或表格；
11.4
系统分解
I P O
回顾SD：从DFD出发 OOD模型分解：
Category
问题域
Application Domain
人机交互 任务管理 数据管理
HumanTask Data Computer Management Management Interface (HCI)
Class-&-Object Structure Attribute Method
设计数据管理子系统
11.8.1 选择数据存储管理模式
1. 文件管理系统 2. 关系数据库管理系统 3. 面向对象数据库管理系统
11.8.2 设计数据管理子系统
设计数据管理子系统，既需要设计数据格式又需 要设计相应的服务。 1. 设计数据格式 2. 设计相应的服务
2014年春 • 软件工程
11.8.3
第11章 面向对象设计
11.1 11.2 11.3 11.4 11.5 11.6 面向对象设计的准则 启发规则 软件重用 系统分解 设计问题域子系统 设计人机交互子系统 11.7 设计任务管理子系统 11.8 设计数据管理子系统 11.9 设计类中的服务 11.10 设计关联 11.11 设计优化
2014年春 • 软件工程
P
O
2014年春 • 软件工程
2、设计实现方法 ⑴ 算法设计：要求做到易修改，并且复杂度低（即 效率高）; 易理解，易实现。 ⑵ 数据结构设计：需要考虑具体的物理结构的选择。 ⑶ 新添用于存放内部处理中间结果的class；引入新 的低层操作，进一步细化。
2014年春 • 软件工程
11.10
设计关联
2014年春 • 软件工程
2. 重用已有的类
重用已有类的典型过程如下： (1) 选择有可能被重用的已有类，标出这些候选类中 对本问题无用的属性和服务，尽量重用那些能使无用 的属性和服务降到最低程度的类。 (2) 在被重用的已有类和问题域类之间添加泛化关系 (即从被重用的已有类派生出问题域类)。 (3) 标出问题域类中从已有类继承来的属性和服务， 现在已经无须在问题域类内定义它们了。 (4) 修改与问题域类相关的关联，必要时改为与被重 用的已有类相关的关联。
2014年春 • 软件工程
11.5
设计问题域子系统
可能对面向对象分析所得出的问题域模型做 的补充或修改 1. 调整需求 有两种情况会导致修改通过面向对象分析所确定的 系统需求：一是用户需求或外部环境发生了变化； 二是分析员对问题域理解不透彻或缺乏领域专家 帮助，以致面向对象分析模型不能完整、准确地 反映用户的真实需求。
（2） 由数据管理子系统负责存储对象
账户类对象在接到“存储自己”的通知后，知道应该向数据管理子系统 发送什么消息，以便由数据管理子系统把它的状态保存起来，为此也需 要增加属性和服务来定义上述行为。使用这种方法的优点，是无须修改 问题域子系统。
2014年春 • 软件工程
如上一小节所述，应该定义一个数据管理类Objec tServer，并声明它的对象。这个类提供下列服务： 通知对象保存自身或保存需长期存储的对象的状态； 检索已存储的对象并使之“复活”。
1、设计结果清晰易懂，应做到： ① 用词一致 —— 按习惯用法命名。不同cla sses中相似的methods最好取同一名字。 ② 使用已有的protocol。 ③ 尽量减少message模式的数目。 ④ 避免模糊定义。 2、一般-特殊结构的深度应适当 （约100个classes,则设计7±2层）
2014年春 • 软件工程
方法和标准重用（例如OO方法和国家规定
的软件开发规范的重用）
软件成分的重用
重用软件成分有三个级别： ① 代码重用： • 源码剪贴 —— 无法溯源，无配置管理 • Include —— 修改后所有包含了此段代码的程 序都须重新编译。 • Inheritance —— 无须改动原有代码
2014年春 • 软件工程
2014年春 • 软件工程
5、内聚Cohesion： 服务内聚(service cohesion)：一个服务只完成一个功能。
类内聚(class cohesion)：一个类只有一个用途，否则分
解之。
一般-特殊内聚
6、复用性Reusability
2014年春 • 软件工程
11.2
启发规则
11.1
面向对象设计的准则
优秀软件设计的一个重要特点是容易维护 回顾：SD准则包括 模块化 抽象 信息隐藏 模块独立
2014年春 • 软件工程
对于 OOD有类似的准则： 1、模块化：Module = Object 2、抽象Abstraction：抽出事物的本质特性, 暂不考 虑其细节，使设计从具体实现方法中超脱。 3、信息隐藏Information hiding = 对象封装 Encapsulation of object 4、耦合Coupling: 交互耦合(interactive coupling):通过传递message 发生；要求降低参数个数和参数复杂性 继承耦合(inheritance coupling): 要求 Parent class IS_A child class as high as p ossible
2014年春 • 软件工程
4、使用简单的protocol，减少message 中传递的 parameters 5、使用简单的method(CASE 可考虑用 inheritance替代)。 6、把设计变动减至最小。
2014年春 • 软件工程
11.3
软件重用
知识 工程
概念： 知识重用（例如软件工程知识的重用）
2014年春 • 软件工程
3. 把问题域类组合在一起 通过引入一个根类而把问题域类组合在一起。 4. 增添一般化类以建立协议 一些具体类需要有一个公共的协议，即一组类似 的服务。在这种情况下可以引入一个附加类 (例如， 根类)，以便建立这个协议(即命名公共服务集合， 这些服务在具体类中仔细定义)。 5. 调整继承层次 (1) 使用多重继承机制 (2) 使用单继承机制
② 设计重用 —— 当移植系统时
③ 分析重用 —— 当需求未变，而系统结构改变时
重用效果的衡量： 额外代价： 创建可重用成分的专门投资 多花2 ~ 4倍时间测试以保证质量 构件库的建立与维护需要投资 以上投资将分摊到重用这些构件的新系统 成本中。重用次数越多，分摊成本越少。
2014年春 • 软件工程
2014年春 • 软件工程
一些设计人机交互子系统的策略
1. 分类用户 通常从下列几个不同角度进行分类： 按技能水平分类(新手、初级、中级、高级)。 按职务分类(总经理、经理、职员)。 按所属集团分类(职员、顾客)。 2. 描述用户 应该仔细了解将来使用系统的每类用户的情况，把获得的 下列各项信息记录下来： 用户类型。 使用系统欲达到的目的。 特征(年龄、性别、受教育程度、限制因素等)。 关键的成功因素(需求、爱好、习惯等)。 技能水平。 完成本职工作的脚本。
2014年春 • 软件工程
1、子系统之间的交互方式(collaboration)
① 客户-供应商(client-server)关系：
Client subsystem request Server subsystem contract
② 平等伙伴(peer-to-peer)关系：
Peer subsystem contract
雇员
公司 雇员
指针集
方法 1：将上述两种单向 关联结合使用
雇员 雇主 公司 雇员
方法 2：另设关联类（特 别适用于链属性）
公司
关联类
雇主 雇员 工资
指针集
2014年春 • 软件工程
例子
为具体说明数据管理子系统的设计方法，让我们再 看看图11.7所示的ATM系统。 从图中可以看出，惟一的永久性数据存储放在分行 计算机中。因为必须保持数据的一致性和完整性， 而且常常有多个并发事务同时访问这些数据，因此， 采用成熟的商品化关系数据库管理系统存储数据。 应该把每个事务作为一个不可分割的批操作来处理， 由事务封锁账户直到该事务结束为止。
2014年春 • 软件工程
request request
Peer subsystem contract
2、系统组织方案
① 水平层次组织： 将系统组织成hierarchy，同一层中的objects相 互独立，而上、下层间有 client-server关系。
一个client只能调用其相邻下层的server —— 封闭式(closed) 一个client可调用其下任一层的server —— 开放式(open)
2014年春 • 软件工程
11.9
设计类中的服务
Status 1 do: Action 1 Event Status 2 do: Action 2
—— 细化object model中的 methods
1、确立服务
⑴ 从 dynamic model出发：
……
⑵ 从function model出发：
I
优点：高效； 缺点：修改影响面广
2014年春 • 软件工程
② 垂直块组织： 将系统垂直分解成若干独立的子系统，一个子 系统相当于一块，每块提供一种类型的服务。
典型应用系统的组织结构
应 用 软 件 包
人机对 话控制
窗口图形 HCI 图形 屏幕图形 处理 象素图形
仿真 软件包
操 作 系 统 计 算 机 硬 件
2014年春 • 软件工程
3. 设计命令层次 (1) 研究现有的人机交互含义和准则 (2) 确定初始的命令层次 (3) 精化命令层次 4. 设计人机交互类 人机交互类与所使用的操作系统及编程语言 密切相关。例如，在Windows环境下运行的Vis ual C++语言提供了MFC类库，设计人机交互 类时，往往仅需从MFC类库中选出一些适用的 类，然后从这些类派生出符合自己需要的类就 可以了。
2014年春 • 软件工程
在这个例子中，需要存储的对象主要是账户类 的对象。为了支持数据管理子系统的实现，账户类 对象必须知道自己是怎样存储的，有两种方法可以 达到这个目的。 （1） 每个对象自己保存自己
账户类对象在接到“存储自己”的通知后，知道怎样把自身存储起来 (需要增加一个属性和一个服务来定义上述行为)。
2014年春 • 软件工程
6. ATM系统实例
图11.7 ATM系统问题域子系统的结构
2014年春 • 软件工程
11.6
设计人机交互子系统
人机交互部分的设计结果，将对用户情绪和 工作效率产生重要影响。人机界面设计得好，则 会使系统对用户产生吸引力，用户在使用系统的 过程中会感到兴奋，能够激发用户的创造力，提 高工作效率；相反，人机界面设计得不好，用户 在使用过程中就会感到不方便、不习惯，甚至会 产生厌烦和恼怒的情绪。
3、设计简单的class（定义不超过一页纸或两屏）。 应注意： ① 避免过多attributes； ② 能用简单的语句描述一个class的任务； ③ objects之间合作关系要简单； ④避免过多mLeabharlann Baiduthods( 7个)。 问题：设计出大量的classes，使结构复杂度增加。 解决：划分主题，提高可理解性。
2014年春 • 软件工程
11.7
设计任务管理子系统
1. 分析并发性 2. 设计任务管理子系统 （1） 确定事件驱动型任务 （2） 确定时钟驱动型任务 （3） 确定优先任务 （4） 确定关键任务 （5） 确定协调任务 （6） 尽量减少任务数 （7） 确定资源需求
2014年春 • 软件工程
11.8