软件产品开发流程是需求、分析、设计、实现。
面向对象三大特征：继承性，封装性、多态性
模型将软件生命周期划分为软件计划、需求分析和定义、软件设计、软件实现、软件测试、软件运行和维护这六个阶段，自上而下、相互衔接的固定次序。
统一过程的五个核心工作流分别是需求流、分析流、设计流、实现流和测试流四个阶段分别是开始阶段、细化阶段、构建阶段和转换阶段。
需求分析阶段：
使用活动图描述业务过程。
用用例图描述整个系统的功能范围。
如果某个需求的流程比较复杂，则使用活动图描述。
设计阶段：
使用类图说明类之间的静态结构关系。
使用顺序图说明类之间的动态调用时序。
使用状态图描述对象的状态变化
使用活动图描述某种算法。
用例图
UML定义：UML（Unified Modeling Language，统一建模语言），是一种面向对象的建模语言。
用例图主要用来图示化系统的主事件流程，它主要用来描述客户的需求，即用户希望系统具备的完成一定功能的动作，通俗地理解用例就是软件的功能模块，所以是设计系统分析阶段的起点，设计人员根据客户的需求来创建和解释用例图，用来描述软件应具备哪些功能模块以及这些模块之间的调用关系
包含关系：基用例必须和包含用例一起使用才够完整，包含用例也必然被执行。包含关系在用例图中使用带箭头的虚线表示(在线上标注<<include>>)，箭头从基用例指向包含用例。
扩展关系：扩展用例是对基用例的扩展，即使没有扩展用例的参与，也可以完成一个完整的功能。扩展在用例图中使用带箭头的虚线表示(在线上标注<<extend>>)，箭头从扩展用例指向基用例。
泛化关系：是一种继承关系，泛化关系在用例图中用实线+空心三角形表示，空心三角形指向父参与者，子参与者可以继承父参与者所有的行为。子用例可以使用父用例的一段行为，也可以重载它。父用例通常是抽象的，子用例中的特殊行为都可以作为父用例中的备选流存在。
| 关系
|
说明 | |
| 参与者与用例之间的关系 | 关联 |
表示该用例是该参与者发起的，表示参与者可以行使系统中的这个功能 |
| 用例之间的关系 | 包含 |
基用例必须和包含用例一起使用才够完整，包含用例也必然被执行。包含关系在用例图中使用带箭头的虚线表示(在线上标注<<include>>)，箭头从基用例指向包含用例。
|
| 扩展 |
扩展用例是对基用例的扩展，即使没有扩展用例的参与，也可以完成一个完整的功能。扩展在用例图中使用带箭头的虚线表示(在线上标注<<extend>>)，箭头从扩展用例指向基用例。 |
|
| 泛化 |
子用例指向父用例，父用例一般是抽象用例 |
|
| 参与者之间的关系 | 泛化 | 是一种继承关系，泛化关系在用例图中用实线+空心三角形表示，空心三角形指向父参与者，子参与者可以继承父参与者所有的行为。 |
类图
类（Class）：使用三层矩形框表示。
第一层显示类的名称，如果是抽象类，则就用斜体显示。
第二层是字段和属性。
第三层是类的方法。
注意前面的符号，‘+’表示public，‘-’表示private，‘#’表示protected。
UML类图符号之接口：使用两层矩形框表示，与类图的区别主要是顶端有<<interface>>显示。
第一行是接口名称。
第二行是接口方法。
UML类图符号之继承类（extends）：用空心三角形+实线来表示。
UML类图符号之实现接口
结，它使一个类知道另一个类的属性和方法。
- UML类图符号之聚合（Aggregation）：用空心的菱形+实线箭头来表示
聚合：表示一种弱的‘拥有’关系，体现的是A对象可以包含B对象，但B对象不是A对象的一部分，例如：公司和员工 - 组合（Composition）：用实心的菱形+实线箭头来表示
（implements）：用空心三角形+虚线来表示 - UML类图符号之关联（Association）：用实线箭头来表示，例如：燕子与气
- 关联关系是类与类之间的联组合：部分和整体的关系，并且生命周期是相同的。例如：人与手
- UML类图符号之依赖（Dependency）：用虚线箭头来表示，例如：动物与氧气
- 依赖关系也是类与类之间的联结
依赖总是单向的。（#add 注意，要避免双向依赖。一般来说，不应该存在双向依赖。）
依赖关系在Java或 C++ 语言中体现为局部变量、方法的参数或者对静态方法的调用。实现（Realization）：空心箭头和虚线表示
7.实现（Realize）：元素A定义一个约定，元素B实现这个约定，则B和A的关系是Realize，B realize A。这个关系最常用于接口。uml中用空心箭头和虚线表示，箭头指向定义约定的元素。实现关系指定两个实体之间的一个合同。换言之，一个实体定义一个合同，而另一个实体保证履行该合同。对Java应用程序进行建模时，实现关系可直接用implements关键字来表示。
UML类图符号之基数：连线两端的数字表明这一端的类可以有几个实例，比如：一个鸟应该有两只翅膀。如果一个类可能有无数个实例，则就用‘n’来表示。关联、聚合、组合是有基数的。
单一职责原则
类（Class）是面向对象的重要组成部分，每个类都具有一定的职责，职责指的是类要完成什么样的功能（单一职责）
参考：https://blog.csdn.net/shang_0122/article/details/106637782
在UML中，聚合关系用带空心菱形+实箭头表示，空心菱形指向整体，实箭头指向部分.单一职责原则定义
单一职责原则(Single Responsibility Principle, SRP)定义如下：
在软件系统中，一个类只负责一个功能领域中的相应职责。
另一种定义方式如下：
就一个类而言，应该仅有一个引起它变化的原因。
lsp：如果子类不能完整地实现父类的方法，或者父类的某些方法在子类中已经发生“畸变”，则建议断开父子继承关系
成员对象与整体对象之间具有共生共灭的关系。在UML中，组合关系用实心菱形+实箭头表示，实心菱形指向整体，箭头指向部分。
在使用里氏代换原则时需要注意如下几个问题：
为了保证系统的扩展性，在程序中尽量使用父类类型来对对象进行定义，而在运行时再确定其子类类型，用子类对象来替换父类对象。所以子类的所有方法必须在父类中声明如果一个方法只存在子类中，在父类中不提供相应的声明，则无法在以父类定义的对象中使用该方法。
尽量把父类设计为抽象类或者接口，运行时，子类实例替换父类实例，我们可以很方便地扩展系统的功能，同时无须修改原有子类的代码，增加新的功能可以通过增加一个新的子类来实现。里氏代换原则是开闭原则的具体实现手段之一。
如果有疑问和需要，可以评论共同学习进步