软件工程 第八章 面向对象的设计方法资料

1、第八章面向对象的设计方法本章采用基于UML的面向对象设计方法的将分析模型转换为设计模型。如第五章所述，面向对象的分析模型主要由顶层架构图、用例与用例图、领域概念模型构成；设计模型则包含以包图表示的软件体系结构图、以交互图表示的用例实现图、完整精确的类图、针对复杂对象的状态图和用以描述流程化处理过程的活动图等。为完成这一转换过程，设计人员必须处理以下任务：（1） 针对分析模型中的用例，设计实现方案。实现方案用 UML交互图表示。（2） 设计技术支撑设施。在大型软件项目中，往往需要一些技术支撑设施来帮助业务需求层面的类或子系统完成其功能。这些设施本身并非业务需求的一部分 ，但却为多种业务需求的实现

2、提供公共服务 。例如，数据的持久存储服务、安全控制服务和远程访问服务等。在面向对象设计中，需要研究这些技术支撑设施的实现方式以及它们与业务需求层面的类及子系统之间的关系。（3）设计用户界面。（4） 针对分析模型中的领域概念模型以及第（2）、（3）两个步骤引进的新类，完整、精确地确定每个类的属性和操作，并完整地标示类之间的关系。此外，为了实现软件重用和强内聚、松耦合等软件设计原则，还可以对前面形成的类图进行各种微调，最终形成足以构成面向对象程序设计的基础和依据的详尽类图。面向对象的软件设计过程如图8-1-1所示。图 8-1-1面向对象的软件设计过程第一节设计用例实现方案UML 的交互图（顺序图、

3、协作图）适于用例实现方案的表示。因此，本节首先介绍交互图的语言机制，然后探讨用例实现方案的设计方法。该设计方法包含如下3个步骤：（1）提取边界类、实体类和控制类；（2）构造交互图；（3）根据交互图精华类图。一、顺序图顺序图用来描述对象之间动态的交互关系，着重表现对象间消息传递的时间顺序。在顺序图中，参与交互的对象位于顶端的水平轴上，垂直轴表示时间，时间推移的方向是自上而下的。顺序图中的对象一般以“对象名：类名”的方式标识，但也可以仅采用缩写形式“对象名”或者“：类名”。对象的下方用垂直虚线表示对象的生命线，即对象在某段时间内存在。对象生命的终结用生命线下方的叉号“”表示。附着在对象生命线上的矩

4、形框表示对象在此段时间内活跃。对象间的通信表现为对象的生命线之间的消息传递。在消息边上需附加消息名和消息参数，有时也以顺序号强调消息的时序。消息的源对象和目标对象可以相同，这种消息称为自调用（self-call） 。可以在消息名前面的方括号中书写条件表达式，表明仅当条件成立时，该消息才发送。还可以在方括号的前面或者直接在消息名的前面加上迭代标记“*” ，以表示一条消息对同一类的多个对象的多次发送。顺序图的左边可带有描述信息，以阐明消息发送的时刻、动作执行情况、两条消息之间的时间间隔以及约束信息等。还可以在消息边上附加文字注解信息，以增强顺序图的可理解性。典型的顺序图如图 8-1-2所示。UML

5、的消息有如下4种类型：（1） 简单消息（simple message）。以一种简单、抽象的函数表示对象之间的信息传递，不考虑通信过程的内部细节。简单消息在 UML顺序图中用普通的有向箭头表示。（2） 同步消息（synchronus message）。消息源发出消息后，必须等待消息处理过程完毕并返回处理结果，才可继续执行后续操作。前面所述的自调用消息应该是同步的。同步消息的表示图元与简单消息相同，这表明UML在缺省状态下认为简单消息即为同步消息。（3） 异步消息（synchonous message）。消息源发出消息后，不必等待消息处理过程的返回，即可继续执行自己的后续操作。异步消息主要用于描述

6、实时系统中的并发行为。异步消息在 UML顺序图中用一种特别的单向箭头表示，见图8-1-2中的“msg1”。图 8-1-2典型的顺序图（4） 返回消息（return message）。表示前面发送的消息的处理过程完成后的返回结果。返回消息应该是同步。在许多情况下，可以隐藏返回消息，但也可显式地标出返回消息以示强调。返回消息用虚线有向箭头表示，见图8-1-2中的“msg6”。一个对象可以通过发送标准消息“new” 来创建另一个对象。当一个对象被删除或自我删除时，该对象生命线上的相应时间点应该用叉号（对象生命线终结符）标识。二、协作图图 8-1-3典型的协作图三、提取边界类、实体类和控制类边界类用于

7、描述目标软件系统与外部环境之间的交互，并负责实现如下功能：（1） 界面控制。包括输入数据的格式及内容转换、输出结果的呈现以及软件运行过程中界面的变化与切换等。（2） 外部接口。实现目标软件系统与外部系统或外部设备之间的信息交流和互操作。主要关注跨越目标软件系统边界的通信协议。（3） 环境隔离。将目标软件系统与操作系统、数据库管理系统、应用服务器中间等环境软件进行交互的功能与特性封装于边界类之中，使目标软件系统的其余部分尽可能的独立于环境软件。在UML 类图中，边界类往往附加UML 构造型< > 作为特别标识。例如，“家庭保安系统”中的边界类有“输入键盘接口类”、“传感器接口类”、“

8、警报器接口类”、“报警电话接口类”和“显示面板接口类”。实体在表示目标软件系统中具有持久意义的信息项及其操作。实体类的操作具有“ 内向收敛 ”特征，它们仅向目标软件系统的其余部分提供读写信息项内容的必要的操作接口，并不涉及业务逻辑处理。实体类的UML构造型为< > 。例如，“家庭保安系统”中的“异常事件”即为实体类。控制类作为完成用例任务的责任承担者，协调、控制其他类共同完成用例规定的功能或行为。对于比较复杂的用例，控制类通常并不处理具体的任务细节，但是它应知道如何分解任务，如何将子任务分派给适当的辅助类，以及如何在辅助类之间进行消息传递和协调。控制类的 UML构造型为< &

9、gt; 。例如，“家庭保安系统”中的“用户命令处理器”和“监测器”均为控制类。在讨论了边界类、实体类和控制类和基本概念之后，下面介绍如何从分析模型中的用例描述和领域概念模型出发获取这些类。通常情况下，执行者与用例之间的一种通信连接对应一个边界类。但是，如果两个以上的用例与同一执行者交互，并且这些交互具有共同的行为、完成相同或类似的任务，就可以考虑用同一边界类实现用例与执行者之间的交互。这就意味着边界类的作用范围可以超越单个用例。实体类主要来源于领域概念模型。有时也需要认真研读用例描述，从中发掘具有持久意义的信息项。如果执行者的属性需要持久保存，也可以建立相应于执行者的实体类。假设一个实体类A仅

10、仅被系统中的另一个类B引用，并且系统无需关心类 A有行为特征，那么为了简化设计模型，应将类A中的信息项直接作为类B的属性。反之，如果类 A被系统中的多个类引用，或者类 A具有不容忽略的行为特征，那么应将类A作为独立的实体类。一般而言，一个用例通常对应一个控制类。如果不同用例的任务较多类似之处，也可以考虑在多个用例的实现方案中共享一个控制类。不过，此种情况应审慎对待，因为对于不同的且例，其事件流的逻辑结构鲜有雷同，它们所需要的控制、协调行为往往会有差异。此外，对于那些事件流非常简单的用例，可以不设独立的控制类，直接在边界类中设置控制、协调功能，边界类在实体类的帮助下完成用例要求的功能及行为。四、

11、构造交互图在标识边界类、实体类和控制类之后，接下来的任务是将分析模型中的用例描述转化成UML交互图，以交互图作为用例的精确实现方案。如前所述，用例描述中已包含事件流说明。事件流中的事件应直接对应于交互图中的消息，而事件间的先后关系体现为交互图中的时序，对消息的响应则构成消息接收者的职责。这种职责在后续的设计活动中将被确立为类的方法。对于比较复杂的用例而言，仅仅依靠控制类、边界类和实体并不能很好地解决问题，因为我们不能使单个控制类过于宏大和复杂，让它既承担控制、协调的任务，又承担复杂的计算任务。因此，在设计复杂用例的实施方案时，应考虑为控制类设置一些独立的辅助类，让控制类将一些任务委托给辅助类完

12、成。例如，在图 5-3-4所示的“家庭保安系统”类图中，“系统配置管理器”和“日志管理器”就是这种意义上的辅助类。在UM顺序图中，用例的主动执行者应位于最左侧，紧邻其右的类的作为用户界面的边界类，再往右是控制类。控制类的右侧应旋转辅助类和实体类，它们的右侧是人秋外部接口和环境隔离层的边界类，最右侧是痊于目标软件系统边界之外的被动执行者。如此布局之后，在顺序图中不应该出现穿越控制类生命线的消息，即主动执行者向边界类发出命令，边界类将命令进行适当转换后传送至控制类，控制类通过消息请求辅助类、实体类的帮助，协调 、控制它们共同完成来自主动执行者的命令 。在此过程中，控制类或辅助害可以向右侧的边界类发

13、送消息，将信息或外部处理请求由边界类传向外部系统（被动执行者）。按照上述而已规则绘制的典型的顺序图如图8-1-4所示。图 8-1-4典型布局规则下的顺序图在用例描述中，许多用例除主事件流外，往往还包含备选事件流，以说明在某些特殊或异常情况下的事件和响应动作序列 。为易于理解 ，在设计模型中应该用分离的UML交互图分别表示事件流和每个备选事件流。由于顺序图能够非常直观地表达事件（消息）的时序，所以它比协作图更多地用于描述用例的实现方案。但是，当需要强调类之间的联系或连接时，就需要绘制协作图。协作图的而已规则是 ：控制类位于中心 ，主动执行者和作为用户界面的边界类位于左上方，作为外部接口和环境隔离

14、层的边界类位于右上方，辅助类和实体类分别位于控制类的左下方和右下方。按照此而已规则绘制的典型的协作图如图8-1-5所示。图 8-1-5典型布局规则下的协作图在“家庭保安系统”中用例“传感器监测”和“命令处理”的实现方案分别见图8-1-6和图8-1-7。为简洁起见，图8-1-6和图8-1-7未表示这两个用例中的日志功能，图 8-1-7也未考虑配置命令的处理，有兴趣的读者可自行添加。图 8-1-6“传感器监测”用例的顺序图图 8-1-7“命令处理”用例的顺序图五、精华类图在UML交互图中,对每个类的对象都规定了它必须响应的消息以及类的对象之间的消息传递通道。前者对应于类的操作，后者则对应于类之间的

15、连接关系。因此，可以利用交互图精华分析模型中的类图，将交互图中出现的新类添加到原有类图中，并且对相关的类进行精华，定义其属性和操作。原则上，每个类都应该有一个操作来响应交互图中指向其对象的那条消息。但是，这并不意味着消息与操作一定会一一对应，因为类的一个操作可能具有响应多条消息的能力。同理，两个类之间的一条连接关系也可以为多条消息提供传递通道。为了简化设计模型，也为了提高重用程度，设计人员应该尽量使用已有的操作来响应新消息，并尽量使用已存在的连接路径作为消息传递的通道。如果两个类之间存在明确、自然的聚合或组合关系，则可以在类图中直接用相应的 UML图元符号表示类间的聚合或组成关系，这两个关系均

16、可提供消息传递通道。接下来讨论如何根据交互图确立类的属性。类的操作完成消息响应责任的能力来源于两方面的知识，一是类本身具有的信息，即类的属性；二是类能够找到的其他类，通过其他类协助其完成消息响应，在综合考虑这两个因素之后，类的操作应该明确哪些子任务可通过消息传递路径委托给其他类完成，哪些子任务必须由自身完成。根据后一种子任务的需要结合领域和业务知识即可推导出类应具有的属性。在图5-3-4的基础上，得出“家庭保安系统”的类图如图8-1-8所示。为简洁起见，图 8-1-8仅标出控制类“监测器”和“用户命令处理器”的方法以及实体类“异常事件”的属性，有兴趣的读者可自行添加其余的属性和方法。图 8-1

17、-8“家庭保安系统”的精化类图 第二节设计技术支撑方案在许多软件项目中 ，应用功能 往往都需要一组技术支撑机制为其服务。例如 ，分布式应用软件（包括电子商务应用 、企业 ERP系统等）而言，需要数据持久存储服务、安全控制服务、分布式事务管理服务、并发与同步控制服务和可靠消息服务等。这些技术支撑设施并非业务需求的直接组成部分，但形态各异的业务处理功能全都依赖于它们提供的公共技术服务。让每个业务功能的设计者直接面对裸机、基本操作系统或基本网络环境来完成软件实现方案是不可思议的。技术支撑方案应该为多个用例的软件实现提供技术服务，所以它应该成为整个目标软件 系统中全局性 的公共技术平台。当用户需求发生

18、变化时，技术支撑方案应具有良好的稳定性。这就要求软件设计者选用开放性和可扩充性较好的技术支撑方案。如果目标软件系统的顶层架构采用分层方式，那么技术支撑方案应该位于层次结构中的较低层次。技术支撑方案的设计一方面取决于目标软件系统对公共技术服务的需求，另一方面取决于设计人员对软件技术手段的把握和选取。例如，对分布式应用系统而言，设计人员必须了解分布构件技术和基于应用服务器的软件开发技术等。本节的后续部分将分别以数据持久存储服务、并发与同步控制服务为例探讨技术支撑方案的设计方法，然后介绍技术支撑方案与用例实现方案的融合。一、数据持久存储服务设计数据持久存储服务的目的是将目标软件系统中依赖于系统运行环

19、境的数据存取部分与其他部分相分离。数据存取通过一般的数据管理系统（如文件系统、关系数据库或面向对象数据库）实现，实现细节因数据存储介质的不同种类而异，但这些细节被集中在数据持久存储服务中，系统的其他部分与存储介质的种类和数据存储的实现方法无关。这样，既有利于软件的扩充、移植和维护，又简化了软件设计、编码和测试的过程。无论基于哪一种数据管理方法，数据持久存储服务的设计都包括定义数据格式和定义数据存取操作两部分。定义数据格式。根据目标软件系统对数据存储的需求，考虑持久存储介质的特性，设计数据的存储格式。例如，针对文件系统，需要定义用于保存数据的文件类别以及每类文件的记录格式；针对关系数据库，需要定

20、义表格的字段名称 、类型 、关键字和约束条件等；针对面向对象数据库（Object-Oriented Data Base OODB），数据格式的定义相对简单，因为OODB直接支持对象的存储和读取。定义数据存取操作。数据持久存储服务至少包含数据的存储和读取两种操作。存储操作负责将实体对象中的属性数据写至持久存储介质，读取操作则负责从持久存储介质中的序列化数据恢复对象的属性值。可以定义适用于所有实体类的存取操作，也可以分别针对不同的实体类定义不同的存取操作。数据存取操作一般以服务类的形式工业基础系统的其他部分提供数据持久存储服务。在引久持久存储服务之后，目标软件系统的其他部分对持久存储介质的访问必须

21、通过该服务进行，不能直接访问。二、并发与同步控制服务与数据持久存储服务类似，设计并发与同步控制服务的目的是将目标软件系统中 依赖于系统运行环境的并发 与同步控制部分和其他部分相分离，其他部分中有关并发与同步控制功能的实现均通过该服务来完成。当然，如果目标软件系统无需考虑并发问题，则可忽略此设计步骤。一般而言，并发与同步控制服务提供的功能应包括：进程线程的定义与启动；进程线程的终止、进程线程的状态查询、同步点的设置及进程线程在同步点的信息交换等。这些功能应封装在服务类之中。三、技术支撑方案与用例实现方案的融合技术支撑方案往往包含数个公共技术服务子系统。这些子系统无论其规模大小和内部复杂度高低，都

22、应该提供数量较少的外部接口。所有的上层应用功能对公共技术服务的调用均通过访问这些外部接口而实现。因此，为了事例技术支撑方案和用例实施方案，只需对相应的 UML交互图作少许修改，在图中添加必需的公共技术服务子系统接口，让控制类的对象与该接口所代表的公共服务对象进行消息交互。对数据持久存储服务，与之交互的可以是实体类或者控制类。至于这些接口在交互图中的布局位置，则依据其所提供服务的性质的不同而有所变化：（1） 先考虑数据持久存储服务。在引入此服务以后，用例中有关数据持久的实现有两种策略：一是让控制类对象调用此服务实现数据存取，二是让实体类对象直接调用此服务。在前一种策略下，实体类对象在数据保存的过

23、程中先向控制类对象提供数据，再由控制类对象调用服务将数据存至持久介质（ 如数据库、文件等 ）数据读取的过程则为此过程的逆过程。在后一策略下，实体类对象负责自己的数据的读取和保存。相比较而言，后一种策略理为简洁、自然。对一图 8-1-4，如果右侧的边界类与公共数据持久存储服务子系统的接口类的功能多有重叠，则应该考虑将二者合并。（2） 再考虑安全控制服务。此类服务的子系统接口在顺序图中应位于控制类的紧邻右侧。（3） 最后考虑分布式事务管理服务、并发与同步控制服务及可靠消息服务。它们的接口类在顺序图中可以位于控制类与右边边界类之间的任意位置，但不应插在两个辅助类或两个实体类的中间。下面讨论技术支撑方

24、案的类图与迄今获得的其他类图的事例问题。如果前者比较简单，可以考虑将技术支撑方案的类图直接与其他类图合并，并建立公共技术服务类与其他类之间的必要连接。此时，有必要在公共技术服务类上以 UML构造型进行特殊标识。如果公共技术服务子系统中包含较多的服务类，它们应单独构成类图，利用 UML的包机制进行适当分组，并将这些包置于系统的体系结构图的较低层次（相对而言，应用功能应位于较高层次）。 第三节设计用户界面需求分析和软件设计阶段都必须考虑人机交互问题。在需求分析阶段要确定人机交互的属性和外部服务，而在设计阶段要给出有关人机交互的所有系统成份，包括用户如何操作系统、系统如何响应命令和系统显示信息的报表

25、格式等。用户界面设计的策略与步骤如下：（1） 熟悉用户并对用户分类。设计人员应深入用户环境，考虑用户需要完成的任务、完成这些任务需要什么工具支持以及这些工具对用户是否适用。事实上，不同类型的用户要求也不同，一般可按技术熟练程度、工作性质和访问权限对用户进行分类，以便尽量照顾到所有用户的合理要求，并优先满足某些特权用户。（2） 按用户类别分析用户的工作流程 与习惯 。在用户分类的基础上，从每类中选取一个用户代表，建立包括下列内容的调查表，并通过对调查结果的分析判断用户地操作界面的需求和喜好：· 姓名· 期望软件用途；· 特征（如年龄、文化程度、限制等）；·

26、 主要要求与喜好；· 技术熟练程度；· 任务客观场景描述。（3） 设计命令系统工进行优化。在设计一个新命令系统时，应尽量遵循用户界面的一般原则和规范，必要时可参考一些优秀的商品软件。根据用户分析结果确定初步的命令系统，然后再优化。命令系统既可为若干菜单、菜单栏 ，也可为一组按钮 。优化命令系统时首先应考虑命令的顺序，一般常用居先，命令的顺序与用户工作习惯一致；其次，根据外部服务之间的聚合关系组织相应的命令，总体功能对应父命令，部分功能对应子命令；然后，充分考虑人类记忆的局限性（即所谓“7±2”原则或“33”原则），命令系统最好组织为一棵两层的多叉树； 最后，应尽可

27、能减少用户完成一个操作所需的动作（如单击鼠标、拖曳鼠标和敲击键盘等）并为熟练用户提供操作的快捷方式。（4） 设计用户界面的各种细节。此步骤包括设计一致的用户界面、耗时操作的状态反馈、“undo”机制、帮助用户记忆的操作序列和自封闭的集成环境等。此类问题的详细讨论见第十二章人机界面设计。（5） 增加用户界面专用的类与对象。用户界面专用类的设计与所选用的图形用户界面（Graphic User Interface,GUI）工具或者支持环境有关。一般而言，需要为窗口、菜单、对话框等界面元素定义相应的类，这些类往往继承自 GUI工具或者支持环境提供的类库中父类。最后，还需要针对每个与用户命令处理相关的界

28、面类，定义控制设计模型中的其他类的方法。（6） 利用快速原形演示 ，改进界面设计 。为人机交互部分构造原形，是界面设计的基本技术之一。为用户演示界面原型，让他们直观感受目标软件系统的使用方法，并评判系统是否功能齐全、方便好用。第四节精化设计模型经过前面的分析和设计步骤，设计模型已相当丰富，包含了较完整的静态结构模型（顶层架构图、类图）和动态行为模型（交互图）。现在有必要对这些模型再进行分析和优化，以生成高质量的设计模型，为后续的实现阶段奠定坚实的基础。对设计模型的精化需考虑以下任务：（1）以顶层架构图为基础，精化目标软件系统的体系结构；（2）精化类之间的关系；（3）精化类的属性和操作；（4）针

29、对具有明显状态转换特征的类，设计状态图；（5）针对比较复杂的类方法，设计活动图。本节首先介绍UNL状态图，然后依次介绍完成上述任务的方法。一、状态图状态图用来描述一个特定类的对象的所有可能状态以及因事件而引起的状态转移。状态图的节点包含状态名和活动（activity）两部分内容。活动是可选的，可分为如下四种：（1）entry活动。一旦对象进入该状态，相应的活动即被触发执行。（2）exit活动。一旦对象离开该状态，相应的活动被触发执行。（3）do活动。 当对象位于状态时，执行相应的活动，对象的状态不变。（4）onevent活动。当对象位于该状态并且接收到某一事件后，执行相应的事件响应活动。在状态

30、图的状态转移边上可以附加以下信息：事件名（事件参数表）条件表达式 / 动作 事件目标。事件名（事件参数表）第一个事件是引发对象状态迁移的触发事件；条件表达式表示此转移边所代表的状态迁移的发生条件；动作表示对象在进行状态迁移的同时还将执行的处理功能；最后一个事件表示对象在进行状态迁移时还可以向其他对象发送的事件。所有上述语法成分都是可选项，并不是必需的。如果状态转移边上没有触发事件，则表明对象在到达该边的源节点时，内部活动执行完结后自动触发状态迁移，但是是否真正发生状态迁移还取决于条件表达式的真假。如果条件表达式不存在，则认为迁移条件恒成立。一张状态图可以包含一个初态和一到多个终态。基本的UML

31、状态图如图5-2-5所示。 UML的状态图是一种结构化的状态图，即其状态可以进一步细分为多个子状态，子状态之间可以拥有“and”和“or” 两种关系。对象处于复合状态s1 and s2当且仅当对象既处于子状态s1，又处于子状态s2 ；对象处于复合状态s1 or s2当且仅当对象处于子状态s1或者处于子状态s2。带有复合状态的UML状态图如图 8-4-1中，“active”状态是由“process”和“auth”两个子状态经过and合成构成的复合状态，“process”状态由“Checking”、“Waiting”和“Dispatching”3 个子状态经过or合成构成“auth” 状态由“Au

32、thorizing”和“Authorized”两个子状态经过or合成构成。在“active”的任一子状态上，如果发生了“cancel”事件，对象将进入“Cancelled”状态。在“Authorizing”状态下，如果权限验证失败，则立即进入“Rejected”状态。在对象到达“active”状态的两个and子状态的终态“Dispatching”和“Authorized”，并执行完这些状态中的活动（图8-4-1中未标出）之后，对象即进入“Delivered”状态。图 8-4-1带复合状态的UML状态图二、精化体系结构1.耦合度的判断 精化体系结构的主要目的是寻找一种理想的包划分方案，使得每个包

33、中直接包含的类的数量规模适中，包的边界清晰、自然、并且包间的耦合度较低。在包图中，包间耦合度主要取决于依赖关系，而包间的依赖关系又取决于分属于两个包的类之间的关系。下面是类之间耦合程度从高到低的判断方法：（1）继承关系；（2）构成关系；（3）聚合关系；（4）关联关系；（5）依赖关系；（6）两个类的对象受同一执行者变化的影响。在分析过程中，用包图表示了目标软件系统的顶层架构。随着分析和设计不断深入，原有包图中的包可能包含了过多的类，此时需要对其进行分拆。按照软件工程“强内聚、松耦合”的原则，这种分拆应该具有某种自然划分的性质，并且应尽可能降低划分以后的子包之间的耦合度。如果拟将包 P拆成分成子包

34、P1和P2，但包P中的类C与包P1和包P2中的类都存在相当密切的联系，那么可以考虑将类C根据包 P1和包P2的自然特征划分成两个类C1和C2，类C1置入包P1，类C2置入包P2，此后包P1和包P2形成松耦合关系。如果对类C的拆分难以进行，那就要考虑将类C移入较低层次的另一个包Q中，让包P1、包P2均依赖于包Q。弱化包间耦合的另一方法是调整类的摆放位置，将它们从一个包移至另一个更合适的包。有时也可以考虑适当地合并一些包，甚至不排除将数个包合并后再重新划分，最终达到“强内聚、松耦合”的目标。2.包间依赖关系遵守的原则完全排除包间的依赖关系即无必要，也不合理，但应尽量遵守以下原则：（1） 避免包间的

35、循环依赖关系，即排除包P1依赖于包P2，P2又依赖于P1的情形。（2） 在层次结构中，位于较低层次的通用包不应当依赖于较高层次中的专用包。（3） 在层次结构中，较高层次的包可以依赖于较低层次的包，但此种依赖应尽量在相邻的层次间发生。（4） 如果针对某些子系统专门划分了接口包和实现包，那么其他与该子系统相关的包只能依赖于接口包，不能依赖于实现包。三、精化类之间的关系1.类之间连接关系 本步骤的任务是在前面已获得的类图的基础上，详细研究类之间的连接关系：（1） 根据这些连接的语义强度，将它们精确地判定为 UML的依赖、关联、聚合或构成关系之一。（2） 确定连接的方向及参与连接的类的对象之间的数量对

36、应关系。（3） 根据软件重用的要求及软件结构简洁化、清晰化的要求，优化类之间的关系。2.面向对象程序设计手段前面确立的类之间的连接关系主要是在类的对象之间构筑消息传递通道。为了在对象obj1与对象obj2之间消息传递，面向对象的程序设计机制提供如下4种手段：（1） 引用全局对象。obj1直接引用作为全局对象的obj2。（2） 通过参数传递。obj2作为obj1的某项操作中的实在参数。（3） 引用局部对象。在obj1的某项操作的函数体中创建或获取obj2。（4） 通过类的成员变量。obj2作为obj1所属类的属性的取值。前三种类型的连接具有暂时性，obj1与obj2之间的连接仅在obj1的某项操

37、作的执行过程中建立，操作完成后连接即告终结。这种暂时性连接用UML 的依赖关系表示。对最后一种具有稳定性的连接关系，需要进一步分析。如果参与连接的两个类在现实世界中存在“皮之不存，毛将焉附”的部分整体关系，则用UML 的构成关系表示。否则，如果它们在现实世界中仍存在“多个整体对象可共享同一部件对象”的部分整体关系，则用UML 的普通聚合关系表示。如果以上两种假设均不成立，则原连接关系精化成UML中普通的关联关系。在某些情况下，系统需要表示关联关系本身具有的属性和操作，将这些属性或操作置于参与关联的两个类的任何一个中，均会破坏设计模型的自然性。此时，需要使用UML的关联类，如图8-4-3所示。U

38、ML的依赖、聚合和构成关系的方向性是非常明显的。对UML的关联关系，设计人员要仔细推敲双向关联的必要性，尽量将关联单向化，仅保留确有必要的双向关联。因为单向关联更简单，实现代价的更小。对于UML 的关联、聚合和构成关系，需进一步考虑参与关联的类的对象之间的数量对应关系以及双方对象在关联中扮演的角色，如图 8-4-2和图8-4-3所示。图 8-4-2UML关联图图 8-4-3关联的精化设计3.类结构结构调整在精化类之间的关系时，往往需要考虑到软件重用的需要而对类结构进行调整：（1） 如果允许修改被重用的类，那么可以将被重用的类与当前设计模型中的类的共同属性和共同操作抽取至公共父类，然后适当调整两

39、个子类的定义，如图8-4-4所示。图 8-4-4为实现软件重用而调整类结构（2） 否则，可以采用“委托”的办法，在拟重用的类和被重用的类之间建立单向关联关系。这样，拟重用的类即可通过关联关系使用被征用的类的属性和操作，如图8-4-5所示。图 8-4-5采用委托法实现软件重用下面考虑利用继承关系精化设计模型。可以从已有的类出发，寻找某些类之间的公共属性和操作，引进新的父类捕获公共性，从而简化设计模型；也可以在一定范围内按照某种准则将所有的类划分为数个集合，针对每个集合的特性设计一个父类，让集合中的所有类成为该父类的子类，这样就通过引入新父类达到了分组管理相关类的目的。此外，如果设计模型中出现了多重继承，而目标软件系统拟采用的程序设计语言不支持多重继承，那么应该将多重继承化解为单重继承，化解方法如图8-4-6所示。图 8-4-6将多重继承化解为单重继承然后，根据“强内聚、松耦合”简单性、自然性等软件工程原则，可以对类之间的结构关系进行如下优化：（1） 合并相互通信频繁的类。属性和操作都非常简单的类可以合并至其他类中。（2） 分拆规模过大的类。特别地，如果一个类的属性可以区分为常用和罕用两部分，那么，为提高软件效率，可以将其分拆为一个“常用”类和数个“罕用”类，并在前