《软件工程》课件-第4章 总体设计

第4章

总体设计XX大学XX系XXX软件工程教程电子科技大学出版社学习目标l

了解总体设计的目标、任务和设计过程；l

理解总体设计的原理和结构设计准则；l

掌握面向数据流的软件结构设计方法和描绘软件结构的图形工具；l

能够运用相关方法和工具进行简单的软件结构设计。目录010203总体设计的目标和任务总体设计的过程总体设计的原理04050607软件结构设计准则描绘软件结构的图形工具面向数据流的软件结构设计方法本章小结总体设计的目标和任务01总体设计的目标和任务按照软件生存周期模型的结构，总体设计（也称概要设计）是在需求分析取得正式结果的基础上开展的软件开发工作，是软件开发时期的第一阶段工作，对开发时期的其他后续工作具有统筹的作用。总体设计的目标和任务总体设计的基本目的是回答“概括地说，系统应该如何实现”这个问题，目标是得到良好的软件总体结构，即独立性良好、规模适中的一组模块以及深度、宽度、扇入、扇出合适的系统结构。良好的总体结构将给后续阶段的工作带来诸多便利，也是保障软件质量、降低开发成本、提高软件可维护性的先决条件。什么是良好的软件结构？如何设计良好的软件结构？可以使用哪些工具？将是本章主要介绍的内容。总体设计的目标和任务从工程管理的角度，软件设计可以划分为两个阶段：总体设计阶段和详细设计阶段。总体设计的目标是把需求分析得到的结构化分析模型映射成结构化设计模型。前者反映的是问题域的既定事实，后者反映的是带有设计者意图的或意志的预期事实。结构化分析与结构化设计的关系如图4.1所示。总体设计的图4.1分析模型到设计模型的映射总体设计的目标和任务需要明白的是，分析模型不是设计的结果，分析模型要如实反映问题域的真实情况；设计模型要以分析模型为基础，用计算机所理解的虚拟世界的方式对问题域中待解决的问题进行重新的结构构建，并反映设计这的意志，设计模型绝不能违反分析模型中的事实和现实世界的常识，否则，就不可能得到符合预期的产品。总体设计的目标和任务总体设计的主要任务是把分析阶段得到的数据模型映射成数据库设计，把数据流图映射成软件功能结构，行为模型可以用于详细设计阶段的流程、算法设计。软件功能结构反映了软件的功能组成，以及各功能模块间的逻辑关系（含接口关系）。总体设计的过程02总体设计的过程总体设计过程通常由两个主要阶段组成：系统设计阶段，确定系统的的具体实现方案；”结构设计阶段，确定软件的结构。典型的总体设计过程包括以下九个步骤。总体设计的过程（1）设想供选择的方案在总体设计阶段，系统分析员首先应该考虑各种可能的实现方案，并力求选出最佳方案。设”想方案的出发点是数据流图，常用的做法是，设想把数据流图中的处理进行分组的各种可能的方法，抛弃在技术上行不通、不合理的分组方法，余下的分组方法代表可能的实现策略。总体设计的过程（2）选取合理的方案从前一步的到的不同方案中选取若干个合理的方案，通常要包括低成本、中等成本和高成本的”三种方案。在判断方案的合理性时，可依据可行性研究阶段确定的项目规模，有时可能还需要进一步征求用户的意见。总体设计的过程（3）推荐最佳方案系统分析员应综合分析对比各种合理方案的利弊，推荐一个最佳方案，并为此方案制定详细的实现计划。用户”和有关技术专家应认真审查分析员推荐的最佳方案，如果确实符合用户需求，且在现有技术条件下能够完全实现，则提请使用部门负责人进行审批。在审批通过后，方可进入总体设计的下一个重要阶段——结构设计。总体设计的过程（4）功能分级结构设计的任务是确定目标系统由哪些模块组成，以及这些模块之间的逻辑关系。结构设计之”后的过程设计属于详细设计阶段的任务，用于确定每个模块的处理过程。总体设计的过程为了确定软件的结构，首先应该从实现的角度把复杂的功能进一步分解。具体做法是，仔细分析数据流图中的每个处理，如果一个处理的功能”过分复杂，则把它适当的分解成一系列比较简单的功能，整个分解过程实质上是对数据流图的进一步细化。在分解的过程中，还应该用IPO表简要地描述每个处理的算法。总体设计的过程（5）设计软件结构设计软件结构就是要把软件的模块组织成良好的层次系统。在这个层次系统中，每一层模块都调用它”下一层的模块，每个下层模块再调用更下层的模块，最下层的模块完成最具体的功能，从而实现程序的某个子功能，所有的子功能共同完成系统的完整功能。描述软件结构可以使用层次图或结构图。总体设计的过程如果数据流图已经细化到适当的层次（如果再分解就涉及到过程设计的问题），则可以”直接从数据流图映射出软件结构。总体设计的过程（6）数据库设计对于需要使用数据库的应用领域，还要进”行数据库设计。数据库的设计包括模式设计子模式设计、完整性设计和安全性设计、优化处理等。总体设计的过程（7）制定测试计划虽然是在设计阶段，但是提早考虑测试问题，能促使设计人员在设计时注意提高软件的”可测试性。在总体设计阶段仅是利用黑盒测试法制定功能测试计划与测试策略。在详细设计时才编写详细的测试用例和测试计划。总体设计的过程（8）编写文档应该用正式的文档记录总体设计的结果，文档通常包括以下五种。①

系统说明。主要内容包括系统流程图描绘的系统构成”方案，组成系统的物理元素清单，成本/效益分析，对最佳方案的概括性描述，精华的数据流图，用层次图或结构图描绘的软件结构，用IPO表或PDL语言简要描述的各个模块的算法，模块间的结构关系，以及需求、功能和模块三者之间的交叉参照关系等。总体设计的过程②

用户手册。根据总体设计的结果，修改更正在需求分析阶段产生的初步的用户手册。③

测试计划。包括测试策略、测试方案、预期结”果、测试计划等。④

详细的实现计划。包括实现的各阶段所需要的时间、资源、人员配置等。⑤

数据库设计的结果。总体设计的过程（9）审查和复查最后，应该对总体设计的结果进行严格的”技术审查，在通过之后，再由使用部门负责人从管理的角度进行复审。总体设计的典型整体过程如图4.2所示。图4.2典型总体设计过程总体设计的原理03模块和模块化模块并非是计算机专有术语，在计算机领域也没有统一的严格定义，但是几乎所有的软件体系结构都是以模块为最小单位构建的。模块也成构件，是指可单独命名且可通过名字访问的过程函数、子程序或宏调用。在具体计算机语言中，模块是由边界元素（比如Java中的｛…｝）限定的相邻程序元素的序列，且有一个总体标识符代表它。面向对象方法学中的对象、对象中的方法，都是模块。模块和模块化模块一般具有如下四个基本属性。（1）接口：指模块的输入与输出。（2）功能：指模块实现的处理。（3）逻辑：描述模块内部的处理过程。（4）状态：指模块使用时的环境和条件。模块化就是把程序划分成独立命名且可独立访问的模块，每个模块完成一个子功能，所有模块按用户业务逻辑集成起来构成一个整体，完成指定的功能满足用户需求。模块和模块化模块化的目的是为了降低软件的复杂性。对软件进行适当的分解，可以减少开发难度，降低开发成本，提高考法效率。模块化的论据如下：如果C(x)表示问题x的复杂程度，函数E(x)表示解决问题x所需要的工作量函数。对于p1、p2两个问题，如果C(p1)>C(p2)，

则有：E(p1)>E(p2)（公式4.1）模块和模块化由于p1和p2两个问题合成一个问题时的复杂程度大于分别考虑每个问题时的复杂程度之和，即C(p1+p2)>C(p1)+C(p2)。这种假设看起来似乎有些武断，但大多数情况下的确如此。所以，可以得到：E(p1+p2)>E(p1)+E(p2)

（公式4.2）模块和模块化但是如果按照这个论断，无限制地分割软件就可以无限地降低成本。现实中显然并非如此，因为还有另一个因素起作用，使得上述论断不能成立。当无限地分割软件时，虽然每个模块的规模在减小，开发成本在降低，但同时系统的总模块数会上升，模块间的接口设计所需要的成本会显著提升。如图4.3所示。最小成本区成本或工作量总成本集成成本M成本/模块模块数量图4.3模块化和软件成本关系图模块和模块化由图4-3可知，存在一个模块数M，使得软件总成本最低。可见在总体设计中，只有选择合适的模块数据，才会使得整个系统的开发成本较小，但在目前还无法准确预测这个M的数值。模块和模块化采用模块化原理可以使软件结构清晰，降低设计难度，提高可理解性。由于程序的错误大多发生在模块及它们之间的接口中，所以模块化设计会使软件容易测试和调试，进而有助于提高软件的可靠性。当变动仅涉及少数几个模块时，模块化还能够提高可修改性。另外，模块化也有助于软件开发的组织管理，一个复杂的大型程序可以通过模块化分解成许多程序，按照实现的难易度分配给技术熟练水平不同的程序员。抽象抽象是人类认识复杂现象时使用的最有力的思维工具。人们在和现实世界的互动中认识到，现实世界中的事务、状态或过程之间总存在着某些共性。把这些共性归纳和概括起来，暂时忽略它们之间的差异，这就是抽象。抽象就是抽出事物的本质特性而暂时不考虑它们的细节。抽象当考虑任何问题的模块化解法时，可以提出许多抽象的层次。在抽象的最高层次使用问题环境的语言，以概括的方式叙述问题的解法。在较低层次上使用更过程化的方法，把面向问题的术语和面向实现的术语结合起来描述问题的解法。最后，在最低的抽象层次则以直接实现的方式叙述问题的解法。抽象软件工程中的每个步骤都是对软件解决方案抽象化程度的一次细化。在可行性研究阶段，软件作为系统的一个完整部件；在需求分析阶段，软件解法是使用在问题环境内熟悉的方式进行的描述；当有总体设计向详细设计过渡时，抽象的程度也随之减少了；最后，当源程序写出来后，也就达到了抽象的最底层。逐步求精逐步求精最初是由NiklausWirth提出的一种自顶向下的设计策略。按照这个策略，程序的体系结构是通过逐步精化处理过程的层次而设计出来的。通过逐步分解对功能的宏观陈述而开发出层次结构，最终得出用程序设计语言表达的程序。逐步求精抽象与求精是一对互补的概念。抽象使得设计者能够说明结构和数据，但却同时忽略了底层的细节。事实上，可以把抽象看作是一种通过忽略多余的细节同时强调有关的细节，而实现逐步求精的方法。求精则帮助设计者在设计过程中逐步解释底层细节。这两个概念都有助于设计者在设计演化过程中创造出完整的设计模型。信息隐藏与局部化应用模块化原理时，必然会产生一个问题：如何分解一个软件才能得到最佳的模块组合？1972年，D．Parnas提出的信息隐藏原理指出：每一个模块的实现细节（过程和数据）对于不需要这些信息的其他模块来说应该是隐藏的。信息隐藏与局部化局部化的概念和信息隐藏概念是密切相关的。所谓局部化是指把一些关系密切的软件元素物理地放得彼此靠近。局部化实质上是一种实现信息隐藏的手段，信息隐藏是局部化的结果。信息隐藏与局部化信息隐藏意味着有效的模块化可以通过定义一组独立的模块来实现，这些模块相互间的通信仅使用对于实现软件功能来说是必要的信息。信息隐藏的原理不仅使得模块可以进行并行开发，还可以减少测试和后期维护的工作量。因为测试和维护阶段不可避免地要修改设计和代码，模块对于多数数据和处理过程细节的隐藏可以减少错误向外传播。此外，整个系统欲扩充功能也只需“插入”新模块，原有的多数模块无需改动。模块独立模块的独立性是指软件系统中每个模块只涉及软件要求的具体子功能，而和软件系统中其他的模块的接口是简单的。显然，模块化、抽象、信息隐藏和局部化的直接结果是模块独立。模块独立程度可以由两个定性标准度量：耦合和内聚。耦合衡量不同模块彼此间的相互依赖程度；内聚衡量一个模块内部各元素间彼此结合的紧密程度。显然，模块的耦合性越低，其独立性越强，内聚性越高，其独立性越强。模块独立（1）耦合耦合是对一个软件结构内不同模块间相互关联程度的度量。耦合强弱取决于模块间接口的复杂程度，一般由模块之间的调用方式、传递信息的类型和数量来决定。模块独立软件设计，应该追求尽可能松散耦合的结构。这样的程序容易测试、修改和维护，当某一模块中出现错误时，传播到整个系统的可能性也小。模块间的耦合性强烈影响着系统的可理解性、可测试性、可靠性和可维护性。模块间的耦合方式有六种，如图4.4所示。低高耦合性低耦合中等强度耦合

较强耦合强耦合非直接耦合

数据耦合特征耦合

控制耦合

公共环境耦合

内容耦合模块独立性强弱图4.4耦合性的6种类型模块独立①

非直接耦合。如果两个模块分别从属于不同的上级模块的控制与调用，它们之间不直接传递任何信息，互相独立，则称这两个模块为非直接耦合关系。需要注意的是，在一个软件系统中，所有模块之间不可能没有任何间接的练习，否则，它们无法构成一个系统。模块独立②

数据耦合。如果两个模块之间有调用关系，相互以参数形式传递信息，而且交换的信息仅仅是数据，那么这种耦合称为数据耦合。系统中至少必须存在这种耦合，因为只有当某些模块的输出数据作为另一个模块的输入数据时，系统才能完成有价值的功能。数据耦合是理想的设计目标。模块独立③

特征耦合。两个模块通过传递数据结构加以联系，或都与一个数据结构有关系，则称这两个模块之间存在特征耦合（或标记耦合）。当被调用模块只需要整个数据结构中的一部分数据元素时，将整个数据结构作为参数的弊端是极易造成信息泄漏，给计算机犯罪提供了可乘之机。模块独立④

控制耦合。如果两个模块彼此间传递的信息中有控制信息，这种耦合称为控制耦合。比如，一个模块传递开关、标志、名字等控制信息，明显控制另一个模块的内部执行逻辑。这种耦合意味着被调用模块内部的功能分解不彻底，调用模块需要知道被调用模块内部的逻辑结构，这就降低了模块的独立性，对被调用模块再分解后可以用数据耦合替代。模块独立⑤

公共环境耦合。当两个或多个模块通过一个公共数据环境相互作用时，它们之间的耦合称为公共环境耦合。公共环境是指全局变量、共享通信区、内存的公共覆盖区、任何存储介质上的文件、物理设备等。公共环境耦合的强度，随耦合的模块个数而变化——随耦合模块的个数增加而增加。在只有两个模块有公共环境耦合的情况下，这种耦合又可分为两种情况。模块独立一种情况是，一个模块往公共环境送数据，另一个模块从公共环境取数据。这种公共环境耦合是一种比较松散的耦合。另一种情况是，两个模块都既往公共环境中送数据，又从连取数据。这种耦合比较紧密，介于数据耦合和控制耦合之间。模块独立如果两个模块共享的数据很多，都通过参数传递可能很不方便，此时利用公共环境耦合是一种可以被接受的方案。模块独立⑥

内容耦合。如果一个模块直接访问另一个模块的内部数据，一个模块不通过正常入口而转入到另一个模块的内部，两个模块有一部分代码重叠（只可能出现在汇编程序中），一个模块有多个入口，这些现象都属于内容耦合。内容耦合是最高程度的耦合，是应该坚决避免使用的耦合。模块独立总之，在设计软件结构时，应该根据问题的特点，选择合适的耦合类型。尽量使用数据耦合，少用标记耦合和控制耦合，限制使用公共环境耦合，完全不用内容耦合。具体做法有：降低模块接口的复杂性，减少每个模块的参数个数，尽量使用标准过程调用，少用直接引用，以标准的形式直接传递数据，把模块的通信信息放在缓冲区中。模块独立（2）内聚内聚标志了一个模块内部各元素彼此结合的紧密程度。它是信息隐藏和局部化概念的自然扩展。理想的内聚是每个模块只做一件事。设计软件结构时应该力求做到高内聚，中等程度的内聚也是可以接受的选择。内聚和耦合密切相关，内聚高往往意味着耦合松散。模块独立内聚和耦合都是设计软件结构时需要考虑的结构特征，但是实践经验表明，内聚更重要，应该把更多的注意力集中到提高模块的内聚程度上。这类似于每个人做好自己，最终形成良好社会的的价值观，因为通过统筹管理获得全面提高的难度显然更大。按照内聚程度的不同，内聚可以分为七种情况，如图4.5所示。低高内聚性中等强度内聚低内聚强内聚偶然内聚逻辑内聚时间内聚过程内聚通信内聚顺序内聚功能内聚模块独立性强弱图4.5内聚类型模块独立①

偶然内聚。模块内个元素之间没有实质性的联系，或者说模块内各组成成分在功能上互不相关。偶然内聚是强度最低的一种内聚，模块内各元素不是为同一个功能服务，各有不同需求，因而模块的内容不易理解，也不易修改和维护。模块独立②

逻辑内聚。如果一个模块完成的任务在逻辑上属于相同或相似的一类，各元素之间存在必然的逻辑关系，则它们之间的关系属于逻辑内聚。典型的情况是把几种相关的功能组合在一个模块内，由传递给模块的参数确定每次调用执行哪种功能。逻辑内聚会存在不同功能混在一起，共用部分程序代码的情况，在遇到需求修改模块时，往往会影响全局，使修改比较困看。模块独立③

时间内聚。一个模块包含的任务必须在同一时间段内执行，这些功能仅是因为时间因素被组织在一起。例如，初始化工作，同时打开文件，关闭文件，紧急故障处理等都是时间内聚模块。一般情况下，各部分只要满足时间上的同一性，执行顺序可以任意安排。模块独立④

过程内聚。如果一个模块内的元素是相关的，而且必须以特定次序执行，受同一控制流支配则称为过程内聚。使用程序流程图设计程序时，确定的模块划分往往得到过程内聚的模块。例如，把流程图中的循环部分、判定部分、计算部分分成3个模块，这3个模块是过程内聚模块。模块独立⑤

通信内聚。如果模块中所有元素都使用相同的输入数据或产生相同的输出数据，则称为通信内聚。⑥

顺序内聚。如果一个模块内的处理元素和同一个功能密切相关，而且这些处理必须顺序执行。通常是，一个处理元素的输出最为下一个处理元素的输入，即在同一个数据结构上操作。根据数据流图划分模块时，往往得到顺序内聚的模块。模块独立⑦

功能内聚。模块内的所有处理元素属于一个整体，即完成一个单一的功能。功能内聚是最高成都的内聚，是设计的目标和理想的结构。在实际设计中，没有必要精确确定内聚的级别，重要的是力争做到高内聚，并且能辨认出低内聚模块，通过修改结构提高内聚程度。软件结构设计准则04软件结构设计准则人们在软件开发的长期实践中积累了丰富的经验，总结得出了一些启发规则，这些规则不是普适的基本原理，但是在许多场合仍然具有一定的指导作用，往往能帮助设计人员改进软件结构提高软件质量。这些规则不是设计目标，但可以作为软件结构设计的准则加以利用。这些准则如下：软件结构设计准则（1）改进软件结构提高模块独立性。初步设计出软件结构之后，为了提高模块的独立性，应该审查、分析这个结构，通过分解和合并，力求降低耦合性提高内聚性。例如多个模块公有的一个子功能可以独立成一个模块，由这些模块调用；有时通过分解或合并模块可以减少控制信息的传递及对全程数据的引用，并降低接口的复杂程度。软件结构设计准则（2）模块规模应该适中。有人从心理学角度研究得知，一个模块的规模不应过大，最好能写在一页A4纸内（通常不超过60行语句），当超过30行以后，模块的可理解性迅速下降。过大的模块往往是由于分解不充分，但是进一步分解必须符合问题结构，一般说，分解不应以牺牲模块独立性为代价。软件结构设计准则模块规模也不宜过小，模块过小，目标系统所需的模块个数必然增多，接口必然复杂。特别是只有一个上层模块调用的模块，通常可以合并到上级模块中。软件结构设计准则（3）深度、宽度、扇入、扇出都应当适中深度指软件结构中控制的层数。在一定意义上能粗略地反映系统的规模和复杂程度。深度和程序的长度有粗略的对应关系，程序越长往往容易深度越深。如果深度过大，则表示控制层数太多，应该考虑是否其中某些模块分的过于简单了，可以考虑适当合并。软件结构设计准则宽度是指软件结构在同一个层次上的模块总数的最大值。一般说来，宽度越大系统越复杂。对宽度影响最大的因素是模块的扇出。扇出是指一个模块直接调用的模块数目。扇出过大意味着模块过分复杂，需要协调和控制过多的下层模块；扇出过小也不好，比如总数是1。经验表明，一个设计得好的典型系统的平均扇出通常是3或4（扇出的上限通常是5~9）。软件结构设计准则扇出过大一般是因为缺乏中间层，此时应当适当增加中间控制层模块。扇出过小时，可以把下级模块进一步分解成若干个子功能模块，或者合并到上级模块中去。通过分解或合并调整软件结构时，必须符合问题结构（即不能违背解决问题的常识），同时也不能违背模块独立原理。软件结构设计准则扇入是指一个模块有多少个上级模块直接调用它。扇入越大说明该模块共享程度越高，这是有利的，但是，不能违背模块独立原理单纯追求高扇入。一般设计得好的软件结构，通常顶层扇出比较高，中间层扇出较少，底层扇入到公共的使用模块中区，从形象看像一个橄榄型。软件结构设计准则（4）模块的作用域应该在控制域之内模块的作用域是指受该模块内一个判定影响的所有模块的集合。模块的控制域是指模块本身及其所有直接或间接从属于它的模块集合。软件结构设计准则在一个设计得好的系统中，所有受判定影响的模块应该都从属于做出判定的那个模块，最好局限于做出判定的那个模块本身及它的下属模块。否则，就需要在作用域之外传递控制信息，以保持判定应有的作用，如此便增加了控制耦合，使软件结构变得复杂而难以理解。软件结构设计准则（5）降低模块结构的复杂程度模块接口复杂是软件出错的主要原因之一。接口的设计应该尽量使信息传递简单，并与模块的功能一致。如果模块的接口复杂或不一致（即看起来传递的数据之间没有联系），是紧耦合低内聚的征兆，应该重新分析该模块的独立性。软件结构设计准则（6）设计单入口单出口的模块这条规则是在告诫软件工程师不要模块间出现内容耦合。当从顶部进入模块且从底部退出模块时，软件是比较容易理解的。软件结构设计准则（7）模块功能应该可以预测模块功能应该能够预测，是考虑到方便以后的软件测试性和维护，但也要防止模块功能过分局限。软件结构设计准则如果一个模块可以看作一个黑盒子，只要输入相同的数据就产生同样的输出，这个模块的功能就是可以预测的。任意限制模块内数据结构的大小、过分限制在控制流中可以做出的选择或外部接口的模式，该模块的功能就过分局限了（使用范围过分狭窄），毕竟可重用性是现代软件设计追求的价值观之一。在现实中不可避免地要修改这类结构，以提高模块的灵活性，扩大它的使用范围。软件结构设计准则以上七条总体设计的准则是经验性的，对改进设计、提高质量往往具有重要的参考价值。但是，需要注意它们既不是设计的目标，也不是设计时应该普遍遵循的原理，仅是可以借鉴的经验。描绘软件结构的图形工具05层次图层次图用来描绘软件的层次结构。层次图中，一个矩形框代表一个模块，方框间的连线表示调用关系，最顶层的方框代表目标系统的主控模块。在方框图中，位于上层的模块调用其有连线的下层模块。层次图适用于自顶向下设计软件结构。图4.6是一个库存管理系统的层次图。层次图在使用层次图时，应该注意以下三点。（1）在层次图中，同一层模块对其上层来说，不存在调用次序问题，虽然人们习惯于从左往右画，但并不代表系统按此顺序调用下层模块。（2）层次图不指明怎样调用模块。（3）层次图只表明一个模块调用哪些模块。HIPO图HIPO（Hierarchy

Plus

Input-Process-Output）图是层次图加上输入-处理-输出图的英文缩写，是IBM公司20世界70年代发展起来表示软件结构的一种常用描述工具。为了能使HIPO图具有可追踪性，在H图（层次图）中除了顶层方框之外，每个方框都加了编号。HIPO图完整的HIPO图由层次图和IPO表组成。H图中的每一个模块要对应一张IPO表，每一个IPO表都要编号，并且要和它所对应的模块的编号一致。结构图Yourdon提出的结构图是进行软件结构设计的另一个有力工具。结构图中一个方框代表一个模块，框内注明模块的名称或主要功能；方框之间用箭头或直线连接表示调用关系，因为按照习惯总是上方模块调用下层模块，为了简单起见，一般用直线替代箭头线表示模块间的调用关系。结构图在结构图中通常还用带有注释的箭头表示模块调用过程中来回传递的信息，其中箭头尾部是空心圆表示传递的是数据，实心圆表示传递的是控制信息，如图4.8所示。产生最佳解结构图解得到好输入计算最佳解输出结果结果格式化显示结果读输入编辑输入图4.8产生最佳解的结构图此外，结构图还使用一些附加符号表示模块的选择调用或循环调用。图4.9所示为当模块M中某个判定为真时调用模块A，为假时调用模块B。图4.10所示为模块M循环调用A、B、C。图4.9结构图选择调用表示法图4.10结构图循环调用表示法结构图通常层次图作为描绘软件结构的文档，而结构图作为文档并不是很合适，因为结构图上的信息较多，反而降低了结构图的清晰性。但是，结构图却可以作为检查设计正确性和评价模块独立性的好方法。如果发现结构图上的模块间的练习不容易解释，则应该考虑是否设计上存在问题。面向数据流的软件结构设计方法06面向数据流的软件结构设计方法面向数据流的软件结构设计方法，即以数据流图为依据的设计软件结构的方法，也是通常所说的结构化设计方法（简称SD方法）。因为任何软件系统都可以用数据流图表示，所以面向数据流的设计方法理论上可以设计任何软件系统的结构。概念面向数据流的设计方法的实质是把数据流图的信息流映射成软件结构。因此，信息流的类型决定了映射的方法。按照信息流的流动特征，可以分为变换流和事务流。概念（1）变换流任何软件系统都看作是一种信息处理系统，信息通常以“外部世界”的形式进入系统，经过处理再以“外部世界”的形式离开系统。概念变换流的特征如图4.11所示。信息沿输入通路进入系统，同时由外部形式转换成内部形式，进入系统的信息经过变换中心的加工处理后，再沿着输出通路变换成外部形式离开软件系统。当数据流具有这些特征时，这种信息流就叫做变换流。概念（2）事务流基本系统模型的实质是变换流，因此，原则上所有信息流都可归结为变换流。但是，当数据流图明显具有图4.12特征时，这种数据流是“以事务为中心的”，即数据沿着输入通路到达一个处理T，该处理根据输入数据的类型在若干个动作序列中选出一个执行。这种数据流称为事务流（输入数据称为事务）。图4.11变换流示意图图4.12事务流示意图面向数据流设计方法的过程运用面向数据流的方法进行软件结构设计的过程，如图4.13所示。应该注意，设计属于创造性活动，不能没有规矩，但更不能拘囿于规矩，设计首先需要人的判断力和创造精神，这些常常需要凌驾于规则之上，才能有最大自由的发挥，才能获得最佳的效果。图面向数据流设计方法的过程变换分析法（1）复查基本系统模型首先应该对需求分析阶段得到的基本系统模型进行复查，复查的目的是为了确保输入数据和输出数据符合实际。变换分析法（2）复查并精化数据流图应该对需求分析阶段得到的数据流图进行复查，并在必要时进行精化。要确保数据流图正确描绘了目标系统的业务业务逻辑，同时要确保数据流图中的每个处理都代表了一个规模适中、相对独立的子功能。变换分析法（3）确定数据流图的类型通常，一个系统中的所有信息都可以被认为是变换流，但是，当遇到有明显事务特性的信息流时，还是采用事务分析的方法进行映射。多数情况是，系统即具有变换特征，也具有事务特征，因此，在确定系统数据流图的特征时，应该从全局角度考虑哪种特征更占优。变换分析法（4）确定数据流的边界对于变换流来说，分析确定输入流和输出流的边界，从而孤立出变换中心。对于事务流来说，分析确定输入流的边界，从而孤立出事务中心。变换分析法在确定边界时，不同的设计考虑有不同的取舍标准，但是，通常一个处理框的误差对最终的软件结构影响不大，况且在到初步软件结构后，还有优化调整的要求。接下来，选取相应的分析方法把系统数据流图映射成变换型结构或事务型结构。变换分析法（5）完成“第一级分解”传统方法论中，软件结构代表对控制自顶向下的分配，所谓分解其实就是分配控制，分配从属关系。第一级分解，就是分配软件结构中的顶层控制。变换分析法对于变换流的情况，位于软件结构最顶层的总控模块协调以下三个从属模块的控制。（1）输入信息处理控制模块。此模块协调对所有输入数据的接收。（2）变换中心控制模块。此模块管理对内部形式的数据的所有操作。（3）输出信息处理控制模块。此模块协调输出信息的产生过程。变换分析法（6）完成“第二级分解”进行第二级分解就是把数据流图中的每个处理映射成软件结构中的一个适当的模块。具体到变换流来说，第二级分解就是从变换中心的边界开始沿着输入通路向外移动，把输入通路中每个处理依次映射成软件结构中的“输入信息处理控制模块”控制下的一个低层模块。变换分析法然后，再从变换中心的边界开始，沿着输出通络向外移动，把输出通路中的每个处理依次映射成直接或间接受“输出信息处理控制模块”控制的一个低层模块。最后，把变换中心内的每个处理映射成受“变换中心控制模块“控制的一个个模块。变换分析法（7）优化对经过以上步骤得到的结果按照模块独立原理和总体设计准则进行优化。为了产生合理的分解，得到尽可能高的内聚、尽可能松散的耦合，最重要的是得到一个易于实现、易于测试、和易于维护的软件结构，应该对初步得到的软件模块进行再分解或合并。变换分析法机械地遵循上述映射规则很可能会得出一些不必要的控制模块，如果它们确实用处不大，那么应该合并它们。如果控制模块功能过分复杂，可以适当地增加中间层的控制模块或者进一步将它们分解。变换分析法任何优化过程不能违背设计原理，不能违背问题域常识、不能为了最求所谓的“最佳设计”而优化。设计的优化可能会导出不同的软件结构，要从中选优，力求得到“最好“的结构。避免把结构的优化留到过程设计阶段，这也是把结构设计和过程设计分开的价值所在。变换分析法结构简单往往表明效率高。设计优化应该力求做到在有效模块化的前提下使用尽可能少的模块数，以及在能够满足信息要求的前提下使用最简单的数据结构。切记，不能正常工作的最佳设计没有实际意义。正常工作是一切设计优化的基础，高效、最佳只是愿景目标。简单说就是“先使它能工作，然后再使它快起来”。事务分析法事务分析的设计步骤和变换分析的设计步骤大致相同或类似，区别仅在于映射方法。由事务流映射成的软件结构包括一个接收分支和一个发送分支。从事务中心的边界开始，把接收流童虎的处理映射成模块。发送分支由一个调度模块控制它下面的所有模块。然后把数据流图中的每个活动流通路映射成与它的流特征相对应的结构。如图4.14所示。总控接收通路调度BACA通

路图4.14事务分析映射法事务分析法一般来说，如果数据流图不具有显著的事务特征，最好使用变换分析；反之，则使用事务分析技术。对于大型的或复杂的系统，事务分析和变换分析往往兼而有之。事务分析法例4.1：由于总体设计的主要工作开始于对需求分析获得的数据流图的分析，下面以某个“学生档案管理系统”的数据流图为例，运用面向数据流的方法设计其软件结构。假设某“学生档案管理系统”的数据流图如图4.15所示，并且假设