系统就是问题域，系统划分过程就是对问题分解过程。实际设计中经常根据业务分类（目的职责环节职能）的划分模块，比如客户有很多个部门，每个部门用的功能放在一个模块中，这样设计的好处是业务部门容易上手。
模块划分依据：http://www.ibm.com/developerworks/cn/rational/1312_wanggb_arch/
所谓模块独立性即：不同模块相互之间的联系尽可能少，尽可能减少公共的变量和数据结构。每个模块尽可能的在逻辑上独立，功能上完整单一，数据上与其他模块无太多的耦合
模块独立性的度量：高内聚低耦合，数据接口简单，可扩展可维护可复用，结构精简。
模块独立性的度量之一：内聚性
一个模块内部各成分之间相互关联的强度。
设计目标：高内聚（一个模块的所有成分都直接参与 并县城对于完成同一功能来说都是最基本的）
内聚性越高，模块独立性越强，由低向高的内聚方式为：
巧合内聚
逻辑内聚
时间内聚
过程内聚
通信内聚
信息内聚
功能内聚
（1）巧合内聚
模块内各分部间无联系， 例：
view source
print?
1 MOVE O TO R
2 READ FILE F
3 MOVE S TO T
模块中的三个语句没有任何联系，
缺点：可理解性差， 可修改性差。
（2）逻辑内聚
把几种相关功能（逻辑上相似的功能）组合在一模块内， 每次调用由传给模块的参数确定执行哪种功能。
缺点：增强了耦合程序（控制耦合），不易修改，效率低
（3）时间内聚
模块完成的功能必须在同一时间内执行，这些功能只因时间因素关联在一起。如
初始化系统模块
系统结束模块
紧急故障处理模块
（4）过程内聚
模块内各处理成分相关，且必须以特定次序执行
（5）通信内聚
模块内各部分使用相同的输入数据，或产生相同的输出结果
（6）信息内聚
信息内聚指模块写成多个功能，各个功能都在同一数据结构上操作，每个功能有唯一入口。如对同一个数据库的查找-添加-删除-修改模块
（7）功能内聚
模块仅包括为完成某个功能所必须的所有成分（模块所有成分共同完成一个功能，缺一不可）
模块独立性的度量之二
耦合性是模块间相互依赖程度的度量，耦合的强弱取决于模块间接口的复杂程度，进入或访问一个模块的点，以及通过接口的数据
耦合性越高，模块独立性越弱， 耦合强度依赖的因素：
一模块对另一模块的引用
一模块向另一模块传递的数据量
一模块施加到另一模块的控制数量
模块间接口的复杂度
（1）非直接耦合
两个模块没有直接关系，模块独立性最强。
（2）数据耦合
一个模块调用另一模块时，被调用模块的输入输出都是简单的数据，性松散耦合
（3）标记耦合
如两个模块通过传递数据结构（不是简单的数据，而是记录，数组等）加以联系，或都与一个数据结构有关系，则称这两个模块间存在标记耦合
信息情况是一个数据结构，图中模块都与此数据结构产生依赖关系，它们之间也是标记耦合
（4）控制耦合
一模块通过开关量、标志、名字等控制信息，明显地控制另一模块
控制耦合增加了理解和编程的复杂性，调用模块必须知道被调用模块的内部逻辑，增加了相互依赖
去除模块间控制耦合的方法：
1）将被调用模块内的判定上移到调用模块中进行
2）被调用模块分解成若干单一功能模块。
（5）外部耦合
一组模块均与同一外部环境关联（例如： I/O模块与特定的设备、模式和通信 协议关联），它们之间便存在外部耦合。
外部耦合必不可少，但是这种模块数目应尽量少。
（6）公共耦合
一组模块引用同一个共用数据区（也称全局数据区，公共数据环境）
公共数据区指：
全局数据结构
共享通讯区
内存公共覆盖区等
公共耦合存在的问题：
软件可理解性降低: 模块间存在错综复杂的联系
软件可维护性差： 修改变量名或属性困难
软件可靠性差： 公共数据区及全程变量无保护措施
慎用公共数据区和全程变量
（7）内容耦合
一模块直接访问另一模块的内部信息（程序代码或数据），最不好的内容耦合形式
发生内容耦合的情形：
一模块直接访问另一模块的内部数据
一模块不通过正常入口转到另一模块内
两模块有一部分代码重叠
一模块有多个入口
如何降低耦合度？
1）如模块必须存在耦合，选择适当的耦合类型
原则：
尽量使用数据耦合
少用控制耦合
限制公共耦合的范围
坚决避免使用内容耦合
2）降低模块间接口的复杂性。
http://m.blog.csdn.net/article/details?id=50121411
http://blog.csdn.net/lyc_daniel/article/details/9212235
http://www.csframework.com/cs-framework-intro.htm
http://www.cnblogs.com/kzloser/archive/2012/07/06/2578960.html