【文档说明】软件工程03-1(设计工程).pptx，共(62)页，331.380 KB，由精品优选上传

转载请保留链接：https://www.ichengzhen.cn/view-290956.html

以下为本文档部分文字说明：

软件工程第5章设计工程1复旦大学计算机科学与工程系软件工程课程内容摘要◼软件设计工程概述◼软件设计过程◼软件体系结构设计◼部件级设计技术（自学）◼设计规约与设计评审（自学）2内容摘要◼软件设计工程概述◼软件设计原则◼软件体系结构设计◼部件级设计技术◼设计规约与

设计评审3软件设计工程概述◼软件需求分析解决“做什么”的问题，软件设计过程则解决“怎么做”的问题◼软件设计是把软件需求变换成软件表示的过程，它主要包含两个阶段：软件体系结构设计阶段和部件级设计4软件设计的任务◼使用一种

设计方法，软件分析模型中通过数据、功能和行为模型所展示的软件需求的信息被传送给设计阶段，产生数据/类设计、体系结构设计、接口设计、部件级设计5接口设计◼接口设计主要包括三个方面：◆设计软件模块间的接口◆设计模块和其他非人的信息生产者和消费者(比如外

部实体)之间的接口◆设计人(用户)和计算机间的接口6部件级设计◼部件级设计将软件体系结构的结构性元素变换为对软件部件的过程性描述。◼从类为基础的模型、流模型、行为模型中得到的信息是部件设计的基础。7衡量设计的技术标准1)设计出来的结构应是分层结构，从而建立软件成份之间的控制。2)设计应当模

块化，从逻辑上将软件划分为完成特定功能或子功能的部件。3)设计应当既包含数据抽象，也包含过程抽象。4)设计应当建立具有独立功能特征的模块。5)设计应当建立能够降低模块与外部环境之间复杂连接的接口。6)设计应能根据软件需求分析获取的信息，建立可驱动、可重复的方法

。8总体设计◼总体设计的基本目的就是回答“概括地说，系统应该如何实现?”。因此，总体设计又称为概要设计或初步设计。◼通过这个阶段的工作将划分出组成系统的物理元素——程序、文件、数据库、人工过程和文档等等，但是每个物理元素仍然处于黑

盒子级。◼总体设计阶段的另一项重要任务是设计软件的结构，也就是要确定系统中每个程序是由哪些模块组成的，以及这些模块相互间的关系。9总体设计的必要性◼可以站在全局高度上，花较少成本，从较抽象的层次上分析对比多种

可能的系统实现方案和软件结构，从中选出最佳方案和最合理的软件结构，从而用较低成本开发出较高质量的软件系统。10总体设计过程(共9个步骤)总体设计过程通常由两个主要阶段组成：A.系统设计阶段，确定系统的具体实现方案；B.结构设计阶段，确

定软件结构(模块组成的层次系统)。11总体设计过程(共9个步骤)典型的总体设计过程包括下述9个步骤：1.设想供选择的方案在总体设计阶段分析员应该考虑各种可能的实现方案，并且力求从中选出最佳方案。在总体设计阶段开始时只有系统的逻辑模型

，分析员有充分的自由分析比较不同的物理实现方案。一种常用的方法：设想把数据流图中的处理分组的各种可能的方法。抛弃在技术上行不通的方法。12总体设计过程(共9个步骤)2.选取合理的方案通常至少选取低成本、中等成本和高成本的三种方案。在判断哪些方案合理时应该考虑在问

题定义和可行性研究阶段确定的工程规模和目标，有时可能还需要进一步征求用户的意见。对每个合理的方案分析员都应该准备下列4份资料：(1)系统流程图；(2)组成系统的物理元素清单；(3)成本/效益分析；(4)实现这个系统的进度计划。13总

体设计过程(共9个步骤)3.推荐最佳方案分析员应该综合分析对比各种合理方案的利弊，推荐一个最佳的方案，并且为推荐的方案制定详细的实现计划。1.用户和有关的技术专家应该认真审查分析员所推荐的最佳系统，如果该系统确实符合用户的需要，并且是在现有条件下完全能够实现的，则2.应该提请使用

部门负责人进一步审批。在使用部门的负责人也接受了分析员所推荐的方案之后，将进入总体设计过程的下一个重要阶段——结构设计。14总体设计过程(共9个步骤)4.功能分解为了最终实现目标系统，必须设计出组成这个

系统的所有程序和文件(或数据库)。对程序(特别是复杂的大型程序)的设计，通常分为两个阶段完成：首先进行结构设计，然后进行过程设计。1.结构设计确定程序由哪些模块组成，以及这些模块之间的关系，属于总体设计阶段的任务；2.过程设计确定每个模

块的处理过程。结构设计是总体设计阶段的任务，过程设计是详细设计阶段的任务。15总体设计过程(共9个步骤)5.设计软件结构◼通常程序中的一个模块完成一个适当的子功能。应该把模块组织成良好的层次系统，顶层模块调用它的下层模块以实现程序的完整功能，每个下层模块再调用更下层

的模块，从而完成程序的一个子功能，最下层的模块完成最具体的功能。软件结构(即由模块组成的层次系统)可以用层次图或结构图来描绘。16总体设计过程(共9个步骤)6.设计数据库对于需要使用数据库的那些应用系统，软件工程师应该在需求分析阶段所确定的系统数据需求的基础上，进一

步设计数据库。7.制定测试计划在软件开发的早期阶段考虑测试问题，能促使软件设计人员在设计时注意提高软件的可测试性。17总体设计过程(共9个步骤)8.书写文档应该用正式的文档记录总体设计的结果，在这个阶段应

该完成的文档通常有下述几种：(1)系统说明:主要内容包括用系统流程图描绘的系统构成方案，组成系统的物理元素清单，成本/效益分析；对最佳方案的概括描述，精化的数据流图，用层次图或结构图描绘的软件结构，用IPO图或其他工具(例如，PDL语言)简要

描述的各个模块的算法，模块间的接口关系等等。(2)用户手册:根据总体设计阶段的结果，修改更正在需求分析阶段产生的初步的用户手册。(3)测试计划:包括测试策略，测试方案，预期的测试结果，测试进度计划等等。(4)详细的实现计划(5)数据库设计结果18总体设计过程(

共9个步骤)9.审查和复审最后应该对总体设计的结果进行严格的技术审查，在技术审查通过之后再由使用部门的负责人从管理角度进行复审。19内容摘要◼软件设计工程概述◼软件设计原理◼软件体系结构设计◼部件级设计技术◼设计规约与设计评审20抽象化与逐步求精◼抽象，是在软件设

计的规模逐渐增大的情况下，控制复杂性的基本策略。◼抽象的过程是从特殊到一般的过程，上层概念是下层概念的抽象，下层概念是上层概念的精化和细化。◼软件工程过程的每一步都是对较高一级抽象的解作一次具体化的描述21逐步求精◼逐

步求精，把问题的求解过程分解成若干步骤或阶段，每步都比上步更精化，更接近问题的解法(“为了能集中解决主要问题而尽量推迟对问题细节的考虑”)。◼抽象使得设计者能够描述过程和数据而忽略低层的细节，而求精有助于设计者在设计过程中揭示低层的

细节；二者的目的不同22模块化◼模块化，即把软件按照规定原则，划分为一个个较小的，相互独立的但又相互关联的部件，实际上是系统分解和抽象的过程。◼模块是数据说明、可执行语句等程序对象的集合，它是单独命名的，并且可以通过名字来访问。◆例如，过程。函数、子程

序、宏等◆面向对象方法学中的对象、对象内的方法（服务）也是模块。模块是构成程序的基本构件。23◼设C(x)是描述问题x复杂性的函数，E(x)是解决问题x所需工作量(按时间计算)的函数。对于两个问题p1

和p2，如果：C(p1)＞C(p2)(5.1a)那么E(p1)＞E(p2)(5.1b)◼即：问题越复杂，解决问题所需要的花费更多。24◼通过对人解决问题的实验，又存在另一个有趣的规律：C(p1＋p2)＞C(p1)＋C(p2)(5.2)◼方程式(5.2)意味着p1和p2组合后的复杂性比单独

考虑每个问题时的复杂性要大。考虑方程式(5.2)和方程式(5.1)隐含的条件，我们可以得出：E(p1＋p2)>E(p1)＋E(p2)(5.3)◼不等式(5.3)表达出了一个对于模块化和软件具有十分重要意义的结论（即，模块化的论据）：将复杂问题

分解成可以管理的片断会更使解决问题更加容易。25◼问题：如果我们无限制地划分软件，开发它所需的工作量会变得小到可以忽略？◼事实上，影响软件开发的工作量的因素还有很多，例如模块接口费用等等。◼上述不等式只能说明，当模块的总数增加时，单独开发各个子模块的工作量之和会有所减少。26◼如果模块是相互独立的

，当模块变得越小，每个模块花费的工作量越低；◼但当模块数增加时，模块间的联系也随之增加，把这些模块联接起来的工作量也随之增加(设计模块间接口所需工作量增加)。27信息隐藏◼信息隐藏：每个模块的实现细节对于其它模块来说应该是隐蔽的；◼块中所包含的信息（包括数据

和过程）不允许其它不需要这些信息的模块使用；◼通过信息隐蔽，则可定义和实施对模块的过程细节和局部数据结构的存取限制。28模块独立◼模块独立：模块完成独立的功能并且与其他模块的接口简单，符合信息隐蔽和信息局部化原则，模块间关联和依赖程度尽可能小。◼模块独立

的重要性◆功能被划分，并且接口被简化，所以具有有效模块化的软件更易于开发。◆由于因设计和编码修改引起的副作用受到局限，错误传播被减小，并且模块复用成为可能，所以独立的模块更易于维护和测试。29模块独立◼模块的独立性可以由两项指标来衡量：内聚度

与耦合度：◆内聚（cohesion）是一个模块内部各个元素彼此结合的紧密程度的度量。◆耦合(coupling)是模块之间的相对独立性（互相连接的紧密程度）的度量。30内聚◼一般模块的内聚性分为七种类型31内聚1)巧合内

聚（偶然内聚）：如果一个模块完成一组任务，这些任务彼此间即使有关系，关系也是很松散的。将几个模块中没有明确表现出独立功能的相同程序代码段独立出来建立的模块称为巧合内聚模块。2)逻辑内聚：指完成一组逻辑相关任务的模块，调用该模块时，由传送给模

块的控制型参数来确定该模块应执行哪一种功能。3)时间内聚：指一个模块中的所有任务必须在同一时间段内执行。例如初始化模块和终止模块。32内聚4)过程内聚：指一个模块完成多个任务，这些任务必须按指定的过程（procedural）执行。5)通信内聚：指一个模块内所有处理元素都集中在

某个数据结构的一块区域中。6)顺序内聚：指一个模块完成多个功能，这些功能又必须顺序执行。7)功能内聚：指一个模块中各个部分都是为完成一项具体功能而协同工作，紧密联系，不可分割的。33◼耦合和内聚的概念是Constantine,Yourdon,Myers和Stevens等人提出来的。按

照他们的观点，如果给上述几种内聚的优劣评分，将得到如下结果：功能内聚10分时间内聚3分顺序内聚9分逻辑内聚1分通信内聚7分偶然内聚0分过程内聚5分事实上，没有必要精确确定内聚的级别。重要的是设计时力争做到高内聚，并且能够辨认出低内聚的模块，有能力通过

修改设计提高模块的内聚程度降低模块间的耦合程度，从而获得较高的模块独立性。34耦合◼一般模块之间可能的耦合方式有七种类型35耦合1)内容耦合：如果一个模块直接访问另一个模块的内部数据；或者一个模块不通过正常入口转到另一模块

内部；或者两个模块有一部分程序代码重迭；或者一个模块有多个入口，则两个模块之间就发生了内容耦合。2)公共耦合：若一组模块都访问同一个公共数据环境，则它们之间的耦合就称为公共耦合。公共的数据环境可以是全局数据结构、共享的

通信区、内存的公共覆盖区等。3)外部耦合：指模块间通过软件之外的环境联结（如I/O将模块耦合到特定的设备、格式、通信协议上）时，称为外部耦合。36耦合4)控制耦合：如果一个模块传送给另一个模块的参数中包含了控制信息，该控制信息用于控制接收模块中的执行逻辑，则称为控制耦合。5)标记耦合：

两个模块之间通过参数表传递一个数据结构的一部分（如某一数据结构的子结构），就是标记耦合。6)数据耦合：两个模块之间仅通过参数表传递简单数据，则称为数据耦合。7)非直接耦合：如果两个模块之间没有直接关系，即它们中的任何一个都不

依赖于另一个而能独立工作，这种耦合称为非直接耦合。37◼模块之间的连接越紧密，联系越多，耦合性就越高，而其模块独立性就越弱。◼一个模块内部各个元素之间的联系越紧密，则它的内聚性就越高。◼模块独立性比较强的模块应是高内聚低耦合的模块。385.3启发规则◼人们在开发计算机软

件的长期实践中积累了丰富的经验，总结这些经验得出了一些启发式规则。◼这些启发式规则在许多场合仍然能给软件工程师以有益的启示，往往能帮助他们找到改进软件设计提高软件质量的途径。395.3启发规则1.改进软件结构提高模块独立性设计出软件的初

步结构以后，应该审查分析这个结构，通过模块分解或合并，力求降低耦合提高内聚。例如：多个模块公有的一个子功能可以独立成一个模块，由这些模块调用；有时可以通过分解或合并模块以减少控制信息的传递及对全程数据的引用，并且降低接口的复杂程度。405.3启发规则2.模块规模应该适中经验表明，一个

模块的规模不应过大。有人从心理学角度研究得知，当一个模块包含的语句数超过30以后，模块的可理解程度迅速下降。过大的模块往往是由于分解不充分，但是进一步分解必须符合问题结构，一般说来，分解后不应该降低模块独立性。过小的模块开销大于有效操作，而且模块数目过多将使系统接口复杂。415.3启发规则

3.深度、宽度、扇出和扇入都应适当（1/2）深度表示软件结构中控制的层数，它往往能粗略地标志一个系统的大小和复杂程度。如果层数过多则应该考虑是否有许多管理模块过分简单了，能否适当合并。宽度是软件结构内同

一个层次上的模块总数的最大值。一般说来，宽度越大系统越复杂。对宽度影响最大的因素是模块的扇出。425.3启发规则3.深度、宽度、扇出和扇入都应适当（2/2）扇出是一个模块直接控制(调用)的模块数目，扇出过大意味着模块过分复

杂，需要控制和协调过多的下级模块；扇出过小(例如总是1)也不好。经验表明，一个设计得好的典型系统的平均扇出通常是3或4(扇出的上限通常是5～9)。扇出太大一般是因为缺乏中间层次，应该适当增加中间层次的控制模块。扇出太小时可以把下级模块进

一步分解成若干个子功能模块，或者合并到它的上级模块中去。当然分解模块或合并模块必须符合问题结构，不能违背模块独立原理。一个模块的扇入表明有多少个上级模块直接调用它，扇入越大则共享该模块的上级模块数目越多，这是有好处的，但是，不能违背模块独立原理单纯追求

高扇入。观察大量软件系统后发现，设计得很好的软件结构通常顶层扇出比较高，中层扇出较少，底层扇入到公共的实用模块中去(底层模块有高扇入)。435.3启发规则4.模块的作用域应该在控制域之内模块的作用域定义为受该模块内一个判定影响的所有模块

的集合。模块的控制域是这个模块本身以及所有直接或间接从属于它的模块的集合。在一个设计得很好的系统中，所有受判定影响的模块应该都从属于做出判定的那个模块，最好局限于做出判定的那个模块本身及它的直属下级模块。445.3启发规则5.力争降低模块

接口的复杂程度模块接口复杂是软件发生错误的一个主要原因。应该仔细设计模块接口，使得信息传递简单并且和模块的功能一致。6.设计单入口单出口的模块这条启发式规则警告软件工程师不要使模块间出现内容耦合。当从顶部进入模块并且从底部退出来时，软件是比较容易理解的，因此也是比较容易

维护的。455.3启发规则7.模块功能应该可以预测模块的功能应该能够预测，但也要防止模块功能过分局限。如果一个模块可以当做一个黑盒子，也就是说，只要输入的数据相同就产生同样的输出，这个模块的功能就是可以预测的。46内容摘要◼软件设计工程概述◼软件设计原则◼软件体系结构设计◼部件级设计技术◼设计

规约与设计评审47体系结构发展过程◼常见的软件体系结构◆单主机结构◆C/S（Client/Server）结构◆B/S（Browser/Server）结构48面向对象风格的体系结构◼系统部件封装数据和操作数据的方法。◼部件之间的交互和协调通过消

息来传递。49层次式风格的体系结构◼在这种结构中，定义不同的层次，每层都完成了相对外层更靠近机器指令的操作50评估可选的体系结构◼对于同一个软件需求，由于各种设计方法的原理不同，会导出不同的软件结构。◼同一

问题的不同软件结构：s1s4s3s2s1s4s3s2s1s4s3s251◼在进行软件体系结构设计时，可以参考如下规则：(1)改进软件结构提高模块独立性(2)模块适当的深度、宽度、扇出和扇入(3)模块判断作用范围应在其控制作用范围内(4)力争降低

模块接口的复杂度(5)设计单入口单出口的模块(6)模块功能应该是可以预测的模块大小适中(7)一般一个模块包含的语句在30～50条左右较好。(8)一个设计好的软件结构，通常顶层扇出比较高，中层扇出比较少，底层有高扇入。52内容摘要◼软件设计工程概述◼软件设计原则◼软件体系结

构设计◼部件级设计技术◼设计规约与设计评审53部件级设计技术◼在结构化分析和设计方法时部件往往被称为模块◼在面向对象分析和设计时部件被称为类，在基于构件的开发方法中，部件被称为构件。54部件级设计技术在部件级设计阶段，主要完成如下工作：(1)为每个部件确定采用的算法，选择某种适当的工具表达算法的过

程，编写部件的详细过程性描述；(2)确定每一部件内部使用的数据结构；(3)在部件级设计结束时，应该把上述结果写入部件级设计说明书，并且通过复审形成正式文档，作为下一阶段（编码阶段）的工作依据。55内容摘要◼软件设计工程概述◼软

件设计原则◼软件体系结构设计◼部件级设计技术◼设计规约与设计评审56设计规约Ⅰ.工作范围A.系统目标B.运行环境C.主要软件需求D.设计约束∕限制Ⅱ.体系结构设计A.数据流与控制流复审B.导出的程序结构C.功能与程序交叉索引Ⅲ.数据设计A.数据对象与形成的

数据结构B.文件和数据库结构ⅰ文件的逻辑结构ⅱ文件逻辑记录描述ⅲ访问方式C.全局数据D.文件∕数据与程序交叉索引Ⅳ.接口设计A.人机界面规格说明B.人机界面设计规则C.外部接口设计ⅰ外部数据接口ⅱ外部系统或设备接口D.内部接口设计规则57Ⅴ.各部件的过程设计

A.处理与算法描述B.接口描述C.设计语言(或其它)描述D.使用的部件E.内部程序逻辑描述F.注释∕约束∕限制Ⅵ.运行设计A.运行部件组合B.运行控制规则C.运行时间安排Ⅶ.出错处理设计A.出错处理信息B

.出错处理对策ⅰ设置后备ⅱ性能降级ⅲ恢复和再启动Ⅷ.安全保密设计Ⅸ.需求∕设计交叉索引Ⅹ.测试部分A.测试方针B.集成策略C.特殊考虑Ⅺ.特殊注解Ⅻ.附录58设计评审◼软件设计的最终目标是要取得最佳方案◼“最佳”是指在所有候选方案中，

就节省开发费用，降低资源消耗，缩短开发时间的条件，选择能够赢得较高的生产率、较高的可靠性和可维护性的方案59设计评审的内容1.可追溯性：即分析该软件的系统结构、子系统结构，确认该软件设计是否覆盖了所有已确定的软件需求，软件每一成分是否可追溯到某一项需求。2．接口：即分析软件各部分之间的联系，确认

该软件的内部接口与外部接口是否已经明确定义。部件是否满足高内聚和低耦合的要求。部件作用范围是否在其控制范围之内。3．风险：即确认该软件设计在现有技术条件下和预算范围内是否能按时实现。4．实用性：即确认该软件设计对于需求的解决方案是否实用。60

设计评审的内容（续）5．技术清晰度：即确认该软件设计是否以一种易于翻译成代码的形式表达。6．可维护性：从软件维护的角度出发，确认该软件设计是否考虑了方便未来的维护。7．质量：即确认该软件设计是否表现出良好的质量特征。8．各种选择方案：看是否考虑过其它方案，比较各种选择方案的

标准是什么。9．限制：评估对该软件的限制是否现实，是否与需求一致。10．其它具体问题：对于文档、可测试性、设计过程等等进行评估。61设计评审◼评审分正式评审和非正式评审两种◆1.正式评审除软件开发人员外，还邀请用户代表和领域专家参加，通常采用答辩形式◆2

.非正式评审多少有些同行切磋的性质，不拘泥于时间和形式62