《软件工程课件08》由会员分享，可在线阅读，更多相关《软件工程课件08（30页珍藏版）》请在金锄头文库上搜索。
1、软件工程,1,软件工程 第八章 设计工程,8.1 软件设计的概念 8.2 设计模型 8.3 基于模式的软件设计,软件工程,2,8.1 软件设计的概念,软件设计的基本目标是用比较抽象概括的方式确定目标系统如何完成预定的任务，即软件设计是确定系统的物理模型。 从技术观点来看，软件设计包括数据设计、体系结构设计、接口设计、构件设计。 数据设计将实体关系图中描述的对象和关系，以及数据字典中描述的详细数据内容转化为数据结构的定义。,软件工程,3,体系结构设计定义软件系统各主要成份之间的关系。 接口设计根据信息流图定义软件内部各成份之间、软件与其它协同系统之间及软件与用户之间的交互机制。 构件设计则是把结
2、构成份转换成软件构件的过程性描述。,软件工程,4,将分析模型转换为设计,软件工程,5,从工程管理角度来看，软件设计分两步完成：概要设计和详细设计。 概要设计 将软件需求转化为软件体系结构 确定系统级接口 全局数据结构或数据库模式。 详细设计 确立每个模块的实现算法和局部数据结构 用适当方法表示算法和数据结构的细节,软件工程,6,软件设计是后续开发步骤及软件维护工作的基础。如果没有设计，只能建立一个不稳定的系统结构。,软件工程,7,软件设计既是过程又是模型。 设计过程是一系列的迭代步骤，使设计人员能够描述目标系统的各个侧面。 设计模型首先描述目标系统的整体架构，然后逐步细化架构得到构造每个细节的
3、指导原则，从而得到系统的一系列不同的视图。 良好的设计原则可为设计过程导航。 衡量设计过程的技术原则： 设计必须实现分析模型中描述的所有显式需求，必须满足用户希望的所有隐式需求。,衡量软件设计的原则,软件工程,8,对于开发者和未来的维护者而言，设计必须是可读的、可理解的，使得将来易于编程、易于测试、易于维护。 设计应该给出软件的全貌，包括从实现角度可看到的数据、功能、行为。 衡量设计模型的技术原则 设计模型应该是一个分层结构。该结构： 使用可识别的设计模式搭建系统结构。 用显示良好设计特征的构件构成。 可以用演化的方式实现。 设计应当模块化。,软件工程,9,设计应当包含数据、体系结构、接口和构
4、件（模块）的清晰的视图。 设计应当根据将要实现的对象和数据模式导出合适的数据结构。 设计应当建立具有独立功能特征的构件。 设计应当建立能够降低模块与外部环境之间复杂连接的接口。 设计模型应当通过使用软件需求信息所驱动的可重复的方法导出。 Davis的软件设计原则 设计应具有可跟踪性，能回溯到软件需求;,软件工程,10,设计不必每次都从头做起，可以复用已有的设计模式和数据模式。 设计应当缩小软件与现实世界中问题的“智力距离”，尽量逼近问题领域的结构; 设计应具有一致性和集成性。整个系统应具有统一的风格和格式，具有良好的接口。 设计结果应能适应未来可能的变更; 设计不是编码，编码也不是设计。设计模
5、型的抽象级别比源代码高。在编码级别上唯一的设计决策是补充一些实现细节。,软件工程,11,设计应具有容错性和异常处理能力。对于异常数据、事件、操作条件等能够平滑处理。 在建立设计方案时就应能评估设计质量，而不是在系统编码之后。 应坚持设计评审，减少概念性（语义性）的错误。 1) 设计应遵循抽象化的原则，包含数据抽象和过程抽象。,软件设计的主要手段,软件工程,12,过程抽象 是指在软件设计中将处理过程的实现细节隐藏在过程抽象中，可以直接通过模块接口使用这些处理操作。 数据抽象 是指采用抽象数据类型表示数据，实现数据封装，使得使用者可通过接口使用数据而不必关心数据结构的实现。,软件工程,13,抽象案
6、例,1993年，美国微软公司推出了它的90年代操作系统Windows NT。在它的许多特色中，有一个特点是它的一体化的“输入/输出系统”的设计。设计者们利用抽象原则，把操作系统的文件管理、网络管理、设备管理和高速缓冲存储器这四个十分不同的事物进行分析，抽取其共性，最后将其统一为“对虚拟文件的字节流，虚拟文件可以为任何设备和实体”，从而设计出具有统一外貌、统一处理模式和规范一体化的输入/输出系统，获得极大成功。,软件工程,14,2) 设计应遵循自顶向下、逐步细化的原则，建立一个层次的结构。 将软件体系结构自顶向下，对过程细节和数据细节从抽象到具体，逐层细化，直到用编程语言的语句能够实现为止。 3
7、) 设计模式描述了在某个特定场景中解决某个特定问题的设计结构。 模式是否适合当前的工作 模式是否能够复用 模式是否能够用于指导开发一个类似但是功能或结构不同的模式,软件工程,15,4) 设计应当遵循模块化的原则。 每个模块可独立地开发、测试，最后组装成完整的程序。 其出发点是本着将一种复杂问题“分而治之”的原则。其目的是使程序的结构清晰，容易阅读、理解、测试、修改。 Meyer的良好模块设计方法的标准 模块可分解性 可将系统按问题子问题分解的原则分解成系统的模块层次结构; 模块可组装性 可利用已有的设计构件组装成新系统，不必一切从头开始。,软件工程,16,模块化的依据,规律一：如果问题P1的复
8、杂性大于问题P2 ，则解决问题P1需要的工作量大于解决问题P2需要的工作量。 C(P1)C(P2) 显然 E(P1)E(P2) 这个不等式导致“各个击破”的结论把复杂的问题分解成许多容易解决的小问题，原来的问题也就容易解决了。这就是模块化的根据。 规律二：如果一个问题Q分别由P1和P2组成而成，那么它的复杂程度大于分别考虑每个问题时的复杂程度之和。 由此可以得出，解决问题Q需要的工作量大于分别解决问题P1和P2需要的工作量之和。 C(P1 + P2)C(P1)+C(P2) 也就是说，如果一个问题由和两个问题组合而成，那么它的复杂程序大于分别考虑每个问题时的复杂程度之和。 综上所述，得到下面的不
9、等式 E(P1 + P2)E(P1)+E(P2),软件工程,17,模块可理解性 一个模块可不参考其他模块而被理解； 模块连续性 对软件需求的一些微小变更只导致对某个模块的修改而整个系统不用大动; 模块保护 将模块内出现异常情况的影响范围限制在模块内部； 5) 设计应遵循信息隐蔽的原则。 Patnas主张在开发时，将每个程序的成分隐藏在模块内，定义每一个模块时尽可能少地显露其内部的处理。,软件工程,18,每个模块的实现细节对于其它模块是隐蔽的，将来修改软件时偶然引入错误所造成的影响就可以局限在一个或几个模块内部，不致波及到软件的其它部分。 在可预见将来可能修改的场合，信息隐蔽可以提高软件的可修改
10、性、可测试性和可移植性。 6) 功能独立性是抽象、模块化和信息隐蔽的直接产物。如果一个模块能够独立于其他模块被编程、测试和修改，则该模块具有功能独立性。,软件工程,19,1978年Myers提出用两个准则来度量功能独立性，即模块间的耦合和模块的内聚。 内聚性：内聚是一个模块内部各个元素彼此结合的紧密程度的度量。 耦合性: 耦合是模块间互相连接的紧密程度的度量，它取决于各个模块之间接口的复杂度、调用方式以及哪些信息通过接口。,软件工程,20,设计类,设计类通过精化分析类获得，设计类的细节将促成类的实现； 创建一组新的设计类，设计类实现了软件的基础设施以支持业务解决方案； 五种不同设计类 用户接口
11、类 业务域类 过程类 持久类 系统类,软件工程,21,设计模型的元素很多都是在分析模型中使用的UML图。差别在于这些图被精化和细化为设计的一部分，并且提供了更多的与实现相关的特殊细节，突出了体系结构的结构和风格，体系结构内的构件和外界之间的接口。 数据设计元素 体系结构设计元素 接口设计元素 构件级设计元素 部署级设计元素,8.2 设计模型,软件工程,22,数据设计元素 数据模型 数据结构，数据库 体系结构设计元素 将要构建的软件的应用域信息 分析模型元素，如数据流图、类图 体系结构的模式和风格 接口设计元素 用户界面（UI） 和其他系统、设备、网络或其他的信息生产者或使用者的外部接口 各种设
12、计构件之间的内部接口,软件工程,23,接口设计表示,软件工程,24,构件图,软件工程,25,部署图,软件工程,26,任何领域的顶级设计人员都有一种不可思议的能力，他们能描述问题和其中的相应多个模式，组合这些模式就可以形成问题的解决方案。 设计模式的模板 模式名和分类 模式名描述了模式的本质。 意图 说明设计模式做什么？基本原理和意图是什么？它要解决什么特定设计问题？ 别名 模式的其他名称。,8.3 基于模式的软件设计,软件工程,27,动机 说明设计问题以及如何用模式中的类、对象来解决该问题的特定情景。 适用性 什么情况下可使用该设计模式？该模式可用来改进哪些不良设计？ 结构 采用UML描述模式
13、中的类，并使用顺序图说明对象间的请求序列和协作关系。 参与者 设计模式中的类和/或对象以及它们各自的职责。 效果 模式怎样支持它的目标？使用模式的效果和所需做的权衡取舍？系统结构的哪些方面可以独立改变？,软件工程,28,实现 实现模式时需要知道的一些提示、技术要点及应避免的缺陷，以及是否存在某些特定于实现语言的问题。 代码示例 说明怎样用 C+ 或 SmallTalk 实现该模式的代码片段。 已知应用 实际系统中发现的模式的例子，每个模式应至少包括两个不同领域的实例。 相关模式 与这个模式紧密相关的模式有哪些？其间重要的不同之处是什么？这个模式应与哪些其他模式一起使用？,软件工程,29,课堂讨论问题,Mini-library系统的部署图可能是什么样的，请尝试画出。,软件工程,30,课后作业,优秀设计的特征是什么？书上P149 设计人员可以创建什么类型的设计类？书上P156,
