软件工程 第4版 教学课件 ppt 作者 张海藩 吕云翔 编著 08第八章：面向对象设计.ppt

分析是提取和整理用户需求，并建立问题域精确模型的过程设计则是把分析阶段得到的需求转变成符合成本和质量要求的、抽象的系统实现方案的过程从面向对象分析到面向对象设计（通常缩写为OOD），是一个逐渐扩充模型的过程 尽管分析和设计的定义有明显区别，但是在实际的软件开发过程中二者的界限是模糊的许多分析结果可以直接映射成设计结果，而在设计过程中又往往会加深和补充对系统需求的理解，从而进一步完善分析结果第八章：面向对象设计,8.1 面向随想设计的准则 8.2 启发规则 8.3 系统分解 8.4 设计问题域子系统 8.5 设计人——机交互子系统 8.6 设计任务管理子系统 8.7 设计数据管理子系统 8.8 设计类中的服务 8.9 设计关联 8.10 设计优化 8.11 面向对象分析与设计实例,第八章：面向对象设计,1．模块化 面向对象软件开发模式，很自然地支持了把系统分解成模块的设计原理：对象就是模块它是把数据结构和操作这些数据的方法紧密地结合在一起所构成的模块 2．抽象 面向对象方法不仅支持过程抽象，而且支持数据抽象类实际上是一种抽象数据类型，它对外开放的公共接口构成了类的规格说明（即协议），这种接口规定了外界可以使用的合法操作符，利用这些操作符可以对类实例中包含的数据进行操作。

3．信息隐藏 在面向对象方法中，信息隐藏通过对象的封装性实现：类结构分离了接口与实现，从而支持了信息隐藏对于类的用户来说，属性的表示方法和操作的实现算法都应该是隐藏的 4．弱耦合 耦合指一个软件结构内不同模块之间互连的紧密程度在面向对象方法中，对象是最基本的模块，因此，耦合主要指不同对象之间相互关联的紧密程度弱耦合是优秀设计的一个重要标准，因为这有助于使得系统中某一部分的变化对其他部分的影响降到最低程度一般来说，对象之间的耦合可分为两大类： （1）交互耦合 如果对象之间的耦合通过消息连接来实现，则这种耦合就是交互耦合为使交互耦合尽可能松散，应该遵守下述准则 ◇ 尽量降低消息连接的复杂程度应该尽量减少消息中包含的参数个数，降低参数的复杂程度 ◇ 减少对象发送（或接收）的消息数2）继承耦合 与交互耦合相反，继承耦合应该提高继承耦合程度继承是一般化类与特殊类之间耦合的一种形式从本质上看，通过继承关系结合起来的基类和派生类，构成了系统中粒度更大的模块，因此，它们彼此之间应该结合得越紧密越好 为获得紧密的继承耦合，特殊类应该确实是对它的一般化类的一种具体化，也就是说，它们之间在逻辑上应该存在“is a”的关系。

5．强内聚 内聚衡量一个模块内各个元素彼此结合的紧密程度也可以把内聚定义为：设计中使用的一个构件内的各个元素，对完成一个定义明确的目的所做出的贡献程度在设计时应该力求做到高内聚在面向对象设计中存在下述3种内聚 （1）服务内聚 一个服务应该完成一个且仅完成一个功能2）类内聚 设计类的原则是，一个类应该只有一个用途，它的属性和服务应该是高内聚的类的属性和服务应该全都是完成该类对象的任务所必需的，其中不包含无用的属性或服务 （3）一般/特殊内聚 设计出的一般/特殊结构，应该符合多数人的概念，更准确地说，这种结构应该是对相应的领域知识的正确抽取6．可重用 软件重用是提高软件开发生产率和目标系统质量的重要途径，重用基本上从设计阶段开始重用有两方面的含义：一是尽量使用已有的类（包括开发环境提供的类库，及以往开发类似系统时创建的类），二是如果确实需要创建新类，则在设计这些新类的协议时，应该考虑将来的可重复使用性8.1 面向随想设计的准则 8.2 启发规则 8.3 系统分解 8.4 设计问题域子系统 8.5 设计人——机交互子系统 8.6 设计任务管理子系统 8.7 设计数据管理子系统 8.8 设计类中的服务 8.9 设计关联 8.10 设计优化 8.11 面向对象分析与设计实例,第八章：面向对象设计,1．设计结果应该清晰易懂 使设计结果清晰、易读、易懂，是提高软件可维护性和可重用性的重要措施。

（1）用词一致 应该使名字与它所代表的事物一致，而且应该尽量使用人们习惯的名字不同类中相似服务的名字应该相同 （2）使用已有的协议 如果开发同一软件的其他设计人员已经建立了类的协议，或者在所使用的类库中已有相应的协议，则应该使用这些已有的协议3）减少消息模式的数目 如果已有标准的消息协议，设计人员应该遵守这些协议如果确需自己建立消息协议，则应该尽量减少消息模式的数目只要可能，就使消息具有一致的模式，以利于读者理解 （4）避免模糊的定义 一个类的用途应该是有限的，而且通过类名应该可以较容易地推想出它的用途2．一般/特殊结构的深度应适当 应该使类等级中包含的层次数适当一般来说，在一个中等规模（大约包含100个类）的系统中，类等级层次数应保持为7±2不应该仅仅从方便编码的角度出发随意创建派生类，应该使一般/特殊结构与领域知识或常识保持一致3．设计简单的类 应该尽量设计小而简单的类，以便于开发和管理当类比较庞大的时候，要记住它的所有服务是非常困难的为保持类的简单，应该注意以下几点 （1）避免包含过多的属性 属性过多通常表明这个类过分复杂了，它所完成的功能可能太多了 （2）有明确的定义 为了使类的定义明确，分配给每个类的任务应该简单，最好能用一两个简单语句描述它的任务。

3）尽量简化对象之间的合作关系 如果需要多个对象协同配合才能做好一件事，则破坏了类的简明性和清晰性 （4）不要提供太多服务 一个类提供的服务过多，同样表明这个类过分复杂典型地，一个类提供的公共服务不超过7个 在开发大型软件系统时，遵循上述启发规则也会带来另一个问题；设计出大量较小的类，这同样会带来一定复杂性解决这个问题的办法，是把系统中的类按逻辑分组，也就是划分“主题”4．使用简单的协议 一般来说，消息中的参数不要超过3个当然，不超过3个的限制也不是绝对的但是，经验表明，通过复杂消息相互关联的对象是紧耦合的，对一个对象的修改往往导致其他对象的修改 5．使用简单的服务 面向对象设计出来的类中的服务通常都很小，一般只有3～5行源程序语句，可以用仅含一个动词和一个宾语的简单句子描述它的功能6．把设计变动减至最小 通常，设计的质量越高，设计结果保持不变的时间也越长即使出现必须修改设计的情况，也应该使修改的范围尽可能小理想的设计变动曲线如图8.1所示 在设计的早期阶段，变动较大，随着时间推移，设计方案日趋成熟，改动也越来越小了图8.1中所示的峰值与出现设计错误或发生非预期变动的情况相对应峰值越高，表明设计质量越差，可重用性也越差。

图8.1 理想的设计变动情况,8.1 面向随想设计的准则 8.2 启发规则 8.3 系统分解 8.4 设计问题域子系统 8.5 设计人——机交互子系统 8.6 设计任务管理子系统 8.7 设计数据管理子系统 8.8 设计类中的服务 8.9 设计关联 8.10 设计优化 8.11 面向对象分析与设计实例,第八章：面向对象设计,人类解决复杂问题时普遍采用的策略是“分而治之，各个击破”同样，软件工程师在设计比较复杂的应用系统时普遍采用的策略，也是首先把系统分解成若干个比较小的部分，然后再分别设计每个部分 系统的主要组成部分称为子系统，通常根据所提供的功能来划分子系统 各个子系统之间应该具有尽可能简单、明确的接口接口确定了交互形式和通过子系统边界的信息流，但是无须规定子系统内部的实现算法在划分和设计子系统时，应该尽量减少子系统彼此间的依赖性采用面向对象方法设计软件系统时，面向对象设计模型（即求解域的对象模型），与面向对象分析模型（即问题域的对象模型）一样，也由主题、类与对象、结构、属性和服务5个层次组成 我们可以把面向对象设计模型的4大组成部分想象成整个模型的4个垂直切片典型的面向对象设计模型可以用图8.2表示。

图8.2 典型的面向对象设计模型,1．客户—供应商关系 在这种关系中，作为“客户”的子系统调用作为“供应商”的子系统，后者完成某些服务工作并返回结果使用这种交互方案，作为客户的子系统必须了解作为供应商的子系统的接口，然而后者却无须了解前者的接口，因为任何交互行为都是由前者驱动的8.3.1 子系统之间的两种交互方式,2．平等伙伴关系 在这种关系中，每个子系统都可能调用其他子系统，因此，每个子系统都必须了解其他子系统的接口由于各个子系统需要相互了解对方的接口，因此这种组织系统的方案比起客户—供应商方案来，子系统之间的交互更复杂，而且这种交互方式还可能存在通信环路，从而使系统难于理解，容易发生不易察觉的设计错误 总的说来，单向交互比双向交互更容易理解，也更容易设计和修改，因此，应该尽量使用客户—供应商关系1．层次组织 这种组织方案把软件系统组织成一个层次系统，每层是一个子系统上层在下层的基础上建立，下层为实现上层功能而提供必要的服务每一层内所包含的对象，彼此间相互独立，而处于不同层次上的对象，彼此间往往有关联 层次结构又可进一步划分成两种模式：封闭式和开放式所谓封闭式，就是每层子系统仅仅使用其直接下层提供的服务在开放模式中，某层子系统可以使用处于其下面的任何一层子系统所提供的服务。

8.3.2 组织系统的两种方案,2．块状组织 这种组织方案把软件系统垂直地分解成若干个相对独立的、弱耦合的子系统，一个子系统相当于一块，每块提供一种类型的服务 利用层次和块的各种可能的组合，可以成功地由多个子系统组成一个完整的软件系统当混合使用层次结构和块状结构时，同一层次可以由若干块组成，而同一块也可以分为若干层例如，图8.3所示为一个应用系统的组织结构，这个应用系统采用了层次与块状的混合结构图8.3 典型应用系统的组织结构,由子系统组成完整的系统时，典型的拓扑结构有管道形、树形、星形等设计者应该采用与问题结构相适应的、尽可能简单的拓扑结构，以减少子系统之间的交互数量8.3.3 设计系统的拓扑结构,8.1 面向随想设计的准则 8.2 启发规则 8.3 系统分解 8.4 设计问题域子系统 8.5 设计人——机交互子系统 8.6 设计任务管理子系统 8.7 设计数据管理子系统 8.8 设计类中的服务 8.9 设计关联 8.10 设计优化 8.11 面向对象分析与设计实例,第八章：面向对象设计,使用面向对象方法开发软件时，在分析与设计之间并没有明确的分界线，对于问题域子系统来说，情况更是如此。

通过面向对象分析所得出的问题域精确模型，为设计问题域子系统奠定了良好的基础，建立了完整的框架 使用面向对象方法学开发软件，能够保持问题域组织框架的稳定性，从而便于追踪分析、设计和编程的结果在设计与实现过程中所做的细节修改（如增加具体类，增加属性或服务），并不影响开发结果的稳定性，因为系统的总体框架是基于问题域的对于需求可能随时间变化的系统来说，稳定性是至关重要的稳定性也是能够在类似系统中重用分析、设计和编程结果的关键因素为更好地支持系统在其生命期中的扩充，也同样需要稳定性 下面介绍在面向对象设计过程中，可能对面向对象分析所得出的问题域模型作的补充或修改 1．调整需求 有两种情况会导致修改通过面向对象分析所确定的系统需求：一是用户需求或外部环境发生了变化；二是分析员对问题域理解不透彻或缺乏领域专家帮助，以致面向对象分析模型不能完整、准确地反映用户的真实需求2．重用已有的类 代码重用从设计阶段开始，在研究面向对象分析结果时就应该寻找使用已有类的方法若因为没有合适的类可以重用而确实需要创建新的类，则在设计这些新类的协议时，必须考虑到将来的可重用性 ①选择有可能被重用的已有类，标出这些候选类中对本问题无用的属性和服务，尽量重用那些能使无用的属性和服务降到最低程度的类；②在被重用的已有类和问题域类之间添加归纳关系；③标出问题域类中从已有类继承来的属性和服务，现在已经无须在问题域类。