软件设计师上午题
软件设计师上午
https://zhuanlan.zhihu.com/p/1893610881109180431
进制与校验码内容暂未写入。
1 知识产权
知识产权分为两类:工业产权、著作权
工业产权:专利、商标
1.1 著作权
著作权(版权):
人身权【发表权(终身+死后50年)、署名权、修改权、保护作品完整权】
财产权【除人身权外】
1.1.2 知识产权地域性特点
只能在本国领域内受法律保护,在其他国家则不受保护,想要在外国受保护,则要申请外国专利。
1.1.3 软件著作权的主体与客体
主体:享有著作权的人,根据**《中华人民共和国著作权法》和《计算机软件保护条例》**
客体:著作权法保护的计算机软件。具体是指计算机程序【源程序和目标程序】及相关文档【软件文档(程序设计说明书、流程图、用户手册)】
1.1.4 软件著作权的权利
人身权(精神权利):发表权、开发者身份权(署名权)
财产权(经济权利)
保护期限:自软件开发完成之日起,50年,到期后只有署名权
1.1.5 软件著作权归属
- 职务作品,著作权就属于单位,开发者只有署名权
著作权属于个人须同时满足:1、不是职务作品;2、作品与单位工作内容无直接联系;3、未使用单位物质技术开发。 - 委托开发的软件
合同约定;若无约定,受托人享有
1.1.6 软件著作权侵权
未经同意发表或登记作品;更改软件署名;未经(作者/受让者)许可修改/翻译/复制作品;
翻译:将原软件从一种程序语言转换成另一种
1.2 软件商业秘密权
对技术信息和经营信息提供保护
1.3 专利
申请要书面,一份申请一份发明,先申请先得,同一天申请,协商,未果就都不给
1.4 商标权、商标注册
商标自注册起10年内有效,期满前6个月可续展,每次10年,可无限延长
先注册先得,同一天谁先使用先得,否则协商,未果抽签
烟草必须先注册商标
2 数据库
2.1 概述
2.1.1 概念数据模型
信息=数据+数据处理
模型是对现实世界的模拟和抽象
2.1.2 结构数据模型
2.1.2.1 层次模型
树结构表示,是有向树
2.1.2.2 网状模型
图结构表示
2.1.2.3 关系模型

基本术语:
- 关系:一个关系就是一张二维表,表名是关系名
- 元组:表的一行即一个元组
- 属性:表的列,列名是属性名
- 域:属性的取值范围
- 关系模型:对关系的描述成为关系模式,如:教师(编号、姓名、性别)
- 候选码:属性或属性组合,能够唯一标识元组
- 主码:候选码中选一个
- 主属性:任何候选码中的属性
- 外码:若关系中的属性并非主码,但是另外关系的主码
- 全码: 所有属性组合在一起才能唯一标识的候选码
- 超码:包含码的属性是超码,如学号是码,(学号,姓名)是超码
2.1.3 三级模式两级映像
数据体系结构的特征:三级模式两级映像
外模式:视图
外模式/概念模式映像:保证数据的逻辑独立性
概念模式:基本表
概念模式/内模式映像:保证数据的物理独立性
内模式:存储文件
2.2 关系代数
2.2.1 完整性约束
3个完整性约束:
实体完整性(主码属性不为空)
参照完整性(外码的值要么在参照表能找到,要么为空)
用户定义的完整性
2.2.2 集合运算符
关系代数:
- 关系的并∪:两个关系的所有元组合并,去重。R∪S
- 关系的差 - :关系R删去关系S中相同元组后 组成新关系。R-S
- 关系的交 ∩:既属于R又属于S的元组看 组成新关系。R∩S
- 笛卡尔积 ×:两个表所有元素相乘。R×S
2.2.3 专门的关系运算符
-
投影 π:选取列,select A,C from R

-
选择 σ:选择满足条件的元组,where

-
连接:基于笛卡尔积进行选择
- θ连接:< > ≥ ≤

- 等值连接:=

- 自然连接:去重的等值连接

4. 外连接


- θ连接:< > ≥ ≤
-
除

2.2.4 关系代数转换成SQL
select 1,2,3 不支持
投影:select A,B,C from R;
选择:select A,B from R where B > ‘3’;
笛卡尔:select A,B from R,S;
2.3 SQL语言
分为4类,DD(Define)L、DM(Manage)L、DQ(query)L、DC(control)L
2.3.1 数据定义语言DDL(了解)
- 建立数据库
create databse 数据库名 - 建表
- 改表
alter table 表名 add 列名 类型
alter table 表名 modify column 列名 新类型
alter table 表名 drop column 列名 - 删表
drop table 表名
列级完整性约束条件(了解):not null、unique、not null unique、default
表级完整性约束条件(掌握):primary key、check、foreign key
例子:
create table S(
sid int,
phone int not null,
name char(10),
sex char(10) default ‘未知’,
score int,
fid int,
primary key(sid),
foreign key(fid) references R(fid),
check (score >=0 and score <= 100)
)
2.3.2 数据操纵语言DML
- insert
insert into xxx values (1,”zhangsan“,18)
insert into xxx(id,name) values(1,“lisi”) - delete
delete from xxx where id=1 - update
update xxx set name=“wangwu” where id=1
2.3.3 数据查询语言DQL
- 投影查询
select sno from student
select distinct sno from student
select sno as ‘学号’ from student - 选择查询
where子句可用的运算符
between、like、in、and/or、is null/is not null - 排序查询
order by xx asc/desc
默认升序,必须是最后一个子句
order by 课程号 desc,分数 asc - 聚合函数
avg()
count()
min()
max()
sum() - 数据分组
where group by having
where不能用聚合函数,有聚合函数用having
如果在聚合函数的基础上进行分组,必须把除聚合函数外的所有属性进行分组 - 连接查询
内连接:
等值连接:表之间的关系是等于。如学生和成绩表
非等值连接:表之间的关系不是等于。如学生成绩和等级表
自连接:把自己作为两个表用。如学生成绩表内对比
外连接:
from A left/right/full join B on (A.xx = B.xx) - 子查询
一般子查询:在where中有select,若子查询的结果大于1,在比较时要用关键字in、not in、any、all
相关子查询:子查询有用到主查询中的属性,相当于嵌套循环
Exists子查询:在相关子查询的基础上用到Exists - 查询结果的并、交、差运算
union、intersect、except
真题易错积累:
这种题目,逐句理解。
1、每个供应商可以为多个项目供应多种零件——供应商:项目:零件=1 :* :*
2、每个项目可由多个供应商供应多种零件——供应商:项目:零件=* :1 :*
合并后是 * :* :*
2.3.4 SQL访问控制
grant授权,revoke收回


2.3.5 视图
视图是从一个或多个基本表或视图中导出的表,是虚拟表
2.3.6 索引
CREATE UNIQUE INDEX sp-no ON student(sno ASC,Pno DESC)
DROP INDEX sp-no
索引是对数据库内模式或存储文件进行修改
2.3.7 关系模式
关系模式应是五元组:R<U,D,dom,F>
通常情况是三元组:R<U,F>
R:关系名
U:属性
F:函数依赖。学号->姓名 的意思是(学号决定姓名 或 姓名依赖于学号)
2.3.7.1 函数依赖


2.3.7.2 求闭包
技巧:看哪个属性没在右边出现过,哪个属性就肯定是主属性

2.3.7.3 关系模式的范式
关系数据库中,用范式衡量规范化程度。
有6种范式:1NF、2NF、3NF、BCNF、4NF、5NF
满足最低要求的是1NF,在1NF基础上完善的是2NF……
最重要的是3NF和BCNF
- 1NF
R中的每个属性不能再分,即满足原子性。
不能排除数据冗余和更新异常的问题,因为可能存在部分函数依赖【(学号,课程号)->成绩,但是存在 学号->(姓名,学院,院长)】。
更新异常:理论上值要更新 学生 名字只需要修改一条记录,现在改一条有异常
插入异常:无法单纯增加 学生/课程 记录
删除异常:无法单纯删除 学生/课程 记录- 关系模式分解:1NF->2NF


- 关系模式分解:1NF->2NF
- 2NF
R中的每个非主属性都完全函数依赖于候选码,但可能存在传递函数依赖,所以还是可能存在数据冗余和更新异常的问题。
更新异常:理论上值要更新 院长 名字只需要修改一条记录,现在改一条有异常
插入异常:无法单纯增加 学院/院长 记录
删除异常:无法单纯删除 学生/学院/院长 记录- 关系模式分解:2NF->3NF

- 关系模式分解:2NF->3NF
- 3NF
R中的每个非主属性都非传递函数依赖于候选码,但可能存在主属性对码的部分依赖和传递依赖,所以还是可能存在数据冗余和更新异常的问题。
* 关系模式分解:3NF->BCNF
- BCNF
F中的每个依赖的决定因素必定包含R的某个候选码,而不是主属性,该范式消除了 插入和删除异常。
满足BCNF的特点:
所有非主属性对每个码都是完全函数依赖
所有主属性对每个不包含它的码,也是完全函数依赖
没有任何属性完全函数依赖于非码的任何一组属性 - 4NF:无多值依赖时不讨论4NF
多值依赖:X->->Y。如一门课程有多个任课老师,也有多本参考书
可以看到规范的表中,实际上的候选码应该是 (任课老师,参考书)
2.3.7.4 判断函数依赖技巧
- 部分函数依赖
有括号的,重点看括号中的属性是否决定其他非主属性 - 传递函数依赖
可用伪传递依赖做题
X->Y,WY->Z,XW->Z
2.3.7.5 关系分解后的无损连接和保持函数依赖

- 无损连接
表拆分后能通过自然连接合成一张表,且不缺少元素。
这题的D,通过自然连接后拥有ABCDE元素,和原本一样 - 函数依赖保持
表拆分后,函数依赖和未拆分前一致
分解后的函数依赖可通过原本的条件推出
比如CB->A=CB->E+E->A、E->D=E->A+A->B+B->D
所以分解后的依赖有{A->B、BC->A、E->D、E->A}
用原表的候选码 CE 也可以推出闭包 ABCDE
所以函数依赖成立
函数依赖保持比较复杂,可以通过无损连接简单判断
2.4 数据库设计
设计策略:自顶向下、自底向上
2.4.1 数据库设计步骤
4+2 阶段
1、需求分析:收集用户需求,确定系统边界
2、概念设计:E-R图
3、逻辑设计:E-R图 转 关系模式与规范化
4、物理设计
5、数据库实施阶段
6、数据库运行、维护阶段
- 需求分析
系统需求说明书:需求说明文档、数据字典、数据流图;需求边界
- 概念设计
E-R图:实体矩形、联系菱形、属性椭圆
弱实体:比如家属是弱实体,依赖于职工而存在,如果职工不存在,表中也没必要体现家属
联系:1:1、1:n、n:m
属性:简单/复合、单值/多值、NULL/派生
属性名有下划线代表 主码
2.4.2 概念结构设计阶段

2.4.2.1 分ER图的冲突
- 属性冲突
同一属性可能存在于不同的分E-R图,他们的类型、取值范围、单位等可能会不一致 - 命名冲突
同名异义、异名同义
命名冲突只出现在:不同的E-R图中有相同的实体,且相同的实体中有 同名异义、异名同义 的属性,那么在合并时就需要整改。
但是如果是不同的实体,即使属性名一样,也不算命名冲突。 - 结构冲突
同一实体在不同分E-R图中有不同数量的属性;同一对象在不同E-R图中分别为实体或属性
2.4.3 逻辑结构设计阶段
在概念结构设计的基础上进行设计,可以是层次模型、网状模型、关系模型
2.4.3.1 E-R图关系模式的转换
- 实体向关系模式的转换
实体名——关系模式名称
实体属性——关系模式属性
实体标识符——关系的码 - 联系向关系模式的转换
- 一对一
方法一:
联系名——关系模式名称
关联的实体、联系属性——关系模式属性
任意一方实体——关系的码
方法二:
将联系属性加到任意一方实体,并增加另一实体的码 - 一对多
和1对1差不多
方法一:
……
多方实体的码——关系的码
方法二:
将联系加到多方,增加另一实体的码 - 多对多
创建关系模式,属性为 多方实体的码 及 联系的属性
关系的码为 多方实体的码构成的属性组
- 一对一
若有多值属性,将E-R图转换为关系模式时,将实体的码分别和每个多值属性独立构成一个关系模式,得到的关系模式为4NF
2.4.4 数据库的控制功能
事务管理
原子性:要么都做,要么都不做
一致性:事务的执行结果必须保证从一个一致性状态到另一个一致性状态
隔离性:事务并发执行的过程,互相不可见
持久性:只要事务提交,即使数据库奔溃,操作也永久有效
2.4.5 数据库的备份与恢复
数据库的关键技术在于建立 冗余数据,即备份数据
恢复的基本原理是:建立数据冗余
备份方法
- 静态转储和动态转储:静态转储期间无法进行任何操作;动态可以
- 海量转储和增量转储:海量是全部;增量是针对上次
- 日志文件:每次事务对数据库的操作都写入日志,发送故障时可利用日志撤销改变
恢复方法步骤
1、反向扫描日志,查找事务的更新操作
2、对事务的更新操作执行逆操作
3、重复1,2,直到事务的开始标志
2.4.6 数据库的并发控制
主要技术是封锁,基本封锁类型有:排他锁(写锁)、共享锁(读锁)
排他锁:若事务T对数据对象A加了写锁,则只允许T读写
共享锁:若事务T对数据对象A加了读锁,则只允许T读,其他事务只能再加读锁……反正不能写
2.4.7 分布式数据库
四个透明、四个性质
2.4.8 杂题积累
- SQL函数结构


- 数据分析工具
OLAP:从 N个维度分析 数据
OLTP(事务角度):接受和快速处理数据
TEL:描述数据从来源到目的地的处理过程 - 存储过程

3 面向对象
3.1 面向对象基础
3.1.1 类
万物皆对象
面向对象=对象+分类+继承+通过消息的通信
- 对象
对象是类是实例,对象包括:数据(属性/状态/成员变量)、操作(服务/行为/方法/函数/成员函数)。对象通常由 对象名、属性、方法 3个部分组成,是封装一组属性和行为的整体。 - 消息
对象间的通信叫消息
例如:m1.ChangeLevel(2); - 类
一个类定义了大体上相似的对象,一个类包含的方法和数据描述一组对象的共同行为和属性
类是抽象,对象是具体,是类的实例
类分为三种:实体类、接口类(边界类)、控制类
实体类的对象表示现实世界中的实体
接口类(边界类)的对象是提供用户和系统交互的方法
控制类的对象用来控制活动流,充当协调者
有些类之间存在一般和特殊关系,比如汽车类、飞机类是特殊类,交通工具类是一般类
3.1.2 方法重载
概念:一个类可以有多个同名而参数类型不同的方法,重载是对类自身而言的。
方法名相同 参数个数不同
方法名相同 参数类型不同
方法名相同 参数类型顺序不同
public class Test{
public void sum(int a,int b,int c){
System.out.println(a+b+c);
}
public void sum(int a,int b){
System.out.println(a+b);
}
public void sum(int a,double b){
System.out.println(a+b);
}
public void sum(double b,int a){
System.out.println(a+b);
}
}
3.1.3 封装(三大特征)
封装是一种信息隐蔽技术,把属性和行为封装在对象里面。
一般会提供一个公共接口给用户,里面是怎么实现的用户不需要关心。
目的是使使用者和生产者分离,对程序员-对象是程序模块,对用户-对象能提供想要的行为。
1、封装,比如属性用private,这样对象实例就无法直接获取和修改属性,需要get、set方法。
2、在set时,局部变量和方法变量重名,用this解决冲突
3.1.4 继承(三大特征)
继承是父类(超类/基类)和子类之间共享数据和方法的机制,是类之间的一种关系。子类可以继承父类全部的内容,并加入新的内容。
子类继承父类后,父类有的属性和方法,子类就不用再定义了。
如:public Student extends Person{}
1、子类只继承一个父类,叫“单重继承”,否则叫“多重继承”。
2、父类中定义了私有变量和方法,子类就访问不了,但是私有变量可以通过get、set函数访问。
3、子类可以 重写/覆盖/置换 父类的方法。
3.1.5 多态(三大特征)
不同对象收到同一消息可产生不同结果,成为多态。
1、多态的写法:父类名 对象名 = new 子类名;
底层原理是:编译看左,执行看右。
编译看左:静态绑定
执行看右:动态绑定——与类的继承及多态相联系
比如Person中只定义了work,Student中定义了work、sleep。
在编程时,写stu.work()能编译且运行子类中的work,写stu.sleep()时无法编译,会报错,因为父类中没有。
2、但是为什么要这么做?直接子类名 对象名 = new 子类名; 就好了啊?
答:实际上,多态是将面向对象编程 转变为 面向父类编程的实现。
问:但为什么要面向父类编程?
答:面向父类编程——>先设计父类,再实现子类——>先设计,再实现,理念更加先进,代码复用性更强。
问:思想再牛逼,团队里,new对象的时候还是有人不规范咋整?
答:父类写法从 Public class Person{} ——> Public abstract Person{} ,即抽象类,只要继承该父类,实例化就得按规范写。
正因此,原本父类还需要定义和实现 属性、方法,现在只需要定义 属性名、方法名就行,剩下的让子类做。
抽象类特点:1、遵循单继承(子类不能多继承);2、子类必须实现所有抽象方法;3、可以跟正常类一样定义属性和方法;
问:那我向多继承咋整?
答:父类写法 Public abstract Person{} ——> Public interface Person{},子类写法 public class a implements Person{}
接口类特点:1、能多继承;2、接口不能有构造函数;3、默认仅包含常量和抽象方法;
3、积累

3.1.6 面向对象设计原则(背)
五大原则:
1、单一责任原则:对一个类而言,应该只有一个引起它变化的原因。
2、开放-封闭原则:软件实体对扩展开放,对修改关闭
3、里氏替换原则:基类出现的地方,子类一定可以出现
4、依赖倒置原则:依赖于抽象(高层),不依赖于细节(实现/低层)
5、接口分离原则:依赖于抽象,不依赖于具体
其他原则:
6、共同封闭原则:一个变化对一个包产生影响,则将对该包中的所有类产生影响
7、共同重用原则:重用了包的一个类,包的所有类都要重用
了解原则:
1、重用发布等价原则:重用的粒度=发布的粒度
2、无环依赖原则:依赖关系图中不允许存在环
3、稳定依赖原则:要稳
4、稳定抽象原则:抽象和稳定程度一样
3.1.7 面向对象分析–设计–程序设计–测试(背)
- 分析的作用是:分析系统要做什么,侧重于理解问题
包含5个活动:认定对象(确定问题域和责任)、组织对象、描述对象间的相互作用、确定对象的操作、定义对象的内部信息 - 设计的作用是:构造蓝图;测重于理解解决方案
包含5个活动:识别类及对象、定义属性、定义服务(行为/操作)、识别关系、识别包 - 程序设计
关键在于加入类和继承性,进一步提高抽象程度 - 测试的层次:算法层、类层、模板层、系统层
题目积累:





3.2 UML
9关系+9图
UML(统一建模语言),能够表达软件设计的动态和静态信息,UML词汇表包含3种构造块:事物、关系、图
事物:对模型中最具代表性的成分的抽象
关系:把事物结合在一起
图:聚集了相关事物
3.2.1 事物
UML有4种事物:结构事物、行为事物、分组事物、注释事物
- 结构事物

- 行为事物

- 分组事物

- 注释事物

3.2.2 关系(类图)
UML4种关系:依赖、关联、泛化、实现
-
依赖

-
关联


1、单向关联:鱼——>水、人——>氧气
依赖:人------>面包
单项关联和依赖的 区别:关联的程度强,依赖有临时性和偶然性
2、关联名是线上的名字,比如 人和氧气的关联名是呼吸
3、关联类:(一般多对多时才创建)

3、聚集分为:聚合(聚是一团火,散是满天星)、组合(同生共死)

-
泛化

-
实现

题目积累:
3.2.3 UML中的图
顶点代表事物,弧代表关系的连通图
一般看9种图:类图、对象图、用例图、序列图、通信图、状态图、活动图、构件图、部署图
- 类图
最常见的就是类图,类图用于对系统的静态设计视图建模,当在建模时,通常使用3种方式:对系统的词汇建模、对简单的协作建模、对逻辑数据库模式建模
类图中通常包括:类、接口、协作、依赖泛化和关联


- 对象图

- 用例图

参与者:可以是人、硬件或其他系统等外部实体
用例:将系统的功能描述成一系列事件,是一个类而不是具体实例
用例图的使用方式包括:对系统的语境建模、对系统的需求建模
关联是参与者和用例之间的关系
包含是用例和用例之间的关系
扩展是用例和用例之间的关系
泛化是参与者和参与者之间的关系,也是用例和用例之间的关系-
包含关系

-
扩展关系

-
泛化关系

-
- 序列图(顺序图):强调时间顺序,描述以时间顺序组织的对象间的活动



- 通信图(协作图)
重点在于描述对象间发送消息的顺序,箭头指向被调用方法的对象
- 状态图
由状态、转换、事件和活动组成,强调事件顺序,是对反应型对象建模,可对任何视图的任何一种对象的建模- 状态+活动
状态可以是 做动作、改变状态、改变状态+做动作
状态转换图 定义的状态主要有:初态(黑圆点,只能有一个)、终态(牛眼睛,0个或多个)、中间态
状态图分为上中下3部分,上面是状态名称,中间是状态变量的名称的值,下面是活动表(活动,由若干动作组合)
- 转换+事件
转换就是一条带箭头的线,转换的别名是迁移
- 组合状态和嵌套状态

- 题目积累


- 状态+活动
- 活动图
动态建模,对工作流和操作建模,展现了活动到活动的流程
- 构件图(组件图)
展现构件之间的组织和依赖,与类图相关,把构件映射为 类、接口或协作
重要特征:1、矩形框内有个哑铃符号;2、存在半圆和园
由供接口对应的构件实现功能
- 部署图
部署图对物理方面建模,展现了系统的软件和硬件之间的关系,在实施阶段使用。
题目积累:


4 操作系统

4.1 操作系统地位

4.2 进程管理
4.2.1 程序顺序执行(前趋图)
程序顺序执行时的特点:顺序性、封闭性、可再现性
前趋图:是一个有向无环图,Pi和Pj代表前趋和后继。
这里主要考的知识点:前趋图、进程的PV操作、信号量S
- 信号量该怎么填?

- 箭头起点V操作,箭头终点P操作
对应的是,P1结束后V(S1),P2开始前P(S1)
S相当于释放和通知,P相当于检查和开始
4.2.1.1 前趋图考试形式
就是给你图,告诉你有几个进程,让你填空(P操作或V操作)。
-
在图形上填空

-
在代码中填空

4.2.2 程序并发执行(前驱图)

并发执行特征:
1)失去了程序的封闭性
2)程序和机器的执行程序的活动不再一一对应
3)并发程序间的相互制约性
并发执行存在的问题:程序并发执行破坏了程序的封闭性和可再现性
4.2.2.1 前驱图考试形式

4.2.3 进程三态模型
- 三态
运行:进程在运行
就绪:除了CPU,其他已就绪
阻塞:运行中的进程暂停运行
进程 CPU 资源
运行√ √
就绪× √
阻塞× ×
- 五态

4.2.4 同步与互斥
并发执行必然存在 资源共享(互斥)和互相合作(同步)的问题
同步是合作进程间的直接制约问题,互斥是申请临界资源进程间的间接制约问题
临界资源:一次只能供一个进程使用的资源
临界区:进程中对临界资源实时操作的那段程序
临界区管理原则:
- 有空则进:有空位就进,但是只能运行有限时间
- 无空则等
- 有限等待:确保有限时间能进,避免进入饥饿状态
- 让权等待:等待时释放CPU,避免忙等
4.2.5 信号量机制和PV操作
4.2.5.1 信号量
信号量:整型信号量、记录型信号量、信号量集机制
共用信号量用于实现互斥,初值为1或资源的数目
私用信号量用于实现同步,初值为0或某个正整数
信号量S的意义:S≥0表示某资源的可用数;S<0表示阻塞队列中等待的进程数。
考点1:信号量为负数时,有几个进程在等待
考点2:n个进程共享2台打印机,S的取值范围为 -(n-2)~2
4.2.5.2 PV操作
PV操作是低级通信原语,执行期间缺一不可
PV操作能够实现资源/进程的互斥、同步使用
互斥和同步的特征:互斥是一段代码中,PV使用的信号量是同一个;同步是一段代码中,PV使用的是信号量不一样。
- PV实现进程互斥
引入信号量mutex,初值为1
- PV实现进程同步(单缓冲区生产者消费者)
S1对应生产者:表示缓冲区容量
S2对应消费者:表示缓冲区产品数量
- PV实现进程同步(N缓冲区生产者消费者)
N缓冲区实现进程同步,需要在同步信号量PV的内部 加入 互斥信号量PV
否则会出现 生产者中2+1=3 ——> 消费者中2-1=1 ——> S2=1
4.2.6 死锁
同类资源分配不当引起死锁:m个资源被n个进程共享,每个进程要k个资源,当m<nk时可能会死锁。
满足多少资源的情况下就不会死锁?(针对轮流分配资源)

4.2.6.1 进程资源图
喜欢考:这个进程是不是堵塞的?是不是可化简的?化简顺序是什么?
可化简:非死锁的就是可化简的
- 可化简的例子:

- 不可化简的例子:

- 题目示例

4.2.6.2 死锁避免
死锁处理策略:鸵鸟策略(不理睬)、预防策略、检测与解除、避免策略(银行家算法)
4.2.7 线程
传统的进程有两个基本属性:可拥有资源的独立单位、可独立调度和分配的基本单位
但是进程在创建、撤销和切换时开销过大,所以要用线程
引入线程后:可拥有资源的独立单位(进程)、可独立调度和分配的基本单位(线程)
同属于一个进程的所有线程共享进程的所有资源,但是线程间不共享资源
4.3 内存管理
4.3.1 局部性原理
时间局限性:程序中的指令可能再次被执行(循环引发)
空间局限性:程序访问了某个存储单元,其附近的单元可能也被访问(程序顺序执行引发)
考点:页号的淘汰
4.3.2 分页存储管理
- 纯分页存储管理
地址结构:页号(12-15 4位)+页内地址(0-11 12位)=共16位
注意:1、物理页大小=页面大小
2、题目说物理块号=页帧号
3、注意看题目是 十六进制 还是 十进制
- 段页式存储管理

4.3.3 缓冲区
- 单缓冲区【公式:x=(T+M)*n+C,前提:C<T】
缓冲区非空时不能输入,缓冲区为空时不能传送
- 双缓冲区【公式:x=T*n+M+C,前提:M+C<T】

4.3.4 磁盘(移臂)调度算法
-
先来先服务(FCFS)
按先后顺序访问
-
最短寻道时间(SSTF)
谁最近访问谁
-
扫描算法(SCAN)或 电梯调度算法
一路向西,再向东
-
循环扫描算法(CSCAN)或 单向扫描算法

-
题目积累
1、柱面一样看扇区,扇区一样看磁头

4.3.5 旋转调度算法


4.3.6 多级索引结构
下图注意:应该是先一级再二级,须纠正



4.3.7 文件目录
文件控制块FCB:包含基本信息类、存取控制信息类、使用信息类
(1)基本信息类:文件名、文件物理地址、长度等
(2)存取……:RWX权限
(3)使用……:建立、修改日期等
文件控制块的有序集合称为 文件目录
4.3.7.1 目录结构
目录机构:一级、二级、多级目录目录结构
4.3.8 位示图


4.4 杂题积累











5 结构化开发(考概念)
抽象、模块化(将整体分为若干个小部分)、信息隐蔽(封装)、模块独立(耦合、内聚)
5.1 耦合
耦合是模块间相对独立性的度量。取决于各个模块之间接口的复杂程度、调用模块方式、接口信息类型
7个耦合及概念都要背,背关键部分即可


5.2 内聚
内聚程度高的模块应当只做一件事
5.3 设计原则

5.4 系统文档
注意:项目开发计划=系统开发合同+系统方案说明书
5.5 数据流图相关(下午题一知识点)



5.5.1 数据字典
数据字典主要给数据流、文件、加工等数据项做出说明。
- 数据字典内容
4类条目:数据流、数据项、数据存储、基本加工 - 数据词典管理
- 加工逻辑的描述
加工逻辑称为“小说明”,加工逻辑(规格)方法有 结构化语言、判定表、判定树
1)结构化语言(伪代码)
1、外层:顺序、选择、重复 结构
2、内层:自然语言短语描述
2)判定表(决策表)
3)判定树(决策树)












6 软件工程
6.1 软件过程
6.1.1 CMM 能力成熟度模型
CMM将软件过程分为以下5个成熟度级别:
初始级:杂乱无章,全靠个人完成
可重复级:有基本的项目管理过程来重复
已定义级:文档化、标准化,标准软件过程
已管理级:软件过程和质量被管理层理解和控制
优化级:定量分析,通过各种新观念、新技术的反馈不断改进
6.1.2 CMMI 能力成熟度模型集成
- 阶段式模型
该阶段关注成熟度,同样有5个等级
1-初始:过程不可预测且缺乏控制
2-已管理:过程为项目服务
3-已定义:过程为组织服务
4-定量管理:过程已度量和控制
5-优化:集中于过程改进 - 连续式模型
该阶段关注能力,共6个
CL0(未完成):未执行、未得到 所有目标
CL1(已执行):将输入转换为输出
CL2(已管理):集中于已管理的过程的制度化
CL3(已定义级):集中于已定义的过程的制度化
CL4(定量管理):集中于可定量管理的过程的制度化
CL5(优化):使用量化手段改变和优化过程域
6.2 软件过程模型
6.2.1 瀑布模型
需求分析-设计-编码-测试-运行与维护,按固定次序进行
每个阶段都要进行评审和文档控制,所以适合开发小组对项目领域熟悉、需求很明确的软件项目,如果中途需求一变就很麻烦
优点:容易理解,管理成本低;强调开发的早期计划及需求调查和产品测试
缺点:客户必须表达完整需求;且项目结束前都不能演示系统;导致需求设计错误只有到后期才发现
6.2.1.1 V模型
是瀑布模型的变体,它先根据需求和设计进行编码,编码之后再进行一系列的测试(质量保证活动),描述了 质量保证活动和沟通、建模相关活动之间的关系。
6.2.1.2 增量模型
增量模型是瀑布模型的迭代版,说白了就是从第一个增量产品(核心)开始,每次都让客户使用和评估,然后出2.0、3.0版本……
它拥有瀑布模型所有优点,第一个版本需要时间很少,变更风险不大。
缺点是如果第一个增量没规划好,后续可能不稳定;如果早期思考不周全,增量可能还要重新开发;管理成本和配置复杂性可能超出组织能力。
6.2.2 演化模型
演化模型是迭代的过程模型,让开发者能够逐步开发出更完整的软件版本,演化模型特别适合对软件需求缺乏准确认识的情况。
它与增量模型的区别:增量是把用户的需求,分成一段段来做;它是逐步收集需求
演化模型提供的版本是为了一步步确认详细的需求,它并不能运行更不能用于测试;但是增量模型是可以运行的,也就可以用于测试
6.2.2.1 原型模型(快速原型模型)
适合 系统规模不大、用户需求不清、需求经常变化的情况
首先和用户进行沟通,提供系统框架,来确定初步的用户需求,用初步的需求快速开发初始原型,以后再在这个原型上不断进行迭代
6.2.2.2 螺旋模型
结合了瀑布模型和演化模型,适合大规模项目,有风险分析功能
支持需求动态变化,为用户决策提供方便,提高软件适应能力,降低软件开发风险。需要开发者有丰富的风险评估知识,迭代次数过多会增加开发成本延迟提交时间。
6.2.3 喷泉模型
以用户需求为动力,以对象作为驱动的模型,适合面向对象的开发方法。
在开发过程中具有迭代性和无间隙性。
意思就是开发活动可能要重复多次,在迭代中不断完善,并且开发活动不存在明显边界,比如分析、设计、实现是可以交叉进行的。
优点:能提高项目开发效率,节省开发时间
缺点:由于各个开发阶段重叠,需要大量人员,不利于管理,文档审核难度大
6.2.4 统一过程(UP)模型
它是一种“用例和风险驱动,以架构为中心,迭代并且增量”的开发过程,由UML支持。
将开发项目分为小的“袖珍”,每次迭代由5个核心工作流(需求、分析、设计、实现、测试),以及4个阶段与里程碑:
初始阶段:生命周期目标
精化阶段:生命周期架构
构建阶段:初始运作功能
移交阶段:产品发布
RUP是典型代表,它是UP的商业扩展,比UP更完整详细

6.2.5 敏捷方法
-
极限编程 XP
4大价值观:沟通、简单性、反馈、勇气
5个原则:快速反馈、简单性假设、逐步修改、提倡更改、优质工作
12个最佳实践:计划游戏、小型发布、隐喻、简单设计、测试先行、重构、结对编程、集体代码所有制、持续集成、每周40小时、现场客户、编码标准 -
水晶法 Crystal
每个项目都i需要一套不同的策略、约定和方法论 -
并列争求法 Scrum
把每30天一次迭代称为一个“冲刺”
-
自适应软件开发 ASD
6个基本原则
使命、特征、等待、变化-调整、交付时间-关键需求、风险 -
敏捷统一过程 AUP
“在大型上连续,在小型上迭代”,采用UP阶段性活动
迭代包括:建模、实现、测试、部署、配置及项目管理、环境管理
6.3 需求分析
功能需求、性能需求、用户或人的因素、环境需求、界面需求、文档需求、数据需求、资源使用需求、安全保密要求、可靠性要求、软件成本消耗与开发进度需求、其他非功能性要求
6.4 系统设计
6.4.1 概要设计
- 设计软件系统总体结构(关键)
把复杂系统划分模块,确定模块功能、关系、接口、传递的信息 - 数据结构及数据库设计
- 编写概要设计文档
概要设计说明书、数据库设计说明书、用户手册、修订测试计划 - 评审
6.4.2 详细设计
对每个模块进行详细的算法设计
数据结构及数据库设计
其他设计(代码设计)
编写详细设计说明书
评审
6.5 系统测试
意义:为了发现尚未发现的错误
目的:以很少的人力时间发现错误,以便解决问题
信息系统测试更多是软件测试
系统测试是保证 系统质量和可靠性的关键步骤
测试应遵循以下原则:
- 尽早不断测试
- 测试应避免由开发者承担
- 输入和输出都要对
- 异常情况也要测
- 程序是否做了不该做的
- 严格按计划进行
- 保存测试计划和用例,写入软件文档
- 测试例子是精心设计的,可复用。系统改代码后,也要重测
- 测试阶段的目标来源于 需求分析阶段【需求阶段就写好测试例子】
6.5.1 传统软件的测试策略
有效的软件测试分为4步进行
- 单元测试
也称为模块测试,一般用白盒测试法
1)测试内容
1、模块接口(数据输入输出、全局变量)
2、局部数据结构(变量的正确性)
3、重要的执行路径
4、出错处理
5、边界条件
2)单元测试过程
模块测试时的两种模块
1、驱动模块:主程序,接受测试用例,传输到测试模块,输出测试结果
2、桩模块:代替测试模块调用的子模块,进行少量数据处理,检验入口并输出信息 - 集成测试
1、自顶向下
不用编写驱动模块,要编写桩模块
2、自底向上
不用写桩模块,要写驱动模块
说白了就是底层的功能合并为N个驱动模块测试,测试完后再合并……
3、回归
软件变更后要重新测试,防止错误
4、冒烟
让团队频繁对项目进行评估 - 确认测试
- 系统测试
6.5.2 测试方法
分为静态测试和动态测试
- 静态测试:人工检测、计算机辅助静态分析
- 动态测试
通过运行程序发现错误,采用黑盒测试和白盒测试
测试用例由 输入数据和预期结果组成
1)黑盒测试(功能测试)—— 看不见/不看代码
黑盒技术分为:等价类划分、边界值分析、错误推测、因果图
1、等价类划分:说白了就是不同的判断语句,判断结果是否为有效或无效
如成绩 score>0 && score<=60 为有效等价类
成绩 score<0 为无效等价类
2、边界值分析:说白了就是 输入边界值给上面的等价类划分判断是否有效
如成绩 score=0、60、-1、 61
3、错误推测:直接凭经验和直觉推测可能存在哪些错误,然后设计测试用例
4、因果图:把程序规格说明的输入输出转换为判定表
2)白盒测试(结构测试)
考试形式:1、白盒测试问几个测试用例能覆盖;2、白盒+Mccabe;3、伪代码+白盒+Mccabe
6.5.2.1 McCabe度量法



6.5.2.2 白盒测试
称为结构测试,也是逻辑测试
常用技术是:逻辑覆盖、循环覆盖、基本路径测试
- 逻辑覆盖







- 循环覆盖
执行足够的测试用例,让循环的每个条件都得到验证 - 基本路径测试
分析控制流图环路复杂性,导出基本路径集合,设计测试用例
技巧:1、了解算法,比如一个图用了折半查找,就算它判断再多,我们知道要么成功要么失败,所以2个用例就够了。
2、循环结构,一般一个用例就能遍历两个条件。
3、如果题目写 至少需要测试用例①②③才能完成XX覆盖。
选项中,只要覆盖都满足,选最强的那个。

6.6 运行和维护
6.6.1 系统维护
软件维护不属于开发过程,且时间最长
系统可维护性评价指标:可理解性、可测试性、可修改性
维护与软件文档:文档是软件可维护性的决定因素,根据用户文档运行,根据系统文档维护。在开发阶段就要有可维护性,每个阶段都要提高可维护性。
- 硬件维护
- 软件维护
软件维护就是根据需求修改程序,修改后填写登记表,标明新旧程序不同之处。
正确性维护:为了防止错误;开发出错,测试未果,运行报错;维护工作量占比17%~21%
适应性维护:为了适应技术变化而进行修改,占比18%~25%
完善性维护:为扩充功能和改善性能进行修改,占比50%~60%
预防性维护:为了不被淘汰增加一些功能,占比4%
适应被动,完善主动 - 数据维护
6.6.2 软件文档
1、编写高质量文档可以提高软件开发的质量
2、文档也是软件产品的一部分,没有文档的软件就不能称之为软件
3、软件文档的编制在软件开发工作中占有突出的地位和相当大的工作量
4、高质量文档对于软件产品的效益有着重要的意义
总的来说,软件文档只好不坏,选项中说软件文档不好的就是不正确的
6.6.3 软件质量属性

故障=可靠性、失效=可用性、修复=可维护性
p156
6.6.4 沟通路径
含N个人的小组,沟通路径最多几条?
- 情况1:无主程序员,所有成员沟通平等
首先,a与b有一条路径,则a有一条,b就算0条。
则,第一个人有N-1条,第二个人有N-2条……倒数第二个有1条,最后一个0条。
按照等差数列:(N-1+0)*N/2 - 情况2:有主程序员
主程序员负责成员间的沟通,成员间无直接联系,所以沟通路径是N-1
6.7 软件项目估算
6.7.1 COCOMO估算模型
- 基本COCOMO模型:是一个静态单变量模型,用于对整个软件系统进行估算。
- 中级COCOMO模型:是一个静态多变量模型,它将软件系统模型分为系统和部件两个层次,系统由部件构成。
- 详细COCOMO模型:它将软件系统模型分为系统、子系统、模块3个层次。
6.7.2 COCOMOII估算模型
分为3个阶段性模型:应用组装模型(对象点)、早期设计阶段模型(功能点)、体系结构阶段模型(代码行)
6.7.3 进度管理
6.7.3.1 甘特图
跟甘蔗一样的图,同一时间段存在多个水平条就代表并行。
Gantt图能清晰地描述每个任务从何时开始,到何时结束,任务的进展情况以及各个任务之间的并行性。但是它不能清晰地反映出各任务之间的依赖关系,难以确定整个项目的关键所在也不能反映计划中有潜力的部分。
6.7.3.2 PERT图
甘特图能反映任务间的并行关系,不能能反映任务间的依赖。
PERT能反映任务间的依赖,不能反映任务间的并行关系。
考点:1、优缺点;2、关键路径;3、松弛时间;4、关键路径长度(结束节点的最小时刻)
6.7.3.3 项目活动图
跟PERT图基本一样,题目解法也一样。
考点:1、关键路径;2、关键路径长度(结束节点的最小时刻);3、某个顶点(活动)是否在关键路径上;4、松弛时间(可以晚几天开始)
6.7.4 软件配置管理(背)

6.7.4.1 风险管理
软件风险2个特性:不确定性和损失
1、项目风险:预算、进度、人员、资源、需求、项目复杂度、规模、结构……
2、技术风险
3、商业风险:市场、策略、销售、管理、预算
- 风险识别:系统化的指出威胁,识别出已知和可预测风险,以便回避和控制风险。
已知和可预测风险:产品规模、商业影响、客户特性、过程定义、开发环境/技术/经验
风险因素:行呢个、成本、支持、进度 - 风险预测:概率+后果
预测活动:1、建立尺度、描述后果、估算影响、标注精确度
技术:建立风险表
影响风险后果的3个因素:风险本质、范围、时间
风险显露度 RE=P(概率)*C(后果) - 风险评估:一种很有用的技术是 定义风险参照水准,水准包括(成本、进度、性能)
- 风险控制
1、风险避免:最好是主动避免
2、风险监控:关注潜在问题
3、RMMM计划:把风险管理工作文档化并由管理者使用
6.8 软件质量(背)
6.8.1 软件质量特性


6.8.2 Mc Call软件质量模型

6.8.3 软件评审
分为设计质量评审、程序质量评审
设计质量评审内容:规格、可靠性、保密、操作特性、实现情况、可修改性、可扩充性、可互换性、可移植性、可测试性、复用性
程序质量评审内容:软件结构、运行接口、变更影响
1、软件结构:功能结构(数据结构、功能结构、模块结构与功能结构之间的对应关系)、功能通用性、模块层次、模块结构(控制流结构、数据流结构、模块结构与功能结构之间的对应关系)、处理过程结构
2、运行接口:与硬件的接口、与用户的接口
技术评审:一旦形成规格说明和设计就要进行质量评估。完成质量评估的中心活动是技术评审,目的是揭露质量问题。
6.8.4 软件容错技术
容错软件4个种类:有屏蔽自身错误能力的、能恢复正常状态的、发生错误还完成任务的、有容错能力的
容错主要手段:冗余
冗余技术:
1、结构冗余:静态冗余、动态冗余、混合冗余
2、信息冗余:为检测和纠正信息,在错误上外加一部分信息
3、时间冗余:以重复执行指令来消除错误影响
4、冗余附加技术:
在屏蔽硬件错误的容错技术中,冗余附加技术包括:关键程序和数据的冗余存储和调用、检测、表决、切换、重构、纠错和复算
在屏蔽软件错误的容错系统中,包括:冗余备份程序的存储和调用、实现错误检测和恢复的程序、实现容错软件所需固化程序
6.9 软件工具
- 软件开发工具
需求分析工具、设计工具、编码排错工具、测试工具 - 软件维护工具
版本控制工具、文档分析工具、开发信息库工具、逆向工程工具、再工程工具
6.10 杂题














7 信息安全
7.1 防火墙
外部网络和内部网络中设置一个DMZ(隔离区),比如放FTP、E-mail、Web等服务器
防火墙处理技术包括:控制、审计、报警、反应等
防火墙技术经历了:包过滤、应用代理网关和状态检测技术三个阶段
- 包过滤防火墙:根据数据包头中的信息来控制访问,处在网络层和数据链路层(TCP和IP)之间,对用户完全透明,速度较快;主要检查包中的源地址、目的地址、协议、端口等;
缺点:不能防范黑客攻击,网关技术力差;不持支应用层协议; - 应用代理网关防火墙:彻底隔离内网与外网的通信,内网通过防火墙转发给外网,通过代理软件转发;
优点:可检查应用层、传输层、网络层协议特征
缺点:难以配置,速度非常慢 - 状态检测技术防火墙:结合代理防火墙的安全性和包过滤防火墙的速度。
7.2 病毒

7.3 网络攻击


7.4 网络安全











8 计网
8.1 网络设备
物理层的互联设备:中继器(Repeater)、集线器(Hub)
集线器可看成是 多路/多端口中继器
集线器不会对信号做任何处理,可以检测发送冲突
数据链路层的互联设备:网桥和交换机
交换机是 多端口的网桥
网络层设备:路由器
应用层设备:网关

8.2 协议簇
考点:
1、某协议对应ISO/OSI或TCP/IP那一层?
2、某协议属于TCP还是UDP?
3、哪个协议不属于TCP/UDP?


技巧:
1、除了TFTP,所有带T的协议都属于TCP
积累:
1、ICMP利用IP传送报文,将数据封装在IP数据报中传送
2、SNMP的报文封装在UDP中传送
3、TCP/UDP基于IP协议
8.2.1 IP、TCP、UDP
IP提供的服务通常是无连接、不可靠的
无连接:对方没准备好就发送
不可靠:发了但是不确认成功
TCP:可靠传输、连接管理、差错检测和重发、流量控制、拥塞控制、端口寻址
流量控制采用的是:可变大小的滑动窗口协议
UDP:不可靠、无连接、可保证应用程序间的通信、开销较小
TCP 首部-20Byte
UDP 首部-8Byte
TCP和UDP均提供了端口寻址的功能

8.2.2 SMTP和POP3
Email系统基于C/S模式
SMTP:发送邮件 基于TCP,端口25 ASCII->MIME
POP3:接受邮件 基于TCP,端口110
MIME:邮件附件扩展类型
PEM:私密邮件
SMTP只能传输ASCII码文本和文字附件
8.2.3 ARP和RARP
ARP地址解析协议,RARP反地址解析协议
ARP将IP转为物理地址,RARP将物理地址转为IP
当计算机需要和其他计算机通信时:
1、查询ARP缓存中是否存在目标ip
2、若缓存中没有,则以广播方式发送ARP请求,当局域网上某计算机ip配对,则以单播方式返回ARP应答信息,信息中包含物理地址
3、ARP协议将 IP及物理地址 添加到缓存中
8.2.4 DHCP

8.2.5 RUL

8.2.6 浏览器



8.3 IP地址和子网掩码
-
IP地址
每个主机必须用IP地址标识,IP地址都由4个小于256的数字组成,共4个字节,32位。
-
子网掩码





8.3.1 IPv4、IPv6

8.3.2 无线网络
蓝牙 覆盖范围最小,通信距离最短
ZigBee(紫蜂) 70m
8.4 Windows命令


8.5 路由




8.6 HTML



8.7 Linux
…………
8.8 杂题




















AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念,把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起,为开发者提供从开发、训练到部署的一站式体验。
更多推荐



所有评论(0)