Unified Modeling Language 统一建模语言，又称标准建模语言。是用来对软件密集系统进行可视化建模的一种语言。语言，也就是一个表达思想的符号约定。
从命名上分析：统一、建模、语言
统一：没有规矩不成方圆，它指定了一种标准，一种约束，使得大家的表达变得一致。它被 OMG（Object Management Group）所认可。
OMG是一个国际化的、开放成员的、非盈利性的计算机行业标准协会，该协会成立于1989年，他是软件行业中一个标准的认可。包括客户、领域专家、分析师、设计师、程序员、测试工程师及培训人员等。UML成为他们工作中统一的沟通工具，用于充分理解和表达自己所关注的内容。
建模：复杂业务系统建模，即建立软件系统模型。UML 的创始人之一 Booch，曾用建一座摩天大楼来比喻 UML 的必要性。简单系统下，可有可无，系统复杂或大到一定程度，建模和文档成为系统周期里非常重要的一环。
语言：面向对象思想的表达。互相之间的沟通工具。一种按照特定规则和模式组成的符号系统。
观点一：UML 是鸡肋，离程序员真正需要的设计工具还差得很远。只有为数不多的程序员使用这个工具交流想法，而没有用在具体工作中。
观点二：UML 设计相当的严谨与全面，在面向对象的系统架构上，可以便捷的表达你想要表达的一切想法，优美切无可替代。
个人观点：一项技能和工具，学会并不难，需要的时候能拿来用就好，艺不压身。
不要把 UML 过度神化
一个表达想法的工具而已
当用则用，不要刻意去套
关系是现实世界中事物与事物之间相互关系的符号表达，抽象到面向对象理念上，大致分为 6 种。
定义：
代码：
//类
public class Animal {
}
public class Cat extends Animal {
}
//接口
public interface Action {
}
public interface Jump extends Action {
}
定义：
代码：
public interface Jump {
}
public class Tiger implements Jump {
}
定义：
代码：方法参数，局部变量
定义：
代码：成员变量
定义：
代码：成员变量，多为集合
正在上传…重新上传取消 定义：
代码：成员变量，多为集合
一张图涵盖所有的关系：
UML 中的图形非常多，按类型分为结构图和行为图，其中，最常用，最典型的为 9 种，下面分开来介绍。
用例图：从用户角度描述系统功能。
类图：描述系统中类的静态结构。
对象图：系统中的多个对象在某一时刻的状态。
状态图：是描述状态到状态控制流，用于表达系统状态的变化
活动图：描述了业务实现用例的工作流程，强调的是动作之间的衔接
序列图：对象之间的动态合作关系，强调对象发送消息的顺序
协作图：描述对象之间的协助关系，强调对象之间的合作关系
组件图：描述系统各个组件及其相关关系的静态视图
部署图：定义系统中软硬件的物理体系结构
1）说明
2）可用元素
正在上传…重新上传取消
正在上传…重新上传取消
3）实例
正在上传…重新上传取消
1）说明
2）可用元素
正在上传…重新上传取消
3）关系
对象图因为是运行在某个时间节点的对象镜像，所以关系比较单一，描述的是类与类的实例之间。不涉及接口
4）图例
1）说明
UML1.1 中，组件图是用来描述一个系统的物理构件。包括文件，可执行文件，库等
UML2 中，关注组件间的关联（使用什么接口，通过什么端口通讯），强调通过接口来描述组件行为
对于后端来说，组件图比较适用于 SOA 架构、微服务架构，描述整个系统的结构以及子系统间的通讯方式
对于前端来说，组件图适合在使用类似 react、vue 这样组件化的前端技术框架时，表达对组件的设计，比如一个页面会有个骨架组件，骨架组件包含了导航组件，列表组件等等
2）可用元素
组件：描述的是系统的其中一个组成部分，一个完整的可独立服务的模块或单元，比如订单服务，k8s 里的一个 pod
部件：组件内可能细化为多个子模块
端口：组件对外提供服务就必须暴露对应的端口。如 http rest 服务默认的 80
接口：部件 / 组件之间的一种约定，分提供者和需求者同时展示了某个部件提供出的功能
3）关系
4）图例
1）说明
一种展示运行时进行处理的节点和在节点上存在的组件配置的图。
阐述了在实际应用中软件和它的运行环境的关系，并且描述了软件部署在硬件上的具体方式。
2）可用元素
正在上传…重新上传取消
节点：
早先单实例 MVC 架构下，节点可以认为是某台物理服务器，微服务及容器化下，物理服务器大多纳入编排管理，docker 实例由系统在物理节点见自由调度，组件无法锁定在某个固定物理节点上，这种环境下的 node 可以理解为一个容器，或 k8s 中的 pod。
组件实例
相当于组件里的实例化，类比于类和对象
3）关系
4）图例
1）说明
用例图是用来描述系统功能的技术，表示一个系统中用例与参与者及其关系的图
主要用于需求分析阶段，和产品文档比较贴近
用例图相当于从用户的视角来描述和建模整个系统，分析系统的功能与行为。
2）可用元素
正在上传…重新上传取消
3）关系
泛化：参与者之间可用泛化，例如用户与普通会员；用例也可用泛化，如用户管理与修改密码
关联：发生于参与者和用例之间，表示该角色可用有哪些用例（行为）
依赖：发生与用例之间，例如登录依赖于注册
4）图例
交互图分为序列图和协作图，两者既可以相互转换而不丢失信息，又存在一定差异。下面分开讲再类比
序列图
1）说明
2）可用元素
3）关系
4）图例
协作图（1.4）/ 通信图（2.0）
1）说明
协作图与时序图类似，二者都是用对象间的交互来描述用例的。
两者关注角度稍有不同，时序图强调交互的时间次序，协作图强调交互的空间结构。
2）可用元素
3）关系
4）图例
两种交互图可以相互转化，类比如下：
状态机分为状态图和活动图，
状态图
1）说明
2）可用元素
3）关系
4）图例
正在上传…重新上传取消
活动图
1）说明
2）可用元素
3）关系
4）图例
老牌，大名鼎鼎，史上最有名的 UML 产品，以至于大多数情况下，很多人将他等同于 UML 工具，需要注意的是，自从 Rational 被 IBM 收购之后，Rational Rose 已经成为历史，作为 UML1.4 标准的产物，现在已经不升级，但是够用。其替代品是 IBM 的其他产品，如 IBM RSA。
IBM® Rational® Software Architect ，IBM 的旗舰产品，是一个高级而又全面的应用程序设计、建模和开发工具，用于实现端到端的软件交付。通过和 IBM 其他产品的协调，支持软件开发的全生命周期开发。但是也有它的缺点，笨重，繁杂（大公司产品的通病？？？）
Sparx Systems 公司的旗舰产品。它覆盖了系统开发的整个周期，除了开发类模型之外，还包括事务进程分析，使用案例需求，动态模型，组件和布局，系统管理，非功能需求，用户界面设计，测试和维护等。总之你需要的基本都可以满足，价格还便宜。性价比之选。
开放源码的 UML 开发工具，是由韩国公司主导开发出来的产品。用 Delphi 写的，是个大神。需要付费，网站提供购买注册码，小巧简单而易用，与 rose 相比更是明显。
VISIO 可以理解为一种通用的画图工具，它具备常见的各种图形，从 VISIO2000 版本才开始涉足软件分析设计到代码生成的全部功能，单纯从画图角度，有着无可比拟的优势，UML 图标仅仅是其中很少的一部分。优点是跟微软的 office 产品的能够很好兼容。可以把图形直接复制或者内嵌到 WORD 的文档中。但是到代码的生成更多是支持微软自家的产品如 VB，C#，ms sql 等（微软的一贯作风），如果仅是画 UML 图和大量的 word 文档表达，它可以满足你。
Sybase 的企业建模和设计解决方案。采用模型驱动方法，将业务与 IT 结合起来，可帮助部署有效的企业体系架构，并为研发生命周期管理提供强大的分析与设计技术。将多种标准数据建模技术集成一体，并与 IDE 集成，典型的如 Eclipse 插件形式。PD 更多给人的印象是数据库建模技术，但是它可以完成 UML 的所有建模操作并映射到数据库和代码层面。并提供 60 多种关系数据库的连接支持。
用例图从订单系统使用人角色出发，反馈订单体系里面有哪些人，可以做哪些事情
1）业务需求：
订单类图从业务模型出发，用面向对象思想，订单业务中的模型抽象为一个个对象
1）元素：
2）关系：
关联：Order→Seller，Buyer，Pay；Shop→Seller
依赖：Order→Cart→Promotion，Invoice；
组合：Shop→Product
聚合：Cart→Product
泛化：Buyer，Seller→User
实现：DiscountPromotion，ReductionPromotion→Promotion；AliPay，WeichatPay，ICBCPay→Pay
对象图表达的是下订单的时刻，系统存在的对象及对象之间的关联关系。对象具备了实际的属性值
1）元素：
2）关系：
序列图反应下单到支付完成这段时间里，各个对象怎么协作和交互，互相之间需要传递什么消息。
1）元素
2）时间序列
协作图同序列图类似，可以由序列图转化而来。但是协作图反映的是交互关系，像是铺开的时序图
1）元素，同时序图
2）交互，同序列图
以 B2B 先款后货业务模式下，订单对象的流转状态为例，实现业务状态展示
1）元素
2）流转
在先款后货的交易中，双方都要做哪些活动或者说操作，通过活动图建模体现
1）元素
2）流程
界定构成订单服务的各个对象以及他们之间的可用接口，相当于定义了一组约定。
1）元素
将订单中心如何部署到服务器？部署图的职责就是完成这部分的内容。在 docker 容器化编排和云环境下，部署图变得不那么的确切。node 可以类比理解为 docker 容器或者是 k8s 等编排工具中的 pod，而组件也不再固定在某个 node 中，而是由调度器动态调度，分散部署。
1）元素
2）关系
一切皆工具，适合你的就是最好的
灵活变通，不要拘泥规矩，规矩是死的人是活的
表达思想才是目的，一切都是为了能说清楚你的想法，这也是语言的本质
不要为了画图而画图，UML 不是必须的，但是有了它你的架构工作会变得更顺畅
希望 UML 能成为你架构工作的利器，提升效率，解决问题。Thanks！
本文由传智教育博学谷 - 狂野架构师教研团队发布！