软件工程复习笔记
软件工程概述
软件
概念：程序+数据+文档
特点：软件是开发的或者是工程化的，并不是制造的；软件生产是简单的拷贝；软件会多次修改；软件开发环境对产品影响较大 软件的开发进度几乎没有客观衡量标准；软件测试非常困难，软件不会磨损和老化；软件维护易产生新的问题
软件危机：
概念：
在计算机软件的开发和维护过程中所遇到的一系列严重问题，这些问题可能导致软件产品的寿命缩短，甚至天折，最终导致的后果就是软件的效率和质量随着软件规模急剧下降。
软件危机产生的原因:
客观—软件本身特点：逻辑部件；规模庞大 主观—不正确的开发方法：忽视需求分析；错误认为软件开发等于程序编写；轻视软件维护
消除途径：软件工程
软件工程
定义：1： 应用系统化的、规范化的、可量化的方法来开发、运行和维护软件。即：将工程应用到软件 。 2： 对 1 中各种方法的研究 。
三要素：方法、工具、过程
原因：软件工程的目标是在给定的时间和预算内，按照用户的需求，开发易修改、高效、可靠、可维护、适应力强、可移动、可重用的软件。消除软件危机。
软件过程
软件生命周期：
三个时期，八份文档
软件过程
概念：是在工作产品构建过程中 所需完成的工作 活动、动作和任务的集合。
软件过程模型：是软件开发全部过程、活动和任务的结构框架的一种概括，它能直观表达软件开发全过程，明确规定要完成的主要 活动、任务或开发策略。
传统软件过程模型
瀑布模型
第一个 软件过程模型，经典生命周期模型，参考上图
是一种以文档为驱动的线性模型，阶段间具有顺序性和依赖性
优点：瀑布模型适用于系统需求明确且稳定、技术成熟、工程管理较严格的场合，如军工、航天、医疗。
缺点：增加工作量，早期错误发现晚，开发风险大，不适应需求变化
原型模型
概念：类比做 ppt 时找 ppt 模板。最终结果是抛弃原型或者进一步完善原型。
优点：减少需求不明确带来的风险，构造原型采用的技术和工具不一定主流 缺点：快速建立起来的系统加上连续的修改可能导致原型质量低下，设计者在质量和原型中进行折中，客户意识不到一些质量问题
增量模型
每次都开发新的一部分，逐步完善（结合了原型模型）。常常和迭代一起使用。（迭代是修改完善原有部分）
每个增量的开发可用瀑布或快速原型模型。
优点：更早应用，初期投入少，适应需求变化，便于维护。
缺点：很难划分增量。软件必须具备开放式体系结构，方便增量。整体控制难。
螺旋模型
结合了瀑布、原型、增量模型，加入风险评估。
优点：适应动态需求，方便开发协作，降低开发风险。
缺点：对成员能力、投入资源要求高，不使用小项目。
敏捷模型：
简化整体开发，小但有激情的团队，最小的软件工程产品
优点：快速响应需求变化，适应激烈竞争环境
喷泉模型（了解）
喷泉模型是一种以用户需求为动力，以对象为驱动的模型，主要用于描述面向对象的软件开发过程。
软件开发早期定义对象，整个开发过程充实和扩充对象。适用于面向对象开发。
不利于项目管理。
专用软件过程模型（了解）
构件开发
核心思想是集成，软件复用
构件 Component：系统中模块化的、可更换的部分，实现特定的功能，对实现进行封装，暴露一组接口
缺点：构件自身难以修改。
Rational 统一过程模型
使用统一建模语言 UML
极限编程
与敏捷开发配合
需求分析
概念：确定系统必须具有的功能和性能，系统要求的运行环境，并且预测系统发展的前景。
过程：需求确认和需求变更
需求确认：有效性、完备性、一致性、现实性
步骤：需求获取 → 需求提炼 → 需求描述（需求规格说明书）→ 需求验证
UML 模型
一个典型的软件系统使用数据结构 （对象模型）， 执行操作（动态模型），并且完成数据值的变化（功能模型）。
功能模型
数据流图，数据字典（了解）。用例图
行为模型（动态模型）
活动图（泳道图）、顺序图（用于系统设计）、状态图
数据模型（对象模型）
类图，用于系统设计
用例图
用例间关系
扩展是有条件执行，包含是子集，泛化是超集
例图
活动图
活动图表明动作间的转换。
状态节点：圆形（开始和结束）；动作节点：圆角矩形；控制流：箭头直线；分支与合并：菱形；同步活动：横条
泳道图
相比活动图增加活动主体，合并横条变竖条
例图
软件设计
八个概念：
抽象；体系结构；设计模式；
模块化：软件被划分为命名和功能相对独立的多个组件（通常称为模块），通过这些组件的集成来满足问题的需求；
信息隐藏：模块划分时遵循信息隐藏原则，即：模块定义和设计时应当保证模块内的信息（过程和数据）不可以被 不需要这些信息的其他模块访问；
功能独立：高内聚低耦合；
细化；重构：不改变组件的功能和行为，优化代码
设计技术（了解）
系统设计：数据设计，架构(体系结构)设计，接口设计，组件设计。部署设计，概要设计/详细设计
数据设计：概念数据模型、物理数据模型（类图）
架构设计：数据中心体系架构；数据流体系架构；调用和返回架构；层级架构；面向对象架构
面向数据流的设计：
由数据流图推导出系统的初始结构图，方法是变换与事务分析
面向过程的组件设计之流程图
盒图、PDL（程序设计语言）、判定表
面向对象的设计
架构设计步骤：构造系统的物理模型，设计子系统，非功能需求设计。
子系统之间的关系(请求-服务关系<=>依赖关系，平等伙伴关系<=>关联关系)
非功能需求主要包括:系统的性能(有效性)、错误监测和故障恢复(可靠性)、系统的安全性、可移植性、和通用性等。
面向对象的用例设计与类设计
覆盖用例的三种类
实体类：用于对必须存储的信息和相关行为进行建模
边界类：参与者与用例之间应建立边界类；用例与用例之间有交互；用例与系统边界之外的非人对象有交互
控制类：来源于对用例场景中动词的分析和定义
类图
需求分析、概要设计、详细设计阶段均可使用
类的描述
可见性级别:“+“公有，“~“默认，“#“保护，“-“私有。
类的关系
依赖(一个类依赖另一个类的定义:成员变量、局部变量、方法形参/返回值)：使用，适合多对多，单向；
public class BClass{
}
public class AClass{
private BClass b1; // 依赖关系情况1:成员变量. 这也是关联关系
public void doWork(BClass b2){ // 依赖关系情况2: 方法参数
}
public void doWork(){
BClass b3; // 依赖关系情况3: 方法内的局部变量
}
}
关联（知道另一个类的属性和方法: 作为成员变量出现）：拥有，一对一或者一对多，单向或者双向
聚合、组合：都是整体与部分的关系；
在聚合中，代表部分事物的对象可以属于多个聚合对象，即为多个聚合对象共享，而且可以随时改变它所从属的聚合对象。
例：大雁聚集在一起形成了雁群，但是离开了雁群的大雁依然可以存在。
在组合中，代表部分事物的对象只属于一个组合对象。脱离了整体，该部分也没有存在的意义。
例：翅膀是组成鸟的局部，翅膀不能脱离一个整体（鸟）而单独存活。
例图
学生成绩管理系统
顺序图
顺序图描述了对象之间传送消息的时间顺序，用来表示用例中的行为顺序，横轴为对象，纵轴为时间。
顺序图的主要用途之一是用来为某个用例的泛化功能提供其所缺乏的解释，即把用例表达的要求转化为更进一步的精细表达 。
组成包括对象，生命线，消息，激活。
对象：命名方式--对象名：类名
生命线：末端打 x 表示消亡
激活：在 UML 中，激活用一个在生命线上的细长矩形框表示。 矩形本身被称为对象的激活期或控制期，对象就是在激活期顶端被激活的。 激活期说明对象正在执行某个动作。当动作完成后，伴随着一个消息箭头离开对象的生命线，此时对象的一个激活期也宣告结束。
消息：顺序图中，尽力保持消息的顺序是从左到右排列的。在各对象之间，消息的次序由它们在垂直轴上的相对位置决定。
例图
质量保证（软件测试）
软件质量
1.定义:明确表示是否符合功能和性能要求，明确地记载开发标准和所有专业开发的软件期望的隐性特点。 2.三个关键点: 符合明确规定的功能和性能要求，即需求中的明确约定(前期约定) 符合文档中明确描述的开发标准，包括企业、行业、地方、国家、国防、国际标准等(明确标准) 符合任何专业开发的软件产品都应该具有的隐含特征，如易用性、可维护性等(共性期望)
软件测试策略
测试策略 V 模型
类比 V 模型。
单元测试
主要目的是验证软件模块是否按详细设计的规格说明正确运行 。
测试内容：单元接口、局部数据结构、独立路径、错误处理路径、边界条件。白盒测试为主。
集成测试
主要目的是检查多个模块间是否按概要设计说明的方式协同工作。
方法：自顶向下和自底向上，广度优先和深度优先。灰盒测试
系统测试
主要目的是验证整个系统是否满足需求规格说明。
从用户使用的角度进行测试，将完成了集成测试的系统放在真实的运行环境下进行。黑盒测试。
压力测试、恢复测试、安全测试、性能测试、功能测试
验收测试
从用户的角度检查系统是否满足合同中定义的需求，以及以确认产品是否能符合业务上的需要。
α 测试：用户在开发环境、模拟用户在模拟实际操作环境下的测试，由用户和开发人员共同参与。
β 测试：多个用户在实际使用环境下进行测试，用户记录所有问题，非正式验收测试的最后阶段。
回归测试
指有选择地重新测试系统或其组件，以验证对软件的修改没有导致不希望出现的影响，以及系统或组件仍然符合其指定的需求。
测试技术常见术语的概念
软件缺陷、验证和确认、测试与质量保证、质量与可靠性、调试与测试
测试用例：测试输入+执行条件+预期结果
黑盒测试
忽略系统或组件的内部机制，仅关注于那些响应所选择的输入及相应执行条件的输出的测试形式。
又叫做功能测试或数据驱动测试。
等价类划分
有效等价类即有意义的，符合要求的数据。
有效等价类的测试用例：一个用例尽可能多的覆盖未被覆盖的有效等价类。
无效等价类的测试用例：每一个用例仅覆盖一个无效等价类。
边界值分析
选取正好等于，刚刚大于，或刚刚小于边界的值做为测试数据做为测试数据。
3 个测试点：上点 、 离点和内点。
n 元函数选点：对每一个变量的上点和离店选取其他变量的内点组成一组 测试用例总共为 4n+1 个
状态测试（了解）
状态转换图
每种状态至少访问一次，测试看起来是最常见和最普遍的状态转换，
测试状态之间最不常用的分支，测试所有错误状态及其返回值，测试状态的随机转换
静态分析（了解）
类型：同事审查，走查（开发内部进行），审查
白盒测试
考虑系统或组件的内部机制的测试形式。
检查范围
对程序模块的所有独立的执行路径 至少测试一次； 对所有的逻辑判定 ，取“真”与取“假”的两种情况都至少测试一次 在循环的边界和运行界限内 执行循环体； 测试内部数据结构的有效性等。
逻辑覆盖
语句覆盖：每一可执行语句至少执行一次
分支覆盖：每个判断的取真分支和取假分支至少经历一次
条件覆盖：设计若干个测试用例，运行被测程序，使得程序中每个判断的每个条件的可能取值至少执行一次。
条件组合覆盖：设计足够的测试用例，运行被测程序，使得每个判断的所有可能的条件取值组合至少执行一次。
控制流图
节点覆盖=语句覆盖。
边覆盖包含节点覆盖，且边覆盖也可以实现分支覆盖。
路径覆盖
基本路径覆盖：将覆盖的路径数压缩到一定限度内，程序中的循环体最多只执行一次。
计算方法 程序基本路径集中的独立路径条数 V(G) = e−n+2 。其中，e 为图中边的数目； n 为节点数目。
确定线性独立路径的基本集合：从源节点（控制流图的入口点）开始，一直走到汇节点（控制流图的出口点）。该路径作为基线路径。接下来，重新回溯基线路径，依次“翻转”在判断节点上原来选择的路径。即当遇到节点的出度大于等于 2 时，必须选择不同的边。
项目管理
项目管理四要素
人员：招聘、 选拔 、 绩效管理 、 培训 、 薪酬 、 职业发展 、 组织和工作设计 、 团队 文化的发展 产品：策划一个项目以前应当建立产品的目标和范围考虑可选的解决方案 项目：理解成功项目管理的关键因素掌握项目计划 、 监控和控制的一般方法 过程：软件过程提供一个框架，在此框架下可以制定项目开发的综合计划 。
软件度量的方法
面向规模的度量
千行代码 KLOC 这些代码指的是源代码，通过源代码的行数来直观度量一个软件程序有多大规模
生产率 PM = L / E, L 表示代码总量 单位：KLOC，E 表示软件工作量 单位：人月
每千行代码的平均成本 CKL = S / L， S 为软件项目总开销 ，L 表示代码总量 单位： KLOC
代码出错率 EQRl = Ne / L ，Ne 表示代码出错的行数，L 表示代码总量 单位： KLOC
文档与代码比 Dl = Pd / L， Pd 表示文档页数， L 表示代码总量 单位： KLOC
面向功能点的度量（了解）
UFC
TCF
面向对象和用例的度量（无）
无
软件估算
基于问题分解的估算
三点期望值法
估计期望值 = （最大值＋ 4 × 最可能值＋最小值 ) / 6
基于经验的软件估算（回归分析的经验估算模型）
基于代码行
指数模型：E=A+B× (ev)^C
其中 A 、 B 、 C 是经验常数， E 是工作量（人月）， ev 是估算变量（ LOC 或功能点）
基于功能点（无）
COCO 经验估算模型（了解）
项目进度计划
甘特图
任务网络图
关键路径--最长
