软件工程(七)

软件设计的任务

软件实现主要任务

将软件详细设计的结果转换为目标软件。

从提高目标软件的质量和可维护性角度，此阶段所要解决的主要问题：软件实现的过程、任务、原则及策路，编程语言的特性及选择的原则和编程风格等。

软件编程的任务

是对详细设计的工作进行具体实现，形成计算机可运行的程序。设计与实现有时是相互交替、循环迭代的过程，即软件设计可能贯穿于整个软件开发过程，个别详细设计细节在实现阶段才最后完成。

软件实现工作量

根据具体研发软件系统项目的性质、规模和复杂程度不同,占整个开发过程约30%-40%工作量。

鲁棒性

软件对规范要求以外的输入情况的处理能力。

健壮系统指对规范要求以外的输入能够检测是否符合规范要求，并有合理处理方式

程序设计风格

定义

书写源程序的习惯、程序代码的逻辑结构与习惯的编程技术。

要素

1. 源程序文档化
2. 数据说明
3. 语向构造
4. 输入输出

输入输出风格应该考虑的原则

1. 对所有的输入数据都进行检查，从而识别错误的输入，以保证每个数据的有效性
2. 检查输入项的各种重要组合的合理性，必要时报告输入状态信息
3. 使得输入的步骤和操作尽可能简单，并保持简单的输入格式
4. 输入数据时，应允许使用自由格式输入
5. 应允许缺省值
6. 输入一批数据时，最好使用输入结束标志，而不要由用户指定输入数据数目；
7. 在以交互式输入/输出方式进行输入时，要在屏幕上使用提示符明确提示交互输入的请求，指明可以选择项的种类和取值范围。同时在数据的输入过程中和输入结束时，也要在屏幕上给出状态信息
8. 当程序语言对输入格式有严格要求时，应保持输入格式与输出语句要求的一致性
9. 给所有的输出加注解，并设计输出报表格式。

输入/输出风格还受到许多其他因素的影响，如输入/输出设备、用户的熟练程度以及通信环境等

程序效率遵循的原则

1. 效率是一个性能要求，目标值应当在需求分析阶段给出。软件效率以需求为准，不以人力所及为准。
2. 好的设计可以提高效率。
3. 程序的效率与程序的简单性相关。

一般来说，任何对效率无重要改善，旦对程序的简单性， 可读性和正确性不利的程序设计方法都是不可取的。

程序的复杂性度量

程序复杂性主要指模块内程序的复杂性。它直接关联到软件开发费用的多少，开发周期的长短和软件内部错误的多少。

McCabe

定义

又称环路复杂性度量，是一种基于程序控制流的复杂性度量方法。它基于一个程序模块的程序图中环路的个数，因此计算它先要画出程序图

考题

结论

环路复杂度取决于程序控制结构的复杂度。当程序的分支数目或循环数目增加时其复杂度也增加。环路复杂度与程序中覆盖的路径条数有关。

MeCabe环路复杂度隐含前提是：错误与程序的判定加上例行子程序的调用数目成正比。

⭐️对于复杂度超过10的程序，应分成几个小程序，以减少程序中的错误。

软件设计的主要手段

1. 设计应遵循抽象化的原则，包含数据抽象（采用抽象数据类型表示数据实现数据封装，使得使用者可通过接口使用数据而不必关心数据结构的实现）和过程抽象（软件设计中将处理过程的实现细节隐藏在数据抽象中，可以直接通过模块接口使用这些处理操作）。
2. 设计应遵循自顶向下、逐步细化的原则，建立一个层次的结构。
3. 设计应当遵循模块化的原则。
4. Meyer 良好模块设计方法的标准（模块可分解性和模块可组装性）
5. 设计应遵循信息隐蔽的原则。

模块

定义

在软件中，通常把用一个名字就可以调用的一段程序成为“模块”

属性

功能：该模块能实现什么功能，做什么事情

逻辑：描述模块内部怎么做

状态：使用时的环境和条件

独立性

定义

软件系统中的每个模块只涉及软件要求的具体子功能，而与软件中其他模块的接口是简单的，若一个模块只有单一的功能，且与其他的模块没有太多的联系，则称此模块为独立的

衡量标准

模块的耦合

模块的内聚

（高内聚低耦合）

耦合

对模块间相互关联程度的一种度量，表现了模块的外部特征，模块间的耦合越低，独立性越好

标记耦合

一个模块调用另一个模块时，不是传送数据A本身，而是存放数据A的变量名或文件名（是数据的标记，故称标记耦合）

结构化设计方法的要点

1. 精化DFD
2. 确定DFD类型
3. 分解上层模块，设计中下层模块结构
4. 根据优化准则对软件结构求精
5. 描述模块功能，接口及全局数据结构
6. 复查，如果有错，转向2修改完善，完成后进入详细设计

研究分析和审查数据流图

1. 需求规格说明中弄清数据流加工的过程，对于发现的问题及时解决
2. 根据数据流图确定数据处理的类型（变换型和事务型）
3. 由数据流图推导出系统的初始结构图
4. 利用一些启发式原则改进系统初始结构图，直到得到符合要求的结构图
5. 修改和补充数据字典
6. 制定测试计划

软件缺陷

1. 软件未达到产品说明书标明的功能
2. 软件出现了产品说明书指明不会出现的错误
3. 软件功能超出了产品说明书的范围
4. 软件未达到产品说明书虽未指明但应达到的目标
5. 软件测试员认为软件难于理解，不易运用，运行速度缓慢或最终用户认为不好

软件测试

目标

1. 测试时程序的执行过程，目的在于发现错误
2. 一个好的测试用例在于能发现至今未发现的错误
3. 一个成功的测试是发现了至今未发现的错误的测试

原则

1. 应当把“尽早地和不断地进行软件测试”作为软件开发者的座右铭
2. 测试用例应由测试输入数据和对应的预期输出结果这两部分组成
3. 程序员应避免检查自己的程序
4. 在设计测试用例时，应包括合理的输入条件和不合理的输入条件
5. 所有的测试都应当追溯到用户要求，导致程序不能满足用户要求的错误是严重错误
6. 充分注意测试中的群集现象。经验表明，测试发现错误的80%很可能出自20%的模块，换句话说，测试后程序中残存的错误数目与该程序中已发现的错误数目成正比
7. 严格执行测试计划，排除测试的随意性
8. 应当对每一个测试结果做全面检查
9. 妥善保存测试计划，测试用例，出错统计和最终分析报告，为维护提供方便

与各阶段的关系

软件开发过程是一个自顶向下，逐步细化的过程

软件计划阶段定义软件范围(作用域)

软件需求分析阶段建立软件信息域、功能和性能需求、约束等

软件设计阶段建立软件体系结构、用户接口、数据结构和细部设计

程序编码阶段把设计用某种程序设计语言转换成程序代码

两个方面

缺陷测试

V&V(验证和确认)

测试计划的内容

测试过程	描述测试过程的主要阶段，如单元和模块测试、子系统集成测试
需求跟踪	对每一项需求分别进行确认测试
测试项目	定义在软件过程中需要进行的测试
测试时间安排	给出总的测试时间安排并相应地安排资源分配。这与整个项目的时间安排有关。
测试记录规程	系统地记录测试结果。然后对测试结果和测试过程进行检查，看测试用例是否得到正常的执行。
硬件与软件需求	列出测试所使用的软件工具和硬件设施
约束	预料可能影响测试过程的约束( 如人员短缺等 )