UML(UnifiedModeling Language，统一建模语言) 是一种在软件设计时提供给分析师、设计师和工程师之间的通用语言。UML在软件需求分析及整个产品生命周期中起着重要作用：一是有助于捕获系统结构或行为；二是有助于定义软件构架，保持设计和实现的一致性；三是有助于管理复业务，方便团队沟通。
UML不仅支持面向对象的分析与设计，还支持产品从0到1的全过程。比如借助UML来与用户进行需求沟通，或指导程序员进行软件开发。UML被应用到面向对象的问题解决上，但面向对象最关键的是建模问题，建模可以把许多复杂业务的重要细节给抽象出。
UML分为结构图和行为图。结构是静态的，它描绘结构元素构成的系统或函数，显示结构或运行时体系结构的静态关系。比如类图、对象图、构件图、部署图。行为是动态的，它描绘一个系统或业务过程的行为特征，显示动态模型的视图。比如活动图、状态图、序列图、用例图。每种图形都是从需求或设计的不同层面来描述模型，通过模型描述系统的类、对象、关联、职责、行为、接口、用例、包、顺序、协作及状态。产品经理可以通过图形化的方式，从各个角度了解产品，以便更好的表达思想与交流问题。
UML建模常用的工具有：ProcessOn、EnterpriseArchitect 、Visio、StarUML、OmniGraffle、ArgoUML。UML建模常见的模型有：业务模型、需求模型、设计模型、实现模型、数据库模型。UML建模的重点不在于如何画UML，而是如何运用UML去管理好一个产品。UML建模适用于不同的场景设计，可从不同角度诠释产品。因侧重从产品经理的角度谈UML建模，所以只介绍用例图、状态图、活动图、时序图与类图。
用例图（UseCase Diagram）
用例图从外部观察者的角度描述系统的作用。用例图描述了系统的功能要求，强调从用户自身角度，分析其功能范围，但不关心具体实现。
1.参与者就是与应用程序或系统进行交互的用户或系统；
2.用例就是外部可见的系统功能，对系统提供的服务进行描述；
3.子系统用来展示系统的一部分功能，这部分功能联系紧密。
以某共享出行系统的乘客为例，在设计用例的时候，一般是按用户角度从Uc级描述统功能，并指向各功能的操作者。比如乘客主要负责的功能有登录平台、微信授权、扫码设备、选择套餐、支付订单与查看订单等。我们可以用一种可视化的方式，来设计系统的功能需求，本质还是扩展功能的增删改查。
状态图（State Diagram）
状态图由状态、转换、事件和活动组成，描述对象所有可能的状态以及事件发生转移的条件。状态图一般为那些有多个状态的、行为随外界环境而改变的类画状态图。根本就是阐明其在生命周期的时间和状态图是用于此目的的一个对象，将满足某些条件、执行某些活动、等待某些事件。
1.研究类、角色、子系统、或组件的复杂行为；
2.在进入和退出状态时所执行的操作；
3.在不使状态发生变更的情况下进行的转移。
以某共享出行出行系统为例，客户完成扫码按摩的订单对象的生存期间的状态序列，引起转移的事件，以及因状态转移而伴随的动作。从扫码充电订单状态从待支付，已完成、已退款到交易关闭都是一个完整的业务闭环。实际应用中并不是所有的类都需要画状态图，有三个及以上状态，且在不同状态下行为有所不同的类才需要画状态图。
活动图（Activity Diagram）
活动图是一种表述业务过程以及工作流的流程图，直白点就是使工作流和业务过程可视化的图。它描述活动的顺序，展现从一个活动到另一个活动的控制流，有利于识别并行活动，能够快速分析业务流程、理解系统功能、挖掘潜在的业务需求。
1.动作状态就是指不可中断的动作，并在此动作完成后，通过完成转换转向另一个状态；
2.动作流就是动作之间的转换过程；
3.节点主要有开始节点、终止节点、分支节点与合并节点，本质都是对流程的约束。
以某跨境电商平台为例，客户完成商品结算的这一活动过程中，分别是查看商品、购买商品、商品结算这三方面完成流程的转换。其实就是从行为动作描述具体业务与工作流程，以及各项业务之间的约束关系。
时序图（Sequence Diagram）
时序图是一种强调时间顺序的交互图，它通过描述对象之间请求和响应消息的时间顺序，来显示多个对象之间的动态协作。时序图具备了时间顺序的概念，提供了控制流随着时间推移的可视化轨迹，从而可以清晰地表示出对象在某一个时刻的动态行为。
1.生命线是一条垂直的虚线，从对象底部延伸出来的，表示对象存在的时间；
2.控制焦点是时序图中表示时间段的符号，在这个时间段内，对象可执行相应的操作；
3.消息显示为箭头，消息可以完成传输，可是同步的，也可是异步的，即可以是请求，也可以是响应。
以某车生活平台为例，车主通过服务劵可以进行线上车服务相关的预约，门店确认预约订单后，车主可以凭劵码到门店进行服务的流程。车主预约中参与交互的所有对象之间消息传递的时间顺序，可以清晰的梳理业务流程及对象关系，保证产品需求的准确性、可实现性。
类图（ClassDiagram）
类图是一种静态模型，通过显示系统的类，以及类之间的关系来表示系统。类图是静态的，可以展现软件系统中的类、接口以及它们之间的架构。类之间关系主要有泛化，实现，关联，聚合，组合与依赖。
1.类是对象类型的表现形式，反映出这类对象在系统内的的结构和行为；
2.接口是实施者需要满足的行为规范；
3.包是一个命名空间，也是一个元素。
以某共享出行系统为例，我们可以直观的看出公司、司机、车辆、设备、业务员之间的对应关系。比如一个公司对应多个车辆，一个车辆又对应多个按摩设备，理清他们之前的结构关系，就可以快速了解业务逻辑和完成表结构设计。
UML在整个软件开发过程中，解决了“一盘散沙”的问题，在国内不少地方获得了应用。作为产品经理，学习UML必须从模型的建造开始，一个萝卜一个坑的去将UML建模实践到产品中，不断历练自己，才能学有所成。当我们对UML建模的各图形都有所了解后，就可以全面的、深入的从各个角度表达产品，让表达变得更丰富、更形象。
对于产品经理而言，掌握UML有助于梳理业务流程和传达产品需求。我们不仅要深挖前端业务流程，还要理解看不见的后端实现逻辑。很多产品在版本迭代阶段，产品经理很容易忽视产品的隐性特性，对产品的核心功能无法深挖或理解，导致实施中还在讨论需求或需求变更，或上线后功能不符合需求，主要原因是缺少对后端整体功能的统筹与把控。而UML的出现，让产品经理拥有一套与技术人员沟通的共同语言，在工作中需求对称会变得更顺畅。