软件工程

第7章 设计工程

主要内容 软件工程中的设计 设计过程和设计质量 设计概念 设计模型 基于模式的软件设计 小结

设计工程 设计创建了软件的表达或模型，但与分析模型（关注于说明必需的数据、功能和行为）不同，设计模型提供了软件数据结构、体系结构、接口和构件的细节，而这些都是实现系统必需的。 设计要让软件工程师为将要构建的系统或产品建立模型。在生成代码、进行测试以及在涉及大量最终用户使用之前，可能要评估该模型的质量并进行改进。设计是确立软件质量的关键步骤。

设计工程 设计可以采用很多不同的方法描绘软件。首先，设计必须体现系统或产品的体系结构；其次，为各类接口建模，这些接口在软件和最终用户、软件和其他系统及设备以及软件和自身组成的构件之间起到联系作用；最后，设计用于构建系统的软件构件。每个视图表现了不同的设计活动，但是都要遵循一组基本的设计概念，这些设计概念指导着所有的软件设计工作。

设计工程 在软件设计过程中，包含体系结构、接口、构件和部署表示的设计模型是主要的工作产品。 可以从以下诸方面来评估设计模型：确定设计模型是否存在错误、不一致或遗漏，是否存在更好的方案可供选择，设计模型是否可以在已经设定的限制、时间进度和花费下实现。

设计工程 设计工程包括一套原理、概念和实践，可以指导高质量的系统或产品开发。设计原理建立了最重要的原则，用以指导设计师工作。在运用设计实践的技术和方法之前，必须先理解设计概念，而且设计实践本身会导致产生各种软件设计表示，这些表示将指导随后的构建活动。

设计工程 设计是一项核心的工程活动。Lotus 1-2-3的发明人在《Dr.Dobbs杂志》上发表了“软件设计宣言”：设计是你身处两个世界——技术世界和人类的目标世界——而你尝试将这两个世界结合在一起……设计良好的建筑应该展示出坚固、适用和令人赏心悦目的特点。对好的软件来说也是如此。所谓坚固，是指程序应该不含任何妨碍其功能的缺陷。适用是要程序符合开发的目标。赏心悦目则是要求使用程序的体验应是愉快的。

设计工程 设计工程的目标是创作出坚固、适用和赏心悦目的模型或设计表示。 为此，设计师的做法必须先实现多样化再行聚合。多样化是指要获取多种方案和设计的原始资料，包括目录、教科书和头脑中的构件、构件方案和知识。在各种信息汇聚在一起之后，设计师应从其中挑选能够满足需求工程和分析模型所定义的需求的元素。此时，设计工程师在经取舍后，进行聚合，使之成为构件的某种特定的配置，于是便得到最终的产品。 多样化和聚合需要直觉和判断力，其质量取决于构造类似实体的经验、一系列指导模型演化方式的原则和(或)启发、一系列质量评价的标准以及导出最终设计表示的迭代过程。

设计工程 在本章将探讨可以应用于所有软件设计的基本概念和原则、设计模型的元素以及模式对设计过程的影响。在随后的章节中，将考察应用于体系结构、接口和构件级设计的各种各样的设计方法。

软件工程中的设计 软件设计在软件工程过程中处于技术核心，并且它的应用与所使用的软件过程模型无关。对软件需求进行分析和建模开始之后，软件设计是建模活动的最后一个软件工程动作，接着便要进入构造阶段。 分析模型的每个元素都提供了创建四种设计模型所必需的信息，这四种设计模型是完成完整的设计规格说明所必需的。软件设计过程中的信息流如图7-1所示。由基于场景的元素、基于类的元素和行为元素所表明的分析模型是设计任务的输入。

软件工程中的设计 图7-1从分析模型到设计模型的转化

软件工程中的设计 数据/类设计将分析类模型转化为设计类的实现以及软件实现所要求的数据结构。CRC索引卡定义的类和关系、类属性和其他表示法刻画的详细数据内容为数据设计活动提供了基础。在和软件体系结构设计连接中可能会有部分的类设计，更详细的类设计在设计每个软件构件时进行。 体系结构设计定义了软件的主要结构元素之间的联系、可用于达到系统所定义需求的体系结构风格和设计模式以及影响体系结构实现方式的约束。体系结构设计表示——基于计算机系统的框架——可以从系统规格说明、分析模型和分析模型中定义的子系统的交互导出。

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

软件工程中的设计 软件设计的重要性可以用一个词来表达——质量。设计是软件工程中形成质量的地方，设计为我们提供了可以用于质量评估的软件表示，设计是我们能够将用户需求准确地转化为软件产品或系统的唯一方法。软件设计是所有软件工程活动和随后的软件支持活动的基础。没有设计，我们冒构造不稳定系统的风险，这样的系统稍做改动就无法运行，而且难以测试，直到软件工程过程的后期才能评估其质量。

设计过程和设计质量 软件设计是一个迭代的过程，通过设计过程，需求被变换为用于构建软件的“蓝图”。初始时，蓝图描述了软件的整体视图，也就是说，设计是在高抽象层次上的表达——在该层次上可以直接跟踪到特定的系统目标和更详细的数据、功能和行为需求。随着设计迭代的开始，后续的精化导致更低抽象层次的设计表示。这些表示仍然能够跟踪到需求，但是连接更加错综复杂了。

设计过程和设计质量 [MCG91]提出了可以指导评价良好设计演化的三个特征： 设计必须实现所有包含在分析模型中的明确需求，而且必须满足客户期望的所有隐含需求。 对于那些生成代码的人和那些进行测试以及随后维护软件的人而言，设计必须是可读的、可理解的指南。 设计必须提供软件的全貌，从实现的角度说明数据域、功能域和行为域。

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

质量指导原则 设计应导出数据结构，这些数据结构适于要实现的类，并由可识别的数据模式提取。 设计应导出显示独立功能特征的构件。 设计应导出接口，这些接口降低了构件之间以及与外部环境连接的复杂性。 设计的导出应根据软件需求分析过程中获取的信息采用可重复使用的方法进行。 应使用能够有效传达其意义的表示法来表达设计。

质量属性 HP开发了一系列软件质量属性，称为FURPS，分别代表功能性、易用性、可靠性、性能、可支持性。FURPS质量属性体现了所有软件设计的目标。 功能性：评估程序的特征集和能力、所提交功能的普遍性以及整个系统的安全性。 易用性：通过考虑人为因素、整体美感、一致性和文档来评估。 可靠性：通过测量故障的频率和严重性、输出结果的精确性、故障平均时间MTTF、故障恢复能力和程序的可预见性来评估。 性能：度量处理速度、响应时间、资源消耗、吞吐量和效率。 可支持性：综合了扩展程序、适应性和耐用性三方面的能力，此外还包括可测试性、兼容性、可配置性、系统安装的简易性和问题定位的简易性。

设计任务集 检查信息域模型，并为数据对象及其属性设计恰当的数据结构。 使用分析模型，选择一个适于软件的体系结构类型。 将分析模型分割为若干个设计子系统，并在体系结构内分配这些子系统。要确定每个子系统是功能内聚的。设计子系统接口。为每个子系统分配分析类或功能。 创建一系列的设计类或构件。将每个分析类说明转化为设计类。据设计标准检查每个设计类，考虑继承问题。定义与每个设计类相关的方法和消息。评估设计类或子系统并为这些类或子系统选择设计模式。评审设计类，并在需要时修改。 设计外部系统或设备所需要的所有接口。

设计任务集 设计用户接口。评审任务分析的结果。基于用户场景详细说明活动序列。创建接口的行为模型。定义接口对象、控制机制。评审接口设计，并在需要时修改。 进行构件级设计。在相对较低的抽象层次上详细说明所有算法。精化每个构件的接口。定义构件级的数据结构。评审每个构件并修正所有已发现的错误。 开发部署模型。

设计概念 在软件工程的历史进程中发展了一系列基本的软件设计概念。尽管多年来对于每一种概念的关注程度不断变化，但它们都经历了时间的考验。每一种概念都为软件设计者提供了应用更加复杂设计方法的基础。 基础的软件设计概念为“使程序正确”提供了必要的框架。

抽象 当考虑某一问题的模块化解决方案时，可以给出许多抽象级。在最高的抽象级上，使用问题所处环境的语言以概括性的术语描述解决方案。在较低的抽象级上，将提供更详细的解决方案说明。

抽象 在不同的抽象级间移动时，我们力图创建过程抽象和数据抽象。过程抽象是指具有明确和有限功能的指令序列。过程抽象的命名暗示了这些功能，但是隐藏了具体的细节。 数据抽象是描述数据对象的冠名数据集合。

体系结构 软件体系结构意指“软件的整体结构和这种结构为系统提供概念上完整性的方式”。从最简单的形式看，体系结构是程序构件(模块)的结构或组织、这些构件交互的形式以及这些构件所用数据的结构。 软件设计的目标之一是导出系统的体系结构透视图，该透视图作为一个框架，将指导更详细的设计活动。一系列的体系结构模式使得软件工程师能够复用设计级的概念。

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

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

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

模块化 考虑两个问题p1和p2，如果p1的理解复杂度大于p2的理解复杂度，那么解决p1所需的工作量大于解决p2所需的工作量。 另一个结果是两个问题结合时的理解复杂度通常要大于每个问题各自的理解复杂度之和。这引出了“分而治之”的策略：将一个复杂问题分解成可以管理的若干块，这样能够更容易解决问题。

模块化 似乎可以得出结论：如果我们无限制地划分软件，那么开发它所需的工作量会变得小到可以忽略!然而，其他因素开始起作用，导致这个结论不成立。如图8-2所示，开发某个独立软件模块的工作量的确随着模块数增加而下降，给定同样的需求，更多的模块意味着每个模块的规模更小。然而，随着模块数量增加，集成模块的工作量也在增加。事实上，的确存在一个模块数量M可以带来最小的开发成本。但是，我们缺乏必要的技术来精确地预测M。

模块化 图7-2 模块化和软件成本

模块化 做模块化设计(以及由其产生的程序)可以更容易地计划开发；可以定义和交付软件增量；更容易实施变更；能够更有效地开展测试和调试；可以开展长期维护而没有严重的副作用。

信息隐蔽 模块化概念让每个软件设计师面对一个基本问题：我们将如何分解一个软件解决方案以求获得最好的模块集合？信息隐蔽原则建议模块应该具有的特征是：每个模块对其他所有模块都隐蔽自己的设计决策。即模块应该详细说明且精心设计以求在某个模块中包含的信息不被不需要这些信息的其他模块访问。

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

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

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

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

功能独立 内聚性是信息隐蔽概念的自然扩展。一个内聚的模块执行一个独立的任务，与程序的其他部分构件只需要很少的交互。简单地说，一个内聚的模块应该只完成一件事情。 耦合性表明软件结构中多个模块之间的相互连接。耦合性依赖于模块之间的接口复杂性、引用或进入模块所在的点以及什么数据通过接口传递。在软件设计中，我们将尽力得到尽可能低的耦合。模块间简单的连接性使得软件易于理解并减少“涟漪效果”的倾向，“涟漪效果”是指在某个地方发生错误时导致扩散到整个系统。

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

求精 抽象和精化是互补的概念。抽象使得设计人员能够明确说明过程和数据而同时忽略低层细节；精化有助于设计人员在设计过程中揭示低层的细节。这两个概念均有助于设计人员在设计演化中构造出完整的设计模型。

重构 重构是一种重新组织的技术，可以简化构件的设计而无需改变其功能或行为。[FOW99]这样定义重构：“重构是使用这样一种方式改变软件系统的过程：不改变代码的外部行为而是改进其内部结构。” 当重构软件时，检查现有设计的冗余性、没有使用的设计元素、低效的或不必要的算法、拙劣的或不恰当的数据结构以及其他设计不足，修改这些不足从而获得更好的设计。

设计类 在设计模式演化时，软件团队必须定义一组设计类：(1)通过提供设计细节精化分析类，这些设计细节将促成类的实现；(2)创建一组新的设计类，该设计类实现了软件的基础设施以支持业务解决方案。[AMB01]建议了五种不同类型的设计类，每一种都表现了设计体系结构的一个层次。

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

设计类 在设计模型演化时，软件团队必须为每个设计类开发一组完整的属性和操作。随着每个分析类转化为设计表示，抽象级就降低。即分析类使用业务域的专门用语描述对象；设计类更多地表现技术细节，将作为实现的指导。 [ARL02]为组织良好的设计类定义了四个特征。

设计类 完整性与充分性：设计类应该完整地封装所有的，可以合理预见会存在于类中的属性和方法。充分性确保设计类只包含那些“对实现这个类的目的足够”的方法，不多也不少。 原始性：和某个设计类相关的方法应该关注于实现类的某个服务。一旦服务已经被某个方法实现，类就不应该再提供另外一种完成同一事情的方法。

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

图7-3 FloorPlan的设计类和类的复合聚集 SAFEHOME实例[26] 图7-3 FloorPlan的设计类和类的复合聚集

设计模型 设计模型可以从两不同的维度观察，如图7-4所示。过程维度表示设计模型的演化，设计工作作为软件过程的一部分被执行；抽象维度表示过程的详细级别，分析模型的每个元素转化为一个等价的设计，然后迭代精化。图中虚线表示分析模型和设计模型之间的边界。在某些情况下，分析模型和设计模型之间可能存在清晰的差别；而在有些情况下，分析模型慢慢地融入设计模型而没有明显的差别。

设计模型的维度 图7-4 设计模型的维度

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

数据设计元素 数据设计（有时也称为数据体系结构设计）创建在高抽象级上（以客户/用户的数据观点）表示的数据模型和/或信息模型。然后，数据模型被精化为越来越和实现相关的特定表示，即基于计算机的系统能够处理的表示。在很多软件应用中，数据体系结构对必须处理该数据的软件体系结构有深远的影响。

数据设计元素 数据结构通常是软件设计的重要部分。在程序构件级，数据结构设计以及相关的处理这些数据的算法对于创建高质量的应用程序是至关重要的。在应用程序级，数据模型到数据库的转变是实现系统业务目标的关键。在业务级，收集存储在不同的数据库中的信息并重新组织为”数据仓库“，要使用数据挖掘或知识发现技术，这些技术影响业务本身的成功。在各种情况下，数据设计都发挥了重要作用。

体系结构设计元素 软件的体系结构等效于房屋的平面图。平面图描绘了房间的整体布局，包括各房间的尺寸、形状、相互之间的联系，能够进出房间的门窗。平面图为我们提供了房屋的整体视图；而体系结构设计元素为我们提供了软件的整体视图。 体系结构模型从以下三个来源获得：(1)关于将要构建的软件的应用域信息；(2)特定的分析模型元素，如数据流图或分析类、现有问题中它们的关系和协作；(3)体系结构模式和风格的可获得性。

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

接口设计元素 接口设计有三个重要的元素：(1)用户界面(UI)；(2)和其他系统、设备、网络或其他的信息生产者或使用者的外部接口；(3)各种设计构件之间的内部接口。这些接口设计元素允许软件和外部通信，并使得在软件体系结构内存在的构件之间能够内部通信和协作。

接口设计元素 UI设计是软件工程的主要活动。UI活动包含美学元素（例如布局、颜色、图形、交互机制）、人机工程元素（例如信息布局、隐喻、UI导航）和技术元素（例如UI模式、可复用构件）。通常，UI是整个应用体系结构内独一无二的系统。

接口设计元素 外部接口的设计需要关于发送和接收信息的实体的确定信息。在各种情况下，这些信息应在需求工程中收集，并且一旦开始进行接口设计，还要检验这些信息。外部接口设计应包括错误检查和适当的安全特征。 内部接口的设计和构件级的设计紧密相关。分析类的设计实现了包含如下内容的方案：在各种类的运作之间实现通信和协作所必需的所有操作和消息发送模式。每个消息的设计必须提供必不可少的信息传递和已被请求的操作的特定功能需求。

接口设计元素 在有些情况下，接口建模的方式和类所用的方式几乎一样。UML定义接口如下：“接口是类、构件或其他分类（包括子系统）的外部可见的操作说明，而没有内部结构的规格说明。”更简单地说，接口是一组描述类的部分行为的操作，并提供了那些操作的访问方法。

SAFEHOME实例[27]

图7-5 ControlPanel的UML接口设计表示 SAFEHOME实例[28] 图7-5 ControlPanel的UML接口设计表示

SAFEHOME实例[29]

构件级设计元素 软件的构件级设计完全类似于某个房屋中的一组详细绘图（以及规格说明）。这些绘图描绘了每个房间内的布线和管道、电器插座和开关、水龙头、水池、浴室、浴盆、下水道、壁橱和储藏室的位置，还说明了所使用的地板、装饰以及和房间相关的任何细节。软件的构件级设计完整地描述了每个软件构件的内部细节。为此，构件级设计为所有本地数据对象定义数据结构，为所有在构件内发生的处理定义算法细节，并定义允许访问构件操作（行为）的接口。

构件级设计元素 在面向对象的软件工程中，使用UML图表现的构件如图7-6所示。图中表示的构件名为SensorManagement(SafeHome安全功能的一部分)。虚线箭头连接了构件和名为Sensor的类。SensorManagement构件完成所有和SafeHome传感器相关的功能，包括监测和配置传感器。 构件的细节设计可以在很多不同的抽象级下建模。活动图可以用于表示处理逻辑，构件详细的处理流可以使用伪代码表示，也可以使用一些图形来表示。

图7-6 SensorManagement的UML构件图 SAFEHOME实例[30] 图7-6 SensorManagement的UML构件图

部署级设计元素 部署级设计元素指明软件功能和子系统将如何在支持软件的物理计算环境内分布。例如SafeHome产品元素被配置为在三个主要的计算环境内运行——基于住宅的PC、SafeHome控制面板和位于CPI公司的服务器(提供基于Internet的系统访问)。 在设计过程中，开发的UML部署图以及随后的精化如图7-7所示。图中显示了三个计算环境（实际上，还可能包括传感器、摄像头和其他的环境）。图中标识出了每个计算元素中的子系统。如个人计算机中有完成安全、监视、住宅管理和通信功能的子系统。此外，还设计了一个外部访问子系统以管理外界资源对SafeHome系统的访问。细化每个子系统，用以说明该子系统所实现的构件。

SAFEHOME实例[31] 图8-7 SafeHome的UML部署图

部署级设计元素 图8-7所示的图使用描述符形式，这意味着部署图显示了计算环境但并没有明确地说明配置细节。在后面的阶段或构建开始时，应该用实例形式重新为部署图提供这些细节，明确每个实例的部署（专用的称为硬件配置）。

基于模式的软件设计 任何领域的顶级设计人员都具有一种不可思议的能力，就是看出其中的模式，即刻画问题和相应的多个模式的特点，组合这些模式就可以形成解决方案。贯穿整个设计过程，软件设计人员都应寻找每个机会重用现有的设计模式而不是创建一个全新的。

描述设计模式 成熟的工程学科利用成千上万的设计模式。模式中固有的东西是属性和操作。设计模式可以使用如下的模板来描述。

描述设计模式 设计模式的描述还可以考虑一系列的设计影响因素。设计影响因素描述与应用该模式的软件相关的非功能性的需求（例如维护的简易性、可移植性）。此外，影响因素定义了可能限制设计实现方式的一些约束。本质上，设计影响因素描述了使用设计模式所必需的环境和条件。模式特征（类、职责和协作）指出了设计的属性，调整这些属性可以帮助模式适应各种各样的问题。这些属性表现了设计的特点，可以通过搜索找到一个恰当的模式。最终，与使用设计模式相关的指导原则指出了设计决策的结果。 应该慎重选择设计模式的名称。软件复用中的一个关键问题是当存在成百上千的候选模式时，不能找到合适的可复用模式。一个有意义的模式名称将有助于查找“恰当”的模式。

在设计中使用模式 在整个软件设计中都可以使用设计模式。一旦开发了分析模型，设计人员可以检查待求解问题的详细表示和该问题所带来的限制。在各种抽象级上检查问题说明，以确定如下类型的设计模式中的一个或多个是否适合该问题。

在设计中使用模式 这些模式类型的不同不仅在于每一个模式都是在不同的抽象级上的表示，还在于为软件过程中构建活动提供直接指导的抽象等级也不同。 体系结构模式：这些模式定义软件的整体结构，体现了子系统和软件构件之间的关系，并定义了说明体系结构元素（类、包、构件、子系统）之间关系的规则。 设计模式：这些模式解决设计中特有的元素，例如解决某些设计问题中的构件聚集、构件间的联系或影响构件到构件之间通信的机制。 习惯用语：有时被称为编码模式，这些编程语言所特有的模式通常实现了构件、特定的接口协议或构件之间通信机制的算法元素。 这些模式类型的不同不仅在于每一个模式都是在不同的抽象级上的表示，还在于为软件过程中构建活动提供直接指导的抽象等级也不同。

框架 在某些情况下，可能需要为设计工作提供和实现相关的特定的骨架基础设施（被称作框架）。也就是说，设计人员可能选择一个“可复用的小架构，该架构为一簇软件抽象及其环境提供通用的结构和行为……从而在给定的域中表明它们的协作和使用“。 框架不是体系结构模式，而是一个带有”插入点”集合的骨架，插入点使得体系结构能够适应特定的问题域。插入点使得设计人员能够在骨架内集成与问题相关的特定类。在面向对象的环境内，框架是相互合作的类的集合。

框架 实质上，框架的设计人员会坚持说一个可复用的小架构适用于在某一有限的应用域中开发的所有软件。为了实现最有效，框架的使用没有变化，但可以添加附加的设计元素，即设计人员只有插入点来充实、丰满框架的骨架。

小结

小结

作业 P165页 8.3 8.8