软件工程期末

第二章

需求的分类：

• 功能需求
• 非功能需求
  易用性、观感、性能、安全、文化、操作需求
• 限制条件（工期、资源等限制，与系统无关的约束）

• 功能需求
• 性能需求
• 可靠性与可用性需求
• 出错处理需求
• 接口需求
• 约束

需求建模模型

• 数据流图：以图形方式来表达数据在系统中的流动、变换过程
• 数据字典：对数据流图中数据流、加工等各个元素的定义及说明，是数据流图的重要补充
• E-R图：系统中实体及实体间的关系
• 状态转换图：描述系统对外部事件的响应及状态变化

需求分析

开发人员进行调研与分析，将用户非形式的需求表述转化为完整的需求定义
主要任务：确定系统的需求，包括功能需求与非功能需求

第四章

模块概念

接口 + 功能 + 逻辑 + 状态
模块的输入输出
模块实现的功能
模块内部逻辑
模块外部运行环境

模块独立性 ?

把软件划分为模块时遵守的准则，也是判断模块构造是否合理的标准
模块只完成一个特定的独立功能，且与其他模块的关系简单

为什么模块独立性很重要

• 模块化的软件易于开发、测试、维护
• 修改设计、程序的工作量小，错误的传播范围小

内聚

耦合

软件设计8条规则

1. 设计过程可预测与评估
2. 设计模型是可跟踪的
3. 设计应重视资源重用
4. 设计应表现一致性与集成性
5. 设计不是编码，编码不是设计
6. 设计应考虑软件的容错性及异常处理的能力
7. 设计应适应扩展及变更

软件程序结构设计的启发式设计准则（模块结构图的设计规则）

1. 提高模块独立性，做到高内聚低耦合
2. 模块规模适中
3. 适当的扇入扇出
4. 作用域在控制域内
   控制域：模块本身及其所有可供调用的下级模块
   作用域：接受我发送的控制信息而影响自身判断的模块
5. 定义功能可预测的模块
6. 设计入口单出口的模块

第五章

变换流与事务流的区别

• 变换流
  具有明显的输入、变换和输出界面的数据流图
• 事务流
  数据沿输入通路到达事务中心后，根据输入数据的类型在若干动作序列中选出一个来执行

第六章

面向对象

面向对象的概念

对象 + 类 + 继承 + 通信

面向对象的特点

• 抽象
• 封装
• 共享

类图

描述系统的结构

类

一组具有相同数据结构与相同操作的对象的集合

四种类间关系

关联

泛化

父类子类关系
动物—狗—猫

组合 is a part of （同生共死）

聚合 is a member of

软件开发小组 — 人

依赖 —->

带箭头的虚线
对于类A和类B，若出现下面情况，称为类A依赖类B：

用例图

3种用例间的关系

• 包含
  使用情况：

• 扩展
  把新行为插入到已有用例，类似于特殊情况处理
  扩展用例是基础用例在某些条件下触发的

• 泛化
  子用例将继承基用例的所有行为，也就是任何使用基用例的地方都可以使用子用例来代替
  

• 顺序图：强调按照时间顺序发生的对象交互行为

协作图与顺序图的区别

若干幅用例图构成

• 定义系统
• 找出角色与用例
• 描述用例
• 用例的加工
• 验证模型

第十章

系统的设计目标

• 可靠性
• 容错性
• 安全性
• 可修改性

5类软件设计准则

• 性能
  对系统速度及空间的需求
• 可靠性
  对减少系统崩溃及随后造成的危害所做的努力程度
• 成本
  开发、配置、管理的成本
• 维护
  运行后再修改系统的困难程度
• 最终用户准则
  用户是否能在系统上完成所需任务
  用户使用系统的容易程度

OCL 对象约束语言

利用OCL去描述一个约束
允许在单个模型元素和模型元组上对约束进行形式化说明的语言

不变式：整个对象生命周期内都需要满足的约束
前置：执行操作前需满足的约束
后置：执行操作后需满足的条件

第10章

软件维护的概念

软件在运行中改正错误或需要添加新需求而修改软件的活动

1. 软件的维护总是针对某一种软件产品在软件生命周期内所进行的活动
2. 卖软件就是卖服务
3. 软件维护的时间是有限度的

为什么软件维护困难

种种原因

1. 读懂他人的程序很难
2. 文档太差
3. 修改后可能会产生新的错误
4. 维护工作很枯燥，没人愿意做

软件维护的4种分类

– 完善性维护 60%
扩展新需求
– 适应性维护 25%
软件运行的软硬件环境变化，需要维护使软件适应新的运行环境
如：操作系统由Linux换为Windows、系统配置信息的更改、软件使用对象变化
– 纠错性维护 20%
改正软件出现的错误、缺陷
– 预防性维护 5%
提高软件的可靠性及可维护性，减少以后的维护工作量
常用方法：软件再工程

软件维护3种副作用

代码的副作用

对代码的修改容易使程序混乱、结构不清晰、可读性变差

数据的副作用

轻易修改数据结构会使

文档的副作用

对软件的任何修改都应在相应技术文档中反映出来（软件修改后要及时更新文档）

第11章

软件测试的目的

以最低的代价尽可能多地找出软件中潜在的错误与缺陷

软件测试的16条原则

1. 尽早地、不断地测试
2. 严格执行测试计划
3. 妥善保存测试计划、测试用例、出错统计及分析 告，为后期维护的方便
4. 设计好的测试用例
5. 适时地结束测试
6. 避免程序员测试自己编写的程序

软件测试的分类

按测试策略分类

按测试方法

1. 静态测试(人工检测)
   不运行被测程序本身，仅对各阶段的文档进行静态审查
   对需求分析、设计说明书、源程序进行结构分析、流程分析来发现错误
2. 动态测试
   在计算机上运行被测代码，输入测试用例后观察其运行情况、分析测试结果

   • 黑盒测试
     完全不考虑程序内部结构和内部特性的情况下，在程序接口进行测试
     只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息

     • 等价类划分法
     • 边界值分析法

   • 白盒测试
     全面了解程序内部逻辑结构、对所有逻辑路径进行测试

     • 基本路径测试

       • 代码语句编
       • 画出控制流图
       • 环形复杂度的计算：
         • 边-节点+2
         • 分支节点数+1
         • 区域数+1
       • 找出独立路径（至少包含一条在定义该路径前不曾用过的边）
       • 设计测试用例， 测试每条独立路径

     • 逻辑覆盖

黑盒测试与白盒测试的比较：PPT P65