1.UML
参考讲解：UML详细讲解
参考讲解：状态图的基本概念和作用
用例模型中各种类的作用
- 边界类，用于描述外部参与者与系统之间的交互的类。
- 控制类，控制其他类； 每个用例通常有一个控制类，控制用例中的事件顺序，控制类也可以在多个用例间共用。 其他类并不向控制类发送很多消息，而是由控制类发出很多消息。
- 实体类，存储信息和相关行为的类； 实体类保存要放进持久存储体的信息。持久存储体就是数据库、文件等可以 永久存储数据的介质。实体类可以通过事件流和交互图发现。通常每个实体类在数据库中有相应的表，实体类中的属性 对应数据库表中的字段。
用例之间的关系
- 泛化：描述了两个对象类之间的一般化/特殊性关系，它可以使子对象类共享父对象类的属性和方法。 宝马汽车 – 汽车
- 实现关系：和泛化关系相似，区别在于实现关系继承一个抽象类。 汽车 – 车
- 依赖关系-包含：一个用例（基用例）可以包含其他用例（包含用例）具有的行为。 码农 – 电脑
- 依赖关系-扩展：一个用例（扩展用例）对另一个用例（基用例）行为的增强。
- 组合关系：是整体与部分的关系，但部分不能脱离整体而独立存在。 部门 – 公司
- 聚合关系：是整体与部分的关系，部分能脱离整体而独立存在。 轮胎 – 汽车
- 关联关系：是整体与部分的关系。 老师 – 学生
什么是UML状态图，它的作用是什么？
- 定义
一个状态图（Statechart Diagram）本质上就是一个状态机，或者是状态机的特殊情况，它基本上是一个状态机中元素的一个投影，这也就意味着状态图包括状态机的所有特征。状态图描述了一个实体基于事件反映的动态行为，显示了该实体是如何根据当前所处的状态对不同的事件作出反应的。 - 作用
- 状态图清晰地描述了状态之间的转换顺序，通过状态的转换顺序也就可以清晰地看出事件的执行顺序。如果没有状态图我们就不可避免地要使用大量文字来描述外部事件的合法顺序。
- 清晰的事件顺序有利于程序员在开发程序时避免出现事件顺序错误的情况。例如，对于一个网上销售系统，在用户处于登录状态前是不允许购买商品的，这就需要程序员开发程序的过程中加以限制。
- 状态图清晰地描述了状态转换时所必需的触发事件、监护条件和动作等影响转换的因素，有利于程序员避免程序中非法事件的进入。例如，飞机起飞前半小时不允许售票，在状态图中就可以清晰地看到，可以提醒程序员不要遗漏这些限制条件。
- 状态图通过判定可以更好地描述工作流因为不同的条件发生的分支。例如，当一个班的人数少于10人的时候需要和其他班合为一班上课，大于10人则单独上课，在状态图中就可以很明确地表达出来。
2.软件生存周期的基本过程
- 获取过程：为需方而定义的活动，启动，招标，合同，对供方监督，验收等
- 供应过程：为供方而定义的活动，启动，准备投标，签订合同，编制计划，执行，交付和完成
- 开发过程：为开发方而定义的活动：需求、设计、编码、测试、安装、验收
- 运作过程：为操作方而定义的活动：运行测试，系统运行，用户支持。也叫运行过程
- 维护过程：为维护方而定义的活动：问题和修改分析，修改实现，维护评审/验收，迁移，软件退役
在软件生命周期的需求分析阶段中出错，对软件质量影响最大。
越靠上的环节出现问题，造成的影响越大
3.软件测试
- 黑盒测试：等价类划分、边界值分析法、猜错法、因果图
- 白盒测试：代码检查法、静态结构分析法、静态质量度量法、逻辑覆盖法、基本路径测试法、域测试、符号测试、路径覆盖和程序变异
- 单元测试 – 详细设计；
- 集成测试 – 概要设计；
- 系统测试 – 规格说明书；
- 验证测试 – 需求分析（正确实现需求）；
软件测试中，语句覆盖的定义：设计若干个测试用例，运行被测试程序，使得每一条可执行语句至少执行一次。
白盒测试中的逻辑覆盖测试
逻辑覆盖即为逻辑结构的覆盖测试，它是以程序内部的逻辑结构为基础设计测试用例的技术。
根据覆盖要求不同，可以分为以下几类：
- 语句覆盖
所谓语句覆盖就是设计若干个测试用例，运行被测程序，使得每一可执行语句至少执行一次。这里的“若干个”，意味着使用测试用例越少越好
语句覆盖是最弱的逻辑覆盖准则。 - 判定覆盖
判定覆盖又称分支覆盖，使程序中每个判定的取真分支和取假分支至少执行一次。 - 条件覆盖
使得程序中每个条件的可能取值至少取得一次。 - 条件/判定覆盖
判定覆盖和条件覆盖的组合 - 条件组合覆盖
使得每个判定的所有可能的条件取值组合至少执行一次。 - 路径覆盖
设计足够多的测试用例，执行程序中所有可能的路径。
路径覆盖是最强的逻辑覆盖准则。
4.E-R模型：实体联系模型
基本成分
- 实体：用矩形框表示
- 属性：用椭圆框表示
- 联系：用菱形框表示并在连线上注明联系的类型，即1-1、1-n、m-n
两个实体之间的联系方式
- 一对一
- 一对多
- 多对多
- 弱实体
- 特殊化
- 聚集
- 三元联系
5.软件过程模型
参考讲解：软件过程模型（软件开发模型）
- 瀑布模型
- 螺旋模型 适用于软件需求不明确的项目开发
- 增量模型
- 喷泉模型
- 演化模型 适用于软件需求不明确的项目开发
-
螺旋模型和演化模型都适用于软件需求不明确的项目开发
-
螺旋模型是在瀑布模型和演化模型的基础上加以修改而形成的
-
增量模型是在瀑布模型的基础上加以修改而形成的
-
每一个增量开发过程都要有明确的需求。螺旋模型 = 瀑布模型 + 演化模型 + 风险分析活动；识别风险迭代的进行。
-
属于增量模型开发活动的是增量分析、 增量设计、 增量实现
-
增量模型是把待开发的软件系统模块化，将每个模块作为一个增量组件，从而分批次地分析、设计、编码和测试这些增量组件。开发活动仅包括：需求、设计、实现、确认、支持。
-
瀑布模型与喷泉模型的主要区别是支持不同的软件开发方法
- 瀑布模型开发方法：结构化分析
- 喷泉模型开发方法：面向对象开发范型
6.需求开发活动包括
- 需求获取
- 需求分析
- 需求定义、验证
7.正式技术评审的目的
- 发现软件在功能、逻辑、实现上的错误，即发现和改正程序中的错误
- 验证软件符合它的需求规格
- 确认软件符合预先定义的开发规范和标准
- 保证软件在统一的模式下进行开发
- 便于项目管理
8.CMMI
- 定义
能力成熟度模型。它是对于软件组织在定义、实施、度量、控制和改善其软件过程的实践中各个发展阶段的描述。CMM的核心是把软件开发视为一个过程，并根据这一原则对软件开发和维护进行过程监控和研究，以使其更加科学化、标准化、使企业能够更好地实现商业目标。 - 级别
- CMMI1级，执行级
- CMMI2级，管理级
- CMMI3级，明确级
- CMMI4级，量化级
- CMMI5级，优化级
CMM 认为，支撑软件质量的三要素是过程、管理、技术
9.内聚和耦合
- 内聚【内聚越高越好】
- 偶然内聚
一个模块完成一组任务，任务与任务之间关系松散，或者没有关系 - 逻辑内聚
把几种功能组合在一起，每次调用时，由传递给模块的判定参数来决定模块实现哪一个功能 - 时间内聚
一个模块包含的任务必须在同一段时间内执行 - 过程内聚
一个模块内的处理元素是相关的，并以特定次序执行 - 通信内聚
模块中所有元素都使用同一个输入数据或者产生同一个输出数据 - 顺序内聚
模块内的处理元素和同一个功能密切相关，并且处理顺序必须顺序执行 - 功能内聚
一个模块中所有元素都是完成某一功能所必需的处理，缺一不可，模块已不可再分
- 偶然内聚
- 耦合【耦合越低越好】
- 内容耦合
A可以直接访问B的数据 - 公共耦合
当两个或者多个模块共同使用一个公共数据环境时，它们之间的耦合即为公共环境耦合，其复杂度随着模块数量的增加显著增加。
公共环境可以是：全程变量、共享的通信区、内存的公共覆盖区、任何存储介质上的文件、物理设备等 - 外部耦合
都访问同一简单全局变量，但不是通过参数表传递 - 控制耦合
都访问同一简单全局变量，但不是通过参数表传递 - 标记耦合
整个数据结构作为参数传递时，被调用的模块只需要使用其中一部分元素 - 数据耦合
两个模块之间，只通过参数交换数据 - 非直接耦合
两模块间无直接关系
- 内容耦合
10.软件规模度量方法
- 功能点
- 对象点
- 用例点
- 故事点
- 代码行
11.软件质量审查中验证和确认
- 验证：通过提供客观证据对规定要求已得到满足的认定
- 确认：通过提供客观证据对特定的预期用途或应用要求已得到满足的认定。确认所适用的条件可以是实际的或模拟的
验证和确认的区别：
验证和确认都是“认定”。但是“验证”表明的是满足规定要求，而“确认”表明的是满足预期用途或要求。简单说“确认”就是检查最终产品是否达到顾客使用要求。
“确认”是要证明所提供的（或将要提供的）产品适合其预计的用途，而“验证”则是要查明工作产品是否恰当的反映了规定的要求。换句话说，验证是要保证“做的正确”，而确认则要保证“做的东西正确”。
验证注重过程，确认注重结果。
12.数据流图
参考讲解：软件工程 — 数据流图的画法_CodeJiao的博客-CSDN博客
-
定义：数据流图(Data Flow Diagram，DFD)是一种图形化技术，它描绘信息流和数据从输入移动到输出的过程中所经受的变换。
-
基本构成成分（4中图形符号）
- 正方形（或立方体）表示数据的源点或终点；
- 圆角矩形（或圆形）代表变换数据的处理；
- 开口矩形（或两条平行横线）代表数据存储；
- 箭头表示数据流，即特定数据的流动方向。