前言：02333软件工程自考，内容方面比较枯燥，理论知识点比较零散，建议结合思维导图*（附录1）进行学习，会更加系统，记忆性更强。考试的话，还是需要多多刷题。
如果文中有错漏的地方，请留言/私信提醒我修改，谢谢。

02333自考软件工程知识点总结、考点串讲、考前复习

• 第1章 绪论
• • 1.1 软件工程概念的提出与发展
  • 1.2 软件开发的本质
• 第2章 软件需求与软件需求规约
• • 2.1 需求与需求获取
  • 2.2 需求规约
• 第3章 结构化方法
• • 3.1 结构化需求分析
  • 3.2 结构化设计
• 第4章面向对象方法—UMI
• • 4.1 UML术语表
  • 4.2 UML的模型表达式
• 第5章 面向对象方法——RUP
• • 5.1 RUP的特点
  • 5.2 核心工作流
• 第6章软件测试
• • 6.1 软件测试目标与软件测试过程模型
  • 6.2 软件测试技术
  • 6.3 软件测试步骤
• 第7章 软件生存周期过程与管理
• • 7.1 软件生存周期过程概述
  • 7.2 过程描述
  • 7.3 应用说明
  • 7.4 软件生存周期模型
  • 7.5 过程规划与管理
• 第8章集成化能力成熟度模型(CMMI)
• • 8.1 背景和原理
  • 8.2 CMMI的模型部件
  • 8.3 CMMI的等级
• 附录1 软件工程思维导图

第1章 绪论

1.1 软件工程概念的提出与发展

1.软件工的概念
软件工程是应用计算机科学理论和技术以及工程管理原则和方法，按预算和进度实现满足用户要求的软件产品的工程，或以此为研究对象的学科。
2.“软件危机”现象
20世纪60年代以来，随着计算机的广泛使用，软件生产率、软件质量远远满足不了 会发展的需求，成为 会、经济发展的制约因素，人们通常把这一现象称为“软件危机”

1.2 软件开发的本质

本质：不同抽象层术语之间映射，以及不同抽象层处理逻辑之间的映射。
1、软件的概念
计算机软件一般是指计算机系统中的程序及其文档。其中，程序是计算机任务的对象和处理规则的描述；文档是为了理解程序所需的阐述性资料。
2.模型概念
简单地说，模型就是待建模系统的任意抽象，其中包括所有的基本能力、特性或其他一些方面，而没有任何冗余的细节。
进一步说，模型是在特定意图下所确定的角度和抽象层次上对物理系统的描述，通常包含对该系统的描述、对系统内各模型元素以及它们之间关系的语义描述。
3.求解问题的基本途径
为了求解其中的非结构化和半结构化问题，其基本途径是问题建模，问题建模是指运用所掌握的知识，通过抽象，给出该问题的一个结构。
常用的建模手段包括：结构化方法、面向对象方法以及诸多向数据结构方法等。
4.模型的分类
在软件开发中，软件系统模型大体可分为两类：概念模型和软件模型。概念模型是创建在需求层上的，它描述了系统是什么；软件模型是创建在抽象层上的，它描述了实现概念模型的软件解决方案。软件模型可进一步分为设计模型、实现模型和部署模型。

第2章 软件需求与软件需求规约

2.1 需求与需求获取

1.需求定义及其基本特性
一个需求是有关一个“要予构造”的陈述，描述了待开发产品/系统（或项）功能上的能力、性能参数或其他性质。
对于单一一个需求，必须具有五个基本特性：
（1）必要的，该需求是用户说要求的；
（2）无歧义的，该需求只能用一种方式解释；
（3）可测的，该需求是可以进行测试的；
（4）可跟踪的，该需求可从一个开发阶段跟踪到另一个阶段；
（5）可测量的，该需求是可测量的。
2.功能需求和非功能需求
功能需求规约了系统或系统构件必须执行的功能。
非功能需求：分为性能需求、外部借口需求、设计约束和质量属性需求。
3.需求发现技术
初始发现需求的常用技术，如下所示

2.2 需求规约

1.需求规约定义及其基本特性
需求规约是一个软件项/产品/系统所有需求陈述的正式文档，它表达了一个软件产品/系统的概念模型、
需求规约一般要满足四个基本特性
（1）重要性和稳定性程度：按需求的重要性和稳定性，对需求进行分级，例如：基本需求、可选需求、期望需求
（2）可修改的：在不过多地影响其他需求的前提下，可以容易地修改一个单一需求。
（3）完整的：没有遗漏的需求。
（4）一致的：不存在互斥的需求。
2.需求规约的表达
在实际工程中，需求规约的表达主要存在三种不同的风格。
（1）非形式化的需求规约。
（2）半形式化的需求规约。
（3）形式化的需求规约。
3.需求规约在软件开发中的作用
（1）需求规约是软件开发组织和用户之间一份事实上的技术合同书，是产品功能及其环境的体现。
（2）对于项目的其余大多数工作，需求规约是一个管理控制点。
（3）对于产品/系统的设计，需求规约是一个正式的、受控的起始点。
（4）需求规约是创建产品验收测试计划和用户指南的基础，即基于需求规约一般还会产生另外两个文档——初始测试计划和用户系统操作描述。

第3章 结构化方法

3.1 结构化需求分析

1.表达问题域信息的基本术语及其表示
（1）数据流：在结构化分析方法中，数据流是数据的流动，用于表达在分析中所要使用的、用于表达“客体”的信息。
（2）加工：在结构化分析方法中，加工是数据的变换单位，即它接受输入的数据，对其进行处理，并产生输出。
（3）数据存储：数据存储是数据的静态借口。
（4）数据源和数据潭：数据源是数据流的起点，数据潭是数据流的归宿地。数据源和数据潭是系统之外的实体，可以是人、物或其他软件。它们均用一个矩形表示。
2.表达功能模型的工具——DFD图
DFD图，即数据流图，是表达功能模型的工具。它是一种描述数据变换的图形化工具，其中包含的元素可以是数据流、数据存储、加工、数据源和数据潭等。
3.数据字典、判定表和判定树
（1）在数据字典中，为了使一义的结构数据便于理解和阅读，一般按三种条目来组织，即数据流条目、数据存储数目和数据条目。
（2）判定表：判定表是用以描述加工的一种工具，通常用来描述一些不易用自然语言表达清楚或需要很大篇幅才能表示清楚的加工。
（3）判定树：判定树也是一种描述加工的工具，判定表可以用判定树等价表示。
4.结构化分析方法中每一术语在建模中的作用
（1）数据流用于表达在分析中所要使用的、用于表达“客体”的信息。
（2）加工用于表达在分析中所要使用、用于表达“处理”的信息。
（3）数据存储用于表达在分析中所要使用的、用于表达“结构化客体”的信息。
（4）数据源和数据潭为了表示系统的环境，可以使用它们和相关数据流来定义系统的边界。
5.构建系统功能模型的步骤
（1）建立系统环境图，确定系统语境、
（2）自顶向下，逐步求精，建立系统的层次数据流图。
（3）定义数据流。
（4）描述加工。
6.需求验证中发现的错误类型及方法
（1）需求验证中发现的错误类型有不正确的事实、遗漏、不一致、歧义性、错放及其他。
（2）需求验证中发现错误的方法有审查、单元测试、评估、集成和其他。

3.2 结构化设计

1.变换型数据流图和事务型数据流图
（1）变换型数据流图：具有较明显的输入部分，和变换部分之间的界面、变换部分和输出部分之间界面的数据流图，称为变换型数据流图。
（2）事务型数据流图：数据到达一个加工T，该加工T根据输入数据的值，在其后的若干动作序列中选出一个来执行，这类数据流图称为事务型数据流图。
2.模块以及模块内聚和耦合
（1）模块。模块是执行一个特殊任务的一个过程你以及相关的数据结构，通常有两个部分组成，一部分是接口，另一部分是模块体。
（2）模块内聚。内聚是指一个模块内部各成分之间相互关联程度的。从低到高常见的内聚类型有：偶然内聚、逻辑内聚、时间内聚、过程内聚、通信内聚、顺序内聚、功能内聚。
（3）模块耦合。耦合是指不同模块之间相互依赖程度的量。从强到弱常见的耦合类型有：内容耦合、公共耦合、控制耦合、标记耦合、数据耦合。
3.详细设计工具：框图、PAD图、N-S图和伪码
（1）框图。程序流程图又称框图，是软件设计的主要工具，是历史最悠久，使用最广泛的软件设计工人。
（2）PAD图。是问题分析图的缩写。
（3）N-S图。N-S图又称为盒图。
（4）伪码（PDL）。类程序设计语言也成为伪码，它是一种正文形式表示数据结构和处理过程的设计工具。PDL是一种“混合”语言。
4.变换设计和事务设计
（1）变换设计。变换设计是在需求规约的基础上，经过一系列设计步骤，将变换型数据流图转换成系统的模块结构图。基本步骤是：
·设计准备——复审并精化系统模型；
·确定输入、交换、输出这三部分之间的边界；
·第一级分解——系统模块结构图顶层和第一层的设计；
·第二级分解——自顶向下，逐步求精。
（2）事务设计。当数据流图具有明显的事务型特征时，也就是有一个明显的事务处理中心时，则比较适宜采用事务设计。十五设计的基本步骤和变换设计大体相同。
·设计准备——复审并精化系统模型；
·确定事务处理中；
·第一级分解——系统模块结构图顶层和第一层设计；
·第二级分解——自顶向下，逐步求精。
5.“高内聚低耦合”的启发式规则
（1）改进软件结构，提高模块独立性。
（2）力求模块规模适中。
（3）力求深度、宽度、扇入、扇出适中。
（4）尽力使模块的作用域在其控制域之内。
（5）尽力降低模块接口的复杂度。
（6）力求模块功能可以预测。
6.概要设计规约指明的高层软件体系结构
（1）系统环境，包括硬件/软件接口、人机界面、外部定义的数据库及其与设计有关的限定条件等。
（2）软件模块的结构，包括模块之间的接口及设计的数据库和主要数据结构等。
（3）模块描述，包括模块接口定义、模块处理逻辑及必要的注释等。
（4）文件结构和全局数据文件的逻辑结构，包括记录描述、访问方式以及交叉引用等。
（5）测试需求等。

第4章面向对象方法—UMI

4.1 UML术语表

4.1.1 UML术语表总述
为了支持抽象分析和设计中的事物，UML给出了八个基本本语即类、接口、协作、用况、主动类、构件、制品、节点。每个术语都体现着一定的软件设计原理，例如类体现了数据抽象、过程抽象、局部化以及信息隐蔽等原理；用况体现了问题分离、功能抽象等原理；接口体现了功能抽象等。

4.1.2 类、接口、用况、协作等概念
(1)类：类是一组具有相同属性、操作、关系和语义的对象的描述。类主要用于抽象客观世界中的事物；
(2)接口：每个操作描述了类、构件或子系统的一个服务，接口就是操作的一个集合。接口是对系统/产品的 “ 接缝 ” 予以模型化，表明了一个类、构件、子系统所需要得到的、且与实现无关的行为；
(3)用况：用况是对一组动作序列的描述，系统执行这些动作应产生对特定参与者有值的、可观察的结果；
(4)协作：协作是一个交互，涉及交互的三要素：交互各方、交互方式以及交内容。

4.1.3 UML的4个术语
为了表达各类事物之间的相互依赖和作用，UML给出了4个术语，即关联、泛化、细化和依赖；
(1)关联：关联是对一组有相同结构、相同链的描述，是类目之间的一种结构关系。关联可以用一条连接两个类目的线段表示，并可对其命名，其结构可以具有方向性,用一个实心三角形来指示关联的方向；
(2)泛化：泛化是一般性类目和它的较为特殊类目之间的一种关系。子类可以继承父类的属性和操作，同时，也可以替换父类的声明；
(3)细化：细化是类目之间的语义关系，其中一个类目规约了保证另一个类目执行的契约；
(4)依赖：依赖用于描述一个类目使用另一个类目的信息和服务，是一种使用关系。

4.1.4 表达组合信息的术语
为了控制信息组织的复杂性，UML提供了组织信息的一种通用机制——包，支持形成一些可管理的部分。换言之，包可以作为“模块化“和“构件化“的一种机制。为了模型化包之间的关系，UML给出了两种依赖，即访问和引入，用于描述一个包可以访问和引入其他包。

4.1.5 UML术语的作用
(1). 类用于抽象客观事物。
(2). 接口用于抽象事物之间的缝隙。
(3). 协作用于抽象协作性行为。
(4). 用况用于抽象功能。
(5). 主动类用于抽象并发行为。
(6). 构件用于抽象软件解中可标识的成分。
(7). 制品用于抽象工作产品。
(8). 节点用于抽象计算单元。
(9). 关联用于抽象结构关系。
(10). 泛化用于抽象“一般/特殊”关系。
(11). 实现用于抽象精化关系。
(12). 依赖用于抽象使用关系。

4.1.6 类在建模中的主要用途
(1)模型化问题域中的概念。
(2)建立系统的职责分布模型。
(3)模型化建模中使用的基本类型。

4.1.7 使用接口应注意的问题
在建立系统模型中，若使用接口对系统中那些“接缝”进行模型化时，应注意以下问题。
(1)接口只可以被其他类目使用，而其本身不能访问其他类目。
(2)接口描述类的外部可见操作，通常是该类的一个特定有限行为。这些操作可以使用可见性、并发性、衍型、标记值和约束来修饰。
(3)接口不描述其中操作的实现，也没有属性和状态。据此可见,接口在形式上等价于一个没有属性、没有方法而只有抽象操作的抽象类。
(4)接口之间没有关联、泛化、实现和依赖，但可以参与泛化、实现和依赖

4.2 UML的模型表达式

4.2.1 结构图和行为图
UML的图形化工具分为两类：一类是结构图，用于表达系统或系统成分的静态结构模型，给出系统或系统成分的一些说明性信息；另一类是行为图，用于表达系统或系统成分的动态结构模型，给出系统或系统成分的一些行为信息。

4.2.2 类图、用况图、顺序图及状态图
(1)类图是可视化地表达系统静态结构功能模型的工具，使用类图所表达的系统静态结构模型，给出的是一些关于系统的说明性信息。
(2)用况图是一种表达系统功能模型的图形化工具，它包含六个模型元素，分别是主题、用况、参与者、关联、泛化、依赖。
(3)顺序图由一组对象以及按时序组织的对象之间的关系组成，是一种交互图，包含对象之间传递的信息。
为了控制交互行为描述的复杂性，以便更好地表达顺序图的复杂控制，UML定义了四种常见的控制操作：选择执行操作、条件操作、并发迭代操作和迭代执行操作。
(4)状态图强调了从一个状态到另一个状态的控制流，是显示一个状态机的图。状态图由状态、事件和状态转移构成。使用状态图的作用有两个：一是创建一个系统的动态模型：二是创建一个场景的模型。

4.2.3 创建一个系统的类图的步骤
(1)模型化待建系统中的概念，形成类图中的基本元素。
使用UML中的术语“类”，来抽象系统中的各个组成部分，包括系统环境。继而确定每类的职责，最终形成类图中的模型元素。
(2)模型化待建系统中的各种关系，形成该系统的初始类图。
使用UML中表达关系的术语，例如关联、泛化等，来抽象系统中各成分之间的关系，形成该系统的初始类图。
(3)模型化系统中的协作,给出该系统的最终类图。
在研究系统中以类表达的某一事物语义的基础上，使用类和UML中表达关系的术语，模型化一些类之间的协作，并使用有关增强语义的术语，给出该模型的详细描述。
(4)模型化逻辑数据库模式。
对要在数据库中存储的信息，以类作为工具，模型化系统所需要的数据库模式，建立数据库概念模型。

4.2.4 信 事件、调用事件、时间事件和变化事件
在UML中，可以把信 、调用、时间、变化模型化为事件，分别称为信 事件，调用事件、时间事件和变化事件。
(1)信 事件是一种异步事件，信 通常由状态机处理。如果没有定义对该事件的响应，那么事件均可能丢失。事件的丢失，就有可能引发接收者—状态机的一个错误的状态转移。
(2)调用事件往往是一个同步事件，即发送者和接收者多处在该操作执行期间的一个汇合点上，发送者的控制流一直被挂起，直到该操作执行完成。但可以把调用规约为异步调用。
(3)时间事件是表示推移一段时间的事件。时间事件是通过时间表达式来规约的。
(4)变化事件表示状态的一个变化，或表示某一条件得到满足。

4.2.5 状态转换所涉及的内容
描述一个状态转换，一般涉及五个部分。
(1)源状态：发生状态转移的那个状态。
(2)转移触发器：在源状态中由对象识别的事件，并且一旦满足其监护条件，则使状态发生转移。
(3)监护条件：一个布尔表达式，当某个事件触发器接收一个事件时，如果该表达式有值为真，则触发一个转移;若有值为假，则不发生状态转移。
(4)效应：一种可执行的行为。
(5)目标状态：转移完成后所处的状态。

4.2.6 最常用的控制操作子
(1)选择执行操作子。该操作子由两部分组成：一是监护条件，二是控制体。
(2)条件执行操作子。控制体通过水平线将其分为一些部分，每一部分表示一个条件分支，每一分支有一个监护条件。
(3)并发执行操作子。该控制操作子的体通过水平线将其分为多个部分，每一部分表示一个并行计算。该控制操作子表明，当进入该控制操作子时，所有部分并发执行。
(4)选代执行操作子。该控制操作子表明，只要在每一次选代之前该监护条件为真，那么该控制体就反复执行；当该控制体上面的监护条件为假时，控制绕过该控制操作子。

4.2.7 子状态机、简单状态和组合状态的概念
(1)子状态机：为了有效地组织状态、控制对象状态的复杂性，UML提供了组合状态，在一个状态机中引入了另一个状态机，被引入的状态机就称为子状态机
(2)简单状态：子状态是被嵌套到另一状态中的状态。相对地,把没有子状态的状态称为简单状态。
(3)组合状态：把含子状态的状态称为组合状态，组合状态可包含两种类型的子状态机，即非正交(顺序)子状态机和正交(并发)子状态机。

第5章 面向对象方法——RUP

5.1 RUP的特点

[选择、填空、简答]
5.1.1 RUP的突出特点
RUP的突出特点是，它是一种以用况为驱动的、以体系结构为中心的迭代、增量式开发。
(1)以用况为驱动
以用况为驱动是指在系统的生存周期中，以用况作为基础，驱动系统有关人员对所要建立系统的功能需求进行交流，驱动系统分析、设计、实现和测试等活动。
(2)以体系结构为中心
以体系结构为中心是指在系统的生存周期中，开发的任何阶段都要给出相关模型视角下有关体系结构的描述，作为构思、构造、管理和改善系统的主要标准。
(3)迭代、增量式开发
迭代、增量式开发是指通过开发活动的迭代，不断地产生相应的增量。在RUP中，规定了四个开发阶段：初始阶段、精化阶段、构造阶段和移交阶段。

5.1.2 初始阶段的基本目标
初始阶段的基本目标是：获得与特定用况和平台无关的系统体系结构轮廓，以此建立产品功能范围；编制初始的业务实例，从业务角度指出该项目的价值，减少项目主要的错误风险。
5.1.3 精化阶段的基本目标
精化阶段的基本目标是：通过捕获并描述系统的大部分需求，建立系统体系结构基线的第一个版本；到该阶段末，就能够估算成本、进度，并能详细地规划构造阶段。

5.1.4 构造阶段的基本目标
构造阶段的基本目标是：通过演化，形成最终的系统体系结构基线，开发完整的系统，确保产品可以开始向客户交付。
5.1.5 移交阶段的基本目标
移交阶段的基本目标是：确保有一个实在的产品发布给用户群。

5.2 核心工作流

[选择、填空、简答]
5.2.1 RUP迭代中的核心工作流
在RUP的每次送代中都要经历一个核心工作流，即需求获取、分析,设计、实现和测试。

5.2.2 需求获取的基本步骤和相关制品

5.2.3 业务用况模型和业务对象模型
(1)业务用况模型。业务用况模型是以用况图予以表达的，如下图所示。