7.1 概述 7.2 系统 设计 过程度 7.3 不同设计用例实现方案 7. 3 精华设计模型

1. 第 7 章 面向对象的设计方法 7.1 概述 7.2 系统设计过程度 7.3 不同设计用例实现方案 7.3 精华设计模型

2. 面象对向的设计目标 设计分类 面向对象设计与分析 面向对象设计的基本原理 面向对象设计层次图 7.1 概述 面象对向的设计目标： 对面象对向的需求分析的无缝过度 设计模型包含以包图表示的软件体系结构图，以交互图表示的用例实现图、完整精确的类图、针对复杂对象的状态图及用以描述流程化处理过程的活动图。 面象对向的设计分类：产品设计和类设计 产品设计: 产品设计的目标是建立系统与外部实体，包括和用户、进程之间的有效交互。注重过程的体系结构、进程间的通信、用户界面及类/对象的存储。 类设计： 系统内部类的定义和它们间的关系。包括类的架构、属性、方法特征标记和语义。不直接与外部系统交互。如图

3. 远程进程 用户界面 外部结构 DBMS 类 类 远程文件 类 内部结构 数据处理软件的内部和外部结构图

4. 面向对象设计与分析 • 面向对象分析（OOA）与面向对象设计（OOD）有如下关系： 1）OOA识别和定义的类和对象，是一些直接反映问题空间和系统任务的，而OOD识别和定义对象则是附加，反映需求一种实现（对话层、任务管理层、数据管理层）。 2）OOA与OOD分别在不同的抽象层次上进行。OOA是独立于程序设计语言的，属于较高层次的抽象。初步的OOD同样在很大程度上与语言无关，但详细OOD则依赖于程序设计语言。 • 从非面向对象分析到面向对象设计，应将一个非面向对象的需求说明快速转变为面向对象分析模型。

5. 面向对象设计的基础—— OOA得出的概念和关系 • 抽象（过程，数据） • 封装 • 继承 • 消息 • 组织方法（对象和属性、类及成员、整体与部分） • 功能分类 • 组装结构 • 实例连接 • 消息连接

6. 面向对象设计的基本原理 1） 指出对象及其属性 2） 指出可能适用于对象的服务 3） 说明对象及服务 4） 确定将为对象提供实现描述的详细设计问题 5） 细化面向对象分析的工作，找出子类、消息 特性和其它详尽的细节 6） 表示与对象属性关联的数据结构 7） 表示与每个服务关联的过程细节

7. 7.2 系统设计 •划分子系统 •并发性设计 •任务管理设计 • 设计用例实现方案 •用户界面设计 • 数据管理设计 •系统间通信设计 • 使用设计模式 系统设计活动：

8. 划分子系统 划分子系统依据的基本概念原则： 所有元素共享某些公共性质 可能协同完成一个功能 可能驻留在一个硬件产品中 它们可能由相同的类管理资源 •子系统构成的是一种责任或服务 例如： 字处理文件管理 生成三维识图 压缩数字图像 等等 •服务完成特定的功能 •服务提供一组可标识的操作 •服务是分层提供的，层次与处理的外界可视性相关

9. 划分子系统 层次划分示意图例子 数据存储层 服务m 服务n ..... C/S形式 P2P形式 层的接口 服务I 服务J 服务K 数据准备层 ..... 层的接口 C/S形式 P2P形式 服务X 服务Y 服务Z 应用层 ..... C/S形式 P2P形式 层的接口 表示层 ..... 服务A 服务B 服务C 外界可视性

10. 划分子系统 C/S形式(Client/Server) P2P形式(Peer-to-Peer) 两种服务方式： 客户/服务器(Client/Server)方式： 客户请求服务，服务器承接服务并完成服务，返回服务结果。服务是被动的，客户是主动的。服务器不需要知道客户是谁，客户必须知道对应的服务器,呈现主从方式。 对等服务(Peer-to-Peer)方式： 每一方既是请求服务方也是接受服务方，都可以承接服务并可以请求服务，不分主从随需要扮演必要的角色,服务是双向流动的。

11. 分层设计步骤： 1)建立分层标准----怎样的层次组合方式 2)确定层次数量----层次总的数量要适中 3)层次命名----封装具有一致运行和管理模式的服务并命名 4)建立各层的内部结构----组织层内的服务访问方式 5)定义层接口----定义各层的交互方式和消息模式 6)评审设计----保证层之间的低耦合 7)迭代精化以上过程

12. 并发性设计 并发的概念: 各事务独立运作，执行顺序无依赖关系。 同步的概念: 各事务独立运作，但执行顺序相互制约。 对象都是并发存在的： 对象是在系统中各自独立的进程，是并发存在的，它们可以在同一个机器空间，也可以被分配到不同的机器空间 例如: 传感器对象 是相互独立的并发对象，它们的动作无依赖顺序，可同时活跃在系统中 SafeHome系统中的： 电话对象 控制面板对象

13. 并发性设计 关于控制线程概念：一组顺序执行的序列 一个控制线程中的并发对象操作： 在实际应用中，一组顺序执行的序列有可能是由若干对象的操作构成的，而这些对象有可能被分配到不同的机器空间。 机器X 对象B 操作bj ... 操作ai 操作bj 操作ck ... 并发设计必须考虑:机器X与Y之间的通讯处理开销及带来的成本 控制线程 机器Y 对象C 操作ck 对象A 操作ai

14. 并发性设计 一个控制线程中的并发对象操作例子 ..... ATM机器 ATM机器 联营计算机 营业部计算机 ATM机器 营业部计算机 营业部计算机 营业部计算机 业务对象 分理对应 营业部操作 业务对象 读密码操作 业务对象 密码验证操作 密码验证事务为同步方式 ..... 控制线程：  读密码  分理对应营业部  密码验证 密码验证事务为非同步方式

15. 任务管理设计 设计系统中分散的对象，组成为独立并发的任务（大粒度对象） 任务管理设计步骤: •确定任务的特征 •定义任务中所关联的对象 •集成任务中所关联的对象 任务初始化方式 任务优先级 任务关键度 任务名----任务对象名称 描述----任务目的叙述 优先级----低级、中级和高级 服务----任务的一组操作 协调----调用方式 通信----I/O方式

16. 设计技术支撑方案 设计技术支撑设施：包括在系统中，需要考虑的数据存储、安全性、远程登陆等内容。 技术支撑方案的设计： （1）取决于目标软件系统对公共技术服务的需求； （2）取决于设计人员对软件技术手段的把握和选取。 技术支撑方案应该为多个用例的软实现提供技术服务。所以，它应该成为整个目标软件系统中全局性的公共技术平台。当用户需求发生改变时，技术支撑平台应具有良好的稳定性。

17. 数据持久存储服务 设计数据持久存储服务的目的，是将目标软件系统中依赖于系统运行环境的数据存取部分于其它部分相分离。这样，既有利于软件的扩充、移植和维护，又简化了软件设计、编码和测试的过程。 数据持久存储服务的设计包括： （1）定义数据格式。根据目标软件系统对数据存储的要求，考虑持久存储介质的特性，设计数据的存储格式。 （2）定义数据存取操作。数据持久存储服务至少包含数据的存储和读取两种操作。 设计并发与同步控制服务的目的，是将目标软件系统中依赖于子系统运行环境的并发于同步控制部分和其它部分相分离，其它部分中有关并发与同步控制功能的实现均通过该服务来完成。 并发与同步控制服务

18. 数据管理设计 数据管理包括：管理对象属性和对应的属性操作 数据库系统的利用： 通常，数据库系统可作为对象实体的管理工具。对象实体可以被数据库管理系统直接查询、插入、删除和修改。但对应属性的复杂操作需要方法的实现。 数据管理设计方法： 数据属性的操纵 分离 高层需求 类方法的实现 对应 数据结构的操纵 数据库系统 低层需求

19. 数据管理设计 例如： 传感器类 编号方法 类型方法 性能方法 功能方法 ... 传感器属性的操纵 各传感器实例 实现集 对应 传感器结构的操纵 传感器文件 编号 类型 性能 ... ac-0013 ACPK 光敏感应 ... dc-0028 DCKH8 触点传导 ... ... ... ... ... 某数据库 管理系统 对应

20. 系统间通信设计 定义系统中服务之间的协作关系 系统中服务之间的协作关系：也叫做 “合约” 包括：消息格式、访问的登记、注册权限 合约 合约的形式和内容： •列出可被请求的服务 •制订合约履行的责任和操作 •建立合约表（协作表） •协作图描述 客户 子系统 请求 服务器 子系统 合约 合约 请求 服务器 子系统 服务器 子系统 请求 服务子系统之间协作模型

21. 系统间通信设计 在交互操作中，激活合约处理，查找协作表的合约来确定操作 建立合约表（协作表）： 约合 类型 协作者 类 操作 消息格式 协作图描述例子： •状态请求 •赋值区域 •测试状态 控制面板 子系统 传感器 子系统 •系统状态请求 •警告周期状态检查的类型说明 •请求警告通知 •根据需求周期检查配置修改 中心通信 子系统

22. 设计算法和数据结构 类的属性和操作是对应的，所有的操作都会作用于属性 操作的类型： 1）对属性数据的直接操作。例如：加入、去除、格式化、判断选择 2）完成某算法步骤的操作 3）监控某对象，等待某控制事件出现的操作 例如： •传感器类的“赋值”操作，将编号和类型赋给传感器的两个属性 •系统类的“编程”操作，将电话号码、警告延迟、主人密码装入系统 •系统类有“启动”和“关闭”系统的操作，将系统状态设为arm/disarm 发消息给相关的设备对象

23. 使用设计模式 在现代软件工程学中，设计要求尽量使用现有的设计模式 设计模式的刻画包括： •模式名字 •模式意图 •模式使用的条件、应对的问题和解决方案 •模式的类、责任和协作 •有效设计的原则 •例子和模板 •模式的交叉引用 黑盒方式是较好的模式复用方式 设计模式的两种机制： 继承----通过继承现存的设计模式，产生新的设计，原模式中的属性和操作也成为新模式中的一部分 复合----通过聚合现存对象，以及现存的聚合模式，形成新的设计模式（黑盒方式）

24. 用户界面设计 在需求分析阶段，要确定人机交互的属性和外部服务，而在设计阶段要给出有关人机交互的所有系统成分，包括用户如何操作系统、系统如何响应命令和系统显示信息的报表格式等。 用户界面设计的策略与步骤： （1）熟悉用户并对用户分类。 （2）按用户类别分析用户的工作流程与习惯。 （3）设计命令系统并进行优化。 （4）设计用户界面的各种细节。 （5）增加用户界面专用的类与对象。 （6）利用快速原型演示，改进界面设计。

25. 7.3不同设计用例实现方案 面向对象的设计方法，采用基于UML的面向对象设计方法，将分析模型转换为设计模型。这一转换过程需要完成： （1）针对分析模型中的用例，设计实现方案； （2）设计技术支撑设施。支撑设施包括在系统中，需要考虑的数据存储、安全性、远程登陆等内容。 （3）设计用户界面； （4）针对分析模型中的领域概念模型以及第（2）、（3）两个步骤引进新类，完整、精确地确定每个类的属性和操作，并完整地标示类之间的关系。

26. 面向对象的软件设计过程 用例描述及 用例图 设计用例实施方案 设计模型 领域概念模型 设计技术支撑方案 体系结构图 设计用户界面 用例实现图 分析模型 精化设计模型 类图 设计师 其它（状态图、活动图等）

27. 交互图：包括顺序图和合作图 • 交互图描述对象之间的动态合作关系以及合作过程中的行为次序。 • 交互图常常用来描述一个用例的行为，显示该用例中所涉及的对象以及这些对象之间的消息传递情况。 • 交互图有顺序图和合作图两种形式。

28. 顺序图：用来描述对象之间动态的交互关系，着重表现对象间消息传递的时间顺序。顺序图：用来描述对象之间动态的交互关系，着重表现对象间消息传递的时间顺序。 UML的消息类型： （1）简单消息（Simple Message）：用简单抽象的函数表示对象之间的信息传播。一般情况下，可以把简单消息看做同步消息。 （2）同步消息（Synchronous Message）：对象发出的消息，必须等待消息处理过程结束，才能进行后续操作。 （3）异步消息（Asynchronous Message）：对象发出的消息，不必等待消息处理过程结束，即可进行后续操作。 （4）返回消息（Return Message）：所发送消息的处理过程结束后的返回结果。 辅助参见书233页图

29. 合作图：用于描述相互合作的对象间的交互关系和链接关系。合作图：用于描述相互合作的对象间的交互关系和链接关系。 在合作图中，消息的内容包含名称、参数、返回值以及序列号，返回值和序列号都是可选的。 顺序图强调消息交互的时间序，而合作图则强调交互对象间的静态链接关系。 合作图中最常用的消息执行顺序的编号方案有两种： • 顺序法：用简单编号方案，从1开始，由小到大，顺序排列。 • 层次法：用小数点制编号方案，此时常常要求表示系统号、子系统号和模块号。UML使用了小数点方案。 辅助参见书234页图

30. 边界类、实体类和控制类 边界类：用于描述目标软件系统于外部环境之间的交互。通常在下面部分可能出现边界类： （1）界面接口。包括人机交互接口、输入/输出接口。 （2）外部接口。系统与外部系统、外部设备之间的数据传递和互操作。 （3）环境隔离。系统与数据管理、运行环境、网络服务等保持独立的部分。 实体类：表示目标软件系统中具有持久意义的信息项及其操作。通常只提供系统接口操作，并不涉及到系统业务逻辑流程。如异常事件、数据读写等。 控制类：用于协调、控制其它类共同完成用例规定的功能或行为。

31. 交互图的用例：订货系统 (1)订单提交窗口对象发送“prepare”消息给订单对象。 (2)订单对象发送“prepare”消息给订单上的每个订单项对象。 (3) 每个订单项检查其对应的仓库货物： • 如果检查结果为真，则订单项对象从对应的仓库货物中减去所订购的数量； • 否则，仓库要求一次新的进货。

32. 仓库货物 订单 订单项 订单提交窗口 prepare() 对象 * prepare() check() 条件 消息 迭代 [check=“false"] remove() needsToRecorder() 回授 返回 [needsToRecorder=“true”] new 进货货物 交付货物 [check=“true”] new 对象的生命线 创建 订货系统的顺序图

33. :订单提交窗口 对象 消息 1:prepare() 时序号 :订单 5:needsToRecorder() 3:check() 4:[check==false]remove() 2*:prepare() 回授 电视栏目:订单项 电视库存:仓库货物 7:[check==true]new 6:new :购进货物 :交付货物 简单编号方案的合作图

34. 小 结 • 顺序图突出对象的执行时序，合作图能更清楚地表示对象之间的静态连接关系。 • 交互图擅长显示对象之间的合作关系，尽管它并不对这些对象的行为进行精确定义。如要描述一个用例中几个对象协同工作的行为时，交互图是一种有力的工具。 • 虽然交互图能清楚地显示消息机制，但当消息中有太多的条件或循环时，交互图就失去其简明性。交互图仅适用于条件判断和循环不太多的时序过程。 • 当行为比较简单时，交互图比较好；当行为比较复杂时，则应使用活动图。 • 如果想描述跨越多个用例的单个对象的行为，应当使用状态图。如果想描述跨越多个用例或多个线程的复杂行为，则应使用活动图。 • 最基本的选择原则是用哪种图更简明清楚则选用哪种图。“越简明，价值越大”。

35. 7.4 精华设计模型 精化设计：就是对已经完成的静态结构模型（顶层框架图、类图）和动态行为模型（交互图）进行分析和优化，以生成高质量的设计模型。 对设计模型的精化需考虑如下任务： （1）以顶层架构图为基础，精华目标软件系统的体系结构； （2）精化类之间的关系； （3）精化类的属性和操作； （4）针对具有明显状态转换特征的类，设计状态图； （5）针对比较复杂的类方法，设计活动图。 状态图 • 状态图有多种形式，以基于 David Harel 的状态表方法在 OO 技术中最为流行。状态图描述系统对象的动态行为，一般描述一个特定对象在其生命周期中的所有可能状态以及由于各种事件的发生而引起的状态转移。

36. 状态语法和转移语法 • 状态之间的转移可带有标注，由三部分组成(每一部分都可省略)，其语法为： • 事件名 [条件] / 动作名 • 状态图中的状态包含一个活动，由两部分组成 (每一部分也都可省略)，其语法为： • do / 活动名 • 动作与活动都是一种过程，都由订单对象中的方法来实现，但动作与转移关联，处理较快且不会被中断；活动与状态关联，处理时间较长且可以被事件中断。

37. 状态的转移条件 • 转移中的事件表示输入条件：一个非真即假的逻辑判断。当且当条件为“真”时才发生转移。 • 当状态中的活动完成后，且当相应的输入事件发生时，转移才会发生；如转移上没有标明引发转移的事件，则表示状态中的活动一旦完成，转移立即发生。 • 在下例中，从检查状态出来三个转移，而且都标有条件。

38. 发货状态 检查状态 do/initiate delivery do/check item 转移 等待状态 实例：订单对象的状态图 开始 活动 事件名[条件]/动作名 /get first item [all items checked && all items available] 取下一项 [not all items checked] 收到货物 [all items available] [all items checked && some items not in stock] 发货 do/活动名 收到货物 [some items not in stock] 已发货 状态 状态 回授

39. 转移条件的互斥性 • 对于一个给定状态，只能产生一个转移。因此从相同状态出来的、事件相同的几个转移条件是互斥的。 • 图中列出了从检查状态引出的三个条件。 • 如没有检查完所有项，则取下一项并回到检查状态继续检查。 • 如已检查完所有项，且都有足够的货物，则转移到发货状态。 • 如已检查完所有项，但有一些项缺货，则转移到等待状态。

40. 基状态名 发货状态 发货状态 发货状态 检查状态 检查状态 do/initiate delivery do/initiate delivery do/check item do/check item 已发货 状态 已发货 状态 等待状态 取消状态 等待状态 取消状态 状态图的基状态表示法

41. 取消 状态 等待 状态 终点 检查 状态 发货 状态 已发货状态 付款确认 状态 已确认状态 拒绝 状态 并发状态图 起点

42. 并发状态图(续) • 并发状态图由两个或多个并发子图组成，每个子图叫作一个并发段。在任何时刻，一个对象的状态是每个并发段中各取一个状态的组合。当对象离开并发段后，它又恢复成一个单一的状态。 • 如果并发子图中的一个状态首先完成，它将首先转入下一个状态。但是，如果异常事件发生，则进入唯一的异常状态。 • 当一个对象有几个相互独立的行为时，并发状态图可以方便地刻画它的行为。但一个对象的并发行为不应太多；如果太多，应将其状态图分细。

43. 精化体系结构 继承关系：一个类的所有信息能被另一个类所共享的机制，就是继承。 基类 －属性 ＋方法 派生类1 派生类2 －属性 －属性 ＋方法 ＋方法 继承关系

44. 精化体系结构 依赖关系：用以描述两个模型元素（类、组合、用例等）之间的语义上的连接关系。 类A 类B <<友元>> －属性 －属性 ＋方法 ＋方法 依赖关系 精化体系结构 关联关系：表示消息传递通道在整个对象的生命周期中稳定存在，它是依赖关系的强化。 人 车 拥有 1..* 0..* －属性 －属性 被拥有 ＋方法 ＋方法 关联关系

45. 精化体系结构 聚集关系：表示消息传递通道在整个对象的生命周期中稳定存在，它是依赖关系的强化。 窗口 －属性 ＋方法 包含 0..* 0..* 0..* 0..* 文本框 列表框 菜单 按钮 －属性 －属性 －属性 －属性 ＋方法 ＋方法 ＋方法 ＋方法 聚集关系

46. 精化体系结构 精化类之间的关系 构成关系：构成关系是聚集关系的强化。 在已获取的类图的基础上，研究类之间的关系： （1）根据连接的语义强度，将它们精确地判定为UML的依赖、关联、聚合或构成关系之一。 （2）确定连接的方向及参与连接的类的对象之间的数量对应关系。 （3）根据软件重用的要求及软件结构简洁化、清晰化的要求，优化类之间的关系。 整体类 1 1 1…n 1…n 部件类1 部件类2 构成关系

47. 精化类之间的关系 例一 employee company 1..n 1..n 精化 －属性 －属性 employer employee ＋方法 ＋方法 employee company －属性 EmploymentHistory －属性 ＋方法 ＋方法 beginDate() endDate() 1 1 －属性 1..n 1..n EmploymentHistory beginDate() endDate() －属性

48. 精化类之间的关系例二 公共父类 设计模型中的类 commMachine 被重用的类 + dial() + hangup() + transmitVoice() Fax + dial() + hangup() + transmitVoice() + sendFax() + recvFax() －dialTone Telephone + dial() + hangup() + transmitVoice() Telephone Fax －dialTone －mode + sendFax() + recvFax() －dialTone －mode

49. 活动图基本概念 • 来源: 活动图主要来源于 Jim Odell 的事件图、SDL状态建模技术和 Petri 网技术。 • 活动图的核心符号是活动，通过连接将活动组成活动图。 • 从概念层看，活动表示需要由人或计算机来完成的任务。图中描述了“人找饮料喝”这一过程。 • 从说明层或实现层看，活动表示类中的方 法。图中描述了名字为“人”的对象类中一个关于“找饮料喝”的方法。

50. 判定活动 [没有咖啡] [没有可口可乐] 人 找饮料 [找到可 口可乐] 同步条件 [找到咖啡] 加水到 容器中 取出 咖啡杯 将咖啡放到 过滤器中 取一听 可口可乐 活动 把过滤器放到咖啡炉上 点燃 咖啡炉 熄灭咖啡炉 倒咖啡 终点 冲调咖啡 喝饮料 判断条件 活动图示例