软考-笔记
面向对象设计原则(部分)
- 共同重用原则：一个包中里的所有类应该是共同重用的，如果重用了包里的一个类，那么就要重用包中的所有类。
- 共同封闭原则： 如果一个变化对一个包产生影响，则将对该包里的所有类产生影响，而对其它包不产生任何影响。
- 开放-封闭原则：对扩展开放，对修改关闭。
- 接口分离原则： 接口的功能尽可能单一，降低模块的耦合性。
面向对象测试的四个层次
- 算法层 –> 单元测试
- 类层 –> 模块测试
- 模板层 –> 主题层
- 系统层 –> 把各个子系统组装成完整的面向对象软件系统，在组装过程进行测试
设计模式
面向对象类关系(继承、实现、依赖、关联、聚合、组合)：https://www.cnblogs.com/zhongj/p/11169780.html
UML: https://blog.csdn.net/quyingzhe0217/article/details/133683814
创建型模式
创建型设计模式包括以下几种常见的模式：
工厂模式（Factory Pattern）：通过工厂方法或抽象工厂来创建对象，将对象的创建过程封装起来，使得客户端代码与具体类解耦。
抽象工厂模式（Abstract Factory Pattern）：提供一个接口，用于创建相关或依赖对象的家族，而不需要指定具体类。
单例模式（Singleton Pattern）：确保一个类只有一个实例，并提供一个全局访问点来访问该实例。
建造者模式（Builder Pattern）：将一个复杂对象的构建过程与其表示分离，使得同样的构建过程可以创建不同的表示。
原型模式（Prototype Pattern）：通过复制现有对象来创建新对象，而不是通过实例化来创建。
结构型模式
结构型设计模式主要包括以下几种常见的模式： 适配器模式（Adapter Pattern）：将一个类的接口转换成客户端所期望的另一个接口，使得原本不兼容的类可以一起工作。
桥接模式（Bridge Pattern）：将抽象部分与实现部分分离，使它们可以独立地变化，从而提高系统的灵活性。
组合模式（Composite Pattern）：将对象组合成树形结构，以表示“部分-整体”的层次结构，使得客户端可以统一地处理单个对象和组合对象。
装饰器模式（Decorator Pattern）：动态地给对象添加额外的职责，同时又不改变其接口。
外观模式（Facade Pattern）：提供一个统一的接口，用于访问子系统中的一组接口，从而简化客户端与子系统之间的交互。
享元模式（Flyweight Pattern）：通过共享细粒度的对象，以减少内存使用和提高性能。
代理模式（Proxy Pattern）：为其他对象提供一个代理，以控制对这个对象的访问。
行为模式
行为型设计模式主要包括以下几种常见的模式：
观察者模式（Observer Pattern）：定义了一种一对多的依赖关系，使得多个观察者对象可以同时监听并收到被观察者对象的通知。
策略模式（Strategy Pattern）：定义了一系列算法，并将每个算法封装起来，使它们可以相互替换，从而使算法的变化独立于使用算法的客户端。
命令模式（Command Pattern）：将请求封装成对象，以使得可以用不同的请求对客户端进行参数化，同时支持请求的排队、记录和撤销。
迭代器模式（Iterator Pattern）：提供一种顺序访问聚合对象中各个元素的方法，而又不暴露该对象的内部表示。
状态模式（State Pattern）：允许对象在内部状态发生改变时改变其行为，使对象看起来像是修改了其类。
责任链模式（Chain of Responsibility Pattern）：将请求的发送者和接收者解耦，使多个对象都有机会处理请求，从而避免请求的发送者与接收者之间的耦合关系。
访问者模式（Visitor Pattern）：在不改变被访问类的前提下，定义了一种新的访问操作，使得可以在不修改被访问类的情况下对其进行操作。
中介者模式（Mediator Pattern）：定义了一个中介对象，封装了一组对象之间的交互方式，使其能够独立地改变交互方式。
备忘录模式（Memento Pattern）：在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态，从而可以在以后恢复到这个状态。
解释器模式（Interpreter Pattern）：给定一个语言，定义它的文法的一种表示，并定义一个解释器，用于解释语言中的句子。
二分查找关键字序列判断
- 第一个关键字一定是序列的中间元素
- 第一个关键字以后的数字要么都大于第一个关键字，要么都小于第一个关键字
- 第二个关键字以后的关键字，要么都位于第一个关键字和第二个关键字之间，要么都在第二个关键字之外
- 第三个关键字以后的关键字，要么都位于第二个关键字和第三个关键字之间，要么都在第三个关键字之外
计组
DRAM使用电容存储信息，而且需要周期性地进行刷新。
编译原理
对高级语言源程序进行编译或者解释过程中需要进行语法分析，递归子程序分析属于自上而下的分析法
模块设计
高内聚低耦合是模块设计的基本原则。 模块之间的耦合性由低到高依次为:
-
非直接耦合：两个模块之间没有直接关系，它们之间的联系完全是通过主模块的控制和调用来实现的。耦合度最弱，模块独立性最强。
-
数据耦合：调用模块和被调用模块之间只传递简单的数据项参数。相当于高级语言中的值传递。
-
标记耦合：调用模块和被调用模块之间传递数据结构而不是简单数据，同时也称作特征耦合。
-
控制耦合：模块之间传递的不是数据信息，而是控制信息例如标志、开关量等，一个模块控制了另一个模块的功能。从控制耦合开始，模块的数据就放在自己内部了，不同模块之间通过接口互相调用。
-
外部耦合：一组模块都访问同一全局简单变量，而且不通过参数表传递该全局变量的信息，则称之为外部耦合。外部耦合和公共耦合很像，区别就是一个是简单变量，一个是复杂数据结构。
-
公共耦合： 多个模块都访问同一个公共数据环境，公共的数据环境可以是全局数据结构、共享的通信区，内存的公共覆盖区等
-
内容耦合：内容耦合是最紧的耦合程度，一个模块直接访问另一模块的内容，则称这两个模块为内容耦合。
1）功能内聚（Functional Cohesion）
如果一个模块内所有处理元素完成一个，而且仅完成一个功能，则称为功能内聚。
功能内聚是最高程度的内聚。但在软件结构中，并不是每个模块都能设计成一个功能内聚模块。
2）顺序内聚（Sequential Cohesion）
如果一个模块内处理元素和同一个功能密切相关，而且这些处理元素必须顺序执行，则称为顺序内聚。
3）通信内聚（Communicational Cohesion）
如果一个模块中所有处理元素都使用同一个输入数据和（或）产生同一个输出数据，称为通信内聚。
4）过程内聚（Procedural Cohesion）
如果一个模块内的处理元素是相关的，而且必须以特定的次序执行，称为过程内聚。
过程内聚与顺序内聚的区别是： 顺序内聚中是数据流从一个处理单元流到另一个处理单元，而过程内聚是控制流从一个动作流向另一个动作。
5）时间内聚（Temporal Cohesion）
如果一个模块包含的任务必须在同一段时间内执行，称为时间内聚。也称为瞬时内聚。
6）逻辑内聚（Logical Cohesion）
如果模块完成的任务在逻辑上属于相同或相似的一类，称为逻辑内聚。
7）偶然内聚（Coincidental Cohesion）
如果一个模块由完成若干毫无关系的功能处理元素偶然组合在一起的，就叫偶然内聚
数据流图
分层的数据流图是结构化分析方法的重要组成部分。
对数据流图中的每个基本加工，需要加工规格说明书。
加工规格说明书描述把输入数据流变换为输出数据流的加工规则。但是不需要描述实现加工的具体流程。
可以使用结构化语言，判定表和判定树来表达基本加工。
软件许可
独占许可： 软件著作权人不得将软件使用权授权第三方，软件著作权人不能使用该软件。 独家许可：软件著作权人不得将软件使用权授权第三方，软件著作权人可以使用该软件 普通许可：软件著作权人可以将软件使用权授权第三方，软件著作权人自己也可以使用该软件
模块控制范围
模块的控制范围包括模块本身及其所有的从属模块。模块的作用范围是指受该模块内任意一个判定影响的所有模块的集合，这其中可能由处于控制范围之外的模块。 原则上，一个模块的作用范围应该在其控制范围内，如果没有，可以采用下面的方法：
- 将判定所在模块合并父模块中，使得该判定处于较高层次
- 将受判定影响的模块下移到该模块的控制范围内
- 将判定上移到层次中较高的位置。
风险控制
风险控制的基本方法：
- 回避
- 转移
- 减轻
- 接受并控制
UML建模
事物
- 结构事物: 通常是模型中的静态部分，描述概念或者物理元素。结构事物包括类，接口，协作，用例，主动类，构件和节点
- 行为事物： 是UML中的动态部分，是模型中的动词，描述了跨越时间和空间的行为。共有两类主要的行为事物: 交互和状态机
- 分组事物： 是UML建模中的组织部分。在所有分组事物中，最主要的是包
- 注释事物：是UML中的解释部分，这些注释事物用来描述，说明和标注模型的任何元素。注解是一个注释事物。注解是一个依附于元素或者一组元素之上，对它进行约束或者解释的简单符号。
关系
依赖，关联，泛化和实现
- 依赖：两个事物之间的语义关系，其中一个事物发生变化会影响另一个事物的语义
- 关联：是一种结构关系。描述了一组链，链是对象之间的连接。聚合是一种特殊类型的关联，描述了整体和部分间的结构关系。组合也是一种特殊类型的关联，同样体现了整体与部分之间的关系，但比聚合更强，因此也被称为强聚合。
- 泛化：是一种特殊/一般关系，特殊元素(子元素)的对象可替代一般元素(父元素)的对象。用这种方法，子元素共享了父元素的结构和行为。
- 实现：是 类元之间的语义关系，其中一个类元制定了由另一个类元保证执行的契约。在两种地方要遇到实现关系：一种是在接口和实现他们的类或者构件之间，另一种是在用例和实现它们的协作之间。
视图
https://blog.csdn.net/TangZhongxin/article/details/4640248 注意用例图方向，
<<include>>是包含了，<<extend>>是扩展于
