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

《软件工程讲义第七章 设计概念精.ppt》由会员分享，可在线阅读，更多相关《软件工程讲义第七章 设计概念精.ppt（78页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

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

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

3、设备以及软件和自身组成的构件之间起到联系以及软件和自身组成的构件之间起到联系作用；最后，设计用于构建系统的作用；最后，设计用于构建系统的软件构软件构件件。每个视图表现了不同的设计活动，但。每个视图表现了不同的设计活动，但是都要遵循一组是都要遵循一组基本的设计概念基本的设计概念，这些设，这些设计概念指导着所有的软件设计工作。计概念指导着所有的软件设计工作。第5页，本讲稿共78页设计工程v 在软件设计过程中，包含在软件设计过程中，包含体系结构体系结构、接接口口、构件构件和和部署部署表示的设计模型是主要的表示的设计模型是主要的工作产品。工作产品。v可以从以下诸方面来评估设计模型：确可以从以下诸方面来

4、评估设计模型：确定设计模型是否定设计模型是否存在错误存在错误、不一致或遗漏不一致或遗漏，是否是否存在更好的方案存在更好的方案可供选择，设计模型可供选择，设计模型是否可以在是否可以在已经设定的限制已经设定的限制、时间进度时间进度和和花费花费下实现。下实现。第6页，本讲稿共78页设计工程v设计工程包括一套设计工程包括一套原理原理、概念概念和和实践实践，可以指导高质量的系统或产品开发。设计可以指导高质量的系统或产品开发。设计原理建立了最重要的原则，用以指导设计原理建立了最重要的原则，用以指导设计师工作。在运用设计实践的技术和方法之师工作。在运用设计实践的技术和方法之前，必须先理解设计概念，而且设计实

5、践前，必须先理解设计概念，而且设计实践本身会导致产生各种软件设计表示，这些本身会导致产生各种软件设计表示，这些表示将指导随后的表示将指导随后的构建活动构建活动。第7页，本讲稿共78页设计工程v设计是一项核心的工程活动。设计是一项核心的工程活动。Lotus 1-2-3的发明的发明人在人在Dr.Dobbs杂志杂志上发表了上发表了“软件设计宣言软件设计宣言”：设计是你身处两个世界：设计是你身处两个世界技术世界和人类的目标技术世界和人类的目标世界世界而你尝试将这两个世界结合在一起而你尝试将这两个世界结合在一起设设计良好的建筑应该展示出坚固、适用和令人赏心悦计良好的建筑应该展示出坚固、适用和令人赏心悦目

6、的特点。对好的软件来说也是如此。所谓坚固，目的特点。对好的软件来说也是如此。所谓坚固，是指程序应该不含任何妨碍其功能的缺陷。适用是是指程序应该不含任何妨碍其功能的缺陷。适用是要程序符合开发的目标。赏心悦目则是要求使用程要程序符合开发的目标。赏心悦目则是要求使用程序的体验应是愉快的。序的体验应是愉快的。第8页，本讲稿共78页设计工程v设计工程的目标是创作出坚固、适用和设计工程的目标是创作出坚固、适用和赏心悦目的模型或设计表示。赏心悦目的模型或设计表示。为此，设计为此，设计师的做法必须先实现多样化再行聚合。多师的做法必须先实现多样化再行聚合。多样化是指要获取多种方案和设计的原始资样化是指要获取多种

7、方案和设计的原始资料，包括目录、教科书和头脑中的构件、料，包括目录、教科书和头脑中的构件、构件方案和知识。在各种信息汇聚在一起构件方案和知识。在各种信息汇聚在一起之后，设计师应从其中挑选能够满足需求之后，设计师应从其中挑选能够满足需求工程和分析模型所定义的需求的元素。工程和分析模型所定义的需求的元素。第9页，本讲稿共78页v此时，设计工程师在经取舍后，进行此时，设计工程师在经取舍后，进行聚合，使之成为构件的某种特定的配聚合，使之成为构件的某种特定的配置，于是便得到最终的产品。置，于是便得到最终的产品。v多样化和聚合需要直觉和判断力，其多样化和聚合需要直觉和判断力，其质量取决于构造类似实体的经验

8、、一质量取决于构造类似实体的经验、一系列指导模型演化方式的原则和系列指导模型演化方式的原则和(或或)启启发、一系列质量评价的标准以及导出发、一系列质量评价的标准以及导出最终设计表示的迭代过程。最终设计表示的迭代过程。第10页，本讲稿共78页设计工程v在本章将探讨可以应用于所有软件设计在本章将探讨可以应用于所有软件设计的基本概念和原则、设计模型的元素以及的基本概念和原则、设计模型的元素以及模式对设计过程的影响。在随后的章节中，模式对设计过程的影响。在随后的章节中，将考察应用于体系结构、接口和构件级设将考察应用于体系结构、接口和构件级设计的各种各样的设计方法。计的各种各样的设计方法。第11页，本讲

9、稿共78页软件工程中的设计v软件设计在软件工程过程中处于技术核软件设计在软件工程过程中处于技术核心，并且它的应用与所使用的软件过程模心，并且它的应用与所使用的软件过程模型无关。对软件需求进行分析和建模开始型无关。对软件需求进行分析和建模开始之后，软件设计是建模活动的最后一个软之后，软件设计是建模活动的最后一个软件工程动作，接着便要进入构造阶段。件工程动作，接着便要进入构造阶段。第12页，本讲稿共78页v需求模型的每个元素都提供了创建四种需求模型的每个元素都提供了创建四种设计模型所必需的信息，这四种设计模设计模型所必需的信息，这四种设计模型是完成完整的设计规格说明所必需的。型是完成完整的设计规格

10、说明所必需的。软件设计过程中的信息流如图软件设计过程中的信息流如图7-1所示。所示。由基于场景的元素、基于类的元素和行由基于场景的元素、基于类的元素和行为元素所表明的分析模型是设计任务的为元素所表明的分析模型是设计任务的输入。使用相应的设计表示法和设计方输入。使用相应的设计表示法和设计方法，将得到数据或类的设计、体系结构法，将得到数据或类的设计、体系结构设计、接口设计和构件设计。设计、接口设计和构件设计。第13页，本讲稿共78页软件工程中的设计图7-1从需求模型到设计模型的转化第14页，本讲稿共78页软件工程中的设计v数据数据/类设计将分析类模型转化为设计类类设计将分析类模型转化为设计类的实现

11、以及软件实现所要求的数据结构。的实现以及软件实现所要求的数据结构。CRC索引卡定义的类和关系、类属性和其索引卡定义的类和关系、类属性和其他表示法刻画的详细数据内容为数据设计他表示法刻画的详细数据内容为数据设计活动提供了基础。在和软件体系结构设计活动提供了基础。在和软件体系结构设计连接中可能会有部分的类设计，更详细的连接中可能会有部分的类设计，更详细的类设计在设计每个软件构件时进行。类设计在设计每个软件构件时进行。第15页，本讲稿共78页v体系结构设计定义了软件的主要结构体系结构设计定义了软件的主要结构元素之间的关系、可用于达到系统所元素之间的关系、可用于达到系统所定义需求的体系结构风格和设计模

12、式定义需求的体系结构风格和设计模式以及影响体系结构实现方式的约束。以及影响体系结构实现方式的约束。体系结构设计表示体系结构设计表示基于计算机系统基于计算机系统的框架的框架可以从需求模型导出。可以从需求模型导出。第16页，本讲稿共78页软件工程中的设计v接口设计描述了软件和协作系统之间、接口设计描述了软件和协作系统之间、软件和使用人员之间是如何通信的。接口软件和使用人员之间是如何通信的。接口就意味着信息流和特定的行为类型。因此，就意味着信息流和特定的行为类型。因此，使用场景和行为模型为接口设计提供了所使用场景和行为模型为接口设计提供了所需的大量信息。需的大量信息。第17页，本讲稿共78页v构件级

13、设计将软件体系结构的结构元构件级设计将软件体系结构的结构元素变换为对软件构件的过程性描述。素变换为对软件构件的过程性描述。从基于类的模型、流模型和行为模型从基于类的模型、流模型和行为模型获得的信息将作为构件设计的基础。获得的信息将作为构件设计的基础。第18页，本讲稿共78页软件工程中的设计v软件设计的重要性可以用一个词来表达软件设计的重要性可以用一个词来表达质量。设计是软件工程中形成质量的质量。设计是软件工程中形成质量的地方，设计为我们提供了可以用于质量评地方，设计为我们提供了可以用于质量评估的软件表示，设计是我们能够将用户需估的软件表示，设计是我们能够将用户需求准确地转化为软件产品或系统的唯

14、一方求准确地转化为软件产品或系统的唯一方法。软件设计是所有软件工程活动和随后法。软件设计是所有软件工程活动和随后的软件支持活动的基础。没有设计，我们的软件支持活动的基础。没有设计，我们冒构造不稳定系统的风险，这样的系统稍冒构造不稳定系统的风险，这样的系统稍做改动就无法运行，而且难以测试，直到做改动就无法运行，而且难以测试，直到软件工程过程的后期才能评估其质量。软件工程过程的后期才能评估其质量。第19页，本讲稿共78页设计过程和设计质量v软件设计是一个迭代的过程，通过设计软件设计是一个迭代的过程，通过设计过程，需求被变换为用于构建软件的过程，需求被变换为用于构建软件的“蓝蓝图图”。初始时，蓝图描

15、述了软件的整体视。初始时，蓝图描述了软件的整体视图，也就是说，设计是在高抽象层次上的图，也就是说，设计是在高抽象层次上的表达表达在该层次上可以直接跟踪到特定在该层次上可以直接跟踪到特定的系统目标和更详细的数据、功能和行为的系统目标和更详细的数据、功能和行为需求。随着设计迭代的开始，后续的精化需求。随着设计迭代的开始，后续的精化导致更低抽象层次的设计表示。这些表示导致更低抽象层次的设计表示。这些表示仍然能够跟踪到需求，但是连接更加错综仍然能够跟踪到需求，但是连接更加错综复杂了。复杂了。第20页，本讲稿共78页设计过程和设计质量vMCG91提出了可以指导评价良好设计提出了可以指导评价良好设计演化的

16、三个特征：演化的三个特征：v设计必须实现所有包含在分析模型中的设计必须实现所有包含在分析模型中的明确需求，而且必须满足客户期望的所有明确需求，而且必须满足客户期望的所有隐含需求。隐含需求。v对于那些生成代码的人和那些进行测试对于那些生成代码的人和那些进行测试以及随后维护软件的人而言，设计必须是以及随后维护软件的人而言，设计必须是可读的、可理解的指南。可读的、可理解的指南。v设计必须提供软件的全貌，从实现的角设计必须提供软件的全貌，从实现的角度说明数据域、功能域和行为域。度说明数据域、功能域和行为域。第21页，本讲稿共78页质量指导原则v设计应展示出这样一种结构：设计应展示出这样一种结构：(a)

17、已经使已经使用可识别的体系结构风格或模式创建；用可识别的体系结构风格或模式创建；(b)由展示出良好设计特征的构件构成；由展示出良好设计特征的构件构成；(c)能够以演化的方式实现，从而便于实现能够以演化的方式实现，从而便于实现和测试。和测试。v设计应该模块化；即软件应按照逻辑划设计应该模块化；即软件应按照逻辑划分为元素或子系统。分为元素或子系统。v设计应该包含数据、体系结构、接口和设计应该包含数据、体系结构、接口和构件的清楚表示。构件的清楚表示。第22页，本讲稿共78页质量指导原则v设计应导出数据结构，这些数据结构适设计应导出数据结构，这些数据结构适于要实现的类，并由可识别的数据模式提于要实现的

18、类，并由可识别的数据模式提取。取。v设计应导出显示独立功能特征的构件。设计应导出显示独立功能特征的构件。v设计应导出接口，这些接口降低了构件设计应导出接口，这些接口降低了构件之间以及与外部环境连接的复杂性。之间以及与外部环境连接的复杂性。v设计的导出应根据软件需求分析过程中设计的导出应根据软件需求分析过程中获取的信息采用可重复使用的方法进行。获取的信息采用可重复使用的方法进行。v应使用能够有效传达其意义的表示法来应使用能够有效传达其意义的表示法来表达设计。表达设计。第23页，本讲稿共78页质量属性vHP开发了一系列软件质量属性，称为开发了一系列软件质量属性，称为FURPS，分别代表功能性、易用

19、性、可靠性、，分别代表功能性、易用性、可靠性、性能、可支持性。性能、可支持性。FURPS质量属性体现了所质量属性体现了所有软件设计的目标。有软件设计的目标。v功能性：评估程序的特征集和能力、所提交功能性：评估程序的特征集和能力、所提交功能的普遍性以及整个系统的安全性。功能的普遍性以及整个系统的安全性。v易用性：通过考虑人为因素、整体美感、一易用性：通过考虑人为因素、整体美感、一致性和文档来评估。致性和文档来评估。第24页，本讲稿共78页v可靠性：通过测量故障的频率和严重性、可靠性：通过测量故障的频率和严重性、输出结果的精确性、故障平均时间输出结果的精确性、故障平均时间MTTF、故障恢复能力和程

20、序的可预见性来评估。故障恢复能力和程序的可预见性来评估。v性能：度量处理速度、响应时间、资源消性能：度量处理速度、响应时间、资源消耗、吞吐量和效率。耗、吞吐量和效率。v可支持性：综合了扩展程序、适应性和耐可支持性：综合了扩展程序、适应性和耐用性三方面的能力，此外还包括可测试性、用性三方面的能力，此外还包括可测试性、兼容性、可配置性、系统安装的简易性和兼容性、可配置性、系统安装的简易性和问题定位的简易性。问题定位的简易性。第25页，本讲稿共78页设计任务集v检查信息域模型，并为数据对象及其属检查信息域模型，并为数据对象及其属性设计恰当的数据结构。性设计恰当的数据结构。v使用分析模型，选择一个适于

21、软件的体使用分析模型，选择一个适于软件的体系结构类型。系结构类型。v将分析模型分割为若干个设计子系统，将分析模型分割为若干个设计子系统，并在体系结构内分配这些子系统。要确定并在体系结构内分配这些子系统。要确定每个子系统是功能内聚的。设计子系统接每个子系统是功能内聚的。设计子系统接口。为每个子系统分配分析类或功能。口。为每个子系统分配分析类或功能。第26页，本讲稿共78页v创建一系列的设计类或构件。将每个分析类说明创建一系列的设计类或构件。将每个分析类说明转化为设计类。据设计标准检查每个设计类，考转化为设计类。据设计标准检查每个设计类，考虑继承问题。定义与每个设计类相关的方法和消虑继承问题。定义

22、与每个设计类相关的方法和消息。评估设计类或子系统并为这些类或子系统选息。评估设计类或子系统并为这些类或子系统选择设计模式。评审设计类，并在需要时修改。择设计模式。评审设计类，并在需要时修改。v设计外部系统或设备所需要的所有接口。设计外部系统或设备所需要的所有接口。第27页，本讲稿共78页设计任务集v设计用户接口。评审任务分析的结果。设计用户接口。评审任务分析的结果。基于用户场景详细说明活动序列。创建接基于用户场景详细说明活动序列。创建接口的行为模型。定义接口对象、控制机制。口的行为模型。定义接口对象、控制机制。评审接口设计，并在需要时修改。评审接口设计，并在需要时修改。v进行构件级设计。在相对

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

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

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

26、(模块模块)的结构或组织、这些构件交互的结构或组织、这些构件交互的形式以及这些构件所用数据的结构。的形式以及这些构件所用数据的结构。v软件设计的目标之一是导出系统的体系软件设计的目标之一是导出系统的体系结构透视图，该透视图作为一个框架，将结构透视图，该透视图作为一个框架，将指导更详细的设计活动。一系列的体系结指导更详细的设计活动。一系列的体系结构模式使得软件工程师能够复用设计级的构模式使得软件工程师能够复用设计级的概念。概念。第32页，本讲稿共78页体系结构v体系结构设计可以使用大量的一种或多体系结构设计可以使用大量的一种或多种模型来表达。结构模型将体系结构表示种模型来表达。结构模型将体系结构

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

28、讲稿共78页模式v设计模式描述了在某个特定场景与可能设计模式描述了在某个特定场景与可能影响模式应用和使用方式的影响模式应用和使用方式的“影响力影响力”中中解决某个特定的设计问题的设计结构。解决某个特定的设计问题的设计结构。v每个设计模式的目的都是提供一个描述，每个设计模式的目的都是提供一个描述，以使得设计人员能够确定：以使得设计人员能够确定：(1)模式是否模式是否适合当前的工作；适合当前的工作；(2)模式是否能够复用；模式是否能够复用；(3)模式是否能够用于指导开发一个类似模式是否能够用于指导开发一个类似但是功能或结构不同的模式。但是功能或结构不同的模式。第34页，本讲稿共78页关注点分离v关

29、注点分离是一个设计概念，它表明任关注点分离是一个设计概念，它表明任何复杂问题如果被分解为可以独立解决和何复杂问题如果被分解为可以独立解决和(或或)优化的若干块，该复杂问题能够更容优化的若干块，该复杂问题能够更容易地被处理。一个关注点是一个特征或行易地被处理。一个关注点是一个特征或行为，被指定为软件需求模型的一部分。通为，被指定为软件需求模型的一部分。通过将关注点分割为更小的关注点，使得解过将关注点分割为更小的关注点，使得解决一个问题需要付出更少的工作量和时间。决一个问题需要付出更少的工作量和时间。第35页，本讲稿共78页模块化v软件体系结构和设计模式表现为模块化；软件体系结构和设计模式表现为模

30、块化；即软件被划分为独立命名的、可寻址的构即软件被划分为独立命名的、可寻址的构件，有时被称为模块，把这些构件集成到件，有时被称为模块，把这些构件集成到一起可以满足问题的需求。一起可以满足问题的需求。v模块化是软件的单个属性，它使程序能模块化是软件的单个属性，它使程序能被理性地管理。软件工程师难以掌握单块被理性地管理。软件工程师难以掌握单块软件。对于大型程序，其控制路径的数量、软件。对于大型程序，其控制路径的数量、引用的跨度、变量的数量和整体的复杂度引用的跨度、变量的数量和整体的复杂度使得理解这样的软件几乎是不可能的。使得理解这样的软件几乎是不可能的。第36页，本讲稿共78页模块化v考虑两个问题

31、考虑两个问题p1和和p2，如果，如果p1的理解的理解复杂度大于复杂度大于p2的理解复杂度，那么解决的理解复杂度，那么解决p1所需的工作量大于解决所需的工作量大于解决p2所需的工作所需的工作量。量。v另一个结果是两个问题结合时的理解复另一个结果是两个问题结合时的理解复杂度通常要大于每个问题各自的理解复杂杂度通常要大于每个问题各自的理解复杂度之和。这引出了度之和。这引出了“分而治之分而治之”的策略：的策略：将一个复杂问题分解成可以管理的若干块，将一个复杂问题分解成可以管理的若干块，这样能够更容易解决问题。这样能够更容易解决问题。第37页，本讲稿共78页模块化v似乎可以得出结论：如果我们无限制地似乎

32、可以得出结论：如果我们无限制地划分软件，那么开发它所需的工作量会变划分软件，那么开发它所需的工作量会变得小到可以忽略得小到可以忽略!然而，其他因素开始起作然而，其他因素开始起作用，导致这个结论不成立。如图用，导致这个结论不成立。如图7-2所示，所示，开发某个独立软件模块的工作量的确随着开发某个独立软件模块的工作量的确随着模块数增加而下降，给定同样的需求，更模块数增加而下降，给定同样的需求，更多的模块意味着每个模块的规模更小。然多的模块意味着每个模块的规模更小。然而，随着模块数量增加，集成模块的工作而，随着模块数量增加，集成模块的工作量也在增加。事实上，的确存在一个模块量也在增加。事实上，的确存

33、在一个模块数量数量M可以带来最小的开发成本。但是，可以带来最小的开发成本。但是，我们缺乏必要的技术来精确地预测我们缺乏必要的技术来精确地预测M。第38页，本讲稿共78页模块化图7-2 模块化和软件成本第39页，本讲稿共78页模块化v做模块化设计做模块化设计(以及由其产生的程序以及由其产生的程序)可可以更容易地计划开发；可以定义和交付软以更容易地计划开发；可以定义和交付软件增量；更容易实施变更；能够更有效地件增量；更容易实施变更；能够更有效地开展测试和调试；可以开展长期维护而没开展测试和调试；可以开展长期维护而没有严重的副作用。有严重的副作用。第40页，本讲稿共78页信息隐蔽v模块化概念让每个软

34、件设计师面对一个模块化概念让每个软件设计师面对一个基本问题：我们将如何分解一个软件解决基本问题：我们将如何分解一个软件解决方案以求获得最好的模块集合？信息隐蔽方案以求获得最好的模块集合？信息隐蔽原则建议模块应该具有的特征是：每个模原则建议模块应该具有的特征是：每个模块对其他所有模块都隐蔽自己的设计决策。块对其他所有模块都隐蔽自己的设计决策。即模块应该详细说明且精心设计以求在某即模块应该详细说明且精心设计以求在某个模块中包含的信息不被不需要这些信息个模块中包含的信息不被不需要这些信息的其他模块访问。的其他模块访问。第41页，本讲稿共78页信息隐蔽v隐蔽意味着通过定义一系列独立的模块可以得到有效隐

35、蔽意味着通过定义一系列独立的模块可以得到有效的模块化，独立模块相互之间只交流实现软件功能所必的模块化，独立模块相互之间只交流实现软件功能所必需的那些信息。抽象有助于定义构成软件的过程实体。需的那些信息。抽象有助于定义构成软件的过程实体。隐蔽定义并加强了模块内的过程细节和模块所使用的任隐蔽定义并加强了模块内的过程细节和模块所使用的任何局部数据结构的访问约束。何局部数据结构的访问约束。v把信息隐蔽用做模块化系统的一个设计标准，在把信息隐蔽用做模块化系统的一个设计标准，在测试和随后的软件维护过程中，在需要修改时将测试和随后的软件维护过程中，在需要修改时将提供最大的益处。因为大多数数据和程序对软件提供

36、最大的益处。因为大多数数据和程序对软件的其他部分是隐蔽的，因此在修改过程中，无意的其他部分是隐蔽的，因此在修改过程中，无意地引入错误并传播到软件其他地方的可能性会很地引入错误并传播到软件其他地方的可能性会很小。小。第42页，本讲稿共78页功能独立v功能独立的概念是模块化、抽象概念和功能独立的概念是模块化、抽象概念和信息隐蔽的直接结果。通过开发具有专一信息隐蔽的直接结果。通过开发具有专一功能和避免与其他模块过多交互的模块，功能和避免与其他模块过多交互的模块，可以实现功能独立。即，我们希望软件设可以实现功能独立。即，我们希望软件设计时要使每个模块仅涉及需求的某个特定计时要使每个模块仅涉及需求的某个

37、特定子功能，并且当从程序结构的其他部分观子功能，并且当从程序结构的其他部分观察时，每个模块只有一个简单的接口。察时，每个模块只有一个简单的接口。第43页，本讲稿共78页功能独立v具有有效模块化的软件更容易开发，这是因为功能被具有有效模块化的软件更容易开发，这是因为功能被分隔而且接口被简化。独立模块更容易维护和测试，因分隔而且接口被简化。独立模块更容易维护和测试，因为修改设计或修改代码所引起的副作用被限制，减少了为修改设计或修改代码所引起的副作用被限制，减少了错误扩散，而且模块复用也成为可能。功能独立是优秀错误扩散，而且模块复用也成为可能。功能独立是优秀设计的关键，而设计又是软件质量的关键。设计

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

39、模块复用也成为可能。功能独立少了错误扩散，而且模块复用也成为可能。功能独立是优秀设计的关键，而设计又是软件质量的关键。是优秀设计的关键，而设计又是软件质量的关键。v独立性可以使用两条定性的标准评估：内聚性和耦独立性可以使用两条定性的标准评估：内聚性和耦合性。合性。内聚性显示了某个模块相关功能的强度；耦内聚性显示了某个模块相关功能的强度；耦合性显示了模块间的相互依赖性。合性显示了模块间的相互依赖性。第45页，本讲稿共78页功能独立v内聚性是信息隐蔽概念的自然扩展。一个内聚的模内聚性是信息隐蔽概念的自然扩展。一个内聚的模块执行一个独立的任务，与程序的其他部分构件只需块执行一个独立的任务，与程序的其

40、他部分构件只需要很少的交互。简单地说，一个内聚的模块应该只完要很少的交互。简单地说，一个内聚的模块应该只完成一件事情。成一件事情。v耦合性表明软件结构中多个模块之间的相互连接。耦合性表明软件结构中多个模块之间的相互连接。耦合性依赖于模块之间的接口复杂性、引用或进入模耦合性依赖于模块之间的接口复杂性、引用或进入模块所在的点以及什么数据通过接口传递。在软件设计块所在的点以及什么数据通过接口传递。在软件设计中，我们将尽力得到尽可能低的耦合。模块间简单的中，我们将尽力得到尽可能低的耦合。模块间简单的连接性使得软件易于理解并减少连接性使得软件易于理解并减少“涟漪效果涟漪效果”的倾向，的倾向，“涟漪效果涟

41、漪效果”是指在某个地方发生错误时导致扩散到是指在某个地方发生错误时导致扩散到整个系统。整个系统。第46页，本讲稿共78页求精v逐步求精是由逐步求精是由Niklaus Wirth最初提出的一种自最初提出的一种自顶向下的设计策略。通过连续精化层次结构的程顶向下的设计策略。通过连续精化层次结构的程序细节来实现程序的开发，层次结构的开发将通序细节来实现程序的开发，层次结构的开发将通过逐步分解功能的宏观陈述直至形成程序设计语过逐步分解功能的宏观陈述直至形成程序设计语言的语句。言的语句。v求精实际上是一个细化的过程。从在高抽象级上求精实际上是一个细化的过程。从在高抽象级上定义的功能陈述开始，该陈述概念性地

42、描述了功能定义的功能陈述开始，该陈述概念性地描述了功能或信息，但是没有提供有关功能内部工作的信息或或信息，但是没有提供有关功能内部工作的信息或数据内部结构的信息。精化促使设计者在原始陈述数据内部结构的信息。精化促使设计者在原始陈述上细化，并随着每个精化的持续进行将提供越来越上细化，并随着每个精化的持续进行将提供越来越多的细节。多的细节。第47页，本讲稿共78页求精v抽象和精化是互补的概念。抽象使得设计人员能够抽象和精化是互补的概念。抽象使得设计人员能够明确说明过程和数据而同时忽略低层细节；精化有助明确说明过程和数据而同时忽略低层细节；精化有助于设计人员在设计过程中揭示低层的细节。这两个概于设计

43、人员在设计过程中揭示低层的细节。这两个概念均有助于设计人员在设计演化中构造出完整的设计念均有助于设计人员在设计演化中构造出完整的设计模型。模型。第48页，本讲稿共78页方面v当我们开始进行需求分析时，一组当我们开始进行需求分析时，一组“关注点关注点”就出现就出现了。这些关注点了。这些关注点“包括需求、用例、特征、数据结构、包括需求、用例、特征、数据结构、服务质量问题、变量、知识产权边界、合作、模式以及服务质量问题、变量、知识产权边界、合作、模式以及合同合同”。理想情况下，可以按某种方式组织需求模型，。理想情况下，可以按某种方式组织需求模型，该方式允许分离每个关注点，使得能够独立考虑每个关该方式

44、允许分离每个关注点，使得能够独立考虑每个关注点。注点。v当开始进行设计时，需求被精化为模块设计表示。当开始进行设计时，需求被精化为模块设计表示。考虑两个需求，考虑两个需求，A和和B。”如果已经选择了一种软件分如果已经选择了一种软件分解，在这种分解中，如果不考虑需求解，在这种分解中，如果不考虑需求A的话，需求的话，需求B就就不能得到满足，那么需求不能得到满足，那么需求A横切需求横切需求B。第49页，本讲稿共78页重构v重构是一种重新组织的技术，可以简化构件的设计而重构是一种重新组织的技术，可以简化构件的设计而无需改变其功能或行为。无需改变其功能或行为。FOW00这样定义重构：这样定义重构：“重构

45、是使用这样一种方式改变软件系统的过程：不改重构是使用这样一种方式改变软件系统的过程：不改变代码的外部行为而是改进其内部结构。变代码的外部行为而是改进其内部结构。”v当重构软件时，检查现有设计的冗余性、没有使当重构软件时，检查现有设计的冗余性、没有使用的设计元素、低效的或不必要的算法、拙劣的用的设计元素、低效的或不必要的算法、拙劣的或不恰当的数据结构以及其他设计不足，修改这或不恰当的数据结构以及其他设计不足，修改这些不足从而获得更好的设计。些不足从而获得更好的设计。第50页，本讲稿共78页设计类v在设计模式演化时，软件团队必须定义一组设计类：在设计模式演化时，软件团队必须定义一组设计类：(1)通

46、过提供设计细节精化分析类，这些设计细节通过提供设计细节精化分析类，这些设计细节将促成类的实现；将促成类的实现；(2)创建一组新的设计类，该设创建一组新的设计类，该设计类实现了软件的基础设施以支持业务解决方案。计类实现了软件的基础设施以支持业务解决方案。AMB01建议了五种不同类型的设计类，每一种都建议了五种不同类型的设计类，每一种都表现了设计体系结构的一个层次。表现了设计体系结构的一个层次。第51页，本讲稿共78页设计类v用户接口类：定义人机交互用户接口类：定义人机交互(HCI)所必需的所有抽象。在所必需的所有抽象。在很多情况下，很多情况下，HCI出现在隐喻的环境，而接口的设计类可能出现在隐喻

47、的环境，而接口的设计类可能是这种隐喻元素的形象表示。是这种隐喻元素的形象表示。v业务域类：通常是早期定义的分析类的精化。这些类识别实现业务域类：通常是早期定义的分析类的精化。这些类识别实现某些业务域所必需的属性和服务。某些业务域所必需的属性和服务。v过程类：实现完整管理业务域类所必需的低层业务抽象。过程类：实现完整管理业务域类所必需的低层业务抽象。v持久类：代表将在软件执行之外持续存在的数据存储。持久类：代表将在软件执行之外持续存在的数据存储。v系统类：实现软件管理和控制功能，使得系统能够运行并在其计系统类：实现软件管理和控制功能，使得系统能够运行并在其计算环境内与外界通信。算环境内与外界通信

48、。第52页，本讲稿共78页设计类v在设计模型演化时，软件团队必须为每在设计模型演化时，软件团队必须为每个设计类开发一组完整的属性和操作。随个设计类开发一组完整的属性和操作。随着每个分析类转化为设计表示，抽象级就着每个分析类转化为设计表示，抽象级就降低。即分析类使用业务域的专门用语描降低。即分析类使用业务域的专门用语描述对象；设计类更多地表现技术细节，将述对象；设计类更多地表现技术细节，将作为实现的指导。作为实现的指导。vARL02为组织良好的设计类定义了四为组织良好的设计类定义了四个特征。个特征。第53页，本讲稿共78页设计类v完整性与充分性：设计类应该完整地封完整性与充分性：设计类应该完整地

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

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