设计原理
模块化
模块是由边界元素限定的相邻程序元素的序列，而且有一个总体标识符代表它。
按照模块的定义，过程、函数、子程序和宏，都可作为模块。
面向对象方法学中的对象是模块，对象内的方法也是模块。模块是构成程序的基本构件。
模块化就是把程序划分成独立命名且可独立访问的模块，每个模块完成一个子功能，把这些模块集成起来构成一个整体，可以完成指定的功能满足用户的需求
当模块数目增加时每个模块的规模将减小，开发单个模块需要的成本确实减少了，但是，随着模块数目的增加，设计模块间接口所需要的工作量也将增加，根据这两个因素，得出图中的总成本曲线。
每个程序都相应地有一个最适当的模块数目M，使得系统的开发成本最小，虽然目前还不能精确地决定M的数值，但是在考虑模块化的时候总成本曲线确实是有也的指南。
采用模块化原理可以使软件结构清晰，不仅容易设计也容易阅读和理解。
抽象
人类在认识复杂现象的过程中使用的最强有力的思维工具是抽象。人们在实践中认识到，在现实世界中一定事物、状态或过程之间总存在着某些相似的方面(共性)。把这些相似的方面集中和概括起来，暂时忽略它们之间的差异,这就是抽象。或者说抽象就是抽出事物的本质特性而暂时不考虑它们的细节。
由于人类思维能力的限制，如果每次面临的因素太多，是不可能产生精确思维的。处理复杂系统的唯有效的方法是用层次的方式构造和分析它。一个复杂的动态系统首先可以用一些高级的抽象概念构造和理解.这些高级概念又可以用一些较低级的概念构造和理解，如此进行下去,直至最低层次的具体元素。
这种层次的思维和解题方式必须反映在定义动态系统的程序结构之中，每级的一个概念将以某种方式对应于程序的一组成分。当考虑对任何问题的模块化解法时，可以提出许多抽象的层次。在抽象的最高层次使用问题环境的语言，以概括的方式叙述问题的解法;在较低抽象层次采用更过程化的方法，把面向问题的术语和面向实现的术语结合起来叙述问题的解法;最后,在最低的抽象层次用可以直接实现的方式叙述问题的解法。
软件工程过程的每一步都是对软件解法的抽象层次的一次精化。在可行性研究阶段,软件作为系统的一个完整部件:在需求分析期间，软件解法是使用在问题环境内熟悉的方式描述的:当由总体设计向详细设计过渡时，抽象的程度也就随之减少了;最后,当源程序写出来以后，也就达到了抽象的最低层。
逐步求精和模块化的概念,与抽象是紧密相关的。随着软件开发工程的进展，在软件结构每层中的模块，表示了对软件抽象层次的一次精化。事实上，软件结构顶层的模块,控制了系统的主要功能并且影响全局:在软件结构底层的模块,完成对数据的一个具体处理。用自顶向下由抽象到具体的方式分配控制，简化了软件的设计和实现，提高了软件的可理解性和可测试性，并且使软件更容易维护。
逐步求精
逐步求精是人类解决复杂问题时采用的基本方法，也是许多软件工程技术(例如，规格说明技术，设计和实现技术)的基础。可以把逐步求精定义为:“为了能集中精力解决主要问题而尽量推迟对问题细节的考虑。”
逐步求精之所以如此重要,是因为人类的认知过程遵守Miller 法则:一个人在任何时候都只能把注意力集中在(7土2)个知识块上。
但是，在开发软件的过程中，软件工程师在一段时间内需 要考虑的知识块数远远多于7。例如，一个程序通常不止使用7个数据,一个用户也往往有不止7个方面的需求。逐步求精方法的强大作用就在于,它能帮助软件工程师把精力集中在与当前开发阶段最相关的那些方面上,而忽略那些对整体解决方案来说虽然是必要的，然而目前还不需要考虑的细节.这些细节将留到以后再考虑。Miller 法则是人类智力的基本局限，人们不可能战胜自己的自然本性，只能接受这个事实，承认自身的局限性，并在这个前提下尽自己的最大努力工作。
事实上，可以把逐步求精看作是项把一个时期内必须解决的种种问题按优先级排序的技术。逐步求精方法确保每个问题都将被解决，而且每个问题都将在适当的时候被解决,但是，在任何时候一个人都不需要同时处理7个以上知识块。逐步求精最初是由Niklaus Wirth提出的种自顶向下的设计策略。按照这种设计策略，程序的体系结构是通过逐步精化处理过程的层次而设计出来的。通过逐步分解对功能的宏观陈述而开发出层次结构，直至最终得出用程序设计语盲表达的程序。
Wirth本人对逐步求精策略曾做过如下的概括说明。“我们对付复杂问题的最重要的办法是抽象，因此,对一个复杂的问题不应该立刻用计算机指令、数字和逻辑符号来表示，而应该用较自然的抽象语句来表示，从而得出抽象程序。抽象程序对抽象的数据进行某些特定的运算并用某些合适的记号(可能是自然语言)来表示。对抽象程序做进一步的分解，并进入下 一个抽象层次,这样的精细化过程一直进行下去,直到程序能被计算机接受为止。这时的程序可能是用某种高级语言或机器指令书写的。”
求精实际上是细化过程。
人们从在高抽象级别定义的功能陈述(或信息措述)开始，也就是说，该陈述仅仅概念性地描述了功能或信息，但是并没有提供功能的内部工作情况或信息的内部结构。求精要求设计者细化原始陈述,随着每个后续求精(即细化)步骤的完成而提供越来越多的细节。
抽象与求精是对互补的概念。
抽象使得设计者能够说明过程和数据，同时却忽略了低层细节。事实上，可以把抽象看作是一种通过忽略多余的细节同时强调有关的细节，而实现逐步求精的方法。求精则帮助设计者在设计过程中逐步揭示出低层细节。这两个概念都有助于设计者在设计演化过程中创造出完整的设计模型。
信息隐藏和局部化
应用模块化原理时，自 然会产生的一个问题是:“为了得到最好的-组模块,应该怎样分解软件呢?”信息隐藏原理指出:应该这样设计和确定模块，使得一个模块内包含的信息(过程和数据)对于不需要这些信息的模块来说，是不能访问的。局部化的概念和信息隐藏概念是密切相关的。所谓局部化是指把些 关系密切的软件元素物理地放得彼此靠近。在模块中使用局部数据元素是局部化的一个例子。显然。局部化有助于实现信息隐藏。
实际上，应该隐藏的不是有关模块的切信息，而是 模块的实现细节。 因此，有人主张把这条原理称为“细节胞藏”。在“隐藏”意味着有效的模块化可以通过定又 一组独立的模块面实现，这些独立的模块彼此间仅仅交换那些为了完成系统功能而必须交换的信息。如果在测试期间和以后的软件维护期间需要修改软件，那么使用信息隐藏原理作为模块化系统设计的标准就会带来极大好处。因为绝大多数数据和过程对于软件的其他部分面言是隐藏的(也就是“看”不见的)，在修改期间由于疏忽面引人的错误就很少可能传播到软件的其他部分。
模块独立
模块独立的概念是模块化抽象、信息隐藏和局部化概念的直接结果。
开发具有独立功能面且和其他模块之间没有过多的相互作用的模块，就可以做到模块独立。换句话说，希望这样设计软件结构，使得每个模块完成一个 相对独立的特定子功能，并且和其他模块之间的关系很简单。
为什么模块的独立性很重要呢?主要有两条理由:
第一，有效的模块化(即具有独立的模块)的软件比较容易开发出来。这是由于能够分割功能而且接口可以简化.当许多人分工合作开发同一个软件时，这个优点尤其重要。
第二，独立的模块比较容易测试和维护。这是因为相对说来，修改设计和程序需要的工作量比较小，错误传播范围小，需要扩充功能时能够“插入”模块。总之，模块独立是好设计的关键，而设计又是决定软件质量的关键环节。
模块的独立程度可以由两个定性标准度量，这两个标准分别称为内聚和耦合。耦合衡量不同模块彼此间互相依赖(连接)的紧密程度:内聚衡量一个模块内部各个元素彼此结合的紧密程度。以下分别详细阐述。
1.耦合
耦合是对一个软件结构内不同模块之间互连程度的度量。桐合强弱取决于模块间接口的复杂程度,进人或访问一个模块的点，以及通过接口的数据。
在软件设计中应该追求尽可能松散耦合的系统。在这样的系统中可以研究、测试或维护任何一个模块，而不需要对系统的其他模块有很多了解。此外，由于模块间联系简单,发生在一处的错误传播到整个系统的可能性就很小。因此，模块间的耦合程度强烈影响着系统的可理解性、可测试性、可靠性和可维护性。
怎样具体区分模块间耦合程度的强弱呢?
如果两个模块中的每一个都能独立地工作而不需要另一个模块的存在，那么它们彼此完全独立.这意味着模块间无任何连接，概合程度最低。但是，在一个软件系统中不可能所有模块之间都没有任何连接。
如果两个模块彼此间通过参数交换信息，而且交换的信息仅仅是数据，那么这种耦合称为数据耦合。如果传递的信息中有控制信息(尽管有时这种控制信息以数据的形式出现),则这种耦合称为控制耦合。
数据耦合是低耦合。系统中至少必须存在这种耦合,因为只有当某些模块的输出数据作为另一些模块的输人数据时，系统才能完成有价值的功能。一般说来，一个系统内可以只包含数据耦合。控制耦合是中等度的耦合,它增加了系统的复杂程度。控制耦合往往是多余的，在把模块适当分解之后通常可以用数据耦合代替它。
如果被调用的模块需要使用作为参数传递进来的数据结构中的所有元素,那么，把整个数据结构作为参数传递就是完全正确的。但是，当把整个数据结构作为参数传递而被调用的模块只需要使用其中一部分数据元素时，就出现了特征耦合。在这种情况下，被调用的模块可以使用的数据多于它确实需要的数据，这将导致对数据的访问失去控制，从而给计算机犯罪提供了机会。
当两个或多个模块通过一个公 共数据环境相互作用时，它们之间的耦合称为公共环境耦合。公共环境可以是全程变量、共享的通信区、内存的公共覆盖区、任何存储介质上的文件、物理设备等。
公共环境耦合的复杂程度随耦合的模块个数而变化，当耦合的模块个数增加时复杂程度显著增加。如果只有两个模块有公共环境,那么这种耦合有下面两种可能。
(1)一个模块往公共环境送数据,另一个模块从公共环境取数据。这是数据耦合的一种形式,是比较松散的耦合。
(2)两个模块都既往公共环境送数据又从里面取数据，这种耦合比较紧密,介于数据耦合和控制耦合之间。如果两个模块共享的数据很多，都通过参数传递可能很不方便，这时可以利用公共环境耦合。
最高程度的耦合是内容耦合。如果出现下列情况之一， 两个模块间就发生了内容耦合
1、一个模块访问另一个模块的内部数据。
2、一个模块不通过正常人口而转到另一个模块的内部。
3、两个模块有一部分程序代码重叠(只可能出现在汇编程序中)。
4、一个模块有多个人口(这意味着一个模块有几种功能)。
应该坚决避免使用内容耦合。事实上许多高级程序设计语言已经设计成不允许在程序中出现任何形式的内容耦合。
总之，耦合是影响软件复杂程度的一个重要因素。应该采取下述设计原则:尽量使用数据耦合，少用控制耦合和特征耦合，限制公共环境耦合的范围，完全不用内容耦合。
2.内聚
内聚标志着一个模块内各个元素彼此结合的紧密程度,它是信息隐藏和局部化概念的自然扩展。简单地说,理想内聚的模块只做一件事情 。设计时应该力求做到高内聚，通常中等程度的内聚也是可以采用的，而且效果和高内聚相差不多。内聚和耦合是密切相关的，模块内的高内聚往往意味着模块间的松耦合。内聚和耦合都是进行模块化设计的有力工具，但是实践表明内聚更重要，应该把更乡注意力集中到提高模块的内聚程度上。
低内聚有如下儿类:如果-个模块完成一组任务，这些任务彼此间即使有关系，关系也是很松散的，就叫做偶然内聚。有时在写完一个程序之后，发现 组语句在两处成多处出现，于是把这些语句作为个模块以节 省内存.这样就出现了偶然内聚的模块。如果一个模块完成的任务在逻辑上属于相同或相似的一类(例如 个模块产生 各种类型的全部输出)则称为逻辑内聚。如果一个模块包含的任务必须在同一段时间内执行(例如，模块完成各种初始化工作)，就叫时间内聚。
在偶然内聚的模块中，各种元素之间没有实质性联系,很可能在一种应用场合需要 修改这个模块，而在另种应用场合又不允许这种修改，从而陷人困境。 事实上，偶然内聚
的模块出现修改错误的概率比其他类型的模块高得多。
在逻辑内聚的模块中，不同功能混在一起，合用部分程序代码即使局部功能的修改有时也会影响全局。因此，这类模块的修改也比较困难。
时间关系在一定程度上反映了程序的某些实质，所以时间内聚比逻辑内聚好一些。中内聚主要有两类:如果一个模块内的处理元素是相关的，而且必须以特定次序执行，则称为过程内聚。使用程序流程图作为工具设计软件时，常常通过研究流程图确定模块的划分，这样得到的往往是过程内聚的模块。如果模块中所有元素都使用同一个输人数据和(或)产生同一个输出数据，则称为通信内聚。
高内聚也有两类:如果一个模块内的处理元素和同一个功能密切相关，而且这此处理必须顺序执行(通常一个处理元素的输出数据作为下一个处理元素的输人数据),则称为顺序内聚。根据数据流图划分模块时，通常得到顺序内聚的模块,这种模块彼此间的连接往往比较简单。如果模块内所有处理元素属于一个整体,完成一个单一的功能,则称为功能内聚。功能内聚是最高程度的内聚。
耦合和内聚的概念是Constantine, Yourdon,Myers和Stevens等人提出来的。按照他们的观点，如果给上述7种内聚的优劣评分，将得到如下结果:
功能内聚10 分 时间内聚3 分
顺序内聚9 分 逻辑内聚1 分
通信内聚7 分 偶然内聚0 分
过程内聚5 分
事实上，没有必要精确确定内聚的级别。重要的是设计时力争做到高内聚，并且能够辨认出低内聚的模块，有能力通过修改设计提高模块的内聚程度并且降低模块间的耦合程度，从而获得较高的模块独立性。
