模块化

信息隐藏

· 容易被改动的区域

1． 识别出那些可能被改动的地方。如果分析工作做得很好的话，其中应该附有可能改动的地方和改动内容的明细表。在这种情况下，找出可能的改动是非常容易的。如果需求分析中没有进行这项工作，可以参阅下面关于在任何项目中都可能被改动的区域的讨论。
2． 把可能被改动的地方分离出来。把第一步中发现的每一个可能改动的地方分隔到自己的模块中，或者将其与其它可能一起被改动的要素一起，独立到一个模块中。
3． 独立可能被改动的地方。应把模块间的接口设计成对可能变动不敏感，同时，接口应该把变动限制在模块内部，外部不会受到内部变动影响。而其它调用这个被改动过模块的模块，不应感受到这个模块被修改过。模块的接口应该能保护模块的隐私权。

以下是一些可能变动的区域：
对硬件有依赖的地方。
输入和输出。
非标准语言特性。
难于设计和实现的域。
状态变量。
数据规模限制。
商业规则。
预防到改动。
· 复杂的数据
· 复杂的逻辑
· 在编程语言层次上的操作

检查表  模块的质量
· 模块是否有一个中心目的？
· 模块是否是围绕着一组公用数据进行组织的？
· 模块是否提供了一套相互联系的功能？
· 模块功能是否足够完备，从而使得其它模块不必干预其内部数据？
· 一个模块相对其它模块是否是独立的？它们之间是松散耦合的吗？
· 一个模块的实现细节，对其它模块来说，是隐含的吗？
· 模块的接口是否抽象到了不必关心其功能实现方式的地步？它是作为一个黑盒子来设计的吗？
· 是否考虑过把模块再划分为单元模块？是否对其进行了充分的再划分工作？
· 如果用不完全支持模块的语言编程，你是否制定了编程约定以使这种语言支持模块？