对软件进行模块设计的时候,可以有不同的抽象层次。在最高的抽象层次上,可以使用 问题所处环境的语言描述问题的解法。而在较低的抽象层次上,则采用过程化的方法 过程的抽象:在软件工程过程中,从系统定义到实现,每进展一步都可以看做是对 软件解决方案的抽象化过程的一次细化。在软件计划阶段,软件被当做整个计算机系统中的 个元素来看待。在软件需求分析阶段,用“问题所处环境的为大家所熟悉的术语”来描述 软件的解决方法。而在从概要设计到详细设计的过程中,抽象化的层次逐次降低。当产生源 程序时到达最低的抽象层次 数据抽象:数据抽象与过程抽象一样,允许设计人员在不同层次上描述数据对象的 细节。例如,可以定义一个draw数据对象,并将它规定为一个抽象数据类型,用它的构成元 素来定义它的内部细节。此时,数据抽象draw本身是由另外一些数据抽象构成。而且在定义 draw的抽象数据类型之后,就可以引用它来定义其它数据对象,而不必涉及draw的内部细 节 ■控制抽象:与过程抽象和数据抽象一样,控制抽象可以包含一个程序控制机制而无 须规定其内部细节。控制抽象的例子就是在操作系统中用以协调某些活动的同步信号。 (2)自顶向下,逐步细化 Niklaus wirth提出的设计策略。将软件的体系结构按自顶向下方式,对各个层次的过程 细节和数据细节逐层细化,直到用程序设计语言的语句能够实现为止,从而最后确立整个的 体系结构。最初的说明只是概念性地描述了系统的功能或信息,但并未提供有关功能的内部 实现机制或有关信息的内部结构的任何信息。设计人员对初始说明仔细推敲,进行功能细化 或信息细化,给出实现的细节,划分出若干成份。然后再对这些成份,施行同样的细化工作。 随着细化工作的逐步展开,设计人员就能得到越来越多的细节 (3)模块化 软件系统的层次结构正是模块化的具体体现。就是说,整个软件被划分成若干单独命名 和可编址的部分,称之为模块。这些模块可以被组装起来以满足整个问题的需求 个大软件,由于其控制路径多、涉及范围广、变量多及其总体复杂性,使其相对于 个较小的软件不容易被人们理解。在解决问题的实践中,如果把两个问题结合起来作为一个 问题来处理,其理解复杂性大于这两个问题被分开考虑时的理解复杂性之和。因此,把一个 大而复杂的问题分解成一些独立的易于处理的小问题,解决起来就容易得多。 基于上述考虑,把问题/子问题(功能/子功能)的分解与软件开发中的系统/子系统 或者系统/模块对应起来,就能够把一个大而复杂的软件系统划分成易于理解的比较单纯的 模块结构。所谓“比较单纯”,是指模块和其它模块之间的接口应尽可能独立ε 实际上,如果模块是相互独立的,当模块变得越小,每个模块花费的工作量越低:但当 模块薮増加时,模块间的联系也随之増加,把这些模块联接起来的工作量也随之増加。如图 4.3所示。因此,存在一个模块个数M,它使得总的开发成本达到最小 成成本/模块 联接成本 总的软件成本 或工作量 最小成本范围 模块数目增加 模块大小减小 模块个数模块数/模块大小3 对软件进行模块设计的时候，可以有不同的抽象层次。在最高的抽象层次上，可以使用 问题所处环境的语言描述问题的解法。而在较低的抽象层次上，则采用过程化的方法。 ▪ 过程的抽象 ：在软件工程过程中，从系统定义到实现，每进展一步都可以看做是对 软件解决方案的抽象化过程的一次细化。在软件计划阶段，软件被当做整个计算机系统中的 一个元素来看待。在软件需求分析阶段，用“问题所处环境的为大家所熟悉的术语”来描述 软件的解决方法。而在从概要设计到详细设计的过程中，抽象化的层次逐次降低。当产生源 程序时到达最低的抽象层次。 ▪ 数据抽象 ：数据抽象与过程抽象一样，允许设计人员在不同层次上描述数据对象的 细节。例如，可以定义一个 draw 数据对象，并将它规定为一个抽象数据类型，用它的构成元 素来定义它的内部细节。此时，数据抽象 draw 本身是由另外一些数据抽象构成。而且在定义 draw 的抽象数据类型之后，就可以引用它来定义其它数据对象，而不必涉及 draw 的内部细 节。 ▪ 控制抽象 ：与过程抽象和数据抽象一样，控制抽象可以包含一个程序控制机制而无 须规定其内部细节。控制抽象的例子就是在操作系统中用以协调某些活动的同步信号。 (2) 自顶向下，逐步细化 Niklaus Wirth 提出的设计策略。将软件的体系结构按自顶向下方式，对各个层次的过程 细节和数据细节逐层细化，直到用程序设计语言的语句能够实现为止，从而最后确立整个的 体系结构。最初的说明只是概念性地描述了系统的功能或信息，但并未提供有关功能的内部 实现机制或有关信息的内部结构的任何信息。设计人员对初始说明仔细推敲，进行功能细化 或信息细化，给出实现的细节，划分出若干成份。然后再对这些成份，施行同样的细化工作。 随着细化工作的逐步展开，设计人员就能得到越来越多的细节。 (3) 模块化 软件系统的层次结构正是模块化的具体体现。就是说，整个软件被划分成若干单独命名 和可编址的部分，称之为模块。这些模块可以被组装起来以满足整个问题的需求。 一个大软件，由于其控制路径多、涉及范围广、变量多及其总体复杂性，使其相对于一 个较小的软件不容易被人们理解。在解决问题的实践中，如果把两个问题结合起来作为一个 问题来处理，其理解复杂性大于这两个问题被分开考虑时的理解复杂性之和。因此，把一个 大而复杂的问题分解成一些独立的易于处理的小问题，解决起来就容易得多。 基于上述考虑，把问题／子问题（功能／子功能）的分解与软件开发中的系统／子系统 或者系统／模块对应起来，就能够把一个大而复杂的软件系统划分成易于理解的比较单纯的 模块结构。所谓“比较单纯”，是指模块和其它模块之间的接口应尽可能独立。 实际上，如果模块是相互独立的，当模块变得越小，每个模块花费的工作量越低；但当 模块数增加时，模块间的联系也随之增加，把这些模块联接起来的工作量也随之增加。如图 4.3 所示。因此，存在一个模块个数 M， 它使得总的开发成本达到最小