软件工程讲义第七章设计概念

1、软件工程讲义第七章设计概念 软件工程 软件工程讲义第七章设计概念 第7章 设计概念 软件工程讲义第七章设计概念 主要内容 v软件工程中的设计软件工程中的设计 v设计过程设计过程 v设计概念设计概念 v设计模型设计模型 v小结小结 软件工程讲义第七章设计概念 设计工程 v设计创建了软件的表达或模型，但与分析模型设计创建了软件的表达或模型，但与分析模型 （关注于说明必需的数据、功能和行为）不同，（关注于说明必需的数据、功能和行为）不同， 设计模型提供了软件体系结构、数据结构、接设计模型提供了软件体系结构、数据结构、接 口和构件的细节，而这些都是实现系统必需的。口和构件的细节，而这些都是实现系统必需

2、的。 v设计要让软件工程师为将要构建的系统或产品设计要让软件工程师为将要构建的系统或产品 建立模型。在生成代码、进行测试以及在涉及建立模型。在生成代码、进行测试以及在涉及 大量最终用户使用之前，可能要评估该模型的大量最终用户使用之前，可能要评估该模型的 质量并进行改进。设计是确立软件质量的关键质量并进行改进。设计是确立软件质量的关键 步骤。步骤。 软件工程讲义第七章设计概念 设计工程 v设计可以采用很多不同的方法描绘软件。设计可以采用很多不同的方法描绘软件。 首先，设计必须体现系统或产品的体系结首先，设计必须体现系统或产品的体系结 构；其次，为各类接口建模，这些接口在构；其次，为各类接口建模，

3、这些接口在 软件和最终用户、软件和其他系统及设备软件和最终用户、软件和其他系统及设备 以及软件和自身组成的构件之间起到联系以及软件和自身组成的构件之间起到联系 作用；最后，设计用于构建系统的软件构作用；最后，设计用于构建系统的软件构 件。每个视图表现了不同的设计活动，但件。每个视图表现了不同的设计活动，但 是都要遵循一组基本的设计概念，这些设是都要遵循一组基本的设计概念，这些设 计概念指导着所有的软件设计工作。计概念指导着所有的软件设计工作。 软件工程讲义第七章设计概念 设计工程 v 在软件设计过程中，包含体系结构、接在软件设计过程中，包含体系结构、接 口、构件和部署表示的设计模型是主要的口、

4、构件和部署表示的设计模型是主要的 工作产品。工作产品。 v可以从以下诸方面来评估设计模型：确定可以从以下诸方面来评估设计模型：确定 设计模型是否存在错误、不一致或遗漏，设计模型是否存在错误、不一致或遗漏， 是否存在更好的方案可供选择，设计模型是否存在更好的方案可供选择，设计模型 是否可以在已经设定的限制、时间进度和是否可以在已经设定的限制、时间进度和 花费下实现。花费下实现。 软件工程讲义第七章设计概念 设计工程 v设计工程包括一套原理、概念和实践，可设计工程包括一套原理、概念和实践，可 以指导高质量的系统或产品开发。设计原以指导高质量的系统或产品开发。设计原 理建立了最重要的原则，用以指导设

5、计师理建立了最重要的原则，用以指导设计师 工作。在运用设计实践的技术和方法之前，工作。在运用设计实践的技术和方法之前， 必须先理解设计概念，而且设计实践本身必须先理解设计概念，而且设计实践本身 会导致产生各种软件设计表示，这些表示会导致产生各种软件设计表示，这些表示 将指导随后的构建活动。将指导随后的构建活动。 软件工程讲义第七章设计概念 设计工程 v设计是一项核心的工程活动。设计是一项核心的工程活动。Lotus 1-2-3的的 发明人在发明人在Dr.Dobbs杂志杂志上发表了上发表了“软件设软件设 计宣言计宣言”：设计是你身处两个世界：设计是你身处两个世界技术世技术世 界和人类的目标世界界和

6、人类的目标世界而你尝试将这两个世而你尝试将这两个世 界结合在一起界结合在一起设计良好的建筑应该展示出设计良好的建筑应该展示出 坚固、适用和令人赏心悦目的特点。对好的软坚固、适用和令人赏心悦目的特点。对好的软 件来说也是如此。所谓坚固，是指程序应该不件来说也是如此。所谓坚固，是指程序应该不 含任何妨碍其功能的缺陷。适用是要程序符合含任何妨碍其功能的缺陷。适用是要程序符合 开发的目标。赏心悦目则是要求使用程序的体开发的目标。赏心悦目则是要求使用程序的体 验应是愉快的。验应是愉快的。 软件工程讲义第七章设计概念 设计工程 v设计工程的目标是创作出坚固、适用和赏设计工程的目标是创作出坚固、适用和赏 心

7、悦目的模型或设计表示。心悦目的模型或设计表示。 为此，设计师为此，设计师 的做法必须先实现多样化再行聚合。多样的做法必须先实现多样化再行聚合。多样 化是指要获取多种方案和设计的原始资料，化是指要获取多种方案和设计的原始资料， 包括目录、教科书和头脑中的构件、构件包括目录、教科书和头脑中的构件、构件 方案和知识。在各种信息汇聚在一起之后，方案和知识。在各种信息汇聚在一起之后， 设计师应从其中挑选能够满足需求工程和设计师应从其中挑选能够满足需求工程和 分析模型所定义的需求的元素。分析模型所定义的需求的元素。 软件工程讲义第七章设计概念 v此时，设计工程师在经取舍后，进行此时，设计工程师在经取舍后，

8、进行 聚合，使之成为构件的某种特定的配聚合，使之成为构件的某种特定的配 置，于是便得到最终的产品。置，于是便得到最终的产品。 v多样化和聚合需要直觉和判断力，其多样化和聚合需要直觉和判断力，其 质量取决于构造类似实体的经验、一质量取决于构造类似实体的经验、一 系列指导模型演化方式的原则和系列指导模型演化方式的原则和(或或) 启发、一系列质量评价的标准以及导启发、一系列质量评价的标准以及导 出最终设计表示的迭代过程。出最终设计表示的迭代过程。 软件工程讲义第七章设计概念 设计工程 v在本章将探讨可以应用于所有软件设计的在本章将探讨可以应用于所有软件设计的 基本概念和原则、设计模型的元素以及模基本

9、概念和原则、设计模型的元素以及模 式对设计过程的影响。在随后的章节中，式对设计过程的影响。在随后的章节中， 将考察应用于体系结构、接口和构件级设将考察应用于体系结构、接口和构件级设 计的各种各样的设计方法。计的各种各样的设计方法。 软件工程讲义第七章设计概念 软件工程中的设计 v软件设计在软件工程过程中处于技术核心，软件设计在软件工程过程中处于技术核心， 并且它的应用与所使用的软件过程模型无并且它的应用与所使用的软件过程模型无 关。对软件需求进行分析和建模开始之后，关。对软件需求进行分析和建模开始之后， 软件设计是建模活动的最后一个软件工程软件设计是建模活动的最后一个软件工程 动作，接着便要进

10、入构造阶段。动作，接着便要进入构造阶段。 软件工程讲义第七章设计概念 v需求模型的每个元素都提供了创建四种需求模型的每个元素都提供了创建四种 设计模型所必需的信息，这四种设计模设计模型所必需的信息，这四种设计模 型是完成完整的设计规格说明所必需的。型是完成完整的设计规格说明所必需的。 软件设计过程中的信息流如图软件设计过程中的信息流如图7-1所示。所示。 由基于场景的元素、基于类的元素和行由基于场景的元素、基于类的元素和行 为元素所表明的分析模型是设计任务的为元素所表明的分析模型是设计任务的 输入。使用相应的设计表示法和设计方输入。使用相应的设计表示法和设计方 法，将得到数据或类的设计、体系结

11、构法，将得到数据或类的设计、体系结构 设计、接口设计和构件设计。设计、接口设计和构件设计。 软件工程讲义第七章设计概念 软件工程中的设计 图7-1从需求模型到设计模型的转化 软件工程讲义第七章设计概念 软件工程中的设计 v数据数据/类设计将分析类模型转化为设计类类设计将分析类模型转化为设计类 的实现以及软件实现所要求的数据结构。的实现以及软件实现所要求的数据结构。 CRC索引卡定义的类和关系、类属性和其索引卡定义的类和关系、类属性和其 他表示法刻画的详细数据内容为数据设计他表示法刻画的详细数据内容为数据设计 活动提供了基础。在和软件体系结构设计活动提供了基础。在和软件体系结构设计 连接中可能会

12、有部分的类设计，更详细的连接中可能会有部分的类设计，更详细的 类设计在设计每个软件构件时进行。类设计在设计每个软件构件时进行。 软件工程讲义第七章设计概念 v体系结构设计定义了软件的主要结构体系结构设计定义了软件的主要结构 元素之间的关系、可用于达到系统所元素之间的关系、可用于达到系统所 定义需求的体系结构风格和设计模式定义需求的体系结构风格和设计模式 以及影响体系结构实现方式的约束。以及影响体系结构实现方式的约束。 体系结构设计表示体系结构设计表示基于计算机系基于计算机系 统的框架统的框架可以从需求模型导出。可以从需求模型导出。 软件工程讲义第七章设计概念 软件工程中的设计 v接口设计描述了

13、软件和协作系统之间、软接口设计描述了软件和协作系统之间、软 件和使用人员之间是如何通信的。接口就件和使用人员之间是如何通信的。接口就 意味着信息流和特定的行为类型。因此，意味着信息流和特定的行为类型。因此， 使用场景和行为模型为接口设计提供了所使用场景和行为模型为接口设计提供了所 需的大量信息。需的大量信息。 软件工程讲义第七章设计概念 v构件级设计将软件体系结构的结构元构件级设计将软件体系结构的结构元 素变换为对软件构件的过程性描述。素变换为对软件构件的过程性描述。 从基于类的模型、流模型和行为模型从基于类的模型、流模型和行为模型 获得的信息将作为构件设计的基础。获得的信息将作为构件设计的基

14、础。 软件工程讲义第七章设计概念 软件工程中的设计 v软件设计的重要性可以用一个词来表达软件设计的重要性可以用一个词来表达 质量。设计是软件工程中形成质量的地质量。设计是软件工程中形成质量的地 方，设计为我们提供了可以用于质量评估方，设计为我们提供了可以用于质量评估 的软件表示，设计是我们能够将用户需求的软件表示，设计是我们能够将用户需求 准确地转化为软件产品或系统的唯一方法。准确地转化为软件产品或系统的唯一方法。 软件设计是所有软件工程活动和随后的软软件设计是所有软件工程活动和随后的软 件支持活动的基础。没有设计，我们冒构件支持活动的基础。没有设计，我们冒构 造不稳定系统的风险，这样的系统稍

15、做改造不稳定系统的风险，这样的系统稍做改 动就无法运行，而且难以测试，直到软件动就无法运行，而且难以测试，直到软件 工程过程的后期才能评估其质量。工程过程的后期才能评估其质量。 软件工程讲义第七章设计概念 设计过程和设计质量 v软件设计是一个迭代的过程，通过设计过软件设计是一个迭代的过程，通过设计过 程，需求被变换为用于构建软件的程，需求被变换为用于构建软件的“蓝蓝 图图”。初始时，蓝图描述了软件的整体视。初始时，蓝图描述了软件的整体视 图，也就是说，设计是在高抽象层次上的图，也就是说，设计是在高抽象层次上的 表达表达在该层次上可以直接跟踪到特定在该层次上可以直接跟踪到特定 的系统目标和更详细

16、的数据、功能和行为的系统目标和更详细的数据、功能和行为 需求。随着设计迭代的开始，后续的精化需求。随着设计迭代的开始，后续的精化 导致更低抽象层次的设计表示。这些表示导致更低抽象层次的设计表示。这些表示 仍然能够跟踪到需求，但是连接更加错综仍然能够跟踪到需求，但是连接更加错综 复杂了。复杂了。 软件工程讲义第七章设计概念 设计过程和设计质量 vMCG91提出了可以指导评价良好设计提出了可以指导评价良好设计 演化的三个特征：演化的三个特征： v设计必须实现所有包含在分析模型中的明设计必须实现所有包含在分析模型中的明 确需求，而且必须满足客户期望的所有隐确需求，而且必须满足客户期望的所有隐 含需求

17、。含需求。 v对于那些生成代码的人和那些进行测试以对于那些生成代码的人和那些进行测试以 及随后维护软件的人而言，设计必须是可及随后维护软件的人而言，设计必须是可 读的、可理解的指南。读的、可理解的指南。 v设计必须提供软件的全貌，从实现的角度设计必须提供软件的全貌，从实现的角度 说明数据域、功能域和行为域。说明数据域、功能域和行为域。 软件工程讲义第七章设计概念 质量指导原则 v设计应展示出这样一种结构：设计应展示出这样一种结构：(a)已经使已经使 用可识别的体系结构风格或模式创建；用可识别的体系结构风格或模式创建；(b) 由展示出良好设计特征的构件构成；由展示出良好设计特征的构件构成；(c)

18、 能够以演化的方式实现，从而便于实现和能够以演化的方式实现，从而便于实现和 测试。测试。 v设计应该模块化；即软件应按照逻辑划分设计应该模块化；即软件应按照逻辑划分 为元素或子系统。为元素或子系统。 v设计应该包含数据、体系结构、接口和构设计应该包含数据、体系结构、接口和构 件的清楚表示。件的清楚表示。 软件工程讲义第七章设计概念 质量指导原则 v设计应导出数据结构，这些数据结构适于设计应导出数据结构，这些数据结构适于 要实现的类，并由可识别的数据模式提取。要实现的类，并由可识别的数据模式提取。 v设计应导出显示独立功能特征的构件。设计应导出显示独立功能特征的构件。 v设计应导出接口，这些接口

19、降低了构件之设计应导出接口，这些接口降低了构件之 间以及与外部环境连接的复杂性。间以及与外部环境连接的复杂性。 v设计的导出应根据软件需求分析过程中获设计的导出应根据软件需求分析过程中获 取的信息采用可重复使用的方法进行。取的信息采用可重复使用的方法进行。 v应使用能够有效传达其意义的表示法来表应使用能够有效传达其意义的表示法来表 达设计。达设计。 软件工程讲义第七章设计概念 质量属性 vHP开发了一系列软件质量属性，称为开发了一系列软件质量属性，称为FURPS， 分别代表功能性、易用性、可靠性、性能、可分别代表功能性、易用性、可靠性、性能、可 支持性。支持性。FURPS质量属性体现了所有软件

20、设质量属性体现了所有软件设 计的目标。计的目标。 v功能性：评估程序的特征集和能力、所提交功能性：评估程序的特征集和能力、所提交 功能的普遍性以及整个系统的安全性。功能的普遍性以及整个系统的安全性。 v易用性：通过考虑人为因素、整体美感、一易用性：通过考虑人为因素、整体美感、一 致性和文档来评估。致性和文档来评估。 软件工程讲义第七章设计概念 v可靠性：通过测量故障的频率和严重性、可靠性：通过测量故障的频率和严重性、 输出结果的精确性、故障平均时间输出结果的精确性、故障平均时间MTTF、 故障恢复能力和程序的可预见性来评估。故障恢复能力和程序的可预见性来评估。 v性能：度量处理速度、响应时间、

21、资源消性能：度量处理速度、响应时间、资源消 耗、吞吐量和效率。耗、吞吐量和效率。 v可支持性：综合了扩展程序、适应性和耐可支持性：综合了扩展程序、适应性和耐 用性三方面的能力，此外还包括可测试性、用性三方面的能力，此外还包括可测试性、 兼容性、可配置性、系统安装的简易性和兼容性、可配置性、系统安装的简易性和 问题定位的简易性。问题定位的简易性。 软件工程讲义第七章设计概念 设计任务集 v检查信息域模型，并为数据对象及其属性检查信息域模型，并为数据对象及其属性 设计恰当的数据结构。设计恰当的数据结构。 v使用分析模型，选择一个适于软件的体系使用分析模型，选择一个适于软件的体系 结构类型。结构类型

22、。 v将分析模型分割为若干个设计子系统，并将分析模型分割为若干个设计子系统，并 在体系结构内分配这些子系统。要确定每在体系结构内分配这些子系统。要确定每 个子系统是功能内聚的。设计子系统接口。个子系统是功能内聚的。设计子系统接口。 为每个子系统分配分析类或功能。为每个子系统分配分析类或功能。 软件工程讲义第七章设计概念 v创建一系列的设计类或构件。将每个分析类创建一系列的设计类或构件。将每个分析类 说明转化为设计类。据设计标准检查每个设说明转化为设计类。据设计标准检查每个设 计类，考虑继承问题。定义与每个设计类相计类，考虑继承问题。定义与每个设计类相 关的方法和消息。评估设计类或子系统并为关的

23、方法和消息。评估设计类或子系统并为 这些类或子系统选择设计模式。评审设计类，这些类或子系统选择设计模式。评审设计类， 并在需要时修改。并在需要时修改。 v设计外部系统或设备所需要的所有接口。设计外部系统或设备所需要的所有接口。 软件工程讲义第七章设计概念 设计任务集 v设计用户接口。评审任务分析的结果。基设计用户接口。评审任务分析的结果。基 于用户场景详细说明活动序列。创建接口于用户场景详细说明活动序列。创建接口 的行为模型。定义接口对象、控制机制。的行为模型。定义接口对象、控制机制。 评审接口设计，并在需要时修改。评审接口设计，并在需要时修改。 v进行构件级设计。在相对较低的抽象层次进行构件

24、级设计。在相对较低的抽象层次 上详细说明所有算法。精化每个构件的接上详细说明所有算法。精化每个构件的接 口。定义构件级的数据结构。评审每个构口。定义构件级的数据结构。评审每个构 件并修正所有已发现的错误。件并修正所有已发现的错误。 v开发部署模型。开发部署模型。 软件工程讲义第七章设计概念 设计概念 v在软件工程的历史进程中发展了一系列基在软件工程的历史进程中发展了一系列基 本的软件设计概念。尽管多年来对于每一本的软件设计概念。尽管多年来对于每一 种概念的关注程度不断变化，但它们都经种概念的关注程度不断变化，但它们都经 历了时间的考验。每一种概念都为软件设历了时间的考验。每一种概念都为软件设

25、计者提供了应用更加复杂设计方法的基础。计者提供了应用更加复杂设计方法的基础。 v基础的软件设计概念为基础的软件设计概念为“使程序正确使程序正确”提提 供了必要的框架。供了必要的框架。 软件工程讲义第七章设计概念 抽象 v当考虑某一问题的模块化解决方案时，可当考虑某一问题的模块化解决方案时，可 以给出许多抽象级。在最高的抽象级上，以给出许多抽象级。在最高的抽象级上， 使用问题所处环境的语言以概括性的术语使用问题所处环境的语言以概括性的术语 描述解决方案。在较低的抽象级上，将提描述解决方案。在较低的抽象级上，将提 供更详细的解决方案说明。供更详细的解决方案说明。 软件工程讲义第七章设计概念 抽象

26、v在不同的抽象级间移动时，我们力图创建在不同的抽象级间移动时，我们力图创建 过程抽象和数据抽象。过程抽象是指具有过程抽象和数据抽象。过程抽象是指具有 明确和有限功能的指令序列。过程抽象的明确和有限功能的指令序列。过程抽象的 命名暗示了这些功能，但是隐藏了具体的命名暗示了这些功能，但是隐藏了具体的 细节。细节。 v数据抽象是描述数据对象的冠名数据集合。数据抽象是描述数据对象的冠名数据集合。 软件工程讲义第七章设计概念 体系结构 v软件体系结构意指软件体系结构意指“软件的整体结构和这软件的整体结构和这 种结构为系统提供概念上完整性的方式种结构为系统提供概念上完整性的方式”。 从最简单的形式看，体系

27、结构是程序构件从最简单的形式看，体系结构是程序构件 (模块模块)的结构或组织、这些构件交互的形的结构或组织、这些构件交互的形 式以及这些构件所用数据的结构。式以及这些构件所用数据的结构。 v软件设计的目标之一是导出系统的体系结软件设计的目标之一是导出系统的体系结 构透视图，该透视图作为一个框架，将指构透视图，该透视图作为一个框架，将指 导更详细的设计活动。一系列的体系结构导更详细的设计活动。一系列的体系结构 模式使得软件工程师能够复用设计级的概模式使得软件工程师能够复用设计级的概 念。念。 软件工程讲义第七章设计概念 体系结构 v体系结构设计可以使用大量的一种或多种体系结构设计可以使用大量的一

28、种或多种 模型来表达。结构模型将体系结构表示为模型来表达。结构模型将体系结构表示为 程序构件的一个有组织的集合。通过确定程序构件的一个有组织的集合。通过确定 类似应用中遇到的可复用的体系结构来设类似应用中遇到的可复用的体系结构来设 计框架，框架模型可以提高设计抽象级别。计框架，框架模型可以提高设计抽象级别。 动态模型强调程序体系结构的行为方面，动态模型强调程序体系结构的行为方面， 指明结构或系统配置作为外部事件的函数指明结构或系统配置作为外部事件的函数 将如何变化。过程模型注重系统必须提供将如何变化。过程模型注重系统必须提供 的业务设计或技术流程设计。最后，功能的业务设计或技术流程设计。最后，

29、功能 模型可以用来表示系统的功能层次结构。模型可以用来表示系统的功能层次结构。 软件工程讲义第七章设计概念 模式 v设计模式描述了在某个特定场景与可能影设计模式描述了在某个特定场景与可能影 响模式应用和使用方式的响模式应用和使用方式的“影响力影响力”中解中解 决某个特定的设计问题的设计结构。决某个特定的设计问题的设计结构。 v每个设计模式的目的都是提供一个描述，每个设计模式的目的都是提供一个描述， 以使得设计人员能够确定：以使得设计人员能够确定：(1)模式是否模式是否 适合当前的工作；适合当前的工作；(2)模式是否能够复用；模式是否能够复用； (3)模式是否能够用于指导开发一个类似模式是否能够

30、用于指导开发一个类似 但是功能或结构不同的模式。但是功能或结构不同的模式。 软件工程讲义第七章设计概念 关注点分离 v关注点分离是一个设计概念，它表明任何关注点分离是一个设计概念，它表明任何 复杂问题如果被分解为可以独立解决和复杂问题如果被分解为可以独立解决和 (或或)优化的若干块，该复杂问题能够更容优化的若干块，该复杂问题能够更容 易地被处理。一个关注点是一个特征或行易地被处理。一个关注点是一个特征或行 为，被指定为软件需求模型的一部分。通为，被指定为软件需求模型的一部分。通 过将关注点分割为更小的关注点，使得解过将关注点分割为更小的关注点，使得解 决一个问题需要付出更少的工作量和时间。决一

31、个问题需要付出更少的工作量和时间。 软件工程讲义第七章设计概念 模块化 v软件体系结构和设计模式表现为模块化；软件体系结构和设计模式表现为模块化； 即软件被划分为独立命名的、可寻址的构即软件被划分为独立命名的、可寻址的构 件，有时被称为模块，把这些构件集成到件，有时被称为模块，把这些构件集成到 一起可以满足问题的需求。一起可以满足问题的需求。 v模块化是软件的单个属性，它使程序能被模块化是软件的单个属性，它使程序能被 理性地管理。软件工程师难以掌握单块软理性地管理。软件工程师难以掌握单块软 件。对于大型程序，其控制路径的数量、件。对于大型程序，其控制路径的数量、 引用的跨度、变量的数量和整体的

32、复杂度引用的跨度、变量的数量和整体的复杂度 使得理解这样的软件几乎是不可能的。使得理解这样的软件几乎是不可能的。 软件工程讲义第七章设计概念 模块化 v考虑两个问题考虑两个问题p1和和p2，如果，如果p1的理解复的理解复 杂度大于杂度大于p2的理解复杂度，那么解决的理解复杂度，那么解决p1 所需的工作量大于解决所需的工作量大于解决p2所需的工作量。所需的工作量。 v另一个结果是两个问题结合时的理解复杂另一个结果是两个问题结合时的理解复杂 度通常要大于每个问题各自的理解复杂度度通常要大于每个问题各自的理解复杂度 之和。这引出了之和。这引出了“分而治之分而治之”的策略：将的策略：将 一个复杂问题分

33、解成可以管理的若干块，一个复杂问题分解成可以管理的若干块， 这样能够更容易解决问题。这样能够更容易解决问题。 软件工程讲义第七章设计概念 模块化 v似乎可以得出结论：如果我们无限制地划似乎可以得出结论：如果我们无限制地划 分软件，那么开发它所需的工作量会变得分软件，那么开发它所需的工作量会变得 小到可以忽略小到可以忽略!然而，其他因素开始起作用，然而，其他因素开始起作用， 导致这个结论不成立。如图导致这个结论不成立。如图7-2所示，开所示，开 发某个独立软件模块的工作量的确随着模发某个独立软件模块的工作量的确随着模 块数增加而下降，给定同样的需求，更多块数增加而下降，给定同样的需求，更多 的模

34、块意味着每个模块的规模更小。然而，的模块意味着每个模块的规模更小。然而， 随着模块数量增加，集成模块的工作量也随着模块数量增加，集成模块的工作量也 在增加。事实上，的确存在一个模块数量在增加。事实上，的确存在一个模块数量 M可以带来最小的开发成本。但是，我们可以带来最小的开发成本。但是，我们 缺乏必要的技术来精确地预测缺乏必要的技术来精确地预测M。 软件工程讲义第七章设计概念 模块化 图7-2 模块化和软件成本 软件工程讲义第七章设计概念 模块化 v做模块化设计做模块化设计(以及由其产生的程序以及由其产生的程序)可以可以 更容易地计划开发；可以定义和交付软件更容易地计划开发；可以定义和交付软件

35、 增量；更容易实施变更；能够更有效地开增量；更容易实施变更；能够更有效地开 展测试和调试；可以开展长期维护而没有展测试和调试；可以开展长期维护而没有 严重的副作用。严重的副作用。 软件工程讲义第七章设计概念 信息隐蔽 v模块化概念让每个软件设计师面对一个基模块化概念让每个软件设计师面对一个基 本问题：我们将如何分解一个软件解决方本问题：我们将如何分解一个软件解决方 案以求获得最好的模块集合？信息隐蔽原案以求获得最好的模块集合？信息隐蔽原 则建议模块应该具有的特征是：每个模块则建议模块应该具有的特征是：每个模块 对其他所有模块都隐蔽自己的设计决策。对其他所有模块都隐蔽自己的设计决策。 即模块应该

36、详细说明且精心设计以求在某即模块应该详细说明且精心设计以求在某 个模块中包含的信息不被不需要这些信息个模块中包含的信息不被不需要这些信息 的其他模块访问。的其他模块访问。 软件工程讲义第七章设计概念 信息隐蔽 v隐蔽意味着通过定义一系列独立的模块可以得隐蔽意味着通过定义一系列独立的模块可以得 到有效的模块化，独立模块相互之间只交流实到有效的模块化，独立模块相互之间只交流实 现软件功能所必需的那些信息。抽象有助于定现软件功能所必需的那些信息。抽象有助于定 义构成软件的过程实体。隐蔽定义并加强了模义构成软件的过程实体。隐蔽定义并加强了模 块内的过程细节和模块所使用的任何局部数据块内的过程细节和模块

37、所使用的任何局部数据 结构的访问约束。结构的访问约束。 v把信息隐蔽用做模块化系统的一个设计标准，把信息隐蔽用做模块化系统的一个设计标准， 在测试和随后的软件维护过程中，在需要修改在测试和随后的软件维护过程中，在需要修改 时将提供最大的益处。因为大多数数据和程序时将提供最大的益处。因为大多数数据和程序 对软件的其他部分是隐蔽的，因此在修改过程对软件的其他部分是隐蔽的，因此在修改过程 中，无意地引入错误并传播到软件其他地方的中，无意地引入错误并传播到软件其他地方的 可能性会很小。可能性会很小。 软件工程讲义第七章设计概念 功能独立 v功能独立的概念是模块化、抽象概念和信功能独立的概念是模块化、抽

38、象概念和信 息隐蔽的直接结果。通过开发具有专一功息隐蔽的直接结果。通过开发具有专一功 能和避免与其他模块过多交互的模块，可能和避免与其他模块过多交互的模块，可 以实现功能独立。即，我们希望软件设计以实现功能独立。即，我们希望软件设计 时要使每个模块仅涉及需求的某个特定子时要使每个模块仅涉及需求的某个特定子 功能，并且当从程序结构的其他部分观察功能，并且当从程序结构的其他部分观察 时，每个模块只有一个简单的接口。时，每个模块只有一个简单的接口。 软件工程讲义第七章设计概念 功能独立 v具有有效模块化的软件更容易开发，这是因为具有有效模块化的软件更容易开发，这是因为 功能被分隔而且接口被简化。独立

39、模块更容易功能被分隔而且接口被简化。独立模块更容易 维护和测试，因为修改设计或修改代码所引起维护和测试，因为修改设计或修改代码所引起 的副作用被限制，减少了错误扩散，而且模块的副作用被限制，减少了错误扩散，而且模块 复用也成为可能。功能独立是优秀设计的关键，复用也成为可能。功能独立是优秀设计的关键， 而设计又是软件质量的关键。而设计又是软件质量的关键。 v独立性可以使用两条定性的标准评估：内聚性独立性可以使用两条定性的标准评估：内聚性 和耦合性。和耦合性。 内聚性显示了某个模块相关功能的内聚性显示了某个模块相关功能的 强度；耦合性显示了模块间的相互依赖性。强度；耦合性显示了模块间的相互依赖性。

40、 软件工程讲义第七章设计概念 功能独立 v具有有效模块化的软件更容易开发，这是因为具有有效模块化的软件更容易开发，这是因为 功能被分隔而且接口被简化。独立模块更容易功能被分隔而且接口被简化。独立模块更容易 维护和测试，因为修改设计或修改代码所引起维护和测试，因为修改设计或修改代码所引起 的副作用被限制，减少了错误扩散，而且模块的副作用被限制，减少了错误扩散，而且模块 复用也成为可能。功能独立是优秀设计的关键，复用也成为可能。功能独立是优秀设计的关键， 而设计又是软件质量的关键。而设计又是软件质量的关键。 v独立性可以使用两条定性的标准评估：内聚性独立性可以使用两条定性的标准评估：内聚性 和耦合

41、性。和耦合性。 内聚性显示了某个模块相关功能的内聚性显示了某个模块相关功能的 强度；耦合性显示了模块间的相互依赖性。强度；耦合性显示了模块间的相互依赖性。 软件工程讲义第七章设计概念 功能独立 v内聚性是信息隐蔽概念的自然扩展。一个内聚内聚性是信息隐蔽概念的自然扩展。一个内聚 的模块执行一个独立的任务，与程序的其他部的模块执行一个独立的任务，与程序的其他部 分构件只需要很少的交互。简单地说，一个内分构件只需要很少的交互。简单地说，一个内 聚的模块应该只完成一件事情。聚的模块应该只完成一件事情。 v耦合性表明软件结构中多个模块之间的相互连耦合性表明软件结构中多个模块之间的相互连 接。耦合性依赖于

42、模块之间的接口复杂性、引接。耦合性依赖于模块之间的接口复杂性、引 用或进入模块所在的点以及什么数据通过接口用或进入模块所在的点以及什么数据通过接口 传递。在软件设计中，我们将尽力得到尽可能传递。在软件设计中，我们将尽力得到尽可能 低的耦合。模块间简单的连接性使得软件易于低的耦合。模块间简单的连接性使得软件易于 理解并减少理解并减少“涟漪效果涟漪效果”的倾向，的倾向，“涟漪效果涟漪效果” 是指在某个地方发生错误时导致扩散到整个系是指在某个地方发生错误时导致扩散到整个系 统。统。 软件工程讲义第七章设计概念 求精 v逐步求精是由逐步求精是由Niklaus Wirth最初提出的一种最初提出的一种 自

43、顶向下的设计策略。通过连续精化层次结构自顶向下的设计策略。通过连续精化层次结构 的程序细节来实现程序的开发，层次结构的开的程序细节来实现程序的开发，层次结构的开 发将通过逐步分解功能的宏观陈述直至形成程发将通过逐步分解功能的宏观陈述直至形成程 序设计语言的语句。序设计语言的语句。 v求精实际上是一个细化的过程。从在高抽象级求精实际上是一个细化的过程。从在高抽象级 上定义的功能陈述开始，该陈述概念性地描述上定义的功能陈述开始，该陈述概念性地描述 了功能或信息，但是没有提供有关功能内部工了功能或信息，但是没有提供有关功能内部工 作的信息或数据内部结构的信息。精化促使设作的信息或数据内部结构的信息。

44、精化促使设 计者在原始陈述上细化，并随着每个精化的持计者在原始陈述上细化，并随着每个精化的持 续进行将提供越来越多的细节。续进行将提供越来越多的细节。 软件工程讲义第七章设计概念 求精 v抽象和精化是互补的概念。抽象使得设计人员抽象和精化是互补的概念。抽象使得设计人员 能够明确说明过程和数据而同时忽略低层细节；能够明确说明过程和数据而同时忽略低层细节； 精化有助于设计人员在设计过程中揭示低层的精化有助于设计人员在设计过程中揭示低层的 细节。这两个概念均有助于设计人员在设计演细节。这两个概念均有助于设计人员在设计演 化中构造出完整的设计模型。化中构造出完整的设计模型。 软件工程讲义第七章设计概念

45、 方面 v当我们开始进行需求分析时，一组当我们开始进行需求分析时，一组“关注点关注点” 就出现了。这些关注点就出现了。这些关注点“包括需求、用例、特包括需求、用例、特 征、数据结构、服务质量问题、变量、知识产征、数据结构、服务质量问题、变量、知识产 权边界、合作、模式以及合同权边界、合作、模式以及合同”。理想情况下，。理想情况下， 可以按某种方式组织需求模型，该方式允许分可以按某种方式组织需求模型，该方式允许分 离每个关注点，使得能够独立考虑每个关注点。离每个关注点，使得能够独立考虑每个关注点。 v当开始进行设计时，需求被精化为模块设计表当开始进行设计时，需求被精化为模块设计表 示。考虑两个需

46、求，示。考虑两个需求，A和和B。”如果已经选择了如果已经选择了 一种软件分解，在这种分解中，如果不考虑需一种软件分解，在这种分解中，如果不考虑需 求求A的话，需求的话，需求B就不能得到满足，那么需求就不能得到满足，那么需求A 横切需求横切需求B。 软件工程讲义第七章设计概念 重构 v重构是一种重新组织的技术，可以简化构件的重构是一种重新组织的技术，可以简化构件的 设计而无需改变其功能或行为。设计而无需改变其功能或行为。FOW00这样这样 定义重构：定义重构：“重构是使用这样一种方式改变软重构是使用这样一种方式改变软 件系统的过程：不改变代码的外部行为而是改件系统的过程：不改变代码的外部行为而是

47、改 进其内部结构。进其内部结构。” v当重构软件时，检查现有设计的冗余性、没有当重构软件时，检查现有设计的冗余性、没有 使用的设计元素、低效的或不必要的算法、拙使用的设计元素、低效的或不必要的算法、拙 劣的或不恰当的数据结构以及其他设计不足，劣的或不恰当的数据结构以及其他设计不足， 修改这些不足从而获得更好的设计。修改这些不足从而获得更好的设计。 软件工程讲义第七章设计概念 设计类 v在设计模式演化时，软件团队必须定义一组设在设计模式演化时，软件团队必须定义一组设 计类：计类：(1)通过提供设计细节精化分析类，这些通过提供设计细节精化分析类，这些 设计细节将促成类的实现；设计细节将促成类的实现

48、；(2)创建一组新的设创建一组新的设 计类，该设计类实现了软件的基础设施以支持计类，该设计类实现了软件的基础设施以支持 业务解决方案。业务解决方案。AMB01建议了五种不同类型建议了五种不同类型 的设计类，每一种都表现了设计体系结构的一的设计类，每一种都表现了设计体系结构的一 个层次。个层次。 软件工程讲义第七章设计概念 设计类 v用户接口类：定义人机交互用户接口类：定义人机交互(HCI)所必需的所有抽象。所必需的所有抽象。 在很多情况下，在很多情况下，HCI出现在隐喻的环境，而接口的设计出现在隐喻的环境，而接口的设计 类可能是这种隐喻元素的形象表示。类可能是这种隐喻元素的形象表示。 v业务域

49、类：通常是早期定义的分析类的精化。这些类识业务域类：通常是早期定义的分析类的精化。这些类识 别实现某些业务域所必需的属性和服务。别实现某些业务域所必需的属性和服务。 v过程类：实现完整管理业务域类所必需的低层业务抽象。过程类：实现完整管理业务域类所必需的低层业务抽象。 v持久类：代表将在软件执行之外持续存在的数据存储。持久类：代表将在软件执行之外持续存在的数据存储。 v系统类：实现软件管理和控制功能，使得系统能够运行系统类：实现软件管理和控制功能，使得系统能够运行 并在其计算环境内与外界通信。并在其计算环境内与外界通信。 软件工程讲义第七章设计概念 设计类 v在设计模型演化时，软件团队必须为每

50、个在设计模型演化时，软件团队必须为每个 设计类开发一组完整的属性和操作。随着设计类开发一组完整的属性和操作。随着 每个分析类转化为设计表示，抽象级就降每个分析类转化为设计表示，抽象级就降 低。即分析类使用业务域的专门用语描述低。即分析类使用业务域的专门用语描述 对象；设计类更多地表现技术细节，将作对象；设计类更多地表现技术细节，将作 为实现的指导。为实现的指导。 vARL02为组织良好的设计类定义了四为组织良好的设计类定义了四 个特征。个特征。 软件工程讲义第七章设计概念 设计类 v完整性与充分性：设计类应该完整地封装完整性与充分性：设计类应该完整地封装 所有的，可以合理预见会存在于类中的属所

51、有的，可以合理预见会存在于类中的属 性和方法。充分性确保设计类只包含那些性和方法。充分性确保设计类只包含那些 “对实现这个类的目的足够对实现这个类的目的足够”的方法，不的方法，不 多也不少。多也不少。 v原始性：和某个设计类相关的方法应该关原始性：和某个设计类相关的方法应该关 注于实现类的某个服务。一旦服务已经被注于实现类的某个服务。一旦服务已经被 某个方法实现，类就不应该再提供另外一某个方法实现，类就不应该再提供另外一 种完成同一事情的方法。种完成同一事情的方法。 软件工程讲义第七章设计概念 设计类 v高内聚性：一个内聚的设计类具有小的、集中高内聚性：一个内聚的设计类具有小的、集中 的职责集

52、合，并且专注于使用属性和方法来实的职责集合，并且专注于使用属性和方法来实 现那些职责。现那些职责。 v低耦合性：在设计模型内，设计类之间相互协低耦合性：在设计模型内，设计类之间相互协 作是必然的。但是，协作应该保持在一个可以作是必然的。但是，协作应该保持在一个可以 接受的最小范围内。如果设计模型高度耦合，接受的最小范围内。如果设计模型高度耦合， 那么系统就难以实现、测试，并且维护也很费那么系统就难以实现、测试，并且维护也很费 力。通常，一个子系统内的设计类对其他子系力。通常，一个子系统内的设计类对其他子系 统中的类应仅有有限的了解。该限制被称作统中的类应仅有有限的了解。该限制被称作 Demet

53、er定律，该定律建议一个方法应该只向定律，该定律建议一个方法应该只向 周围类中的方法发送消息。周围类中的方法发送消息。 软件工程讲义第七章设计概念 SAFEHOME实例26 图7-3 FloorPlan的设计类和类的复合聚集 软件工程讲义第七章设计概念 设计模型 v设计模型可以从两不同的维度观察，如图设计模型可以从两不同的维度观察，如图 7-4所示。过程维度表示设计模型的演化，所示。过程维度表示设计模型的演化， 设计工作作为软件过程的一部分被执行；设计工作作为软件过程的一部分被执行； 抽象维度表示过程的详细级别，分析模型抽象维度表示过程的详细级别，分析模型 的每个元素转化为一个等价的设计，然后

54、的每个元素转化为一个等价的设计，然后 迭代精化。图中虚线表示分析模型和设计迭代精化。图中虚线表示分析模型和设计 模型之间的边界。在某些情况下，分析模模型之间的边界。在某些情况下，分析模 型和设计模型之间可能存在清晰的差别；型和设计模型之间可能存在清晰的差别； 而在有些情况下，分析模型慢慢地融入设而在有些情况下，分析模型慢慢地融入设 计模型而没有明显的差别。计模型而没有明显的差别。 软件工程讲义第七章设计概念 设计模型的维度 图7-4 设计模型的维度 软件工程讲义第七章设计概念 设计模型 v设计模型的元素很多都是在分析模型中使用的设计模型的元素很多都是在分析模型中使用的 UML图。差别在于这些图

55、被精化和细化为设计图。差别在于这些图被精化和细化为设计 的一部分，并且提供了更多的与实现相关的特的一部分，并且提供了更多的与实现相关的特 殊细节，突出了体系结构的结构和风格、体系殊细节，突出了体系结构的结构和风格、体系 结构内存在的构件以及构件和外界之间的接口。结构内存在的构件以及构件和外界之间的接口。 v沿横坐标表示的模型元素通常并不总是顺序开沿横坐标表示的模型元素通常并不总是顺序开 发的。大多数情况下，初步的体系结构设计是发的。大多数情况下，初步的体系结构设计是 基础，随后是接口设计和构件级设计（通常是基础，随后是接口设计和构件级设计（通常是 并行进行）。通常直到设计全部完成后才开始并行进

56、行）。通常直到设计全部完成后才开始 部署模型的工作。部署模型的工作。 软件工程讲义第七章设计概念 数据设计元素 v数据设计（有时也称为数据体系结构设计）数据设计（有时也称为数据体系结构设计） 创建在高抽象级上（以客户创建在高抽象级上（以客户/用户的数据用户的数据 观点）表示的数据模型和观点）表示的数据模型和/或信息模型。或信息模型。 然后，数据模型被精化为越来越和实现相然后，数据模型被精化为越来越和实现相 关的特定表示，即基于计算机的系统能够关的特定表示，即基于计算机的系统能够 处理的表示。在很多软件应用中，数据体处理的表示。在很多软件应用中，数据体 系结构对必须处理该数据的软件体系结构系结构

57、对必须处理该数据的软件体系结构 有深远的影响。有深远的影响。 软件工程讲义第七章设计概念 数据设计元素 v数据结构通常是软件设计的重要部分。在数据结构通常是软件设计的重要部分。在 程序构件级，数据结构设计以及相关的处程序构件级，数据结构设计以及相关的处 理这些数据的算法对于创建高质量的应用理这些数据的算法对于创建高质量的应用 程序是至关重要的。在应用程序级，数据程序是至关重要的。在应用程序级，数据 模型到数据库的转变是实现系统业务目标模型到数据库的转变是实现系统业务目标 的关键。在业务级，收集存储在不同的数的关键。在业务级，收集存储在不同的数 据库中的信息并重新组织为据库中的信息并重新组织为”

58、数据仓库数据仓库“， 要使用数据挖掘或知识发现技术，这些技要使用数据挖掘或知识发现技术，这些技 术影响业务本身的成功。在各种情况下，术影响业务本身的成功。在各种情况下， 数据设计都发挥了重要作用。数据设计都发挥了重要作用。 软件工程讲义第七章设计概念 体系结构设计元素 v软件的体系结构等效于房屋的平面图。平面图描软件的体系结构等效于房屋的平面图。平面图描 绘了房间的整体布局，包括各房间的尺寸、形状、绘了房间的整体布局，包括各房间的尺寸、形状、 相互之间的联系，能够进出房间的门窗。平面图相互之间的联系，能够进出房间的门窗。平面图 为我们提供了房屋的整体视图；而体系结构设计为我们提供了房屋的整体视

59、图；而体系结构设计 元素为我们提供了软件的整体视图。元素为我们提供了软件的整体视图。 v体系结构模型从以下三个来源获得：体系结构模型从以下三个来源获得：(1)关于将关于将 要构建的软件的应用域信息；要构建的软件的应用域信息；(2)特定的分析模特定的分析模 型元素，如数据流图或分析类、现有问题中它们型元素，如数据流图或分析类、现有问题中它们 的关系和协作；的关系和协作；(3)体系结构模式和风格的可获体系结构模式和风格的可获 得性。得性。 软件工程讲义第七章设计概念 接口设计元素 v软件的接口设计相当于一组房屋的门、窗和外部软件的接口设计相当于一组房屋的门、窗和外部 设施的详细绘图。这些绘图描绘了

60、门窗的尺寸和设施的详细绘图。这些绘图描绘了门窗的尺寸和 形状、门窗的工作方式、设施连接入室的方式和形状、门窗的工作方式、设施连接入室的方式和 在平面图上的室内布置。图纸可以告诉我们门铃在平面图上的室内布置。图纸可以告诉我们门铃 在哪、是否使用内部通信以通知有客来访以及如在哪、是否使用内部通信以通知有客来访以及如 何安装保安系统。门、窗、外部设施的详细图纸何安装保安系统。门、窗、外部设施的详细图纸 （以及规格说明）大体上告诉我们事件和信息如（以及规格说明）大体上告诉我们事件和信息如 何流入和流出住宅以及如何在平面图的房间内流何流入和流出住宅以及如何在平面图的房间内流 动。类似地，软件接口设计元素