13.1 系统设计基本原理
- 抽象：面向对象的基本
- 模块化：将一个待开发的软件分解为若干个简单的小模块；
- 信息隐蔽：封装
- 模块独立：每个模块完成一个相对独立的特定子功能，并且与其他模块之间的联系简单。衡量模块独立程度的标准：耦合性和内聚性；
13.1.1 耦合性
耦合是模块之间的相对独立性的度量，耦合取决于各模块之间接口的复杂程度、调用模块的方式和通过接口的信息类型等；
| 耦合分类 | 定义 | 关键字 |
|---|---|---|
| 无直接耦合 | 两个模块之间没有直接的关系，它们分别从属于不同模块的控制与调用，不传递任何信息 | 无直接关系 |
| 数据耦合 | 两个模块之间有调用关系，传递的是简单的数据值，相当于高级语言中的值传递 | 传递数据值调用 |
| 标记耦合 | 两个模块之间传递的是数据结构 | 传递数据结构 |
| 控制耦合 | 一个模块调用另一个模块时，传递的是控制变量，被调用模块通过该控制变量的值有选择的执行模块内的某一功能 | 控制变量、选择执行某一功能 |
| 外部耦合 | 模块间通过软件之外的环境联合（如I/O将模块耦合到特定的设备、格式、通信协议上）时 | 软件外部环境 |
| 公共耦合 | 通过一个公共数据环境相互作用的那些模块间的耦合 | 公共数据结构 |
| 内容耦合 | 当一个模块直接使用另一个模块的内部数据，或通过非正常入口转入另一个模块内部时 | 模块内部关联 |
13.1.2 内聚性
内聚是对一个模块内部各个元素彼此结合的紧密程度的度量；一个内聚程度高的模块应当只做一件事。
| 内聚分类 | 定义 | 关键字 |
|---|---|---|
| 偶然内聚 | 一个模块内的各处理元素之间没有任何联系 | 无直接关系 |
| 逻辑内聚 | 模块内执行若干个逻辑上相似的功能，通过参数确定该模块完成哪一个功能 | 逻辑相似、参数决定 |
| 时间内聚 | 把需要同时执行的动作组合在一起形成的模块 | 同时执行 |
| 过程内聚 | 一个模块完成多个任务，这些任务必须按指定的过程执行 | 指定的过程顺序 |
| 通信内聚 | 模块内的所有处理元素都在同一个数据结构上操作，或者各处理使用相同的输入数据或者产生相同的输出数据 | 相同数据结构、相同输入输出 |
| 顺序内聚 | 一个模块中的各个处理元素都密切相关于同一功能且必须顺序执行，前一个功能元素的输出就是下一个功能元素的输入 | 顺序执行、输入为输出 |
| 功能内聚 | 最强的内聚，模块内的所有元素共同作用完成一个功能，缺一不可 | 共同作用、缺一不可 |
13.1.3 设计原则
13.1.3.1 系统结构设计原则
(9) 模块的作用范围应该在其控制范围内；
(10)减少或避免使用病态连接(从中部进入或访问一个模块)。
13.1.3.2 子系统划分的原则
- 子系统要具有相对独立性
- 子系统之间数据的依赖性尽量小
- 子系统划分的结果应使数据冗余较小
- 子系统的设置应考虑今后管理发展的需要
- 子系统的划分应便于系统分阶段实现
- 子系统的划分应考虑到各类资源的充分利用
13.1.4 系统文档
- 用户与系统分析人员在系统规划和系统分析阶段通过文档进行沟通。这里的文档主要包括可行性研究报告、总体规划报告、系统开发合同和系统方案说明书等。有了文档，用户就能依次对系统分析师是否正确理解了系统的需求进行评价，如不正确，可以在已有文档的基础上进行修正。(项目开发计划=系统开发合同+系统方案说明书)；
- 系统开发人员与项目管理人员通过文档在项目期内进行沟通。这里的文档主要有系统开发计划(包括工作任务分解表、PERT图、甘特图和预算分配表等)、系统开发月报以及系统开发总结报告等项目管理文件。有了这些文档，不同阶段之间的开发人员就可以进行工作的顺利交接，同时还能降低因为人员流动带来的风险，因为接替人员可以根据文档理解前面人员的设计思路或开发思路。
- 系统测试人员与系统开发人员通过文档进行沟通。系统测试人员可以根据系统方案说明书、系统开发合同、系统设计说明书和测试计划等文档对系统开发人员所开发的系统进行测试。系统测试人员再将评估结果撰写成系统测试报告。
- 系统开发人员与用户在系统运行期间进行沟通。用户通过系统开发人员撰写的文档运行系统。这里的文档主要是用户手册和操作指南。
- 系统开发人员与系统维护人员通过文档进行沟通。这里的文档主要有系统设计说明书和系统开发总结报告、有的开发总结报告写得很详细，分为研制报告、技术报告和技术手册3个文档，其中的技术手册记录了系统开发过程中的各种主要技术细节。这样，即使系统维护人员不是原来的开发人员，也可以在这些文档的基础上进行系统的维护与升级。
- 用户与维修人员在运行维护期间进行沟通。用户在使用信息系统的过程中，将运行过程中的问题进行记载，形成系统运行报告和维护修改建议。系统维护人员根据维护修改建议以及系统开发人员留下的技术手册等文档对系统进行维护和升级。
13.1.4 数据字典(DD)
13.1.4.1 数据字典的内容
数据字典有4类条目：数据流、数据项、数据存储、数据加工；数据项是数据流和数据存储的最小元素；源点、终点不再系统之内，故一般不再数据字典内。数据字典不包括外部实体。
13.1.4.2 加工逻辑的描述
加工逻辑也称为“小说明常用的加工逻辑描述方法有结构化语言、判定表和判定树3种。
13.1.5 其他
- 利用结构化分析模型进行接口设计时，应以数据流图(DFD)为依据。
- 根据加工规格说明和控制规格说明进行过程设计；根据数据字典和实体关系图进行数据设计；根据数据流图进行接口设计；根据数据流图进行体系结构设计。
- 数据流图中某个加工的一组动作依赖于多个逻辑条件的取值，则用决策树能够清楚地表示复杂的条件组合与应做的动作之间的对应关系。
- 结构化分析模型包括数据流图、实体联系图、状态迁移图和数据字典。
- 结构化设计主要包括：①体系结构设计：定义软件的主要结构元素及其关系。②数据设计：基于实体联系图确定软件涉及的文件系统的结构及数据库的表结构。③接口设计：描述用户界面，软件和其他硬件设备、其他软件系统及使用人员的外部接口，以及各种构件之间的内部接口。依据主要为数据流图。④过程设计：确定软件各个组成部分内的算法及内部数据结构，并选定某种过程的表达形式来描述各种算法。
- 数据流图建模应遵循自顶向下、从抽象到具体的原则。
- 模块结构图由模块、调用、数据、控制信息和转接符号5种基本符号组成。
- Theo Mandel 在其关于界面设计的著作中提出了3条“黄金原则”：用户操纵控制；减少用户的记忆负担；保持界面一致。
- 结构化分析输出包括：数据流图、数据字典、加工逻辑。
- 对于数据处理领域的问题，若系统规模不是很大且不是很复杂，需求变化也不是很大，则最适合采用结构化开发方法；
