一、模块化

模块：是由边界元素限定的相邻程序元素的序列，而且有一个总体标识符代表它。

模块化：就是把程序划分成独立命名且可独立访问的模块，每个模块完成一个子功能，把这些模块集成起来构成一个整体，可以完成指定的功能满足用户的需求。 

为什么要模块化？

■模块化是为了使一个复杂的大型程序能被人的智力所管理，软件应该具备的惟一属性。

■如果一个大型程序仅由一个模块组成，它将很难被人所理解。

模块化的根据： 

如果C(P1)>C(P2)，显然E(P1)>E(P2)

根据人类解决一般问题的经验：C(P1+P2)>C(P1)+C(P2)

综上所述，得到下面的不等式：E(P1+P2)>E(P1)+E(P2)

每个程序都相应地有一个最适当的模块数目M，使得系统的开发成本最小。 

评价一种设计方法定义模块能力的五条标准：

1、模块可分解性

2、模块可组装性 

3、模块可理解性

4、模块连续性 

5、模块保护性

模块化的作用：

1、采用模块化原理可以使软件结构清晰，不仅容易设计也容易阅读和理解。

2、模块化使软件容易测试和调试，因而有助于提高软件的可靠性。

3、模块化能够提高软件的可修改性。

4、模块化也有助于软件开发工程的组织管理。 

二、抽象

现实世界中一定事物、状态或过程之间总存在着某些相似的方面(共性)。把这些相似的方面集中和概括起来，暂时忽略它们之间的差异，这就是抽象。

抽象就是抽出事物本质特性而暂时不考虑细节。

“抽象是人类处理复杂问题的基本方法之一。”            ——Grady Boach

一般抽象过程：

处理复杂系统的惟一有效的方法是用层次的方式构造和分析它。

一个复杂的动态系统首先可以用一些高级的抽象概念构造和理解，这些高级概念又可以用一些较低级的概念构造和理解，如此进行下去，直至最低层次的具体元素。 

例：过程抽象、数据抽象

软件工程抽象过程：

软件工程过程的每一步都是对软件解法的抽象层次的一次精化。

在可行性研究阶段，软件作为系统的一个完整部件；

在需求分析期间，软件解法是使用在问题环境内熟悉的方式描述的；

当由总体设计向详细设计过渡时，抽象的程度也就随之减少了；

最后，当源程序写出来以后，也就达到了抽象的最低层。 

三、逐步求精

为了能集中精力解决主要问题而尽量推迟对问题细节的考虑。逐步求精是人类解决复杂问题时采用的基本方法，也是许多软件工程技术的基础。

Miller法则：一个人在任何时候都只能把注意力集中在（7±2）个知识块上。 

例：用筛选法求100以内的素数。所谓的筛选法，就是从2到100中去掉2，3，5，7的倍数，剩下的就是100以内的素数。

首先按程序功能写出一个框架

main() 

{ 

  建立2到100的数组A[ ]，其中A[i]＝i；..........................1

  建立2到10的素数表B[ ]，存放2到10以内的素数；......2

  若A[i]＝i是B[ ]中任一数的倍数，则剔除A[i]；............3

  输出A[ ]中所有没有被剔除的数；…..………………....4

 }

上述框架中每一个加工语句都可进一步细化

main()   {

   /*建立2到100的数组A[ ]，其中A[i]＝i*/ ………..………1

   for （i = 2；i <= 100；i++）A[i] = i；

   /* 建立2到10的素数表B[ ]，存放2到10以内的素数*/ ….2

   B[1] =2；  B[2] = 3；  B[3] = 5；  B[4] = 7；

   /*若A[i]＝i是B[ ]中任一数的倍数，则剔除A[i]*/ .…..….3

   for （j = 1； j <= 4； j++）

     检查A[]所有数能否被B[j]整除并将其从A[]剔除；.....3.1

   /*输出A[ ]中所有没有被剔除的数*/  …………………….4

   for （i = 2； i <= 100； i++）

     若A[i]没有被剔除，则输出之……………………..…..4.1

 }

继续对3.1和4.1细化，直到每个语句都能用程序设计语言来表示 

逐步求精的作用：

它能帮助软件工程师把精力集中在与当前开发阶段最相关的那些方面上，而忽略那些对整体解决方案来说虽然是必要的，然而目前还不需要考虑的细节。

逐步求精方法确保每个问题都将被解决，而且每个问题都将在适当的时候被解决，但是，在任何时候一个人都不需要同时处理7个以上知识块。 

Wirth本人对逐步求精策略的概括说明：

我们对付复杂问题的最重要的办法是抽象，因此，对一个复杂的问题不应该立刻用计算机指令、数字和逻辑符号来表示，而应该用较自然的抽象语句来表示，从而得出抽象程序。

抽象程序对抽象的数据进行某些特定的运算并用某些合适的记号（可能是自然语言）来表示。对抽象程序做进一步的分解，并进入下一个抽象层次，这样的精细化过程一直进行下去，直到程序能被计算机接受为止。这时的程序可能是用某种高级语言或机器指令书写的。

四、信息隐藏和局部化

信息隐藏：应该这样设计和确定模块，使得一个模块内包含的信息(过程和数据)对于不需要这些信息的模块来说，是不能访问的。

局部化：局部化的概念和信息隐藏概念是密切相关的。所谓局部化是指把一些关系密切的软件元素物理地放得彼此靠近。显然，局部化有助于实现信息隐藏。 

信息隐藏和局部化的作用：

“隐藏”意味着有效的模块化可以通过定义一组独立的模块而实现，这些独立的模块彼此间仅仅交换那些为了完成系统功能而必须交换的信息。

使用信息隐藏原理作为模块化系统设计的标准就会带来极大好处。因为绝大多数数据和过程对于软件的其他部分而言是隐藏的，在修改期间由于疏忽而引入的错误就很少可能传播到软件的其他部分。 

五、模块独立

模块独立的概念是模块化、抽象、信息隐藏和局部化概念的直接结果。希望这样设计软件结构，使得每个模块完成一个相对独立的特定子功能，并且和其他模块之间的关系很简单。 

模块独立的重要性：

有效的模块化(即具有独立的模块)的软件比较容易开发出来。这是由于能够分割功能而且接口可以简化，当许多人分工合作开发同一个软件时，这个优点尤其重要。

独立的模块比较容易测试和维护。这是因为相对说来，修改设计和程序需要的工作量比较小，错误传播范围小，需要扩充功能时能够“插入”模块。

模块独立程度的两个定性标准度量：

耦合衡量不同模块彼此间互相依赖(连接)的紧密程度。耦合要低，即每个模块和其他模块之间的关系要简单；

内聚衡量一个模块内部各个元素彼此结合的紧密程度。内聚要高，每个模块完成一个相对独立的特定子功能。 

1. 耦合

耦合：是对一个软件结构内不同模块之间互连程度的度量。

要求：在软件设计中应该追求尽可能松散耦合的系统。

可以研究、测试或维护任何一个模块，而不需要对系统的其他模块有很多了解；

模块间联系简单，发生在一处的错误传播到整个系统的可能性就很小；

模块间的耦合程度强烈影响系统的可理解性、可测试性、可靠性和可维护性。 

耦合程度的度量：

(1) 非直接耦合/完全独立(no direct coupling)

如果两个模块中的每一个都能独立地工作而不需要另一个模块的存在，那么它们完全独立。

在一个软件系统中不可能所有模块之间都没有任何连接。

(2) 数据耦合(data coupling)

如果两个模块彼此间通过参数交换信息，而且交换的信息仅仅是数据，那么这种耦合称为数据耦合。

评价：

■系统中至少必须存在这种耦合。一般说来，一个系统内可以只包含数据耦合。

■数据耦合是理想的目标。

■维护更容易，对一个模块的修改不会是另一个模块产生退化错误。 

(3) 控制耦合(control coupling)

如果两个模块彼此间传递的信息中有控制信息，这种耦合称为控制耦合。 

评价：

■控制耦合往往是多余的，把模块适当分解之后通常可以用数据耦合代替它。

■被调用的模块需知道调用模块的内部结构和逻辑，降低了重用的可能性 。

(4) 特征耦合(stamp coupling)

当把整个数据结构作为参数传递而被调用的模块只需要使用其中一部分数据元素时，就出现了特征耦合。

评价：

■被调用的模块可使用的数据多于它确实需要的数据，这将导致对数据的访问失去控制，从而给计算机犯罪提供了机会。

■无论何时把指针作为参数进行传递，都应该仔细检查该耦合。

(5) 公共环境耦合(common coupling)

当两个或多个模块通过一个公共数据环境相互作用时，它们之间的耦合称为公共环境耦合。公共环境可以是全程变量、共享的通信区、内存的公共覆盖区、任何存储介质上的文件、物理设备等等。

公共环境耦合的类型： 

一个模块往公共环境送数据，另一个模块从公共环境取数据。数据耦合的一种形式，是比较松散的耦合。

两个模块都既往公共环境送数据又从里面取数据，这种耦合比较紧密，介于数据耦合和控制耦合之间。

例：

while(global_bariable==0)

{

     if (argument_xyz>25)

         module_3();

     else

         module_4();

}

评价：

■与结构化编程矛盾，生成的代码完全不可读。

■如果在一个模块中对一个全局变量的声明进行修改，必须修改能够访问该全局变量的每一个模块。

■公共环境耦合的模块难于重用，必须提供一个全局变量的清单。

■即使模块本身不改变，它和产品中其他模块之间公共环境耦合的实例数也会变化非常大。

■潜在危险很大。模块暴露出必需要更多的数据，难以控制数据存取，而且会导致计算机犯罪。

■有些情况下公共环境耦合更好。 

(6) 内容耦合(content coupling)

最高程度的耦合是内容耦合。如果出现下列情况之一，两个模块间就发生了内容耦合：

■一个模块访问另一个模块的内部数据；

■一个模块不通过正常入口转到另一个模块的内部；

■两个模块有一部分程序代码重叠；

■一个模块有多个入口。 

总结

耦合是影响软件复杂程度的一个重要因素。

应该采取下述设计原则：

1、尽量使用数据耦合。

2、少用控制耦合和特征耦合。

3、限制公共环境耦合的范围。

4、完全不用内容耦合。

2. 内聚

内聚：标志一个模块内各个元素彼此结合的紧密程度，它是信息隐藏和局部化概念的自然扩展。简单地说，理想内聚的模块只做一件事情。

要求：设计时应该力求做到高内聚，通常中等程度的内聚也是可以采用的，而且效果和高内聚相差不多；但是，低内聚不要使用。

内聚和耦合是密切相关的，模块内的高内聚往往意味着模块间的松耦合。实践表明内聚更重要，应该把更多注意力集中到提高模块的内聚程度上。 

内聚程度的度量：

(1) 偶然内聚(coincidental cohesion)

如果一个模块完成一组任务，这些任务彼此间即使有关系，关系也是很松散的，就叫做偶然内聚。

评价：

■模块内各元素之间没有实质性联系，很可能在一种应用场合需要修改这个模块，在另一种应用场合又不允许这种修改，从而陷入困境；

■可理解性差，可维护性产生退化；

■模块是不可重用的。

解决方案：

将模块分成更小的模块，每个小模块执行一个操作。

(2) 逻辑内聚(logical cohesion)

如果一个模块完成的任务在逻辑上属于相同或相似的一类，则称为逻辑内聚。

评价：

■接口难以理解，造成整体上不易理解；

■完成多个操作的代码互相纠缠在一起，即使局部功能的修改有时也会影响全局，导致严重的维护问题；

难以重用。

解决方案：

模块分解。 

(3) 时间内聚(temporal cohesion)

如果一个模块包含的任务必须在同一段时间内执行，就叫时间内聚。

评价：

■时间关系在一定程度上反映了程序某些实质，所以时间内聚比逻辑内聚好一些。

■模块内操作之间的关系很弱，与其他模块的操作却有很强的关联。

■时间内聚的模块不太可能重用。 

(4) 过程内聚(procedural cohesion)

如果一个模块内的处理元素是相关的，而且必须以特定次序执行，则称为过程内聚。

使用程序流程图作为工具设计软件时，常常通过研究流程图确定模块的划分，这样得到的往往是过程内聚的模块。 

评价：

■比时间内聚好，至少操作之间是过程关联的。

■仍是弱连接，不太可能重用模块。

解决方案：

分割为单独的模块，每个模块执行一个操作。

(5) 通信内聚(communicational cohesion)

如果模块中所有元素都使用同一个输入数据和(或)产生同一个输出数据，则称为通信内聚。即在同一个数据结构上操作。

评价：

■模块中各操作紧密相连，比过程内聚更好。

■不能重用。

解决方案：

分成多个模块，每个模块执行一个操作。

(6) 顺序内聚(sequential cohesion)

如果一个模块内的处理元素和同一个功能密切相关，而且这些处理必须顺序执行，则称为顺序内聚。

评价：

根据数据流图划分模块时，通常得到顺序内聚的模块，这种模块彼此间的连接往往比较简单。 

(7) 功能内聚(functional cohesion)

如果模块内所有处理元素属于一个整体，完成一个单一的功能，则称为功能内聚。功能内聚是最高程度的内聚。

评价：

■模块可重用，应尽可能重用；

■可隔离错误，维护更容易；

■扩充产品功能时更容易。

七种内聚的优劣评分结果：

高内聚：功能内聚     10分

              顺序内聚    9分

中内聚：通信内聚    7分

             过程内聚    5分

低内聚：时间内聚    3分

             逻辑内聚    1分

             偶然内聚    0分

设计时力争做到高内聚，并且能够辨认出低内聚的模块。