UML和ERD
UML
UML是Unified Modeling Language的英文缩写，中文名称为统一建模语言。它是一套图形化的符号语义系统，可以说是RUP的“副产品”。但有意思的是，它的名气好像比RUP还大，而且RUP虽然已经逐渐没落了，但它却经久不衰。
UML诞生的时间，正是面向对象的软件设计（Object-Oriented Design，OOD）方法论逐步迈向C位的时代。彼时，各种编程语言、设计思想、开发流程、管理方法如雨后春笋般纷纷冒头，给实际的软件开发工作造成了很大的困扰，工程师们语言不通、思想不统一、流程不一致，导致交流想法异常困难。
而UML通过一套图形标志来同意这种差异。例如，当使用不同编程语言进行开发的工程师们讨论类的时候，他们可以用UML的类图画出心中所想，然后告诉其他人：这就是我要表达的类。而懂UML工程师看到类图就能马上明白：哦，原来TA说的是这个意思。
UML在软件开发领域中的作用，就如同建筑设计图在工程领域中的作用。
UML包括三大类设计图。
结构图，用于描述系统的静态结构，包括类图（Class Diagram）、对象图（Object Diagram）、组件图（Component Diagram）和部署图（Deployment Diagram）。行为图，用于描述系统的动态行为，包括用例图（Use Case Diagram）、活动图（Activity Diagram，也叫流程图）、状态图（State Diagram）、时序图（Sequence Diagram）和通信图（Communication Diagram）。交互图，描述系统中对象之间的交互关系，包括时序图（Sequence Diagram）和协作图（Collaboration Diagram）。
如果按软件项目的开发阶段来划分，出现频率最高的几种分别是用例图、类或对象图、流程图、状态图和时序图。
用例图
可以画图的工具很多，但能完整遵循标准UML语法的工具很少。我自己经常使用的只有Rational Rose（目前已经不可用）和StarUML。
StarUML很好地继承了Rational Rose的大部分功能，风格上也是一脉相承，而且至今仍在更新。
可以把用例（Use Case）理解为一个独立且完整的功能需求，它用来描述用户、系统、需求这三者之间的关联关系。
通过用例，开发工程师可以清楚地知道下面的信息。
系统为谁服务？谁是最终用户（而非中间用户）？
最终用户希望系统提供什么样的服务？又希望得到什么样的输出？
最终用户能为系统提供什么样的输入？有哪些约束条件？
用例图主要有四个组成部分。
参与者（Actor），它并非指具体的人，而是指的存在于外部并直接与系统交互的人、子系统、其他系统或对象，它在UML中用一个小人表示。
用例（Use Case），用来描述需要给参与者提供的功能或服务。它必须由参与者来执行，获取参与者的输入，并将输出结果反馈给参与者或系统。
关系（Association），表示参与者和用例之间的联系，也可以用来表示参与者和参与者、用例和用例之间的关系。有四种关系：关联、包含、扩展和泛化。
系统（System），是用例需要描述的对象，它可以是一个软件平台或者一个硬件设备，或者是一次促销活动，也可以是一个更大的系统的一部分。它有自己的边界，由参与者、用例和关系共同组成。
另外，在用例文档中切忌啰嗦，一般都是非常简洁的名词 + 动词的形式来描述主要业务流程，至于分支流程和边界条件等详细内容，可以在需求说明书中给出。
下面是一个良好的用例文档范例。
1.用户打开登录界面。
2.用户输入用户名和密码。
3.系统确认用户名和密码。
4.用户登录成功。
5.......而比较啰嗦的反面典型则是这样的。
1.用户打开浏览器，然后在浏览器地址栏中输入地址......，浏览器保存Cookie......。
2.页面显示出登录界面，用户单击页面输入框，然后输入用户名和密码。
3.输入用户名密码时弹出人机确认对话框，用户确认身份，系统读取用户输入的登录名称和密码。
4.后台先验证用户名是否存在，核对用户密码是否正确。如果用户存在且密码匹配则用户登录成，否则登录失败，给出页面提示。
5.......类图
用例图描述的是需求的结构及其关系，而类图则反应的是系统中类或对象之间的结构与关联关系。这是一种静态的建模方法，是对现实世界的抽象。
类图分为两大部分，一是类的基本属性，包括类名、类的属性和类的方法。
类图的另外一部分就是类与类之间的关系。在UML类图中，类之间共有六种关系：关联关系、聚合关系、组合关系、实现关系、泛化关系和依赖关系。
流程图
流程图就是将业务流程的各个环节和分支条件按照事件发生的顺序展现出来。
下面就是典型的用户登录流程图。
上面图中有三个竖长的矩形，分别表示用户、后端和``前端，这在流程图中称为泳道`，就像泳池中的泳道一样，所以流程图有时候也叫“泳道图”。
当然，没有这些修饰，流程图依然是流程图。
状态图
状态图和流程图非常类似，但它关注的不是业务流程的推进，而是某些业务领域在事件发生时的状态变化，例如订单状态。
有些UML图中将状态图弄的很复杂，包括诸如组合状态、历史状态、状态机等概念，但大多数情况下都用不到它们。
当状态A经过事件1时，如果符合条件A，就转换到状态B，否则就转换到状态C。
状态C可以通过条件B完成自身状态的不断循环检查，例如已创建的订单如果未付款，那么它是否还在付款超时时间之内等这样的循环检查条件。
只有当状态B和状态C同时满足业务约束A时，业务才能继续转换到状态D并进而完成。
以终端用户视角的订单履约状态为例，其状态图会像下面这样。
时序图
时序图又被称为序列图（Sequence Diagram），它通过对象之间互相调用方法以及发送消息的时间顺序，来显示多个对象之间的动态协作过程。
时序图将类图和流程图结合到了一起，它既有对象的方法调用，也有调用时的流程事件。相对于其他UML图，时序图更强调交互的时间顺序，同时也能很直观地描述并发过程。时序图的组成部分也比较多，但和状态图一样，真正需要用到的并不多。一个最简单的时序图一定会包括这四类组件：对象、生命线、关联消息和控制焦点。
下面是OAuth 2.0第三方授权登录时序图。
搞清楚了时序图的结构后，就不难用它来画出与业务相关的对象之间的调用过程了。
ERD
如果说UML图是用来图形来表示业务系统的结构的话，那么ERD就是一种特殊的UML图，它表示的是业务数据库的各种数据表的结构及其之间的关系。
ERD是英文Entity-Relationship Diagram的翻译，称为实体-关系图，主要用于表示数据实体Entity（通常对应于数据表）、属性Attribute（通常对应于数据表中的字段）和实体之间的关系Relationship（即数据表之间的关联），它是数据库设计中最为常用的工具，没有之一。
通过ERD，可以清晰地展示出数据模型中各个实体之间的关系，有助于数据库设计人员理解需求和设计出合理的数据（库）模型。
ERD从概念上分为逻辑模型与物理模型，这两类模型其实本质上是同一个，只是详细程度不同。
逻辑模型描述了数据之间的逻辑关系，它独立于具体的数据库管理系统DBMS或存储结构，更侧重于抽象的逻辑概念，而不涉及具体的物理存储细节。
物理模型除了添加了更详细的字段属性之外，它和逻辑模型基本没什么区别，而且从模型设计图的外观上也看不出什么不同。可能唯一的区别在于有些ERD软件可以直接从物理模型生成初始化数据库的SQL语句吧，例如PowerDesigner。
在ERD中，不同的数据实体Entity之间有六种关系。
None，表示一个实体与任何其他的实体之间都没有关系，属于是孤零零的存在，这种情况多见于一些配置表、系统初始化表等之类的特殊实体。One and Only One，表示一个实体有且仅有一个对应的实体，如果另一个实体也是这种关系，那这两个实体之间就是基本的一对一映射关系（1 : 1）。例如，每个自然人有且仅有一个对应的身份证，反过来也一样，那么它们之间就是一对一的关系。
Zero or One，这是一对一映射关系的一个特例，表示一个实体要么没有对应的实体，要么最多只有一个对应的实体。例如，自然人和身份证之间的关系，每个人刚出生的头几年之内都可以没有身份证，但之后最多只能有一个身份证。
Many，表示一个实体有多个其他对应的实体，这种关系称为一对多映射关系（1 : n），例如，班级和学生之间就是这种一对多的关系。如果另一个实体也是这种关系，那这两个实体之间就是基本的多对多映射关系（m : n）。例如，学生和课程之间的关系就是多对多的关系。
One or Many，这是多对多映射关系的一种特例，表示每个实体至少有另一个对应的实体，或者有多个对应的实体。例如，一本书至少有一个作者，也可以是多为作者联合编写（但书是不可能没有任何作者而能独立存在的）。
Zero or Many，这是多对多映射关系的另一个特例，表示每个实体要么没有另一个对应的实体，要么有多个对应的实体。例如，用户和聊天群之间就属于这种关系。某个用户可以不加入任何聊天群，也可以在多个聊天群中。
需要特别注意的是，大多数数据库表之间的关系都是双向的，而且并不是说一张表对另一张表的关系反过来也成立。
例如，当数据表A为左表，而数据表B为右表时，它们之间是“Zero or One”的映射关系，但是反过来，当数据表B为左表，而数据表A为右表时，它们之间就可能是另外一种映射关系了。
有一个非常典型的例子。
对用户来说，TA可以不加入任何聊天群，也可以属于一个或多个聊天群，是典型的
Zero or Many的映射关系。对聊天群来说，它至少要有一个用户，也可以有多个用户，是典型的
One or Many的映射关系。
这一点是每个有经验的开发工程师或者数据库工程师都必须要知道的。
感谢支持
更多内容，请移步《超级个体》。