终极软工笔记

系列文章目录

终极数据库笔记
终极计网笔记
终极C++笔记

---

---

动力猿在备考研究生复试时总结的软工考点，纯考试向，应该能应对期末考试和绝大多数学校的研究生复试。如果对您有所帮助，麻烦点赞关注支持一下动力猿吧！

---

二、类图

类加上它们之间的关系就构成了类图，继承关系必考无疑

1.各组件的画法

类

整体是个三层矩形，第一层类名，第二层数据成员，第三层方法。

基类的数据成员前用#
派生类的数据成员前用-

所有的方法前都是+号

类间关系

1.先判断是不是 继承

多个类都有相同的属性和方法肯定有一个超类，题目没给就自己加。

2.再判断是不是 聚集（聚合）与合成（组合）

聚集与合成都用来表示类与类之间整体与部分的关系。

聚集弱，主亡子存子还能用。比如课程与培训班，一个课程可以有多个培训班，培训班离了课程也还有意义。再比如员工和地址，一个员工可以有多个地址，地址离了员工也还是有意义的类。

合成强，主亡子亡子不能再用。如一个订单项只属于一个订单，订单项离开订单没有意义。一个心脏只属于一个人，没有人心脏也就不能存在。

3.最普通的就是关联和依赖

判断是依赖还是关联——
依赖：只是操作对方的数据，而没有语义上的直接对应关系。依赖一般是单向的，有操作任务的一方依赖于被操作的另一方。
关联：两个类在语义上有直接对应关系时，可以说这两个类之间存在关联关系。关联一般是双向的，你不能没我，我不能没你。

单向依赖是带箭头的虚线，由操作方指向被操作方。
比如 管理员与课程：
这是一个单向依赖关系。因为管理员只是对课程来进行增删查改操作，而课程和管理员是没有语义上的直接对应关系。而且管理员需要管理课程，没了课程不行，而课程可以没有管理员。

双向关联是不带箭头的实线。
比如学生和课程：
这是一个双向关联关系，因为学生和课程在语义上有直接对应关系，一个学生选哪些课是确定的，一门课被哪些学生选也是确定的。学生必须选课，课也必须得有学生选。

2.画类图并给出设计思想

类图设计思想:
在教学评估系统中，发现学生类、教师类、管理员类等都有用户名、联系电话、电子邮箱等属性，都有登录的方法，则将这些共性部分提取出来，构造一个超类用户类和三个子类的两层泛化结构。考虑到学生数量远大于教师和管理员的数量，故没有将学生的学号和教师、管理员的工号抽象成一个属性，而是将它们分开。

有一个教学评估系统系统的主要功能模块如下:
(1)用户认证模块，首先用户输入登录信息，经过用户认证模块验证正确后就可以访问整个系统所有被赋权访问的模块。
(2)学生评教模块，模块从学生评教入，针对参与教师课堂教学质量评价的学生，提供学生评教和个人信息修改的功能。
(3)教师评学模块和教师互评模块，从教师评学入手，针对参与教师课堂教学质量评价的教师，提供教师评学、教师互评和个人信息修改的功能。
(4)基础数据管理模块，有部门管理、专业管理、班级管理、学生管理、教师管理几个功能。
(5)课程信息管理模块，有学期管理、课程类型管理、专业课程管理学期教学升划管理、课表管理几个功能。
(6）测评管理模块，有教师评学和学生评教管理两个功能。
(7)系统管理模块，有教师用户管理、数据维护和退出3个功能。

——明显的超类和子类的继承关系（一般就是用户分很多类）才是给分的考点
——有可能有隐含的类如管理员，因为系统的管理模块肯定是管理员在做，管理模块都可以简化为管理员的操作方法而不用再新建类

3.要求改造XX类图使之更合理

改造类图重点是改造关系，一般是添加继承关系。不要舍本逐末花时间填充属性和方法，不会给分的。

4.解释类图

该类图体现了接口隔离原则和抽象思想。
图中有一个负责提供服务的Service类以及三个使用服务的客户端。由于这三个客户端所使用的服务不同，因此提供三个不同的接口，即 IService1,IService2和 IService3。每个接口都只将对应客户端需要的服务暴露出来，从而减小了客户端与服务器端之间的依赖性，体现了接口隔离原则。
使用接口把方法的特征和方法的实现分割开来，很好地体现了抽象思想。

三、画用例图

参与者就是人，用例就是人能干的事，边界就是系统，参与者之间只有泛化而且是必考的，参与者和用例间只有带箭头的关联，用例间有泛化、包含和扩展。

1.边界

边界：用一个大框表示系统，框里是系统的功能，框外是参与者。

2.参与者和用例的关联

参与者是用以表示和系统交互的参与者角色，一般是人，使用一个小人表示。
用例是参与者可以使用的系统服务，对系统提供的服务进行描述。使用一个椭圆表示。

参与者用带箭头的直线指向用例表示参与者可以使用系统中的这些功能。

3.参与者之间的泛化

参与者之间只可能有这种关系，几乎是必考

4.用例之间的泛化、包含、扩展

用例间泛化：一般与特殊，而不是整体与部分的关系。
三角箭头指向超类用例。

用例间包含：整体与部分的关系，所有部分加起来才是一个完整的整体。
虚线箭头从整体指向部分，并有书名号include。

用例间扩展：执行基本功能的过程中让用户自己选择执行不执行的附加功能，而不是另一项功能。
虚线箭头从部分指向整体，并有书名号extend。

对某个用例写用例文档

四、画顺序图

顺序图中的元素包括对象、生命线、控制焦点、消息。

对象

顺序图中的对象就是用例图中的参与者和边界系统，也就是说只有人和系统才能做到传递消息、使用和提供服务。

生命线

生命线是一条垂直的虚线。表示对象存在的时间。每个对象的底部中心的位置都带有生命线。

控制焦点

在对象的生命线上包含一个矩形，表示当前对象正在工作。
在一个用例功能中：使用服务的对象发出请求服务消息时开始控制焦点，一直到接收返回消息它的控制焦点才会消失。而提供服务的类是收到请求消息时才开始控制焦点，返回消息时控制焦点消失。
两个不同的用例功能之间所有对象的控制焦点都有明显的空白期。

消息

请求服务和返回信息都是消息

五、软件开发

1.规划软件开发方案

1.选择模型
针对这个项目，我会采用RUP模型来进行系统开发。使用RUP模型，可以在开发过程中与用户很好地交互，减少开发风险，调整开发计划，加强团队合作等。

2.人力配置
分配系统架构师、软件架构师、实施工程师等角色，并对团队成员进行YY（客户要求使用但我们不擅长的技术）的培训。

3.项目规划

制定详细的项目计划和各阶段的时间表及任务分配，并确定关键里程碑监控项目进度。

4.系统设计
进行系统架构设计，着重考虑用户友好性和易用性。

5.开发测试

采用敏捷开发方法开发，并进行单元测试、集成测试和系统测试。

6.上线维护

在网站开发完成后进行部署和上线，建立后续的维护支持机制

7.用户反馈

收集用户反馈，不断优化网站功能。

2.选择所用过程模型及原因

软件开发中主要的过程模型
线性系列模型：线性顺序模型、瀑布模型、RAD模型
演进系列模型：边建边改模型、增量模型、螺旋模型、RUP模型

答RUP模型。
原因如下:项目规模较大、需要多人协作:需求不够清楚、缺乏领域经验;技术基础薄弱，缺乏相关准备。使用RUP/增量/螺旋模型，可以在开发过程中与用户很好地交互，减少开发风险，调整开发计划，加强团队合作等。早期迭代中可以先做一些技术实验或者构造原型产品，尽快熟悉业务需求，掌握相关技术，增强开发人员信心;然后在后面的迭代中,完善基础构架，逐步开发出符合用户需求的产品。

3.团队角色

系统架构师:负责整个项目设计活动的领导和协调。1人

软件架构师:确立系统的整体结构、组成元素以及这些主要元素之间的接口。1人

构件设计师:设计系统的构件细节。1人

数据库设计师:设计系统所需的数据库结构。1人

界面设计师:设计系统的用户交互界面。 1 人

实施工程师：对整个项目的实施活动进行领导和协调。1人

程序员:对系统构件进行开发与测试。6人

设计复审员：执行对软件设计的正式复审。1人

代码复审员：负责审查程序员开发出来的代码。 2人

测试工程师：领导测试小组对测试活动进行计划、设计、实施和评估。2人

4.项目存在的风险

刚刚当上经理，缺乏管理经验;
采购的设备若没按时到位，将影响项目实施和部署;
项目规模较大、需要多人协作;
需求不够清楚、缺乏领域经验;
技术基础薄弱，缺乏相关准备

5.设计一个可复用的组件

开发人员只需要设置该控件的Length属性(生成验证码的字符串长度)和 SourceChars属性(验证码的字符来源)来配置图片特征。

开发人员可以使用Refresh方法来XX，使用 Validate方法来XX。

六、设计测试用例

数据库产品规范要求该产品必须能够处理从1到65535的数据

1.等价类划分法

按照边界值划分等价类（小于下限、上下限之间、大于上限），每个类里面其实是若干测试用例。

– 等价类1：少于1个记录。
– 等价类2：从1到65535个记录。
– 等价类3：多于65535 个记录

2.边界分析法

确定划分等价类依据的若干边界值（一般就上下限两个），每个边界值及其前后一个数（共三个）都取作测试用例。每两个边界再取个中间数。
– 测试用例1：0个记录
– 测试用例2：1个记录
– 测试用例3：2个记录

– 测试用例4：100个记录

– 测试用例5：65534个记录
– 测试用例6：65535个记录
– 测试用例7：65536个记录

七、面向对象方法设计一个XX系统

某云盘读写系统需要满足用户在任何设备上传和下载文件.并且能将文件同步于用户登录的所有设备。请简单说明如何使用面向对象的方法设计该云盘的读写系统。

我们的设计步骤如下：

步骤 1: 定义用户需求和用例

步骤 2: 定义类和它们的责任

步骤 3: 设计类之间的交互

步骤 4: 实现类和方法

步骤 5: 测试和验证

其中最重要的就是我们需要使用面向对象的方法定义一系列的类,包含属性和方法。主要的有：

1. 用户对象（User）:

   • 属性: 用户名、密码等。

   • 方法: 登录、登出、注册设备、注销设备等。

2. 设备对象（Device）:

3. 文件对象（File）:

4. 存储管理器（StorageManager）:

5. 权限管理器（AuthManager）:

6. 网络通信接口（NetworkInterface）:

八、数据流图

英语阅读理解的定位环节，根据实体名/进出的数据流名在说明或图里定位，逐个确定。

一、先背大题这些概念有印象就行

软件工程是以质量为核心，为了经济地开发满足客户需求的软件而研究、建立和应用的系统化的、有规则的、可度量的、可控制的工程原则、方法。

1.耦合和内聚

•耦合
– 是模块间相互联系强弱程度的度量
– 各模块之间的耦合越松散越好

（1）内 容耦合
最高级别的耦合，一个模块直接访问另一个模块的内部的某个位置。

（2）公 共耦合
两个模块间通过一个公共环境进行数据交换。
（3）外 部耦合
模块对外部系统有依赖关系。
（4）控 制耦合

（5）印 记耦合
两个模块之间通过参数交换方式产生耦合，且交换的是类而不是数据元素。

印记耦合降耦

这段代码存在印记耦合，可采用接口或简单参数类型的方法降耦。
public class Order
{
public float getTotalMoney(int userLevel, int consumeScore)
{//…
return 0;
}
}

需要传递的参数较少时，数据耦合较好
需要传递的参数较多时，印记耦合要更好
（6）数 据耦合
如果两个模块之间通过函数的参数表交换信息,并且这些信息是基本数据类型(如 int,float, bool 或 string 等)，则这种耦合为数据耦合

降耦后的代码可以像这样修改：
引入了 main 函数来处理输入和输出，而 fun2 函数现在只是简单地调用 fun1 并返回结果，遵循了单一职责原则。这样，我们就降低了函数之间的耦合。

#include <stdio.h>

int fun1(int n, int k) {
    if(k == 1)
        return n;
    else
        return 0;
}

int fun2(int n, int k) {
    return fun1(n, k);
}

int main() {
    int n, k;
    scanf("%d %d", &n, &k);
    printf("%d\n", fun2(n, k));
    return 0;
}

• 内聚
– 是一个模块内部各部件间联系紧密程度的度量
– 一个模块内的各个部件联系越紧越好

模块尺寸太大时应分解以提高内聚。

（1）功 能内聚———内聚性最高

功能性内聚是最强的一种内聚形式，一个模块（或类）只完成单一的功能。

这段代码中的 GetAge() 函数具有功能内聚性，因为它包含了与计算年龄相关的所有步骤，从接收输入到处理时间再到输出结果，所有步骤都共同完成一个单一的功能。

"用户注册-登录使用-更改密码"被认为是功能性内聚。

（2）顺 序内聚
（3）通 信内聚——所有的部件都访问同一组数据，各部件之间只有数据关系没有控制关系。
（4）过 程内聚
（5）时 间内聚
（6）实 用程序内聚
（7）偶 然内聚
（8）层 内聚

2.基线

IEEE将基线定义为:已经通过正式评审和批准的规格说明或者产品，它可以作为进一步开发的基础，并且只有通过正式的变更控制规程才能修改它。

3.白盒测试与黑盒测试

（1）
使用白盒测试导出测试用例是依据模块的编码，即模块的内部逻辑对测试者是可见的

白盒测试导出的测试用例能保证：
– 模块中所有独立途径至少测试一次
– 测试有逻辑决策真和假两个方面
– 在所有循环的边界内部和边界上执行循环体
– 检查内部数据结构以保证其有效性

白盒测试即使测试了程序的所有路径，程序也不一定100%正确

白盒测试有以下几类
基本途径测试：指覆盖基本途径集合的试验用例将使程序中的每个语句至少执行一次

条件测试：检查程序中所包含的逻辑条件

循环测试：确定循环结构是否有效

（2）

黑盒测试在程序或者模块的接口级进行，而不考虑程序的内部逻辑。

它主要用于检测程序中不正确或者漏掉的功能、接口错误、数据结构错误、初始化错误等。

黑盒测试有以下两类

等价类划分： 把一个程序输入的定义域划分成不同的数据类，然后根据这些数据类可以导出测试用例

边界值分析： 在等价类划分的基础上，不是随意选择等价类中的元素，而是专门选择等价类“边”上的元素。

4.辅助性活动（普适性活动）

软件项目跟踪和控制

软件质量保证

软件配置管理

风险管理

技术评审

测量

等

5.数据流程图/用例图/数据流图

用例图中，
角色与系统通讯，可以是系统外部与系统自身的任何事物
参与者是在系统之外，透过系统边界与系统进行有意义交互的任何事物

数据流程图/层次图/模块图不是UML图（类图/用例图/顺序图/活动图）
数据流程图分三个层次:总体图、零级图、细节图，分别描述系统的不同特征
数据流程图主要使用的阶段是用户需求分析

6.软件/组件复用

软件/组件复用：在软件开发中通过重复利用已有的可靠软件代码/组件，提高开发效率、降低成本，并提高软件质量。

可复用软件：为了复用目的而设计的软件。
组件：具有特定的功能和接口并且可以独立使用或协同工作的一些函数、类、模块或者库。

7.软件构架

软件构架是指系统的组织结构和基本特征，它可以递归解构为通过接口交互的部件、连接部件的关系以及组装部件的一些限制条件。

8.回归测试/集成测试

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

白盒测试、黑盒测试、单元测试、集成测试不是包含关系，但是单元或集成都会使用白盒或黑盒测试方法。

回归测试:当有新模块加入时，要对原测试通过的模块重新进行测试
单元测试和集成测试都要进行回归测试。

集成测试：

自底向上的集成测试方法可以先确保系统的基础功能（底层模块）没有问题，然后再测试上层模块。这样可以早期发现并解决问题，提高测试的效率。
例如一个简单的在线购物系统，它可以被分为以下几个模块：用户界面模块、商品浏览模块、购物车模块、支付模块、订单管理模块。
如果按照自底向上的集成测试方法，我们可以按照以下的模块测试顺序：

• 首先，测试最底层的模块，如商品浏览模块、购物车模块、支付模块、订单管理模块。
• 然后，测试与底层模块交互的模块，如用户界面模块。

自顶向下的集成测试方法的优点是可以尽早发现高层次的问题和缺陷，关注系统的整体行为和交互。这样可以确保系统的一致性和稳定性，提高测试效率。
例如将上面的例子反过来。

9.软件生命周期

1.需求分析的结果是软件系统开发的基础，关系到工程的成败，产品的质量
功能需求：描述用户使用产品必须要完成的任务
非功能需求：从各种角度对系统的约束和限制

2.决定系统可扩展、可维护、可复用性以及系统性能的是系统设计

3.甘特图是一种进度计划表达方式

4.软件的生命周期一般可以划分为3个阶段：软件定义，软件开发，软件维护

4.软件配置管理贯穿于软件的整个软件生命周期，

10.接口和抽象类

接口和抽象类的区别：
（1）接口是一些不包含具体实现细节的特征的集合。抽象类是一种不能被实例化只能被继承的类。
（2）接口只能声明方法而不能实现方法，也不包含任何实例变量。抽象类可以包含抽象方法和具体方法，也可以包含实例变量。
（3）一个类可以实现多个接口。一个类只能继承一个抽象类。

11.开闭原则/里氏替换原则/依赖倒转原则/接口隔离原则

开闭原则:一个软件实体应当对扩展开放、对修改关闭。

里氏替换原则:子类可以替换父类，可以出现在父类能出现的任何地方。

依赖倒转原则:要依赖于接口或者抽象类，不要依赖于具体类。

接口隔离原则：指设计接口时应该保持接口的独立性，不应该强迫依赖不需要的方法或属性。

12.以用户为中心的设计

是一种设计方法论，旨在确保产品的设计和开发过程始终以用户的需求和体验为中心。强调理解用户的特征和任务、确保用户参与、遵循良好的界面设计原则。

14.复杂性与工作量的关系

设C(X)定义问题X的复杂性函数，E(X)定义解决问题X所需要工作量的函数，对于两个问题pl和p2，一般情况下如果C(p1)>C(p2)，则 E(p1+ p2)>E(p1)+ E(p2)

15.三点值估计软件尺寸

基于LOC通过三点值估计软件尺寸的公式是EV=( Sopt + 4Sm + Spress)/ 6

16.投入和净现值计算最优方案

A的投入/B的投入>A的净现值/B的净现值
则说明投入与回报不成正比，B是最优方案
否则A是最优方案

17.信息隐蔽

信息隐蔽：模块内部的数据结构和算法对用户是不可见的

模块间的通讯只能通过模块提供的接口实现
模块应该是单入口的

18.构件的图形表示

19.分治/抽象

分治：将一个大问题分解为多个小问题来解决，从而降低问题的复杂度，当问题被分解到一定程度后就可以直接解决。

抽象：通过隐藏细节而只关注关键特征，将复杂的系统或问题简化为一组概念或模型。
抽象有利于认识事物的普遍特征:有利于软件的复用: 有利于提高系统的可扩展性。

20.需求文档

需求文档是软件工程中的重要文档，它详细描述了一个产品的用户预期、功能需求等。主要分为以下几类：用户需求文档、系统需求文档和软件需求规格文档。

• 用户需求文档：描述了用户对产品的需求，比如产品应该完成什么任务。指导需求分析。

• 软件需求规格文档：描述了软件的功能需求、设计约束等。指导软件设计和开发。

• 系统需求文档：描述了系统应该提供哪些服务，满足哪些性能。指导系统设计。

21.包间关系

图中显示的是UML中两个包的包含关系，其中 A 包包含了 B 包。

一个电子商务应用程序，可能会有一个名为“ECommerce”的主包，它包含了多个子包，如“ShoppingCart” “User”，“Product”等。
在这个例子中，“ShoppingCart”是“ECommerce”的一部分，它专门处理购物车相关的功能，比如添加商品、删除商品和计算总价等。

22、模块规模、模块成本、接口成本、总成本之间的关系

从图中可以看出：

1. 模块规模成本：随着模块规模数目增大规模减小，模块规模成本减少。因为随着模块数目增多每个模块的内部复杂性越低。

2. 接口成本：随着模块规模数目增大规模减小，接口成本增加。因为更多的模块导致通信接口数量和复杂性升高。

3. 总成本：是模块规模成本和接口成本的总和，随着模块数目增多呈现先下降后上升的趋势，最低点M代表了成本最优的模块数目。

通过这个图，我们可以理解软件模块设计的一个重要原则：模块化需要平衡模块内部的复杂性和模块间接口的数量复杂性，以达到总成本最优。

23.需求分析为什么会贯穿整个设计过程：

需求分析是确定软件功能的关键步骤，它是软件设计过程中的持续活动而不是一次性任务。
需求分析在项目初始化阶段帮助我们明确项目目标；在设计和实现阶段指导我们如何构建系统以满足用户需求；在测试阶段提供了验证是否满足预期的标准；

24.实施活动为什么会贯穿整个软件开发过程：

因为实施活动是一个连续的、迭代的过程，涵盖了从需求分析、设计、开发、测试到部署等所有阶段，每一个阶段都包含了实施活动。

25.瀑布模型

瀑布模型是一种严格线性的开发过程，其中每个阶段如需求分析、设计、实现、测试、维护等都是连续的，每个阶段完成后才能进入下一个阶段。适用于项目需求明确且稳定、相对简单、质量要求高的情形，不适用于需求经常变化或不完全确定的项目。

在现代软件开发实践中，更加灵活和迭代的开发模型往往更受欢迎，如RUP模型。

26.软件总体设计（软件架构师的任务）

软件总体设计的任务是确立一个合理的软件体系结构，包括系统的整体结构、组成元素以及这些主要元素之间的接口。

27.过时题

软件工程中SQA指软件质量保证。