第四章 设计工程思维导图

第四章 设计工程思维导图，此脑图包含软件设计工程概述，软件设计原则，软件体系结构设计，部件级设计技术，设计规约与设计评审，用于复习预习。

第四章 设计工程

• 软件设计工程概述
  • 软件设计工程概述
    • 软件需求分析解决“做什么”的问题，软件设计过程则解决“怎么做”的问题
    • 软件设计是把软件需求变换成软件表示的过程，它主要包含两个阶段：软件体系结构设计阶段和部件级设计
  • 软件设计的任务
    • 使用一种设计方法，软件分析模型中通过数据、功能和行为模型所展示的软件需求的信息被传送给设计阶段，产生数据/类设计、体系结构设计、接口设计、部件级设计
    • 数据/类设计：将分析-类模型变换成类的实现和软件实现所需要的数据结构
      • 在类和由CRC中定义的数据对象和关系以及数据字典中描述的详细数据内容提供了数据设计活动的基础
      • 数据设计的过程包括以下两步 ：
        • 首先，为在需求分析阶段所确定的数据对象选择逻辑表示，需要对不同结构进行算法分析，以便选择一个最有效的设计方案；
        • 然后，确定对逻辑数据结构所必需的那些操作的程序模块，以便限制或确定各个数据设计决策的影响范围。
    • 体系结构设计：体系结构设计定义了软件的整体结构
      • 体系结构设计定义了软件的整体结构，它由软件部件、外部可见的属性和它们之间的关系组成。
      • 体系结构设计表示可以从系统规约、分析模型和分析模型中定义的子系统的交互导出。
    • 接口设计：接口设计描述了软件内部、软件和协作系统之间以及软件同人之间如何通信
      • 接口设计主要包括三个方面：
        • 设计软件模块间的接口
        • 设计模块和其他非人的信息生产者和消费者(比如外部实体)之间的接口
        • 设计人(用户)和计算机间的接口
    • 部件级设计：部件级设计将软件体系结构的结构性元素变换为对软件部件的过程性描述
      • 部件级设计将软件体系结构的结构性元素变换为对软件部件的过程性描述
      • 从类为基础的模型、流模型、行为模型中得到的信息是部件设计的基础
  • 软件设计的目标
    • 在进行软件设计的过程中，我们要密切关注软件的质量因素。
    • McGlanghlin 软件设计过程的目标：
      • 1)设计必须实现分析模型中描述的所有显式需求，必须满足用户希望的所有隐式需求。
      • 2)设计必须是可读、可理解的，使得将来易于编程、易于测试、易于维护。
      • 3)设计应从实现角度出发，给出与数据、功能、行为相关的软件全貌。
  • 衡量设计的技术标准
    • 1) 设计出来的结构应是分层结构，从而建立软件成份之间的控制。
    • 2) 设计应当模块化，从逻辑上将软件划分为完成特定功能或子功能的部件。
    • 3) 设计应当既包含数据抽象，也包含过程抽象。
    • 4) 设计应当建立具有独立功能特征的模块。
    • 5) 设计应当建立能够降低模块与外部环境之间复杂连接的接口。
    • 6) 设计应能根据软件需求分析获取的信息，建立可驱动、可重复的方法。
  • 软件设计的过程
    • 1) 制定规范
    • 2) 体系结构和接口设计
    • 3) 数据/类设计
    • 4) 部件级（过程）设计
    • 5) 编写设计文档
    • 6) 设计评审
• 软件设计原则
  • 抽象化与逐步求精
    • 抽象，是在软件设计的规模逐渐增大的情况下，控制复杂性的基本策略。
      • 抽象的过程是从特殊到一般的过程，上层概念是下层概念的抽象，下层概念是上层概念的精化和细化。
      • 软件工程过程的每一步都是对较高一级抽象的解作一次具体化的描述
      • 软件设计中主要抽象手段有：过程抽象和数据抽象
        • 过程抽象（也称功能抽象）是指任何一个完成明确定义功能的操作都可被使用者当作单个实体看待，尽管这个操作实际上是由一系列更低级的操作来完成的
        • 数据抽象是指定义数据类型和施加于该类型对象的操作，并限定了对象的取值范围，只能通过这些操作修改和观察数据
    • 逐步求精
      • 逐步求精，把问题的求解过程分解成若干步骤或阶段，每步都比上步更精化，更接近问题的解法
      • 抽象使得设计者能够描述过程和数据而忽略低层的细节，而求精有助于设计者在设计过程中揭示低层的细节
  • 模块化
    • 模块化，即把软件按照规定原则，划分为一个个较小的，相互独立的但又相互关联的部件，实际上是系统分解和抽象的过程
    • 模块是数据说明、可执行语句等程序对象的集合，它是单独命名的，并且可以通过名字来访问
    • 例如，过程。函数、子程序、宏等
  • 信息隐藏
    • 每个模块的实现细节对于其它模块来说应该是隐蔽的
    • 块中所包含的信息（包括数据和过程）不允许其它不需要这些信息的模块使用
    • 通过信息隐蔽，则可定义和实施对模块的过程细节和局部数据结构的存取限制
  • 功能独立
    • 功能独立：功能独立是模块化、抽象、信息隐藏和局部化等概念的直接结果。开发功能专一的且避免与其他模块过多交互的的模块可以实现功能独立。
    • 功能独立的重要性
      • 功能被分隔且接口被简化使得软件更容易开发
      • 由于因修改设计或修改编码引起的副作用被限制，减少了错误扩散，且模块复用成为可能，因而使得软件更易于维护和测试。
    • 功能独立性可以由两项指标来衡量：内聚度与耦合度
      • 内聚（cohesion）是一个模块内部各个元素彼此结合的紧密程度的度量
        • 一般模块的内聚性分为七种类型
          • 1) 巧合内聚（偶然内聚）：将几个模块中没有明确表现出独立功能的相同程序代码段独立出来建立的模块称为巧合内聚模块
          • 2) 逻辑内聚 ：指完成一组逻辑相关任务的模块，调用该模块时，由传送给模块的控制型参数来确定该模块应执行哪一种功能
          • 3) 时间内聚：指一个模块中的所有任务必须在同一时间段内执行。例如初始化模块和终止模块
          • 4) 过程内聚 ：指一个模块完成多个任务，这些任务必须按指定的过程（procedural）执行
          • 5) 通信内聚 ：指一个模块内所有处理元素都集中在某个数据结构的一块区域中
          • 6) 顺序内聚：指一个模块完成多个功能，这些功能又必须顺序执行
          • 7) 功能内聚 ：指一个模块中各个部分都是为完成一项具体功能而协同工作，紧密联系，不可分割的
      • 耦合(coupling)是模块之间的相对独立性（互相连接的紧密程度）的度量
        • 一般模块之间可能的耦合方式有七种类型
          • 1) 内容耦合 ：如果一个模块直接访问另一个模块的内部数据；或者一个模块不通过正常入口转到另一模块内部；或者两个模块有一部分程序代码重迭；或者一个模块有多个入口，则两个模块之间就发生了内容耦合
          • 2) 公共耦合 ：若一组模块都访问同一个公共数据环境，则它们之间的耦合就称为公共耦合。公共的数据环境可以 是全局数据结构、共享的通信区、内存的公共覆盖区等
          • 3) 外部耦合 ：指模块间通过软件之外的环境联结（如I/O将模块耦合到特定的设备、格式、通信协议上）时，称为外部耦合
          • 4) 控制耦合：如果一个模块传送给另一个模块的参数中包含了控制信息，该控制信息用于控制接收模块中的执行逻辑，则称为控制耦合
          • 5) 标记耦合：两个模块之间通过参数表传递一个数据结构的一部分（如某一数据结构的子结构），就是标记耦合
          • 6) 数据耦合：两个模块之间仅通过参数表传递简单数据，则称为数据耦合
          • 7) 非直接耦合 ：如果两个模块之间没有直接关系，即它们中的任何一个都不依赖于另一个而能独立工作，这种耦合称为非直接耦合
      • 模块之间的连接越紧密，联系越多，耦合性就越高，而其功能独立性就越弱
      • 一个模块内部各个元素之间的联系越紧密，则它的内聚性就越高
      • 功能独立性比较强的模块应是高内聚低耦合的模块
• 软件体系结构设计
  • 软件体系结构关注系统的一个或多个结构，包含软件构件、这些构件的对外可见的性质以及它们之间的关系
  • Bass提出体系结构重要的三个关键理由：
    • ①方便利益相关人员的交流
    • ②有利于系统设计的前期决策
    • ③可传递的系统级抽象
  • 体系结构发展过程
    • 常见的软件体系结构
      • 单主机结构k
      • C/S（Client/Server）结构
      • B/S（Browser/Server）结构
  • 软件体系结构的风格
    • 绝大多数可以被归类为相对小数量的体系结构风格之一
    • 每种风格描述一种系统范畴，范畴包括：
      • ①一些实现系统所需的功能的部件（如数据库、计算模块）
      • ②一组用来连接部件“通信、协调和合作”的“连接子”
      • ③定义部件之间怎样整合的系统约束
      • ④使设计者能够理解整个系统属性并分析已知属性的语义模型
  • 数据为中心体系结构
    • 一些数据（比如一个文件或者数据库）保存在整个结构的中心，并且被其他部件频繁地使用、添加、删除、或者修改
  • 数据流风格的体系结构
    • 这种结构适用于输入数据被一系列的计算或者处理部件变换成输出数据
  • 调用和返回风格的体系结构
    • 这种风格使一个软件设计者设计出非常容易修改和扩充的体系结构
    • 包含：主程序/子程序风格体系结构和远程过程调用风格的体系结构
    • 在这里要了解几个概念：
      • 程序结构的深度：程序结构的层次数称为结构的深度。结构的深度在一定意义上反映了程序结构的规模和复杂程度
      • 程序结构的宽度：层次结构中同一层模块的最大模块个数称为结构的宽度
      • 模块的扇入和扇出：扇出表示一个模块直接调用（或控制）的其它模块数目。扇入则定义为调用（或控制）一个给定模块的模块个数。多扇出意味着需要控制和协调许多下属模块。而多扇入的模块通常是公用模块。
  • 面向对象风格的体系结构
    • 系统部件封装数据和操作数据的方法
    • 部件之间的交互和协调通过消息来传递
  • 层次式风格的体系结构
    • 在这种结构中，定义不同的层次，每层都完成了相对外层更靠近机器指令的操作
  • 评估可选的体系结构
    • 对于同一个软件需求，由于各种设计方法的原理不同，会导出不同的软件结构
    • 同一问题的不同软件结构
  • ATAM（architecture trade-off analysis method）
    • 1) 定义应用场景（scenarios）：通过use case图来从用户的角度表现系统
    • 2) 得出需求、约束和环境描述：这是需求工程的一部分，用以确定所有客户方关心的问题都被列出
    • 3) 描述能处理上述情境和需求的体系结构风格
    • 4) 单独地评价系统的各项性能。针对体系结构设计的性能包括：可靠性，性能、安全性，可维护性，灵活性，可测试性，可移植性，可重用性和互操作性等
    • 5) 针对不同的架构形式，评价第4步提到的这些性能的敏感程度。可以通过这样的方法来评价：在整个架构中做一些小的变更，分析并确定上诉性能有没有很敏感的变化。那些在体系结构改动中受到较大影响的性能被称为敏感点（sensitive point）
    • 6) 通过第5步的敏感度分析来评价第三步中提出的那些体系结构。SEI描述的方法如下：当一个架构的敏感点被确定，我们需要找到在系统中最需要权衡利弊的因素（trade-off point）。权衡因素就是指改变架构中的这项内容系统的很多性能就会发生敏感的变化。比如说，一个client-server结构的系统的表现性能和系统中server的数量是息息相关的（比如增加server的数量，一定程度上系统的表现性能就会提高）……这样的话，server的数量就是这个架构中的平衡点。
  • 在进行软件体系结构设计时，可以参考如下规则：
    • (1) 改进软件结构提高模块独立性
    • (2) 模块适当的深度、宽度、扇出和扇入
    • (3) 模块判断作用范围应在其控制作用范围内
    • (4) 力争降低模块接口的复杂度
    • (5) 设计单入口单出口的模块
    • (6) 模块功能应该是可以预测的模块大小适中
    • (7) 一般一个模块包含的语句在30～50条左右较好
    • (8) 一个设计好的软件结构，通常顶层扇出比较高，中层扇出比较少，底层有高扇入
• 部件级设计技术
  • 在结构化分析和设计方法时部件往往被称为模块
  • 在面向对象分析和设计时部件被称为类，在基于构件的开发方法中，部件被称为构件
  • 在部件级设计阶段，主要完成如下工作：
    • 为每个部件确定采用的算法，选择某种适当的工具表达算法的过程，编写部件的详细过程性描述
    • 确定每一部件内部使用的数据结构
    • 在部件级设计结束时，应该把上述结果写入部件级设计说明书，并且通过复审形成正式文档，作为下一阶段（编码阶段）的工作依据
  • 结构化程序设计方法
    • 一种较为流行的定义是：“如果一个程序的代码块仅仅通过顺序、选择和循环这三种基本控制结构进行连结，并且每个代码块只有一个入口和一个出口，则称这个程序是结构化的”
    • 随着面向对象和软件复用等新的软件开发方法和技术的发展，更现实、更有效的开发途径可能是自顶向下和自底向上两种方法有机的结合
  • 图形表示法
    • 程序流程图
      • 程序流程图独立于任何一种程序设计语言，比较直观、清晰、易于学习掌握
      • 为使用流程图描述结构化程序，必须限制流程图只能使用五种基本控制结构
    • N-S图
      • Nassi和Shneiderman 提出了一种符合结构化程序设计原则的图形描述工具，叫做盒图，也叫做N-S图
      • 五种基本控制结构
    • PAD
      • PAD是Problem Analysis Diagram的缩写 ，由程序流程图演化而来
      • 五种基本控制结构
  • 判定表
    • 当算法中包含多重嵌套的条件选择时，用程序流程图、N-S图或PAD都不易清楚地描述
    • 然而，判定表却能清晰地表达复杂的条件组合与应做动作之间的对应关系
    • 判定表的优点是能够简洁，无二义性地描述所有的处理规则
    • 但判定表表示的是静态逻辑，是在某种条件取值组合情况下可能的结果，它不能表达加工的顺序，也不能表达循环结构
  • 设计性语言PDL
    • PDL（Program Design Language）是一种用于描述功能部件的算法设计和处理细节的语言，称为设计性语言
    • 它是一种伪码。一般地，伪码的语法规则分为“外语法”和“内语法”
      • 外语法应当符合一般程序设计语言常用语句的语法规则
      • 内语法可以用英语中一些简单的句子、短语和通用的数学符号，来描述程序应执行的功能
    • PDL的使用实例
    • PDL特点
      • 1. 有固定的关键字外语法，提供全部结构化控制结构、数据说明和部件特征。属于外语法的关键字是有限的词汇集，它们能对PDL正文进行结构分割，使之变得易于理解。为了区别关键字，规定关键字一律大写，其它单词一律小写。
      • 2. 内语法使用自然语言来描述处理特性。内语法比较灵活，只要写清楚就可以，不必考虑语法错，以利于人们可把主要精力放在描述算法的逻辑上。
      • 3. 有数据说明机制，包括简单的（如标量和数组）与复杂的（如链表和层次结构）的数据结构。
      • 4. 有子程序定义与调用机制，用以表达各种方式的接口说明。
• 设计规约与设计评审
  • 设计规约
  • 设计评审
    • 软件设计的最终目标是要取得最佳方案
    • “最佳”是指在所有候选方案中，就节省开发费用，降低资源消耗，缩短开发时间的条件，选择能够赢得较高的生产率、较高的可靠性和可维护性的方案
    • 设计评审的内容
      • 可追溯性：即分析该软件的系统结构、子系统结构，确认该软件设计是否覆盖了所有已确定的软件需求，软件每一成分是否可追溯到某一项需求。
      • 接口：即分析软件各部分之间的联系，确认该软件的内部接口与外部接口是否已经明确定义。部件是否满足高内聚和低耦合的要求。部件作用范围是否在其控制范围之内。
      • 风险：即确认该软件设计在现有技术条件下和预算范围内是否能按时实现
      • 实用性：即确认该软件设计对于需求的解决方案是否实用
      • 技术清晰度：即确认该软件设计是否以一种易于翻译成代码的形式表达
      • 可维护性：从软件维护的角度出发，确认该软件设计是否考虑了方便未来的维护
      • 质量：即确认该软件设计是否表现出良好的质量特征
      • 各种选择方案：看是否考虑过其它方案，比较各种选择方案的标准是什么
      • 限制：评估对该软件的限制是否现实，是否与需求一致
      • 其它具体问题：对于文档、可测试性、设计过程等等进行评估
    • 评审分正式评审和非正式评审两种
      • 正式评审除软件开发人员外，还邀请用户代表和领域专家参加，通常采用答辩形式
      • 非正式评审多少有些同行切磋的性质，不拘泥于时间和形式