废话

update on 4.24：这里是brz，软工期中考前一天，又来写了，这种背概念的科目最讨厌了。稍微整理一下下。
完成了前四章

update on 5.27：期中考咣咣一顿写，考的好像都会，最后反正分没几个。要做小组作业了，又来补一下。

update on 6.18：准备期末考，刚问候完现代交换原理，开始复习软工。
重构了复习提纲

update on 6.19：整了点练习题。

update on 6.21：总了个结。

知识点总结

Part1 软件工程概述

软件的定义： 软件是包括程序、数据及其相关文档的完整集合。

软件至今未完全摆脱手工艺的制作方式。

软件是复杂的的原因：实际需求的复杂性、程序逻辑的复杂性。

现代软件的需求者是市场用户，决定质量的因素是管理水平。

软件危机具体表现在：

1. 软件开发成本难以估算，无法制定合理的开发计划；
2. 用户的需求无法确切表达；
3. 软件质量存在问题；
4. 软件的可维护性差；
5. 缺乏文档资料；

产生软件危机的原因：软件系统本身的复杂性；软件开发方法和技术的不合理以及不成熟。

软件工程的定义：

1. 首次提出： 软件工程是为了经济地获得能够在实际机器上高效运行的可靠软件而建立和使用的一系列好的工程化原则。
2. IEEE： 应用系统化的、规范化的、定量的方法来开发、运行和维护软件（即将工程应用到软件），以及对上述方法的研究。

软件工程三要素：方法、工具、过程。

1. 方法：提供了“如何做”的技术；
2. 工具：提供了自动或半自动的软件支撑环境；
3. 过程：将软件工程的方法和工具综合起来以达到合理、及时地进行计算机软件开发的目的。

软件工程的目标：生产具有正确性、可用性以及开销适宜的软件产品。

软件工程的最终目的：摆脱手工生产软件的状况，逐步实现软件研制和维护的自动化。

软件工程过程包含的主要活动：

1. 软件规格说明：规定软件的功能及其使用限制；
2. 软件开发：产生满足规格说明的软件；
3. 软件确认：通过有效性验证以保证软件可以满足客户的要求；
4. 软件演进：为了满足客户的变更要求，软件必须在使用过程中不断地进行改进。

PDCA循环（戴明环）：针对工程的质量目标，将工程过程分为 Plan, Do, Check, Action 四个环节。

软件生命周期的六个基本步骤：

1. 制定计划 P
2. 需求分析 D
3. 设计 D
4. 程序编码 D
5. 测试 C
6. 运行维护 A

软件过程模型： 对软件开发过程的抽象，包含活动、软件工件、参与角色。

瀑布模型：

特点： 推迟了软件实现，强调在软件实现前必须进行分析和设计工作。

瀑布模型让人们意识到，由于需求很难调研充分，所以很难一次性开发成功。

演化模型：

第一次开发得到试验性的原型产品，只为了探索可行性，弄清楚需求。

增量模型：

结合了瀑布模型和演化模型的优点。最高优先级的部分得到多次测试，保障了重要部分的可靠性。

RUP： 一个基于面向对象的程序开发方法论。
分为初始阶段、细化阶段、构造阶段、交付阶段。
每个阶段结束于一个主要的里程碑，并在阶段结尾评估这个阶段的目标是否已经满足。

敏捷建模： 主要特点是具有快速且灵活的响应变更的能力。

喷泉模型：

没有特定的次序要求，在任意开发阶段可以随时补充其他开发阶段中遗漏的需求。

别的模型懒得写了，应该不考，敢考就敢挂。

---

完整的需求规格说明是很难一次性得到的，因为：

• 在开发早期用户的想法比较模糊，很难完全准确地表达出对系统的全面要求；
• 开发过程中用户可能会产生新的要求；
• 开发者可能在设计和实现时遇到困难，需要改变需求。

原型： 模拟某种最终产品的原始模型。

原型方法： 获得一组基本需求后，通过快速分析构造出一个小型的软件系统原型，满足用户的基本要求。
用户可以通过使用原型系统，提出修改意见，从而减少用户与开发人员对系统需求的误解，使需求尽可能准确。

原型方法主要用于明确需求，但也可以用在软件开发的其他阶段。

优点：

1. 有助于快速理解用户对于需求的真实想法；
2. 容易确定系统的性能，确认各项重要服务的可应用性，确认系统设计的可行性，确认系统作为产品的结果；
3. 软件原型的最终版本，有的可以直接作为产品，有的略加修改后就能成为最终系统的组成部分，这样有利于建成最终系统。

局限性：

1. 大型系统不经过系统设计直接用原型模拟比较困难；
2. 对于需要大量计算、逻辑性较强的程序模块，原型方法难以构造该模块的原型；
3. 对于原有应用的业务流程、信息流程混乱的情况，原型的构造和使用有一定的困难。

存在的问题：

1. 文档容易被忽略；
2. 建立原型的许多工作会被浪费掉；
3. 项目难以规划和管理。

Part2 软件需求分析

需求介绍

需求的定义： 研究一种无二义性的表达工具，它能为用户和软件人员双方都接受，并能把“需求”严格地、形式地表达出来。

需求分析的困难：

1. 用户无法清楚表达需求
2. 双方对需求的理解不一致
3. 用户经常变更需求

需求分析的必要性：

1. 它使得软件开发人员在系统分析的基础上深入描述软件的功能和性能，指明软件和其他系统元素的接口，建立软件必须满足的约束条件。
2. 它允许软件开发人员对关键问题进行细化，并构建相应的分析模型：数据、功能和行为模型。
3. 分析模型成为设计模型的基础，需求规格说明书也为软件测试人员和用户提供了软件质量评估的依据。
4. 它能准确表达用户对系统的各项要求。

需求分析的对象：用户要求。

需求分析的任务：准确定义新系统的目标，编制需求规格说明书。

需求分析的目标：借助当前系统的逻辑模型到处目标系统的逻辑模型，解决系统“做什么”的问题。

需求分析的操作性原则：

1. 问题的信息域必须被表示和理解；
2. 软件将完成的功能必须被定义；
3. 软件的行为必须被表示。

需求分析的工程化原则：

1. 首先要正确地理解问题，再建立分析模型；
2. 记录每个需求的起源及原因，保证需求的可回溯性；
3. 开发一个人机交互过程的原型；
4. 给需求赋予优先级：紧张的开发时间要求尽量避免一次性实现每个软件需求，应采用迭代增量的开发模型；
5. 努力删除歧义性：因为大多数需求以自然语言描述，存在歧义的可能性，正式的技术评审是发现并删除歧义性的一种有效方法。

用户需求说明书 和 软件需求规格说明书 的区别：

• 前者主要采用自然语言来表达用户需求，其内容相比于后者比较粗略，不够详细；
• 后者是前者的细化，更多的采用计算机语言和图形符号来刻画需求，软件需求是系统软件设计的直接依据；
• 两者之间并不存在一一对应关系。

需求类别：

• 功能需求：列举所开发的软件在功能上应该做什么，这是最主要的需求。
• 性能需求：给出所开发软件的技术性能指标，尤其是系统的实时性和其他时间要求，如响应时间、处理时间、消息传送时间等；资源配置要求，精确度，数据处理量等。
• 环境需求：是对软件运行时所处环境的要求。包含硬件要求、软件要求（系统软件）、使用要求（对操作人员的要求）。

需求描述方法

UML是一种标准的图形化建模语言，它是面向对象分析与设计的一种标准表示，有以下特点：

1. 它是一种可视化的建模语言；
2. 它是一种建模语言规格说明；
3. 它允许任何一种过程和方法使用它。

UML的 $4+1$ 视图：

1. 用例视图：用户角度看到的系统功能。
2. 逻辑视图：展现系统的静态或结构特征。
3. 进程试图：描述设计的并发和同步特性。
4. 构建视图：关注代码的静态组织与管理。
5. 部署视图：关注硬件以及软硬件的映射。

UML的九个基本图：

1. 用例图： （从用户的角度）描述系统的功能；
2. 类图： 描述系统的静态结构（类及其相互关系）；
3. 对象图： 描述系统在某个时刻的静态结构（对象及其相互关系）；
4. 顺序图： 按时间顺序描述系统元素间的交互；
5. 协作图： 按照时间和空间的顺序描述系统元素之间的交互 和 他们之间的关系。
6. 状态图： 描述了系统元素（对象）的状态条件和响应。
7. 活动图： 描述了系统元素之间的活动。
8. 构件图： 描述了实现系统的元素的组织；
9. 部署图：描述了环境元素的配置并把实现系统的元素映射到配置上。

视图与图的关系：

• 用例视图：使用用例图和活动图；
• 逻辑视图：使用类图、对象图、顺序图/协作图；
• 进程视图：使用状态图和活动图；
• 构件视图：使用构件图；
• 部署视图：使用部署图。

面向对象的需求分析中包含两个模型：领域模型和用例模型。领域模型表示“当前系统”逻辑模型的静态结构和业务流程，用例模型是“目标系统”的逻辑模型，包含：用例图、用例说明、系统顺序图、操作契约。

领域模型： 针对某一特定领域内概念类或对象的抽象可视化表示。仅仅关注客观世界中的事务并将其可视化，而不关注软件对象。关键思想： 软件类的名称要源于领域模型的概念类和职责，减小人们的思维和软件模型之间的表示差异。

识别概念类： 用例描述中的名词可能是概念类或者是其属性。属性一般可以赋值，概念类则不可以，不确定时当做概念类处理。注意名词和类之间没有映射关系，因为自然语言具有二义性。

领域模型的创建步骤：

1. 找出候选概念类；
2. 描述这些概念类，用问题域中的词汇为其命名，排除与需求无关的概念类；
3. 添加概念类之间的关联；
4. 添加概念类的属性。

类的关系：

1. 依赖关系： A 使用了 B（A使用了B的实例 / A调用了B的方法），则 A 对 B 有依赖。
2. 关联关系： A 知道 B 的属性和方法，关联可以是单向也可以是双向的。
3. 聚合关系： A 是整体，B 是部分，但其生命周期并没有必然联系。
4. 组合关系： 比聚合更强，整体和部分不可分开，生命周期一致。
5. 继承关系： B 是 A 的子类，则 B 拥有 A 的所有属性和方法，在此基础上可以再做拓展；
6. 关联类： C 中含有对 A, B 之间的关联有用的信息。

画图：

1. 依赖关系： A 虚线箭头指向 B；
2. 关联关系： A 实线箭头指向 B，或用实线与 B 连接；
3. 聚合关系： A 空心菱形箭头指向 B；
4. 组合关系： A 实心菱形箭头指向 B；
5. 继承关系： B 空心箭头指向 A；
6. 关联类： C 用虚线连接到 A 和 B 之间的关联。

例子：

用例模型的创建步骤：

1. 确定问题域的分析范围；
2. 确定该范围内可能出现的角色；
3. 根据业务背景或者领域模型，确定每个角色需要的用例，并形成用例图；
4. 基于确定的用例，整理成规范的用例描述文本；
5. 在可能的情况下，将多个角色的用例图合成一个相对完整的用例图；
6. 针对每个用例，确定系统顺序图中角色与系统之间的交互，并绘制系统顺序图。
7. 基于系统顺序图，确定每个事件交互经过系统处理后应该返回给角色的声明性结果，即操作契约。

用例模型的基本结构：

用例图有三个基本要素组成：

1. 角色：使用系统的对象。
2. 用例：角色使用系统功能实现需求目标的一系列成功或失败的场景。
3. 关系：角色和用例，用例和子用例之间的关系。

基本用例： 与角色直接相关的用例，表示系统的功能需求。

子用例： 根据场景描述分析归纳得出的用例，与角色无关，与基本用例相关。基本用例中相同的必须执行的操作可以提取成为包含子用例，而相同的某种条件下可以执行的操作成为扩展子用例。

用例说明范例：

系统顺序图： 在用例描述的基础上，描述角色与系统之间的交互信息，并用可编程的方式命名。一般只需要三个UML符号元素：

• 角色；
• 代表软件系统的对象；
• 两者的交互信息。

例子：

操作契约： 使用前置和后置条件的形式，描述领域模型中对象的详细变化，作为系统操作的结果。模板为：

创建操作契约的指导原则：

1. 根据系统顺序图确定所有系统操作；
2. 对于每个系统操作，结合对应的用例领域模型，找到相关的概念类对象。
3. 对于复杂的操作（用例描述中不清楚的），确定其后置条件（仅描述变化，不关注其实现），包含：对象实例的创建和删除、对象属性修改、对象关联的形成和断开。

例子：

---

--------期中考分割线--------

---

Part3 软件设计方法

软件设计的概念与原则

软件设计的两个阶段：概要设计、详细设计。

概要设计：

1. 制定设计规范
2. 软件系统结构的总体设计
3. 数据结构设计
4. 编写软件概要设计说明书

详细设计：

1. 确定各个功能模块内的算法以及数据组织方式。
2. 确定某种表达形式来描述算法。
3. 编写软件详细设计说明书。

模块： 可单独命名且可编址组成的部分。
包含三个基本属性：功能；逻辑；状态。

设计原则：

1. 单一职责。
2. 开闭原则：对扩展开放，对修改关闭。
3. 里氏替换原则：任何函数中父类可以替换成子类而功能不变。（如正方形不能是长方形的子类，即表达子类应该是父类的细化，而不是特例，不过也需要根据需求来分析）
4. 依赖倒置原则：高层模块不依赖于底层模块，两者都依赖于抽象；细节也依赖于抽象，抽象不依赖于细节。比如函数 funA 调用了 funB，那么 funA 只需要依赖 funB 的功能，而不必关心其具体实现。

软件设计的方法

在明确软件框架的基础上，设计：

1. 对象： 确定系统有哪些对象；
2. 功能： 确定对象的属性和行为；
3. 关系： 确定对象之间的交互关系。

层次化的模型结构：用户界面层、控制器层、业务/应用层、持久化层。

对象的职责通过调用对象的方法来实现，面向对象设计最关键的活动是正确地给对象分配职责。有下面几种职责分配模式：

1. 类职责分配模式：核心逻辑来源于领域模型的概念类，再补充一些功能类。确定两类职责：了解型（了解能用什么，要得到什么）、行为型（具体能干什么）。
2. 控制器模式：把接受和处理系统事件的职责分配给控制器层的对象。
3. 创建者模式：B聚合或包含A，或与A有很大联系时，B负责创建A。
4. 信息专家模式：将职责分配给拥有履行职责的能力（拥有相关信息）的对象。

拥有相关信息后，可创建设计类图：

1. 扫描出所有类，添加属性
2. 添加方法
3. 添加详细信息，如类型、返回值等
4. 添加关联
5. 添加额外信息

Part4 程序实现方法

关键点：源程序文档化。

标识符命名： 含义清晰，可阅读性好。

源程序布局： 确定编码规范（缩进，空格）。

注释：

1. 序言性注释：在代码之前，描述模块作用。
2. 功能性注释：对程序中复杂结构进行局部说明。

Part5 软件测试方法

软件测试的三个必要条件： 明确的测试目标，测试用例，测试环境。

两种测试方法： 白盒测试，黑盒测试。

五种测试类型： 单元测试（对单元使用白盒测试），集成测试（对模块使用黑盒测试），确认测试，系统测试，验收测试。

白盒测试

概念： 将测试对象看做一个透明的盒子，可利用其内部逻辑进行测试。

测试内容：

1. 模块内的所有执行路径
2. 所有的逻辑判断，“真”和“假”都要测试一次

控制流图：

1. 顺序结构的多个节点可以合并为一个节点
2. 分支结构的汇聚处创建一个虚拟汇聚节点
3. 复合判断条件要拆开成多个逻辑判断节点

环路复杂度： 确定了控制流图中独立路径的上界。
计算方法：（有三种，记一种就行）等于图中的区域数。（区域即被点和边划分出的空白区域，外面的开放区域也算）

黑盒测试

概念： 将测试对象看做一个不透明的盒子，只关心其功能是否满足需求说明书以及概要设计说明书，根据功能说明进行测试。

等价类： 相同类型的一组数据。由于不能穷举测试，所以选取每个等价类中的一组数据进行测试。
具体分为 有效等价类 和 无效等价类。
等价类划分表：

测试用例设计： 首先为等价类编号，然后设计用例尽可能多覆盖没有测试过的有效等价类，最后设计用例每次覆盖一个无效等价类。

边界测试：测试边界附近的数据的逻辑。

因果图：用于考虑输入条件的各种组合，画完之后整理得到判定表。

练习题

很多手写的答案懒得上传了，而且我写的也不很对，不能给带歪了。

北邮2021~2022期末考

第一题：
（感觉有点主观的）
软件危机包含五个方面：开发成本难以控制，需求不明确，质量不能保证，可维护性差，缺乏文档资料。
我认为软件工程方法让这些问题得到了一定程度上的解决。首先结构化的需求分析方法产生的用户需求说明书确保了对用户的需求有充分的理解，而软件功能需求说明书确保了开发方向无误，软件质量可靠性也得到提升。瀑布模型等开发模型也强调了开发时文档资料的撰写，这同时保证了软件的可维护性，按部就班的开发下，开发成本（时间，人力）也得到了控制。

第二题：
需求获取的难点：用户无法准确表达需求；双方对需求的理解不一致；用户经常变更需求。
应对方法包含：生命周期模型中的制定计划部分，首先确定了初步需求；需求分析部分制作了领域模型用于和用户确认需求，确保需求无误；开发过程中也可以先开发一个原型给用户使用，再次确认需求的细节；最后测试部分确保需求得到满足。

第三题：
概要设计负责设计程序的框架结构、开发方法、功能划分等，而不涉及具体实现；详细设计则需要描述每个模块中每个方法的具体逻辑与算法。
软件设计中的软件对象是用于描述系统功能的类，而操作契约后置条件表示的对象是这个类的内部具体实现逻辑，两者从不同角度描述了类的功能。

第四题：
明确的测试目标，测试用例，测试环境。
需要先定位问题，然后修改出问题的部分，重新再对该部分进行单元测试，功能无误后重新集成再进行集成测试。

第五题：
好像不在今年考点里，先不管。

关键词：商品，商品信息，购物车，商品数量，订单，物流，物流运单。
概念类：商品，购物车，订单，物流。

今年不考结构化需求与分析。

重点！必考！

超级大原题。

北邮2018期末考

一、判断题
（去掉了一些课件上根本没见过的）

软件工程三要素是：程序、数据及相关文档。
错。是方法、工具、过程。

UP模型是一种以用例为驱动并融合了喷泉和增量模型的软件生命周期模型。
对。但理论上今年不考。

数据、功能和行为模型构成了需求分析阶段的一组三元模型
对。但理论上今年不考。

软件开发的最终目标是实现目标系统的逻辑模型。
错。最终目标是：以较低的成本，可控的进度……高质量的，满足用户需求的系统。（反正一大串，一眼错）

UML规范所规定的概念类关系中，从弱到强依次是：依赖关系、关联关系、聚合关系、组合关系、继承关系。
对。

无论是外观还是用例控制器，均无需实现系统事件请求的内容。
对。

确认测试是以测试人员为主，开发人员为辅，并且以系统设计说明书为参照标准的测试阶段。
错。是需求规格说明书。

在基于等价类划分法设计测试用例时，应该使得每个测试用例覆盖尽可能多的无效等价类。
错。一个用例只应该覆盖一个，要不然无法确定每个无效等价类都能被正确处理。

二、选择题

1、D
2、D 不能加快开发进程
3、C
4、B
5、课件也妹说有这种约束啊
6、A
7、D
8、C 这是交叉引用的内容
9、B 但不考
10、B

考后总结

今年考题结构和2021~2022那一套基本一样啊，最后一个大题换了个名字又拿来用了，很能偷懒了。

今年选择题判断题倒没有很偏，见到好歹能说：哥们我好像对你有点印象啊。虽然还是有些不会的，但可以说一句良心了。（$20$ 分）

简答题依然抽象，只有把概念都背完的神人能做了。印象中有这些题：OOD中动态结构设计和静态结构设计的作用和联系；操作契约后置条件有哪三种，作用是什么（哎这个真的很怪啊问的，问有哪种不就是创建实例、形成关联、修改属性值，还问有什么作用？作用不就是创建能创建的实例，形成能形成的关联，修改能修改的属性值吗？？我真的迷惑好久）；需求分析的主要活动和可作为里程碑的结果是什么。剩下俩不太记得了。（$4\times 5$ 分）

大题有：黑盒测试的等价类划分（$10$ 分，比较常规）；画控制流图，问环路复杂度和路径独立集（$10$ 分）；给了个操作契约，问系统顺序图（还有个 $3$ 分小问不记得了）（$10$ 分）；以及和2021~2022几乎一样的大题，就是把第二小问换成画领域模型（$30$ 分）。

考得一般啊，算了不管了。