软件设计的概念和原理
出处：按学科分类—工业技术 企业管理出版社《工程师手册》第990页（6399字）
本节讲述在软件设计过程中应该遵循的基本原理和有关的概念。
1．模块化
模块是数据说明、可执行语句等程序对象的集合，它是单独命名的而且可通过名字来访问，例如，过程、函数、子程序、宏等等。模块化就是把程序划分成若干个模块，每个模块完成一个子功能，把这些模块集总起来组成一个整体，可以完成指定的功能满足问题的要求。
有人说，模块化是为了使一个复杂的大型程序能被人的智力所管理，是软件应该具备的唯一属性。如果一个大型程序仅由一个模块组成，它将很难被人所理解。下面根据人类解决问题的一般规律，论证上面的结论。
设函数C(x)定义问题x的复杂程度，函数E(x)确定解决问题x需要的工作量(时间)。对于两个问题P1和P2，如果
C(P1)＞C(P2)显然E(P1)＞E(P2)
根据人类解决一般问题的经验，另一个有趣的规律是
C(P1+P2)＞C(P1)+C(P2)也就是说，如果一个问题由P1和P2两个问题组合而成，那么它的复杂程序大于分别考虑每个问题时的复杂程度之和。
综上所述，得到下面的不等式
E(P1+P2)＞E(P1)+E(P2)这个不等式导致“各个击破”的结论——把复杂的问题分解成许多容易解决的小问题，原来的问题也就容易解决了。这就是模块化的根据。
由上面的不等式似乎还能得出下述结论：如果无限地分割软件，最后为了开发软件而需要的工作量也就小得可以忽略了。事实上，还有另一个因素在起作用，从而使得上述结论不能成立。参看图7．4．2－1，当模块数目增加时每个模块的规模将减小，开发单个模块需要的成本(工作量)确实减少了；但是，随着模块数目增加，设计模块间接口所需要的工作量也将增加。根据这两个因素，得出了图中的总成本曲线。每个程序都相应地有一个最适当的模块数目M，使得系统的开发成本最小。
图7．4．2－1 模块化和软件成本
采用模块化原理可以使软件结构清晰，不仅容易设计也容易阅读和理解。因为程序错误通常局限在有关的模块及它们之间的接口中，所以模块化使软件容易测试和调试，因而有助于提高软件的可靠性。因为变动往往只涉及少数几个模块，所以柜块化能够提高软件的可修改性。模块化也有助于软件开发工程的组织管理，一个复杂的大型程序可以由许多程序分工编写不同的模块，并且可以进一步分配技术熟练的程序员编写困难的模块。
2．抽象
人类在认识复杂现象的过程中使用的最强有力的思维工具是抽象。人们在实践中认识到，在现实世界中一定事物、状态或过程之间总存在着某些相似的方面(共性)。把这些相似的方面集中和概括起来，暂时忽略它们之间的差异，这就是抽象。或者说抽象就是抽出事物的本质特性而暂时不考虑它们的细节。
由于人类思维能力的限制，如果每次面临的因素太多，是不可能做出精确思维的。处理复杂系统的唯一有效的方法是用层次的方式构造和分析它。一个复杂的动态系统首先可以用一些高级的抽象概念构造和理解，这些高级概念又可以用一些较低级的概念构造和理解，如此进行下去，直至最低层次的具体元素。
这种层次的思维和解题方式必须反映在定义动态系统的程序结构之中，每级的一个概念将以某种方式对应于程序的一组成分。
当我们考虑对任何问题的模块化解法时，可以提出许多抽象的层次。在抽象的最高层次使用问题环境的语言，以概括的方式叙述问题的解法；在较低抽象层次采用更过程化的方法，把面向问题的术语和面向实现的术语结合起来叙述问题的解法；最后，在最低的抽象层次用可以直接实现的方式叙述问题的解法。
软件工程过程的每一步都是对软件解法的抽象层次的一次精化。在可行性研究阶段，软件作系统的一个完整部件；在需求分析期间，软件解法是使用在问题环境内熟悉的方式描述的；当我们由总体设计向详细设计过渡时，抽象的程度也就随之减少了；最后，当源程序写出来以后，也就达到了抽象的最低层。
逐步求精和模块化的概念，与抽象是紧密相关的。随着软件开发工程的进展，在软件结构每一层中的模块，表示了对软件抽象层次的一次精化。事实上，软件结构顶层的模块，控制了系统的主要功能并且影响全局；在软件结构底层的模块，完成对数据的一个具体处理，用自顶向下由抽象到具体的方式分配控制，简化了软件的设计和实现，提高了软件的可理解性和可测试性，并且使软件更容易维护。
3．信息隐蔽和局部化
应用模块化原理时，自然会产生的一个问题是：“为了得到最好的一组模块，应该怎样分解软件呢?”信息隐蔽原理指出：应该这样设计和确定模块，使得一个模块内包含的信息(过程和数据)对于不需要这些信息的模块来说，是不能访问的。
局部化的概念和信息隐蔽概念是密切相关的。所谓局部化是指把一些关系密切的软件元素物理地放得彼此靠近。在模块中使用局部数据元素是局部化的一个例子。显然，局部化有助于实现信息陷蔽。
“隐蔽”意味着有效的模块化可以通过定义一组独立的模块而实现，这些独立的模块彼此间仅仅交换那些为了完成系统功能而必须交换的信息。
如果在测试期间和以后的软件维护期间需要修改软件，那么使用信息隐蔽原理作为模块化系统设计的标准就会带来极大好处。在为绝大多数数据和过程对于软件的其他部分而言是隐蔽的(也就是“看”不见的)，在修改期间由于疏忽而引入的错误就很少可能传播到软件的其他部分。
4．模块独立
模块独立的概念是模块化、抽象、信息隐蔽和局部化概念的直接结果。
开发具有独立功能而且和其他模块之间没有过多的相互作用的模块，就可以做到模块独立。换句话说，希望这样设计软件结构，使得每个模块完成一个相对独立的特定子功能，并且和其他模块之间的关系很简单。
为什么模块的独立性很重要呢?主要有两条理由：第一，有效的模块化(即具有独立的模块)的软件比较容易开发出来。这是由于能够分割功能而且接口可以简化，当许多人分工合作开发同一个软件时，这个优点尤其重要。第二，独立的模块比较容易测试和维护。这是因为相对说来，修改设计和程序需要的工作量比较小，错误传播范围小，需要扩充功能时能够“插入”模块。总之，模块独立是好设计的关键，而设计又是决定软件质量的关键环节。
模块的独立程度可以由两个定性标准度量，这两个标准分别称为内聚和耦合。耦合衡量不同模块彼此间互相依赖(连接)的紧密程度；内聚衡量一个模块内部各个元素彼此结合的紧密程度。以下分别详细阐述。
(1)耦合
耦合是对一个软件结构内不同模块之间互连程度的度量。耦合强弱取决于模块间接口的复杂程度，进入或访问一个模块的点，以及通过接口的数据。
在软件设计中应该追求尽可能松散耦合的系统。在这样的系统中可以研究、测试或维护任何一个模块，而不需要对系统的其他模块有很多了解。此外，由于模块间联系简单，发生在一处的错误传播到整个系统的可能性就很小。因此，模块间的耦合程度强烈影响系统的可理解性、可测试性、可靠性和可维护性。
怎样具体区分模块间耦合程度的强弱呢?
如果两个模块中的每一个都能独立地工作而不需要另一个模块的存在，那么它们彼此完全独立，这意味着模块间无任何连接，耦合程度最低。但是，在一个软件系统中不可能所有模块之间都没有任何连接。
如果两个模块彼此间通过参数交换信息，而且交换的信息仅仅是数据，那么这种耦合称为数据耦合。如果传递的信息中有控制信息(尽管有时这种控制信息以数据的形式出现)，则这种耦合称为控制耦合。
数据耦合是低耦合。系统中至少必须存在这种耦合，因为只有当某些模块的输出数据作为另一些模块的输入数据时，系统才能完成有价值的功能。一般说来，一个系统内可以只包含数据耦合。控制耦合往往是多余的，在把模块适当分解之后通常可以用数据耦合代替它。
当两个或多个模块通过一个公共数据环境相互作用时，它们之间的耦合称为公共环境耦合。公共环境可以是全程变量、共享的通信区、内存的公共覆盖区、任何存储介质上的文件、物理设备等等。
公共环境耦合的复杂程度随耦合的模块个数而变化，当耦合的模块个数增加时复杂的程度显着增加。如果只有两个模块有公共环境，那么这种耦合有下面两种可能：
一个模块往公共环境送数据，另一个模块从公共环境取数据。这是数据耦合的一种形式，是比较松散的耦合。
两个模块都既往公共环境送数据又从里面取数据，这种耦合比较紧密，介于数据耦合和控制耦合之间。
如果两个模块共享的数据很多，都通过参数传递可能很不方便，这时可以利用公共环境耦合。
最高程度的耦合是内容耦合。如果出现下列情况之一，两个模块间就发生了内容耦合：
①一个模块访问另一个模块的内部数据；
②一个模块不通过正常入口而转到另一个模块的内部；
③两个模块有一部分程序代码重叠(只可能出现在汇编程序中)；
④一个模块有多个入口(这意味着一个模块有几种功能)。
应该坚决避免使用内容耦合。事实上许多高级程度设计语言已经设计成不允许在程序中出现任何形式的内容耦合。
总之，耦合是影响软件复杂程度的一个重要因素。应该采取下述设计原则：
尽量使用数据耦合，少用控制耦合，限制公共环境耦合范围，完全不用内容耦合。
(2)内聚
内聚标志一个模块内各个元素彼此结合的紧密程度，它是信息隐蔽和局部化概念的自然扩展。简单地说，理想内聚的模块只做一件事情。
设计时应该力求做到高内聚，通常中等程度的内聚也是可以采取的，而且效果和高内聚相差不多；但是，低内聚很坏，不要使用。
内聚和耦合是密切相关的，模块内的高内聚往往意味着模块间的松耦合。内聚和耦合都是进行模块化设计的有力工具，但是实践表明内聚更重要，应该把更多注意力集中到提高模块的内聚程度上。
低内聚有如下几类：如果一个模块完成一组任务，这些任务彼此间即使有关系，关系也是很松散的，就叫做偶然内聚。有时在写完一个程序之后，发现一组语句在两处或多处出现，于是把这些语句作为一个模块以节省内存，这样就出现了偶然内聚的模块。如果一个模块完成的任务在逻辑上属于相同或相似的一类，(例如，一个模块产生各种类型的全部输出)，则称为逻辑内聚。如果一个模块包含的任务必须在同一段时间内执行(例如，模块完成各种初始化工作)，就叫时间内聚。
在偶然内聚的模块中，各种元素之间没有实质性联系，很可能在一种应用场合需要修改这个模块，在另一种应用场合又不允许这种修改，从而陷入困境，事实上，偶然内聚的模块出现修改错误的概率比其他类型的模块高得多。
在逻辑内聚的模块中，不同功能混在一起，合用部分程序代码，即使局部功能的修改有时也会影响全局。因此，这类模块的修改也比较困难。
时间关系在一定程度上反映了程序的某些实质，所以时间内聚比逻辑内聚好一些。
中内聚主要有两类：如果一个模块内的处理元素是相关的，而且必须以特定次序执行，则称为过程内聚。使用程序流程图作为工具设计软件时，常常通过研究流程图确定模块的划分，这样得到的往往是过程内聚的模块。如果模块中所有元素都使用同一个输入数据和(或)产生同一个输出数据，则称为通信内聚。
高内聚也有两类：如果一个模块内的处理元素和同一个功能密切相关，而且这些处理必须顺序执行(通常一个处理元素的输出数据作为下一个处理元素的输入数据)，则称为顺序内聚。根据数据流图划分模块时，通常得到顺序内聚的模块，这种模块彼此间的连接往往比较简单。如果模块内所有处理元素属于一个整体，完成一个单一的功能，则称为功能内聚。功能内聚是最高程度的内聚。
耦合内聚的概念是Constantine，Yourdon，Myerrs和Stevens等人提出来的。按照他们的观点，如果给上述七种内聚的优劣评分，将得到如下结果：
功能内聚10分 时间内聚3分
顺序内聚9分 逻辑内聚1分
通信内聚7分 偶然内聚0分
过程内聚5分
事实上，没有必要精确确定内聚的级别。重要的是设计时力争做到高内聚，并且能够辨认出低内聚的模块，有能力通过修改设计提高模块的内聚程度降低模间的耦合程度，从而获得较高的模块独立性。