第9章软件详细设计

第九章

软件详细设计软件工程(第三版)齐治昌 谭庆平 宁洪2012年8月3/19/2021国防科技大学计算机学院2第九章

软件详细设计详细设计的任务与过程模型用例设计子系统设计构件设计类设计数据模型设计设计整合与验证3/19/2021国防科技大学计算机学院3第九章

软件详细设计

软件体系结构设计关注软件的较高层结构，包括结构中的软件设计元素及其协作关系；软件详细设计关注这些设计元素内部的设计，包括如何设立若干抽象级别更低、规模粒度更小的设计元素来分担某个高层设计元素的职责，及如何协同才能适当地完成该职责。

详细设计与体系结构设计没有绝对的分隔，体系结构设计过程和技术也可部分地适用于详细设计。

如，大型软件的体系结构中，某个规模较大的子系统，详细设计前可能需要先完成该子系统的体系结构设计。

软件设计的细化工作应该推迟至详细设计，而不是在体系结构设计阶段完成。

详细设计是软件体系结构与软件实现之间的桥梁，是确保体系结构设计成果得以落地的关键环节。3/19/2021国防科技大学计算机学院4软件详细设计本章介绍详细设计的主要工作任务、用以指导完成这些任务的详细设计过程模型探讨详细设计过程中的七大主要活动用例设计、子系统设计、构件设计、类设计、数据模型设计、设计整合及详细设计验证活动涉及的过程、技术和方法。限于篇幅，不能进一步探讨7.4节引入的设计模式，建议读者进一步研习之，因为许多设计模式[9-1]都是软件工程学术界和产业界关于详细设计的经验结晶。3/19/2021国防科技大学计算机学院59.1详细设计的任务与过程模型详细设计的任务对体系结构设计和界面设计的成果进行细化和精化，最终获得高质量的详细设计模型。详细设计模型的质量要素：⑴正确性――模型中若干设计元素通过模型指定的协作方式能够实现所有的软件需求；⑵优化性――模型以充分优化的方式实现所有的软件需求；⑶设计充分性――模型的细化和精确程度足以作为软件编程人员的全部工作基础，没有含混、笼统和歧义之处。3/19/2021国防科技大学计算机学院6详细设计的任务与过程模型体系结构模型和界面设计模型中的设计元素包括：子系统、构件、关键设计类和界面类详细设计的任务：对它们进行细化和精化。这些设计元素必须通过体系结构模型和界面设计模型验证，设定的协作关系能够正确地、以充分优化的方式完成软件需求，否则，详细设计模型的正确性就将成为无本之木。3/19/2021国防科技大学计算机学院7详细设计的任务与过程模型验证活动要完成三项相互关联的工作：⑴将体系结构模型和界面设计模型中的设计元素整合或者连接起来以协同工作，因为大部分软件需求项的实现过程均涉及界面类和软件系统内部的设计元素；⑵以软件需求为基准，检验已有的设计模型的正确性和充分优化性；⑶添加必要的细节（如关键设计类的属性和操作、子系统或构件的对外接口函数等）使软件需求

得以完整地实现，甚至需要对已有设计元素的

某些方面（例如职责分派、接口定义等）进行

必要的调整。3/19/2021国防科技大学计算机学院8详细设计的任务与过程模型本书将所有的功能性软件需求项均表示为用例，验证活动将大量沿用用例分析的成果，所以我们将其称为“用例设计”将设计模型中若干设计元素协同完成用例规定的功能的过程称为用例的实现方案。用例设计已经为详细设计模型的正确性和充分优化性奠定了坚实基础详细设计的充分性对体系结构模型中的设计元素（子系统、构件和关键设计类）和界面设计模型中的界面类展开细化和精化这些工作分别称为子系统设计、构件设计和类设计（包括关键设计类和界面类的设计）。3/19/2021国防科技大学计算机学院9详细设计的任务与过程模型数据密集型应用：在完成子系统、构件、类和外部接口的详细设计之，必须明确哪些数据需要持久保存，如何在持久存储媒介中组织这些数据以提高数据存储和查询的性能。这些工作称为“数据模型设计”。数据模型设计直接影响到需要保存或使用持久数据的设计元素的详细设计，也会对整个目标软件系统（尤其是数据密集型系统）的性能和可伸缩性产生影响。3/19/2021国防科技大学计算机学院10详细设计的任务与过程模型详细设计是软件设计过程的最后环节在将设计模型提交给软件编程人员展开软件实现工作之前，有必要将前述的用例设

计、子系统设计、构件设计、类设计、数

据模型设计的成果进行整合和必要的优化，并再次对其进行验证，研究其是否足以支

撑所有软件需求项的实现，是否还有进一

步优化的空间，是否存在设计不充分的现

象。3/19/2021国防科技大学计算机学院11详细设计过程的主要活动用例设计针对需求分析模型中的每个用例，基于体系结构和用户界面设计模型给出的设计元素，设计用例的软件实现方案。通过详细考察每个设计元素与其他设计元素协同完成用例功能的过程，可以更精确地定义这些设计元素。3/19/2021国防科技大学计算机学院12详细设计过程的主要活动（2）子系统设计。体系结构设计活动仅设定了子系统的职责和对外接口，并未深究子系统的内部实现方案。子系统设计的任务是，确定子系统内部的结构，即，设置包含于其中的更小粒度的子系统、构件和设计类，明确它们之间的协作关系，确保它们能够协同实现子系统接口规定的所有功能和行为。3/19/2021国防科技大学计算机学院13详细设计过程的主要活动（3）构件设计类似于子系统设计，构件设计是对体系结构设计活动中设定的构件的内部实现方案的设计，任务是定义构件内部的设计元素及协作方法。构件的内部元素既可以是类，也可以是粒度更细的（子）构件。3/19/2021国防科技大学计算机学院14详细设计的任务与过程模型（4）类设计软件设计活动围绕软件需求的实现设定了许多类，包括界面类、直接出现于体系结构中的关键设计类、实现用例功能或行为的设计类、子系统或构件中的设计类。类设计负责对这些类进行必要的设计精化，使之精细到可以提交软件实现的程度。具体的类设计工作包括：确定类的可见范围，定义类的操作和属性，精化类之间的关系，等。3/22/2021国防科技大学计算机学院15详细设计的任务与过程模型（5）数据模型设计。

数据模型指，需要持久保存的数据条目的内容及条目之间的逻辑联系。

数据模型还包含持久存储机制提供的优化数据操作性能的特殊设施如，关系数据库中的存储过程。数据模型设计活动包括：确定设计模型中类的对象、这些对象的哪些属性需要持久保存；在设计模型与持久存储机制支持的数据组织方式（例如关系数据库中的表、关键字、外键等）之间进行映射；为提高数据存储、操作的性能，设计持久存储机制的优化设施。3/22/2021国防科技大学计算机学院16详细设计的任务与过程模型（6）设计整合与验证。整合前面获得的所有设计模型，检查并消解它们之间的不一致性，剔除冗余性，以用例为导引构建设计模型中所有元素协力完成用例目标的完整视图，最终形成设计规约。基于该设计规约，重新审视所有软件需求项的实现方案，研究如何化解迄今标识出来的所有重要的全局风险，在此过程中验证详细设计的正确性、优化性和设计充分性。对中、大型软件项目，上述详细设计过程往往需要迭代多次，经过反复求精后才能获得高质量的软件设计模型。迭代的方式与体系结构设计过程类似，见7.3节。3/22/2021国防科技大学计算机学院179.2

用例设计用例设计针对软件需求的分析模型中的每个用例，在前述的体系结构设计和界面设计给出的设计元素的基础上，设计用例的详细实现方案。

用例设计活动要确保界面设计模型、体系结构模型与软件需求的符合性。用例设计的主要任务针对每个用例，联合采用体系结构设计中确定的软件设计元素（包括子系统、构件、关键设计类），以及用户界面设计中确定的界面类（包括屏幕类及输入表格类），完整地实现每个用例要求的业务处理功能和交互动作序列。通过详细考察每个设计元素与其协作者之间的协作关系，以求更精确地定义这些设计元素，例如补齐必要的细节，调整接口定义等。3/22/2021国防科技大学计算机学院18用例设计在软件的详细设计过程中首先展开用例设计，是为了在子系统设计、构件设计、类设计及数据模型设计尚未全面铺开前，以软件需求为准则检验体系结构模型和界面设计模型的符合性，及早发现不一致性并立即改正。5.4节已采用UML交互图表示若干分析类为实现用例要求的功能施行的交互动作序列。这些UML交互图位于软件需求的分析模型中，为用例实现方案的设计奠定了良好基础。用例设计的首要活动就是，以体系结构设计模型和界面设计模型中的设计元素替代UML交互图中的分析类，通过设计元素的职责及其交互协作完整地实现用例。此项活动称为用例实现方案的（详细）设计。3/22/2021国防科技大学计算机学院19用例设计

如5.4所述，在需求分析阶段，基于分析类的逻辑职责设置及分析类之间的协作关系，可以推导出分析类图。

在软件设计阶段，基于设计元素的职责及其协作关系的

UML交互图表示，可以推导出设计类图。

这些设计类图将成为详细设计模型中的重要成分并作为面向对象软件编程实现的主要依据。

前述的两项活动分别针对单个用例进行的，有必要站在全局的高度整合并优化整个软件系统的设计成果。用例设计的子活动归纳如下：设计用例实现方案；导出设计类图；整合并优化用例实现方案。3/22/2021国防科技大学计算机学院209.2.1

设计用例实现方案按照用例逐个给出用UML交互图表示的软件实现方案，研究分析模型中该用例的UML交互图表示，它是生成基于设计元素的用例实现方案的主要基础。需要研究体系结构模型和界面设计模型中与当前待设计的用例相关的设计元素，它们构成用例实现方案的实际参与者。研究与当前待设计的用例相关的非功能性需求项，设计师在用例实现方案的设计过程中必须给出其实现方法。3/22/2021国防科技大学计算机学院21设计用例实现方案分析模型已给出基于分析类的用例实现方案，要明确分析类的职责与设计元素的操作之间的对应关系，将需求分析阶段生成的UML交互图转换成设计阶段需要的交互图。分析类与设计元素的对应关系多种多样，可能的情形包括：一个分析类的一项职责由一个设计元素的单项操作完整地实现。这种情形最简单，从分析模型中的交互图到设计模型中的交互图的变换方法见图9.1(a)。一个分析类的一项职责由一个设计元素的多项操作来实现。这种情形下交互图的变换方法见图9.1(b)。3/22/2021国防科技大学计算机学院22设计用例实现方案一个分析类的一项职责由多个设计元素协同完成。此时用例设计师应考虑如何将分析类的职责分配给这些设计元素，以及这些设计元素如何通过必要的消息传递来进行协作。见图9.1(c)。对于在分析模型的交互图中出现的执行者，如果该执行者由软件系统的用户扮演，那么在设计模型中其对应的设计元素应该为界面设计模型的界面类，其发送消息、响应消息的职责应该由界面类的操作来实现，因为用户是通过界面与软件系统交互的；如果该执行者是外部设备或外部软件系统，那么应该将其替换为7.6.1节中设置对应于该执行者的子系统。图9.1从分析模型中用例的顺序图表示到设计模型中用例实现方案的变换方法(a)说明：A’、B’分别是对应于分析类A、B的设计元素，msg’是分析模型中msg在设计模型中的对应消息3/22/2021国防科技大学计算机学院23图9.1

从分析模型中用例的顺序图表示到设计模型中用例实现方案的变换方法(b)

说明：分析类B处理msg的职责被分解为设计元素B’中处理msg1’，…，msgn’的操作3/22/2021国防科技大学计算机学院24图9.1

从分析模型中用例的顺序图表示到设计模型中用例实现方案的变换方法(c)说明：在设计模型中，消息msg’触发分析类B中处理msg的职责的执行3/22/2021国防科技大学计算机学院253/22/2021国防科技大学计算机学院26设计用例实现方案从分析模型中的交互图生成设计模型中的交互图并非简单的语法替换，软件设计师必须确保后者能够准确、完整地实现前者规定的业务逻辑处理功能及行为。设计师应当选用尽可能简单、高效的实现方法，并思考实现方法如何满足相关的非功能性需求。设计模式可以发挥很好的作用，软件设计师必须熟练掌握有关的设计模式知识，并在此步骤中灵活运用。3/22/2021国防科技大学计算机学院27例9.1

用例实现方案的详细设计针对家庭保安系统中的“传感器监测”用例，在图5-16所示的基于分析类的用例实现方案的基础上，结合第七章得到的逻辑体系结构（见图7-18），得到仍以UML顺序图表示的用例实现如图9.2(a)和(b)。为图形简洁，本例分别针对门窗和烟雾传感器监测两种情况展开详细设计。读者也可以尝试将它们合并表示为单张UML顺序图。图9.2

家庭保安系统中“传感器监测”用例的设计(a)

门窗传感器监测3/22/2021国防科技大学计算机学院28图9.2

家庭保安系统中“传感器监测”用例的设计(b)

烟雾传感器监测3/22/2021国防科技大学计算机学院293/22/2021国防科技大学计算机学院30主要的详细设计点Monitor类的对象（简称Monitor对象，下同）从系统配置子系统中获取传感器配置数据的动作被移入到Monitor类的构造函数之中，所以将其从用例实现方案中删除。3/22/2021国防科技大学计算机学院31主要的详细设计点将体系结构中设置的子系统和构件纳入用例实现方案，必要时调整消息的名称、参数及期望的消息处理功能，使之与子系统和构件的对外接口保持一致。在家庭保安系统的逻辑体系结构的基础上，“传感器监测”用例的实现必须借助四个构件：

MovingObjectMonitorTelephoneDialerTextToSpeech（例7-3）LogManager（例7-13）TelephoneDialer构件的dial函数具有重复拨号的功能，所以VideoMonitor和SmogMonitor对象勿需考虑失败重拨问题。3/22/2021国防科技大学计算机学院329.2.2

构造设计类图基于第七章给出的逻辑体系结构和前面给出的用例实现方案的UML交互图表示，不难将分析模型中的分析类图（见5.4.4节）变换为详细设计模型

中的设计类图。设计类图中的结点为各种设计元素，包括子系统、构件和通常的UML类。对UML类图稍作扩充以表示详细设计类图：允许在类图中出现子系统和构件，它们的类别可以采用不同的UML构造型或者不同的图元符号来表示，见图9.3。3/22/2021国防科技大学计算机学院33构造设计类图依据用例实现方案的交互图推导出设计类图的过程和方法类似于从分析模型之交互图推导出分析类图的过程，参见5.4.4节，这里不再赘述。不同的是，这里的推导过程同时也是从分析类图到设计类图的精化过程，应该沿用分析类图中可以续用的机制，并且确保设计类图相对于分析类图的逻辑符合性。3/22/2021国防科技大学计算机学院34例9.2

设计类图的构造针对家庭保安系统，基于分析类图（见图5-21）逻辑体系结构（见图7-18）和“传感器监测”用例的实现方案（见图9.2），导出图9.3所示的设计类图。图5-21中除输入键盘接口（KeyboardInteraction）显示面板接口（DisplayPanelInteraction）外的其他分析类的职责均已在逻辑体系结构的设计过程中置入传感器监测子系统（safeHomeMonitor）系统配置子系统（safeHomeConfigManager）日志管理构件（logManager）所以图9.3与图5-21的差别较大，而与图7-18的差别较小。3/22/2021国防科技大学计算机学院35主要的详细设计点根据图9.2可以推知，safeHomeMonitor的对外接口中必须包含analyseVideoSensorData和analyseSmogSensorData两个函数；

DisplayPanelInteraction类中必须包含

showCurStatus函数。根据图9.2，设置两个新的设备接口类：

VideoSensorInteraction和SmogSensorInteraction，并将它们作为原

SensorInteraction的子类。添加必要的关联和依赖关系。图9.3 家庭保安系统的设计类图（初步）3/22/2021国防科技大学计算机学院363/22/2021国防科技大学计算机学院379.2.3

整合并优化用例实现方案在针对每个用例完成9.2.1和9.2.2所述的工作后，软件设计师必须从全局和整体的高度整合并优化所有的用例实现方案。具体工作包括：将具有相同或相似职责的多个设计元素整合为一个。将具有相同或相似功能的多个操作整合为一个。采用继承或代理机制（见5.4.4节）对设计元素中的公共操作进行抽象。确保所有用例实现方案在同一软件系统中和谐共存，无逻辑冲突。根据上述调整相应地修改前述的交互图和设计类图。3/22/2021国防科技大学计算机学院38整合并优化用例实现方案最后，还需要基于用例设计的成果复核非功能性软件需求的实现程度。可能时，将有关的非功能需求分解至设计元素或其操作，使之成为设计元素的实现约束。必要时，以非功能需求和相关的功能需求的优化实现为目标，重新调整用例实现方案和设计类图。3/22/2021国防科技大学计算机学院399.3

子系统设计

子系统设计的任务是，确定子系统内部的结构，即，设置包含于其中的、粒度更小的子系统、构件和设计类，明确它们之间的协作关系，确保它们能够协同实现体系结构模型中该子系统的服务提供接口所规定的全部功能和行为。

软件设计师首先必须确立子系统内部的设计元素，根据体系结构模型中确定的子系统的职责及其对外接口针对这些设计元素逐个分派职责，并研究它们如何协同以完成子系统的每项职责。

设计师必须根据子系统内部设计元素的职责及其协作关系推导出子系统的详细设计类图，因为类图是软件实现工程师的主要编程基础和依据。

如果状态图或活动图有助于软件实现工程师对于当前子系统的理解和实现，设计师不妨构造之，以便为子系统的编程实现奠定更好的基础。3/22/2021国防科技大学计算机学院409.3.1

确立内部设计元素在体系结构设计模型中，已经定义了其中每个子系统的接口。这些接口中的服务提供接口实际上规定了子系统必须承担的职责。这些职责必须由子系统内部的设计元素来完成。换言之，为了完成子系统的服务提供接口中规定

的职责，需要在子系统中设置构件、设计类，有

时甚至需要设置当前子系统的子系统，并确定它

们的职责和协作关系，通过它们的分工和合作来

完成当前子系统的接口中规定的所有功能和行为。3/22/2021国防科技大学计算机学院41确立内部设计元素此项工作属于软件详细设计的范畴，其目的是确保软件实现人员能够可行地、精确地实现当前子系统。如果在分析模型中有对应于当前子系统的状态图或活动图，那么，它们将有助于设计师确定上述软件设计元素的设置、职责和协作关系定义。合适的设计模式无疑也将帮助设计师做出更优化的设计决策。3/22/2021国防科技大学计算机学院42确立内部设计元素在分派子系统内部的设计元素的职责时，必须注意利用体系结构模型中定义的其他设计元素（包括技术支撑设施和可复用的设计资产）已经提供的功能，不能在目标软件系统的不同模块重复实现相同或相似的功能。利用的方式有两种：通过本子系统的服务请求接口（如果存在的话）；直接调用构件的服务提供接口或设计类的公开函数。上述工作的成果可以表现为一系列的UML交互图，其中每张交互图说明子系统内的软件元素为完成子系统接口中规定的某项特定职责而展开的协作行动，见图9.4。3/22/2021国防科技大学计算机学院43例9.3子系统设计－确立内部设计元素并明确协作关系“传感器监测”（safeHomeMonitor）是家庭保安系统中最关键的子系统，在第七章所述的逻辑体系结构设计的过程中，已经将“命令处理器”（CommandHandler）、“监测器”（Monitor）、异常事件（ExEvent）、传感器接口（SensorInteraction）、警报器接口（AlarmInteraction）报警电话接口（AlarmTelephoneInteraction）纳入该子系统，3/22/2021国防科技大学计算机学院44例9.3子系统设计－确立内部设计元素并明确协作关系详细设计继续沿用这些设计元素，并将例9.2中引入的两个新的设备接口类

VideoSensorInteraction和SmogSensorInteraction，它们是SensorInteraction的子类。图9.2已经描述了该子系统在响应接口函数

analyseVideoSensorData和analyseSmogSensorData的调用时内部设计元素之间（以及它们与外部构件之间）的协作关系。本例通过safeHomeMonitor响应接口函数reset的调用时动作过程来进一步精化其设计，见图9.4。图9.4 传感器监测子系统的详细设计的交互图表示（局部）3/22/2021国防科技大学计算机学院453/22/2021国防科技大学计算机学院469.3.2

导出设计类图对于面向对象的软件实现而言，类图是其主要的编程基础和依据。有必要从子系统详细设计的UML交互图表示出发推导出子系统的详细设计类图。具体的推导方法类似于从分析模型之交互图推导分析类图的方法，请见5.4.4节。在子系统的详细设计类图中，建议采用某种方式显式区分子系统内部的设计元素与位于子系统之外、为子系统提供服务的其他设计元素。如，图9.5即采用垂直虚线分割子系统内、外的设计元素。3/22/2021国防科技大学计算机学院47例9.4

子系统设计－－导出设计类图仍以“传感器监测”（safeHomeMonitor）子系统为例说明如何生成子系统的详细设计类图。可供利用的工作基础包括：逻辑体系结构（见图7-17）；分析类图（见图5-21）；详细设计阶段得到的表示子系统对外接口实现的顺序图表示（见图

9.2和图9.4）。如例9.3所述，safeHomeMonitor包含CommandHandler、Monitor（及其子类VideoMonitor

和

SmogMonitor）、ExEvent、SensorInteraction（及其子类VideoSensorInteraction

和SmogSensorInteraction）、AlarmInteraction和AlarmTelephoneInteraction，它们构成safeHomeMonitor的详细设计类图的主要结点。3/22/2021国防科技大学计算机学院48子系统设计－－导出设计类图以这些类为基础，综合图5-21图9.2和图9.4，推导它们的主要操作：switchOn、switchOff和reset（据图9.4）操作显然应置入CommandHandler类。analyseVideoSensorData、onMovingObjectDetected和describeEvent（据图

9.2(a)）操作应置入VideoMonitor类，其中后者应该是private操作。同理，

analyseSmogSensorData、isNormal和describeEvent（据图9.2(b)）操作应置入

SmogMonitor类。describeEvent重复出现是因为

它在Monitor的两个子类中的实现方法完全不同，当然，其标记（signature）可以提升至Monitor类。3/22/2021国防科技大学计算机学院49子系统设计－－导出设计类图（3）据图9.2(a)和(b)，onTelephoneConnected和onDialFailed两个操作对Monitor的两个子类而言是公共的，所以将其置入Monitor类。接下来，考虑safeHomeMonitor子系统在运作过程中需要的外部子系统、构件及设计类。据图9.2和图9.4，它需要外部构件

MovingObjectMonitor、TelephoneDialer和TextToSpeech，需要构件logManager和securityService，还需要设计类

DisplayPanelInteraction。图9.5将它们布局于垂直分割线的右方，以示其位于safeHomeMonitor子系统的边界以外。3/22/2021国防科技大学计算机学院50子系统设计－－导出设计类图采用5.4.4节所述的“根据消息传递确定类之间的连接”的方法初步确定以上所有类之间的关联关系。对于子系统和构件，外部的设计元素对其功能的调用一般均通过接口，从该元素到接口之间不可能存在单向关联，因为关联关系含数量对应关系，而接口没有数量的意义应通过从外部设计元素到接口之间的单向依赖关系表示这种调用。得到的safeHomeMonitor子系统的详细设计类图如图9.5。图9.5 传感器监测子系统的阶段性详细设计类图3/22/2021国防科技大学计算机学院513/22/2021国防科技大学计算机学院529.3.3

设计状态图与活动图如果子系统具有明显的状态特征，通过UML状态图可以更清晰地描述子系统的行为特征，并且状态图有助于软件实现工程师理解子系统、实现子系统，那么可以为子系统构造状态图。否则，一般没有必要绘制子系统的状态图。如果当前子系统的状态图在分析模型中已

经存在，那么需要对此状态图进行必要的

精化，确保它与子系统的详细设计模型（包括前述的UML交互图和详细设计类图）协调一致。3/22/2021国防科技大学计算机学院53设计状态图与活动图在有必要的情况下软件设计师可以通过构造子系统的活动图来帮助软件实现工程师理解子系统、实现子系统。活动图有两种：⑴表示子系统内部的设计元素协同完成子系统的某些功能；⑵表示作为一个黑箱的子系统与外部设计元素协同完成更大范围内的某些功能。如果在分析模型中与当前子系统相关的活动图已经存在，需要对活动图进行精化。3/22/2021国防科技大学计算机学院549.4

构件设计构件设计的任务是，为实现构件的服务提供接口中规定的职责而在其内部设置子构件和类，明确它们的职责，定义其对外接口，确定它们之间的协作关系。构件设计与子系统设计非常类似，本节仅讨论构件设计不同于子系统设计之处。3/22/2021国防科技大学计算机学院559.4.1

为复用设计构件构件的详细设计必须确保接口与实现相分离。实现了同一接口的两个构件可以等价替换，无论它们的内部实现方法如何不同。构件使用方的任何变化都不应导致构件的修改，除非构件自身提供的服务需要调整。构件应具有上下文无关性，可以在不同的上下文环境中不加修改地被复用。构件可以与外界相互协作，但它们不能相互干扰，例如，构件不能与外界共享公共的数据结构。在可预期的应用场景下，相同或相似的服务可以由同一构件来提供。软件设计师必须分析当前及将来可能的多种应用场景中对构件的功能需求的相同点和不同点，采取以下办法来提高构件的可复用性。3/22/2021国防科技大学计算机学院56为复用设计构件分离相同点和不同点，将相同点实现为构件。以参数化手段从不同点中抽象出公共部分，通过构件的不同配置覆盖不同点。参数化可以直接针对构件的服务功能来进行，也可以利用构件的定制机制（见9.4.2）。将相同点抽象为框架（framework[84]），其中的不同点被定义为框架中的抽象服务。构件设计者只需设定抽象服务的标记（signature），并在构件实现时直接使用它们。这些抽象服务的实现体将延迟至构件使用方在复用构件时再根据实际需求来提供，见

9.4.2节有关构件继承和委托机制的论述。3/22/2021国防科技大学计算机学院579.4.2

设计构件的定制机制构件的定制机制是提高构件的灵活性和可复用性的主要手段之一。它与构件的接口设计和内部实现机制的设计息息相关。最简单的定制机制就是将构件接口中定义的对外服务参数化，构件使用者通过使用不同的实参值来定制自己需要的构件服务。另一种构件定制方法是，以构件为单元定义配置信息，通过配置项的具体取值的不同来实现构件功能的定制。当构件设计者希望通过一组参数来影响构件接口定义中的多个对外服务时，此种定制机制优于前述的针对逐个服务的参数化机制。3/22/2021国防科技大学计算机学院58设计构件的定制机制可以采用基于继承和基于委托的定制机制。它们必须与9.4.1节所述的基于框架的抽象方法配套使用。采用前者时，构件的使用者利用面向对象的继承机制为框架中的抽象服务提供适合于特定应用场景的实现体。采用后者时，构件在运行过程中将允许使用方定制的部分功能委托给使用方提供的抽象服务的实现体，或者说，框架型构件采用回调（callback）的方法动态整合构件使用者挂接到框架之上的抽象服务的实现体。使用这两种定制机制时，框架中的抽象服务将在构件的服务请求接口中定义，构件对外提供的服务则在服务提供接口中定义，见图9.6。3/22/2021国防科技大学计算机学院59例9.5

构件的详细设计以日志管理构件为例说明如何生成构件的详细设计类图。这里的工作基础和方法与例9.4非常相似，不再赘述。详细设计类图如图9.6。图9.6 日志管理构件的结构及接口3/22/2021国防科技大学计算机学院603/22/2021国防科技大学计算机学院619.4.3

设计构件的组装机制构件的组装与普通的类之间的组装有着显著的差异：类可以基于源代码进行组装，但构件通常基于执行

码进行组装。构件的设计师必须在使用者无法获知构件源代码的条件下设计相应的组装机制。最简单的组装机制是基于构件描述文档的组装，即，构件设计师在每个构件上附加一个描述性文档。该文档可以采用（结构化）自然语言，也可以采用

XML[144]来描述。使用者通过该文档来了解构件服务的使用方法（包括定制方法）和约束条件，或者，支持构件组装的软件开发环境读取并向构件使用者展示该文档所描述的构件接口及其使用方法。由构件使用者以手工方式完成构件组装。3/22/2021国防科技大学计算机学院62设计构件的组装机制上述方式有两个明显的缺陷：当构件接口发生变化时，接口描述文件必须相应修改；因人为错误可能导致接口描述文件与实际的构件接口不一致。自描述接口可以圆满地解决上述问题。其基本思想是，支持构件组装的软件开发环境或者构件的运行平台自动从构件的执行码中综合出构件的接口定义。在自描述接口机制的支持下，构件组装有两种途径：静态组装与动态组装。前者是指，构件使用者在开发阶段通过软件开发环境获取构件接口定义，设计调用构件服务的源代码；后者是指，构件使用者在开发阶段对构件接口定义一无所知，仅通过代码在程序执行时动态获取构件接口定义、动态构建对构件服务的调用代码。3/22/2021国防科技大学计算机学院63设计构件的组装机制静态组装机制的执行效率较高，但当构件接口发生变化时使用代码必须相应修改；动态组装机制虽然可以在一定程度上避免由于构件接口的变化导致构件使用代码的变化，但其执行效率远低于静态组装，所以，除非特别必要一般不宜采用。构件接口自描述机制的典型代表是Java的反射机制[145]，JavaBeans[145]和CORBA[90]均同时支持静态组装与动态组装。限于篇幅，本书不能展开讨论这些有关构件设计的高级技术，感兴趣的读者请参阅文献[145][90]。3/22/2021国防科技大学计算机学院649.5

类设计类设计的任务是，对体系结构模型中出现的关键设计类，以及界面设计模型、子系统设计模型和构件设计模型中出现的类进行细化设计，以使它们足够精细，能够直接提交给软件构造阶段进行编码实现。类的设计工作针对设计模型中每个具体的类而展开。首先需要确定类的可见范围。如果类仅仅被其所在的包所使用，那么该类就是

“私有的”（private）；否则就是“公开的”（public）。确定类的可见范围应遵循以下原则：尽量缩小类的可见范围，即，除非确有必要，否则应将类“隐藏”于包的内部。3/22/2021国防科技大学计算机学院659.5.1

精化类间关系接下来需要精化类之间的关系、精化类的操作和属性。这些工作的内容较多，将分别在9.5.1和9.5.2两节专题探讨。如果类的典型对象的状态图或活动图有助于软件实现工程师理解或实现这个类，设计师就应该考虑构造其状态图或活动图，详见9.5.3节。3/22/2021国防科技大学计算机学院66精化类间关系为了使类图精细化至足够的程度以供软件实现工程师展开编程实现，软件设计师必须详细研究所有的设计类图中类之间的所有连接关系，并完成以下三项工作：根据这些连接的语义强度将它们精确地判定为UML的依赖、关联、聚合或构成关系之一；确定连接的方向及参与连接的类的对象之间的数量对应关系（多重性，

multiplicity）；根据软件复用的要求及软件结构简洁化、清晰化的要求，优化类之间的关系。3/22/2021国防科技大学计算机学院67（一）确定类间连接关系类之间连接关系的语义强度从高到低依次是：继承，组合，聚合，（普通）关联，依赖。按照软件工程“强内聚、松耦合”的原则，在不违背面向对象的简单性、自然性原则的前提下，应该尽量采用语义连接强度较小的关系。此外，可以从类间连接关系在软件系统运行时发挥的作用－－消息传递通道－－的视角来选择最合用的连接关系。3/22/2021国防科技大学计算机学院68确定类间连接关系为了在对象obj1与对象obj2之间实现消息传递，面向对象的程序设计机制提供四种手段：引用全局对象。obj1直接引用作为全局对象的obj2。通过参数传递。obj2作为obj1的某项操作中的实在参数。引用局部对象。在obj1的某项操作的函数体中创建或获取obj2。通过类的成员变量。obj2作为obj1所属类的属性的取值。3/22/2021国防科技大学计算机学院69确定类间连接关系前三种类型的连接具有暂时性，obj1与obj2之间的连接仅在obj1的某项操作的执行过程中建立，操作完成后连接即告终结。这种暂时性连接用UML的依赖关系表示。对最后一种具有稳定性的连接关系，需要进一步分析。如果参与连接的两个类在现实世界中存在

“皮之不存，毛将焉附”型的部分—整体关系，则用UML的构成关系表示。否则，如果它们在现实世界中仍存在“多个整体对象可共享同一部件对象”的部分—整体关系，则用UML的普通聚合关系表示。如果以上两种假设均不成立，则原连接关系精化成UML中普通的关联关系。图9.7

关联类示例在某些情况下，系统需要表示关联关系本身具有的属性和操作，将这些属性或操作置于参与关联

的两个类之任何一个均会破坏设计模型的自然性。此时需要使用UML的关联类，如图9.7所示。关联类的精化设计示例如图9.8所示。3/22/2021国防科技大学计算机学院70图9.8

关联类的精化设计示例3/22/2021国防科技大学计算机学院713/22/2021国防科技大学计算机学院72（二）确定类间连接关系的方向和多重性UML的依赖、聚合和构成关系的方向性是非常明显的。对UML的关联关系，设计师要仔细推敲双向关联的必要性，尽量将关联单向化，仅保留确有必要的双向关联。因为，单向关联更简单、实现代价更小。对于UML的关联、聚合和构成关系，需进一步考虑参与关联的类的对象之间的数量对

应关系以及双方对象在关联中扮演的角色。3/22/2021国防科技大学计算机学院73（三）优化类间连接关系在精化类之间的关系时，往往需要考虑到软件复用的需要而对类之间的连接关系进行调整。如果允许修改被复用的类，那么可以将被复用的类与当前设计模型中的类的共同属性和共同操作抽取至公共父类，然后适当调整两个子类的定义，如图9.9所示。否则，可以采用面向对象的代理机制，在拟复用的类和被复用的类之间建立单向关联关系。如此，拟复用的类即可通过关联关系使用被复用的类的属性和操作，详见5.4.4节图5-20。图9.9 为实现软件复用而优化类间关系的示例3/22/2021国防科技大学计算机学院743/22/2021国防科技大学计算机学院75优化类间连接关系考虑利用继承关系精化设计模型。可以从已有的类出发，寻找某些类之间的公共属性和操作，引进新的父类捕获公共性，从而简化设计模型；也可以在一定范围内按照某种准则将所有的类划分为数个集合，针对每个集合的特性设计一

个父类，让集合中的所有类成为该父类的子类，这样就通过引入新父类达到了分组管理相关类

的目的。此外，如果设计模型中出现了多重继承，而目标软件系统拟采用的程序设计语言不支持多重继承，那就应该将多重继承化解为单重继承，化解方法如图9.10所示。图9.10 将多重继承化解为单重继承的示例3/22/2021国防科技大学计算机学院763/22/2021国防科技大学计算机学院77优化类间连接关系最后，根据“强内聚、松耦合”、简单性、自然性等软件工程原则，对类之间的结构关系可以进行如下优化：合并相互通信频繁的类。属性和操作都非常简单的类可以合并至其他类中。分拆规模过大的类。特别地，如果一个类的属性可以区分为常用和罕用两部分，那么，为提高软件效率，可以将其分拆为一个“常用”类和数个“罕用”类，并在前者和后者之间建立聚合关系，“罕用”类的实例应按需创建。3/22/2021国防科技大学计算机学院78优化类间连接关系（3）定义嵌入类。如果类class1和类class2之间存在关联关系，但

class2的对象在整个软件系统中仅被class1的对象使用，并且class2规模不大，那么可以考虑将

class2嵌入class1的内部。引进嵌入类的好处是使设计模型更加简单；付出的代价是，无论是否有必要，类class2的对象都将随class1对象的实例化而存在，这样可能浪费存储空间。3/22/2021国防科技大学计算机学院799.5.2

精化属性和操作为了使类图精细化至足够的程度以供软件实现工程师展开编程实现，软件设计师必须详细研究所有的设计类的属性和操作，并完成以下工作：细化属性和操作的内容；确定属性和操作的作用范围；添加必要的属性或操作；明确标示静态的属性和操作。3/22/2021国防科技大学计算机学院80（一）细化属性和操作的内容对于类的每项属性，在设计模型中，可以定义属性的名称、类型、作用范围、初始值、约束条件（例如取值范围）及属性说明，后三项内容是可选的。操作的基本内容包括名称、参数表（含参数的名称和类型）、返回类型、功能描述、前提条件（pre-condition）、出口断言（post－condition）、实现算法。前提条件是指，软件执行进入此操作前必须满足的逻辑断言；出口断言是指，在此操作执行完成的时刻点必然成立的逻辑断言。它们一般表示为逻辑表达式[53]。在设计过程中，并非对所有的操作都必须给出前提条件和出口断言，它们是可选的。3/22/2021国防科技大学计算机学院81细化属性和操作的内容如果操作的功能相对复杂，软件实现工程师不能从文字性的操作功能描述推导出软件实现代码，那么设计师还必须进行操作的算法设计。算法设计的结果可以用（结构化）自然语言表达，也可以采用UML活动图来表达。算法表示的精细化程度必须符合以下标准：合格的软件实现工程师能够基于算法表示编写出符合设计师期望的程序代码。3/22/2021国防科技大学计算机学院82（二）确定属性和操作的作用范围属性和操作的作用范围有以下三种：public：

对软件系统中的所有类均可见。protected：仅对本类及其子类可见。private：仅对本类可见。确定属性和操作的作用范围的基本原则是，尽量缩小作用范围，每个类仅公开那些为直接响应消息所必需的操作。原则上，属性不宜公开，如果确有必要让其他类读取或者设置该属性的值，应通过在本类中增设相应的get/set函数来实现。3/22/2021国防科技大学计算机学院83（三）添加必要的属性为了实现类之间的关联、聚合和构成关系，可能需要在类中设置属性。如果存在从类A到类B之间的1对1关联或聚合（非构成）关系，那么可以考虑在A中设置类型为B的指针或引用（reference）的属性。如果存在从A到B之间的1对多关联或聚合（非构成）关系，那么可以考虑在A中设置一个集合类型的属性，集合元素的类型为B的指针或引用。对构成关系的处理类似于普通聚合关系，但是属性的类型（在1对多的情形下，集合元素的类型）应修改为B而非B的指针或引用。3/22/2021国防科技大学计算机学院84添加必要的属性在Java中既没有指针类型，也不可能表示非引用的类型B，所以Java中构成和普通聚合关系的属性表示并无差异。但是，在程序逻辑中，对构成关系而言，一旦整体类的对象的生命终结，那么，属于此对象的部件类的对象必须被销毁；对普通聚合关系而言，是否将部件类的对象随同整体类的对象一并销毁则取决于业务逻辑的需要。3/22/2021国防科技大学计算机学院85添加必要的属性此外，如果类A与类B之间的关联关系是双向的，或者类图要求从部件类导航（navigate）至整体类，那么还需要将前述规则沿从B到A的方向再应用一次。必须指出的是，并非所有的关联关系均须表示为属性，只要A的对象能够通过某个方法获取与其关联的B的对象，就没有必要设置专门的属性，而是在需要时使用此方法即可。为了提高运行效率，有时需要在对象的生命周期中保存经计算生成的一些中间结果，以免重复计算，用空间换时间。此时可以引入派生属性作为类的私有属性。但是，在业务逻辑处理过程中，要特别注意派生属性值容易失效的问题。3/22/2021国防科技大学计算机学院86（四）添加必要的操作类的操作主要来源于体系结构模型、用例实现方案、子系统设计方案、构件设计方案中对类的职责（即类的对象必须响应的消息，以及在处理这些消息的过程中必须履行的职责）的规定。这里还需要针对每个类思考添加以下操作的必要性：（1）对象创建：类中每个对象的初始化操作。其功能通常包括属性取值的初始化和必要的资源申请。注意，在对象创建方法中，仅申请必须伴随对象整个生命周期的资源；单项操作需要的资源应该在该操作被相应的消息激活后再按需申请，不宜在在对象创建之初就开始占用资源。3/22/2021国防科技大学计算机学院87添加必要的操作对象删除：类中每个对象在其生命周期结束前执行的最后一个操作。该操作提供了释放对象占用的资源的最后机会。为杜绝资源泄漏（即，系统不再需要曾经申请到的资源，但系统已经失去了这些资源的“句柄”，已不可能释放此资源），软件设计者和实现者必须善用此机会，确保类的所有对象均能够“清白”地退出系统。对象比较：比较类的两个实例对象是否相同，或者比较它们的大小。对象复制：将类的一个实例对象的属性值复制到另一对象。3/22/2021国防科技大学计算机学院88（五）明确标示静态的属性和操作类的属性和操作可区分为实例级和类级两种。实例级的属性和操作在类的每个实例对象中拥有一份独立拷贝，这些拷贝之间互不影响。反之，类级的属性和操作为该类的所有实例对象所共享，它们在系统运行期间仅有单份拷贝，所以又称为静态的属性/操作，在面向对象的

程序设计语言中常以关键字“static”标示。严格地说，静态的属性/操作有损于面向对象概念体系的简单性和自然性，应该尽量避免使用。3/22/2021国防科技大学计算机学院899.5.3

设计状态图与活动图状态图适于表示跨越多个用例的单个对象的行为。在详细设计过程中，并不需要对所有类的对象都绘制状态图，只要针对具有明显的状态特征、并且具有比较复杂的状态―事件―响应行为的类设计状态图即可。图9.11 家庭保安系统中“监测器”（Monitor）对象的状态图例9.6类的详细设计－－设计状态图在家庭保安系统中，“监测器”类的典型对象具有比较明显的状态特征，其状态―事件―响应行为如图9.11所示。3/22/2021国防科技大学计算机学院903/22/2021国防科技大学计算机学院91设计状态图与活动图类的活动图有两种：表示类中每个复杂操作的实现算法的过程细节；将类的典型对象作为一个黑箱，以活动图表示它与外部设计元素协同完成某项功能的过程。在详细设计过程中，并不需要对所有类的所有方法都绘制活动图，也不需要对所有的协同处理过程都设计活动图，只要针对具有比较复杂并且非常重要的处理过程设计活动图即可。此外，如果需要强调处理过程中并行性，应该使用活动图。如果与当前设计类相关的状态图或活动图在分析模型中已经存在，那么需要对它们进行精化，确保它们与整个详细设计模型协调一致。例9.7类的详细设计－设计活动图

在家庭保安系统中，

“监测器”类的子类

SmogMonitor中的

analyseSmogSensorData操作相对比较重要且复杂，其活动图如图9.12所示。3/22/2021国防科技大学计算机学院923/22/2021国防科技大学计算机学院939.6

数据模型设计在讨论数据模型的设计方法之前，先介绍一个相关概念：持久数据操作。它包括写入、查询、更新和删除四类基本操作以及由它们复合而成的业务数据操作。写入操作将数据从运行时的软件系统保存至数据库；查询操作按照特定的选择准则从数据库提取部分数据置入运行时软件系统中的指定对象；更新操作以运行时软件系统中的（新）数据替换数据库中符合特定准则的（旧）数据；删除操作将符合特定准则的数据从数据库中删除。3/22/2021国防科技大学计算机学院94数据模型设计数据模型设计的任务是，确定设计模型中需要持久保存的数据条目，基于数据模型[93][94]设计这些数据条目的组织方式，必要时还须设计特定于本软件项目将采用的数据库管理系统[94]的优化机制，以提高持久数据操作的性能。3/22/2021国防科技大学计算机学院959.6.1

确定持久数据条目数据模型设计的首要任务是确定设计模型中需要持久保存的类的对象及其属性。此动作必须在设计模型中相应的类已经相对稳定后才可执行。如果采用关系数据库，在面向对象设计模型中的类将对应于关系数据模型中的“表格”（table），对象将对应于“记录”（record），属性将对应于表格中的“字段”（field）或“列”（column）。哪些类的何种对象，以及这些对象的何种属性需要持久化，完全取决于业务应用对数据持久的需求。一般情况下，为节约持久存储空间，提高数据操作的效率，同时也为了避免数据库中的数据不一致性，派生属性不应进入持久存储。3/22/2021国防科技大学计算机学院96确定持久数据条目对于关系数据库，为了唯一地标识表格中的一条记录，需要确定表格中的某一个或者某些字段作为“关键字”字段。关键字必须确保：表格中任意两条记录在关键字字段上的值不会全部相同。关系数据模型中的表格仍然可以采用带构造型的

UML类来表示，见图9.13。其中<<table>>表示“表格”，<<key>>修饰关键字字段。例9.8 数据模型设计－－确定持久数据条目家庭保安系统中的需要保存的数据条目主要包括日志、异常事件和传感器配置信息，它们的详细设计如图9.13所示。图9.13

家庭保安系统中的持久数据条目3/22/2021国防科技大学计算机学院973/22/2021国防科技大学计算机学院989.6.2

确定持久数据的组织结构本节以关系数据库为例讨论持久数据的组织结构。在关系数据模型中，同一类型的数据组织为表格。不同类型的数据一般被置于不同表格，利用表格之间通过外部关键字（外键）搭建起来的关联，可以表示不同类型的数据之间的关联关系。如，在图9.14中，表格T_C2中的记录通过外键

key_for_C1的值可以获知相应的表格T_C1中的记录。确定持久数据的组织结构的关键在于，将面向对象的设计模型中类之间的关系映射到关系数据模型中表格之间关系。在数据模型中不需考虑依赖和实现关系，所以下面仅讨论从关联和继承关系到关系数据模型的映射方法。（一）一对一、一对多型关联关系的映射假设类C1、C2对应的表格分别为T_C1、T_C2，只要将T_C1中关键字字段纳入T_C2中作为外键，就可表示从T_C1到T_C2之间的一对一、一对多

型关联关系，见图9.14。图9.14 一对一、一对多型关联到关系数据模型的映射3/22/2021国防科技大学计算机学院993/22/2021国防科技大学计算机学院100（二）多对多型关联关系的映射在T_C1到T_C2之间引进新的交叉表格

T_Intersection，将T_C1和T_C2中关键字字段均纳入T_Intersection中作为外键，在T_C1与T_Intersection之间、T_C2与T_Intersection之间建立一对多关系，见图9.15。图9.15 多对多型关联到关系数据模型的映射3/22/2021国防科技大学计算机学院1013/22/2021国防科技大学计算机学院102（三）继承关系的映射假设C1是C2的父类，有两种方法在关系数据模型中表示它们之间的继承关系：将T_C1中的所有字段全部引入至T_C2，见图

9.16(a)。这种方法的弊端是，浪费了持久存储空间，并且容易因数据冗余而导致数据不一致性。仅将T_C1中关键字字段纳入T_C2中作为外键，见图9.16(b)。要从关系数据模型中获取C2的对象的全部属性，则需要联合T_C2中的记录和对应于外键值的T_C1中的某条记录。这种方法避免了数据冗余，但是在读取C2的对象时性能不如前一种方法。(a)

在子类对应的表格中复制父类的属性3/22/2021国防科技大学计算机学院103(b) 通过外键连接父、子类对应的表格

图9.16 多对多型关联到关系数据模型的映射3/22/2021国防科技大学计算机学院1043/22/2021国防科技大学计算机学院105例9.9

数据模型设计－确定持久数据的组织结构家庭保安系统的持久数据的组织结构非常简单，仍如图9.13所示。为了演示9.6.2节所述的设计方法，再以课程注册管理系统为例给出其持久数据的组织结构，如图9.17所示。Curriculum与CourseOffering之间存在1对多关系，所以，在T_CourseOffering中建立外键curriculumId指向T_Curriculum中的记录。3/22/2021国防科技大学计算机学院106数据模型设计－确定持久数据的组织结构Schedule与CourseOffering之间存在多对多关系，

Student与CourseOffering之间存在多对多关系，而Schedule与Student之间是一一对应的，所以，在T_Schedule与T_CourseOffering当中建立表格

T_CourseOfferingAndStudent，其中包含两个外

键，分别指向T_CourseOffering中的记录和

T_Schedule（及T_Student）中的记录，所以它可以同时表示Schedule与CourseOffering之间的多对多关系和Student与CourseOffering之间的多对多关系。对图9.17的进一步解释请见文献[17]。图9.17 课程注册管理系统中持久数据的组织结构3/22/2021国防科技大学计算机学院1073/22/2021国防科技大学计算机学院1089.6.3

确立持久数据操作这里考虑的持久数据操作是指，仅仅与持久数据本身有关、数据处理逻辑非常简单、因为使用频繁而对整个目标软件系统的性能有较大影响的数据操作。需要在数据模型中考虑的比较典型的操作有：数据完整性验证，对数据对象或其属性的批量处理，数据求和、求均值等。数据完整性又有两种：对表格中某些字段的取值范围的约束，以及一张表格中每条记录的外键所引用的另一张表格的记录必须存在。后者又称引用完整性。3/22/2021国防科技大学计算机学院109确立持久数据操作当前的关系数据库管理系统普遍支持两种形式的持久数据操作：存储过程和触发器[94]。存储过程是命名的SQL语句[94]块，它一经定义即可供反复调用。触发器是带有执行条件的SQL语句块，触发器仅由关系数据库管理系统在触发条件成立时自动执行，不能以其他方式显式调用。本步骤不是必需的，因为上述所有的持久数据操作既可采用存储过程或触发器来实现，也可以由数据持久存储服务（见7.6.1节）来实现。3/22/2021国防科技大学计算机学院110确立持久数据操作采用第一种方法的好处是执行效率较高，但是弊端也非常明显：存储过程和触发器破坏了面向对象的软件结构，并且，由于它们与具体的关系数据库管理系统密切相关，也破坏了目标软件系统相对于数据持久机制的独立性、可移植性。建议采用采用第二种方法，不要使用存储过程和触发器，除非数据模型设计师经过审慎评估后确认存储过程或触发器能够显著改善系统性能，并且这样的性能提升对于目标软件系统达到预定的性能指标确有必要，舍此别无它法。3/22/2021国防科技大学计算机学院1119.6.4

优化持久数据操作的性能在数据密集型应用中，持久数据操作的性能对于目标软件系统的整体性能表现起着至关重要的作用。在关系数据模型中，常用的持久数据操作性能优化方法有索引和反规范化两种。3/22/2021国防科技大学计算机学院112（一）索引的创建及优化索引是关系数据库管理系统提高数据查询效率最为有效的手段，它对持久数据操作的性能影响甚巨。应该针对关键字、经常出现在查询语句和数据更新语句的条件部分的字段建立索引。索引的代价是，在写入、更新或删除数据时必须进行额外的索引更新；此外，索引也要占据一定的持久存储空间。在决定对表格的哪些字段建立索引之前，数据模型设计师必须仔细分析各种数据操作的条件子句，以及它们的执行频度。3/22/2021国防科技大学计算机学院113索引的创建及优化如果增、删、改的执行频度高于查询的执行频度，或者前者的性能表现比后者更重要，那么被索引

的字段就不宜太多；不需要针对执行频度不高，并且对性能无特殊要求的查询建立索引；如果需要大批量地进行记录的增、删、改操作，那么应该先删除索引，在大批量操作完成后再重建索引。被索引的字段在表格的UML类表示中可以冠以构造型<<indexed>>。3/22/2021国防科技大学计算机学院114（二）反规范化如果需要一次性从多个表格中查询数据，关系数据库必须进行表格连接（table

join）。

表格连接操作的效率远低于单表查询，所以，在多表连接操作频繁执行时，系统性能会明显下降。此时，可考虑将多张表合并为一张表，这种手段称为“反规范化”，因为它与关系数据模型所要求的规范化设计原则[94]背道而驰。反规范化的代价是，针对未合并前的单表的查询操作效率降低，合并后数据更新的效率也会降低。所以，数据模型设计师必须权衡利弊，适度采用反规范化方法。3/22/2021国防科技大学计算机学院1159.7

设计整合与验证设计整合的任务是，汇总迄今获得的所有设计模型，包括体系结构模型、界面设计模型、用例设计模型、子系统/构件/类设计模型、数据模型，在全局范围内检查并消解它们之间的不一致性，剔除冗余性，最终形成设计规约。设计验证的任务是，基于设计规约，重新审视所有软件需求项（包括功能需求项――用例，以及非功能需求项）的实现方案，研究如何化解迄今标识出来的所有重要的全局风险，在此过程中验证详细设计的正确性、优化性和设计充分性。3/22/2021国防科技大学计算机学院1169.7.1

设计规约软件设计规约的主要内容包括：

(1)系统概述(1.1)文档概览：文档的结构、每部分的内容简介；文档的读者对象及阅读顺序导引。(1.2)术语定义：本文档中使用的所有术语、缩写、标识符的完整定义，特别包括在设计模型中出现的每个UML构造型的定义。(1.3)软件系统简述：宏观地描述目标软件产品的整体目标、功能，目标用户，运行环境。这些内容主要源自需求规约的“系统概述”部分（见5.7节）。3/22/2021国防科技大学计算机学院117设计规约(1.4)软件设计目标：与需求规约中的内容相对应，明确说明本文档中的设计模型实现了哪些功能性、非功能性需求。若有未予实现的需求，必须说明理由或延后实现的大致计划安排。(1.5)设计和实现约束：影响本软件产品的设计和实现的约束条件。如果没有变化，可以直接引用需求规约中的相应内容，或者省略此节。(1.6)参考文献：本文档引用的标准、相关的本项目的其他技术文档（至少包括需求规约）。3/22/2021国防科技大学计算机学院118设计规约(2)设计指南。描述设计过程中遵循的设计原则、规则，以及采用的非常识性的软件设计经验。这部分内容不仅有助于读者理解设计模型，而且有助于软件开发机构积累设计资产。(2.1) 用户界面设计指南。(2.2) 体系结构设计指南。(2.3) 用例设计指南。(2.4) 子系统设计指南。(2.5) 构件设计指南。(2.6) 类设计指南。(2.7) 数据模型设计指南。3/22/2021国防科技大学计算机学院119设计规约界面设计模型。包括屏幕瞬时快照的静态图示、界面流、屏幕类图，见第八章。体系结构模型。可以将体系结构模型作为单独的文档，在设计规约中直接引用此文档；对于规模不大的软件系统，也可以考虑将其内容嵌入设计规约中作为其中的一部分。不论采用何种方式，文档撰写者应该通过适当的引用或内容的统一编排，避免体系结构模型与设计规约（其余部分）的内容冗余或重复，并且确保二者之间的一致性。接口设计。描述当前软件系统与外部系统之间的交互协议。用例设计模型。以UML交互图的形式逐个用例地表示其实现方案，见9.2节。在用例设计步骤生成的设计类图应该整合至相应的子系统、构件或类设计模型之中，不必在此示出。3/22/2021国防科技大学计算机学院120设计规约(7)子系统设计模型。如果在体系结构模型中未对当前软件系统划分子系统，那么可省略此部分。(7.1)子系统1的设计模型(7.1.1)设计类图。描述子系统1的结构、其中各设计元素的职责及其关系。(7.1.2)交互图。描述子系统1中各设计元素之间的动态协作关系。(7.1.3)类设计模型。针对子系统1的设计类图中出现的每个类，逐个描述其职责、协作者、类的属性（包括属性的名称、类型、作用范围、初始值、约束条件、属性说明等）、类的方法（包括方法的名称、功能说明、参数的名称和类型、返回类型，以及可选的前提条件、出口断言、实现算法等）、类的状态图（可选）、与类相关的活动图（可选）。(7.1.4)状态图（可选）。子系统1的状态图。

(7.1.5)活动图（可选）。与子系统1相关的活动图。(7.2)子系统2的设计模型3/22/2021国防科技大学计算机学院121设计规约(7)子系统设计模型。如果在体系结构模型中未对当前软件系统划分子系统，那么可省略此部分。(7.1)子系统1的设计模型(7.1.1)设计类图。描述子系统1的结构、其中各设计元素的职责及其关系。(7.1.2)交互图。描述子系统1中各设计元素之间的动态协作关系。(7.1.3)类设计模型。针对子系统1的设计类图中出现的每个类，逐个描述其职责、协作者、类的属性（包括属性的名称、类型、作用范围、初始值、约束条件、属性说明等）、类的方法（包括方法的名称、功能说明、参数的名称和类型、返回类型，以及可选的前提条件、出口断言、实现算法等）、类的状态图（可选）、与类相关的活动图（可选）。(7.1.4)状态图（可选）。子系统1的状态图。(7.1.5)活动图（可选）。与子系统1相关的活动图。

(7.2)子系统2的设