软件工程-第九章-面向对象设计

1、软件工程软件工程 Software Engineering 第九章第九章 面向对象设计面向对象设计 l提取了用户需求，建立了问题域模型后，系统 分析的任务基本完成。下一步则是将分析的成 果用于设计当中。 l从面向对象分析到面向对象设计，是一个逐渐 扩充模型的过程。分析处理以问题为中心，设 计则是面向计算机的“实现”开发活动。 l相对于传统方法中，从数据流图到结构图的变 化突然而不连续，分析人员很在跟踪整个设计 过程，而面向对象方法学保证了在各个开发阶 段之间的平滑过渡，这是面向对象方法与传统 方法相比起来所具有的一大优势。 9.1 设计的准则设计的准则 l综合考虑各种因素，使得在整个软件生命周

2、期 总开销最小的设计，就是一个优秀的设计。鉴 于目前软件维护占了整个软件总费用的60%以 上。所以，维护的简易性成为优秀软件设计的 主要特点。 l9.1.1 转向面向对象的设计 分析阶段给出了一个基于面向对象的软件开发模 型，现在是增加各种组成部分以扩充这个模型。 具体来说，面向对象分析（OOA）与面向 对象设计(OOD)有如下一些关系： OOA识别和定义的类和对象，是一些直接反映问题 空间和系统任务的；而OOD识别和定义的对象则是 附加的，反映需求的一种实现。 OOA与OOD分别在不同的抽象层次上进行。OOA是 独立于程序设计语言的，属于较高的抽象层次的。 但详细OOD则一般都会依赖于程序设

3、计语言，属于 较低的抽象层次。 从非面向对象分析到面向对象设计，应将一个非面 向对象的需求说明快速转变为面向对象分析模型， 用服务说明去跟踪所得到的需求说明中的功能，消 除用这种方法未曾发现的漏洞。然后进行初步面向 对象的设计，在借助用于实现的程序设计语言进行 详细的OOD。 l9.1.2 抽象抽象 把众多的事物归纳，划分出一些类是人类在认识 客观世界时经常采用的思维方法。分类所依据的原则 是抽象，即是忽略事物的非本质特征，只注意那些与 当前目标相关的本质特征，从而找出事物的特性，把 具有共同性质的事物划分为一类，得到一个抽象的概 念。 面向对象方法支持过程抽象和数据抽象。类就是 一种抽象数据

4、类型，对外提供方法，对内封装数据及 实现。使用者可以通过方法来说明数据，通常把这类 抽象称为规格说明抽象。 此外，某些对象的程序设计语言还支持参数化抽 象。 l9.1.3信息隐藏 “信息隐蔽”是指对外尽可能隐藏对象的 内部细节，利用有限的对外接口或方法与外界 保持联系。 l9.1.4模块化 面向对象软件开发模式很自然地支持了把 系统划分成模块的设计原理，对象就是模块， 它是由一组属性和对这组属性进行操作的一组 服务构成。 l9.1.5类的设计准则 在面向对象的应用中，类实例是系统的主要组成 部分，下面列出一些设计类时应考虑的因素和应遵循 的准则。 （1）类的公共接口的单独成员应该是类的操作符。

5、 （2）类A的实例不应直接发送信息给类B的成员。 （3）只有当类实例的用户可用，操作符才是公共的。 （4）属于类的每个操作符只能赋予修改成访问 类中某个数据的权限，两者只能择一。 （5）类必须保持独立性，尽可能少地依赖其它 类。 （6）两个类之间的相互作用应是显式的。 （7）采用子类继承超类的公共接口，开发子类 成为超类的专用。 （8）目标概念的抽象换型应是继承结构中的根 类。 前四种着重考虑接口的形式及使用，后四 种着重类之间的关系。 l9.1.6面向对象的设计基本原理 抽象（过程，数据） 封装 继承 消息 组织方法（对象和属性、类专成员、整体与部分） 功能分类（基本函数、状态文件响应、对象

6、生 命历程） 分类结论 组装结构 实例连接 消息连接 l9.1.7软件复用 支持软件复用是人们对面向对象方法寄托的主要 希望之一。面向对象方法之所以有利于软件复用，是 由于它的主要概念及原则与软件复用十分吻合。支持 软件复用的OO概念和原则是：对象与类、抽象、封 装、继承与一般特殊结构，聚合与整体部分结构， 粒度控制、多态性。 l9.1.8 面向对象设计的步骤 指出对象及其属性； 指出可能适用于对象的服务； 说明对象及服务； 确定将为对象提供实现描述的详细设计问题； 细化面向对象分析的工作，找出子类、消息特性 和其它详尽的细节； 表示与对象属性关联的数据结构； 表示与每个服务关联的过程细节。

7、9.2启发式规则启发式规则 l何谓启发式规则，乃是人们使用面向对象方法 学的过程中所积累的经验，往往能帮助软件开 发人员提高面向对象的质量。 l9.2.1简单 （1）类简单 小而简单的类利于开发管理。建议类的定义不超 过一页纸（或两屏）。避免包含过多的属性与提供太 多的服务，定义明确，简化对象间的合作关系。但由 于类的规格较小，则有可能导致类的数目增多，带来 一定的复杂性。此时，可将类按分组，划分“主题 “予以解决。 （2）服务简单 简单的服务一般只包含35行源程序语句，功能 描述用一个简单句子即可。case语句的使用，或者语 句嵌套的层次增多，都会导致服务的复杂化。应该设 法分解和简化它，譬

8、如对于case语句，可考虑采用一 般特殊结构予以取代。 （3）协议简单 建议消息中参数不要超过3个，经验表明，通过复 杂信息相互关联的对象是紧耦合的，对一个对象的修 改往往导致其它对象的修改。 l9.2.2设计变动尽可能小 设计质量的水平与设计结果的稳定性（保持不变 的时间）是成正比的。即使必须修改，也应该尽量缩 小范围，理想的设计变动曲线如图91所示： 图91 理想的设计变动曲线 一般情况下，在设计初期变化很大，而后 随着设计方案的日趋成熟，变化应该越来越小。 图91中的峰值对应于出现设计错误或发生非 预期变动的情况。峰值越高，表现设计质量越 差，可重用性程度越低。 l9.2.3设计结果的可

9、懂性 欲提高软件的维护性及重用性，其中一个主要措 施在于使得设计结果清晰易读易懂。以下是对于提 高设计结果可读可懂的一些建议。 1.一致性 命名应与其所代表的事务一致，与人们习惯的名 字一致，可从类名较容易的推想到它的用途。不同 类中的相似服务器命名应一致，避免模糊的定义。 2.使用已有的协议 已有的协议包括同一软件的其他设计人员已经建 立了的类的协议，及已在所使用的类库中相应的协 议。 3.减少信息模式的数目 在自己建立的消息协议中，建议使信息具有一致 的模式，利于读者理解。 9.3 系统分解系统分解 l在现实世界当中，人们解决复杂的，“大而难” 的问题的一般对策是“分而治之”。这同样适 用

10、于软件设计当中。首先把系统按照一定的策 略分解成若干个较小的部分，再分别设计每个 部分。 l子系统是系统的主要组成部分。划分子系统的 原则有很多，但通常均以功能来划分，而且子 系统的数目应该与系统规模基本匹配。 l例如：编译系统可划分为词法分析、语法分析、 中间代码生成、优化、目标代码生成和出错处 理等子系统。 l在划分和设计子系统时，应遵循下列几个原 则： 1.应保持设计的各个子系统相对独立。 2.减少子系统彼此间的依赖性。 3.每个子系统应具备尽可能简单、明确的接口，子 系统之间的交互形式及信息流传递由接口确定。 4.不须规定子系统内部的实现算法。 l9.3.1 子系统之间的两种交互方式

11、子系统之间存在两种可能的交互方式，分别是客 户-供应商（CLIENT-SUPPLIER）关系和平等伙伴 （PEER TO PEER）关系。 1.客户-供应商关系 “供应商”子系统提供借口作为“客户”的子系 统的调用，并返回结果给“客户”。 2.平等伙伴关系 相对前者而言，在这种关系中，每个子系统都是 客户，亦都是供应商，可以互相调用 l9.3.2 组织系统的两种方案 可以采用水平层次方案或垂直块组织方案 将子系统组织成完整的系统。 1.层次组织 一个系统中的各个子系统构成一个层次结构， 每层是一个子系统，各层内部所包含的对象彼此 间相互独立，而不同层之间的对象却往往存在关 联。 层次结构又可分

12、为两种模式：封闭式和开放式。 封闭式 上层只能调用其直接下层提供的服务。 开放式 上层可以调用其下面任意一层所提供的服务。 通常，需求陈述中只描述了对系统顶层和底层的 需求，将目标系统，即用户看到的那部分置于顶层， 供调用的资源全部置于底层。两层之间差异很大，这 要求设计者设计一些中间层次，在减少概念差异的同 时，将顶层底层首尾有效的具体的联系起来。 2块状结构 整个软件系统由垂直分解地若干个相对独立的、 弱耦合的子系统所组成，每个垂直子系统称作块，提 供一种类型的服务。 可以单独利用层次结构和块状结构将多个子系统 组成一个完整的软件系统，当然可以混合的使用层次 结构和块状机构，用若干块组成一

13、层，而同一块也可 以分为若干层。 图9-2是一个运用层状块状混合结构来表示的一个应用系 统的组织结构。 图图92 混合结构表示混合结构表示 l9.3.3设计系统的拓扑结构 子系统可利用一些典型的拓扑，如树型、 星型，管道型来组成完整的系统。设计应该以 简单，减少子系统之间的交互数量为原则，采 用与问题结构相适应的拓扑结构。 9.4 设计问题域子系统设计问题域子系统 l在面向对象分析阶段，得出的概念模型已描述了我们 要解决的问题，为设计问题域子系统奠定了良好的基 础。在设计阶段，应当继续OOA阶段的工作，保持已 经建立的结构，对其进行改进和增补。 l主要是根据需求的变化，对OOA产生的模型中的某

14、些 类与对象、结构、属性、操作进行组合和分解。 l由于面向对象方法的优越性，可在分析与设计阶段保 持问题域组织框架的一致性，从而便于跟踪分析、设 计和编程的结果。在设计过程中进行的修改，不会影 响结果的稳定性。 l以下为读者列出可能对问题域模型进行改进和增补 的几个方面。 1.调整需求：需求的变化可能贯穿于软件开发的全 过程，但是这种变化出现的越早越好，就越容易 更改。其变化主要来自于以下两点： 分析初期对问题域不甚了解，导致面向对象分析模型不 能完整准确地反映用户的真实需求。 用户需求或外部环境的变化。 2. 复用设计：可以通过重用已有类的方法来从设计 阶段开始实现代码重用。如果因为没有合适

15、的类 供重用，在创建新类时必须考虑到将来的可重用 性。 重用已有类的典型过程如下： 根据问题解决的需要，在问题的解决方案中添加从类库 或其他来源得到的既存类。 在被重用的已有类和问题域类之间添加归纳关系（即从 被重用的已有类派生出问题域类），增加从既存类到应 用类之间的一般-特殊化关系。 进一步把标出应用中因继承既存类而成为多余的属性和 服务。 修改与问题域类相关的关联，改为与被重用的已有类相 关的关联，修改应用类的结构和连接，必要时把它们变 成可复用的既存类。 3把问题域类组合在一起。 在设计中，设计者往往从类库中因近一个根类， 作为包容类，而把问题域类组合在一起，建立了类 的层次。把同一问

16、题论域的一些类集合起来，存于 类库中。此外，这样的根类还可以用来建立协议。 4加入一般化类以建立类间协议 有时，某些特殊类要求一组类似的服务，或者还 需要相应的属性。在这种情况下可以引进一个一般 化的类（例如根类），以定义虚函数的形式建立这 个协议，定义为所有这些特殊类共用的一组服务名。 5.对继承机制的分析 因为在分析阶段可建立的模型是独立于程序设计 语言的，所以可能包括有多继承关系，但是不同的 程序设计语言对继承级别的支持不同，有些可能只 有单继承，甚至没有继承机制，这样就需对分析结 果进行修改，稍作一些调整。 分几种情况讨论： 使用多重机制 使用多重机制时应该避免出现属性及服务的 命名冲

17、突。图9-3是多继承模式。这种模式可以成 为窄菱形模式户或叫做狭义的菱形。图9-4是另一 种多重继承的模式，成为阔菱形模式或者叫做广 义的菱形。 图图9-3 窄菱形模式窄菱形模式 图图94 阔菱形模式阔菱形模式 使用单继承机制 如果所用的程序设计语言仅支持单继承，则 必须把多重继承结构转换为单继承结构。 有两种常见的转换方法，下面结合汽车类的 例子，进行说明。 使用映射分解多重映射 在两个层次间建立整体-部分关系或关联关系称之为映射。 通过映射可将多重继承结构分解成两个层次。 l把特殊类的对象看作是一个一般类对象所扮演的角色，通 过实例连接把多继承的层次结构转换为单继承的层次结构。 例如，图9

18、-4所示的多重继承关系，可以分解成如 图9-5或图9-6所示的单重继承关系 图图95利用整体利用整体-部分关系改多重继承为单继承部分关系改多重继承为单继承 图图96利用关联将多重继承为单继承利用关联将多重继承为单继承 化为单一层次 把多继承的层次结构平铺，成为单继承的层次结构， 如图9-7所示。显然，在多重继承结构中的某些一般-特殊 关系，经简化后将不再出现。在这种情况下，有些属性或 服务在同层的特殊类中会重复出现。 图图97将多重继承调整为单继承将多重继承调整为单继承 不具备继承机制 建议软件设计者尽最大可能使用支持继承机制的语言 开发软件系统。因为它不仅能够直接描述问题域固有的归 纳定义，

19、而且能够显式的表示公共属性和服务，为重用奠 定了较好的基础。 当最终选用不具备继承机制的语言编程实现采用的 OOA的分析模型时，需要对模型中的继承做针对式调整。 当使用无继承程序设计语言时，必须把具有继承关系的类 层次结构平铺开来，作为一组类和对象，可利用命名惯例， 把这些类或对象关联起来。如图9-8所示。 图图98将多重继承调整为对象类将多重继承调整为对象类 改进性能 提到执行效率和速度是系统设计的主要指标之一。有时， 必须改变问题论域的结构以提高效率。 加入较低层的构件 在做面向对象分析时，分析员往往专注于较高层的类和对 象，避免考虑太多较低层的实现细节。 9.5 设计任务子系统设计任务子

20、系统 l 所谓任务，是进程的别称，是执行一系列活 动的一段程序。当系统中有许多并发行为时， 为了简化并发行为的设计和编码，需依照各个 行为的协调和通信关系，划分各种任务。 l常见的任务有事件驱动型任务、时钟驱动型任 务、优先任务、关键任务和协调任务等。 1.确定事件驱动型任务 2.确定时钟驱动型任务 3.确定优先任务 4.确定关键任务 5.确定协调任 6.尽量减少任务数 7.确定资源需求 9.6 设计数据管理子系统设计数据管理子系统 l数据管理部分提供了在数据管理系统中存储和 检索对象的基本结构。而建立在某种数据存储 管理系统之上的数据管理子系统是系统存储或 检索对象的基本设施。它分离了数据管

21、理机构 所关心的事项，包括事件，关系型DBMS，或 面向对象数据库管理系统。 l9.6.1数据管理方法 数据管理方法主要有三种：文件管理、关系数据库 管理和面向对象数据库管理。 1.文件管理系统 作为OS的一个组成部分，提供基本的文件处理能 力，简单，成本低。但文件操作级别低，需额外 编写代码以提供适当的抽象级别。此外，不同OS 的文件管理系统之间存在较明显的差异。 2.关系数据库管理系统 建立在坚实的关系理论基础上，使用表格来管理 数据。其优点在于： 使用特定操作，可对表格进行剪切和粘贴。 语言的标准化（SQL）和接口的一致化。 利用范式，可减少数据冗余，保证修改一致性数据不致 出错。 同样

22、，RDBMS也存在一些缺点： 运行开销大，尤其对较多表格进行存取和剪贴时 性能较差。 开发过程中，一旦需求发生变化，数据管理的稳 定性较差。 SQL与程序设计语言连接不自然。 3.面向对象数据库管理系统 面向对象数据库管理系统是一种新技术，一 般以两种方法实现：一是扩充的RDBMS，二是扩 充的面向对象程序设计语言(OOPL)。 扩充的RDBMS主要对RDBMS扩充了抽象数据类 型和继承性，增加了通过服务来创建和操纵类和 对象。扩充了的OOPL对面向对象程序的设计语 言嵌入了在数据库长期管理存储对象的语法和功 能。 l9.6.2 设计数据管理子系统 数据存储管理部分地设计包括数据存放方法的设计

23、和相应 操作的设计。 1.数据存放设计 （1）采用文件存放 l定义第一范式表：列出每个类的属性表；把属性表规范成第一 范式，从而得到第一范式表的定义。 l为每个第一范式表定义一个文件。 l测量性能和需要的存储容量。 l个性原设计的第一范式，以满足性能和存储需求。 （2）关系数据库管理系统 l定义第三范式表格；列出每个类和它的属性；把列表引入 第三范式，产生符合第三范式表格的定义。 l为每个第三范式表格定义一个数据库表。 l度量性能和存储量，然后回到第三范式，设法满足性能和 存储需求。 （3）面向对象数据库管理系统 l扩展的关系数据库途径：使用与关系数据库管理系统相同 的方法。 l扩充的OOPL

24、方法：不再需要附加的操作。DBMS本身为 每个需要长期保存的对象提供了“存储我自己”的行为。 2.设计相应的操作 为每个需要存储的对象及其类增加用于存储管理 的属性和操作，在类及对象的定义中加以描述。通过 定义，每个需要存储的对象将知道如何“存储我自 己”。 （1）采用文件存放数据 被存储的对象需要知道打开哪个（些）文件，怎样把文件 定位到正确的记录上，怎样检索出旧值（如果有的话）， 以及怎样用现有值更新他们。 （2）采用关系数据库存放数据 对象要知道存取哪些表格，如何存取所需的栏，如何检索 要求的数据，以及如何对数据进行更新。 定义一个名为ObjectServer的类，它应带有两个操作：告诉

25、 每个对象存储它自己；检索存储中的对象（查找、取值、 建立初始对象），供设计中的其他成分使用。 （3）采用面向对象数据库存放数据 扩展的关系数据库途径：与使用的关系数据库管理系统时 方法相同。 扩充的OOPL方法：不再需要附加的属性和操作。DBMS本 身提供了“存储我自己”的功能，使每个对象能够长期保 存。如何保存和恢复数据，由面向对象的DBMS来管理。 9.7 面向对象程序设计面向对象程序设计 l9.7.1面向对象程序的特点 与以往各种过程式语言不同的是，它的设计出发 点就是为了能更直接地描述问题域中客观存在的事物 （即对象）以及它们之间的关系。主要体现在以下几 点： OOPL用对象描述问题

26、域中的事物，其构成 成分：属性和服务分别对应着事物的静态特征和动态 特征。 OOPL引入类的概念，包含具有相同属性和服 务的对象，并通过继续机制保证子类具有父类的全部 属性和服务。 复杂的事物由简单的事物所构成，OOPL可 以很好地描述客观世界的这种组成关系。 OOPL的封装机制把对象的服务和属性结合为 一个整体，对外屏蔽了对象的内部细节。 OOPL通过消息表示对象之间的动态联系。 l9.7.2 OOPL概观 面向对象语言OOPL在80年代以后发展非常迅猛， 形成了两大类型。一类是纯面向对象的语言，如 smalltalk和Eiffel；另一类是混合型面向对象的语言， 即在过程型语言中增加面向对象的结构，如C+， Objective-C、CLOS等。 图图99 OOPL的形成的形成 l9.7.3 OOPL特征： 1. 支持类与对象概念的机制 2