第十一章 软件工程 面向对象设计

1软件工程第十一章面向对象设计2第十一章面向对象设计11.1面向对象设计的准则11.2启发规则11.3软件重用11.4系统分解11.5设计问题域子系统(主题部件)11.6设计人机交互子系统11.7设计任务管理子系统11.8设计数据管理子系统11.9设计类中的服务11.10设计关联11.11设计优化3概述设计是把分析阶段得到的对目标系统的需求转变成符合成本和质量要求的、抽象的系统实现方案的过程。从面向对象分析到面向对象设计，是一个逐渐扩充模型的过程，或者说，面向对象设计就是利用面向对象观点建立求解域模型的过程。实际上，分析和设计是一个多次反复迭代的过程。面向对象方法学在概念和表示方法上的一致性，保证了在各开发活动之间的平滑过渡，这是面向对象方法的一大优点。4概述客观世界的对象和操作客观世界的对象输出数据程序设计语言的对象和操作数据结果问题空间客观世界的算法空间计算机算法解空间程序员对问题的表达•对象、操作、消息类、实例和继承•对象描述（对象名及所属对象类，私有数据结构的每一数据项及类型，每个操作的过程描述或指向该过程描述的指针）511.1面向对象设计的准则模块化——对象是面向对象软件系统中的模块，它是把数据结构和操作这些数据的方法紧密地结合在一起所构成的模块。抽象——面向对象的程序设计育秧不仅支持过程抽象，而且支持数据抽象，对象类实际上是具有继承机制的抽象数据类型。此外，某些面向对象的程序设计语言还支持参数化抽象。信息隐藏——在面向对象的软件中，信息隐藏通过对象的封装来实现：类结构分离了接口与实现，从而支持了信息隐藏。611.1面向对象设计的准则弱耦合——交互耦合：对象之间的耦合通过消息连接来实现。交互耦合应尽可能松散：尽量降低消息连接的复杂程度尽量减少消息中的参数个数，降低参数的复杂程度减少对象发送(或接收)的消息数继承耦合：是一般化类与特殊类之间耦合的一种形式。应该提高继承耦合程度：从本质上看，通过继承关系结合起来的基类和派生类，构成了系统中粒度更大的模块，因此，它们彼此之间应该结合得越紧密越好为获得紧密的继承耦合，特殊类应该是对其一般化类的具体化711.1面向对象设计的准则强内聚——服务内聚：一个服务应该完成一个且仅完成一个功能。类内聚：一个类应该只有一个用途，它的属性和服务应该是高内聚的，也就是说，类的属性和服务应该全都是完成该类对象的任务所必需的，其中不包含无用的属性或服务。实际上，对于面向对象软件来说，最佳的内聚是信息型内聚：一个模块可以完成许多相关的操作，每个操作都有各自的入口点，它们的代码相对独立，而且所有操作都在相同的数据结构上完成。一般-特殊内聚：设计出的一般-特殊结构应该是对相应的领域知识的正确抽取。一般说来，紧密的继承耦合与高度的一般-特殊内聚是一致的。811.1面向对象设计的准则可重用——重用是提高软件开发生产率和目标系统质量的重要途径。重用基本上从设计阶段开始。重用有两方面的含义：尽量使用已有的类(包括开发环境提供的类库，及以往开发类是系统是创建的类)如果确实需要创建新类，则在设计这些新类的协议时，应该考虑将来的可重复使用性911.2启发规则1.设计结果应该清晰易懂用词一致：应该是名字与它所代表的事物一致，而且应该尽量使用人们习惯的名字。不同类中相似服务的名字应该相同。使用已有的协议：如果开发统一软件的其他设计人员已经建立了类的协议，或者在所使用的类库中已有相应的协议，则应该使用这些已有的协议。减少消息模式的数目：如果已有标准的消息协议，涉及人员应该遵守这些协议。如果确需自己建立消息协议，则应该尽量减少消息模式的数目，只要可能，就是消息具有一致的模式，以利于读者理解。避免模糊的定义：一个类的用途应该是有限的，而且应该从类名可以较容易得推导出它的用途。1011.2启发规则2.一般-特殊结构的深度应适当应该使类等级中包含的层次数适当。一般说来，在一个中等规模(大约包含100个类)的系统中，类等级层次数应保持为7±2。不应该仅仅从方便编码的角度出发随意创建派生类，应该使一般-特殊结构与领域知识或常识保持一致。3.设计简单的类经验表明，如果一个类的定义不超过一页纸(或两屏)，则这个类比较容易使用。为使类保持简单，应该做到以下几点不要包含过多的属性有明确的定义：为使类的定明确，分配给每个类的任务应该简单简化对象之间的合作关系不要提供太多的服务1111.2启发规则4.使用简单的协议一般说来，消息中的参数不要超过3个。5.使用简单的服务通常，类中的服务都很小，可以用仅含一个动词和一个宾语的简单句子描述它的功能。6.把设计变动减至最小理想的设计变动情况1211.3软件重用3.1概述1.重用重用也称为再用或复用，是指同一事物不经修改或稍加改动就多次重复使用。软件中主要指软件成分重用。2.软件成分的重用级别软件成分的重用可以进一步划分成以下3个级别：代码重用设计结构重用——重用某个软件系统的设计模型(即求解域模型)。这个级别的重用有助于把一个应用系统移植到完全不同的软硬件平台上。分析结构重用——重用某个软件系统的分析模型(即问题域模型)。这类重用特别适用于系统需求未变，但系统体结构发生了根本变化的场合。1311.3软件重用3.典型的可重用软件成分主要有以下10种：项目计划成本估计体系结构需求模型和规格说明设计结构源代码用户文档和技术文档用户界面数据测试用例1411.3软件重用3.2类构件1.可重用软构件应具备的特点模块独立性强且可靠性高具有高度可塑性，也就是说，必须提供扩充或修改已有构件的机制，而且所提供的机制必须使用起来非常简单方便接口清晰、简明、可靠，而且有详尽的文档说明2.类构件的重用方式实例重用：除了用已有的类样板直接创建该类的实例之外，还可以用几个简单的对象作为类的成员创建出一个更复杂的类，这是实例重用的另一种形式。继承重用：当已有的类构件不能通过实例重用方式满足当前系统的需求时，利用继承机制从已有类派生出符合需要的子类，是安全地修改已有的类构件，获得可在当前系统中使用的类构件的有效手段。1511.3软件重用多态重用：为提高软件的可重用性，在设计类构件时应该把注意力集中在下列这些可能妨碍重用的操作上：与表示方法有关的操作与数据结构、数据大小等因素有关的操作与外部设备有关的操作实现算法在将来可能会改变的核心操作如果在设计时未采取适当措施，上述这些操作将妨碍类构件的重用。因此，必须把它们从类的一般操作中分离出来，作为“适配接口”。在设计类构件时应该把作为“适配接口”的操作说明为多态操作(例如，C++语言中的函数)，类中其他操作通过调用适当的多态操作来完成自己的功能。1611.3软件重用当已有的类构件不能通过实例重用方式在当前系统中重用时，可以从已有类派生出子类，在子类中只需重新定义某些多态操作即可满足当前系统的需求。11.3.3软件重用的效益研究表明，通过积极的软件重用，软件产品的质量、开发生产率和整体成本都得到改善。1711.4系统分解OOD设计模型(即求解域的对象模型)与分析模型(即问题域的对象模型)一样，也由5个层次组成：OOA分析阶段OOD设计阶段定义主题主题层标识对象类和对象层标识对象所属类结构层标识对象的属性属性层标识对象的行为服务层人机交互部件主题部件任务管理部件数据管理部件主题层类与对象层结构层属性层服务层大多系统使用OOD的设计模型在逻辑上都由4大部分组成。这4大部分对应于组成目标系统的4个子系统1811.4系统分解这5个层次一层比一层表示的细节更多，可以把这5个层次想象为整个模型的5个水平切片。在不同的软件系统中，这4个子系统的重要程度和规模可能相差很大，规模过大的应该进一步分解成更小的子系统，规模过小的可以合并成其他子系统中。某些应用系统可能仅由3个(甚至少于3个)子系统组成。4.1子系统之间的两种交互方式客户-供应商关系：在这种关系中，作为“客户”的子系统调用“供应商”的子系统，后者完成某些服务工作并返回结果。使用这种交互方案，作为客户的子系统必须了解作为供应商的子系统的接口，而后者则无须了解前者的接口，因为，任何交互行为都是由前者驱动的。1911.4系统分解平等伙伴关系：在这种关系中，每个子系统都可能调用其他子系统，每个子系统都必须了解其他子系统的接口。由于各个子系统需要相互了解对方的接口，因此这种组织系统的方案比起客户-供应商方案来，子系统之间的交互更复杂，而且这种交互方式还可能存在通信环路，从而使系统难于理解，容易发生不易察觉的设计错误。单向交互比双向交互更容易理解，更容易设计和修改。4.2组织系统的两种方案方案一：层次组织把软件系统组织成一个层次系统，每层是一个子系统。上层在下层的基础上建立，下层为实现上层功能提供服务。每一层被包含的对象，彼此间相互独立，而处于不同层次上的对象，彼此间往往有关联。实际上，在上、下层之间存在客户-供应商关系。低层子系统提供服务，相当于供应商，上层子系统使用下层提供的服务，相当于客户。2011.4系统分解方案二：块状组织这种组织方案把软件系统垂直地分解成若干个相对独立的、弱耦合的子系统，一个子系统相当于一块，每块提供一种类型的服务。利用层次和块的各种可能的组合，可以成功地由多个子系统组成一个完整的软件系统。当混合使用层次结构和块状组成，而同一个也可以分为若干层。4.3设计系统的拓扑结构由子系统组成完整的系统时，典型的拓扑结构有管道型、树型、星型等。设计者应该采用与问题结构相适应的、尽可能简单的拓扑结构，以减少子系统之间的交互数量。2111.4系统分解典型应用系统的组织结构2211.5设计问题域子系统(主题部件)通过面向对象分析所得出的问题域精确模型，为设计问题域子系统奠定了良好的基础，建立了完整的框架。只要可能，就应该保持面向对象分析所建立的问题域结构。通常，面向对象设计仅需从实现角度对问题域模型作一些补充或修改，主要是增添、合并或分解类、属性及服务，调整继承关系等。当问题域子系统过复杂庞大时，应该把它进一步分解成若干个更小的子系统。问题域子系统设计也称为主题部件设计2311.5设计问题域子系统(主题部件)5.1主体部件（PDC）设计主体部件是构造应用软件的总体模型（结构），是标识和定义模块的过程。模块可以是一个单个的类，也可以是由一些类组合成的子系统。主体部件设计阶段标识在计算机环境中进行问题解决工作所需要的概念，并增加了一批需要的类。主要是可使应用软件与系统的外部世界交互的类此阶段的输出是适合应用要求的类、类间的关系、应用的子系统视图规格说明。5.1.1主体部件设计的任务设计包括与应用问题直接有关的所有类和对象。对OOA模型中的某些类与对象、结构、属性、操作进行组合与分解。进而进行改进和增补要考虑对时间与空间的折衷、内存管理、开发人员的变更、以及类的调整等。24主体部件设计模型2511.5设计问题域子系统(主题部件)5.1.2主体部件设计应遵循的原则使在子系统的各个高层部件之间的通信量达到最小；子系统应当把那些成组的类打包，形成高度的内聚；逻辑功能分组，提供一个逻辑功能一个单元，识别并定位问题事件；5.1.3主体部件设计和类设计关系每个子系统都可以被当做一个类来实现，这个类聚集它的部件，提供了一组操作。类和子系统的结构是正交的，一个单个类的实例可能是不止一个子系统的一部分。主题部件设计和类设计这两个阶段是相对封闭的，又是相互连接的。2611.5设计问题域子系统(主题部件)在面向对象设计过程中，可对面向对象分析得出的问题域模型做下述修改：5.2调整需求为了调整对目标系统的需求，通常只需简单地修改面向对象分析结果，然后再把这些修改反映到问题域子系统中。5.3重用已有的类尽量使用已有的类库中既存类在已有类中找出与问题域内某个最相似的类作为被重用类从被重用的类派生出问题域类简化对问题域类的定义(从被重用的类继承的属性和服务无须再定义)修改与问