10.2 设计技术支撑方案—与用例实现方案的融合 与用例实现方案的融合
技术支撑方案常包含数个公共技术服务子系统，它们为所有 的上层应用功能提供数量较少的外部接口。 融合技术支撑方案与用例实现方案：在UML交互图中添加 必要的公共技术服务子系统接口，让控制类与该接口所代表 的公共服务对象进行消息交互。这些接口在交互图中的布局 位置依据其提供服务的性质不同而有所变化：
第十章 面向对象的设计方法
齐治昌《软件工程》 齐治昌《软件工程》第二版
1. 设计用例实现方案 2. 设计技术支撑方案 3. 设计用户界面 4. 精化设计模型
10.0 概述
OOA、OOD模型过渡平滑 分析以问题为中心，设计面向计算机实现。 OOD使得从问题空间到解空间的变换直观合理。 OOD更自然地遵循抽象、信息隐藏、模块化原则。 OOD完成信息和处理的双重模块化。 OOA、OOD、OOP阶段间反复迭代
10.4 精化设计模型
精化的任务：p244
① ② ③ ④ ⑤
以顶层架构图为基础，精化目标软件系统的体系结构。 精化类之间的关系。 精化类的属性和操作。 针对具有明显状态转换特征的类，设计状态图。 针对比较复杂的类方法，设计活动图。
状态图：描述一个特定类的对象的所有可能状态以及因事 件而引起的状态转移。
状态图的节点包含状态名和活动(可选) 活动的分类：(1)-(4) p245 转移边上可以附加信息：p245 一张状态图可以包含一个初态和一到多个终态。 UML状态图是一种结构化的状态图。 例：p245 图10.9
10.4 精化设计模型——精化体系结构 精化体系结构
目的：寻找一种理想的包划分方案，使得每个包中直接包含 的类的数量规模适中，包的边界清晰、自然，并且包间的耦 合度较低。 类间耦合：从高到低p246 ：继承关系、构成关系、聚合关 系、关联关系、依赖关系、两个类的对象受同一执行者变化 的影响。 包的合并和分拆的目标：强内聚，松耦合 完全排除包间的依赖关系既无必要，也不合理。但是以下原 则要尽量遵守：
10.3 设计用户界面
用户界面设计的策略和步骤p243-244 ：
① ② ③ ④ ⑤ ⑥
熟悉用户并对用户分类。 按用户类别分析用户工作流程与习惯。 设计并优化命令系统。 设计用户界面的各种细节。 增加用户界面专用的类与对象。 利用快速原型演示，改进界面设计。为人机交互部 分构造原型，是界面设计的基本技术之一。
10.1 设计用例实现方案——精化类图 精化类图
利用交互图精化分析模型中的类图
交互图中，对每个类的对象都规定了它必须响应的消息(对应类的操 作)以及对象之间的消息传递通道(对应类间的连接关系) 。 方法/操作：原则上，每个类都应有一个操作来响应交互图中指向其 对象的那条消息。设计人员应尽量使用已有操作来响应新消息，并 尽量使用已存在的连接路径作为消息传递通道。 属性：类的操作完成消息响应责任的能力来源于两方面的知识：类 本身具有的信息（属性），其它类的协助。
10.1 设计用例实现方案——构造交互图 构造交互图
用例描述中，事件流中的事件直接对应于交互图中的消息， 事件的顺序体现为交互图中的时序… 用分离的交互图分别表示事件流和每个备选事件流 顺序图的布局规则：p236，典型 图10.4 协作图的布局规则：p237，典型 图10.5 例：图10.6、10.7
活动图适于表示用例中的事件流和过程，也可以表 示复杂的算法以及并发处理的进程。 针对比较复杂的处理过程并且比较重要的方法设计 活动图，如果需要强调处理过程中的并行性，可使 用活动图。 例:图10.17 例:图10.18
公共服务。 ③ 设计用户界面。 ④ 针对分析模型中的领域概念模型，以及第(2)、第(3)两个步骤引进的新类，完 整、精确地确定每个类的属性、操作，完整地标示类之间的关系。
设计过程：图10.1
10.1 设计用例实现方案
用例实现方案用交互图描述，交互图包括：顺序图、协作图 顺序图：描述对象之间动态的交互关系，着重表现对象间消息传递的时 间顺序。例：p233图10.2
元素：对象、时间、生命线、生命终结、活跃期、消息（序号、条件表达 式）、迭代标记*、描述信息等。 UML消息的四种类型：p232-233
① 简单消息：以一种简单、抽象的函数表示对象之间的信息传递，不考虑通信过程的
内部细节。简单消息在UML顺序图中用普通的有向箭头表示。 ② 同步消息：消息源发出消息后必须等待消息处理过程完毕并返回处理结果后，消息 源才可继续执行后续操作。前面所述的自调用消息应该是同步的。同步消息的表示 图元与简单消息相同，这表明UML在缺省情形下认为简单消息即为同步消息。 ③ 异步消息：消息源发出消息后不必等待消息处理过程的返回，即可继续执行自己的 后续操作。异步消息主要用于描述实时系统中的并发行为。异步消息在UML顺序图 中用一种特别的单向箭头表示。 ④ 返回消息： 表示前面发送的消息的处理过程完结之后的返回结果。返回消息应该是 同步的。在许多情况下，可以隐藏返回消息，但也可显式标出返回消息以示强调。 返回消息用虚线有向箭头表示，
协作图：描述相互合作的对象间的交互关系和链接关系，强调交互对象 间的静态链接关系。例：P234 图10.3
元素：现方案——提取边界类、 提取边界类、 提取边界类
实体类和控制类
边界类：用于描述目标软件系统与外部环境间的交互，功能：
① ② ③
界面控制：包括输入数据的格式及内容转换，输出结果的呈现，软件运行 过程中界面的变化与切换等。 外部接口：实现目标软件系统与外部系统或外部设备之间的信息交流和互 操作。主要关注跨越目标软件系统边界的通信协议。 环境隔离：将目标软件系统与操作系统、数据库管理系统、应用服务器中 间件等环境软件进行交互的功能与特性封装于边界类之中，使目标软件系 统的其余部分尽可能地独立于环境软件。
10.4 精化设计模型——精化类的属性和操作 精化类的属性和操作
10.4 精化设计模型——设计状态图 设计状态图
状态图适于表示跨越多个用例的单个对象的行为。 只需针对有明显的状态特征并且具有比较复杂的状 态-事件-响应行为的类设计状态图。 例：p252 图10.16
10.4 精化设计模型——设计活动图 设计活动图
避免包间的循环依赖关系 ② 在层次结构中，位于较低层次的通用包不应当依赖于较高层次中的 专用包。 ③ 在层次结构中，较高层次的包可以依赖于较低层次的包，但此种依 赖应尽量在相邻的层次间发生。 ④ 如果针对某些子系统专门划分了接口包和实现包，那么，其他与该 子系统相关的包只能依赖于接口包，不能依赖于实现包
10.2 设计技术支撑方案——数据持久存储服务 数据持久存储服务
目的：将目标软件系统中依赖于系统运行环境的数 据存取部分与其它部分相分离。 数据持久存储服务的设计包括：
定义数据格式 定义数据存取操作
10.2 设计技术支撑方案——并发与同步控制服务 并发与同步控制服务
目的：将目标软件系统中依赖于系统运行环境的并 发与同步控制部分和其他部分相分离。 功能：进程/线程的定义与启动、终止、状态查询、 同步点设置及其在同步点的信息交换等。
①
10.4 精化设计模型——精化类间关系 精化类间关系
详细研究类之间的关系：(1)-(3) p247 对象间实现消息传递的四种手段：
(1)-(4) p247 前三种具有暂时性：依赖关系；最后一种具有稳定性，可表示为： 构成关系、普通聚合关系、普通的关联关系
关联类：关联关系本身具有属性和操作，P247 图10.10 UML的依赖、聚合和构成关系的方向性很明显。对关联关 系，尽量将它单向化。进一步考虑对象间的数量对应关系 及对象在关联中扮演的角色。图10.11 面向重用的类结构调整：抽取公共父类，图10.12；类之 间建立单向的委托，图10.13 利用继承关系精化设计模型：引入父类 多继承化解为单继承，图10.14 按“强内聚、松耦合”、简单性、自然性等原则优化： p250
10.4 精化设计模型——精化类间关系 精化类间关系
10.4 精化设计模型——精化类间关系 精化类间关系
10.4 精化设计模型——精化类的属性和操作 精化类的属性和操作
属性的描述内容：名称、类型、初始值、取值范围、属性 说明（后三项可选） 操作的描述内容：名称、参数表（参数名称及类型）、返 回值类型、功能描述 属性和操作的作用范围：public, protected, private，原则： 尽量缩小作用范围，属性不宜公开 属性和操作可区分为类级和实例级 为了提高运行效率，有时需要在对象的生命周期中保存一 些中间结果，可引入导出属性作为类的私有属性。 设计模型精化的例子：p251 图10.15
先考虑数据持久存储服务 再考虑安全控制服务 最后考虑分布式事务管理、并发与同步控制、可靠消息等服务
技术支撑方案的类图与其它类图的融合：p243
如果前者比较简单，直接与其他类图合并，并建立公共技术服务类 与其他类之间的必要连接。 如果公共技术服务子系统中包含较多的服务类，它们应单独构成类 图，利用UML的包机制进行适当分组，并将这些包置于系统的体系 结构图中的较低层次。
10.2 设计技术支撑方案
应用功能往往都需要一组技术支撑机制为其提供服 务。 技术支撑方案是整个目标软件系统中全局性的公共 技术平台。 技术支撑方案应具有良好的稳定性、开放性、可扩 充性。 技术支撑方案的设计一方面取决于目标软件系统对 公共技术服务的需求，另一方面取决于设计人员对 软件技术手段的把握和选取。
10.0 基于 基于UML的OOD概述 的 概述
分析模型：顶层架构图、用例与用例图、领域概念模型。 设计模型：体系结构图、交互图、类图、状态图、活动图等。 任务：p231
① 针对分析模型用例，设计用UML交互图表示的实现方案。 ② 设计技术支撑设施。非业务需求的一部分，但却为多种业务需求的实现提供
实体类：表示目标软件系统中具有持久意义的信息项及其操作。 控制类：完成用例任务的责任承担者，协调、控制其它类共同完 成用例规定的功能或行为。 提取方法：