软件工程与uml期末复习

简介

以下内容为根据学校重点复习部分整理，可能会有缺漏，谅解

第1章 软件工程学概述

1.1 软件危机的典型表现

1. 对软件开发成本和进度的估计常常很不准确;
2. 用户对“已完成的”软件系统不满意的现象经常发生;
3. 软件产品的质量往往靠不住;
4. 软件常常是不可维护的;
5. 软件通常没有适当的文档资料;
6. 软件成本在计算机系统总成本中所占的比例逐年上升;
7. 软件开发生产率提高的速度，远远跟不上计算机应用迅速普及深入的趋势;

1.2 软件工程的本质特性：

1. 软件工程关注于大型程序的构造
2. 软件工程关注于大型程序的构造
3. 软件工程的中心课题是控制复杂性
4. 软件经常变化
5. 开发软件的效率非常重要
6. 和谐地合作是开发软件的关键
7. 软件必须有效地支持它的用户
8. 在软件工程领域中是由具有一种文化背景的人替具有另一种文化背景的人创造产品

1.3 软件工程的基本原理

1. 用分阶段的生命周期计划严格管理
2. 坚持进行阶段评审
3. 实行严格的产品控制
4. 采用现代程序设计技术
5. 结果应能清楚地审查
6. 开发小组的人员应该少而精
7. 承认不断改进软件工程实践的必要性

1.4 软件生命周期 ⭐

三个时期八个阶段：软件生命周期由软件定义、软件开发和运行维护(也称为软件维护)三个时期组成，每个时期又进一步划分成若干个阶段。

以下了解就好

1. 问题定义
	任务：问题是什么
	结果：关于系统规模和目标的报告书
2.	可行性研究
	任务：有可行的解吗
	结果：系统的高层逻辑模型（数据流图、成本效益分析）；可行性论证报告
3.需求分析
	任务：必须做什么
	结果：系统的逻辑模型（数据流图、数据字典、简要的算法描绘）、用规格说明书准确记录对目标系统的需求
4.总体设计
	任务：如何解决已提出的问题
	结果：可能的解法（系统流程图、成本效益分析）；推荐的系统体系结构（层次图或结构图)
5.详细设计
	任务：怎样具体实现该系统
	结果：每个模块的算法和数据结构(程序流程图、 PAD图、 N-S 图等)
6.编码和单元测试
	任务：得到正确的程序模块
	结果：代码和测试报告
7.综合测试
	任务：得到符合要求的软件
	结果：测试计划、详细测试方案以及实际测试结果；完整一致的软件配置
8.软件维护
	任务：使系统持久地满足用户的需要
	结果：完整准确的维护记录

1.5 模型

1.5.1 瀑布模型

以文档为驱动
优点：规范易懂，阶段清晰
缺点：不适用与大型项目，难以适应变化，测试滞后
适用于：需求是与之预知的；软件实现方法是成熟的，项目周期段短

1.5.2 快速原型模型

以用户需求和反馈为驱动
优点：快速，便于测试，节省成本，提高质量和用户体验
缺点：不够完整和稳定，需要不断优化和改进

1.5.3 增量模型

以变化为驱动
优点：人员分配灵活，提供了一种先推出核心产品的途径，使用户有 较充裕的时间 学习和适应新产品
缺点：软件体系结构必须是开放的，模型本身是自相矛盾的。

1.5.4 螺旋模型

以风险管理为驱动
优点：风险可控，适应变化，用户参与
缺点：成本高，时间长，需专业人员
适用于：庞大、复杂并具有高风险的系统；内部开发的大规模软件项目

1.5.5 喷泉模型

以对象为驱动

第2章 可行性研究

2.1 可行性研究的任务

主要方面：

1、技术可行性，使用现有的技术能实现这个系统吗?
2、经济可行性，这个系统的经济效益能超过它的开发成本吗?
3、操作可行性，系统的操作方式在这个用户组织内行得通吗?

其他方面：

1、运行可行性，系统的运行方式是否可行?
2、法律可行性，系统是否侵犯他人、集体或国家的利益，是否违反法律?

2.2 数据流图

数据流图（DFD）：

1、是一种图形化技术，它描绘信息流和数据从输入移动到输出的过程中所经受的变换。
2、在数据流图中没有任何具体的物理部件，它只是描绘数据在软件中流动和被处理的逻辑过程。

基本符号

画基本系统模型

由若干个数据源点/终点和一个处理组成。

2.3 数据字典的内容

数据字典的组成：
数据流、数据流分量（既数据元素）、数据存储、处理（如IPO图）

例1:
标识符=字母字符+字母数字串
字母数字串=0 {字母或数字}7
字母或数字=[字母字符 |数字字符]

例2:
购书单=学号+姓名+{书号+数量+单价+总价}+书费合计
学生用书表={学院编号+专业编号+年级+{书号}}
年级=[1 |2 |3 |4]
学号=10 {数字}10


习题2.5
北京某高校可用的电话号码有以下几类：
校内电话号码由4位数字组成，第1位数字不是0;
校外电话又分为本市电话和外地电话两类；
拨校外电话需先拨0;
若是本市电话则再接着拨8位数字(第1位不是0);
若是外地电话则拨3位区码再拨8位电话号码(第1位不是0)。

答案
电话号码 = [ 校内电话号码 | 校外电话号码 ]
校内电话号码 = 非零数字 + 3位数字
校外电话号码 = [ 本市号码 | 外地号码 ]
本市号码 = 0 + 8位数字
外地号码 = 0 + 3位数字 + 8位数字
非零数字 = [ 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 ]
3位数字 = 3{数字}3
8位数字 = 非零数字 + 7位数字
7位数字 = 7{数字}7

第3章 需求分析

需求分析的任务：
1、准确回答"系统必须做什么?" 这个问题。
2、确定系统必须完成哪些工作。
3、写出软件需求规格说明书，以 书面形式准确地描述软件需求。

3.1 确定对系统的综合要求（8个需求）

1.功能需求
2.性能需求
3.可靠性和可用性需求
4.出错处理需求
5.接口需求
6.约束
7.逆向需求
8.将来可能提出的要求

需求分析过程应该建立3种模型
分别是：数据模型；功能模型；行为模型

3.2 其他图形工具

3.2.1 层次方框图

用树形结构的一系列多层次的矩形框描绘数据的层次结构。
树形结构的顶层是一个单独的矩形框，它代表完整的数据结构；
下面的各层矩形框代表这个数据的子集；
最底层的各个框代表组成这个数据的实际数据元素(不能再分割的元素)。

3.2.2 IPO图

IPO图是输入、处理、输出图的简称，它是 美国IBM公司发展完善起来的一种图形工具， 能够方便地描绘输入数据、对数据的处理和输出数据之间的关系。

基本形式：是在左边的框中列出有关的输入数 据，在中间的框内列出主要的处理，在右边的 框内列出产生的输出数据。在IPO 图中还用类 似向量符号的粗大箭头清楚地指出数据通信的 情况。

3.3 验证软件需求的方法

1. 验证需求的一致性
■ 人工技术审查
■ 形式化的描述软件需求的方法
2.验证需求的现实性
■仿真或性能模拟技术
3.验证需求的完整性和有效性
■开发原型系统

第5章 总体设计

5.1 设计过程

7.制定测试计划
在软件开发的早期阶段考虑测试问题，能促使软件设
计人员在设计时注意提高软件的可测试性。
8.书写文档
应该用正式的文档记录总体设计的结果，在这个阶段
应该完成的文档通常有下述几种：
(1)系统说明；
(2)用户手册；
(3)测试计划；
(4)详细的实现计划；
(5)数据库设计结果。
9.审查和复审
最后应该对总体设计的结果进行严格的技术审查和管理复审。

5.2 设计原理

5.2.1 模块化

模块：是由边界元素限定的相邻程序元素的序 列，而且有一个总体标识符代表它。

模块化：就是把程序划分成独立命名且可独立 访问的模块，每个模块完成一个子功能，把这 些模块集成起来构成一个整体，可以完成指定 的功能满足用户的需求。

5.2.2 模块独立程度的两个定性标准度量：

耦合衡量不同模块彼此间互相依赖(连接)的紧密程度。
耦合要低，即每个模块和其他模块之间的关系要简单；

内聚衡量一个模块内部各个元素彼此结合的紧密程度。
内聚要高，每个模块完成一个相对独立的特定子功能。

6种耦合
最好的耦合是数据耦合,最差耦合是内容耦合
7种内聚
最好的是功能内聚，最差的是偶然内聚

5.3 启发规则

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

深度：软件结构中控制的层数，它往往能粗略地标志一个系统的大小和复杂程度。
宽度：软件结构内同一个层次上的模块总数的最大值。
扇出： 一个模块直接控制(调用)的模块数目。
扇入：有多少个上级模块直接调用它。

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

模块的作用域：定义为受该模块内一个判定影响的所有模块的集合。
模块的控制域：是这个模块本身以及所有直接或间接从属于它的模块的集合。

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

5.4 描绘软件结构的图形工具

5.4.1 层次图和HIPO 图

1.层次图(H 图)
层次图用来描绘软件的层次结构。很适于在自顶向 下设计软件的过程中使用。
层次图和层次方框图的区别：

-	层次图	层次方框图
作用	描绘软件结构	描绘数据结构
矩形框	模块	数据元素
连线	调用关系	组成关系

5.5 面向数据流的设计方法

5.5.1 概念

面向数据流的设计方法把信息流映射成软件结构，信息流的类型决定了映射的方法。

信息流有两种类型：
变换流
2、事务流

数据沿输入通路到达一个处理T,T 根据输入 数据的类型在若干个动作序列中选出一个来执 行。
处理T称为事务中心，它完成下述任务：

• 接收输入数据；
• 分析每个事务以 确定它的类型；
• 根据事务类型
• 选取一条活动通路。
  
  例3:自动柜员机
  顾客插入磁卡，输入密码，然后执行动作，包括向支票、存折或信用卡账户存款，提款或查询余额等。
  设计上分成两部分：
• 分析器和调度器。
• 分析器确定事务类型并将信息送到分配器，由调度器进行事务处理。
  
  
  
  例四：一个公司的销售管理系统
  
  
  三条“黄金规则”:
• 置用户于控制之下。
• 减少用户记忆负担。
• 保持界面一致。

第六章 详细设计

6.1 设计问题

设计人机界面过程中会遇到的4个问题：

1. 系统响应时间
2. 用户帮助设施
3. 出错信息处理
4. 命令交互

6.2 过 程 设 计 的 工 具

6.2.1 程 序 流 程 图

程序流程图又称为程序框图，它是历史最悠久、使用最广泛的描述过程设计的方法。
它的主要优点是对控制流程的描绘很直观，便于初学者掌握。

6.2.2 盒图(N-S 图)

盒图具有下述特点：

• 功能域明确。
• 不可能任意转移控制。
• 很容易确定局部和全程数据的作用域。
• 很容易表现嵌套关系，也可以表示模块的层次结构。

盒图的基本符号

6.2.3 PAD图

PAD 是用二维树形结构的图来表示程序的控制流，将这种图翻译成程序代码比较容易。

PAD图的基本符号

PAD图

6.2.4 判定表

当算法中包含多重嵌套的条件选择时，用程序 流程图、盒图、 PAD 图或后面即将介绍的过程设计语言(PDL)都不易清楚地描述。
判定表却能够清晰地表示复杂的条件组合与应做的动作之间的对应关系。

例题

1. 假设某航空公司规定，乘客可以免费托运重量 不超过30kg的行李。
   当行李重量超过30kg时，对头等舱的国内乘客 超重部分每公斤收费4元，对其他舱的国内乘客超重部分每公斤收费6元。
   对外国乘客超重部分每公斤收费比国内乘客多 一倍，对残疾乘客超重部分每公斤收费比正常乘客少一半。
   

6.2.5 判定树

判定树是判定表的变种，也能清晰地表示复杂的条件组合与应做的动作之间的对应关系。多年来判定树一直受到人们的重视，是一种比较常用的系统分析和设计的工具。

用判定树表示计算行李费的算法
PDL 的特点：

• 关键字的固定语法，它提供了结构化控制结构、 数据说明和模块化的特点。
• 自然语言的自由语法，它描述处理特点
• 数据说明的手段。应该既包括简单的数据结构， 又包括复杂的数据结构。
• 模块定义和调用的技术，应该提供各种接口描 述模式。

练习题
1：画出下列伪码程序的程序流程图和盒图：

2:用判定表和判定树表示"检查订货单"程序

6.3 面向数据结构的设计方法

6.3.1 Jackson图

Jackson图的优点：

• 便于表示层次结构，而且是对结构进行自顶向 下分解的有力工具；
• 形象直观可读性好；
• 既能表示数据结构也能表示程序结构。

Jackson图的缺点：

• 表示选择或重复结构时，选择条件或循环结束条件不能直接在图上表示出来，影响了图的表达能力，也不易直接把图翻译成程序；
• 框间连线为斜线，不易在行式打印机上输出。

6.4 程序复杂程度的定量度量

详细设计阶段设计出的模块质量可以使用软件 设计的基本原理和概念进一步仔细衡量它们的质量。

6.4.1 McCabe方法

1. 流图
McCabe方法根据程序控制流的复杂程度定量 度量程序的复杂程度，这样度量出的结果称为 程序的环形复杂度。
流图的表示：
结点：用圆表示， 一 个圆代表一条或多条语句。
边：箭头线称为边，代表控制流。在流图中一条边必须终止于一个结点，即使这个结点并不代表任何语句。
区域：由边和结点围成的面积称为区域，包括图外部未被围起来的区域。

映射方法：
任何方法表示的过程设计结果，都可以翻译成流图。
对于顺序结构，一个顺序处理序列和下一个选择或循环的开始语句，可以映射成流图中的一个结点。

第七章 实现

7.1 编码

7.1.1 选择程序设计语言

• 机器语言，几乎不使用。
• 汇编语言，特殊场合使用。
• 高级语言，明显优于汇编语言。

7.2.2 软件测试准则

• 所有测试都应该能追溯到用户需求；
• 应该远在测试开始之前就制定出测试计划；
• 应该从“小规模"测试开始，并逐步进行“大 规模"测试；
• 穷举测试是不可能的；
• 为了达到最佳的测试效果，应该由独立的第三 方从事测试工作。

黑盒测试与白盒测试优缺点比较：

7.2 单元测试

• 单元测试集中检测模块；
• 单元测试和编码属于软件过程的同一个阶段；可以应用人工测试和计算机测试这样两种不同类型的测试方法；
• 单元测试主要使用白盒测试技术，对多个模块的测试可以并行地进行。

7.3 集成测试

• 集成测试是测试和组装软件的系统化技术，主要目标是发现与接口有关的问题。
• 由模块组装成程序时有两种方法：
  □非渐增式测试方法
  □渐增式测试方法

7.4 回归测试

• 回归测试是指重新执行已经做过的测试的某个 子集，以保证测试过程中的变化没有带来非预 期的副作用。
• 回归测试就是用于保证由于调试或其他原因引起的变化，不会导致非预期的软件行为或额外错误的测试活动。
• 回归测试可以通过重新执行全部测试用例的一个子集人工地进行，也可以使用自动化的捕获回放工具自动进行。

7.5 Alpha和Beta测试

• Alpha 测试由用户在开发者的场所进行，并且 在开发者对用户的“指导”下进行测试。
  Alpha 测试是在受控的环境中进行的。
• Beta 测试由软件的最终用户们在一个或多个客 户场所进行。开发者通常不在Beta 测试的现场， 因此， Beta 测试是软件在开发者不能控制的环 境中的“真实”应用。

测试总结

7.6 逻辑覆盖

有选择地执行程序中某些最有代表性的通路是对穷尽测试的惟一可行的替代办法。
从覆盖源程序语句的详尽程度分析，大致有以下一些不同的覆盖标准：

• 语句覆盖
• 判定覆盖
• 条件覆盖
• 判定/条件覆盖
• 条件组合覆盖

从对程序路径的覆盖程度分析的逻辑覆盖标准：

• 点覆盖
• 边覆盖
• 路径覆盖
  
  
  

7.7 边界值分析

经验表明，处理边界情况时程序最容易发生错 误。例如，许多程序错误出现在下标、纯量、 数据结构和循环等等的边界附近。
使用边界值分析方法设计测试方案首先应该确 定边界情况。选取的测试数据应该刚好等于、 刚刚小于和刚刚大于边界值。
通常设计测试方案时总是联合使用等价划分和 边界值分析两种技术。

平均维修时间MTTR:
是修复一个故障平均需要用的时间，它取决于 维护人员的技术水平和对系统的熟悉程度，也和系统的可维护性有重要关系。
平均无故障时间MTTF:
是系统按规格说明书规定成功地运行的平均时 间，它主要取决于系统中潜伏的错误的数目， 因此和测试的关系十分密切。

第八章 维护

8.1 软件维护的定义

所谓软件维护就是在软件已经交付使用之后， 为了改正错误或满足新的需要而修改软件的过程。
可分为4项活动：

• 改正性维护
• 适应性维护
• 完善性维护
• 预防性维护

8.2 决定软件可维护性的因素

决定软件可维护性的因素主要有7个：

1. 可理解性
2. 可测试性
3. 可修改性
4. 可靠性
5. 可移植性
6. 可使用性
7. 效率

第九章 UML统一建模语言

9.1 UML概述

• UML（Unified Modeling Language）是软件界第一个统一的建模语言，该方法结合了Booch, OMT, 和OOSE方法的优点，统一了符号体系。
• 统一建模语言(UML)是一种绘制软件蓝图的标准语言。可以用UML对软件密集型系统的制品进行可视化详述和文档化。UML是一种定义良好、易于表达、功能强大且普遍适用的可视化建模语言。它融入了软件工程领域的新思想、新方法和新技术。它的作用域不限于支持面向对象的分析与设计，还支持从需求分析开始的软件开发的全过程。UML的作用就是用很多图从静态和动态方面来全面描述我们将要开发的系统。

9.2 图( Diagrams）

UML 语言定义了五种类型，9种不同的图，把它们有 机的结合起来就可以描述系统的所有视图。
用例图(Use case diagram) 从用户角度描述系统功能， 并指出各功能的操作者。
静态图(Static diagram),表示系统的静态结构。包括类图、对象图、包图。
行为图(Behavior diagram), 描述系统的动态模型和 组成对象间的交互关系。包括状态图、活动图。
交互图(Interactive diagram),描述对象间的交互关系。 包括顺序图、合作图
实现图(Implementation diagram)用于描述系统的物 理实现。包括构件图、部件图。

9.2.1 常用模型元素

可以在图中使用的概念统称为模型元素。模型元素在图中用其相应的视图元素(符号)表示，图中给 出了常用的元素符号：类、对象、结点、包和组件等。

用例图定义：由参与者 (Actor)、 用 例(Use Case) 以及它们之间的关系构成的用于描 述系统功能的图成为用例图。
作用：用例图是从软件需求分析到最终实现的第 一步，它显示了系统的用户和用户希望提供的功 能，有利于用户和软件开发人员之间的沟通。用 例图可视化的表达了系统的需求，具有直观、规 范等优点，克服了纯文字性说明的不足。用例方 法是完全从外部来定义系统的，它把需求和设计 完全分离开来，使用户不用关心系统内部是如何 完成各种功能的。

9.2.2 用例图的构成要素

用例图包含3方面内容：

• 来参与者 (Actor)
• 来用例 (Use Case)
• 关系：关 联-- 泛化-- 包含 --扩展

9.3 动态模型

包括4类图：状态图、活动图、顺序图、合作图。
状态图(state diagram): 描述某个对象，子系统，系统 的生命周期。
活动图(activity diagram) : 描述操作实现中完成的工作 以及用例实例或对象中的活动，活动图是状态图的一个变种。
顺序图(sequence diagram): 是一种交互图，描述对象 之间的动态合作关系以及合作过程中的行为次序，常用来 描述一个用例的行为。
合作图(collaboration diagram）: 用于描述相互合作的 对象间的交互关系，它描述的交互关系是对象间的消息连接关系。

9.3.1 顺序图 (又称时序图，序列图)

一、概述
顺序图(Sequence Diagram)用来描述对象之间动态的交互行为，着重体现对象间消息传递的时间顺序。

顺序图构成：
一组对象(对象名和类名)
对象生命线(时间轴)
对象被激活
对象间的通信(消息)

9.3.2 序列图

序列图(机房收费系统-注册)

9.3.3 合作图(又称协作图)

• 合作图(Collaboration Diagram),也称为协作图，用于描述相互合作的对象间的交互关系和 链接(Link) 关系。虽然顺序图和合作图都用来描述对象间的交互关系，但侧重点不一样。
• 顺序图着重体现交互的时间顺序，合作图则着重体现交互对象间的静态链接关系，强调的是发送和接收消息的对象之间的组织结构。

9.4 导图概述

活动图(购物系统)

9.5 3. 泳道

• 泳道进一步描述完成活动的对象，并聚合一组活动。泳道也是一种分组机制。
• 泳道可以直接显示动作在哪一个对象中执行，或显示的是一项组织工作的哪部分。
  

9.6 实现模型

实现模型描述了系统实现时的一些特性，又称为物理体系结构建模。实现模型包括：
构件图(Component diagram)显示代码本身的逻辑 结构，它描述系统中存在的软构件以及它们之间的依赖关系。
配置图(Deployment diagram)描述了系统中硬件和 软件的物理配置情况和系统体系结构。显示系统运行时刻的结构.

9.6.1 构件图

构件 ( component ), 又称组件，可以看作逻辑上 与包与类对应的物理代码模块，实际上是对应一个文件 。
一 、构件的类型：

1. 源代码构件(Source Component);
   << file>> 源代码文件
   <> WEB页
   <> 文档
2. 二进制构件(Binary Component);
3. 可执行构件(Executable Component);

9.7 总结

UML 提供了一系列的图来支持面向对象的分析与设计，其中类图是面向对象系统规模中最常用的图，用于说明系统的静态设计视图；当需要说明系统的静态实现视图时，应该选择组件图；当需要说明体系结构的静态实施视图时，应该选择部署图。用例图对系统的行为进行组织和建模是非常重要的；时序图和协作图都是描述系统动态视图的交互图，生命线是UML 视图中时序图的组成部分；状态图描述一个对象的生命周期，协作图强调收发消息的对象的空间结构。