第九章 面向对象的设计

1. 第九章 面向对象的设计 本章目标： 了解面向对象的分析的概念 了解如何应用UML建立需求分析模型 掌握以用例为中心的面向对象的分析方法。

2. 9.1 面向对象的设计概述 9.1.1 面向对象的设计目标 OOA的目标是理解需求并建立问题域的精确模型； OOD的描述一个计划好的系统，使之成为有效的实现蓝图。 在实际的软件开发过程中，界限是模糊的。

3. 类设计和产品设计 • 1）设计的分类 • 产品设计 • 目标是建立系统与外部实体，包括和用户、进程之间的有效交互。 • 注重过程的体系结构、进程之间的通信和用户界面。

4. 类设计 • 类设计是系统内部，类的定义以及它们之间的关系，包括类的架构、属性、方法、特征标记和语义。不直接与软件外部交互。

5. 2）产品设计目标 • 类、对象的存储，使对象持久化，有效地进行数据库存储。 • 设计系统体系结构，实现分布式协同计算和资源利用。 • 设计友好、有效的用户界面。

6. 9.1.2 面向对象设计的准则 前述的指导软件设计的几条基本原理，在面向对象方法中仍然成立，但具备了一些新特点。 1. 模块化：对象即模块； 2. 抽象：不仅支持过程抽象，而且支持数据抽象，某些面向对象的程序设计语言还支持参数化抽象； 3. 信息隐藏：封装； 4. 弱耦合：不同对象之间相互关联程度降到最低程度； 5. 强内聚： 3种内聚-服务内聚、类内聚、一般-特殊内聚； 6. 可重用。

7. 9.1.3 启发规则 帮助提高面向对象设计质量的经验。 1. 设计结果应该清晰易懂 2. 一般-特殊结构的深度应适当 3. 设计简单的类 4. 使用简单的协议5. 使用简单的服务 6. 把设计变动减至最小

8. 1. 设计结果应该清晰易懂 （1） 用词一致 （2） 使用已有的协议 （3） 减少消息模式的数目 （4） 避免模糊的定义

9. 2. 一般-特殊结构的深度应适当 应该使类等级中包含的层次数适当。 一般说来，类等级层次数应保持为7±2。 应该使一般-特殊结构与领域知识或常识保持一致。

10. 3. 设计简单的类 尽量设计小而简单的类，以便于开发和管理。 (1) 避免包含过多的属性 (2) 有明确的定义 (3) 尽量简化对象之间的合作关系 (4) 不要提供太多服务

11. 4. 使用简单的协议 一般，消息中的参数不要超过3个。 因为通过复杂消息相互关联的对象是紧耦合的，对一个对象的修改往往导致其他对象的修改。

12. 5. 使用简单的服务 应尽量避免使用复杂的服务。 如果需要在服务中使用CASE语句，通常应该考虑用一般-特殊结构代替这个类的可能性。

13. 6. 把设计变动减至最小 即使出现必须修改设计时，也应使修改的范围尽可能小。

14. 9.2 对象的存储-----数据管理部分的设计 • 对象存储又被称为数据管理部分是指将对象描述的信息存放在存储设备上，以便于长期维护，持久保存；提供了在数据管理系统中存储和检索对象的基本结构，包括对永久性数据的访问和管理。 • 它分离了数据管理机构所关心的事项，包括文件、关系型DBMS或面向对象DBMS等。

15. 9.2.1 对象存储方法-----数据管理方法 • 文件管理、关系数据库管理和面向对象库数据管理。 • 1、对象流或对象序列 • 对象流技术，存放到文件并在文件中重建对象。 • 2、数据库 • 常规的RDBMS • 3、面向对象的数据库 • OORDBMS

16. 面向对象数据库管理系统──通常，面向对象的数据库管理系统以两种方法实现：一是扩充的RDBMS，二是扩充的面向对象程序设计语言。面向对象数据库管理系统──通常，面向对象的数据库管理系统以两种方法实现：一是扩充的RDBMS，二是扩充的面向对象程序设计语言。 • 扩充的RDBMS主要对RDBMS扩充了抽象数据类型和继承性，再加一些一般用途的操作创建和操纵类与对象。 • 扩充的OOPL在面向对象程序设计语言中嵌入了在数据库中长期管理存储对象的语法和功能。

17. 9.2.2 对象序列化 • 利用面向对象的开发语言提供的对象流技术， • 文件管理──提供基本的文件处理能力。

18. 9.2.3 选择数据存储管理模式 • 1、文件管理系统 • OS的一部分，成本低、简单；但文件操作的级别低，为提供适当的抽象级别还必须编写额外的代码；不同OS的的FMS差异大。

19. 2、RDBMS • 关系数据库管理系统提供了各种基本的数据管理功能；为多种应用提供了一致的接口；标准语言SQL；使用若干表格来管理数据。 • 运行开销大；数据结构简单；面向集合的操作-非过程性的语言。

20. 3、OODBMS • 通过扩展RDBMS和扩展OOPL实现 • 扩展RDBMS：在RDBMS的基础上，增加了抽象数据类型和继承机制，增加创建和管理类/对象的服务。 • 扩展OOPL：扩充OOPL的语法和功能，增加在数据库中存储和管理对象的机制。

21. 9.2.4 设计数据管理子系统 • 1、设计数据格式 • 与所使用的数据存储管理模式密切相关。 • 文件系统、RDBMS、OORDBMS。 • 2、设计相应的服务 • 对于需要存储的类/对象，增加一个属性和服务，用于完成存储对象自身的工作并作为隐含的属性和服务。

22. 9.3 类设计 • 根据分析阶段得出的场景和类图，画出对象图和交互图； • 加入类的细节，包括类的属性、方法，组成类的架构。

23. 9.3.1 类架构 • 类架构包括： • 类的作用角色； • 何时创建和删除； • 类的每个作用所对应的语义； • 带有前置和后置条件的构造函数； • 方法的特征标记、语义、前置和后置条件。

24. 类框架 • Delphi 类 • Type 类名 =class (基类) • {数据成员声明：字段、域} • {过程和函数声明：方法，执行类的操作，完成类的任务} • {属性的声明：访问数据对象的接口} • End;

25. 9.3.2 系统分解 • 把系统模型分解到可以实现的地步。

26. 9.3.4 交互图 • 类图描述系统的静态结构，交互图描述系统的动态信息。指出产生某个行为所需类的交互。 • UML中的顺序图、协作图。

27. 9.4 类设计的目标及其验证 • 代码重用 • 设计良好的类和方法 • 数据完整性保证

28. 9.4.1 代码重用 • 面向对象技术通过类的封装机制，为软件重用提供强有力的支持。 • 与函数库对应，很多面向对象语言为应用程序开发者提供了易于使用的类库，如VC++中的MFC。

29. 1 通过复用设计类 • 根据解决问题的需要，从类库或其它来源得到的既存类增加到问题解决方案中去。 • 标明既存类中不需要的属性和操作， • 增加从既存类到应用类之间的一般化-特殊化的关系。 • 把应用类中因继承既存类而成为多余的属性和操作标出。 • 修改应用类的结构和连接。

30. 四种方式 • 利用既存类来设计类，有4种方式：选择，分解，配置和演变。 • 选择 • 设计一个类最简单的服务是从既存的部件中简单地选择合乎需要的软件部件。

31. 部件库 • 一个面向对象开发环境应提供一个常用部件库。 • 大多数语言环境都带有一个初始部件库，如整数、实数和字符，它是提供其它所有功能的基础层。 • 任一基本部件库(如“基本数据结构”部件)都应建立在这些原始层上。 • 这个层还包括一组提供其它应用论域方法的一般类，如窗口系统和图形图元。

32. 一个面向对象部件库的层次 • 特定组的部件 (一个小组为他们自己组内所有成员使用而开发) • 特定项目的部件 (一个小组为某一个项目而开发) • 特定问题论域的部件 (购自某一个特定论域的软件销售商) • 一般部件 (购自专门提供部件的销售商) • 特定语言原操作 (购自一个编译器的销售商)

33. 分解 • 最初标识的“类”常常是几个概念的组合。在着手设计时，必须把一个类分成几个类，希望新标识的类容易实现，或它们已经存在。 • 配置 • 在设计类时，我们可能会要求由既存类的实例提供类的某些特性。通过把相应类的实例声明为新类的属性来配置新类。

34. 一种仿真服务器可能要求使用一个计时器来跟踪服务时间。设计者应当找到计时器类，并在服务器类的定义中声明它。一种仿真服务器可能要求使用一个计时器来跟踪服务时间。设计者应当找到计时器类，并在服务器类的定义中声明它。 • 这个服务器还要求有一个队列类的实例来作客户排队工作。 • 对每一个客户的服务时间由一个已知的概率分布来确定，因此，可能使用一个具有泊松分布或具有均匀分布的随机变量的类的实例。

35. 演化 • 要求开发的新类可能与一个既存类非常类似，但不完全相同。此时，可以利用继承机制。一般化-特殊化处理有三种可能的方式。

36. 9.4.2良好设计的类和方法 • 良好设计的类和方法指南： • 保持数据的私有化； • 在构造函数内初始化数据； • 不使用太多的相关联的原始数据类型； • 一致排列类的元素； • 有意义地命名。

37. 9.4.3 数据完整性保证 • 在独立事务或方法调用中更新相关联的数据时会产生潜在的问题，为维护数据的完整性，必须同时更新多重数据。 • 安全性设计。

38. 9.4.4 类设计的验证 • 类设计的验证的目的： • 保证OOA的需求在设计中进一步被细化； • 保证所有需要的类成员都被适当地使用； • 保证系统的独立构件在一起正确地工作。

39. 9.5 设计类中的服务 • OOA中的对象模型没有详细描述类中的服务，OOD是扩充、完善、细化对象模型的过程，设计类中的服务是其中的重要内容。 • 包括确定类中服务和实现服务的方法

40. 9.5.1确定类应有的服务 • 需要综合考虑对象模型、动态模型和功能模型，才能正确确定类中应有的服务。 • 将动态模型中对象的行为以及功能模型中的数据处理，转换成由适当的类所提供的服务。

41. 动态模型中的状态图的状态转换是执行对象服务的结果。动态模型中的状态图的状态转换是执行对象服务的结果。 • 对象的动作既与事件有关，也与对象的状态有关。 • 功能模型指明了系统必须提供的服务，状态图中状态转换所触发的动作可能扩展成数据流图。数据流图中的某些处理可能与对象提供的服务相对应。

42. 若干规则 • 1、当处理的功能是从输入流中抽取一个值，则该输入流就是目标对象。 • 2、当处理的具有类型相同的输入流和输出流，且输出流实质上是输入流的另一种形式，则该输入输出流就是目标对象。

43. 3、当处理从多个输入流得出输出值，则该处理是输出类中定义的一个服务。3、当处理从多个输入流得出输出值，则该处理是输出类中定义的一个服务。 • 4、当处理把对输入流处理的结果输出给数据存储或动作对象，则该数据存储或动作对象流就是目标对象。

44. 9.5.2 设计实现服务的方法 • 1、设计实现服务的算法 • 注意算法复杂度，便于理解和实现，易修改。 • 2、选择数据结构 • 方便、有效。 • 3、定义内部类和内部操作 • 引入新的底层操作分解高层操作。

45. 9.6 设计人机交互子系统----用户界面设计 • OOA中对用户界面做了初步分析; • OOD阶段必须对此进行详细的设计; • 根据需求把人机交互的细节加入到用户界面设计中，包括人机交互所必需的实际显示和输入。

46. 1. 用户分类 • 按技能层次分类： 外行／初学者／熟练者／专家 • 按组织层次分类： 行政人员／管理人员／专业技术人员／其它办事员 • 按职能分类： 顾客／职员

47. 2. 描述人及其任务的脚本 • 对以上定义的每一类用户，列出对以下问题做出的考虑：什么人、目的、特点、成功的关键因素、熟练程度以及任务脚本。 • 在OOATOOLTM 中有一个例子： • 什么人──分析员 • 目的──要求一个工具来辅助分析工作 (摆脱繁重的画图和检查图的工作)。

48. 特点──年龄：42岁；教育水平：大学；限制：不要微型打印，小于9个点的打印太小。特点──年龄：42岁；教育水平：大学；限制：不要微型打印，小于9个点的打印太小。 • 成功的关键因素──工具应当使分析工作顺利进行；工具不应与分析工作冲突；工具应能捕获假设和思想，能适时做出折衷；应能及时给出模型各个部分的文档，这与给出需求同等重要。 • 熟练程度──专家。

49. 任务脚本── • 主脚本： • 识别“核心的”类和对象； • 识别“核心”结构； • 在发现了新的属性或操作时随时都可以加进模型中去。 • 检验模型： • 打印模型及其全部文档。

50. 3. 设计命令层 • 研究现行的人机交互活动的内容和准则：这些准则可以是非形式的，如“输入时眼睛不易疲劳”，也可以是正式规定的； • 建立一个初始的命令层：可以有多种形式，如一系列 Menu Screens、或一个Menu Bar、或一系列Icons. • 细化命令层：考虑以下几个问题。