4.2 软件结构设计准则

• 软件体系结构设计准则
  • 普通适用
    • 能够描述各种风格的软件系统结构，可以高效地处理多种多样的个体需求。
  • 在一定的时间内保持稳定
    • 确保接口一致，既能确保某一体系结构配置描述内相关接口描述的一致，又能确保建立关联的两个构件接口描述的一致性。
  • 普通、高效和稳定
• 软件模块设计准则
  1. 降低模块之间的耦合性，提高模块的内聚性；
     • 通过模块分解或合并，降低耦合提高内聚。
  2. 模块结构的深度、宽度、扇出和扇入应适当；
     • 深度：软件结构中模块的层数；
       1. 标识系统的规模和复杂程度。
     • 宽度：软件结构中同一层次上模块的最大个数。
       1. 宽度越大的系统越复杂
     • 扇出：一个模块直接调用的模块数目。
       1. 扇出过大意味着模块过分复杂；
       2. 扇出过小意味着功能过度集中；
       3. 好的系统结构的平均扇出数一般是3-4，上限5-9。
     • 扇入：有多少个上级模块直接调用它。
     • 不违背模块独立性的条件下，扇入越大越好。
     • 一般设计的比较好的软件结构，顶层扇出高，中层扇出较少，底层模块有高扇入。
  3. 模块的作用范围应该在控制范围内；
     • 模块的作用范围：指受该模块内一个判断影响的所有模块的集合；
     • 模块的控制范围：指模块本身以及其所有直接或者间接从属于它的模块集合；
     • 在设计的好的软件结构中，所有受判断影响的模块都从属于作出判断的那个模块，最好局限于做出判定的那个模块本身及它的直属下级模块。
  4. 模块接口设计要简单，以便降低复杂程度和冗余度；
     • 模块接口复杂是软件发生错误的一个主要原因，应该仔细设计模块接口，使得信息传递简单并且和模块的功能一致。
  5. 设计功能可预测并能得到验证的模块；
     • 功能可预测：如果一个模块可以当作一个黑盒子，只要输入的数据相同就产生同样的输出，这个模块的功能就是可以预测的。
     • 模块的功能应该能够预测，但也要防止模块功能过分局限。
     • ![[Pasted image 20230608164807.png]]
  6. 适当划分模块规模，以保持其独立性。
     • 经验表明，一个模块的规模不应过大，最好能写在一页纸内。通常规定50-100行语句，最多不超过500行。
     • 过大的模块往往是由于分解不充分，但是进一步分解必须符合问题结构，一般说来，分解后不应该降低模块独立性。
     • 过小的模块开销大于有效操作，而且模块数目过多将使系统接口复杂。
     • 解决方法：
       1. 进一步分解过大的模块
       2. 将频繁调用的小模块合并到上级模块中
  • 以上介绍的软件结构设计准则是人们经过长期的软件开发实践总结出来的；
  • 但是这些准则不是设计的目标，也不是在设计时必须普遍遵循的原理。
  • 在实际应用时，应根据系统的大小、难易程度加以灵活应用