软件工程(导论)

成秀秀、杨玲、戚爱斌、苗世迪、温东新

目录

  • 1 软件与软件工程
    • 1.1 软件
    • 1.2 软件危机
    • 1.3 软件工程
    • 1.4 软件生命周期
    • 1.5 软件过程模型
    • 1.6 学生成果分享
  • 2 可行性研究与项目开发计划
    • 2.1 可行性研究的任务
    • 2.2 可行性研究过程
    • 2.3 进度计划
    • 2.4 学生成果分享
  • 3 需求分析
    • 3.1 需求分析的任务
    • 3.2 与用户沟通获取需求的方法
    • 3.3 分析建模与规格说明
    • 3.4 实体-联系图
    • 3.5 数据规范化
    • 3.6 状态转换图
    • 3.7 其它图形工具
    • 3.8 验证软件需求
  • 4 总体设计
    • 4.1 系统流程图
    • 4.2 数据流图
    • 4.3 数据字典
    • 4.4 设计过程
    • 4.5 设计原理
    • 4.6 启发规则
    • 4.7 描绘软件结构的图形工具
    • 4.8 面向数据流的设计方法
  • 5 详细设计
    • 5.1 结构程序设计
    • 5.2 人机界面设计
    • 5.3 过程设计的工具
    • 5.4 面向数据结构的设计方法
    • 5.5 程序复杂程度的定量度量
  • 6 软件编码
    • 6.1 程序设计语言
    • 6.2 编码风格
  • 7 软件测试
    • 7.1 软件测试基础
    • 7.2 单元测试
    • 7.3 集成测试
    • 7.4 确认测试
    • 7.5 白盒测试技术
    • 7.6 黑盒测试技术
    • 7.7 调试
    • 7.8 软件可靠性
  • 8 软件项目管理
    • 8.1 估算软件规模
    • 8.2 工作量估算
    • 8.3 人员组织
    • 8.4 质量保证
    • 8.5 软件配置管理
    • 8.6 能力成熟度模型
启发规则

一、改进软件结构提高模块独立性

通过模块分解或合并,降低耦合提高内聚。

两个方面: 

1、模块功能完善化。一个完整的模块包含:

■执行规定的功能的部分

■出错处理的部分

■返回一个“结束标志”

2、消除重复功能,改善软件结构。

■完全相似

■局部相似


二、模块规模应该适中

经验表明,一个模块的规模不应过大,最好能写在一页纸内。通常规定50~100行语句,最多不超过500行。数字只能作为参考,根本问题是要保证模块的独立性。

过大的模块往往是由于分解不充分,但是进一步分解必须符合问题结构,一般说来,分解后不应该降低模块独立性。

过小的模块开销大于有效操作,而且模块数目过多将使系统接口复杂。


三、深度、宽度、扇出和扇入都应适当

深度:软件结构中控制的层数,它往往能粗略地标志一个系统的大小和复杂程度。

宽度:软件结构内同一个层次上的模块总数的最大值。

扇出:一个模块直接控制(调用)的模块数目。

扇入:有多少个上级模块直接调用它。


四、模块的作用域应该在控制域之内

模块的作用域:定义为受该模块内一个判定影响的所有模块的集合。

模块的控制域:是这个模块本身以及所有直接或间接从属于它的模块的集合。 

在一个设计得很好的系统中,所有受判定影响的模块应该都从属于做出判定的那个模块,最好局限于做出判定的那个模块本身及它的直属下级模块。


解决方案:

■把模块A中的判定移到模块M中;

■把模块G移到模块A下面,作为他的下级模块。 


五、力争降低模块接口的复杂程度

模块接口复杂是软件发生错误的一个主要原因。应该仔细设计模块接口,使得信息传递简单并且和模块的功能一致。

例:解一元二次方程的函数

QUAD_ROOT(TBL,X)     --不合理

■其中数组TBL传送方程的系数

■数组X送回求得的根

QUAD_ROOT(A,B,C,ROOT1,ROOT2)   --合理


六、设计单入口单出口的模块

警告软件工程师不要使模块间出现内容耦合。当从顶部进入模块并且从底部退出来时,软件是比较容易理解的,因此也是比较容易维护的。


七、模块功能应该可以预测

模块的功能应该能够预测,但也要防止模块功能过分局限。

功能可预测:如果一个模块可以当做一个黑盒子,只要输入的数据相同就产生同样的输出,这个模块的功能就是可以预测的。