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