面向对象设计.ppt

第七章面向对象的设计方法,设计用例实现方案设计技术支撑方案设计用户界面精化设计模型,面向对象的设计方法,基于UML的面向对象设计方法将分析模型转换为设计模型。面向对象:分析模型-顶层架构图、用例与用例图、领域概念模型构成。设计模型-以包图表示的软件体系结构图以交互图表示的用例实现图完整、精确的类图复杂对象的状态图描述流程化处理过程的活动图,面向对象的软件设计过程,7.1设计用例实现方案,本节介绍UML交互图的语言机制和用例实现方案的设计方法。UML的交互图包括顺序图和协作图，适于用例实现方案的表示。用例实现方案的设计方法有三个步骤：(1)提取边界类、实体类和控制类；(2)构造交互图；(3)根据交互图精化类图。,7.1.1顺序图,UML四种类型的消息,(1)简单消息(SimpleMessage)以一种简单、抽象的函数表示对象之间的信息传递，不考虑通信过程的内部细节。简单消息在UML顺序图中用普通的有向箭头表示。(2)同步消息(SynchronousMessage)消息源发出消息后必须等待消息处理过程完毕并返回处理结果后，消息源才可继续执行后续操作。前面所述的自调用消息应该是同步的。同步消息的表示图元与简单消息相同，这表明UML在缺省情形下认为简单消息即为同步消息。,UML四种类型的消息,(3)异步消息(AsynchronousMessage)表示，消息源发出消息后不必等待消息处理过程的返回，即可继续执行自己的后续操作。异步消息主要用于描述实时系统中的并发行为。异步消息在UML顺序图中用一种特别的单向箭头表示(4)返回消息(Returnmessage)表示前面发送的消息的处理过程完结之后的返回结果。返回消息应该是同步的。在许多情况下，可以隐藏返回消息，但也可显式标出返回消息以示强调。返回消息用虚线有向箭头表示一个对象可以通过发送标准消息“new”来创建另一个对象。当一个对象被删除或自我删除时，该对象的生命线上的相应时间点应该用叉号(对象生命线终结符)标识。,7.1.2协作图,协作图用于描述相互合作的对象间的交互关系和链接关系。虽然顺序图和协作图都用来描述对象间的交互关系，但它们的侧重点不一样。顺序图强调消息交互的时间序，协作图则强调交互对象间的静态链接关系。从外观看，协作图并不采用单独的维度来表示时间推移，因此，协作图中的对象可以在二维平面中自由占位。对象之间的链接用于表示消息传递通道，消息标示于链接之上，消息的箭头指明消息的传递方向。在协作图中，消息的描述内容包含名称、参数、返回值以及序列号，返回值和序列号是可选的。,协作图,虽然协作图不强调消息传递的时间序，但借助于序列号可以表达时间序，序列号较大的消息发生较晚。消息序列号可以采用线性编号，但采用适当的多级编号会使消息之间的结构关系更清晰。如果一个对象在消息的交互过程中被创建，则可在对象名称之后标以new。类似地,如果一个对象在交互期间被删除，则可在对象名称之后标以destroy。,典型的协作图,例“1.1msg2”表明msg2是“对象1”为了处理“1.msg1”而发送的第一条消息“1.2msg4”是“对象1”为了处理“1.msg1”而发送的第二条消息“1.1.1msg3”表明msg3是“对象2”为了处理“1.1msg2”而发送的第一条消息，依此类推。,协作图的两种等价表示,7.1.3提取边界类、实体类和控制类,边界类描述目标软件系统与外部环境的交互，主要任务：(1)界面控制：包括输入数据的格式及内容转换，输出结果的呈现，软件运行过程中界面的变化与切换等。(2)外部接口：实现目标软件系统与外部系统或外部设备之间的信息交流和互操作。主要关注跨越目标软件系统边界的通信协议。(3)环境隔离：将目标软件系统与操作系统、数据库管理系统、应用服务器中间件等环境软件进行交互的功能与特性封装于边界类之中，使目标软件系统的其余部分尽可能地独立于环境软件。在UML类图中，边界类往往附加UML构造型boundary作为特别标识。,提取边界类、实体类和控制类,例如，“家庭保安系统”中的边界类有“输入键盘接口类”、“传感器接口类”、“警报器接口类”、“报警电话接口类”和“显示面板接口类”。实体类表示目标软件系统中具有持久意义的信息项及其操作。实体类的操作具有“内向收敛”特征，它们仅向目标软件系统的其余部分提供读、写信息项内容的必要的操作接口，并不涉及业务逻辑处理。实体类的UML构造型为entity。例如，“家庭保安系统”中的“异常事件”为实体类。,提取边界类、实体类和控制类,控制类作为完成用例任务的责任承担者，协调、控制其他类共同完成用例规定的功能或行为。对于比较复杂的用例，控制类通常并不处理具体的任务细节，但是它应知道如何分解任务，如何将子任务分派给适当的辅助类，如何在辅助类之间进行消息传递和协调。控制类的UML构造型为control。例如，“家庭保安系统”中，“用户命令处理器”和“监测器”均为控制类。,提取边界类、实体类和控制类,在讨论了边界类、实体类和控制类的基本概念之后，下面介绍如何从分析模型中的用例描述和领域概念模型出发获取这些类。通常情况下，执行者与用例之间的一种通信连接对应一个边界类。但是，如果两个以上的用例与同一执行者交互，并且这些交互具有共同的行为、完成相同或类似的任务，就可以考虑用同一边界类实现用例与执行者之间的交互。这就意味着边界类的作用范围可以超越单个用例。,提取边界类、实体类和控制类,实体类源于领域概念模型。有时也需要认真研读用例描述，从中发掘具有持久意义的信息项。如果执行者的属性需要持久保存，也可以建立相应于执行者的实体类。假设一个实体类A仅仅被系统中的另一个类B引用，并且系统勿需关心A的行为特征，那么，为了简化设计模型，应将A中信息项直接作为B的属性。如果A被系统中的多个类引用，或者A具有不容忽略的行为特征，那么应将A作为独立的实体类。,提取边界类、实体类和控制类,一个用例通常对应一个控制类。如果不同用例的任务有较多类似之处，也可以考虑在多个用例的实现方案中共享同一控制类，此种情况应审慎对待，不同用例所需要的控制、协调行为往往会有差异。对于那些事件流非常简单的用例，可以不设独立的控制类，直接在边界类中设置控制、协调功能，边界类在实体类的帮助下完成用例要求的功能及行为。,7.1.4构造交互图,在标识边界类、实体类和控制类之后，接下来的任务是，将分析模型中的用例描述转化成UML交互图，以交互图作为用例的精确实现方案。用例描述中已包含事件流说明。事件流中的事件应直接对应于交互图中的消息，而事件间的先后关系体现为交互图中的时序，对消息的响应则构成消息接收者的职责。这种职责在后续的设计活动中将被确立为类的方法。,构造交互图,对于比较复杂的用例，仅仅依靠控制类、边界类和实体类会使单个控制类过于庞大、复杂，它既承担控制、协调的任务，又承担复杂的计算任务。在设计复杂用例的实施方案时，应考虑为控制类设置一些独立的辅助类，让控制类将一些任务委托给辅助类完成。如，在“家庭保安系统”类图中，“系统配置管理器”和“日志管理器”就是这种意义上的辅助类。,构造交互图,UML顺序图的横向排列次序用例的主动执行者用户界面的边界类控制类实体类和辅助类外部接口和环境隔离层的边界类目标软件系统的边界之外的被动执行者按此布局，在顺序图中不应该出现穿越控制类生命线的消息，即，主动执行者向界面类发出命令，界面类将命令进行适当转换后传送至控制类，控制类通过消息请求辅助类、实体类的帮助，协调、控制它们共同完成来自主动执行者的命令。,构造交互图,控制类或辅助类可以向右侧的边界类发送消息，将信息或外部处理请求由边界类传向外部系统（被动执行者）。在用例描述中，许多用例除主事件流外，往往还包含备选事件流，以说明在某些特殊或者异常情况下的事件和响应动作序列。为易于理解，在设计模型中应该用分离的UML交互图分别表示事件流和每个备选事件流。按照上述布局规则绘制的典型的顺序图如图10.4所示,典型布局规则下的顺序图,构造协作图,由于顺序图能够非常直观地表达事件（消息）的时序，所以它比协作图更多地用于描述用例的实现方案。但是，当需要强调类之间的联系或连接时，就需要绘制协作图。协作图的布局规则控制类位于中心主动执行者和作为用户界面的边界类位于左上方作为外部接口和环境隔离层的边界类位于右上方辅助类和实体类分别位于控制类的左下、右下方。按照此布局规则绘制的典型的协作图如图10.5所示。,典型布局规则下的协作图,例家庭保安系统,在“家庭保安系统”中，用例“传感器监测”和“命令处理”的实现方案分别见图10.6和图10.7。为简洁，图10.6和图10.7未表示这两个用例中的日志功能，图10.7也未考虑配置命令的处理。,图10.6“传感器监测”用例的顺序图,图10.7“命令处理”用例的顺序图,7.1.5精化类图,在UML交互图中，对每个类的对象都规定了它必须响应的消息以及类的对象之间的消息传递通道。前者对应于类的操作，后者则对应于类之间的连接关系。因此，可以利用交互图精化分析模型中的类图，将交互图中出现的新类添加到原有类图中，并且对相关的类进行精化，定义其属性和操作。原则上，每个类都应该有一个操作来响应交互图中指向其对象的那条消息。但是，这并不意味着消息与操作一定会一一对应，因为类的一个操作可能具有响应多条消息的能力。同理，两个类之间的一条连接关系也可以为多条消息提供传递通道。为了简化设计模型，也为了提高重用程度，设计人员应该尽量使用已有的操作来响应新消息，并尽量使用已存在的连接路径作为消息传递的通道。如果两个类之间存在明确、自然的聚合或组合关系，则可以在类图中直接用相应的UML图元符号表示类间的聚合和组成关系，这两个关系均可提供消息传递通道。,精化类图,接下来讨论如何根据交互图确立类的属性。类的操作完成消息响应责任的能力，来源于两方面的知识，一是类本身具有的信息，即类的属性，二是类能够找到的其他类，通过其他类协助其完成消息响应。在综合考虑这两个因素之后，类的操作应该明确哪些子任务可通过消息传递路径委托给其他类完成，哪些子任务必须由自身完成。根据后一种子任务的需要，结合领域和业务知识即可推导出类应具有的属性。在图6.16的基础上，得出“家庭保安系统”的类图如图10.8所示。为简洁见，图10.8仅标出控制类“监测器”和“用户命令处理器”的方法，以及实体类“异常事件”的属性，有兴趣的读者可自行添加其余的属性和方法。,图10.8“家庭保安系统”的精化类图,7.2设计技术支撑方案,在许多软件项目中，应用功能往往都需要一组技术支撑机制为其提供服务。例如，对分布式应用软件（包括电子商务应用、企业ERP系统等）而言，需要数据持久存储服务、安全控制服务、分布式事务管理服务、并发与同步控制服务、可靠消息服务等。这些技术支撑设施并非业务需求的直接组成部分，但形态各异的业务处理功能全都有赖于它们提供的公共技术服务。让每个业务功能的设计者直接面对裸机、基本操作系统或基本网络环境来完成软件实现方案，那是不可思议的。,设计技术支撑方案,技术支撑方案应该为多个用例的软件实现提供技术服务，所以，它应该成为整个目标软件系统中全局性的公共技术平台。当用户需求发生变化时，技术支撑方案应具有良好的稳定性。这就要求软件设计者选用开放性和可扩充性较好的技术支撑方案。如果目标软件系统的顶层架构采用分层方式，那么，技术支撑方案应该位于层次结构中的较低层次。,设计技术支撑方案,技术支撑方案的设计取决于目标软件系统对公共技术服务的需求设计人员对软件技术手段的把握和选取如，对分布式应用系统，设计人员必须了解分布构件技术、基于应用服务器的软件开发技术等。本节的后续部分以数据持久存储服务、并发与同步控制服务为例，探讨技术支撑方案的设计方法，最后介绍技术支撑方案与用例实施方案的融合。,7.2.1数据持久存储服务,设计数据持久存储服务的目的是，将目标软件系统中依赖于系统运行环境的数据存取部分与其他部分分离。数据存取通过一般的数据管理系统(如文件系统、关系数据库或面向对象数据库)实现，实现细节因数据存储介质的种类而异，但这些细节被集中在数据持久存储服务中，系统的其他部分与存储介质的种类和数据存储的实现方法无关。这样既有利于软件的扩充、移植和维护，又简化了软件设计、编码和测试的过程。,数据持久存储服务,数据持久存储服务的设计包括，定义数据格式和定义数据存取操作两部分。(1)定义数据格式。根据目标软件系统对数据存储的需求，考虑持久存储介质的特性，设计数据的存储格式。如，针对文件系统，需要定义用于保存数据的文件类别、每类文件的记录格式；针对关系数据库，需要定义表格的字段名称、类型、关键字、约束条件等；针对面向对象数据库(OODB)，数据格式的定义相对简单，因为OODB直接支持对象的存储和读取。,数据持久存储服务,(2)定义数据存取操作。数据持久存储服务至少包含数据的存储和读取两种操作。存储操作负责将实体对象中的属性数据写至持久存储介质读取操作则负责从持久存储介质中的序列化数据恢复对象的属性值。可以定义适用于所有实体类的存取操作，也可以分别针对不同的实体类定义不同的存取操作。数据存取操作一般以服务类的形式为系统的其他部分提供数据持久存储服务。在引入持久存储服务之后，目标软件系统的其他部分对持久存储介质的访问必须通过该服务进行，不能直接访问。,7.2.2并发与同步控制服务,设计并发与同步控制服务的目的是，将目标软件系统中依赖于系统运行环境的并发与同步控制部分和其他部分分离，其他部分中有关并发与同步控制功能的实现均通过该服务来完成。并发与同步控制服务提供的功能包括：（1）进程/线程的定义与启动；（2）进程/线程的终止；（3）进程/线程的状态查询；（4）同步点的设置及进程/线程在同步点的信息交换，等。这些功能应封装在服务类之中。,7.2.3技术支撑方案与用例实现方案的融合,技术支撑方案往往包含数个公共技术服务子系统。这些子系统无论其规模大小和内部复杂度高低，都应该提供数量较少的外部接口。所有的上层应用功能对公共技术服务的调用均通过访问这些外部接口而实现。为了融合技术支撑方案和用例实施方案，只需要对相应的UML交互图中添加必需的公共技术服务子系统接口，让控制类的对象与该接口所代表的公共服务对象进行消息交互。对于数据持久存储服务，与之交互的可以是实体类或者控制类。至于这些接口在交互图中的布局位置，则依其所提供服务的性质的不同而有所变化：,技术支撑方案与用例实现方案的融合,(1)先考虑数据持久存储服务。在引入此服务以后，用例中有关数据持久的实现有两种策略：一是让控制类对象调用此服务实现数据存取实体类对象在数据保存的过程中先向控制类对象提供数据，再由控制类对象调用服务将数据存至持久介质（如数据库、文件等），数据读取的过程则为此过程的逆过程。二是让实体类对象直接调用此服务实体类对象负责自己的数据的读取和保存。相比较而言，后者更为简洁、自然。对于图10.4，如果右侧的边界类与公共数据持久存储服务子系统的接口类的功能多有重叠，应该考虑将二者合并。,技术支撑方案与用例实现方案的融合,(2)再考虑安全控制服务。此类服务的子系统接口在顺序图中应位于控制类的紧邻右侧。(3)最后考虑分布式事务管理服务、并发与同步控制服务及可靠消息服务。它们的接口类在顺序图中可以位于控制类与右边边界类之间的任意位置，但不应插入两个辅助类或两个实体类中间。,技术支撑方案与用例实现方案的融合,现在讨论技术支撑方案之类图与迄今获得的其他类图的融合问题。如果前者比较简单，可以考虑将技术支撑方案的类图直接与其他类图合并，并建立公共技术服务类与其他类之间的必要连接。此时，有必要在公共技术服务类上以UML构造型进行特殊标识。如果公共技术服务子系统中包含较多的服务类，它们应单独构成类图，利用UML的包机制进行适当分组，并将这些包置于系统的体系结构图中的较低层次（相对而言，应用功能应位于较高层次）。,7.3设计用户界面,需求分析和软件设计阶段都必须考虑人机交互问题。需求分析阶段要确定人机交互的属性和外部服务设计阶段要给出有关人机交互的所有系统成份，包括：用户如何操作系统、系统如何响应命令、系统显示信息的报表格式等。,设计用户界面,HIC设计的策略与步骤为：(1)熟悉用户并对用户分类。设计人员应深入用户环境，考虑用户需要完成的任务、完成这些任务需要什么工具支持以及这些工具对用户是否适用。不同类型的用户要求不同，一般可按技术熟练程度、工作性质和访问权限对用户分类，以便尽量照顾到所有用户的合理要求，并优先满足某些特权用户。,(2)按用户类别分析用户工作流程与习惯。在用户分类的基础上，从每类中选取一个用户代表，建立包括下列内容的调查表，并通过对调查结果的分析判断用户对操作界面的需求和爱好：姓名期望软件用途特征(年龄、文化程度、限制等)主要要求与爱好技术熟练程度任务客观场景描述,设计用户界面,(3)设计并优化命令系统。在设计一个新命令系统时，应尽量遵循用户界面的一般原则和规范，必要时参考一些优秀的商品软件。根据用户分析结果确定初步的命令系统，然后再优化。命令系统既可为若干菜单、菜单栏，亦可为一组按钮。,设计用户界面,优化命令系统应考虑命令的顺序，一般常用命令居先，命令的顺序与用户工作习惯保持一致；根据外部服务之间的聚合关系组织相应的命令，总体功能对应父命令，部分功能对应子命令；充分考虑人类记忆的局限性(即所谓“72”原则或“33”原则)，命令系统最好组织为一棵两层的多叉树；应尽可能减少用户完成一个操作所需的动作(如点按、拖曳和击键等)，并为熟练用户提供操作捷径,设计用户界面,(4)设计用户界面的各种细节。此步骤包括：设计一致的用户界面风格；耗时操作的状态反馈；“undo”机制；帮助用户记忆操作序列；自封闭的集成环境等。此类问题的详细讨论见“第十二章人机界面设计”。,设计用户界面,(5)增加用户界面专用的类与对象。用户界面专用类的设计与所选用的图形用户界面(GUI)工具或者支持环境有关。一般而言，需要为窗口、菜单、对话框等界面元素定义相应的类，这些类往往继承自GUI工具或者支持环境提供的类库中的父类。最后，还需要针对每个与用户命令处理相关的界面类，定义控制设计模型中的其他类的方法。(6)利用快速原型演示，改进界面设计。为人机交互部分构造原型，是界面设计的基本技术之一。为用户演示界面原型，让他们直观感受目标软件系统的使用方法，并评判系统是否功能齐全、方便好用。,7.4精化设计模型,经过前面的分析和设计步骤，设计模型已相当丰富，包含了较完整的静态结构模型（顶层架构图、类图）和动态行为模型（交互图）。现在有必要对这些模型再进行分析、优化，以生成高质量的设计模型，为后续的实现阶段奠定坚实基础。,精化设计模型,设计模型精化的任务(1)以顶层架构图为基础，精化目标软件系统的体系结构。(2)精化类之间的关系。(3)精化类的属性和操作。(4)针对具有明显状态转换特征的类，设计状态图。(5)针对比较复杂的类方法，设计活动图。本节首先介绍UML状态图，然后依次介绍完成上述任务的方法。,7.4.1精化体系结构,精化体系结构的目的是，寻找一种包的划分方案，使得每个包直接包含的类的数量适中，包的边界清晰、自然，并且包间的耦合度较低。在包图中，包间耦合度取决于包间依赖关系，而依赖关系又取决于分属于两个包的类之间的关系。类之间的耦合程度（从高到低）排列：（1）继承关系。（2）构成关系。（3）聚合关系。（4）关联关系。（5）依赖关系。（6）两个类的对象受同一执行者变化的影响。,精化体系结构,在分析过程中，用包图表示了目标软件系统的顶层架构。随着分析和设计不断深入，原有包图中的包可能包含了过多的类，此时需要对其进行分拆。按照软件工程“强内聚、松耦合”的原则，这种分拆应该具有某种自然划分的性质，并且尽可能降低划分以后的子包之间的耦合度。如果拟将包P拆分成子包P1和P2，但包P中的类C与包P1和包P2中的类都存在相当密切的联系，那么可以考虑将C根据包P1和包P2的自然特征划分成两个类C1和C2，C1置入P1，C2置入P2，此后P1和P2形成松耦合关系。如果对C的分拆难以进行，那就要考虑将C移入较低层次的另一个包Q中，让P1、P2均依赖于Q。弱化包间耦合的另一方法是调整类的摆放位置，将它们从一个包移至另一更合适的包。有时也可以考虑适当地合并一些包，甚至不排除将数个包合并后再重新划分，最终达到“强内聚、松耦合”的目标。,精化体系结构,完全排除包间的依赖关系既无必要，也不合理。但是以下原则要尽量遵守：(1)避免包间的循环依赖关系，即，排除包P1依赖于包P2、P2又依赖于P1的情形(2)在层次结构中，位于较低层次的通用包不应当依赖于较高层次中的专用包。(3)在层次结构中，较高层次的包可以依赖于较低层次的包，但此种依赖应尽量在相邻的层次间发生。(4)如果针对某些子系统专门划分了接口包和实现包，那么，其他与该子系统相关的包只能依赖于接口包，不能依赖于实现包。,7.4.2精化类之间的关系,本步骤的任务是在前面已获得的类图的基础上，详细研究类之间的连接关系：(1)根据这些连接的语义强度将它们精确地判定为UML的依赖、关联、聚合或构成关系之一；(2)确定连接的方向及参与连接的类的对象之间的数量对应关系；(3)根据软件重用的要求及软件结构简洁化、清晰化的要求优化类之间的关系。,精化类之间的关系,前面确立的类之间的连接关系主要是在类的对象之间构筑消息传递通道。为了在对象obj1与对象obj2之间实现消息传递，面向对象的程序设计机制提供四种手段：（1）引用全局对象。obj1直接引用作为全局对象的obj2。（2）通过参数传递。obj2作为obj1的某项操作中的实在参数。（3）引用局部对象。在obj1的某项操作的函数体中创建或获取obj2。（4）通过类的成员变量。obj2作为obj1所属类的属性的取值。,精化类之间的关系,前三种类型的连接具有暂时性，obj1与obj2之间的连接仅在obj1的某项操作的执行过程中建立，操作完成后连接即告终结。这种暂时性连接用UML的依赖关系表示。对最后一种具有稳定性的连接关系，需要进一步分析。如果参与连接的两个类在现实世界中存在“皮之不存，毛将焉附”型的部分整体关系，则用UML的构成关系表示。否则，如果它们在现实世界中仍存在“多个整体对象可共享同一部件对象”的部分整体关系，则用UML的普通聚合关系表示。如果以上两种假设均不成立，则原连接关系精化成UML中普通的关联关系。,图10.10UML关联类,在某些情况下，系统需要表示关联关系本身具有的属性和操作，将这些属性或操作置放于参与关联的两个类之任何一个均会破坏设计模型的自然性。此时需要使用UML的关联类，如图10.10所示。,关联类的精化设计,关联类的精化设计,UML的依赖、聚合和构成关系的方向性是非常明显的。对UML的关联关系，设计人员要仔细推敲双向关联的必要性，尽量将关联单向化，仅保留确有必要的双向关联。因为，单向关联更简单、实现代价更小。对于UML的关联、聚合和构成关系，需进一步考虑参与关联的类的对象之间的数量对应关系以及双方对象在关联中扮演的角色，如图10.10和图10.11所示。,关联类的精化设计,在精化类之间的关系时，往往需要考虑到软件重用的需要而对类结构进行调整：(1)如果允许修改被重用的类，那么可以将被重用的类与当前设计模型中的类的共同属性和共同操作抽取至公共父类，然后适当调整两个子类的定义。如图10.12所示。(2)否则，可以采用“委托”的办法，在拟重用的类和被重用的类之间建立单向关联关系。如此，拟重用的类即可通过关联关系使用被重用的类的属性和操作。如图10.13所示。,为实现软件重用而调整类结构,图10.13采用委托法实现软件重用,精化继承关系,接下来，考虑利用继承关系精化设计模型。可以从已有的类出发，寻找某些类之间的公共属性和操作，引进新的父类捕获公共性，从而简化设计模型；也可以在一定范围内按照某种准则将所有的类划分为数个集合，针对每个集合的特性设计一个父类，让集合中的所有类成为该父类的子类，这样就通过引入新父类达到了分组管理相关类的目的。此外，如果设计模型中出现了多重继承，而目标软件系统拟采用的程序设计语言不支持多重继承，那就应该将多重继承化解为单重继承，化解方法如图10.14所示。,图10.14将多重继承化解为单重继承,类的精化,最后，根据“强内聚、松耦合”、简单性、自然性等软件工程原则，对类之间的结构关系可以进行如下优化：(1)合并相互通信频繁的类。属性和操作都非常简单的类可以合并至其他类中。(2)分拆规模过大的类。特别地，如果一个类的属性可以区分为常用和罕用两部分，那么，为提高软件效率，可以将其分拆为一个“常用”类和数个“罕用”类，并在前者和后者之间建立聚合关系，“罕用”类的实例应按需创建。(3)定义嵌入类。如果类class1和类class2之间存在关联关系，但class2的对象在整个软件系统中仅被class1的对象使用，并且class2规模不大，那么可以考虑将class2嵌入class1的内部。引进嵌入类的好处是使设计模型更加简单，付出的代价是，无论是否有必要，类class2的对象都将随class1对象的实例化而存在，这样可能浪费存储,7.4.3精化类的属性和操作,对于类的每项属性，在设计模型中，可以定义属性的名称、类型、初始值、取值范围及属性说明，后三项内容是可选的。操作的基本内容包括名称、参数表（含参数的名称和类型）、返回类型、功能描述。如果操作比较复杂，还需要用文字或UML活动图说明操作的实现算法。属性和操作的作用范围有以下三种：(1)public：对软件系统中的所有类均可见。(2)protected：仅对本类及其子类可见。(3)private：仅对本类可见。确定属性和操作的作用范围的基本原则是，尽量缩小作用范围，每个类仅公开那些为直接响应消息所必需的操作。原则上，属性不宜公开，如果确有必要让其他类读取或者设置该属性的值，应通过在本类中增设相应的get/set函数来实现。,精化类的属性和操作,类的属性和操作还可区分为类级和实例级两种。类级的属性和操作为该类的所有实例对象所共享，它们在系统运行期间仅有单份拷贝。实例级的属性和操作则在类的每个实例对象中拥有一份独立拷贝，这些拷贝之间互不影响。为了提高运行效率，有时需要在对象的生命同期中保存经计算生成的一些中间结果，以免重复计算，用空间换时间。此时可以引入导出属性作为类的私有属性。但是，在业务逻辑处理过程中，要特别注意导出属性值容易失效的问题。,精化类的属性和操作,按照本章前面所述的方法和过程，最终得出“家庭保安系统”的类图如图10.15所示。图10.15与图10.8的区别在于，显式标出了关联类的对象之间的数量对应关系，并且引进了技术支撑方案中的服务类。图10.15中未标出的类的属性和方法留给有兴趣的读者自行添加。,7.4.4状态图,状态图用来描述一个特定类的对象的所有可能状态以及因事件而引起的状态转移。状态图的结点包含状态名和活动(activity)两部分内容。活动是可选的，它们又分为四种：(1)entry活动：一旦对象进入该状态，相应的活动被触发执行。(2)exit活动：一旦对象离开该状态，相应的活动被触发执行。(3)do活动：当对象位于该状态时，执行相应的活动，对象的状态不变。(4)on-event活动：当对象位于该状态并且接收到某一事件后，执行相应的事件响应活动。,状态图,在状态图的状态转移边上可以附加以下信息：事件