Presentation Transcript

1. 软件工程 第十章 面向对象的设计方法 授课教师：李梁 联络电话：68668334 电子邮件：iliang@cqit.com.cn

2. 第十章 面向对象的设计方法 • OOD面向对象设计概述 • 面向对象设计 • 主体部件设计（PDC：高层设计） • 用户界面部件设计（HIC） • 任务管理部件设计（TMC） • 数据管理部件设计（DMC） • 基于对象的设计方法

3. §8.1 面向对象设计概述 数据 客观世界的 对象和操作 结果 问题空间 客观世界 的对象 程序员对 问题的表达 客观世界的算法空间 计算机算法 程序设计语言 的对象和操作 输出数据 解空间 • 对象、操作、消息 类、实例和继承 • 对象描述（对象名及所属对象类，私有数据结构的每一数据项及类型，每个操作的过程描述或指向该过程描述的指针）

4. §8.2 面向对象设计方法 OOD在设计阶段中继续采用分析阶段中提到的五个层次。这五个层次用于建立系统的四个组成成份。 • OOA分析阶段 OOD设计阶段 • 定义主题 主题层 • 标识对象 类和对象层 • 标识对象所属类 结构层 • 标识对象的属性 属性层 • 标识对象的行为 服务层

5. 1、主体部件（PDC）设计 • 主体部件是构造应用软件的总体模型（结构），是标识和定义模块的过程。模块可以是一个单个的类，也可以是由一些类组合成的子系统。 • 主体部件设计阶段标识在计算机环境中进行问题解决工作所需要的概念，并增加了一批需要的类。 • 主要是可使应用软件与系统的外部世界交互的类 • 此阶段的输出是适合应用要求的类、类间的关系、应用的子系统视图规格说明。 1.1 主体部件设计的任务 • 设计包括与应用问题直接有关的所有类和对象。 • 对OOA模型中的某些类与对象、结构、属性、操作进行组合与分解。进而进行改进和增补 • 要考虑对时间与空间的折衷、内存管理、开发人员的变更、以及类的调整等。

6. 主体部件设计模型

7. 1.2 主体部件设计应遵循的原则 • 使在子系统的各个高层部件之间的通信量达到最小； • 子系统应当把那些成组的类打包，形成高度的内聚； • 逻辑功能分组，提供一个逻辑功能一个单元，识别并定位问题事件； 1.3 主体部件设计和类设计关系 • 每个子系统都可以被当做一个类来实现，这个类聚集它的部件，提供了一组操作。 • 类和子系统的结构是正交的，一个单个类的实例可能是不止一个子系统的一部分。 • 主题部件设计和类设计这两个阶段是相对封闭的，又是相互连接的。

8. 1.4 复用设计：尽量使用已有的类库中既存类 • 根据问题解决的需要，把从类库或其它来源得到的既存类增加到问题解决方案中去。 • 标明既存类中不需要的属性和操作， • 增加从既存类到应用类之间的继承的关系。 • 把应用类中因继承既存类而成为多余的属性和操作标出。 • 修改应用类的结构和连接。 1.5 引入新“父类”，分组管理系统相关类 • 在设计时，从类库中引进一个根类，做为容器类，把所有与问题论域有关的类关联到一起，建立类的层次。 • 把同一问题论域的一些类集合起来，存于类库中。

10. 1.6 引入新父类捕获共性，简化软件设计和编码 • 有时，某些特殊类要求一组类似的服务。 • 此时，应加入一个一般化的类和其父类，“一般化的类”定义为所有这些特殊类共用的一组服务名，这些服务都是虚函数。输入站：ATM+柜员终端，可以设计一个一般化类：“基本业务” • 在特殊类中定义其实现。 1.7 调整继承支持级别 • OOA阶段建立的对象模型中可能包括有多继承关系，但实现时使用的程序设计语言可能只有单继承，甚至没有继承机制，这样就需对分析的结果进行修改。 • 多继承模式有两种： 狭义的菱形 广义的菱形

12. 针对单继承语言的调整 • 把特殊类的对象看做是一个一般类对象所扮演的角色，通过实例连接把多继承的层次结构转换为单继承的层次结构。 • 把多继承的层次结构平铺，成为单继承的层次结构。在这种情况下，有些属性或操作在同层的特殊类中会重复出现。

13. 汽车 1+ 货运 客运 汽车用途 汽车 汽车用途 平铺 汽车 汽车用途 货运 客运 单继承 货运 客运 汽车用途 货运 客运 单一层次单继承 多继承 • 针对无继承语言的调整 • 当使用无继承的程序设计语言时，必须把具有继承关系的类层次结构平铺开，成为一组类和对象。 • 一般可利用命名惯例，把这些类或对象关联起来。

14. 针对无继承语言的调整 • 当使用无继承的程序设计语言时，必须把具有继承关系的类层次结构平铺开，成为一组类和对象。 • 一般可利用命名惯例，把这些类或对象关联起来。 1.9 改进性能 • 提高执行效率和速度是系统设计的主要指标之一。有时，必须改变问题论域的结构以提高效率。 • 如果类之间经常需要传送大量消息，可合并相关的类以减少消息传递引起的速度损失。 • 增加某些属性到原来的类中，或增加低层的类，以保存暂时结果，避免每次都要重复计算造成速度损失。

16. 1.10 加入较低层的构件 • 在做面向对象分析时，分析员往往专注于较高层的类和对象，避免考虑太多较低层的实现细节。 • 在做面向对象设计时，设计师在找出高层的类和对象时，必须考虑到底需要用到哪些较低层的类和对象。 2、用户界面部分的设计 • 在 OOA 阶段给出了所需的属性和操作， • 在设计阶段必须根据需求把交互细节加入到用户界面设计中，包括人机交互所必需的实际显示和输入。 • 用户界面部分设计主要由以下几个方面组成。

17. 2.1 用户分类 • 按技能层次分类： 外行／初学者／熟练者／专家 • 按组织层次分类： 行政人员／管理人员／专业技术人员／其它办事员 • 按职能分类： 顾客／职员 2.2 描述人及其任务的脚本 • 对以上定义的每一类用户，列出对以下问题做出的考虑：什么人、目的、特点、成功的关键因素、熟练程度以及任务脚本。 • 在OOATOOLTM 中有一个例子： • 什么人──分析员 • 目的──要求一个工具来辅助分析工作 (摆脱繁重的画图和检查图的工作)。

18. 特点──年龄：42岁；教育水平：大学；限制：不要微型打印，小于9个点的打印太小。特点──年龄：42岁；教育水平：大学；限制：不要微型打印，小于9个点的打印太小。 • 成功的关键因素──工具应当使分析工作顺利进行；工具不应与分析工作冲突；工具应能捕获假设和思想，能适时做出折衷；应能及时给出模型各个部分的文档，这与给出需求同等重要。 • 熟练程度──专家。 • 任务脚本── • 主脚本： • 识别“核心的”类和对象； • 识别“核心”结构； • 在发现了新的属性或操作时随时都可以加进模型中去。 • 检验模型： 打印模型及其全部文档。

19. 2.3 设计命令层 • 研究现行的人机交互活动的内容和准则：这些准则可以是非形式的，如“输入时眼睛不易疲劳”，也可以是正式规定的； • 建立一个初始的命令层：可有多种形式，如一系列 菜单、或一个窗口、或一系列图标. • 细化命令层：考虑以下几个问题。 • 排列命令层次。把使用最频繁的操作放在前面；按照用户工作步骤排列。 • 通过逐步分解，找到整体－局部模式，以帮助在命令层中对操作分块。 • 根据人们短期记忆的“7±2”或“每次记忆3块／每块3项”的特点，把深度尽量限制在三层之内。 • 减少操作步骤：把点取、拖动和键盘操作减到最少。

20. 2. 4 设计详细的交互 • 用户界面设计有若干原则，包括： • 一致性：采用一致的术语、一致的步骤和一致的活动。 • 操作步骤少：减少敲键和鼠标点取的次数，减少完成某件事所需的下拉菜单的距离。 • 不要“哑播放”：每当用户等待系统完成一个活动时，要给出一些反馈信息。 • Undo：在操作出现错误时，要恢复或部分恢复原来的状态。 • 减少人脑的记忆负担：不应在一个窗口使用在另一个窗口中记忆或写下的信息；需要人按特定次序记忆的东西应当组织得容易记忆。 • 学习的时间和效果：提供联机的帮助信息。 • 趣味性：尽量采取图形界面，符合人类习惯。

21. 2. 5 继续做原型 • 用户界面原型是用户界面设计的重要工作。人需要对提交的人机交互活动进行体验、实地操作，并精炼成一致的模式。 • 使用快速原型工具或应用构造器，对各种命令方式，如菜单、弹出、填充以及快捷命令，做出原型让用户使用，通过用户反馈、修改、演示的迭代，使界面越来越有效。 2. 6 设计 HIC (人机交互) 类 • 窗口需要进一步细化，通常包括：类窗口、条件窗口、检查窗口、文档窗口、画图窗口、过滤器窗口、模型控制窗口、运行策略窗口、模板窗口等。 • 设计HIC类，首先从组织窗口和部件的用户界面界面的设计开始。 • 每个类包括窗口的菜单条、下拉菜单、弹出菜单的定义。还要定义用于创建菜单、加亮选择项、引用相应响应的操作。

22. 2. 7 根据图形用户界面进行设计 • 图形用户界面区分为字型、坐标系统和事件。 • 字型是字体、字号、样式和颜色的组合。 • 坐标系统主要因素有原点(基准点)、显示分辨率、显示维数等。 • 事件则是图形用户界面程序的核心，操作将对事件做出响应。 3 任务管理部分的设计：将重要的服务设计成任务类 • 任务是进程的别称，是执行一系列活动的一段程序。 • 当系统中有许多并发行为时，需要依照各个行为的协调和通信关系，划分各种任务，以简化并发行为的设计和编码。 • 任务管理主要包括任务的选择和调整，它的工作有以下几种。

23. 识别事件驱动任务：一些负责与硬件设备通信的任务是事件驱动的，这种任务可由事件来激发。插卡（任务处于睡眠状态，接受中断唤醒）识别事件驱动任务：一些负责与硬件设备通信的任务是事件驱动的，这种任务可由事件来激发。插卡（任务处于睡眠状态，接受中断唤醒） • 识别时钟驱动任务：以固定的时间间隔激发这种事件，以执行某些处理。某些人机界面、子系统、任务、处理机或与其它系统需要周期性的通信，因此时钟驱动任务应运而生。超时提示 • 识别优先任务和关键任务：根据处理的优先级别来安排各个任务。 • 识别协调者：当有三个或更多的任务时，应当增加一个追加任务（新类，将不同任务中的协调部分封装起来形成）。它的行为可以用状态转换矩阵来描述。结息 • 评审各个任务：对各任务进行评审，确保它能满足选择任务的工程标准─事件驱动？时钟驱动？优先级/关键任务？协调者？

24. 定义各个任务 • 定义任务的工作主要包括：它是什么任务、如何协调工作及如何通信。 (1) 它是什么任务──为任务命名，并简要说明这个任务。 (2) 如何协调工作──定义各个任务如何协调工作。指出它是事件驱动还是时钟驱动。 (3) 如何通信──定义各个任务之间如何通信。任务从哪里取值，结果送往何方。 (4) 一个模版──任务的定义如下： • Name (任务名) • Description (描述) • Priority (优先级) • Servicesincluded (包含的操作)、 • Communication Via (经由谁通信)。

25. 4 数据管理部分的设计 • 数据管理部分提供了在数据管理系统中存储和检索对象的基本结构，包括对永久性数据的访问和管理。 • 它分离了数据管理机构所关心的事项，包括文件、关系型DBMS或面向对象DBMS等。 • 数据管理方法：文件管理、关系数据库管理和面向对象库数据管理。 • 文件管理──提供基本的文件处理能力。 • 关系数据库管理系统──关系数据库管理系统使用若干表格来管理数据。 • 面向对象数据库管理系统──面向对象的数据库管理系统以两种方法实现：一是扩充RDBMS，二是扩充OOPL。 • 扩充RDBMS主要对RDBMS扩充了抽象数据类型和继承性，再加一些一般用途的操作创建和操纵类与对象。 • 扩充OOPL在面向对象程序设计语言中嵌入了在数据库中长期管理存储对象的语法和功能。

26. 设计要点： • 增加对象服务类（通知保存对象自身、检索已储存的对象：查找、读值、创建、初始化对象，以便其他子系统使用这些对象） • 例ATM系统 • 唯一的永久性数据存放在分行计算机中，因此必须保持数据的一直性和完整性，因有许多并发操作，因此应使用RDBMS方式进行数据管理 • 主要存储对象：账户类对象 • 设计“对象服务”类，该类提供以下服务： • 所有账户类对象接到“存储自己”的通知后，向RDBMS发送信息（SQL），保存对象自身或保存需长期保存的对象的状态（如透资卡） • 检索已存储的对象使之“复活”

27. §8.3 类设计 • 应用分析过程包括了对问题论域所需的类的模型化，但在最终实现应用时不只有这些类，还需要追加一些类。在类设计的过程中应当做这些工作。 1、类设计的目标 • 单一概念的模型 • 使用多个类来表示一个“概念”。 • 常常把一个概念进行分解，用一组类来表示这个概念。 • 也可只用一个单个类来表示一 个概念。 • 在类的文档中应对类的用途做出清楚的标识和精确的陈述，类的共有界面应当使用操作的特征、先决条件和后置条件加以定义。

28. 可复用的“插接相容性”部件 • 部件可以在未来的应用中使用。 • 界面的标准化 • 类的“插接相容性” • 可靠的部件 • 可靠的(健壮的和正确定义的)部件。 • 每个部件必须经过充分的测试。 • 每个操作尽可能小和作用单一。 • 可集成的部件 • 类的界面应当尽可能小 • 一个类所需要的数据和操作都定义在类定义中 • 避免命名冲突 • 封装特性保证了把一个概念的所有细节都组合在一个界面下 • 信息隐蔽保证了实现级的名字将不会与其它类的名字互相干扰。

29. 直接引用类中的数据 2 、类设计的方针 • 信息隐蔽 • 保护抽象数据类型的存储表示不被抽象数据类型实例的用户直接存取。 • 对其表示的唯一存取途径只能是界面。 Point Point 引用 x y 引用 data.x data.y public: create( ); print( ); int x; int y; public: create( ); print( ); struct { int x; int y; } data;

30. 通过界面引用类中的数据 Point Point 引用 get_x( ); get_y( ); set_x( ); set_y( ); 引用 get_x( ); get_y( ); set_x( ); set_y( ); public: create( ); print( ); get_x( ); get_y( ); set_x( ); set_y( ); public: create( ); print( ); get_x( ); get_y( ); set_x( ); set_y( ); private: int x; int y; struct { int x; int y; } data;

31. 消息限制 • 避开直接引用另一个类的数据 • 类A的数据表示中包括了类C的实例，类B的数据表示则直接使用了类C。如果类A的实例发送一个消息给类B的一个实例，则类A必须知道类B的实现是如何使用类C的实例的，并把这种知识包括到它自己的实现中去。当类B需要改变自己的实现，改动类C的数据表示时，类A的实现也必须随之改变。

32. 类间的相互作用

33. 狭窄界面 • 不是所有的操作都是公共的。 • 对于一个HashTable类，界面应包括插入和检索表的操作，而不应包括使用一个表项的关键码计算散列值的操作。散列函数不应由类的实例的用户来访问。它应是一个单独的操作，以便容易调整或改变散列函数，它应是隐蔽实现的部分。 • 强内聚 • 模块内部各个部分之间应有较强的关系，它们不能分别标识。 • 弱耦合 • 一个单独模块应尽量不依赖于其它模块。如果在类A的实例中建立了类B的实例，类A的操作需要类B的实例做为参数，如果类A是类B的一个派生类，则称类A“依赖于”类B。一个类应当尽可能少地依赖于其它类。

34. 显式信息传递 • 在类之间全局变量的共享隐含了信息的传递，并且是一种依赖形式。因此，两个类之间的交互应当仅涉及显式信息传递。 • 显式信息传递是通过参数表来完成的。借助于显式地列出将要通过参数表传递给一个操作的值，可以循特定的路径来跟踪错误。 • 显式信息传递要最小化 • 派生类当做派生类型 • 在继承结构中，每个派生类应该当做基类的特殊化来开发，而基类所具有的公共界面成为派生类的共有界面的一个子集。 • C++允许设计者选择类的基类是共有的或私有的。 • 如果基类是共有的，则其共有界面将成为新的派生类的共有界面部分，这类似于类型与派生类型之间的关系。

35. 如果基类是私有的，它的行为将不是派生类的公共行为部分而是实现部分。它的提出是为了提供实现新类的服务。如果基类是私有的，它的行为将不是派生类的公共行为部分而是实现部分。它的提出是为了提供实现新类的服务。 • 在实现一个新类时通过声明一个类的实例，就可以使得该类的服务有效。 • Dictionary类的实现可采用Array类的实例，这样可以把存储提供给Dictionary项，而不给Dictionary类的界面增加不适当的操作。 • 抽象类 • 某些语言提供了一个类，用它做为继承结构的开始点，所有用户定义的类都直接或间接以这个类为基类。 • C++支持多重继承结构。每一种结构都包含了一组类，它们是某种概念的特殊化。这个概念应抽象地由结构的根类来表示。因此，每个继承结构的根类应当是目标概念的一个抽象模型。

36. 这个抽象模型起始于一个根类，它不产生实例。它定义了一个最小的共有界面，许多派生类可以加到这个界面上以给出概念的一个特定视图。这个抽象模型起始于一个根类，它不产生实例。它定义了一个最小的共有界面，许多派生类可以加到这个界面上以给出概念的一个特定视图。 • 考虑一组涉及 “List” 概念的类，根类应提供一组操作做为界面而不考虑是什么表。这个抽象类可以提供某些操作的缺省实现，但在派生类中将根据特殊化要求给出特定实现。 3、通过复用设计类 • 利用既存类来设计类，有4种方式：选择，分解，配置和演变。 • 选择 • 设计一个类最简单的服务是从既存部件中简单地选择合乎需要的软件部件。

37. 部件库 • 一个面向对象开发环境应提供一个常用部件库。 • 大多数语言环境都带有一个初始部件库，如整数、实数和字符，它是提供其它所有功能的基础层。 • 任一基本部件库(如“基本数据结构”部件)都应建立在这些原始层上。 • 这个层还包括一组提供其它应用论域方法的一般类，如窗口系统和图形图元。 • 一个面向对象部件库的层次 • 特定组的部件(一个小组为他们自己组内所有成员使用而开发) • 特定项目的部件(一个小组为某一个项目而开发) • 特定问题论域的部件(购自某一个特定论域的软件销售商) • 一般部件(购自专门提供部件的销售商) • 特定语言原操作 (购自一个编译器的销售商)

38. 分解 • 最初标识的“类”常常是几个概念的组合。在着手设计时，必须把一个类分成几个类，希望新标识的类容易实现，或它们已经存在。 • 配置 • 在设计类时，我们可能会要求由既存类的实例提供类的某些特性。通过把相应类的实例声明为新类的属性来配置新类。 • 一种仿真服务器可能要求使用一个计时器来跟踪服务时间。设计者应当找到计时器类，并在服务器类的定义中声明它。 • 这个服务器还要求有一个队列类的实例来作客户排队工作。 • 对每一个客户的服务时间由一个已知的概率分布来确定，因此，可能使用一个具有泊松分布或具有均匀分布的随机变量的类的实例。

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

40. 预习内容：第十二章 • 作业： • P194 10.2、10.9、10.10