软件工程期末复习

1、软件生存周期

可行性分析与项目开发计划

解决的问题是什么，是否有可行的解决方法，费用，资源，时间

主要文档有：可行性分析报告和项目开发计划

参加人员：用户、项目负责人、系统分析师

需求分析

明确系统要做什么，而不是怎么做，确定系统的逻辑模型

主要文档：软件需求说明书

参加人员：用户、项目负责人、系统分析师

概要设计

模块间的关系

概要设计就是设计软件的结构，明确软件由哪些模块组成，这些模块的层次结构，模块间的调用关系，模块的功能；数据结构和数据库结构

主要文档：概要设计说明书

参加人员：系统分析师、软件设计师

详细设计

模块的控制结构（针对一个个单独的模块进行详细设计）

文档：详细设计文档

参加人员：软件设计师、程序员

2、软件过程模型

软件过程模型也叫软件开发模型，它是软件开发全部过程、活动和任务的结构框架。

典型的软件过程模型有瀑布模型、增量模型、演化模型（原型模型、螺旋模型）、喷泉模型、基于构件的开发模型和形式化方法模型等。

瀑布模型

瀑布模型是将软件生存周期中的各个活动规定为依线性顺序连接的若干阶段模型，包含需求分析、设计、编码、测试、运行和维护

优点：容易理解，管理成本低，需求明确，二次开发

缺点：要求一开始需求完整

增量模型

增量模型融合了瀑布模型的基本成分和原型实现的迭代特征；增量模型强调每一个增量均发布一个可操作性的产品

优点：

• 第一个可交付版本所需要的成本和时间很少；
• 开发由增量表示的小系统锁承担的风险不大；
• 由于很快发布第一个版本，因此可以减少用户需求的变更
• 运行增量投资，即项目开始时，可以仅对一个或两个增量投资

缺点：管理发生的成本、进度和配置的复杂性可能会超出组织的能力

演化模型

演化模型是迭代的过程模型，使得软件开发人员能够逐步开发出更完整的软件版本。特别适用于对软件需求缺乏认识(软件需求不明确)。典型的演化模型有原型模型和螺旋模型

原型模型

原型方法比较适合于用户需求不清、需求经常变化的情况，且系统规模不大，不复杂

分为：探索性原型、实验型原型和演化型原型

螺旋模型

螺旋模型将瀑布模型和演化模型结合起来，并且加入了两个模型所忽略的风险分析

螺旋模型强调风险分析，因此该模型适用于庞大、复杂且具有高风险的系统

喷泉模型

喷泉模型是一种以用户需求为动力，以对象作为驱动的模型，适用于面向对象的开发方法

喷泉模型使开发过程具有迭代性和无间隙性，也就是说喷泉模型的各个阶段没有明显的界限，开发人员可以同步进行

优点：提高软件项目的开发效率，节省开发时间

缺点：喷泉模型各个开发阶段是重叠的，需要大量开发人员，不利于项目的管理

基于构建的开发模型

基于构建的开发是指利用预先包装的构件来构造应用系统。具有许多螺旋模型的特点，本质是演化模型，需要以迭代方式构建软件

统一过程（UP）模型

统一过程模型是一种“用例和风险驱动，以架构为中心，迭代并且增量”的开发过程，UML方法和工具支持

统一过程定义了4个技术阶段及其制品

起始阶段：生命周期目标

精化阶段：生命周期架构

构建阶段：初始运作功能

移交阶段：产品发布

统一过程的典型代表：RUP，是UP的商业拓展，完全兼容UP，但比UP更完整详细

敏捷方法

敏捷方法的总体目标是通过“尽可能早地、持续地对有价值的软件的交付”

1、极限编程（XP）

XP是一种轻量级（敏捷）、高效、低风险、柔性、可预测的、科学的软件开发方式。它由价值观、原则、实践和行为4个部分，彼此相互依赖、关联，并通过行为贯穿于整个生存周期。

4大价值观：沟通、简单性、反馈和勇气

5个原则：快速反馈、简单性假设、逐步修改、提倡更改和优质工作

12个最佳实践：计划游戏（快速制定计划、随着细节的不断变化而完善）、小型发布（系统的设计要能够尽可能早地交付）、隐喻（找到合适的比喻传达信息）、简单设计（只处理当前的需求，使设计保持简单）、测试先行（先写测试代码，然后在编写程序）、重构（重新审视需求和设计，重新明确地描述它们以符合新的和现有的需求）、结队编程、集体代码所有制、持续集成（可以按日甚至按小时为客户提供可运行版本）、每周工作40个小时、现场客户和编码标准

2、水晶法（Crystal）

水晶法认为每一个不同的项目都需要一套不同的策略、约定和方法论

3、并列争求法（Scrum）

并列争求法使用迭代的方法，其中，把每30天一次的迭代称为一个“冲刺”，并按需求的优先级别来实现产品

4、自适应软件开发（ASD）

ASD有6个基本的原则：

• 有一个使命作为指导；
• 特征被视为客户价值的关键点；
• 过程中的等待是很重要的，因此“重做”与“做”同样关键；
• 变化不被视为改正，而是被视为软件开发实际情况的调整；
• 确定的交付时间迫使开发人员认真考虑每个生产版本的关键需求
• 风险也包含其中

5、敏捷统一过程（AUP）

敏捷统一过程采用“在大型上连续”以及在“在小型上迭代”的原理来构建软件系统。采用经典的UP阶段性活动（初始、精化、构建和准换） 在每个活动里，团队迭代使用敏捷，并将有意义的软件增量尽可能快地交付给最终用户。

每个AUP迭代：建模、实现、测试、部署、配置以及项目管理、环境管理

3、软件项目估算

常用的估算方法有下列三种：

1. 基于已经完成的类似项目进行估算
2. 基于分解技术进行估算
3. 基于经验估算模型的估算

估算两大类：

• 第一类常见方法有：功能点法、代码行法
• 第二类常见方法有Delphi估算法、微软的由底而上估算法等

成本估算方法

• 自定向下估算方法
• 自底向上估算方法
• 差别估算方法
• 其他估算方法
  • 专家估算法
  • 类推估算法
  • 算式估算法

COCOMO估算模型

COCOMO模型按其详细程度分为基本COCOMO模型，中级COCOMO模型和详细COCOMO模型

基本COCOMO模型

是一个静态变量模型，用于对整个软件系统进行估算

E=a(L)^b D=cE^d

E代表工作量，单位是人/月；D表示开发时间，单位是月；L是项目的源代码进行估计值；

abcd是常数

中级COCOMO模型

中级模型以基本COCOMO模型为基础，它将软件系统模型分为系统和部件两个层次，成本驱动型属性函数

E=a(L)^bEAF

详细COCOMO模型

将软件系统模型分为系统、子系统和模块三个层次，考虑了需求分析、软件设计等每一步的成本驱动属性的影响

COCOMOII模型

应用组装模型使用的是对象点；早期设计阶段模型使用的是功能点，功能点可以转换为代码行

Putnam估算模型

动态多变量

L=CkE^(1/3)td(4/3)

td表示持续开发时间（年）

E包括软件开发和维护在整个生存期锁花费的工作量（人/年）

Ck表示技术状态阐述

4、软件进度管理

1、Gantt图

Gantt图用水平条状图描述，它以日历为基准描述任务，可以清楚地表示任务的持续时间和任务之间的并行，但是不能清晰描述各个任务之间的依赖关系

缺点：

不能显示地描绘各项作业间的依赖关系；
进度的关键部分不明确，难以判断哪些部分是主攻和主控的对象；
计划中有潜力的部分及潜力的大小不明确，往往造成潜力的浪费。

2、网络计划法（PERT）

PERT图不仅给出了每个任务的开始时间、结束时间和完成该任务所需的时间，还给出了任务之间的关系，即那些任务完成后才能开始另外一些任务，以及如期完成整个工程的关键路径。图中的松弛时间则反映了完成某些任务时可以推迟其开始时间或延长其所需要完成的时间。

但是，PERT图不能反映任务之间的并行关系

最早时刻为EET，最迟时刻为LET

起点和终点的EET，LET相同

后一个EET等前一个max（EET+路径）

前一个LET等于后一个LET-路径

关键路径：EET=LET

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-42Cj2A5F-1640397390994)(大三上期末复习.assets/image-20211219212239318.png)]

5、软件配置管理

使用配置管理技术，使变更锁所产生的错误达到最小并最有效地提高生产率。

软件配置管理（Sofeware Configure Managerment，SCM）用于整个软件工程过程。其主要目标是标识变更；确保变更正确地实现；报告有关变更。SCM是一组管理整个软件生存周期中各阶段变更的活动

基线

基线是软件生存周期各个开发阶段的一个特定点，它的作用是使各开发阶段的工作划分更加明确，使本来连续的工作在这些点上断开，以便于检查与肯定阶段成果。因此，基线可以作为一个检查点，在开发过程中，当采用的基线发生错误时可以知道所处的位置，返回到最近和最恰当的基线上

软件配置项

软件配置项（Software Configure Item，SCI）是软件工作中产生的信息项，它是配置管理的基本单位，对于已经成为基线的SCI，虽然可以修改，单必须按照一个特殊的、正式的过程进行评估，确认每一处修改。

版本控制

软件配置实际上是一个动态的概念，它一方面随着软件生存周期向前推进，SCI的数量在不断增多，一些文档经过转换生成另一些文档，并产生一些信息；另一方面又随时会有新的变更出现，形成新的版本

变更控制

开发库、受控库、产品库

版本控制工具

版本管理的工作模式发展过程：

单机版（文件系统，RCS 无法协作）===> 集中式（CVS，SVN服务器会宕机；网络崩溃问题） ------> 分布式（Git、Mercurial）

工作区-----(add)-----> 暂存区 -----（push）-----> 本地库

暂存区：.get/index (一个文件)

对象库：.git/objects (一个目录，存放版本库各种对象)，每个对象都是一个文件，前两位作为目录名，后38位作为文件名

对象组成：

blob：存储文件内容

tree：包含其它tree和blob

commit：包含时间、作者、一个tree的标识、父commit的标识

tag：包含一个commit的标识

6、结构化分析

结构化方法就是采用自顶向下逐层分解的思想进行分析建模。自顶向下逐层分解充分体现了分解和抽象的原则。结构化分析方法的分析结果由以下几部分组成：一套分层数据流图、一本数据词典、加工逻辑说明、补充材料

数据流图DFD

数据流图也称数据流程图（Data Flow Diagram,DFD），它是一种便于用户理解、分析系统数据的图形工具。它摆脱了系统的物理内容，精确地在逻辑上描述系统的功能、输入、输出和数据存储等，是系统逻辑模型的重要组成部分。

数据流图的基本图形元素

数据流（Data Flow）、加工（Process）、数据存储（Data Store）和外部实体（External Agent/数据源点）

其中数据流、加工和数据存储用于构建软件系统内部的数据处理模型；外部实体表示存在于系统之外的对象，用来帮助用户理解系统数据的来源和去向

数据流：

• 从一个加工流向另一个加工
• 从加工流向数据存储（写操作）
• 从数据存储流向加工（读）
• 从外部实体流向加工（输入）
• 从加工流向外部实体（输出）

注意：DFD中的每个数据流用一个定义明确的名字表示。除了流向数据存储或从数据存储流出的数据流不必命名外，每个数据流都必须有一个合适的名字

加工：

加工描述了输入数据流到输出数据流之间的变换。

一个加工可以有多个输入流和多个输出流，但至少有一个输入数据流和一个输出数据流

常见错误

1. 有输入没输出
2. 有输出没输入
3. 输入不足以产生输出

使用DFD优点

便于实现与使用

使用原则

1） 数据守恒原则
外部实体与外部实体之间不存在数据流

外部实体与数据存储之间不存在数据流

数据存储与数据存储之间不存在数据流
2） 守恒加工原则
对于每一个加工，必须既有输入数据流。又有输出数据流。
数据流与加工有关，且必须经过加工

数据字典DD

数据字典的任务是: 对于数据流图中出现的所有被命名的图形元素在字典中作为一个词条加以定义，使得每一个图形元素的名字都有一个确切的解释。

数据流图和数据字典共同构成系统的逻辑模型，没有数据字典数据流图就不严格，然而没有数据流图数据字典也难于发挥作用。

数据流图的组成

数据流

数据流分量（即数据元素）

数据存储

处理

7、数据规范化

三范式

第一范式(1NF)
每个属性值都必须是原子值，即仅仅是一个简单值而不含内部结构，“属性原子性”

第二范式(2NF)
满足第一范式条件，而且每个非关键字属性都由整个关键字决定(而不是由关键字的一部分来决定)

第三范式(3NF)
符合第二范式的条件，每个非关键字属性都仅由关键字决定，而且一个非关键字属性不能仅仅是对另一个非关键字局性的进一步描述(即一个非关键字属性值不依赖于另一个非关键字属性值)

8、UML集合

UML是一种标准的图形化建模语言，是面向对象分析与设计的一种标准表示。
是对象管理组织（OMG）制定的一个通用的、可视化的建模语言标准，可以用来可视化（visualize） 、描述（specify）、构造（construct）和文档化（document）

(1) 用例图(Use Case Diagram)，描述系统功能；

(2) 类图(Class Diagram)，描述系统的静态结构；

(3) 对象图(Object Diagram)，描述系统在某个时刻的静态结构；

(4) 组件图(Component Diagram)，描述了实现系统的元素的组织；

(5) 配置图(Deployment Diagram)，描述了环境元素的配置，并把实现系统的元素映射到配置上；

(6) 状态图(State Diagram)，描述了系统元素的状态条件和响应；描述了一个对象的生命周期；动态模型

(7) 时序图(Sequence Diagram)，按时间顺序描述系统元素间的交互；

(8) 协作图(Collaboration Diagram)，按照时间和空间顺序描述系统元素间的交互和它们之间的关系；

(9) 活动图(Activity Diagram)，描述了系统元素的活动；

顺序图 由消息 生命线 对象组成

用例图

用例图（Use Case Diagram）展现了一组用例、参与者（Actor）以及它们之间的关系

组成部分：用例、参与者、用例之间的关系

用例之间关系：扩展关系（<>）、包含关系(<>)和泛化

参与者与用例之间的关系：关联

用例与用例以及参与者与参与者之间的关系：泛化

是外部可见的一种系统功能

代表的是一个完整的功能

有一系列动作

包含关系：基于用例本身是不完整的

扩展关系：基于用例本身是完整的

用例之间是不能有通讯的

用例规约

一个正常的业务事件流描述：

• 只书写“可观测”的
• 使用主动语句
• 句子必须以参与者或系统作为主语
• 不要涉及界面细节
• 分支和循环

用例规约：用例的文字描述，用例的核心

进行用例阐述
成功场景（正常事件流的描述）
扩展场景（备选事件流）
约束等
需要解决的问题

用例之间的关系

包含、拓展、泛化

参与者与用例之间

参与者与参与者之间

泛化关系（继承关系）

类图

聚合和整体的关系

聚合关系：

聚合(Aggregation)关系表示整体与部分的关系
在聚合关系中，成员对象是整体对象的一部分，但是成员对象可以脱离整体对象独立存在

组合关系：

组合(Composition)关系也表示类之间整体和部分的关系，但是在组合关系中整体对象可以控制成员对象的生命周期，一旦整体对象不存在，成员对象也将不存在
成员对象与整体对象之间具有同生共死的关系

顺序图

活动图（从用户角度描述用例）

顺序图（从计算机角度描述用例）

类图（静态结构）	顺序图（动态行为）
类	对象
操作	消息

顺序图（Sequence Diagram）也可叫作序列图、时序图
描述了对象之间传递消息的时间顺序，它用来表示用例的行为顺序。
顺序图的作用：
用对象间的交互来描述用例
寻找类的操作

顺序图的组成

参与者（actor）或者 对象（object）
生命线（lifeline）
激活期(activation)/ 控制焦点（focus of control）
消息（message）

生命线：表示对象的生存时间。生命线从对象创建开始到对象销毁时终止

协作图

它描述对象、对象间的链接及链接对象之间如何发送消息

协作图强调的是空间

不要用协作图来建模过程流，对过程流和行为流建模需要使用活动图

对需要描述消息发送的顺序时使用顺序图

协作图与顺序的的异同

状态图

一种逻辑上的流程机
用于描述一个对象在其生命周期中的动态行为
表现对象响应事件所经历的状态序列以及伴随的动作
揭示Actor、类、子系统和组件的复杂特性。
为实时系统建模

对象在交互中具有不同的状态。
状态可以转换或变换、迁移。
状态的变换需要事件触发。
触发一个状态变换完成需要执行一个动作。

转换五要素：

源状态(Source State)
目标状态(Target State)
触发事件(Trigger Event)
监护条件(Guard Condition)
动作(Action)

组件图

组件图描述了软件的各种组件和它们之间的依赖关系
组件图中通常包含3种元素：组件、接口和依赖关系

类和组件之间也存在着差别：

－类描述了软件设计的逻辑组织和意图；
－组件描述软件设计的物理实现，即每个组件体现了系统设计中特定类的实现。

在软件系统建模过程中，存在3种类型的组件：配置组件、工作产品组件、执行组件

组件的名称有两种：简单名和路径名

配置组件

配置组件是运行系统需要配置的组件，是形成可执行文件的基础
操作系统、Java虚拟机(JVM)和数据库管理系统(DBMS)都属于配置组件

工作产品组件

工作产品组件包括模型、源代码和用于创建配置组件的数据文件，它们是配置组件的来源
工作产品组件包括UML图、Java类和动态链接库(DLL)和数据库表等

执行组件

执行组件是在运行时创建的组件，是最终可运行的系统产生的允许结果。
HTML和XML文档和.NET组件等都是执行组件的

接口

通过使用命名的接口，可以避免在系统中各个组件之间直接发生依赖关系，有利于组件的替换

组件图中的接口也使用一个小圆圈来表示。
接口和组件之间的关系分为两种：实现关系和依赖关系。
接口和组件之间用实线连接表示实现关系；用虚线箭头连接表示依赖关系。 组件的接口分为两种：导入接口和导出接口

接口Interface对于组件Component来说是导出接口，对于组件Component2来说是导入接口。

客户组件依赖于提供者组件；提供者组件只在开发时存在，运行时则不存在。

活动图

通信图

DFD数据流图

（1）数据源点或终点：系统外部环境中的实体（人员，组织或其他软件系统）， 统称外部实体，表达该系统数据的外部来源和去向。

（2）数据处理：（又称加工）对数据进行某些操作或变换，每个处理需要被命名，通常动词短语，简明描述完成什么处理。在分层的数据流图中还应编号。

（3）数据存储：(又称为文件)，指暂时保存的数据，它可以是数据库文件或任何形式的数据组织，一般为表结构。

（4）数据流。数据流是数据传递的路径，因此由一组成分固定的数据组成，箭头表示数据流向。由于数据流是流动中的数据，所以必须有流向，除了与数据存储之间的数据流不用命名外，数据流应该用名词或名词短语命名。

数据流图实例

顶层数据流图

9、面向对象设计

面向对象设计的软件是可维护和可复用的。一个好的系统设计应该具备如下三个性质：
1、可扩展性(Extensibility)
2、灵活性(Flexibility)
3、可插入性(Pluggability)

软件能达到业务功能的需求，不考虑可维护性和可复用性。

1、开闭原则

开闭原则：软件实体应当对扩展开放，对修改关闭。
抽象化是开闭原则的关键

2、单一职责原则

单一职责原则是最简单的面向对象设计原则，用于控制类的粒度大小。
单一职责原则：一个对象应该只包含单一的职责，并且该职责被完整地封装在一个类中。
类的职责：数据职责和行为职责。
将不同的变化原因封装在不同的类中
单一职责原则是实现高内聚、低耦合的指导方针

3、里氏替换原则

里氏代换原则：所有引用基类的地方必须能透明地使用其子类的对象。

里氏代换原则是实现开闭原则的重要方式之一。
在软件中将一个基类对象替换成它的子类对象，程序将不会产生任何错误和异常
反过来则不一定成立，如果一个软件实体使用的是一个子类对象的话，那么它不一定能够使用基类对象
在程序中尽量使用基类类型来对对象进行定义，而在运行时再确定其子类类型多态

使用里氏代换原则需注意的问题：
子类的所有方法必须在父类中声明，或子类必须实现父类中声明的所有方法。
尽量将父类设计为抽象类或接口，让子类基础父类或实现父接口，并实现父类中声明的方法。

4、依赖倒转原则

依赖倒转原则：高层模块不应该依赖低层模块，它们都应该依赖抽象。抽象不应该依赖于细节，细节应该依赖于抽象
要针对接口编程，不要针对实现编程

在程序中尽量使用抽象层进行编程，而将具体类写在配置文件中

5、接口隔离原则

接口隔离原则定义：客户端不应该依赖那些它不需要的接口

接口隔离原则分析
当一个接口太大时，需要将它分割成一些更细小的接口
使用该接口的客户端仅需知道与之相关的方法即可
每一个接口应该承担一种相对独立的角色

6、合成复用原则

合成复用原则又称为组合/聚合复用原则

优先使用对象组合，而不是继承来达到复用的目的

合成复用原则就是在一个新的对象里通过关联关系（包括组合关系和聚合关系）来使用一些已有的对象，使之成为新对象的一部分
新对象通过委派调用已有对象的方法达到复用功能的目的
复用时要尽量使用组合/聚合关系（关联关系），少用继承

合成复用原则分析

继承复用

实现简单，易于扩展。破坏系统的封装性；从基类继承而来的实现是静态的，不可能在运行时发生改变，没有足够的灵活性；只能在有限的环境中使用。（“白箱”复用 ）

组合/聚合复用

耦合度相对较低，有选择性地调用成员对象的操作；可以在运行时动态进行，新对象可以动态地引用与成员对象类型相同的其他对象。（“黑箱”复用 ）

7、迪米特原则

米特法则又称为最少知识原则
迪米特法则：每一个软件单位对其他的单位都只有最少的知识，而且局限于那些与本单位密切相关的软件单位。

迪米特法则要求一个软件实体应当尽可能少地与其他实体发生相互作用
应用迪米特法则可降低系统的耦合度，使类与类之间保持松散的耦合关系

迪米特法则要求在设计系统时，应该尽量减少对象之间的交互
如果两个对象之间不必彼此直接通信，那么这两个对象就不应该发生任何直接的相互作用
如果其中一个对象需要调用另一个对象的方法，可以通过“第三者”转发这个调用
通过引入一个合理的“第三者”（中间类）来降低现有对象之间的耦合度

设计原则	定义	考试频率
单一职责原则(SRP)	一个对象应该只包含单一的职责，并且该职责被完整地封装在一个类中	★★★★☆
开闭原则( OCP)	软件实体应当对扩展开放，对修改关闭	★★★★★
里氏代换原则(LSP)	所有引用基类的地方必须能透明地使用其子类的对象	★★★★★
依赖倒转原则( DIP)	高层模块不应该依赖低层模块，它们都应该依赖抽象。抽象不应该依赖于细节，细节应该依赖于抽象	★★★★★
接口隔离原则( ISP)	客户端不应该依赖那些它不需要的接口	★★☆☆☆
合成复用原则( CRP)	优先使用对象组合，而不是继承来达到复用的目的	★★★★☆
迪米特法则( LoD)	每一个软件单位对其他的单位都只有最少的知识，而且局限于那些与本单位密切相关的软件单位	★★★☆☆

10、数据建模与数据库设计

1、数据库设计的基本过程

概念设计、逻辑设计、物理设计

在UML中表用类表示，带有图标 或构造型<

>

2、表间关系

表之间的任何依赖关系称为联系（Relationship）。
联系有两种：非标识关系和标识关系。

非标识关系（Non-Identifying Relationship）：子表的数据实例不能通过与父表的关联识别，即父表的主键属性成为子表的非主键属性

标识关系（Identifying Relationship）：子表的数据实例能够通过与父表的关联识别，即父表的主键属性成为子表的主键属性

3、视图

视图（View）是一个虚表，它代表具有相同结构的一组数据记录，只不过它的物理上的数据来源是某一个或多个表。
视图不是物理存在的，它不包含真正存储的数据，不占存储空间；但视图可以象一般的表那样操作（少有限制）
真正物理存在的表称作实表或基本表
在同一个基本表上可以创建多个视图，一个视图也可以在几张表上创建。此外，一个视图也可以从另一个视图创建

在UML中，视图用图标盒子或构造型<< View >>的类表示。

4、泛化映射

为父类和每一个子类创建一个表，同时视需要可为每一个父类/子类各创建一个视图。
为父类创建一个表，将子类的所有列信息存入到父类表中，即将表示泛化联系的层次结构（继承）简单地转换为一个表。
为每一个子类创建一个表，将父类的所有列信息存入到每个子类表中。

5、触发器与存储过程

触发器Trigger是与表紧密联系在一起的，通常作为保证表数据完整性的约束操作在表中定义。当对表数据进行增、删、改等操作时，触发器被自动激发执行

触发器使用构造型<< Trigger >>表示，它加在一个操作名称的前面，以标志该操作是一个触发器

存储过程Stored Procedure是一种对数据库进行数据操作和运算的程序过程，是经过事先编译的存储在数据库内部的过程，供应用程序调用。一个存储过程可以是依附于某个表的，也可以是独立的。
在数据库建模中，一个或多个存储过程可以组织成存储过程集，用带有构造型<< SP Container >>的类图标表示，在其中的操作框中列出每个存储过程的名称、类型、参数，并在前面标记<< SP >>。

11、软件测试

为了发现错误(寻找软件缺陷)而执行程序的过程----否定测试

测试是一种旨在评估一个程序或系统的属性或能力，确定它是否符合其所需结果的活动—肯定测试

测试是一个为了寻找错误而运行的过程
一个好的测试用例是指很可能找到迄今为止尚未发现的错误的用例
一个成功的测试是指揭示了迄今为止尚未发现的错误的测试

测试的原则

所有的测试都应追溯到需求
应该在测试工作真正开始前的较长时间就进行测试计划
Pareto（20-80）原则应用于软件测试
测试应从“小规模”开始，逐步转向“大规模”
穷举测试是不可能的
集成测试和系统测试应该由独立的测试部门和第三方测试机构来承担。

测试的策略

ide测试开始于模块层，然后延伸到整个基于计算机的系统集合中
根据测试对象的层次，可以将软件测试策略分为单元测试、集成测试和系统测试。
不同的测试技术适用于不同的时间点
测试和调试是不同的活动，但是调试必须能够适应任何的测试策略

验证和确认

软件测试是“验证和确认”的一部分
验证指的是保证软件正确地实现了某一特定功能的一系列活动，试图证明在软件生存期各个阶段以及阶段间的逻辑协调性、完备性和正确性

确认指的是保证软件的实现满足了用户需求的一系列活动，目的是要证实在一个给定的外部环境中软件的逻辑正确性

静态测试

不实际运行程序，而是通过检查和阅读等手段来发现错误并评估代码质量的软件测试技术 也称为静态分析技术

静态分析：对代码的机械性、程式化的特性分析方法

代码审查：小组集体阅读讨论检查代码

代码走查：小组集体用“脑”执行并检查代码

技术评审：会议形式讨论检查代码

桌面检查：由程序员阅读自己编写的程序

动态测试

白盒测试：控制结构测试；基本路径测试
黑盒测试：功能分解；等价类划分；边值分析；因果图；随机测试；猜错法

白盒测试

语句覆盖

选取足够多的测试数据，使被测试程序中每个语句至少执行一次。

判定覆盖

选取足够多的测试数据，使被测试程序中不仅每个语句至少执行一次，而且每个判定的每种可能的结果都至少执行一次

条件覆盖

选取足够多的测试数据，使被测试程序中不仅每个语句至少执行一次，而且每个判定表达式中的每个条件都取到各种可能的结果

判定/条件覆盖

选取足够多的测试数据，使得判定表达式中的每个条件都取到各种可能的结果，而且每个判定表达式也都取到各种可能的结果

条件组合覆盖

选取足够多的测试数据，使得判定表达式中条件的各种可能组合都至少出现一次

路径覆盖

选取足够多的测试数据，使得程序的每条可能路径都至少执行一次（若程序图中有环，则每个环至少经过一次）

环路复杂度

黑盒测试

黑盒测试不深入代码细节

黑盒测试的缺点有：
1）功能性测试的覆盖范围不可能达到100%。
2）自动化测试的复用性较低。
3）如果外部特性本身设计有问题或规格说明的规格有问题，用黑盒测试方法是发现不了的。
4）测试用例数量大，测试用例可能会有很多冗余。
5）黑盒测试不能替代白盒测试，而是用来发现白盒测试以外的其他类型的错误。

等价类划分

等价类是指某个输入域的子集合。在该集合中，各个输入数据对于揭露程序中的错误都是等价的。
有效等价类：符合需求规格说明书，合理的输入数据的集合；
无效等价类：不符合需求规格说明书，无意义的输入数据集合

等价类划分法测试设计用例

(1) 对每个输入或外部条件进行等价类划分，形成等价类表，为每一等价类规定一个唯一的编号；
(2)设计一测试用例，使其尽可能多地覆盖尚未覆盖的有效等价类，重复这一步骤，直到所有有效等价类均被测试用例所覆盖；
(3)设计一新测试用例，使其只覆盖一个无效等价类，重复这一步骤直到所有无效等价类均被覆盖；

判定表法

黑盒白盒比较

测试过程

单元测试

目标：
检验程序最小单元有无错误
接口、数据结构、边界、覆盖、逻辑
检验单元编码与设计是否吻合
时机：
编码完成后，首先要实施的测试
方法：
静态测试
白盒测试
责任：
开发工程师

系统测试

目标：
检验组成整个系统的代码、以及系统的软硬件配合有无错误
代码实现的系统与用户需求是否吻合
检验系统的文档等各种是否完整、有效
模拟验收测试的要求，检查系统是否符合用户的验收标准
时机：多数集成测试完成后
方法：黑盒测试
责任：测试工程师

验收测试

目标：
使客户验收签字
系统是否符合事先约定的验收标准
时机：
系统测试完成后，在项目组看来开发和测试工作已经全部完成，可以交付使用
方法：黑盒测试

回归测试

目标：
验证程序修改或者版本更新以后，以前正确的功能和其他指标仍旧正确。
时机：
每次错误修改之后，或者版本更新之后
方法：
白盒测试/黑盒测试

Alpha测试和Beta测试

采用Alpha测试和Beta测试来发现只有最终用户才能发现的问题
Alpha(α )测试：由一个用户在开发者的场所、在开发者指导下进行测试
Beta(β )测试：由最终用户在一个或多个用户场所单独地进行测试

12、选择题

1、开发软件所需高成本和产品的低质量之间有尖锐的矛盾，这种现象称作软件危机

• 开发的软件不满足用户的需要
• 开发的软件可维护性差
• 开发的软件可靠性差

2、软件开发计划是软件工程中的一种管理性文档

3、需求评审将对项目提供可行性评估（错）

4、研究软硬件资源的有效性是进行技术可行性研究的一方面

5、UML状态图中的状态可以分解为“与”状态，以及“或”状态，但是都可以转换为基本状态机来表示

6、系统用例是可观测的，要从系统的角度进行描述（错）

7、检查软件产品是否符合需求定义的过程称之为确认测试

8、需求分析是软件开发工作的基础

9、软件可行性一般不考虑待开发的软件是否有质量问题

10、数据流图和数据字典共同组成系统的功能模型

11、瀑布模型本质上是一种线性顺序模型

12、软件项目的进度安排的两种比较常用的方法是程序评估与审查技术（PERT）和关键路径法（CPM）

13、功能需求制定系统必须提供的服务，是对软件系统的一项基本需求，但却并不是唯一的需求

14、使用白盒测试方法时，确定测试数据应根据程序的内部逻辑和指定的覆盖标准

15、采用工程的概念、原理、技术和方法来开发 维护软件，把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来，以经济地开发出高质量的软件并有效地维护它，这就是软件工程

16、原型模型是用户和设计交换最频繁的方法

17、顺序图由消息，生命线和对象组成

18、软件工程由方法、工具和过程三部分组成，称软件工程的三要素

19、项目开发效益包括成本效益和社会效益两部分

20、经济可行性研究主要是从成本和效益两方面进行分析

21、问卷调查方法最适用于身处多个不同地点的人在各自方便的时间参与并围绕同一个主题表达自己的观点

22、赶工一个任务时，应该关注加速执行关键路径上的任务

23、软件测试是为了发现程序中的错误而执行程序的过程

24、软件开发的可行性研究，一般涉及经济、技术和操作的可能性，而进行可行性研究的基本依据则是用户提出的软件系统目标

25、与瀑布模型最典型地刻画了软件生命周期的阶段划分，结构化方法与其最相适应

26、故事点表示开发一个用户故事或特性所要付出的工作量（对）

27、所谓管理就是通过计划、组织、协调、控制等一些列活动，合理地配置和使用各种资源，以达到既定目标的过程

28、在敏捷开发方法中，用户故事（User Story）的作用：

• 定义需要发布给最终用户的软件特性和功能
• 用于估算构建当前增量所需要的努力

29、软件会逐渐退化而不会磨损，其原因在于不断的变更使组件接口之间引起错误

30、造成大型软件开发困难的根本原因在于软件系统的复杂性

31、与用户沟通获取需求的方式有很多，其中自底向上的求精方法不属于获取需求的方式

32、软件工程是一种层次化的技术，质量关注度是软件工程的根基

33、在软件开发中，成本—效益分析是指对将要开发的系统的开发成本进行估算，然后与可能取得的效益进行比较和权衡

34、可行性研究也称为：项目论证

35、在面向对象设计中，基于父类创建的子类具有父类的所有特性（属性和方法），这一特点称之为类的封装性

36、支持10万以上日活跃用户进行各种点赞、评论等交互活动，应该采用Mongo+Redis数据库或数据库组合

37、状态迁移的发生不会收到目标状态的影响

38、顺序图描述了一组交互对象间的动作协作关系，它表示完成某项行为的对象和这些对象之间传递消息的时间顺序

39、状态图描述一个对象的生命周期

40、验证指的是保证软件正确地实现了某一特定功能的一些列活动，试图证明在软件生存期各个阶段以及阶段间的逻辑协调性、完备性和正确性

41、软件技术复审是由用户和测试人员实施的一种质量保证活动（错）

42、每个判定表达式中条件的各种可能组合至少出现一次 ，称之为判定覆盖