软件工程期末复习提纲、主要内容

第一章 软件工程的范畴

软件工程

软件工程是一门学科 目的是生产出没有错误的软件 以工程学的思维去进行软件设计、软件开发、软件软件运维的一种方法论，按时并且在预算范围内交付，满足用户的需求。

软件危机

软件危机指软件产品的质量低得通常不能接受，并且不能够满足交付和预算限制。

传统的生命周期模型的六个阶段

• 需求阶段

  对概念进行细化，提取客户的需求

• 分析阶段

  分析客户的需求并以规格说明文档的形式给出

• 设计阶段

  • 结构设计：将整体分成各个模块
  • 详细设计：设计每一个具体的模块

• 实现阶段

  对各个部分独立进行代码编写和测试

• 交付后维护

  • 纠错型性维护
  • 增强性维护
    • 完善性维护
    • 适应性维护

• 退役

交付后维护的重要性

维护成本远大于开发成本

三个为什么

• 为什么没有计划阶段

• 为什么没有测试阶段

• 为什么没有文档阶段

上述三个阶段在软件开发的过程中是贯穿始终的，因此不能单独拿出来作为一个独立的阶段而存在

面向对象的范型

面向对象的生命周期模型

• 需求工作流
• 面向对象分析工作流
• 面向对象设计工作流
• 面向对象实现工作流
• 交付后维护
• 退役

和传统范型的主要区别

在面向对象分析工作流中 面向对象的设计方法需要确定产品要做什么的前提之下还需要进行类的提取

第二章 软件生命周期模型

核心工作流

• 需求工作流
• 分析工作流
• 设计工作流
• 实现工作流
• 测试工作流

核心概念

迭代-递增、米勒法则

各种生命周期模型的比较

生命周期模型	长处	短处
进化树模型	与迭代-递增模型等价，与现实世界软件开发最接近的模型
迭代-递增生命周期模型	与现实世界软件开发最接近的模型，蕴含统一过程和方法
编码-修补生命周期模型	适用于不需要任何维护的小程序	不适合于重要的软件程序的开发
瀑布生命周期模型	纪律性强的方法，文档驱动	交付后的产品可能不符合客户的要求
快速原型开发生命周期模型	确保交付后的产品符合客户的要求	还没有证明无懈可击
开源生命周期模型	在少量实例中工作的很好	实用性有限
敏捷过程	客户的需求模糊时能够很好的工作	只适用于小型项目
同步-稳定生命周期模型	能够满足未来用户的哎哟求，确保各个组件能够成功的集成	出了微软公司，还没有广泛的应用
螺旋生命周期模型	风险驱动	只能用于大型的内部产品，开发者必须精通风险分析和风险排除

第三章 软件过程

软件过程的定义

软件过程是我们生产软件的方式。它包括方法学和隐含的生命周期模型，技术、所使用的工具，以及建造这些软件的人。

核心工作流

• 需求流
• 分析流
• 设计流
• 实现流
• 测试流

需求流

目标是让开发组织确定客户的需求

分析流

分析和提取需求，让需求以一种更为精确的方式进行描述，解决语言中的可能的歧义性问题。

设计流

细化分析流的制品，直至材料处于程序员可实现的形式。

实现流

用选择的语言实现目标软件产品

测试流

1. 每个开发者和维护者都要负责确保自己的工作是正确的。
2. 一旦软件人员确信要给制品是正确的，就将它交个软件质量保证小组进行独立测试。
3. 对所有制品都至关重要的一个特性是可追踪性

统一过程的各个阶段

• 开始阶段

  • 第一次递增 目标是决定是否值得开发目标软件产品 明确提出软件产品是否经济上可行

• 细化阶段

  • 第二次递增 细化最初需求 细化体系结构，监控风险和细化它们的属性，细化商业案例，以及生成软件项目管理计划

• 构建阶段

  • 第三次递增 生产软件产品的第一个可行工作版本

• 转换阶段

  • 第四次递增 确保客户的需求切实得到满足

一维与二维生命周期模型

能力成熟度模型

• 级别1：初始级

  • 有效的软件过程管理方法本质上没有获得使用
  • 世界上大多数的软件组织的软件开发能力成熟度级别仍处于1级

• 级别2：可重复级

  • 使用了基本的软件项目管理措施，有软件生产文档，但是不够充分

• 级别3：定义级

  • 过程有充分的软件生产文档，软件开发过程在所有的管理和技术方面都有明确的意义，并在任何可能的地方不断努力改进软件开发过程，用评审方式来保证软件质量

• 级别4：管理级

  • 组织为每个项目设计了质量目标和生产目标，在软件开发过程中对这两个指标不断测量，当与目标有不可接受的偏移时，采取适当的措施对其进行纠正。

• 级别5：最优级

  • 目标时持续改进软件的生产过程，用统计质量和过程控制技术对软件组织进行指引。在每个项目中获取到的知识在以后的项目中可以得到不断的利用。开发过程是一个良性循环，从而使软件的质量不断得到提高。
    

第四章 软件小组

布鲁克斯法则

向一个以及延期的软件项目小组增加人员会使得该项目完成的更晚。

民主小组方法

• 无我编程

  • 优点：对查找代码错误的积极态度有利于代码质量的提高
  • 缺点：经理们可能难以接受无我编程 有着多年编程经验的老手可能不愿意将代码交给新人评判

传统的主程序员小组

• 特性

  • 专业化
  • 等级性

• 存在的问题

  • 主程序员是一个搞水平的程序员同时也是一个高水平的管理者的结合，这样的人才稀缺
  • 备用程序员和编程秘书都很难寻找，因此主程序员小组很难付诸实践

现代化的小组结构

各个小组组织方法总结

小组组织	优点	缺点
民主小组	积极寻找错误，代码质量高，特别适用于解决难题	经理和有经验的人方案新手的评价 不能从外部强加
传统著程序员小组	如果主程序员是胜任的，那么这种小组会工作的很好	不实用
现代分级编程小组	小组经理、小组领导代替的主程序员的需求，可扩展，支持分散决策	需要明确各个小组的负范围，否则容易出错
同步-稳定小组	鼓励创造性，确保大量开发者为同一个目标而工作	出了微软公司之外还没有应用实例
敏捷过程小组	程序员不测试代码，成员离职不会有损失，小组之间相互学习，代码具有小组所有权	还没有更多的实例证明有效
开源小组	少数项目非常成功	应用面比较窄，需要由具有出色号召力的人来领导，需要顶尖的高手参与

第五章 软件开发工具

逐步求精法

尽可能的将细节的定义推延到最后，以便集中精力在重要的事项上

成本-效益分析法

通过对比估计的未来收入和预测的未来成本来确定一个行为过程是否有利可图的方法，确定客户是否应当进行业务计算机化的基本技术，如果确定使用计算机化，应用何种方法来比较各个可选方案的成本和收益。

分治

把不好解决的大问题拆分成一个一个的小问题这样有望更容易解决

软件度量

CASE

• 数据字典

软件版本

配置控制

建造工具

第六章 测试

质量问题

软件质量保证

• SQA小组（质量保证小组）

非执行测试

包括 评审和使用数学方法分析，其中评审包括：

• 走查
• 管理走查
• 审查

优点：

• 是检测错误的一个有效途径
• 能够在软件开发早期就发现错误，也就是在修复变得昂贵之前发现错误

缺点：

• 大型软件相当难于评审
• 设计评审小组经常需要查看设计文档，这就得保证设计文档时刻处于最新、在线状态，否则会严重妨碍评审小组发挥作用

执行测试

• 测试方面

  • 实用性：在规格说明书允许的条件下使用正确的产品时，满足用户需求的程度
  • 可靠性：对产品故障的出现频率和严重性进行测量
  • 健壮性：有效输入带来不可接受的结果的可能性以及产品的输入无效时结果的可接受性
  • 性能
  • 正确性

第七章 从模块到对象

模块的定义

一个或多个邻接的程序语句集合，它有一个名称以便系统的其他部分调用它，并且最好具有自己专用的变量名集，即一个模块单独的代码块组成，它可以像过程、函数或方法一样被调用。

内聚

内聚级别	说明
信息性内聚	如果模块进行许多操作，每个操作都有各自的入口点，并且每个操作的代码相对独立，而且所有操作都对相同的数据结构完成，则该模块具有信息性内聚
功能性内聚	只执行一个操作或只达到单一目标的模块具有功能性内聚
通信性内聚	如果一个模块执行一系列与产品要遵守的步骤顺序有关的操作，并且所有操作都对相同的数据进行，则该模块具有通信性内聚
过程性内聚	如果一个模块执行一系列与产品要遵守的步骤顺序有关的操作，则该模块具有过程性内聚
时间性内聚	当模块执行一系列与时间有关的操作时，该模块具有时间性内聚
逻辑性内聚	当一个模块及进行一系列相关操作，每个操作由调用模块来选择时，该模块具有逻辑性内聚
偶然性内聚	如果一个模块执行多个完全不相关的操作，则具有偶然性内聚

内聚级别从上往下，一次降低，最好的内聚是信息性内聚，最差的内聚是偶然性内聚

耦合

耦合级别	说明
数据耦合	如果两个模块的所有参数都是同类数据项，则它们是数据耦合
印记耦合	如果把数据结构作为参数传递，则两个模块之间具有印记耦合
控制耦合	如果两个模块中的一个模块给另外一个模块传递控制要素，则它们具有控制耦合
共用耦合	如果两个模块都可以存取相同的全局数据，则它们之间是共用耦合
内容耦合	如果两个模块中的一个模块直接引用了另外一个模块的内容，它们之间存在着内容耦合

耦合的级别从上往下依次降低，最好的是数据耦合，最差的是内容耦合，一个好的设计是高内聚，低耦合

数据封装

抽象数据类型

将对同一个数据结构的操作封装成一个类，这个类就是一种抽象数据类型

信息隐藏

对象

多态、继承、动态绑定

第十一章 需求

需求流概述

需求流的整体目标是让开发组织确定客户的需要（而非想要）。达到这个目标的第一步是理解应用域，也就是目标产品应用的特定环境。

业务模型

业务模型是对公司的商业过程进行的描述。建立业务模型的方式有以下几种方式：

• 访谈

  • 程式化访谈：受限的回答
  • 非程式化访谈：自由回答

• 调查问卷

• 用例

用例图示例

用例描述示例

快速原型开发

• 概念

  • 仓促建立的软件，展示目标软件产品的主要功能

第十二章 传统的分析

规格说明文档

规格说明文档是客户和开发者之间的一种合同。它明确规定了产品必须做什么，以及对产品的约束

非形式化规格说明

使用自然语言对规格进行说明会存在歧义性的问题

结构化系统分析

• 数据流图

• 数据流图说明

  • 数据流箭头上为名词，表示某个具体的数据
  • 数据处理过程必须是动词，表示数据处理的动作

• 示例

  

构建实体-关系模型

• 示例

有穷状态机

• 转换规则

  $$当前状态与事件\to 下一个状态$$

• Petri网

传统分析阶段面临的挑战

1. 规格说明文档既要是非形式化的，又要是形式化的，非形式化的内容给客户看，形式化的内容给开发人员看。
2. 分析和设计之间的界限不够明显，容易跨越

第十三章 面向对象分析

分析流

• 目标

  • 分析需求流，得到对需求流更深的理解
  • 按设计和实现易于维护的的思路描述需求

• 三种类

  • 实体类：为长期存在的信息建模
  • 边界类：为软件产品和它的参与者之间的交互行为进行建模
  • 控制类：为复杂的计算和算法建模

抽取实体类

• 功能建模

  • 提取所有的场景（场景是用例的一个实例）

  • 场景示例

  

• 实体类建模

  • 确定实体类和它们的属性，然后确定实体类之间的交互关系和交互行为，以类图的形式提供这些信息

• 动态建模

  • 确定每个实体类或子类执行的操作或对它们的操作（状态图）

  • 状态图示例

  

  • 顺序图示例

注意点：1.顺序图最上方是类 不是某个方法 2.顺序图要标好序号 3.顺序图表示消息的传递顺序 应当是有进有出的

• 通信图示例

第十四章 设计

面向操作的设计

• 数据流分析

  • 输入最高抽象点

    • 输入失去作为输入的性质并且简单地变为由产品的操作作为内部数据的点

  • 输出最高抽象点

  • 输出与输入相反 是最低点

  • 依据输入最高抽象点和输出最高抽象点 可以简单的讲系统划分为以下三个模块：

    • 输入模块

  • 转换模块

  • 输出模块

  • 结构图示例
    

  • 说明

    • 结构图的左部为输入部分

  • 结构图右部为输出部分

  • 中间为转换部分

  • PDL语言—伪代码

面向对象设计

• 完成类图设计

  • 确定属性的格式
  • 分配方法

• 进行详细设计

  • PDL描述

第十五章 实现

编程语言的选择

• 使用成本-效益法进行深入分析

良好的编程实践

• 使用一致和有意义的变量名

• 嵌套if语句不超过三层

• 制定编码标准

集成

• 自顶向下集成

  • 设计错误能够被较早发现
  • 支持错误隔离
  • 潜在的可重用部分可能会测试不充分

• 自底向上集成

  • 操作制品能够被充分测试
  • 错误隔离

• 三明治集成

  • 综合了自顶向下和自底向上集成

• 三种集成的比较

  方法	优点	缺点
  实现然后集成		没有错误隔离手段，主要设计错误发现迟，潜在可重用代码制品不能被充分地测试
  自顶向下集成	具有错误隔离手段，主要设计错误能够被较早的发现	潜在可重用代码制品不能被充分的测试
  自底向上集成	具有错误隔离手段，潜在可重用制品能够被充分的测试	主要设计错误发现的迟
  三明治集成	具有错误隔离手段，主要设计错误发现的早，潜在可重用的代码制品能够被充分的测试

  实现流

  用所选的语言实现目标软件产品，大型的软件被分成小一些的子系统，然后由编码小组并行的实现，这些子系统由组件或代码制品组成。

黑盒单元测试技术

• 等价测试和边界值分析

  • 对于不同的输入，如果能够依据产品规格说明书得到相同的输出，那么这一类输入的测试数据被称为等价类
  • 边界值：位于两个等价类之间的输入值

• 功能测试

  • 根据模块的功能来选择测试数据

玻璃盒单元测试技术

• 结构测试

  • 语句覆盖

    • 让代码中的每一个语句都能够被测试到
    • 不能够保证对分支的所有输出都充分的测试

  • 判定覆盖（分支覆盖）–路径

    • 每个判定True或False都执行一次

    • 示例

• 条件覆盖–条件

  • 针对判断语句里面的每一个表达式 True 和 False各取一次

  • 示例

• 路径覆盖

  • 测试所有的路径
  • 路径数量非常大 几乎不可能实现

• 完全定义-使用路径覆盖

  • 在每个变量的定义和使用之间的代码路径建立一个测试用例

秩复杂度

二进制判定数+1，本质上是代码制品中的分支数

单元测试技术比较

• 黑盒测试 白盒测试 代码阅读 三者在发现错误方面同样有效
• 代码走查比其他技术成本要低很多

第十六章 交付后维护

为什么交付后维护是必要的

• 需要纠正的错误：分析错误、设计缺陷、编码错误、文档错误$$\to$$纠错性维护
• 完善性维护
• 适应性维护

第十七章 UML的进一步讨论

类图

• $\underline{:类名/某一具体对象名称}$ 表示一个实例

• 前缀+ 表示public属性/方法

• 前缀- 表示private属性/方法

• 示例
  

• 聚合

  • 局部-整体关系–空心菱形表示（整体丢失 但是局部可以独立存在）

  • 示例

• 组合

  • 部分-整体关系–实心菱形表示（整体丢失 部分无法单独存在）

  • 示例–棋盘和棋格
    

• 关联

  • 它表示类与类之间的连接，它使得一个类知道另一个类的属性和方法。

  • 示例
    

• 泛化

  • 继承是泛化的特例（用空心三角形表示）

  • 示例