一、面向对象需求分析的相关概念
| 对象 | 在开发时会将人、物等都抽象为对象，人、物的特性会变成对象的属性，对象还有相关的操作方法，即这个人（物）在系统内部可以做些什么；对象由标识属性和服务构成，他们被封装为一个整体以接口的形式对外提供服务 |
| 类 | 将多个对象的共性抽取出来形成类，一个类中的对象都是这个类的实列，没有实例的类是抽象类，抽象类不能被实例化，不能用new关键字。建立丰富的类库是程序设计成熟的重要标志 |
| 实体类：人、物等实体 | |
| 边界类：具有与外界交互职能的类 | |
| 操控类：类与类之间需要衔接，因此需要控制类来控制衔接 | |
| 抽象 | 抽取事务的本质特征 |
| 封装 | 例如对程序中一部分属性封装起来作为私有，如果外部想要访问这些属性需要通过固定接口 |
| 继承和泛化 | 继承：子类继承父类的全部特征 |
| 泛化：将有共性的几个类提取共性形成一个上层类 | |
| 多态 | 同样的操作去控制不同的对象，对象的表现状态不一样，例如快速移动操作，控制对象狗表现状态是跑，控制鱼表现状态是游；其中参数多态和包含多态称为通用多态，过载多态和强制多态称为特定多态 |
| 接口 | 接口是一种特殊的类，此种类只有方法的定义没有实现，相当于空条例 |
| 消息 | 对象之间进行交互的时候采用的机制，采用异步方式传输 |
| 组件 | 组件就是构件，是面向软件架构体系可以复用的模块 |
| 模式和复用 | 模式：经验累积形成的模板 |
| 复用：重复使用 |
面向对象分析与设计
面向对象分析基于用例模型包括三个活动：
建模系统功能
发现并确定业务对象
组织对象并确定关系
面向对象设计是在分析基础上设计各个对象、对象之间的关系、通信方式等
二、面向对象设计原则
注：一般考选择
| 单一职责原则 | 设计目的单一的类 | 类的目的单一即一个类解决一个问题，此情况下类与其他类的联系相对较少，即程序的耦合度低 |
| 开放-封闭原则 | 对扩展开发，对修改封闭 | 维护过程中添加新功能最好是拓展新的类实现新功能而不是修改原有的类，因为修改原有类可能会引入新的错误 |
| 李氏(Liskov) 替换原则 | 子类可以替换父类 | 不要盲目修改父类 |
| 依赖倒置原则 | 要依赖于抽象而不是具体实现； 针对接口编程，不要针对实现编程 | 如果依赖实现编程，需要改动时会有大的牵连 |
| 接口隔离原则 | 使用多个专门的接口比使用单一总接口要好 | 一个接口做一件事使问题简单化不易出错 |
| 组合重用原则 | 尽量使用组合，而不是继承关系达到重用目的 | 继承中父类变化子类需要跟着变比较麻烦 |
| 迪米特原则 (最少知识法则) | 一个对象应当对其他对象有尽可能少的了解 | 使用封装使部分属性私有不对外界展示，各模块之间了解较少使用接口进行连接 |
三、设计模式的基本概念
架构模式
软件设计中的高层决策，从全局看待问题，例如C/S结构，架构模式反映了开发软件系统过程中所作的基本设计决策
惯用法
最低层的模式，关注软件系统的设计与实现，实现时通过某种特定的程序设计语言来描述构件之间的关系，每种编程语言都有自己特定的模式，即语言的惯用法。
设计模式
主要关注软件系统的设计，从局部看待问题，与具体实现语言无关
设计模式的分类
创建型模式
用于创建对象的模式，为设计类实例化的新对象提供指南。
| 创建型模式名称 | 说明 |
| 抽象工厂模式 Abstract Factory | 提供一个接口类型，可以创建一系列相关或相互依赖的对象，无需指定他们具体的类（不止可以是类模式，也可以是对象模式） |
| 构建器模式 Builder | 将一个复杂类的表示与其构造相分离，使得相同的构建过程能得出不同的表示 |
| 工厂方法模式 Factory Method | 定义一个创建对象的接口，由子类决定需要实例化哪一个类，工厂方法使得子类实例化过程推迟 |
| 原型模式 Prototype | 用原型实例指定创建对象类型，拷贝原有对象生成新的对象，例如直接复制源代码改一下生成新代码比重新敲一遍源代码要快 |
| 单例模式 Singleleton | 保证一个类只有一个实例，比如浏览器中可以打开多个标签页，但是当前显示的只有一个页面 |
结构型模式
处理类或对象的组合问题，为类或对象形成更大的结构提供指导。
| 结构型模式名称 | 说明 | 关键字 |
| 适配器模式 Adapter | 将一个类的接口转换成用户希望得到的另一种接口，使原本不相容的接口可以协同工作（不止可以是类模式，也可以是对象模式） | 转换接口 |
| 桥接模式 Bridge | 将类的抽象部分和他的实现部分分离，使他们可以独立变化 | 继承树拆分 |
| 组合模式 Composite | 将对象组合成树形结构来表示整体和部分的层次结构，使用户对单个对象和和对象的使用具有一致性 | 树形目录结构 |
| 装饰模式 Decorator | 动态地给一个对象添加一些额外的职责，提供了用子类扩展功能的一个灵活的替代，比派生子类更加灵活 | 附加职责 |
| 外观模式 Facade | 定义一个高层接口，为了系统中的一组接口提供一个一致的外观，从而简化了该子系统的使用 | 对外统一接口 |
| 享元模式 Flyweight | 提供支持大量细粒度对象共享的有效方法 | |
| 代理模式 Proxy | 为其他对象提供一种代理以控制这个对象的访问 |
行为型模式
| 行为模式名称 | 说明 | 关键字 |
| 职责链模式 Chain of Responsibility | 将接收对象连接起来形成链，发送者发送消息通过链中对象依次传递，直到有对象能回复，可以减少发送者与接收者之间的耦合 | 传递职责 |
| 命令模式 Command | 将请求封装成为对象，将请求排队或记录日志支持撤销 | 日志记录，可撤销 |
| 解释器模式 Iterpreter | 给定一种语言，定义他的文法表示并定义一个解释器，该解释器用来根据文法表示来解释语言中的句子（不止可以是类模式，也可以是对象模式） | |
| 迭代器模式 Iterator | 提供一种方法来顺序访问一个聚合对象中的各个元素而不需要暴露该对象的内部表示 | |
| 中介者模式 Mediatir | 用一个中介对象来封装一些列的对象交互，它使各对象不需要显示地相互调用，从而达到低耦合们还可以独立地改变对象间地交互 | 不直接引用 |
| 备忘录模式 Memento | 不破坏封装性地前提下捕获对象内部状态，并在该对象之外进行保存，从而可以在以后将该对象恢复 | |
| 观察者模式 Observer | 定义对象之间的一对多关系，当一个对象的状态发生改变时，所有依赖于他的对象都得到通知并自动更新 | |
| 状态模式 State | 将状态做成类，类的改变可以改变当前的行为 | 状态变成类 |
| 策略模式 Strategy | 定义一系列算法，把他们各自封装，使他们之间可以相互替换，让算法可以独立于使用他的用户变化 | 多方案切换 |
| 模板方法模式 Template Method | 定义一个操作中的算法骨架，将一些步骤延迟到子类当中，使子类可以不改变一个算法的结构即可重新定义算法的某些特定步骤（不止可以是类模式，也可以是对象模式） | |
| 访问者模式 Visitor | 表示一个作用于某对象结构中的各元素的操作，使得在不改变个元素的类的前提下定义作用于这些元素的新操作 |
四、数据流图DFD
又称分成数据流图，常用于需求分析阶段。
图例
图例需要记牢，有时会将E-R图等多种图的图例混合出选择。
分层
数据流图的分层一般是分为顶层图、0层图、最底下的子图。上层图与下层图（或称之为父图与子图）需要保持平衡。数据流图的封层是从顶到下逐层进行分解，此分解思路与结构化的开发方法完全吻合，所以数据流图成为了结构化方法里面最常用的工具
顶层图
中间椭圆表示需要开发的程序，两侧方框表示该程序与外部实体进行的交互。
0层图
在顶层图基础上，对需开发程序细化，将整体程序拆分成部件。
底层子图
在0层的基础上，对部件进行进一步细化。
数据字典
数据字典用来配合数据流图的使用，对一些数据或名词进行相应的诠释。
| 符号 | 含义 | 例子 |
| + | 与 | a+b 表示 a 与 b，即 a 和 b |
| = | 被定义为 | 机票=姓名+日期+航班号+起点+终点+费用； 表示：元素姓名、日期、航班号、起点、终点、费用被定义为机票 |
| [......，......] [......|......] | 或 | x=[a，b]、x=[a | b]，表示x由a组成或者由b组成 |
| {......} | 重复 | x={a}，x由0个或者多个a组成 |
| （......） | 可选 | x=（a），表示a可以在x中出现，也可以不出现 |
数据流图平衡原则
父图与子图之间的平衡
数据流图的平衡原则是上层图与下层图（父图与子图）之间，凡是在上层数据流图中出现的交互，在下层数据流图中也必须出现，且方向、数量、名词都需一致。
例如下图顶层数据流图中，外部组织前端应用，与需开发程序数据管理之间有6个箭头，那么在此图细化而成的0层数据流图中，二者之间的交互也应该是6个箭头，并且箭头的名词、方向、数量都需相同。另外两个外部交互组织，数据管理员、后端数据库也需要遵循此原则。
注：由数据需开发程序，数据管理中间件细化而成的内部交互与此无关。
子图内平衡
子图内平衡是指在加工这一项操作中，如果有输入必须有输出才能算作平衡，有输入无输出称作黑洞；无输出有输入称作奇迹；还有一种是输入与输出不对等，或者输出与输入不对等；此三者都属于不平衡，在数据流图中违背平衡原则是错误的。
例
关于数据流图的平衡原则一般的考察方式是给定上层图（或下层图），让判断下层图（或上层图）之间的交互对应关系有无缺失和错误，尤其注意有无箭头指向的方向错误，此错误容易忽略。
上图中红色代表上层图与下层图共有的交互，蓝色代表下层图中缺失的交互，绿色表示需开发程序的细化。如图中，下层图缺失2个上层图中存在的交互，此为不平衡。
数据流图考察
数据流图考察一般为大题类型，首要的是尽可能详细的分析题目中的题干信息，数据流图就是根据题干绘制而成的，然后再利用平衡原则查看是否有数据流方向问题，数据流是否缺失等。
五、UML建模
UML建模部分包含多种类型的图。考察方式一般为大题。
UML三部分
构造块
UML事物
结构事物是UML模型中的名词，通常是，模型的静态部分描述概念或物理元素。
行为事物是UML模型的动态部分，通常是，模型中的动词，描述跨越时间和空间的行为。
分组事物是UML模型的组织部分，通常是由模型分解成的盒子。
注释事物是UML模型的解释部分，通常是用来描述，说明模型的任何元素。
图
图分为：结构图（静态图）、行为图（动态图）
结构图（静态图）
行为图（动态图）
用例图
考察方式其一是根据题干将图做补充或者修改，其二是根据题干判断两个用例之间属于包含关系、扩展关系、泛化关系中的哪一种。
类图与对象图
考察方式其一是根据题干信息填写类名、方法名、属性名；其二是填写多重度；其三是填关系。多重度和关系需要牢记。
多重度
| 1 | 表示一个集合中的一个对象对应另一个集合中的一个对象，可以是数字2、3等意义同上 |
| 0..*或* | 表示一个集合中的一个对象对应另一个集合中的0个或多个对象（可以是0个不对应） |
| 1..* | 表示一个集合中的一个对象对应另一个集合中的1个或多个对象（至少对应1个） |
| 0..1 | 表示一个集合中的一个对象对应另一个集合中的0个或1个对象 |
关系
例
对象图是类图的一个实例。
顺序图
考察方式一般是通过阅读题干，将题干与图相结合，对图进行补充，但是考察方式比较简单。其一是一般会给与消息名称，让把消息名称填到对应的位置，其二是根据题干填写对象名。顺序图执行方式是由上到下，顺序图是动态图它表现处理事务的时间顺序情况。
例
图中蓝色表示对象，对象一般住在最上方，例如最左侧对象中标注的CardRead则为对象名，考察时可能会让根据题干标注对应的对象名，其下的虚线称作生命线 ；
图中粉色1-11表示消息，考察时可能会让根据题干内容标注对象名例如消息6-9；
绿色箭头表示两个对象之间有交互，例如左上方第一个箭头表示对象CardRead发送消息carInserted给对象ATM，部分题目中会将实线箭头看作调用，虚线箭头看作返回。
活动图
活动图类似于流程图，能表现整个处理流程的基本情况和分支状态。考察方式是根据题干信息补充图中信息。
例
如下图，图中的粗黑线表示分支与合并。
活动图还有带泳道的模式，每个泳道代表不同的对象，泳道的作用是可以更加明确活动图中的活动归属于哪个对象。
状态图
状态图是动态图，表现状态的变迁，往往以状态为结点，连线为触发事件，状态结点经过事件出发转变为另一状态。考察方式为根据题干完善状态图，其一是填充结点中的状态，其二是填充连线上的触发事件。
例
通信图
通信图又称协作图，是顺序图的另一种表达方式，只是顺序图更强调时间，而通信图的事件进行时间没有顺序图明晰。所以通信图与顺序图有时统称交互图。考察方式是研读题干，将题干与图对应，其一是填充对象名，其二是填充消息。
例
图中黄色结点表示对象，其中内容为对象名，实现与虚线箭头表示对象之间的消息传递。
六、其他
1、C++中类的继承
公有继承public
派生类成员能访问基类中的共有成员和保护成员
私有继承private
派生的子类不能访问基类中的成员
保护继承protected
只能被派生的子类访问基类中的成员
2、静态数据成员
类的静态数据成员与一般的类成员不同：
静态数据成员只能访问静态数据成员；
静态数据成员无法访问普通数据成员；
任何成员都可以访问静态成员；
标签：基本,对象,子类,交互,模式,面向对象,接口,数据流,方法 From： https://blog.csdn.net/m0_55661792/article/details/142431104