第8章 面向对象设计
第8章 面向对象设计
在面向对象分析阶段只考虑问题域 和系统责任，在面向对象设计阶段则 要考虑与具体实现有关的问题
与传统的结构化设计相比：
相同点：将需求分析模型转变为软件设计 模型 不同点：OOA和OOD之间没有明显界限 OOA和OOD都是迭代过程
第8章 面向对象设计
例如银行储蓄系统中分行、终端、储户这个 组织结构会长期保持稳定，虽然如储户的属 性可能会发生变化。正是基于这种稳定，面 向对象的分析和设计模型按问题域本身的样 子来组织系统，也能从容适应变化的需求， 能保持稳定性。
设计问题域子系统
改动不是否定OOA的分析结果，而是 完善结果 改动基于以下几个原因： （1）由于需求的变化； （2）分析员对问题域的理解可能有误解 或欠缺，需要对此加以修正； （3）分析与设计毕竟是性质不同的两类 开发工作，分析可以而且应该与具体 实现无关，而设计在很大程度上受具 体实现环境的约束。
组织系统的两种方案
水平层次组织
上层在下层的基础上建立，下层为上层提 供必要的服务 每一层内所包含的对象，彼此间相互独立， 而处于不同层次上的对象，彼此间往往有 关联。实际上，在上、下层之间存在客户 -供应商关系。
垂直块状组织
把软件系统垂直地分解成若干个相对独立、 弱耦合的子系统
A. 一致性（一致的术语、一致的步骤、一致 的活动） B. 操作步骤少 C. 提供撤销命令 D. 最大限度减少记忆 E. 易学易懂 F. 趣味浓，有吸引力（不要“哑播放”）
设计人-机交互子系统
人机交互设计的策略：
1. 2. 3. 4. 5.
分类用户 描述用户 设计命令层次 设计详细的交互 设计人机交互的类
OOD遵循的原则
（二）抽象
过程抽象 数据抽象 参数化抽象：把数据类型作为参数，例如C++里 的模板 类实际上是一种抽象数据类型，它对外开放的公 共接口构成了类的规格说明（即协议），这种接 口规定了外界可以使用的合法操作符，利用这些 操作符可以对类实例中包含的数据进行操作。使 用者无须知道这些操作符的实现算法和类中数据 元素的具体表示方法，就可以通过这些操作符使 用类中定义的数据。通常把这类抽象称为规格说 明抽象。
系统设计过程
人机交互部分（HIC）的设计概述 虽然好的人机交互部分不可能挽救 一个功能很差的软件, 但性能很差的 人机交互部分将使一个功能很强的 产品变的不可接受!
系统设计过程
任务管理部分（TMC）的设计概述
为什么要有任务管理部分？ 系统中有许多并发行为时，需要按照各 个行为的协调和通信关系，划分各种任务 (进程)，简化并发行为的设计和编码。
整体-部分关系：寻找在这些服务中存在的整体-部分模 式，这样做有助于在命令层中分组组织服务。
宽度和深度：每层命令的个数应遵循7+2原则，命令的层 次深度尽量要控制在三层以内。 操作步骤：应该用尽量少的单击、拖动和击键组合来表 达命令，而且应该为高级用户提供简捷的操作方法。
设计人-机交互子系统
4. 设计人机交互类
设计人-机交互子系统
1. 分类用户
为设计出符合用户需要的界面，首先应该将 用户分类。通常从下列几个不同角度进行分 类： 按技能水平分类(新手、初级、中级、高 级)。 按职务(职员、顾客)。
设计人-机交互子系统
2. 描述用户 描述用户信息有：
设计问题域子系统
重用类例子：
重用现成类 问题域中的类 交通工具 颜色 性能 制造商 现成的类 交通工具1 类别 性能 制造商 交通工具1 类别 性能 制造商 交通工具 颜色 性能 制造商
（a）
（b）
（c）
设计问题域子系统
如果已存在一些可复用的类，而且这些类既 有分析、设计时的定义，又有源程序，那么， 复用这些类即可提高开发效率与质量。
组织系统的两种方案
利用层次和块的各种可能的组合，可以成功地由多 个子系统组成一个完整的软件系统。当混合使用层 次结构和块状结构时，同一层次可以由若干块组成， 而同一块也可以分为若干层。 典型应用系统组织结构（层次与块状的混合）
设计问题域子系统
一般来说，基于问题域的总体组织框架是长 时间保持稳定的（当然，细节是会变的，这 里加一个类说明，那里加一个属性或服务）。
OOD遵循的原则
（三）信息隐藏 通过对象的封装性实现 对于用户来说，类中的属性的表示方法和 操作的实现算法都应该是隐藏的。 （四）弱耦合 降低交互耦合（消息连接）
1.尽量降低消息连接的复杂程度。应该尽量减少 消息中包含的参数个数，降低参数的复杂程度。 2.减少对象发送（或接收）的消息数。
提高继承耦合
系统设计过程
⑴ 划分子系统； ⑵ 确定需要并发运行的子系统并为它们分 配处理器； ⑶ 描述子系统之间的通信； ⑷ 确定系统资源的管理和控制； ⑸ 确定人机交互构件； ⑹ 选择实现数据管理和任务管理的基本策 略。
系统设计过程
确定子系统需要考虑的问题
哪个子系统负责什么客户需求？ OOA中定义的对象分配到哪个子系统 中？ 哪些子系统必须并发运行，以及由什么系 统构件协调和控制它们？ 全局资源如何被子系统管理？
内容安排： OOD遵循的原则 系统设计过程
子系统之间的两种交互方式 组织系统的两种方案
设计人-机交互、设计任务管理、数据 管理子系统 设计类中的服务、关联 设计优化
OOD遵循的原则
（一）模块化
对象就是模块，把数据和方法结合在一起 面向对象软件开发模式，很自然地支持了 把系统分解成模块的设计原理：类就是模 块。它是把数据结构和对数据的操作紧密 地结合在一起所构成的模块。
OOD遵循的原则
（五）强内聚
服务内聚：一个服务仅完成一个功能 类内聚：一个类只有一个用途，不包括无 用的属性或服务 一般-特殊内聚：要符合多数人的概念
OOD遵循的原则
（六）可重用
尽量使用已有的类 创建新类时，考虑将来的可重用性 重用有两方面的含义：一是尽量使用已有 的类（包括开发环境提供的类库，以及以 往开发类似系统是创建的类）；二是如果 确实需要创建新类，则在设计这些新类的 协议时，应该考虑将来的可重复使用性
人机交互类与所使用的操作系统及编程语 言密切相关。 例如在windows环境下，从主窗口和部件 的人机交互开始，以分类或组装的结构设 计出各层的窗口类，每个类中封装了菜单 条、下拉菜单、弹出菜单的定义；定义了 用来创建菜单、加亮选择项、引用相应的 响应所需的服务、所有的物理对话、窗口 的实际显示。设计人员可以重用现成的类， 例如Visual C++语言提供的MFC类库
可复用的类可能只是与OOA模型中的类相似， 而不是完全相同，因此需对二者进行修改。 目标：尽可能使复用成分增多，新开发的成 分减少
设计问题域子系统
不同程度的复用
可 复 用 类 定 义 的 信 息 当 前 所 需 的 类 的 信 息
＝ ＜
直接复用 通过继承复用
比
＞
≈
删除可复用类的多余信息
删除多余信息，通过继承而复用
设计问题域子系统
考虑语言调整继承支持级别
如果OOA模型依赖于多重继承而设计者 发现最终用于实现系统的程序设计语言只 能支持单继承或不具备继承机制。这时就 需要修改原来的类层次结构。
设计问题域子系统
例如：采用聚合方法
公司人员
创建“雇主职员”对 象
公司人员 1 0..2 身份
雇主
职员
雇主身份 雇主职员
系统设计过程
划分子系统时应考虑的原则
模块化、独立性、信息隐藏等等 同一个子系统的类是否拥有共同特性？ 同一个子系统的类是否具有相同的目的？ 同一个子系统的类是否提供相似的服务类 型？ 同一个子系统的类之间是否具有高耦合性？
系统设计过程
系统设计的四种主要子系统： 1.问题域—直接负责实现客户需求的子系 统 2. 人 机 交 互 — 实 现 用 户 界 面 的 子 系 统 （包括可复用的GUI子系统） 3.任务管理—负责控制和协调并发任务的 子系统，任务可能被包装在一个子系 统中或不同的子系统间； 4.数据管理—负责对象的存储和检索的子 系统
用户类型。 使用系统欲达到的目的。 特征(年龄、性别、受教育程度、限制因 素等)。 关键的成功因素(需求、爱好、习惯等)。 技能水平。 完成本职工作的脚本。
设计人-机交互子系统
3. 设计命令层次 (1)研究现有的人机交互含义和准则
与熟悉的应用程序界面相一致，例如 windows程序。
设计问题域子系统
把问题域专用类组合在一起，通过增 添一般类而建立协议
将问题域许多不同的类聚集在一起，这时 可建立一个新的父类——超类，将这许多 类作为该超类的子类。这样一方面有助于 改进模型的可理解性，同时可以在超类中 给出一个公共的协议(例如：提供创建、 删除、复制等服务)，用来与其它子系统 或与外部系统部件进行通信。通信的细节 在子类中定义。
职员身份
创建“雇主”对 象
创建“职员”对 象
设计人-机交互子系统
简单的讲，人机交互部分是人和计算 机之间交互信息的媒介，对它的设计 涉及到计算机科学、心理学、艺术学、 认知科学和人机工程学等学科。本节 阐述的是人机交互的软件方面的设计。
设计人-机交互子系统
为每一个命令设计详细的交互，在设计 交互过程中要遵循以下规则：
系统设计过程
数据管理部分（DMC）的设计概述 数据管理部分提供了数据在数据管 系统中存储和检索对象的基本结构， 它分离了数据管理方案的影响 (不管 该方案是普通文件、关系型数据库、 面向对象数据库或其它方式。)
子系统之间的两种交互方式
(1) 客户-供应商(Client-supplier)关系 在这种关系中，作为“客户”的子系统调用 作为“供应商”的子系统，后者完成某些服 务工作并返回结果。 (2) 平等伙伴(peer-to-peer)关系 在这种关系中，每个子系统都可能调用其他 子系统，因此，每个子系统都必须了解其他 子系统的接口。 总的说来，单向交互比双向交互更容易理解， 也更容易设计和修改，因此应该尽量使用客 户-供应商关系。