分解（decomposition）
C（P1+P2）> C（P1）+C（P2）
E（P1+P2）> E（P1）+E（P2）
C为问题的复杂程度，E为解题需要的工作量
关于模块的一些概念
深度：系统结构中的控制层数
宽度：同一层次的模块总数的最大值
扇入&扇出：如图所示
作用范围：受到该模块内部一个判定影响的所有模块的集合（同样包括控制范围以外的模块）
控制范围：包括该模块本身及所有下属模块的集合
（优化原则：作用范围应该在控制范围内）
模块独立性（module independence）
内聚（cohesion）
模块内部各成分之间
单个模块内部
内聚程度由低到高可分类为：
偶然性内聚 coincidental cohesion
模块中所要完成的各个动作之间没有任何关系
eg：一些重复用到的语句，为了方便组成一个模块
逻辑性内聚 logical cohesion
模块中的各个组成部分在逻辑上具有相似的处理动作，但功能上，用途上却彼此无关。
eg：输出各种报表的操作放入一个模块中实现
时间性内聚 temporal cohesion
模块中所包含的各个处理动作必须在同一时间内执行
eg：初始化模块
过程性内聚 procedural cohesion
模块内各个成分彼此相关，并且按照特定的次序执行
eg：由程序流程图直接演变而来的模块
通讯性内聚 communicational cohesion
模块中的各个成分都对数据结构的同一区域进行操作，以达到通信的目的
eg：模块内各个动作都使用同一个输入数据或者产生同一个输出数据
顺序性内聚 sequential cohesion
模块内各个处理成分都与同一个功能相关，并且这些处理必须顺序执行
eg：前一部分处理动作的输出是后一部分处理动作的输入
与过程性内聚区分：
模块内动作是否围绕同一个功能。
功能性内聚 functional cohesion
模块内所有成分形成一个整体，完成单个的功能
eg：单一目的，单一功能，界面清楚（比如求平方根模块）
评价标准
联接形式、可修改性、可读性、通用性、联系程度
耦合（coupling）
一个模块与其它模块之间
多个模块之间
由耦合度低到高可分类为：
非直接耦合 no direct coupling
两个模块中的任何一个都不依赖于对方能够独立工作
数据耦合 data coupling
两个模块通过参数传递信息，信息仅限于数据（这个参数并不影响程序流程）
特征耦合 stamp coupling
模块间通过参数传递复杂的数据据结构，（复杂数据结构超出接收模块的最大需要）
此数据结构的变化将使相关的模块发生变化。
这种耦合介于数据耦合与控制耦合
控制耦合 control coupling
两个模块通过参数传递信息，信息中包含控制
外部耦合 external coupling
多个模块与同一个外部环境关联
eg：多个I/O模块与特定的设备、格式和通信协议相关联
公共耦合 common coupling
多个模块通过全局的数据环境相互作用。
全局数据环境包括：全局变量、公共区、内存公共覆盖区、任何存储介质上的文件、物理设备。
内容耦合 content coupling
一个模块使用另一个模块的内部数据或者控制信息；一个模块直接转移到另外一个模块内部。
基于耦合的设计原则
- 尽量使用数据耦合
- 减少使用控制耦合
- 限制外部环境耦合和公共耦合
- 杜绝内容耦合
模块独立性高
模块内联系强/模块内聚合大
模块间联系弱/模块间耦合小
文章内所有图片均来自于网络
体系结构设计优化的指导规则
设计阶段早期应该对程序结构多做精化和评估以达到最好
便于优化是开发软件体系结构表示的一个重要因素
结构上的简单往往反映出程序的优雅和高效
设计优化应在满足模块化要求的前提下尽量减少模块数量（每个模块内代码行数尽量控制在60行）
在满足信息需求的前提下尽量减少复杂的数据结构
对模块分割、合并和变动调用关系的指导规则：
- 提高内聚先，降低耦合后
- 简化模块接口
- 少用全局性数据和控制型信息
保持高扇入/低扇出的原则
作用域/控制域规则：
- 作用域不要超出控制域的范围
- 位置离受它控制的模块越近越好
对于性能要求高的应用，有时需要进行如下的工作：
- 开发和精化程序结构，且不考虑关键性能而进行的优化
- 使用可以提高运行性能的CASE工具来孤立低效的部分
- 在后期设计中，对有可能最消耗时间的模块的算法进行时间优化
- 用适当的程序设计语言编码
- 孤立出那些大量占用处理器时间的模块
- 如果需要，用依赖机器的语言重新设计和编码，以提高效率
先使其工作起来，再设法使其更好地工作
