需求分析与设计：模块的划分

模块划分应遵循的准则：
高内聚低偶合
模块大小规模适当
模块的依赖关系适当等

大型软件项目开发中，模块的划分非常的重要！一般来说，模块在功能上尽可能单一和明确化，最好做到模块与目标的一一对应。模块间的联系应尽可能少，对于必须的联系都应该有明确的说明，模块应足够小，以方便单个模块的调试。

从模块划分的视角优化架构:
http://blog.csdn.net/zengjibing/archive/2009/02/13/3888747.aspx

引用

对初步的架构轮廓作第二个方面的审视，是考虑模块化的设计问题。也就是从架构的组
成单元来说，定义清楚子系统以后，下一步就是定义模块。
1，模块化设计的概念
如何合理的进行模块设计呢？这里的关键是要保证模块的独立性。
模块：模块是数据说明、可执行语句等程序对象的集合，是单独命名的并且可以通过名
字来访问，例如过程、函数、子程序、宏等。
模块化：软件被划分成独立命名和可独立访问的被称作模块的构件，每个模块完成一个
子功能，它们集成到一起可以满足问题需求。
利用模块化解决方案的注意事项：
一般来说，倾向于每个用户描述定义一个模块。我们应该努力使每个模块的大小差
别在一个数量级之内。如果发现某个模块规模太大，就需要实现模块切割，然后针
对这种切割的结果，反过来修改需求分析的时候用户描述（或者用例）的表达方式。
这就是由设计引发的需求变更。
模块的大小一般以一个开发团队在一次迭代时间内能完成为好。模块切割方法与开
发成本有关。我们可以这样来思考模块化对软件工作量和成本的影响。实际的情况
见下图， 随着模块数量的增加，开发成本减低，但是系统集成的成本增加，所以
最小成本的区域在一个合适的区间。也就是说，模块并不是越多越好，只有模块数
量适当的时候，总体成本才可能下降。
2，实现模块化的手段
抽象：抽出事物的本质特性而暂时不考虑它们的细节。
信息隐蔽：应该这样设计和确定模块，使得一个模块内包含的信息（过程和数据）
对于不需要这些信息的模块来说，是不可访问的。
模块独立性问题：
模块独立是指开发具有独立功能而且和其它模块之间没有过多的相互作用的模块。
模块独立的意义：
1）功能分割，简化接口，易于多人合作开发同一软件；
2）独立的模块易于测试和维护。
模块独立程度的衡量标准：
1）耦合性：对一个软件结构内不同模块间互连程度的度量。
2）内聚性：标志一个模块内各个处理元素彼此结合的紧密程度，理想的内聚模块只
做一件事情。
3，模块化设计的一般准则
改进软件结构，提高模块独立性。
模块规模应该适中。大模块分解不充分；小模块使用开销大，接口复杂。
尽量减少高扇出结构的数目，随着深度的增加争取更多的扇入。扇出过大意味着模
块过分复杂，需要控制和协调过多的下级模块。一般来说，顶层扇出高，中间扇出
少，低层高扇入。
模块的作用范围保持在该模块的控制范围内。模块的作用范围是指该模块中一个判
断所影响的所有其它模块；模块的控制范围指该模块本身以及所有直接或间接从属
于它的模块。
力争降低模块接口的复杂程度模块接口的复杂性是引起软件错误的一个主要原因。
接口设计应该使得信息传递简单并且与模块的功能一致。
设计单入口单出口的模块，以避免内容耦合，易于理解和维护。
模块的功能应该可以预测。相同的输入应该有相同的输出，否则难以理解、测试和
维护。

该博客引申：
从质量属性及其应对策略的视角优化架构 ：
http://blog.csdn.net/zengjibing/archive/2009/02/13/3888736.aspx
从共享分层结构的视角优化架构：
http://blog.csdn.net/zengjibing/archive/2009/02/13/3888755.aspx
从软件复用与构件化的视角优化架构：
http://blog.csdn.net/zengjibing/archive/2009/02/13/3888759.aspx

软件架构设计的流程：
http://blog.csdn.net/zengjibing/archive/2009/02/13/3888760.aspx