11.1系统设计的基本原理
11.1.1 抽象
11.1.3 信息隐蔽(封装)
- 无直接耦合。指两个模块之间没有直接的关系,它们分别从属于不同模块的控制与调用,它们之间不传递任何信息。因此,模块间耦合性最弱,模块独立性最高。
- 数据耦合。指两个模块之间有调用关系,传递的是简单的数据值,相当于高级语言种的值传递
- 标记耦合。指两个模块之间传递的是数据结构。
- 控制耦合。指一个模块调用另一个模块时,传递的是控制变量,被调用模块通过该控制变量的值有选择地执行模块内的某一功能。因此,被调用模块应具有多个功能,哪个功能起作用哪个功能受调用模块控制(eg:switch-case语句)
- 外部耦合。模块间通过软件之外的环境联结(如I/O将模块耦合到特定的设备、格式、通信协议上)时称为外部耦合。
- 公共耦合。指通过一个公共数据环境相互作用的那些模块间的耦合。
- 内容耦合。当一个模块直接使用另一个模块的内部数据,或通过非正常入口转入另一个模块内部时,这种模块之间的耦合称为内容耦合。
2.内聚性
内聚是对一个模块内部各个元素彼此结合的紧密程度的度量。一个内聚程度高的模块(在理想情况下)应当只做一件事。一般模块的内聚性分为7种类型。
- 用户与系统分析人员在系统规划和系统分析阶段通过文档进行沟通。这里的文档主要包括可行性研究 告、总体规划 告、系统开发合同和系统方案说明书等。有了文档,用户就能依次对系统分析师是否正确理解了系统的需求进行评价,如不正确,可以在已有文档的基础上进行修正。(项目开发计划=系统开发合同+系统方案说明书)
- 系统开发人员与项目管理人员通过文档在项目期内进行沟通。这里的文档主要有系统开发计划(包括工作任务分解表、PERT图、甘特图和预算分配表等)、系统开发月 以及系统开发总结 告等项目管理文件。有了这些文档,不同阶段之间的开发人员就可以进行工作的顺利交接,同时还能降低因为人员流动带来的风险,因为接替人员可以根据文档理解前面人员的设计思路或开发思路
- 系统测试人员与系统开发人员通过文档进行沟通。系统测试人员可以根据系统方案说明书、系统开发合同、系统设计说明书和测试计划等文档对系统开发人员所开发的系统进行测试。系统测试人员再将评估结果撰写成系统测试 告
- 系统开发人员与用户在系统运行期间进行沟通。用户通过系统开发人员撰写的文档运行系统。这里的文档主要是用户手册和使用指南
- 用户与维修人员在运行维护期间进行沟通。用户在使用信息系统的过程中,将运行过程中的问题进行记载,形成系统运行 告和维护修改建议。系统维护人员根据维护修改建议以及系统开发人员留下的技术手册等文档对系统进行维护和升级
11.4.数据流图(DFD;对功能建模)
数据流图也称数据流程图(Data Flow Diagram ,DFD),它是一种便于用户理解、分析系统数据流程的图形化工具。它摆脱了系统的物理内容,精确地在逻辑上描述系统的功能、输入、输出和数据存储等,是系统逻辑模型的重要组成部分
11.4.1 数据流图的基本图形元素
在试卷上的图中要认准字母:;因为可能图中使用的图形并不是我们认知里的图形,但是字母一定是准确的
11.5 数据字典(DD)
数据流图描述了系统的分解,但没有对图中各成分进行说明。数据字典就是为数据流图中的每个数据流、文件、加工,以及组成数据流或文件的数据项做出说明。其中,对加工的描述称为“小说明”,也可以称为“加工逻辑说明”。
11.5.1 数据字典的内容(了解)
数据字典有以下4类条目:。数据项是组成数据流和数据存储的最小元素。源点(外部实体)、终点(外部实体)不在系统之内,故一般不在字典中说明。
1.数据流条目。
数据流条目给出了DFD中数据流的定义,通常列出该数据流的各组成数据项。在定义数据流或数据存储组成时,使用下表给出的符
结构化方法采用的是 逐层分解的思想进行分析建模的。自顶向下逐层分解充分体现了分解和抽象的原则。随着分解层次的增加,抽象的级别也越来越低,即越来越接近问题的解。
结构化方法的分析结果由以下几部分组成:一套分层的数据流图、一本数据字典、一组小说明(也称加工逻辑说明)、补充材料。
决策树和决策表适于用来表示加工中涉及多个逻辑条件的情况。
结构图的基本成分包括模块、调用和数据。
Theo Mandel提出了3条“黄金原则”:用户操纵控制;减少用户记忆负担;保持界面一致
构造分成DFD时需要注意的问题:
- 适当命名
- 画数据流而不是控制流
- 避免一个加工有过多的数据流
- 分解尽可能均匀
- 先考虑确定状态,忽略琐碎的处理
- 随时准备重画
声明:本站部分文章及图片源自用户投稿,如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢!