前言：02333软件工程自考，内容方面比较枯燥，理论知识点比较零散，建议结合思维导图*（附录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.需求发现技术
初始发现需求的常用技术，如下所示

名称	适用情况	成功条件	存在风险
自悟	需求人员不能直接与用户进行交流，自悟就可能是一种切实可行的、比较有吸引力的方法	需求人员必须是具有比最终用户还要多的应用领域和过程方面的知识，并具有丰富的想象力	无法验证发现的需求是否满足用户的要求，无法验证发现的需求是不是正确的
交谈	客户支持需求人员与最终用户进行有关系统需求的交流	依赖于：（1）需求人员是否具有“正确提出问题”的能力；（2）回答人员是否具有“揭示需求本意”的能力	在交谈期间所获得的需求可能不断增长，或是以前没有认识到合理需求的一种表现，或是“完美蠕行”病症的体现，可能导致超出项目成本和进度的限制
观察	用户允许需求人员进入工作场所，并进行观察，可与有关人员就有关问题进行交流	需求人员具有洞察事物本质的能力	（1）客户可能抵触这一观察（2）客户可能认为开发者在签约之前，就已经熟悉他们的业务
小组会	各方组织在管理层面上重视需求工作，并有能力提供人力资源	会议组织得当，包括责权分明，参与会议人员具有良好的需求发现能力，并允许发表不同的观点，以便很快的标识需求，揭示需求中存在的问题，并与客户达成共识。	如果会议组织不到位，或收到某些客观环境限制，就有可能过多地召开这样的会议，并产生一些互相矛盾的需求。
提炼	提炼方法是针对已经有了部分需求文档的情况。依据产品的本来情况，可能有很多文档需要重审，以确定其中是否包含相关联的信息	已存在项目背景文档以及一些紧密相关的需求文档，并且需求人员具有很好的想象力和需求标识能力，包括熟悉相关的技术标准和法律	与自悟方法一样，无法验证发现的需求是否正确。

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)业务用况模型。业务用况模型是以用况图予以表达的，如下图所示。

图5-1业务用况模型

(2)业务对象模型。
为了精化业务用况模型中的每一个业务用况，RUP引入了三个术语，用于表达参与业务的业务对象：工作人员、业务实体和工作单元。业务对象模型可通过交互图和活动图予以表达。

5.2.4 标识用况应注意的问题
(1)建立用况的结构中，应尽可能反映用况的实际情况；
(2)在用况的结构化中，不论是施加什么结构，新引入的用况都不应该太小或太大；
(3)在建立用况的结构时，应尽量避免对用况模型中的用况功能进行分解；

5.2.5 需求分析层上的术语
(1)分析类是类的一种衍型,分为边界类、实体类和控制类。
(2)用况细化时一个协作，针对一个用况，其行为可用多个分析类之间的相互作用来细化，并记为用况细化。用况细化对用况模型中的一个特定的用况提供了一种直接跟踪的方式。
(3)分析包是一种控制信息组织复杂性的机制，提供了分析制品的一种组织手段。其主要特征为：体现问题的分离；高内聚、低耦合；尽可能体现一个系统的完整顶层设计，尽可能成为一些子系统或成为一些子系统的组成部分。

5.2.6 具有良好结构的分析包的特征
(1)体现问题分离。
(2)高内聚、低耦合。
(3)尽可能体现一个系统的完整顶层设计。

5.2.7 软件设计层上的术语
软件设计是定义满足需求规约所需要的软件结构。BUP为了满足系统/产品分析模型规约需求的软件结构，为设计层提供了四个术语：设计类、用况细化、设计子系统和接口，用于表达软件结构中的基本元素。
(1)设计类：一个设计类是对系统实现中一个类或类似构造的一个无缝抽象。
(2)用况细化：用况细化是设计模型中的一个协作，其中使用设计类及其对象，描述个特定用况是如何予以细化的，是如何执行的。
(3)设计子系统：设计子系统可以包含设计类、用况细化、接口，以及其他子系统，通过对其操作来显示其功能。
(4)接口：接口用于规约由设计类和设计子系统，必须提供与该接口操作对应的实现方法。

5.2.8 创建系统/产品用况模型的活动和任务
创建系统/产品用况模型需要的活动和任务如下
(1)活动1：发现并描述参与者。
任务1：发现参与者，即直接发现一些候选的参与者。
任务2：描述参与者，即对参与者进行命名并描述。

(2)活动2：发现用况并对用况进行描述。
任务1：发现用况。
任务2：描述用况，即确定用况后对其进行描述。

(3)活动3：确定用况的优先级，目的是在寻找参与者并对其进行描述和发现用况，并对用况进行描述的基础上确定哪些用况适合在早期的迭代中开发，哪些适合在后期的迭代中开发。

(4)活动4：精化用况。这一活动的目的是详细描述出每一用况的事件流，包括用况是怎样开始的，是怎样结束的，是怎样与参与者进行交互的。最终形成一系列精化的用况。

(5)活动5：构造用户界面原型。这一活动的目的在于建造用户界面原型，使用户可以有效地执行用况。

(6)活动6：用况模型的结构化。进行用况模型的结构化要做以下工作。
①抽取用况描述中的那些一般性的和共享的功能并使用泛化关系标识和描述那些共享功能。
②抽取用况描述中附加的或可选的功能。
③标识用况之间的包含关系。通过用况模型的结构化，最终形成一个系统/产品的精化用户模型。

5.2.9 创建系统/产品需求分析模型的活动和任务
(1)活动1：体系结构分析。该活动的目标是通过标识分析包和分析类，建立分析模型和体系结构“骨架”，并标识有关分析包和分析类的特定需求。
任务1：标识分析包。该任务的基本输入是系统的用况模型。
任务2：处理分析包之间的共性。
任务3：标识服务包。
任务4：定义分析包的依赖，该任务的目标是发现相对独立的包，实现包的高内聚和低耦合。
任务5：标识重要的实体类，该任务的目标是标识在体系结构方面具有意义的实体类。
任务6：标识分析包和重要实体类的公共特定需求，该任务的目标是依据需求获取阶段所标识的非功能需求，针对在分析期间所标识的包和分析类，标识它们的一些公共的特定要求。
(2)活动2：用况分析。该活动的目标是：一是标识那些在用况事件流执行中所需要的分析类和对象；二是将用况的行为分布到参与交互的各个分析对象;三是捕获用况细化上的特定需求。
任务1：标识分析类，该任务的目标是标识在细化一个用况中所需要的实体类、控制类和边界类，给出它们的名字、责任、属性和关系。
任务2：描述分析类对象之间的交互。首先确定细化该用况所必要的交互，其次分派该用况的功能，最后根据其责任，发现该交互图中的各个链。
(3)活动3：类的分析。该活动的目标：一是标识并维护分析类的属性和关系；三是捕获分析类细化中的特殊需求。
任务1：标识责任，通过组合一个类在不同用况细化中所扮演的角色来完成。
任务2：标识属性。
任务3：标识关联和聚合。
(4)活动4：包的分析。该活动的目标是：一是确保分析包尽可能与其他包相对独立；二是确保分析包实现了它的目标；三是描述依赖，以益于可以估计未来的变化

5.2.10 创建系统/产品设计模型的活动和任务
创建系统产品设计模型的活动和任务如下：
(1)活动1：体系结构设计，该活动的目标是创建设计模型和部署模型，以及它们视角下的体系结构描述。
任务1：标识节点和它们的网络配置，网络配置通常使用一种三元模式：客户端、数据库功能、业务/应用逻辑。
任务2：标识子系统和它们的接口，目的是为了寻求一些复用的可能，而后随着设计模型的开发，在形成子系统结构中不断发现并演化。
任务3：标识在体系结构方面有意义的设计类和它们的接口。标识在体系结构方面有意义的设计类的基本思想是：初始可以依据在体系结构方面有意义的分析类来标识一些体系结构上具有重要意义的设计类。标识在系统体系结构方面有意义的设计类时，应注意主动类往往是一类在体系结构方面具有重要意义的类。
任务4：标识一般性的设计机制。其共性需求包括：永久性、透明对象的分布、安全特征、错误检测与揭示和事务管理等，这些共性需求是在分析期间有关用况细化分析中所标识的对设计类的特殊需求。

(2)活动2：用况的设计。其中分析模型的用况细化分析是活动的输入，对应输出用况细化设计。
为了实现用况设计的输入/输出，一般采用两种方法：
①标识参与用况细化的设计类。首先基于分析模型研究相应用况细化分析中的分析类，来标识为细化这些分类所需要的设计类，然后基于用况的功能对每一个标识的设计类赋予相应的责任，最后为该细化创建一个类图，汇聚参与该用况细化的设计类，并给出类之间的关系。
②标识参与用况细化的子系统和接口。

(3)活动3：类的设计。该活动的目标是完成用况细化设计中每一个类的角色设计，并完成有关每一类的非功能需求的设计。
任务1：概括描述设计类，该任务的输入为分析类/接口。
任务2：标识的操作，一般应依据分析类来标识设计类所提供的、所需要的操作，其中需要使用程序设计语言的语法来描述所标识的操作。
任务3：标识属性，该任务的目标是标识设计类所需要的属性，并使用程序设计语言的语法给出属性的描述。
任务4：标识关联和聚合。
任务5：标识泛化,基于分析模型中分析类之间的泛化，可以发现设计模型中的很多泛化。
任务6：描述方法，在设计期间一般用自然语言或适当的使用伪码对方法进行规约，但是在实现期间直接使用程序设计语言对方法进行规约。
任务7：描述状态，有些设计对象是受状态控制的，即它们的状态确定了它们接受一个消息的行为。在这种情况下，使用一个状态图描述一个对象的不同状态转移是有意义的。

(4)活动4：子系统的设计。该活动的目标是：确保子系统尽可能独立于其他子系统或它们的接口；确保子系统提供正确的接口；确保子系统实现了它的目标，即给出了该子系统提供的那些接口所定义的操作的细化。

5.2.11 设计模型包含的元素
RUP设计的主要结果是设计模型，它尽量保持该系统具有分析模型的结构，并作为系统实现的输入，包含以下四个元素。
(1)设计子系统和服务子系，,以及它们的接口、依赖和内容。
(2)设计类以及它们具有的操作、属性、关系及其实现的需求。
(3)用况细化设计。
(4)设计模型视角下的体系结构描述。

5.2.12 用况模型与分析模型的比较
用况模型与分析模型的比较如表5-1所示。
表5-1用况模型与分析模型的比较

用况模型	分析模型
使用客户语言来描述	使用开发者语言来描述
给出的是系统对外的视图	给出的是系统对内的视图
使用用况予以结构化，但给出的是外部视角下的系统结构	使用衍型类予以结构化,但给出的是内部视角下的系统结构
可以作为客户与开发者之间关于“系统应做什么,不应做什么”的契约	可以作为开发者理解系统如何勾画、如何设计和如何实现的基础
在需求之间可能存在一些冗余、不一致和冲突等问题	在需求之间不应存在冗余、不一致和冲突问题
捕获的是系统的功能，包括在体系结构方面具有意义的功能	给出的是细化的系统功能，包括在体系结构方面有意义的功能
定义了一些进一步需要在分析模型中予以分析的	定义了用况模型中每一个用况的细化

5.2.13 RUP测试活动
RUP的测试包括内部测试、中间测试和最终测试。
RUP测试活动

输入	活动	输出
补充需求、用况模型、分析模型、设计模型、实现模型、体系结构描述	计划测试	测试计划
补充需求、用况模型、分析模型、设计模型、实现模型、体系结构描述、测试计划	设计测试	测试用况，测试过程
测试用况、测试过程、实现模型	实现测试	测试构件
测试用况、测试过程、测试构件、实现模型	执行集成测试	缺陷
测试用况、测试过程、测试构件、实现模型	执行系统测试	缺陷
测试计划、测试模型、缺陷	评价测试	测试评价

第6章软件测试

6.1 软件测试目标与软件测试过程模型

[选择、填空、简答]
6.1.1 软件测试及目标
软件测试的定义为：按照特定规程发现软件错误的过程。其目的是检验它是否满足规定的需求，或清楚了解预期结构与实际结果之间的差异。

6.1.2 软件测试与软件调试的区别
软件测试与软件调试相比，在目的、技术和方法等方面都存在很大区别，主要表现在以下几个方面。
(1)测试从一个侧面证明程序员的“失败”。调试是为了证明程序员的正确。
(2)测试以已知条件开始，使用预先定义的程序且有预知的结果，不可预见的仅是程序是否通过。调试一般是以不可知的内部条件开始，除统计性调试外，结果是不可预见的。
(3)测试是有计划的，并要进行测试设计。调试是不受时间约束的。
(4)测试是一个发现错误、改正错误、重新测试的过程。调试是一个推理过程。
(5)测试的执行是有规程的。调试的执行往往要求程序员进行必要推理。
(6)测试经常是由独立的测试组在不了解软件设计的条件下完成的。调试必须由了解详细设计的程序员完成。
(7)大多数测试的执行和设计可由工具支持。调试时，程序员能利用的工具主要是调试器。

6.1.3 测试过程模型
软件测试是一个有程序的过程，包括测试设计、测试执行以及测试结果比较。测试过程模型可分为三类：环境模型、被测对象模型和错误模型。
(1)环境模型：是对程序运行环境的抽象。程序运行环境又包括支持其运行的硬件、固件和软件，如计算机、终端设备、网卡、操作系统、编译系统、实用程序等。在软件测试过程中，建立环境模型的主要目的是，确定所发现的错误是否为环境造成的。
(2)被测对象模型：该模型是从测试的角度对程序的抽象。为了测试，必须简化程序，形成被测程序的抽象版本，即对象模型。
(3)错误模型：该模型是对程序中的错误及其分类的抽象。在软件测试中，往往需要定义“什么是错误”、“什么是一般性错误”、“什么是严重性错误”等，即要给出“错误模型”。

6.2 软件测试技术

[选择、填空、简答]
6.2.1 测试覆盖及其它们之间的基本关系
软件测试技术大体上可分为两大类：一类是白盒测试技术，又称为结构测试技术，典型的是路径测试技术；另一类是黑盒测试技术，又称为功能测试技术，包括事务处理流程技术、状态测试技术、定义域测试技术等。白盒测试技术依据的是程序的逻辑结构，而黑盒测试技术依据的是软件行为的描述。

6.2.2 路径测试技术的分类
测试覆盖包括路径覆盖、分支覆盖、条件覆盖与条件组合覆盖。
(1)路径覆盖：执行所有可能穿过程序控制流程的路径。在路径测试中，该度量是最强的，一般是不可实现的。
(2)语句覆盖：至少执行程序中所有语句一次。
(3)分支覆盖：至少将程序中的每一个分支执行一次。
(4)条件覆盖与条件组合覆盖。条件覆盖是指每个判定中的所有可能的条件取值至少执行一次；条件组合覆盖是指设计足够的测试用例，使每个判定中所有可能的条件取值组合至少执行一次。
这四种测试覆盖的测试覆盖率由弱到强的顺序是：语句覆盖、分支覆盖、条件组合覆盖、路径覆盖。

6.2.3 事务流测试步骤
事务流测试步骤具体如下。
第一步：获得事务流程图。
第二步：浏览、复审。
第三步：用例设计。
第四步：测试执行。

6.2.4 运用等价类划分技术进行测试的步骤
具体测试步骤如下。
第一步：建立等价类表。
第二步：为有效等价类设计测试用例。
第三步：为无效等价类至少设计一个测试用例。

6.2.5 边界值分析的使用原则
边界值分析是一种常用的黑盒测试技术。使用边界值分析在设计测试用例时，可以遵循以下原则。
(1)如果某个输入条件规定了输入值的范围，则应该选择正好等于边界值的数据，以及刚刚超过边界值的数据作为测试数据。
(2)如果某个输入条件规定了值的个数，则可用最大个数、最小个数、比最大个数多1比最小个数少1的数据作为测试数据。
(3)根据规格说明的每个输出条件，使用前面的原则(1)。
(4)根据规格说明的每个输出条件，使用前面的原则(2)。
(5)如果程序的规格说明中，输入域或输出域是有序集合，在实践中则经常选取集合的第一个元素、最后一个元素以及典型元素作为测试用例。
(6)如果程序中使用了内部数据结构，则应当选择这个内部数据结构的边界上的值作为测试用例。
(7)分析规格说明，找出其他可能的边界条件。

6.2.6 使用因果图生成测试用例的步骤
因果图技术是通过为判定表的每一列设计一个测试用例，从而实现测试用例的设计与选择的。该方法生成测试用例的基本步骤如下。
(1)通过软件规格说明书的分析，找出一个模块的原因和结果,并给每个原因和结果赋予一个标识符。
(2)分析原因与结果之间以及原因之间对应的关系，并画出因果图。
(3)在因果图上标识出一些特定的约束或限制条件。
(4)把因果图转换成判定表。
(5)把判定表的每一列拿出来作为依据，设计测试用例。

6.3 软件测试步骤

[选择、填空、简答]
软件测试的基本步骤
(1)单元测试单元测试主要检验软件设计的最小单元——模块。该测试以详细设计文档为指导，测试模块内的重要控制路径。一般来说，单元测试往往采用白盒测试技术。
(2)集成测试集成测试是软件组装的一个系统化技术，其目标是发现与接口有关的错误，将经过单元测试的模块构成一个满足设计要求的软件结构。集成测试集中于模块组合的功能和软件结构检验。集成测试可“自顶向下”地进行，称为自顶向下的集成测试;也可以“自底向上”地进行测试，称为自底向上的集成测试。
(3)有效性测试有效性测试的目标是发现软件实现的功能与需求规格说明书不一致的错误。因此有效性测试通常采用黑盒测试技术。
(4)系统测试系统测试验证将软件融于更大系统中时整个系统的有效性。

第7章 软件生存周期过程与管理

7.1 软件生存周期过程概述

[选择、填空、简答]
7.1.1 过程分类
按过程主体把软件生存周期过程分为以下几个过程。
(1)基本过程：是指那些与软件生产直接相关的活动集。该过程又可分为获取过程、供应过程、开发过程、运行过程和维护过程。
(2)支持过程：是指有关各方按他们的目标所从事的一系列相关支持活动集。该过程又可分为文档过程、配置管理过程、质量保证过程、验证过程、确认过程、联合评审过程、审计过程和问题解决过程。
(3)组织过程：是指那些与软件生产组织有关的活动集。该过程又可分为设计过程、基础设施过程培训过程和改进过程。

7.1.2 系统语境的过程类
系统语境的过程类包含四个过程组，分别是协议过程组、项目过程组、技术过程组和组织上项目使能过程组。
(1)协议过程组包含两个过程：获取过程和供应过程。
(2)项目过程组包含七个过程：:项目规划过程项目评价过程、决策管理过程、风险管理过程、配置管理过程、信息管理过程和测量过程。
(3)技术过程组包含11个过程：利益攸关方需求定义过程、系统需求分析过程、系统体系结构设计过程、实现过程、系统集成过程、系统测试过程、软件安装过程、软件接受支持过程、软件运行过程、软件维护过程和软件销毁过程。
(4)组织上使能过程组包含五个过程：生存周期模型管理过程、基础设施管理过程、项目包管理过程、人力资源管理过程和质量管理过程。

7.1.3 组织上使能过程的作用。
组织上使能的过程一般来说是组织层面上的工作，为项目的执行提供基本保障。该过程包含五个子过程。
(1)生存周期模型管理过程：其任务为过程建立、过程评估、过程改进。
(2)基础设施管理过程：其任务为过程实现、基础设施的建立、基础设施的维护。
(3)项目包管理过程：项目初始化、项目包评估、项目结束处理
(4)人力资源管理过程：其任务为技能标识、技能开发、技能获取和供给、知识管理。
(5)质量管理过程：其任务为质量管理、质量管理纠正措施。

7.2 过程描述

[选择、填空、简答]
软件验证过程包含两个活动：过程实现和验证。
验证活动有五个任务：需求验证、设计验证、代码验证、集成验证和文档验证个过程可通过过程意图、期望的结果以及达到过程结果所需要执行的活动和任务来描述。
对于一个过程的完整技术上的描述，还应包括：达到过程意图和实现过程结果的方法或规程，以及过程和活动的文档。

7.3 应用说明

[选择、填空、简答]
7.3.1 系统和软件的关系
在《SO/EC系统与软件工程一软件生存周期过程122072008》标准中，把软件认为是整个系统的一个组成部分，执行系统中所确定的功能主要包括三大功能：控制功能、耦合功能以及软件本身提供的功能。由于软件通常存在于一个系统的上下文中，因此软件产品或服务一般可被认为是系统的一个项或称为系统元素。

7.3.2 剪裁过程及应用
剪裁过程是使剪裁这一标准过程满足以下特定情况或因
(1)围绕一个组织，其中该组织在一个协议中使用了这一标准。
(2)影响一个项目，其中要求该项目满足一个引用该标准的协议。
(3)反映一个组织的需要，其中该组织要供给产品或服务。

7.4 软件生存周期模型

[选择、填空、简答]
7.4.1瀑布模型
瀑布模型是将软件生存周期各个活动规定为按固定顺序连接的若干阶段的模型。这模型规定了各开发阶段的活动：系统需求、软件需求、需求分析、设计、编码、测试和运行，并且自上而下具有相互衔接的固定顺序；还规定了每一阶段的输入，即工作对象以及本阶段的工作成果，作为输出传送到下一阶段。

△瀑布模型的提出，对软件工程的主要贡献为如下：
(1)在决定系统怎样做之前存在一个需求阶段，它鼓励对系统做什么进行规约。
(2)在系统构造之前存在一个需求阶段，它鼓励规划系统结构。
(3)在每一阶段结束时进行评审，从而允许获取方和用户的参与。
(4)前一步可以作为下一步被认可的、文档化的基线，并允许基线和配置早期接受控制。

瀑布模型的问题主要是：
(1)要求客户能完整、正确和清晰地表达他们的需求；并要求开发人员一开始就要理解这一应用。
(2)由于需求的不稳定性，使设计、编码和测试阶段都可能发生延期；并且当项目接近结束时，出现了大量的集成和测试工作。
(3)在开始的阶段中，很难评估真正的进度状态；并且直到项目结束之前都不能演示系统的能力。
(4)在一个项目的早期开发阶段，过分地强调了基线和里程碑处的文档；并可能需要花费更多的时间用于建立一些用处不大的文档。

7.4.2 增量模型
增量模型是一种非整体开发的模型。软件在该模型中逐渐开发出来，开发出一部分，可让用户及早看到部分软件，及早发现问题。该模型具有较大的灵活性，适合于软件需求不明确、设计方案有一定风险的软件项目。

7.4.3 演化模型
该模型主要针对事先不能完整定义需求的软件开发的。
在用户提出待开发系统的核心需求的基础上，软件开发人员按照这一要求，
1.首先开发一个核心系统并投入运行,以便用户能够有效地提出反馈，即精化系统、增强系统能力的需求；
2.接着，软件开发人员根据用户反馈，实施开发的迭代过程；
3.每一迭代过程均由需求、设计、编码、测试、集成等阶段组成，为整个系统增加一个可定义的、可管理的子集；
4.如果在一次迭代中，有的需求不能满足用户的要求，可在下一次迭代中予以修正。

主要特征：该模型显式地把需求获取扩展到需求阶段，即为了第二个构造增量，使用了第一个构造增量来精化需求。演化模型在一定程度上可以减少软件开发活动的盲目性。不足之处：在演化模型的使用中，即使很好地理解了需求或设计，也很容易弱化需求分析阶段的工作。

7.4.4 螺旋模型
螺旋模型将瀑布模型与增量模型结合起来，加入了两种模型均忽略了的风险分析，弥补了这两种模型的不足。因而它是一种风险驱动的模型。螺旋模型将开放过程分为几个螺旋周期，每个螺旋周期大致和瀑布模型相符合。
螺旋模型关注解决问题的基本步骤，即标识问题，标识一些可选方案，选择一个最佳方案，遵循动作步骤并实施后续工作。其一个突出特征是,在开发的选代中实际上只有一个选代过程真正开发了可交付的软件。
螺旋模型与演化模型和增量模型相比，同样适用了瀑布模型作为一个嵌入的过程，但螺旋模型所关注的阶段以及它们的活动是不同的。
如果项目的开发风险很大或客户不能确定系统需求，在更广泛的意义上来讲，还包括一个系统或系统类型的要求，这时螺旋模型就是一个好的生存周期模型。

7.4.5 喷泉模型
喷泉模型体现了软件创建所固有的迭代和无间隙的特征。该模型主要用于支持面向对象技术的软件开发。由于对象概念的引人，使分折、设计、实现之间的表达没有明显间隙。

7.5 过程规划与管理

[选择、填空、简答]
7.5.1 创建一个软件项目生存周期过程的步骤
(1)选择软件生存周期模型。
(2)细化所选择的生存周期模型。
(3)为每一个活动或任务标识合适的实例数目。
(4)确定活动的时序关系,并检查査信息流。
(5)建立过程计划的文档。
7.5.2 软件评估
软件评估中应考虑的影响因素不管做什么样的决策，都必须对所采取的措施对生存周期过程所产生的影响进行评审，以便保证项目获得好的结果。在这一评估中,应考虑以下几方面的影响。
(1)所要求的“返工”。
(2)资源需求。
(3)实施时间。
(4)对项目和用户的益处。
(5)员工情绪。

第8章集成化能力成熟度模型(CMMI)

8.1 背景和原理

[选择、填空、简答]
8.1.1 过程改善
历史过程改善，是指人为设计的一个活动程序，其目的是改进组织的过程性能和成熟度，并改进这一程序的结果。
8.1.2 过程专用目标和共用目标
过程域是一个业务域中一束相关的实践，当它们一起得以实现时，就满足被认为对该过程域的改善具有重要作用的一组条件。
专用目标是用于描述满足该过程域必须呈现的一些独有特征。经可以用于帮助确定一个过程域是否得以满足。
共用目标用于描述产现制度化的该过程必须呈现的特征，仅用于确定一个过程域是否得以满足。

8.2 CMMI的模型部件

[选择、填空、简答]
CMMI模型中有22个过程域,分为4个类,见表8-1。
表8-1CMMI的过程域

过程域类名	包括的过程域
项目管理类	项目规划、项目监控、定量项目管理、集成项目管理、风险管理、提供方协议管理
工程类	需求开发、需求管理、技术解决方案、产品集成、确认、验证
支持类	配置管理、过程和产品质量保证、测量与分析、原因分析与解决、决策分析与解决
过程管理类	组织过程定义、组织过程性能、组织过程培训、组织过程关注、组织创新与部署

8.3 CMMI的等级

[选择、填空、简答]
8.3.1 能力等级的组成
能力等级是用来表征组织对一个过程域的改善，是不断改善一个给定过程域的一种手段。在CMM中，针对每个过程域设定了6个能力等级，即0级：未完成级；1级：已执行级； 2级：已管理级；3级：已定义级；4级：已定量管理级；5级：持续优化级。
8.3.2 成熟度等级的组成
在CMM中，应用于一个组织过程改善的成熟度等级有5个。即1级：初始级；2级：已管理级；3级：已定义级；4级：已定量管理级；5级：持续优化级。
8.3.3 能力等级与成熟度等级之间的基本关系
能力等级与成熟度等级是互补的关系，两者都是一种过程改善路径，其中：
(1)能力等级的路径可使组织针对单一过程域不断改善该过程域，即表征组织对单过程域的改进。
(2)成熟度等级的路径可使组织通过关注一个过程域不断改善一组相关过程域，即表征组织对一组过程域的改进。
(3)两种等级的2-5级使用了同样的名字。
8.3.4 达到各共用目标所要实施的共同实践
达到共用目标2、共用目标3、共用目标4和共用目标5所要实施的共同实践如下表所示。

目标	所要实施的共用实践
共用目标2:把过程制度化为一个管理过程	GP2.1建立组织策略，GP2.2规划过程，GP2.3提供资源，GP2.4指派责任，GP2.5培训人员，GP2.6管理配置，GP2.7标识相关利益方的参与，GP2.8监控过程，GP2.9客观地评估符合性，GP2.10从高层管理的视觉评审状态
共用目标3:把过程制度化为一个已定义过程	GP3.1建立一个已定义的过程，GP3.2收信进信息
共用目标4:把过程制度化为一个已定量管理过程	GP4.1为该过程建立定量目的，GP4.2使子过程性能达到稳定
共用目标5:把过程制度化为一个持续优化过程	GP5.1确保不断进行过程改善，GP5.2收集问题的根本原因

【正文完结】

附录1 软件工程思维导图

(本思维导图取自Coder_Jh的《软件工程导论思维导图》：https://blog.csdn.net/qq_31239371/article/details/106567656)